WCAG compliance is a floor, not a finish line

Most teams treat accessibility as a compliance checkbox: run an automated scanner, hit WCAG AA, ship. We treat it as a testing discipline with the same rigor as any other quality gate: automated coverage for the mechanical issues, manual and user testing for everything a script cannot catch. The difference is whether a disabled user can actually complete a task on your site, not just whether a report says they can.

WCAG is built on four principles, known as POUR: content has to be perceivable, operable, understandable, and robust enough for a wide range of assistive technologies. The guidelines have moved through several versions since 1999, adding coverage for mobile use, low vision, and cognitive disabilities with each update, most recently in WCAG 2.2. Conformance comes in three levels, A, AA, and AAA, and most organizations target AA because it addresses the most common barriers without demanding the most complex fixes. None of that tells you whether a screen reader user can actually finish checking out.

Automated scans catch a fraction of it

Tools like WAVE, axe DevTools, Lighthouse, and SiteImprove are fast at what they check: missing alt text, broken heading structure, contrast ratios, unlabeled form fields. They are not foolproof, and they consistently miss the issues that only surface when someone tries to use the product with a keyboard, a screen reader, or a switch device. That gap is where most compliance programs quietly fail.

• Automated scans for the mechanical issues, so obvious defects never reach review.
• Manual keyboard and screen reader testing, because tab order and focus rarely show up in a scan.
• Testing with people who have disabilities, since usability problems surface only when real users attempt real tasks.
• Expert review against WCAG, so subjective judgment calls get a second opinion.

A clean scan report proves the machine ran, not that someone using a screen reader can complete the task.

Build it in, do not bolt it on

Retrofitting accessibility after launch costs more than designing for it from the first wireframe: semantic HTML, sufficient color contrast, clear form labels, and captions on video content are cheap when they are part of the build and expensive when they are patched in afterward. Treat it as a habit that repeats every release, not a one-time project that ends when a badge goes up: regular audits, training for the team, and a documented accessibility statement that gets updated as the product changes.