Accessibility in 2026: Legal Requirement and Competitive Advantage

Web accessibility has moved from "best practice" to legal requirement in most major markets. The Americans with Disabilities Act (ADA) has been interpreted by courts to apply to websites, with litigation increasing year-over-year. The EU's European Accessibility Act came into force in 2025. For any product targeting business customers, accessibility compliance is now a procurement requirement. Beyond legal compliance, accessible websites consistently score better on Core Web Vitals, rank better in search results, and convert better — the practices that make websites accessible also make them faster and clearer.

The WCAG 2.2 Four Principles

WCAG 2.2 organizes requirements around four principles: Perceivable (information must be presentable to users in ways they can perceive), Operable (UI components must be operable by all users), Understandable (information and operation must be understandable), and Robust (content must be robust enough to be interpreted by assistive technologies). Each principle contains guidelines, each guideline contains success criteria rated A (minimum), AA (standard), or AAA (enhanced). Legal compliance typically requires AA conformance.

The WCAG 2.2 Developer Checklist

Images: all meaningful images have descriptive alt text; decorative images use alt="" to be ignored by screen readers. Color: color is never the only means of conveying information; text has 4.5:1 contrast ratio against background (3:1 for large text). Keyboard: all interactive elements are reachable and operable by keyboard; focus is visible and never trapped; skip navigation links allow keyboard users to bypass repetitive navigation. Forms: all form inputs have associated labels (not just placeholder text); error messages identify the specific field and describe the error. Motion: animations respect prefers-reduced-motion media query; no content flashes more than 3 times per second.

ARIA: When and How to Use It

ARIA (Accessible Rich Internet Applications) attributes add semantic meaning to HTML elements that lack native accessibility. The first rule of ARIA: don't use ARIA if a native HTML element already provides the semantics. Use button not div role="button". Use nav not div role="navigation". When ARIA is necessary — for complex widgets like comboboxes, date pickers, and custom sliders — implement the full ARIA pattern including keyboard interaction. aria-label provides an accessible name for elements without visible text. aria-expanded, aria-selected, and aria-checked communicate state for custom controls. aria-live="polite" announces dynamic content changes to screen readers.

Testing Accessibility

Automated testing with axe-core (integrated into Playwright, Jest, and Chrome DevTools) catches ~30-40% of accessibility issues. Manual testing covers the rest: keyboard-only navigation of every interactive element, screen reader testing with NVDA (Windows) or VoiceOver (Mac/iOS), zoom testing at 200% and 400%, and color contrast verification with the browser's DevTools color picker. ProofMatcher's templates are built with WCAG 2.2 AA compliance from the start — download accessible dark mode templates at proofmatcher.com.

What Is New in WCAG 2.2

WCAG 2.2 builds on 2.1 and adds success criteria that mostly help people with low vision, motor impairments, and cognitive disabilities. The criteria at levels A and AA, which most legal requirements reference, are:

• Focus Not Obscured (Minimum): when an element receives keyboard focus, it must not be completely hidden by sticky headers, cookie banners, or other overlays.
• Dragging Movements: anything that can be done by dragging, such as reordering a list or moving a slider, must also be possible with a simple click or tap.
• Target Size (Minimum): interactive targets should be at least 24 by 24 CSS pixels, or have enough space around them.
• Consistent Help: help options such as a contact link or chat should appear in the same place on every page.
• Redundant Entry: do not ask users to enter the same information twice in one process; pre-fill it or let them select it.
• Accessible Authentication (Minimum): logging in must not depend on memorising or transcribing information, so allow password managers and pasting, and offer alternatives to puzzles.

Keyboard Navigation Done Right

Many users navigate only with a keyboard or with devices that emulate one. Every interactive element must be reachable with the Tab key in a logical order that follows the visual layout, and operable with Enter or Space. Focus must always be visible; never remove outlines without providing a clear replacement, and style it with :focus-visible so mouse users do not see it on click. Add a "Skip to main content" link as the first focusable element so keyboard users can bypass the navigation, and make sure no component traps focus, except modal dialogs, which should keep focus inside until they are closed and then return it to the button that opened them.

Accessibility in Single-Page Applications

Frameworks like React change the page without a full reload, which means screen readers are not told that a new page has appeared. After each route change, update the document title and move focus to the main heading or the main content region so assistive technology announces the new page. Announce dynamic updates such as form errors, search results counts, and toast notifications with an ARIA live region, using aria-live="polite" for most messages.

Accessible Forms

Every input needs a visible, programmatically associated label; placeholder text is not a label because it disappears as users type. Group related options with fieldset and legend. Show errors in text next to the field, explain how to fix them, link them to the input with aria-describedby, and move focus to the first error or a summary when a form fails to submit. Use the correct input types and autocomplete attributes so browsers can help users fill in details.

Building an Accessibility Process

Accessibility works best as a habit, not a one-time audit. Add automated checks such as axe to your development workflow and CI pipeline to catch missing labels, contrast problems, and invalid ARIA early; automated tools find roughly a third of issues, so they are a starting point, not a guarantee. Test key user journeys manually with the keyboard and with at least one screen reader, such as NVDA on Windows or VoiceOver on macOS and iOS. Include accessibility acceptance criteria in design reviews, and if possible, test with people who use assistive technology every day.

Finally, publish an accessibility statement that explains your conformance target, known limitations, and how users can report problems. It shows commitment, gives users a way to get help, and is expected by many procurement teams and regulators.

Colour and Contrast in Practice

Contrast failures are the most common accessibility issue found on websites. Body text needs a contrast ratio of at least 4.5:1 against its background, and large text, icons, and the boundaries of form controls need at least 3:1. Check every state, including placeholder text, disabled buttons that users still need to read, links inside paragraphs, and text over images or gradients. Links within text should be distinguishable by more than colour alone, usually with an underline. Build your palette with tested pairs of foreground and background colours, so designers and developers pick from combinations that already pass instead of checking each screen afterwards.

Images, Video, and Audio

Write alternative text that describes the purpose of an image in context, not every visual detail. A product photo might be "Blue running shoe, side view", while a decorative flourish should have an empty alt="" so screen readers skip it. Charts and infographics need the key numbers or conclusion available as text nearby. Videos need captions for deaf and hard-of-hearing users, and audio-only content needs a transcript. Avoid autoplaying media with sound, and make sure every media player can be operated with the keyboard.