Web Accessibility Checklist: Ensure Your Site Is Inclusive

Web accessibility checklists turn WCAG success criteria into pass or fail tests, and each test points at a barrier that users with visual, auditory, motor or cognitive disabilities run into. The conditions are measurable, like a 4.5:1 text contrast ratio or a 24 by 24 CSS pixel minimum target size. Prerecorded video needs captions too.

WCAG 2.2 added nine success criteria to 2.1 and removed 4.1.1 Parsing (W3C, 2023). The laws lag behind it, though. As of October 2026 the ADA Title II rule cites WCAG 2.1 AA, and Section 508 still cites 2.0 AA.

Which WCAG version and level should the checklist target?

Target WCAG 2.2 Level AA, unless a contract or regulation names an older version.

W3C describes the 2.0 and 2.1 success criteria as essentially unchanged in 2.2, except for 4.1.1 Parsing, which was removed as obsolete. A checklist built on 2.2 AA therefore doubles as a 2.1 AA checklist.

W3C published WCAG 2.2 as a Recommendation on 5 October 2023, adding nine criteria to 2.1 (W3C WAI, What’s New in WCAG 2.2).

Rules on web accessibility usually name a WCAG version, not a checklist. The version decides what an auditor tests.

Auditors working from 2.1 may still list 4.1.1. Keep the markup valid and that item costs nothing.

Level A, AA and AAA in practice

A claim of Level AA covers every Level A criterion and every Level AA criterion.

• Level A is the baseline, with requirements such as text alternatives (1.1.1) and keyboard access (2.1.1).
• Level AA adds contrast, reflow, visible focus, target size and status messages. Most laws and contracts name this level.
• Level AAA tightens some AA rules, 7:1 text contrast being the usual example.

Adopt AAA criteria case by case, not as a site-wide rule.

W3C’s Understanding document for 1.4.3 ties the 7:1 ratio to vision loss near 20/80. Past that point, users usually rely on assistive technology that has its own contrast tools.

Why success criterion counts differ between sources

Published checklists disagree on how many criteria Level A and AA contain. W3C’s own criterion lists settle it.

The 2.1 baseline follows published counts (TestParty, 2025). The two new Level A criteria are 3.2.6 Consistent Help and 3.3.7 Redundant Entry.

The four new AA criteria are 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum) and 3.3.8 Accessible Authentication (Minimum), per W3C.

TestParty’s 2025 guide lists 50 criteria for its 2.2 checklist, which is really the 2.1 count. Clym’s 2026 guide lists 56. Several vendor guides label all six new A and AA criteria as Level AA, while W3C puts two of them at Level A.

Webability’s 2026 total of 55 matches the arithmetic above.

The failures behind 96% of detected errors

A short list of failure types accounts for nearly all the errors that automated scans find. WebAIM concludes that fixing only those would improve the web’s accessibility substantially.

The WebAIM Million, a February 2026 analysis of the top one million home pages, found 95.9% of them had at least one detected WCAG 2 failure. Low contrast text showed up on 83.9%, images with missing alternative text on 53.1%, and form inputs with no label on 51%. Across all pages, 96% of detected errors fell into six categories.

The same six have led the list in every WebAIM report since 2019. Each one maps to a specific criterion, and each leaves something a scanner cannot judge.

WebAIM counted only automatically detectable errors with its WAVE engine. It states plainly that a clean result does not make a page accessible or conformant.

So start the checklist with these six, then add the criteria that need a human.

Perceivable checks for images, media, contrast and reflow

Perceivable checks cover content users receive through sight or hearing. Each one needs a second route for people who cannot use the default.

Measure color contrast from the foreground and background values in the stylesheet, not from a screenshot. W3C warns that anti-aliasing can make thin fonts look fainter than their specified color.

The ratios are thresholds with no rounding. A computed 4.499:1 fails.

