WCAG 2.2 AA at scale. a design-system playbook for sustainable accessibility in ecommerce, the public sector and nonprofits.

1. The rules that matter

This section summarizes public rules as of October 5, 2026. It is not legal advice. Check the current rules and your own situation before acting.

Title II details. Population comes from 2020 US Census data for the government entity, not from how many students, customers or visitors an organization serves. School districts and smaller divisions follow specific rules in the regulation. The DOJ moved both dates by one year in an interim final rule published April 20, 2026.

Archived content. Title II exempts archived web content only when all four conditions are met: it was created before the compliance date, it is kept only for reference, research or recordkeeping, it sits in a clearly marked archive area, and it has not changed since it was archived. Moving a document into an archive does not by itself exempt it. Documents people need to use a current service still have to be accessible.

HHS details. HHS moved both Section 504 dates by one year on May 7, 2026. The extension changes only the dates. Recipients’ existing duty not to discriminate on the basis of disability still applies.

Title III. The DOJ has not issued a detailed web technical rule for private businesses. It points to WCAG as helpful guidance, and courts and settlements often use WCAG 2.1 AA as a benchmark. In practice, a business is judged on whether people with disabilities can actually use its site.

Europe. The European Accessibility Act covers listed products and services, including ecommerce, banking, transport ticketing and e-books, not everything sold to EU consumers. ETSI published EN 301 549 v4.1.1, which includes WCAG 2.2 AA, in September 2026. A standard’s publication is separate from its citation in the EU Official Journal: as of October 2026, the cited version is still v3.2.1, so check the legal status before relying on v4.1.1.

Lawsuit trends. UsableNet’s 2026 midyear report, based on filings through mid-June, projects about 6,176 digital accessibility lawsuits for 2026, nearly 20% more than 2025. Ecommerce companies were the target in 79% of cases, and 36% of sued companies had revenue above $25 million. This is a projection, not a final count. For scale, Seyfarth counted 5,006 federal ADA Title III filings in the first half of 2026; that figure covers all Title III cases, not only websites.

2. What WCAG 2.2 adds

WCAG 2.2 keeps every WCAG 2.1 requirement except 4.1.1 Parsing, which it removes, and adds six criteria at levels A and AA.

Do not forget the baseline. Most failures we see are not new 2.2 criteria. A short baseline checklist for forms and checkouts:

• Everything works with a keyboard alone, with no keyboard traps (2.1.1, 2.1.2)
• Visible focus on every interactive element (2.4.7)
• Text contrast of at least 4.5:1 for normal text and 3:1 for large text; meaningful interface components and graphical objects generally need 3:1 against adjacent colors (1.4.3, 1.4.11)
• Content reflows at 320 CSS pixels wide with no sideways scrolling (1.4.10)
• Text spacing can be increased without losing content (1.4.12)
• Labels and instructions for every field (1.3.1, 3.3.2)
• Clear text error messages and suggestions (3.3.1, 3.3.3)
• Status messages, such as “item added to cart”, announced without moving focus (4.1.3)
• For purchases and legal or financial submissions, a way to review, confirm or reverse (3.3.4)

3. Component-first, not component-only

Page-by-page fixes fail because the same broken button, field or menu appears on hundreds of pages, and every new page copies the problem again. Fixing components addresses the source. But fixing components is a remediation strategy, not a conformance evaluation.

The method we recommend follows the W3C evaluation methodology (WCAG-EM):

1. Define scope. Which sites, templates, journeys and documents, and which standard (for example WCAG 2.2 AA).
2. Audit shared components first. Buttons, links, form fields, navigation, modals, carousels, cards, headers and footers.
3. Evaluate a representative sample. Each template, each unique page type and each complete journey (search, sign-up, checkout, donation, login, contact) as actually built, with real content and third-party tools.
4. Fix at the source. Change the component, the design token or the CMS rule, not the page.
5. Retest and report. Retest the sample, record evidence and assign remaining issues.

4. Eight design-system decisions that reduce recurring failures

These decisions, made once in the design system, help prevent whole classes of failure from coming back, although overrides, vendor code and drift can still cause regressions. They support conformance; they do not replace testing.

5. A worked example: the form field

Forms are where accessibility failures cost money: a buyer or donor who cannot finish leaves. Here is one component taken from failure to acceptance.

Original failure. A donation form uses placeholder text instead of labels. Errors appear only as a red border. On submit, nothing is announced and focus stays on the button.

Corrected implementation.

<label for="amount">Donation amount (USD)</label>
<p id="amount-hint">Minimum $5</p>
<input id="amount" name="amount" inputmode="decimal"
       aria-describedby="amount-hint amount-error"
       aria-invalid="true" autocomplete="transaction-amount">
<p id="amount-error">Enter an amount of $5 or more.</p>

Interaction states. Default, focused (visible outline at 3:1), filled, error (text message plus icon, not color alone), disabled (not used for required steps), and success.

On submit with errors. Show an error summary at the top listing each problem as a link to its field, and move focus to the summary.

