ADA Compliance Tools Your Digital Agency Needs in 2026

When this guide first ran in 2020, "ADA compliance" for a digital agency mostly meant watching US lawsuits and hoping your client was not next. That is no longer the whole picture. Since then the Web Content Accessibility Guidelines 2.2 became a W3C Recommendation, the US Department of Justice published a binding web rule for state and local government, and the European Accessibility Act started to apply across the EU.

If you build WordPress sites for clients, accessibility has moved from a differentiator to a procurement question you will be asked to answer in writing. This guide has been rewritten to reflect that: what the standards actually say now, what genuinely helps a WordPress site, how to test it, and which "one-click compliance" products deserve scepticism.

What changed since 2020

Four things matter, and they interact.

WCAG 2.2 is the current guideline

WCAG 2.2 was published as a W3C Recommendation on 5 October 2023, with an updated edition published on 12 December 2024. It is backwards compatible with WCAG 2.1: a page that conforms to 2.2 is at least as accessible as one that conforms to 2.1.

It adds nine success criteria:

• 2.4.11 Focus Not Obscured (Minimum) — Level AA
• 2.4.12 Focus Not Obscured (Enhanced) — Level AAA
• 2.4.13 Focus Appearance — Level AAA
• 2.5.7 Dragging Movements — Level AA
• 2.5.8 Target Size (Minimum) — Level AA
• 3.2.6 Consistent Help — Level A
• 3.3.7 Redundant Entry — Level A
• 3.3.8 Accessible Authentication (Minimum) — Level AA
• 3.3.9 Accessible Authentication (Enhanced) — Level AAA

It also removes one: 4.1.1 Parsing is obsolete and gone, because assistive technology no longer parses HTML directly. Markup problems that genuinely break accessibility now fail other criteria instead, usually 1.3.1 Info and Relationships or 4.1.2 Name, Role, Value. Removing it did not lower the bar; it removed a duplicate check.

Three of the new AA criteria bite hardest on typical WordPress builds. Target Size (Minimum) asks for pointer targets of at least 24×24 CSS pixels, with spacing and inline-text exceptions — that catches cramped icon rows, tight pagination and social-share strips. Focus Not Obscured catches sticky headers and cookie bars that hide the element you just tabbed to. Accessible Authentication catches login flows that demand a cognitive test, such as retyping a code from memory or solving a puzzle, with no alternative.

The ADA Title II web rule now has dates

The DOJ's final rule under Title II of the ADA was published on 24 April 2024 and took effect on 24 June 2024. It adopts WCAG 2.1 Level AA as the technical standard for the web content and mobile apps of state and local government entities.

The compliance dates were then extended by an interim final rule published on 20 April 2026. As it stands:

• Public entities with a total population of 50,000 or more: compliance begins 26 April 2027 (extended from 24 April 2026).
• Public entities with a total population under 50,000, and all special district governments: compliance begins 26 April 2028 (extended from 26 April 2027).

Two practical notes. First, the extension moved the deadline; it did not remove the underlying obligation, and existing ADA duties still apply in the meantime. Second, the standard named in the rule is WCAG 2.1 AA, not 2.2 — so if you are contracting against Title II, write 2.1 AA into the deliverable and treat 2.2 as good practice on top.

If your agency works with school districts, city governments, transit authorities, libraries or public universities, this is the clearest accessibility deadline you will ever be handed. Use it.

The European Accessibility Act applies from 28 June 2025

Directive (EU) 2019/882, the European Accessibility Act, applies to covered products placed on the market and covered services provided to consumers after 28 June 2025. It reaches private businesses, not just the public sector, and it applies to companies selling into EU markets whether or not they are based in the EU.

It is not a blanket rule for every website. It covers specific consumer services — including e-commerce, consumer banking, electronic communications, transport ticketing and information, e-books and audiovisual media access. For a WordPress agency, the e-commerce hook is the one that matters: a WooCommerce store selling to EU consumers is in a different position than a local brochure site.

The harmonised technical route is EN 301 549, which incorporates WCAG 2.1 Level A and AA for web content and adds requirements WCAG does not cover, such as documents, software and hardware. Conforming to the harmonised standard gives a presumption of conformity with the Directive. Note that WCAG 2.2, though published in 2023, is not yet the referenced version in a harmonised EN 301 549.