A few things are exempt. Logos and logotypes, for one, though brand guidelines do not exempt ordinary text. Inactive controls like a disabled submit button are exempt as well, along with pure decoration.

Large text means 18 point, or 14 point bold, roughly 24 and 18.5 CSS pixels (W3C, Understanding SC 1.4.3).

Fixed-height boxes and pixel line heights are what usually break the text spacing override, so accessible typography starts with flexible containers. WebAIM also found placeholder alt values like “image”, “graphic” and bare file names on popular home pages. Those pass a scan and fail a human.

Operable checks for keyboard use, focus and target size

Every action available to a mouse user must work from a keyboard, and the item holding focus must stay visible.

Three of the four criteria WCAG 2.2 adds at Level AA belong to this group.

Sticky bars are a classic cause of 2.4.11 failures. W3C’s own example is a fixed banner across the bottom of the page that covers whatever receives focus, and a sticky navigation header does the same when focus scrolls beneath it.

AA asks only that the item is not entirely hidden. The AAA version, 2.4.12, requires that no part of it is hidden.

Skip links fail in quiet ways. WebAIM found some hidden so they never receive focus, and others pointing at targets missing from the page.

The 24 by 24 rule has exceptions (W3C, Understanding SC 2.5.8).

• An undersized target passes on spacing if a 24 CSS pixel diameter circle centered on it intersects no other target and no circle belonging to another undersized target.
• If another control on the page does the same job at full size, the small one is excused.
• Links inside sentences, or constrained by line height, are exempt.
• So are unmodified browser defaults.
• A particular presentation can also be essential or legally required, as with dense map pins.

In W3C’s worked example, six 20 by 20 pixel icon buttons pass with a 4 pixel gap and fail with none.

A 16 pixel hamburger menu toggle needs the same 4 pixel clearance. Browser zoom does not rescue a small target, because the requirement is measured in CSS pixels regardless of zoom.

Understandable checks for forms, error messages and sign-in

Label every input, describe every error in text, declare the page language, and keep sign-in free of memory tests.

A sign-in passes 3.3.8 when paste works in the password field, a password manager can fill it, or an emailed sign-in link offers another route. It fails when paste is blocked, or when a one-time code must be retyped with no alternative.

Accessible Authentication (Minimum) is new at AA in 2.2. W3C names password manager support and copy and paste as qualifying mechanisms.

Redundant Entry (3.3.7) and Consistent Help (3.2.6) join it as new Level A criteria in this group.

Labels come first when building accessible forms. Each input needs a visible label tied to it, and fields that collect personal data need the right autocomplete value.

Repeated menus keep one relative order across pages (3.2.3), and the same function keeps the same label (3.2.4). That keeps website navigation predictable for keyboard and screen reader users.

Missing page language remains the smallest of WebAIM’s six failure types, and its share of home pages has fallen over the years. It is still the cheapest fix on the list.

Robust checks for semantic HTML, accessible names and ARIA

Use native elements first, give every control a name, and add ARIA only where HTML has no equivalent.

Label in Name fails when the spoken label and the programmatic name diverge. W3C’s Understanding document says that leaves speech-input users unable to activate the control. A button labeled “Send” on screen but named “submit” in code ignores the voice command “Send”.

Heading structure shows the same gap between presence and meaning. WebAIM found skipped heading levels on a large share of home pages, and nearly all pages that used an h6 also skipped levels, which suggests those headings were styling choices, not structure.

ARIA attributes change only what assistive technology is told, never how the control behaves. A div given a button role still needs its own keyboard handling.

Home pages with ARIA averaged 59.1 errors, against 42 for pages without it (WebAIM, February 2026).

WebAIM notes this does not prove ARIA caused the errors, since those pages were also more complex. The pattern still holds, though. More ARIA attributes, more detected errors.

Icon-only buttons built from inline SVG have no name until someone supplies one, whether as visible text, an aria-label or a title inside the graphic. The naming options for graphics are covered separately in a guide on accessible SVG files.

