a11y-ops

a11y-ops

Accessibility stopped being a quality preference and became a legal requirement with dates attached. It is also, unhelpfully, a domain where the tooling everyone reaches for finds well under half the problems — so the work is mostly about knowing where automation stops.

Helps with

"Is our site compliant?" — a question with a real answer that depends on which jurisdiction, which standard version, and which deadline applies to that client.

An audit that needs to find real failures rather than produce a score. Vendor "94% accessible" numbers correspond to nothing in the standard.

A component library where every custom control is mouse-only, because a <div> replaced a <button> and nothing replaced what the <button> was doing.

Forms that lose conversions from screen reader and keyboard users: placeholders used as labels, errors signalled only in red, no autocomplete.

outline: none shipped across a design system, leaving keyboard users with no idea where they are.

A modal, dropdown or date picker that traps focus, or drops it, or never returns it to the trigger.

Writing an accessibility statement that is honest enough to be defensible rather than an overclaim that creates its own liability.

Wiring accessibility into CI so a fix stays fixed instead of being re-bought at the next audit.

The two things that decide everything

1. Automated tooling finds roughly 30–40% of WCAG failures. Every plan follows from this. A green axe run is a floor, not a result — the rest needs a keyboard and a human. Anyone selling automated compliance is selling the 30%.

2. Use the native element. <button>, <a href>, <input>, <select>, <details> arrive with focusability, keyboard activation, correct role and state announcement already handled. Almost every failure in the catalogue comes from replacing one with a <div> and rebuilding a fraction of what was lost. Its corollary is the first rule of ARIA: no ARIA beats bad ARIA, because role="button" claims a contract a div does not fulfil.