Accessibility Beyond WCAG: Building Digital Products for Everyone

WCAG 2.1 AA compliance is table stakes in 2025 — required by law in most jurisdictions, expected by enterprise procurement, and increasingly checked by automated tooling in CI pipelines. But passing an automated accessibility audit and building a genuinely accessible product are not the same thing. Automated tools catch at most 30–40% of real accessibility issues.

The 60% that automation misses

Automated tools are excellent at catching missing alt text, insufficient colour contrast, unlabelled form inputs, and missing ARIA roles. They cannot catch: focus order that is technically correct but confusing to a screen reader user, gesture-only interactions with no keyboard equivalent, error messages that are present in the DOM but not announced by screen readers, or modal dialogs that trap focus incorrectly. These require manual testing with actual assistive technology.

Building the accessibility testing stack

Effective accessibility testing has three layers. Automated: axe-core in CI (via jest-axe or Playwright axe integration) catches structural issues on every PR. Manual: monthly testing sessions with keyboard-only navigation and NVDA/VoiceOver screen readers catch interaction-level issues. User testing: quarterly sessions with disabled users catch the usability issues that neither automation nor developer testing surfaces. The investment in all three layers pays back in reduced legal risk and broader audience reach.

Semantic HTML is the foundation

The single highest-leverage accessibility improvement most teams can make is using the correct HTML elements. A `<button>` is keyboard focusable, announces as a button to screen readers, fires on Enter and Space, and communicates its state through `disabled` and `aria-pressed`. A `<div onClick>` does none of this and requires 15 ARIA attributes to partially replicate the behaviour. Use native elements, add ARIA only when native semantics are insufficient, and test with the browser's accessibility tree before shipping.

Focus management in SPAs

Single-page applications have a persistent accessibility problem: when a route changes or a modal opens, the browser doesn't move focus to the new content. Screen reader users find themselves lost on the previous page after clicking a link. Fix: on route change, move focus programmatically to the `<main>` element or the new page heading. When a modal opens, move focus to the first focusable element inside it. When the modal closes, return focus to the trigger element. These three rules resolve the majority of SPA focus management issues.

Accessible motion and animation

Animations and transitions can trigger vestibular disorders in users with certain neurological conditions. The `prefers-reduced-motion` media query is your friend: wrap all animations in a CSS `@media (prefers-reduced-motion: no-preference)` block, or check the value in JavaScript before applying Framer Motion animations. This is a one-day implementation with zero visual impact for the 97% of users who don't have motion sensitivity, and a significant quality-of-life improvement for those who do.

Colour and contrast: beyond the 4.5:1 ratio

WCAG AA requires a 4.5:1 contrast ratio for normal text. But contrast isn't just about text — it's about icon clarity, focus indicator visibility, and distinguishing interactive from non-interactive elements. WCAG 2.2 introduces new requirements for focus indicators (minimum 3:1 contrast ratio against adjacent colours). WCAG 3.0 will introduce APCA (Advanced Perceptual Contrast Algorithm), which is more accurate than the current relative luminance formula. Design teams should be moving to APCA tooling now to future-proof their colour systems.

Accessibility as a product metric

Accessibility is often treated as a compliance concern rather than a product quality metric. The reframe that works: accessibility bugs are user-reported bugs, they go into the product backlog, they have severity levels, and they block releases when they're P1. Teams that treat accessibility as a quality dimension — not a compliance checkbox — ship better products for everyone, because the constraints of accessible design consistently produce clearer interfaces, more logical information architecture, and better keyboard navigation for all users.