Enforcement is national: each Member State applies its own procedures and penalties, so "EAA compliance" is really compliance with the transposed law in each country you sell into. There are carve-outs for content published before 28 June 2025, such as archived pages no longer updated, older office documents and pre-recorded media.

Private-sector US litigation is still the driver

For private businesses under Title III of the ADA, there is still no federal regulation naming a technical standard for websites. That gap is why the area remains litigation-driven rather than rule-driven: plaintiffs sue, courts reason by analogy to physical "places of public accommodation," and WCAG AA gets used as the practical yardstick in settlements and consent decrees.

We are deliberately not quoting a filing-count statistic here. The widely circulated annual numbers come from private law-firm and vendor trackers with differing methodologies, and we have not verified them against a primary source. What is safe to say, and what matters commercially, is that the exposure is real, it is concentrated in retail and e-commerce, and a demand letter costs a client far more than the remediation would have.

Be sceptical of overlay widgets

This section is a correction. The 2020 version of this article recommended an AI accessibility overlay, with a price and a claim about compliance "within 48 hours." We no longer stand behind that recommendation, and the reason is a matter of public record.

In January 2025 the US Federal Trade Commission announced a complaint and proposed order against accessiBe, alleging that the company misrepresented the ability of its accessWidget product to make any website WCAG-compliant, and that it presented paid third-party articles and reviews as independent opinion without disclosing its material connections to the reviewers. The FTC approved the final consent order in April 2025. It requires a $1,000,000 payment and bars the company from representing that its automated products can make any website WCAG-compliant, or can ensure continued automatic compliance over time as content changes, without evidence to support the claim.

Read that order carefully, because it generalises. It is written around any "Covered Product or Service" that claims to correct accessibility barriers through automated tools. The regulator's position is not that overlays are illegal — it is that the claim of automated compliance was not substantiated.

The practical implications for an agency:

• An overlay does not make a site conformant. It runs client-side over markup it did not author. It cannot know that a chart needs a text alternative, that your heading order is wrong for a reason, or that a form label is misleading rather than missing.
• Buying one does not transfer your risk. If you promise a client compliance on the strength of a widget, that promise is yours.
• Some disabled users actively dislike them. Overlays can conflict with the assistive technology a person already has configured — which is a genuine, reported complaint, not a theoretical one.
• Visible accessibility toolbars are not the same thing as conformance. A font-size and contrast switcher is a UI feature. It has almost nothing to do with whether your markup exposes the right names, roles and values.

None of this means "never use a plugin." It means the work is in the theme, the templates, the content and the editorial process — and no script bolted onto the front end substitutes for it. If a vendor tells you otherwise, ask them to put the compliance claim in the contract.

The POUR principles, and what they mean in practice

WCAG is organised under four principles. The acronym is still the clearest way to brief a team:

• Perceivable. Users must be able to perceive the content through some sense. Text alternatives, captions, sufficient contrast, and content that survives being resized or restyled.
• Operable. Users must be able to operate the interface. Everything reachable and usable by keyboard, adequate target sizes, no dependence on a dragging gesture, no keyboard traps.
• Understandable. Content and behaviour must be predictable. Consistent navigation, clear labels, helpful error messages, no surprise context changes.
• Robust. Content must work with current and future user agents and assistive technology. Valid, semantic markup and correct accessible names, roles and values.

What to actually fix on a WordPress site

These are the defects we see most often on real client sites, in rough order of how much they hurt relative to how cheap they are to fix.

1. Heading structure

Headings are the primary way screen reader users navigate a page. One h1, then a logical nesting of h2 and h3 with no skipped levels.

Use the block editor's Heading block rather than bolding and enlarging a paragraph. Visual weight is not structure — a larger, bolder paragraph is still a paragraph to assistive technology.

The block editor has a built-in check for this. Open the Document Overview panel (the list icon at the top left) and switch to the Outline view: it lists the heading structure and warns about incorrect levels. The Details panel also flags an empty or missing h1.

2. Colour contrast

WCAG 2.x Level AA requires a contrast ratio of at least 4.5:1 for normal-size text and 3:1 for large-scale text, with exceptions for incidental and decorative text and for logotypes. Non-text UI components and meaningful graphics need 3:1.

Check the values rather than trusting your eye: the WebAIM Contrast Checker is the quickest tool for a single pair. On a block theme, the colour palette in theme.json is where this is won or lost — if the palette itself contains a failing text-on-background pair, every editor on the team will eventually ship it. Fix the palette, not the page.