How to test each check: automated scans, keyboard passes and screen readers

Start with an automated scan, move to a keyboard-only pass, and finish with a screen reader pass. Each one catches faults the previous one cannot see.

How much a scan covers on its own is disputed, and the dispute comes down to what gets counted.

The older rule of thumb puts automated tools at 20-30% of criteria, because many WCAG criteria cannot be machine-checked at all. Deque’s 2021 study of more than 2,000 audits (all first-time assessments) landed higher. Once it counted issues instead of criteria, automated testing fully covered 57% of them.

Deque measured that on its own engine, so read 57% as a vendor-measured ceiling, not a neutral average. The axe-core README repeats the figure and adds that anything the engine cannot decide comes back as “incomplete” and needs manual review.

Subtract it from 100 and the remaining 43% of issues by volume still need a person or a guided test (simple arithmetic on Deque’s number).

Automated scans

Scans reliably catch the following.

• Images without an alt attribute
• Buttons and links with no name
• Form fields with no label
• A missing page language
• Invalid ARIA roles and attributes

Tab order and focus handling are left to a person. So is checking that captions match the audio, and whether an error message actually tells the user how to fix the problem.

Lighthouse itself files logical tab order, trapped focus and managed focus under manual checks, per its Chrome for Developers documentation.

Keyboard-only pass

Put the mouse aside and work through each page template.

1. Load the page and press Tab once. A skip link should appear and take focus.
2. Keep pressing Tab. Focus should follow reading order, and every control should show a visible indicator.
3. Activate links with Enter, and buttons and checkboxes with Space.
4. Open each menu, modal and widget, then leave it using the keyboard alone. Any spot where focus cannot escape is a keyboard trap.
5. Press Shift+Tab along the same path and confirm the order reverses cleanly.
6. Repeat with sticky bars, cookie banners and chat widgets on screen.

Any control that works with a mouse and does nothing from the keyboard is a 2.1.1 failure.

Screen reader pass

A screen reader pass tests what gets announced, not what looks right.

Listen for each control’s name, role and state, the heading list, and any form errors or confirmations that arrive without focus moving. Run it on sign-in, search, a form submitted with a deliberate error, and the main purchase or contact flow.

WebAIM’s 2024 survey found that most screen reader users move through a long page by headings first, so check the heading list before anything else.

Which accessibility testing tools cover which checks?

No single tool covers a whole web accessibility checklist. Pair a scanner with a contrast tool and two screen readers, then add guided testing where the scanner stops.

Lighthouse deserves a warning. Its accessibility score is a weighted average of axe audits, each scored pass or fail.

A page with one unnamed button among many named ones scores zero on that audit, so the score swings on single defects. A 100 only means every scored audit passed. Use Lighthouse as a baseline, not the acceptance gate.

Accessibility Insights is the better fit for guided work. Its FastPass runs about 50 automated checks plus a tab stops helper, and its Assessment adds about 20 manual tests.

The overview page describes the Assessment as verifying WCAG 2.1 Level AA. Cover the four criteria WCAG 2.2 adds at AA by hand, using the Operable and Understandable tables above.

Pa11y suits build gates. It runs from the command line or Node, uses HTML_CodeSniffer by default with axe as an option, tests against WCAG2AA unless told otherwise, and exits with code 2 when it finds errors.

Warnings and notices are left out of its report by default.

For contrast, the Colour Contrast Analyser is one of the tools the W3C’s Understanding document for 1.4.3 lists for calculating ratios.

The screen readers worth testing with are in the table below.

WebAIM’s Screen Reader User Survey #10 (December 2023 to January 2024) found 65.6% of respondents commonly used NVDA and 60.5% commonly used JAWS. WebAIM notes the sample was not controlled, so read the figures as indicative.

Region changes the answer. JAWS led NVDA as a primary screen reader in North America, while NVDA led in Europe, Asia and Africa/Middle East.

