Website accessibility testing checklist
A concrete, runnable checklist for WCAG 2.x A/AA accessibility: color contrast, alt text, ARIA, keyboard navigation, form labels, heading structure, and focus states. Each item tells you what passes, how Mira's automated audit checks it, and how to verify it by hand in under a minute.
Automating the checklist first is the fastest start. See what Mira's automated accessibility audit checks — it runs free as part of the general site test.
The 7-point WCAG accessibility checklist
Work through the list top to bottom on any page you're about to ship. Each point covers the WCAG 2.1 A/AA success criteria that matter most for screen-reader and keyboard users — and each maps to how Mira's automated audit checks it and how you can verify it manually.
-
1
Color contrast: 4.5:1 for text, 3:1 for large text and UI
Normal-size text needs a contrast ratio of at least 4.5:1 against its background; large text (24px+, or 18.66px+ when bold) and UI components such as input borders and icons need at least 3:1.
Mira checks: text and UI elements that fail the WCAG contrast ratio thresholds, reported with the rule that fired.
Manual check: sample key text and button colors with a contrast checker or the browser's eyedropper against the real background — gradients, images, and hover states included.
-
2
Alt text on every meaningful image
Informative images carry alt text that describes their purpose (WCAG 1.1.1); decorative images use an empty alt and are hidden from assistive technology instead of read out as filenames.
Mira checks: images without alternative text, and decorative images that should be hidden from screen readers.
Manual check: in DevTools, inspect each
img(or open the Accessibility tree) and confirm every informative image has a purpose-describing alt, every decorative one an emptyalt="". -
3
ARIA roles and labels that assist, not confuse
Interactive controls that have no visible text carry an accessible name (
aria-label,aria-labelledby), roles match the behavior (a button is a button), and no redundant or invalid ARIA is present.Mira checks: missing, redundant, or invalid ARIA attributes that confuse assistive technology.
Manual check: open the browser's Accessibility tree, walk the named controls, and confirm each interactive element announces a name and a role that matches what it does.
-
4
Keyboard navigation with no traps
Every interactive element is reachable and operable with the keyboard alone (WCAG 2.1.1): Tab moves forward, Shift+Tab backward, Enter and Space activate, Escape closes dialogs and menus — and focus never gets stuck in a trap.
Mira checks: interactions that trap the keyboard or cannot be reached without a mouse.
Manual check: press Tab from the top of the page and complete one full journey (open a menu, fill a form, submit) using only the keyboard; confirm the focus ring moves in a logical order and never disappears into a trap.
-
5
Every form input has a programmatic label
Each input, select, and textarea has a label associated via
label for/idor an accessible name — a placeholder text is not a label (WCAG 3.3.2, 4.1.2). Errors are described, not just colored.Mira checks: inputs without a programmatically associated label, name, or accessible description.
Manual check: click each label — the associated input should receive focus. Then inspect the Accessibility tree and confirm every field announces a name.
-
6
Heading structure: one H1, logical order
Exactly one
h1per page, headings arranged in a logical descending hierarchy with no skipped levels, and headings used for structure — not for styling text.Mira checks: skipped heading levels that break the document outline for screen-reader users.
Manual check: use the browser's document outline or a headings extension and confirm the page has exactly one H1 and flows h1 → h2 → h3 without jumps.
-
7
A visible focus indicator on every interactive element
Keyboard focus is always visible (WCAG 2.4.7): a clear outline, ring, or background change on links, buttons, and inputs — never removed entirely via
outline: nonewithout a replacement.Mira checks: interactive elements with no visible focus indicator, so keyboard users lose their place.
Manual check: Tab through the page and confirm a clearly visible focus indicator moves with you — including on dark backgrounds and custom-styled controls.
Automated audit first, human review after
Every point above breaks into two halves: what a machine can verify automatically, and what still needs human judgment. Run the automated half first — it is fast, repeatable, and catches the issues it is actually good at finding. Then use the manual checks for the rest, like whether an alt text describes an image accurately or whether a keyboard flow feels logical.
Mira's automated audit runs the WCAG 2.1 A/AA success criteria that tools like Axe can check automatically (the wcag2a, wcag2aa, and wcag21aa rulesets) on every page the agent visits — as part of the free general site test. It covers the pages the agent discovers and selects, so it doesn't crawl your whole application and doesn't reach pages behind authentication.
One honest caveat that applies to every accessibility testing tool: this is an automated audit, not a WCAG certification or a full compliance review. Findings are model-assisted and can be wrong, and automation can't judge everything a human auditor can. Treat a clean run as a useful signal, then verify against the real pages.
See the automated accessibility audit in detail — what it checks, how it runs for free, and where it stops.
Where the checklist fits in your testing flow
The checklist is most useful when it runs on schedule — on every release, not just the one before launch. These guides cover the rest of that flow:
Run the checklist on the live URL after every deploy — accessibility regressions ship just like any other bug.
Fold these checks into a pre-deploy release checklist next to status codes, titles, and broken links.
How the AI agent discovers representative pages and journeys — and carries the accessibility audit with it.
Target the journeys the broad audit can't reach — like the pages behind login — with plain-English goals.
Frequently asked questions
- Is an automated accessibility audit the same as a WCAG certification?
- No. An automated audit runs the WCAG 2.1 A/AA success criteria that tools like Axe can check automatically. Automation can't judge everything a human auditor can, so a clean automated run is a useful signal — not a WCAG certification and not a full compliance review.
- What contrast ratio does WCAG require for text?
- WCAG 2.x requires at least 4.5:1 for normal-size text and at least 3:1 for large text (24px+, or 18.66px+ when bold) and for UI components and graphical objects such as input borders and icons.
- Can an automated tool check all WCAG A/AA criteria?
- No. Automated tools reliably catch a meaningful subset — missing labels, contrast failures, broken ARIA, keyboard traps, skipped headings, missing focus indicators. Everything else, such as whether an image's alt text is actually accurate, still needs a human reviewing the page.
- How does Mira's automated accessibility audit fit into this checklist?
- As the testing agent visits pages, Mira runs an automated accessibility audit against the WCAG 2.1 A/AA success criteria that tools like Axe can check (the wcag2a, wcag2aa, and wcag21aa rulesets). It is free as part of the general site test and reports what failed and which rule it violates — an automated audit, not a full compliance review.
Let Mira run the checklist for you
Rather than working through the manual steps page by page, bring us in: Mira Checks integrates the automated audit and runs the full QA loop on your site — contrast, alt text, ARIA, keyboard navigation, form labels, headings, and focus states, reported with the rule that failed. One URL in, an audit out.
Try Mira