The A11y Gate

The incident

The product worked beautifully — for users with a mouse, sharp vision, and no assistive technology. For a screen-reader user, the checkout was a maze of unlabeled buttons ending at a custom dropdown that keyboard focus couldn't enter at all. The company learned this from a legal demand letter, which is the most expensive possible QA channel — and the least of it: the product had been silently turning away a real segment of paying users since launch.

Why the obvious approach fails

Treating accessibility as a pre-launch audit guarantees it becomes retrofit work — and accessibility retrofit is expensive precisely because the cheap decisions (semantic elements, focus order, color contrast, labeled controls) were made wrong months earlier, at zero cost, by default. Custom components are the classic trap: a div dressed as a dropdown looks identical and is invisible to keyboards and screen readers, and every hand-rolled widget re-solves problems the native elements solved decades ago. Automated scanners catch maybe a third of real issues; the rest need the two tests that take minutes and get skipped: can you complete the flow with only a keyboard, and does it make sense with your eyes closed and a screen reader on.

The standard

• +Semantic HTML is the default; custom interactive components must implement full keyboard and ARIA behavior or use a proven accessible primitive — a div with a click handler is not a button.
• +Automated WCAG checks (axe-class) run in CI on every merge; violations at declared severity block, not warn.
• +Every feature's acceptance criteria include the two human tests: full keyboard completion, and a screen-reader pass of the core flow.
• +Contrast, focus visibility, and touch-target sizes are design-token enforced — inaccessible values can't ship because they can't be expressed.
• +Accessibility bugs are triaged as functional bugs with the same severity scale — 'works for most users' is a partial outage, and it's treated like one.

Composes with