Accessibility used to be something teams added to the backlog and moved to next sprint indefinitely. In 2026 that posture has become legally and financially risky.
The EU Web Accessibility Directive and European Accessibility Act are in force. US courts continue to rule that the ADA applies to websites. UK accessibility regulations carry enforcement teeth. Companies have paid significant settlements for inaccessible products. The conversation has shifted from "should we do this" to "what do we actually need to ship."
This post is the practical developer version — what the standards require, how to test for them, and what to fix first.
The current standard: WCAG 2.2
WCAG 2.2 is the current benchmark for legal compliance. It builds on 2.1 with several new criteria — the most important being:
Focus Appearance (2.2 AA) — keyboard focus indicators must be visible and meet minimum size and contrast requirements. The browser default outline does not reliably pass.
Dragging Movements (2.2 AA) — any functionality that uses drag must also be operable with a single pointer alternative. Kanban boards, sliders, and reorderable lists are commonly affected.
Target Size (2.2 AA) — interactive targets must be at least 24×24 CSS pixels. Small icon buttons and tightly packed link lists are the usual failures.
Accessible Authentication (2.2 AA) — login flows cannot require cognitive tests (like puzzles) that do not have an accessible alternative. CAPTCHA implementations are frequently flagged here.
WCAG 3.0 is in development but not yet a legal standard. Focus on 2.2 AA compliance for now.
The four principles (and what they mean in code)
WCAG organises everything under four principles: Perceivable, Operable, Understandable, Robust (POUR).
Perceivable means all information reaches the user regardless of sense. In practice:
- Every
<img>needsalttext oralt=""if decorative - Videos need captions
- Colour cannot be the only way to convey information
- Text contrast must meet the 4.5:1 ratio (3:1 for large text)
Operable means everything works without a mouse. In practice:
- All interactive elements must be keyboard focusable and activatable
- No keyboard traps
- Skip navigation links for screen reader users
- No content that flashes more than 3 times per second
Understandable means content and UI behaviour are predictable and clear:
- Form inputs need visible, programmatically associated labels (
<label for>oraria-label) - Error messages must identify what went wrong and how to fix it
- Language is declared (
<html lang="en">)
Robust means your HTML works with assistive technologies:
- Valid, semantic HTML — use
<button>not<div onclick> - ARIA roles and properties are correct when custom components require them
- Status messages use
aria-liveso screen readers announce them
The fastest wins
If you are auditing an existing codebase, these fixes have the highest impact-to-effort ratio:
1. Add focus styles
:focus-visible {
outline: 2px solid #E21B1B;
outline-offset: 2px;
}Never outline: none without a replacement. The :focus-visible pseudo-class shows focus styles for keyboard users while hiding them for mouse clicks — the modern best practice.
2. Fix form labels
<!-- Wrong -->
<input type="email" placeholder="Email">
<!-- Right -->
<label for="email">Email</label>
<input type="email" id="email" placeholder="email@example.com">
Placeholders disappear when you type. Labels persist and are announced by screen readers.
3. Use semantic HTML
<!-- Wrong -->
<div class="btn" onclick="submit()">Submit</div>
<!-- Right -->
<button type="submit">Submit</button><button> is keyboard focusable, activatable with Enter and Space, and announces its role to assistive technology for free. A <div> does none of those things without significant ARIA work.
4. Add alt text that communicates meaning
<!-- Decorative image -->
<img src="divider.png" alt="">
<!-- Informative image -->
<img src="chart.png" alt="Revenue grew 40% from Q1 to Q4 2025">
<!-- Functional image (button) -->
<img src="search-icon.png" alt="Search">
Alt text describes the purpose of the image in context, not just what it looks like.
5. Ensure colour contrast
Use a contrast checker on your text and background colour pairs. The most common failures are light grey text on white backgrounds and white text on brand colours that are not dark enough.
The minimum ratios: 4.5:1 for normal text, 3:1 for text 18px+ or 14px+ bold, 3:1 for UI components and focus indicators.
Testing tools
Automated testing catches ~30-40% of issues. Run these as part of your build:
- axe-core — integrates with Playwright, Cypress, and Jest. Catches ARIA errors, missing labels, and colour contrast issues.
- Lighthouse — built into Chrome DevTools, gives an accessibility score with specific failures.
- eslint-plugin-jsx-a11y — catches accessibility issues in JSX at write time.
Manual testing catches the rest:
- Unplug your mouse and tab through your entire app. Every interactive element must be reachable and usable.
- Turn on a screen reader (VoiceOver on Mac, NVDA on Windows, TalkBack on Android) and navigate your most critical flows.
- Zoom to 200% and verify the layout does not break.
- Test with a keyboard only on forms, modals, and custom dropdowns.
What the legal exposure looks like
In the US, web accessibility lawsuits under Title III of the ADA exceeded 4,000 cases in 2025. E-commerce, banking, healthcare, and hospitality are the most targeted sectors, but no vertical is exempt. Settlement costs typically range from $25,000 to $250,000 plus remediation costs — before factoring in reputational damage.
In the EU, the European Accessibility Act requires private sector digital products and services to meet accessibility standards from June 2025. Member state enforcement mechanisms vary, but the direction is toward active compliance monitoring.
The liability picture is clear: fixing accessibility proactively is cheaper than fixing it under legal pressure.
Building it in from the start
Retrofitting accessibility into an existing codebase is expensive and error-prone. Building it in from the start is not.
The practical checklist for new components:
- Does it work with keyboard only?
- Does it work with a screen reader?
- Do all interactive elements have accessible names?
- Does it meet colour contrast requirements?
- Are error states programmatically announced?
Run axe-core in your CI pipeline and fail builds on new violations. That single change prevents the debt from compounding.
Accessibility is not a feature. It is a quality baseline — and in 2026, increasingly a legal one.