Guide · WCAG Accessibility Checklist

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. 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. 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 empty alt="".

  3. 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. 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. 5
    Every form input has a programmatic label

    Each input, select, and textarea has a label associated via label for/id or 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. 6
    Heading structure: one H1, logical order

    Exactly one h1 per 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. 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: none without 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.

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