Accessibility After the Deadline: Building Digital Products for WCAG 2.2 and the EAA

Start with the end-to-end service, not the website navigation. A retail journey may include discovery, account creation, authentication, product configuration, checkout, payment, confirmation, delivery tracking, returns, customer support, and electronic documents. A ticketing service may span schedules, seat selection, identity checks, a third-party payment page, a QR ticket, and disruption alerts. If one mandatory step is inaccessible, the service is inaccessible in practice.

Create a scope register that identifies the operating company, target markets, service category, customer channels, supporting products, third parties, document types, and named owner. Record the legal interpretation and the evidence behind it. The EU guidance describes a microenterprise exemption for service providers with fewer than 10 employees and annual turnover or balance-sheet total not exceeding €2 million; it is not a blanket exemption for every product, supplier, or contracting situation.[4]

Also document claimed disproportionate-burden or fundamental-alteration assessments. The EU business guidance expects evidence and periodic review rather than an unsupported conclusion. Procurement matters here: contracts should require suppliers to state accessibility support, disclose known limitations, provide conformance evidence, and cooperate on fixes. Outsourcing a widget does not outsource the customer experience.[4]

WCAG 2.2 is the current W3C Recommendation and W3C advises using it as the new conformance target. It retains the familiar foundations—perceivable, operable, understandable, and robust—and adds nine success criteria. Several additions directly affect everyday product patterns: keyboard focus must not be obscured, dragging needs a non-drag alternative, interactive targets need adequate size or spacing, help should stay in a consistent location, repeated information should not be requested unnecessarily, and authentication must not depend on a cognitive-function test without an accessible mechanism.[1][2]

Convert those outcomes into stories and component contracts. A sticky cookie banner must not cover the focused “Place order” control. A kanban card that can be dragged must also move through buttons or a menu. A compact icon action needs a sufficient target or adequate spacing. A multi-step application should carry forward information it already knows. Sign-in should support password managers and paste, and avoid puzzles based on memory, transcription, or object recognition when no alternative is available.

European standard EN 301 549 is the key technical reference used for ICT accessibility in European procurement and legislation. Its September 2026 edition is published, and the updated web, document, and software clauses align with WCAG 2.2. Teams should confirm which harmonized standard and presumption-of-conformity rules apply to their situation rather than assuming that a version number alone settles compliance.[6][7]

The most scalable accessibility work happens below the page level. Build accessible defaults for buttons, links, fields, errors, dialogs, menus, tabs, notifications, data tables, pagination, and media controls. Each component should publish its semantics, keyboard behavior, focus management, contrast expectations, responsive behavior, error states, and assistive-technology notes alongside the visual API.

Do not treat color tokens as decoration. Define text, border, icon, status, and focus combinations with verified contrast across light, dark, hover, disabled, selected, and error states. Preserve meaning without color alone. Motion tokens should respect reduced-motion preferences. Layout primitives should survive 400% zoom and narrow reflow without forcing two-dimensional scrolling for ordinary content.

Governance is as important as code. Require an accessibility review for new components, maintain a small set of tested reference patterns, and make deviations explicit. Deprecate inaccessible legacy components instead of documenting a better alternative that teams may ignore. A component library only reduces risk when product teams can adopt it more easily than building their own.

Automated scanners are useful for deterministic failures such as missing names, duplicate identifiers, invalid ARIA relationships, and some contrast problems. Run them in component tests, continuous integration, and representative production pages. They cannot judge whether alternative text is useful, focus order is logical, instructions make sense, a live update is announced at the right time, or a journey remains usable under stress.

Add structured manual testing. Complete the critical journey with keyboard alone and with visible focus. Test at 200% and 400% zoom, narrow viewport reflow, browser text overrides, high-contrast or forced-colors mode, reduced motion, and at least representative screen-reader/browser combinations for the audience. Validate errors by causing them deliberately: empty required fields, expired sessions, declined payments, invalid dates, and interrupted multi-step flows.

Research with disabled participants reveals product problems that a conformance review will miss: confusing recovery language, exhausting repetition, time limits, inconsistent controls, support dead ends, or a technically labelled field whose purpose is still unclear. Pay participants fairly, support their preferred setup, and track findings in the same product backlog as every other customer insight.

Clear content reduces cognitive load for everyone. Use descriptive headings, meaningful link text, direct instructions, and plain error messages that explain what happened and how to recover. Give images useful alternatives when they convey information and empty alternatives when they are decorative. Captions, transcripts, audio description where needed, and accessible documents are part of the service—not optional publishing extras.

Forms should expose persistent labels, programmatic instructions, input purpose, and errors connected to the relevant control. Preserve the user’s entries after validation. Do not use placeholder text as the only label. Time limits need warning and extension where required. Multi-step journeys should expose progress and avoid asking customers to re-enter information that the service already holds unless there is a valid security or privacy reason.

Authentication and payments deserve dedicated testing because they combine security pressure, third parties, timeouts, and irreversible consequences. Support password managers, passkeys, and copy/paste. Avoid inaccessible CAPTCHA traps. Announce cart and payment updates without stealing focus. Ensure the confirmation is perceivable and retrievable, and provide an accessible route to correct a mistake or reach support.

In days 1–30, confirm legal scope, inventory customer journeys and suppliers, establish WCAG 2.2 as the technical target, and baseline the top three journeys with automated and manual testing. Fix blockers immediately: inaccessible authentication, keyboard traps, missing labels, obstructed focus, unusable payment steps, and support channels that cannot be reached.

In days 31–60, repair the design-system primitives that caused repeated failures, add accessibility acceptance criteria to delivery templates, train designers, engineers, content authors, QA, procurement, and support for their specific responsibilities, and put contract requirements around critical vendors. Publish a clear accessibility statement and feedback route appropriate to the service and jurisdiction.

In days 61–90, test with disabled participants, commission an independent review of the highest-risk flows, document remaining issues and timelines, and add release and production controls. Report a small set of operational measures: critical blockers, time to remediation, coverage of key journeys, component adoption, repeat regressions, and user-reported issues. The goal is not a ceremonial score; it is fewer people blocked from completing important tasks.