ADA website compliance checklist for 2026 (WCAG 2.2 AA)

For most organizations, ADA website compliance means meeting WCAG 2.1 or 2.2 Level AA. State and local governments now have fixed DOJ deadlines: 26 April 2027 for larger entities and 26 April 2028 for smaller ones and special districts. Private businesses fall under Title III, where DOJ has no detailed web regulation but expects accessible sites.

This guide is general information, not legal advice. Laws and deadlines change, and how they apply depends on your organization. Talk to a qualified lawyer about your obligations. What follows is a practical checklist built on primary sources only: ada.gov, the W3C, WebAIM, the FTC, GOV.UK and the European Commission's AccessibleEU centre.

Some widely shared articles still give the old Title II date of April 2026. The dates below reflect the interim final rule published on 20 April 2026.

What does the law require in 2026 (US, UK, EU)?

Sources: ada.gov Title II web rule, ada.gov web guidance, GOV.UK, AccessibleEU. Read 22 October 2026.

ADA Title II: state and local governments

ada.gov says the Federal Register published DOJ's interim final rule on 20 April 2026. Public entities with a total population of 50,000 or more must comply by 26 April 2027. Those with a population under 50,000, and special district governments, must comply by 26 April 2028. The rule states that "Version 2.1, Level AA is the technical standard" for their web content and mobile apps.

ADA Title III: private businesses

For businesses, DOJ's 2022 guidance says: "The Department of Justice does not have a regulation setting out detailed standards." It adds that "Businesses and state and local governments have flexibility in how they comply." In practice, WCAG 2.1 or 2.2 AA is the standard accessibility auditors and developers work to. Meeting it is the most defensible way to show your site is accessible, though no checklist can guarantee a legal outcome.

UK and EU

GOV.UK says public sector bodies must "meet the Web Content Accessibility Guidelines (WCAG) 2.2 AA accessibility standard", and that "All UK service providers have a legal obligation to make reasonable adjustments under the Equality Act 2010." In the EU, the European Accessibility Act has applied since 28 June 2025 and covers products and services including "computers, smartphones, e-commerce platforms, televisions, digital books" and more.

Which WCAG version should you follow: 2.1 or 2.2?

Test to WCAG 2.2 AA. The W3C says "WCAG 2.2 was published as a 'W3C Recommendation' web standard on 5 October 2023" and "provides 9 additional success criteria since WCAG 2.1." The current edition is dated 12 December 2024. WCAG 2.2 also "has removed one success criterion, 4.1.1 Parsing".

Because 2.2 builds on 2.1, a site that meets 2.2 AA also meets every 2.1 AA criterion that is still in use. That covers the Title II standard (2.1 AA) and the UK public sector standard (2.2 AA) in one pass.

The ADA compliance checklist (WCAG 2.2 AA)

Each item lists the WCAG success criterion and a quick way to test it. Items marked new were added in WCAG 2.2.

Perceivable

• Images have text alternatives (1.1.1). Informative images have alt text that says what matters; decorative images have empty alt. Test: check each image's alt in your browser's inspector or with a screen reader.
• Videos have captions (1.2.2) and audio-only content has a transcript (1.2.1). Test: play each video with captions on and check they are accurate and in sync.
• Structure is in the code (1.3.1). Headings use heading tags in order, lists are real lists and data tables have header cells. Test: view the heading outline with a browser extension or screen reader.
• Text contrast is at least 4.5:1, or 3:1 for large text (1.4.3). Test: use a contrast checker on body text, buttons, placeholders and text over images.
• Text resizes to 200% without losing content (1.4.4). Test: zoom the browser to 200% and read every page.
• Content reflows at 320 CSS pixels wide without horizontal scrolling (1.4.10). Test: zoom to 400% on a 1280-pixel-wide window, or narrow the window to 320 pixels.
• Controls and icons have 3:1 contrast against adjacent colors (1.4.11). Test: check input borders, focus rings and icon buttons.

Operable

• Everything works with a keyboard (2.1.1), with no keyboard trap (2.1.2). Test: unplug the mouse and use Tab, Shift+Tab, Enter, Space and the arrow keys.
• A skip link or landmarks let users bypass repeated blocks (2.4.1). Test: press Tab once on page load.
• Focus order is logical (2.4.3) and focus is visible (2.4.7). Test: tab through each page and watch where the focus ring goes.
• Focus is not hidden behind sticky headers, cookie banners or chat widgets (2.4.11, new). Test: tab through with every sticky element showing.
• Link text makes sense in context (2.4.4). Test: list the links with a screen reader; "click here" fails.
• Dragging has a single-pointer alternative (2.5.7, new), such as buttons next to a slider or sortable list. Test: complete each drag action without dragging.
• Targets are at least 24 by 24 CSS pixels, or spaced so they don't overlap (2.5.8, new). Test: measure small icons, pagination and inline controls.

Understandable