Watch placeholder text, disabled-looking-but-enabled buttons, light grey meta text under post titles, and text over hero images.

3. Alternative text

Every image that carries meaning needs a text alternative that conveys the same information. Images that are purely decorative should have an empty alt attribute so screen readers skip them — an empty alt is a deliberate, correct choice, not an omission.

In WordPress you can set alt text in the Media Library or in the block sidebar when the image is selected. Two things to train clients on: alt text set in the Media Library is a default, not a global truth — the useful description depends on context; and the caption, title and description fields are not substitutes for it.

4. Captions, transcripts and audio description

Captions for pre-recorded video are required at Level A. Audio description for pre-recorded video is required at Level AA. Live captioning is a Level AA requirement for live audio content.

Audio description is the requirement most often missed, because it needs a narration track describing what is shown but not spoken. Scope and price it separately; do not let it be discovered after launch.

5. Keyboard operation and visible focus

Tab through the whole page. Every interactive element should be reachable, in a sensible order, with a clearly visible focus indicator, and you should never get stuck.

This is where custom WordPress work most often fails: mega menus that only open on hover, sliders whose controls are div elements, modals that do not trap and return focus correctly, and "skip to content" links that were styled out of existence. Also check that a sticky header or cookie banner does not cover the focused element, which is exactly what WCAG 2.2's Focus Not Obscured criterion is about.

6. Forms

Every input needs a programmatically associated label. Placeholder text is not a label — it disappears on input and often fails contrast. Errors must be identified in text, not by colour alone, and the message should say how to fix the problem.

Most WordPress form plugins can produce accessible output and can also be configured into an inaccessible mess, so test the rendered form rather than trusting the plugin's marketing.

7. Link text

Links should make sense out of context, because screen reader users often pull up a list of all links on a page. "Read more" repeated fourteen times tells them nothing. This is also a small SEO win, which makes it an easy sell.

WordPress-specific: themes, plugins and process

Start from an accessibility-ready theme

The WordPress.org theme directory has an accessibility-ready tag. It is not a certificate of WCAG conformance for your finished site, but it is meaningful: themes carrying it have passed a specific review against the Theme Review Team's accessibility requirements, covering keyboard navigation, skip links, focus indication, form labelling, contrast and headings.

Starting there saves real money, because retrofitting focus states and landmark structure into a theme that never had them is slow work. It also gives you a defensible answer when a client asks why you chose a particular starting point.

Whatever theme you pick, the site is still yours to verify — page builders, custom blocks and third-party embeds can undo a good theme quickly.

Plugins that genuinely help

These are on WordPress.org and actively maintained. Figures below are from the plugin directory at the time of writing.

• WP Accessibility — by Joe Dolson, a long-standing contributor to the WordPress accessibility team. Around 60,000 active installs, version 2.3.5, last updated 11 August 2026 and tested to WordPress 7.1.1. It is a toolbox of targeted fixes rather than an overlay: adding skip links, enforcing alt text prompts, adding language attributes, flagging missing labels, and removing the title-attribute and tabindex patterns that older themes add.
• Equalize Digital Accessibility Checker — around 10,000 active installs, version 1.49.0, updated 1 September 2026, tested to WordPress 7.1.1. This is the one that changes behaviour, because it scans content inside the editor and reports problems to the person creating the page, while they are still creating it. Moving accessibility feedback into the authoring loop does more for a client site over a year than any front-end script.
• WP Accessibility Helper — around 10,000 active installs, version 0.6.7, updated 2 September 2026. Worth knowing about, but note that its main surface is a front-end user-preference toolbar. Treat it as a usability nicety, not as conformance work.

A note on the widely installed "Web Accessibility" plugin (formerly Ally, slug pojo-accessibility): it reports around 500,000 active installs, which makes it hard to ignore, but its directory rating is currently 58% across 162 reviews — markedly lower than the others listed here. Its current positioning centres on a widget and automated scanning. Given the FTC order discussed above, we would not build a client compliance commitment on it, and we are flagging the rating rather than recommending it.

The core project also has a dedicated accessibility team, whose handbook is a better reference for content authors than most paid training.

Fix the editorial process, not just the build

Almost every site we audit was more accessible on launch day than it is now, because accessibility decays with publishing. Alt text stops being written, a marketer drops in a low-contrast promo banner, someone pastes a heading as bold body text.