JAWS with Chrome was the most common pairing, followed by NVDA with Chrome, and VoiceOver with Safari was the usual Apple pair.

NVDA with Chrome or Firefox plus VoiceOver with Safari is the minimum. Add JAWS when your audience is North American or a contract names it.

Respondents mostly see free screen readers as viable alternatives to commercial ones, though JAWS users agreed less often than NVDA and VoiceOver users.

Where each check belongs in the design-to-release workflow

Split the checklist by stage instead of running everything before launch. Deque makes the same argument in the axe-core documentation, saying testing built into early development saves time and rework.

Design

Settle contrast, target size, focus styles and heading levels before any code exists.

• Contrast pairs for text and UI components in the palette
• 24 by 24 CSS pixels, or enough spacing, for every control in the component specs
• A drawn focus style for each interactive state

Review heading levels and landmark regions on the wireframe, while moving a section costs nothing.

Check contrast and focus styles again on the finished mockup, where real brand colors and photography replace placeholders.

Development and content

Markup should use native elements with the right roles, one h1, no skipped heading levels and labels bound to their inputs. Components get their keyboard behavior and focus handling tested once, before they spread across pages.

In the pipeline, axe-core runs inside unit or integration tests and Pa11y fails pull requests on errors. Content authors set alt text, captions, link text and page language at publishing time, not as a retrofit.

Deque designs axe-core to run inside existing functional tests and states a goal of zero false positives, bugs aside. That makes failing a build on a violation a reasonable policy.

Pre-launch

Run the full keyboard and screen reader passes on the flows that carry the site’s purpose.

When time is short, DOJ’s planning guidance for public entities suggests ranking content by these factors.

• Key tasks such as registering, searching, submitting forms and paying
• Frequently accessed content
• Content flagged by people with disabilities
• Anything newly in development
• Elements repeated across pages, such as menus, search and footers
• Templates

The same guidance warns that testing takes planning and should not be left to the last minute (ADA.gov).

Regression

Passing once proves little. Every release can undo it.

Keep the scanner in CI so a new violation fails the build. Pa11y’s threshold option permits a fixed number of known errors while a legacy backlog shrinks.

Re-run the keyboard pass whenever a component library, cookie banner or chat widget changes, since those layers sit on top of every page.

DOJ says the same about public entities. Compliance has to continue after the deadline passes.

Which laws point to which WCAG version?

As of October 2026, the US rules still name WCAG 2.0 or 2.1, and the EU standard has only just moved to 2.2.

The Title II rule covers mobile apps too, so mobile app accessibility work follows the same WCAG 2.1 AA standard.

DOJ’s interim final rule, published in the Federal Register on 20 April 2026, pushed the compliance dates back one year and left the rest of the rule as it was. Guides written before April 2026 still list the original deadlines.

Section 508 applies WCAG 2.0 Level AA, and a page that fails even one of the 38 applicable criteria does not conform (Section508.gov). For non-web documents and software, four criteria are excluded: 2.4.1, 2.4.5, 3.2.3 and 3.2.4 (W3C WAI policy summary).

Directive (EU) 2019/882 covers products and services including e-commerce, banking services, e-books and passenger transport, and member states had to transpose it by June 2022 (European Commission). EN 301 549 is the standard most guidance names for it. V3.2.1 incorporates WCAG 2.1 for web content, as ITI’s VPAT notes show, while V4.1.1 aligns the web requirements with WCAG 2.2 Level A and AA.

ETSI published V4.1.1 on 2 September 2026. It does not carry a legal presumption of conformity until it is cited in the Official Journal, which Deque expected around 30 November 2026. Check ETSI and EUR-Lex for the current reference.

Businesses open to the public fall under ADA Title III instead. DOJ’s 2022 guidance says no regulation sets detailed web standards there, and it points to WCAG and the Section 508 Standards as helpful references.

