Accessibility Is Not a Feature.
It’s a Baseline.

The Failure Rate Nobody Talks About

The number of digital products that fail WCAG 2.1 AA the accessibility standard required by law in many jurisdictions is genuinely staggering. WebAIM’s annual audit of the top one million web pages consistently finds that over 96% have detectable WCAG failures. Automated scan tools typically catch only 30% of issues; the remaining 70% require human testing with assistive technologies.

The deeper problem isn’t detection it’s timing. Most teams discover accessibility issues in a compliance audit six months after launch, at which point fixes require rearchitecting components that were built without accessibility in mind. The cost multiplier for retroactive accessibility work versus building it in from the start is estimated at 5–30x depending on the severity of the issues.

Accessibility as a Design Constraint

The teams doing this well have made a simple but profound shift: they treat keyboard navigation, screen reader semantics, colour contrast, and focus management as constraints that shape initial design decisions not defects to fix after the fact. The difference shows up in how they review design work.

When accessibility is a constraint from the wireframe stage, it costs almost nothing. When it’s an audit finding six months post-launch, it costs a great deal.

In practice this means: colour contrast ratios are checked before a colour palette is finalised, not after. Interactive components are designed with keyboard focus states from the beginning. Form fields have visible labels because that’s the specification, not as an afterthought. Screen reader flow is considered when information architecture decisions are made.

What WCAG 2.1 AA Actually Requires

WCAG 2.1 AA is structured around four principles: perceivable (content can be perceived by all users), operable (interface components are keyboard-navigable and don’t cause seizures), understandable (content and operation are comprehensible), and robust (content can be interpreted by current assistive technologies).

In practical engineering terms, the most impactful requirements are:

• Colour contrast: 4.5:1 ratio for normal text, 3:1 for large text and UI components
• Keyboard navigation: all interactive elements reachable and operable by keyboard alone
• Focus indicators: visible focus states on all interactive elements (not just removed via outline: none)
• Alternative text: meaningful alt text on all non-decorative images
• Form labels: all form inputs have programmatically associated labels
• Heading structure: logical heading hierarchy that makes sense to screen reader users
• Error identification: errors identified in text, not just with colour alone

Testing Properly

Automated tools (axe, Lighthouse, WAVE) are a necessary starting point but insufficient on their own. They catch the detectable pattern failures missing alt text, insufficient contrast, missing form labels but they can’t tell you whether the keyboard navigation flow is logical, whether the screen reader announcement order makes sense, or whether a complex interactive widget actually works with assistive technology.

The minimum viable manual testing suite: keyboard-only navigation through the entire critical user journey, a screen reader test (VoiceOver on macOS, NVDA on Windows) through the same journey, and a zoom test at 200% to ensure layout doesn’t break. This takes roughly two hours for a typical SaaS product and surfaces the issues that automated tools miss.

The Legal Reality in 2026

Web accessibility lawsuits under the ADA (US), EN 301 549 (EU), and similar legislation in Canada, Australia, and the UK are at record levels in 2026. The European Accessibility Act, which came into force in June 2025, now requires all products and services marketed in the EU to meet EN 301 549 standards. For any team with European customers or aspirations, this is a legal compliance requirement, not optional guidance.

The pragmatic response: implement WCAG 2.1 AA as your baseline, document your conformance, and test with real users who use assistive technologies. Full WCAG conformance requires more than automated testing, but a systematic approach to the highest-impact requirements eliminates the vast majority of legal and user experience risk.