The durable fixes are process ones: an in-editor checker so authors get feedback immediately, a short house style rule for alt text and link text, a locked-down colour palette in theme.json, and a quarterly re-test. If you sell accessibility as a retainer rather than a project, this is what you are actually selling — and it is a far easier renewal conversation than a one-off audit. It belongs in the same operational toolkit as the rest of your agency project management.

How to actually test a WordPress site

Automated tools catch only a minority of real accessibility issues — they are good at machine-checkable failures such as a missing alt attribute or a failing contrast ratio, and blind to whether the alt text is correct or the focus order makes sense. They are necessary and nowhere near sufficient. Use them to clear the mechanical failures fast, then test manually.

Automated passes

• WAVE (WebAIM) — browser extension, annotates the page in place. Good for a first look and for showing a non-technical client what is wrong.
• axe DevTools — the engine most other tools embed; low false-positive rate and clear remediation guidance.
• Lighthouse — built into Chrome DevTools. Its accessibility score is a smoke test, not a grade; do not let anyone treat 100 as conformance.
• Pa11y — command-line and CI friendly, so you can fail a build when a regression lands.
• In-editor scanning — Accessibility Checker, per the previous section, so authors see problems before publishing.

Manual checks that find what scanners cannot

1. Keyboard only. Put the mouse away. Tab through the page: navigation, search, menus, sliders, modals, forms, footer. Watch for invisible focus, illogical order, traps, and content hidden behind a sticky element.
2. Screen reader. Test with a real one — NVDA or JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android. You do not need expertise to catch the big failures: unlabelled buttons, images announced as filenames, forms that read as "edit text" with no name.
3. Zoom and reflow. Zoom the browser to 400% and check that content reflows into a single column without horizontal scrolling or clipped text. Then test 200% text-only resizing.
4. Contrast in context. Sample actual rendered pixels, including text over images, hover and focus states, and disabled controls.
5. Content review. Read the alt text, link text, headings and error messages as prose. This is a human judgement call and always will be.
6. Forms end to end. Submit a form wrongly on purpose and make sure the error is announced, described in text, and focusable.

Record the results. A dated report listing what was tested, what failed, what was fixed and what remains — essentially an accessibility statement with a remediation plan — is the single most useful artefact you can hand a client. It demonstrates good faith, which matters both commercially and if anything is ever disputed.

What this means for your agency's offer

The opportunity has changed shape since 2020. Then, accessibility was a nice line item. Now there are dated obligations you can point at, which makes it a budgeted one.

Three things sell well and are honest:

• An audit with a remediation plan, priced separately from the fixes. Include the manual testing; that is the part clients cannot get from a free scanner.
• Accessibility built into new builds — starting from an accessibility-ready theme, a checked colour palette, and component-level keyboard and focus testing before handover. Far cheaper than retrofitting, and worth saying so in the proposal.
• A maintenance retainer covering in-editor checking, author training and periodic re-tests, because published content is where conformance erodes.

What does not sell well for long: promising compliance you cannot evidence. The FTC order is a useful reminder that "we installed a widget" is not a defence. Be precise in your contracts — commit to a named standard and level, such as WCAG 2.1 AA, describe your testing method, and be explicit about what is out of scope, such as third-party embeds and user-generated content.

This also pairs naturally with work you are probably already selling. Accessible markup, sane heading structure and descriptive link text overlap heavily with the fundamentals in our WordPress web design guide, and the skill set sits alongside the rest of a modern WordPress developer's toolkit.

Conclusion

Accessibility in 2026 is less mysterious than it was in 2020, and the guesswork has mostly been replaced by dates and named standards. WCAG 2.2 is the current guideline. WCAG 2.1 AA is the standard written into the ADA Title II rule, with compliance now beginning 26 April 2027 or 26 April 2028 depending on population. The European Accessibility Act has applied since 28 June 2025 to covered consumer services, e-commerce included, with EN 301 549 as the harmonised route.

The work itself has not changed much: correct headings, sufficient contrast, meaningful alt text, captions and audio description, full keyboard operation with visible focus, properly labelled forms, and link text that stands alone. Do those well, start from an accessibility-ready theme, put a checker in front of your authors, and test manually as well as automatically.

And be honest about the tooling. There is no script you can paste into a footer that makes a website accessible. The regulator has now said so with a $1,000,000 order attached. Agencies that internalise that early will be the ones still winning public-sector and EU e-commerce work in two years.

Frequently asked questions