On success. Show a confirmation page or message with a clear heading. Announce in-page updates through a status region.

Test procedure. Keyboard only: tab through, submit empty, fix errors, submit. Screen reader (NVDA with Firefox, VoiceOver with Safari): confirm each label, hint and error is read. Zoom to 400% and check reflow. Run automated checks.

Why this matters. Accessible labels and error handling help people finish the journeys that matter most: checkout, donations, admissions, applications, account registration and appointment booking.

Acceptance criteria. Every field has a programmatic label. Errors are described in text and linked to fields. Focus moves to the error summary on failed submit. The flow can be completed by keyboard and screen reader. No automated accessibility violations detected in the tested form states.

6. An illustrative 90-day priority plan

This is an example plan for priority remediation, not a promise that every site conforms in 90 days. It assumes one website on a shared design system, a small team (designer, two developers, a tester), vendors that respond within two weeks, a manageable document library, and approvals within a week. Larger estates take longer.

Inventory documents in the first phase, not the last. Large PDF libraries are often the biggest backlog.

7. Keeping it accessible at scale

What blocks a release: new critical or high-impact accessibility regressions on changed content, found by automated or manual testing, especially when they stop someone completing a priority journey by keyboard or assistive technology. Exceptions are recorded with an owner, a reason and a fix date.

8. Proving it

Automated tools catch only part of the problem. Proof needs manual testing with assistive technology and, where possible, testing with people with disabilities.

A sample test record

Two documents show the work:

1. Accessibility Conformance Report (ACR). A report of an evaluation, written using the VPAT template from the Information Technology Industry Council. It is not a certification. It states, criterion by criterion, whether a product supports, partially supports or does not support the standard.
2. Accessibility statement. Names the standard you target, the date of the last review, known limitations, your plan and a contact that responds.

Be honest in both. A report that claims full conformance and fails a spot check does more harm than one that lists known gaps.

Free screening. OST’s free WCAG checker is a first screening tool. Like every automated scanner, it cannot verify full conformance; a manual audit is still needed.

9. Real-world audit example: two design tokens, 25 failing elements

Example from a public website: a San Francisco public-policy nonprofit (anonymized). This is a findings example only; no changes were made to the site.

What was tested. On October 5, 2026, OST ran an automated WCAG 2.2 AA scan (axe-core 4.10) of the organization’s homepage. It found one type of failure, color contrast, on 25 elements. No overlay widget is used. An automated scan of one page is a starting point, not a full audit.

What caused it. All 25 failures came from two brand colors used across the site:

What the fix would be. A page-by-page approach would mean editing 25 elements on this page alone, and more on every other page. The design-system approach changes two color tokens once. For example, darkening the gray to #747678 (4.56:1) and the teal to #0b819f (4.51:1) keeps both colors close to the brand while passing for normal text everywhere they are used. Any real change would need the organization’s brand approval and a retest of its pages.

The lesson. On this page, two design tokens caused every automated failure. Fixing the problem at the token level can resolve it wherever that token is consistently used, and reduces the risk of the same failure appearing on new pages.

About the author

Manish Mittal is Technology and Digital Solutions Leader at OpenSource Technologies (OST). He has 23+ years in technology and has been with OST since 2012. OST is a women-led, WBENC-certified digital engineering firm with 14+ years and 500+ projects delivered for ecommerce, public sector and nonprofit clients.

Sources

All accessed October 5, 2026.

1. US Department of Justice, ADA.gov, “Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps,” with the April 2026 interim final rule. https://www.ada.gov/resources/2024-03-08-web-rule/
2. HHS, “HHS’ Office for Civil Rights Extends Web and Mobile Accessibility Compliance Deadline,” May 2026. https://www.hhs.gov/press-room/hhs-extends-mobile-and-web-accessibility-deadline.html
3. Federal Register, “Extension of Compliance Dates … Accessibility of Web Content and Mobile Applications of Recipients of Departmental Financial Assistance,” May 11, 2026. https://www.federalregister.gov/documents/2026/05/11/2026-09266/
4. W3C, “What’s New in WCAG 2.2.” https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
5. W3C, “Website Accessibility Conformance Evaluation Methodology (WCAG-EM).” https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/
6. European Commission, “European Accessibility Act.” https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/union-equality-strategy-rights-persons-disabilities-2021-2030/european-accessibility-act_en
7. ETSI, EN 301 549 V4.1.1, September 2, 2026. https://www.etsi.org/deliver/etsi_en/301500_301599/301549/04.01.01_60/en_301549v040101p.pdf
8. UsableNet, 2026 Midyear Report, July 2026. https://info.usablenet.com/2026-midyear-report
9. Seyfarth Shaw LLP, ADA Title III News and Insights, “2026 Mid-Year Report: ADA Title III Federal Lawsuit Numbers Are Climbing,” September 2026. https://www.adatitleiii.com/2026/09/2026-mid-year-report-ada-title-iii-federal-lawsuit-numbers-are-climbing/
10. Information Technology Industry Council, VPAT. https://www.itic.org/policy/accessibility/vpat