Build to WCAG 2.2 AA and report against whichever version the contract names. W3C describes the 2.0 and 2.1 criteria as essentially unchanged in 2.2, so for web content one test pass serves all four rules (4.1.1 Parsing aside).

This section reports what the rules say and is not legal advice.

When passing the checklist still does not mean conformance

A passed web accessibility checklist is evidence of effort, not a conformance claim.

A claim covers every page and app in scope, so the audit starts with an inventory of content, not a handful of templates.

Custom widgets are another weak spot. WebAIM’s 2024 survey ranked menus, tabs and dialogs that do not behave as expected as the second most problematic item for screen reader users, behind CAPTCHA.

Third-party content stays your problem. DOJ’s guidance says a public entity remains responsible when a vendor provides or posts content for it, and its suggested contract practices include requiring accessibility information before signing and asking for warranties.

Reports need care as well. ITI says there is no VPAT certification and no pass/fail scale.

DOJ’s 2022 guidance warns that a clean automated report does not guarantee accessibility, and that a few reported errors do not always mean real barriers. Pair the scan with a manual check, as the testing section above describes.

Testing with disabled users covers what no checklist can. DOJ’s planning guide advises hearing from people with disabilities who have WCAG experience, work that belongs to inclusive design.

Documentation is what backs a claim. The VPAT is a free ITI template, and a completed one is an Accessibility Conformance Report (ACR) that records each criterion as supports, partially supports, does not support or not applicable.

ITI does not review or approve VPATs. Pick the edition that matches the buyer’s contract.

Web Accessibility Checklist FAQ

Is a checklist the same as an accessibility audit?

No. The checklist only lists the tests. An accessibility audit applies them across the whole site through an expert evaluation, brings in assistive technology and often user testing, and ends in a written report with remediation priorities.

Do I need to meet WCAG Level AAA?

No. The laws covered above target Level AA, and WCAG itself advises against requiring AAA as a general policy because some content cannot satisfy every AAA criterion.

Adopt individual AAA criteria where they fit, such as the 7:1 enhanced contrast ratio.

Does a mobile site need separate accessibility checks?

Mobile web is tested against the same success criteria, repeated on a phone-sized viewport with VoiceOver or TalkBack. Native apps need their own pass, and the ADA Title II rule names WCAG 2.1 AA for mobile apps as well as websites.

Is an accessibility statement required?

It depends on the law. The European Accessibility Act expects service providers to publish information on how their service meets the accessibility requirements.

The ADA Title II rule sets a technical standard instead. DOJ still advises giving the public a way to report accessibility problems.

Does meeting WCAG 2.2 AA also satisfy 2.1 AA?

In practice, yes. WCAG 2.2 keeps every 2.1 criterion except 4.1.1 Parsing, which W3C removed as obsolete.

A site that passes 2.2 AA therefore passes the 2.1 AA criteria that contracts and regulations name.

Who Owns Each Check After Launch?

A web accessibility checklist holds up after launch only when each check has one named owner and a re-test trigger. DOJ’s planning guidance for public entities makes the same point, saying to clearly identify who is responsible for what.

Assign in this order, because unattended checks hold without people and manual checks do not.

• Developers own the scanner gates in CI.
• Content authors own alt text, captions and link text at publishing.
• A named tester runs the keyboard and screen reader passes each release.

A manual pass on every release adds its runtime to the ship date.

As of 11 October 2026, 197 days remain before the 26 April 2027 ADA Title II deadline for entities of 50,000 or more people.

Revisit this ownership plan if DOJ amends the rule after its interim final rule, or when EN 301 549 V4.1.1, which names WCAG 2.2, is cited in the Official Journal.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web and graphic design, focusing on creating user-friendly websites, innovative UI kits, and unique fonts.

Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• What is Backend in Web Development? - September 13, 2026
• What is Frontend Development? - September 11, 2026
• How to Make a Button in Figma: Design Best Practices - September 10, 2026