• Page language is set (3.1.1). Test: check the lang attribute on the html element.
• Help is in a consistent place across pages (3.2.6, new), such as contact details or a chat link. Test: compare its position on several pages.
• Forms have labels and instructions (3.3.2) and errors are described in text (3.3.1). Test: submit each form empty and with bad data.
• Users aren't asked to re-enter information they already gave in the same process (3.3.7, new). Test: walk through checkout and multi-step forms.
• Log-in doesn't depend on a memory or puzzle test (3.3.8, new). Allow password managers and paste, or offer another method. Test: log in using a password manager and with paste.

Robust

• Custom controls expose name, role and value (4.1.2). Test: use a screen reader on menus, tabs, accordions, modals and custom selects.
• Status messages are announced without moving focus (4.1.3), such as "Added to cart" or search result counts. Test: trigger them with a screen reader running.

The remaining three new WCAG 2.2 criteria (2.4.12, 2.4.13 and 3.3.9) are Level AAA, so they aren't required for AA conformance, but they are good practice.

Thresholds from the W3C WCAG 2.2 quick reference and What's new in WCAG 2.2.

What are the most common accessibility failures?

WebAIM tests the home pages of the top one million websites every year. Its 2026 report, updated 30 March 2026, found that "95.9% of home pages had detected WCAG 2 failures", up from 94.8% in 2025, with "an average of 56.1 errors per page".

Source: WebAIM Million 2026.

These six failures are all detectable by automated tools and mostly cheap to fix. If you only have a day, start here: fix contrast in your design tokens, add alt text, label every form field, give icon links and buttons accessible names, and set the page language.

How can you test your site in an afternoon?

You don't need special training to find the most serious problems. Pick five representative pages: home, a content page, a listing page, a form and checkout or sign-up.

1. Run an automated scan with a free browser extension such as axe DevTools, WAVE or Lighthouse. Note the errors, but don't stop there. ada.gov warns: "A 'clean' report does not necessarily mean everything is accessible."
2. Use the keyboard only. Tab through each page. Can you reach and use every link, button, menu and form field? Can you always see where focus is? Can you close pop-ups with Escape?
3. Turn on a screen reader. Use VoiceOver on Mac or iPhone, NVDA on Windows or TalkBack on Android. Listen to headings, links, form labels and error messages. Do they make sense without seeing the screen?
4. Zoom to 200% and 400%. Text should grow, nothing should overlap, and you shouldn't need to scroll sideways.
5. Check contrast on text, buttons, placeholders and focus rings with a contrast checker.
6. Fill in every form with mistakes. Are errors explained in text, next to the field, and announced?

Log each issue with the page, the WCAG criterion, a screenshot and who will fix it. That list is the start of your remediation plan.

Do accessibility overlays make you compliant?

No. Overlays are scripts that add a toolbar or claim to fix a site automatically. They can't reliably fix missing labels, broken keyboard support, poor structure or inaccessible custom components, because those problems live in the code.

The US Federal Trade Commission has acted on these claims. In January 2025 it announced that accessiBe would pay $1 million over deceptive claims that its AI product could make websites compliant. The final order, approved on 22 April 2025, bars the company from "representing that its automated products can make any website WCAG-compliant".

The fix is less exciting but works: correct the code, the content and the design system, then test with real assistive technology.

What about PDFs, videos and mobile apps?

• PDFs and documents. If people need a document to use your service, it should be accessible too: tagged headings, reading order, alt text and form fields. Often the better fix is to publish the content as an HTML page.
• Video and audio. Add accurate captions, transcripts and, where visuals carry meaning that the audio doesn't, audio description. Make sure the player itself works with a keyboard.
• Mobile apps. The Title II rule covers state and local government mobile apps as well as websites. For any app, test with VoiceOver and TalkBack, support Dynamic Type and larger text, and check touch target sizes. Our mobile app maintenance and iOS app development teams build these checks into each release.

When should you bring in an accessibility audit?

A self-check finds the obvious problems. An expert audit is worth it when:

• you have a Title II deadline, a procurement requirement or a legal complaint
• your site has complex components: checkout, booking, dashboards, maps or custom widgets
• you are planning a redesign and want accessibility built into the design system
• you need a prioritized issue list your developers can act on, with WCAG references and fixes
• you need retesting after fixes and monitoring on each release

A good audit combines automated scans with manual keyboard and screen-reader testing, reports each issue against a WCAG criterion, and comes with remediation, not just a PDF. It should never promise that your site is "lawsuit-proof".

How can Elgrith help with website accessibility?

Elgrith has delivered 1,000+ projects for 250+ clients since 2015, from our New Delhi headquarters and client centers in New York, London and Shanghai. Our website accessibility team audits sites against WCAG 2.2 AA with manual and automated testing, fixes issues in your code and content, and retests with screen readers and keyboards. We don't sell overlays, and an audit is remediation guidance, not legal advice or a compliance guarantee. We can also keep fixes in place through website maintenance or build accessibility into a website redesign. We give a fixed written quote after a free call. Book a call or start a project.