Accessibility is system correctness, not interface polish

Accessibility is system correctness, not interface polish. If a user cannot perceive system state, operate a control, understand an error, or recover from an action, the product has produced the wrong behavior for that user. Treating the defect as a final visual adjustment is like calling a failed authorization check a copy problem—the failure sits in the contract, not the decoration.

WCAG’s four principles make this architectural. Perceivable means information survives different sensory channels. Operable means every action has a usable interaction path. Understandable means state changes and errors can be interpreted. Robust means semantics reach browsers, assistive technology, and other consumers through stable interfaces. Those obligations cross content, DOM structure, state management, component APIs, navigation, and testing. No contrast audit can repair a modal that loses focus or a status change that never enters the accessibility tree.

I therefore want accessibility acceptance criteria attached to behavior. A dialog must receive focus, contain it without trapping the user permanently, and restore it to a meaningful origin. A form error must identify the field, describe a repair, and be programmatically associated with the control. A live update must be announced without stealing focus. A drag interaction needs a single-pointer alternative. Authentication must not make memory or puzzle-solving the only route. These are state-transition requirements with observable outcomes.

Native semantics are the cheapest reliable implementation because they carry behavior into the accessibility tree. A real button already participates in keyboard order and exposes a role. Rebuilding it with a clickable container creates a private protocol that every input method must rediscover. ARIA can express missing states and relationships, but its first rule matters: prefer the native element when one exists. Semantics are not labels pasted onto pixels; they are the machine-readable shape of the interaction.

This is also why design systems should be constraint systems. Shared components can encode label association, visible focus, target sizing, reduced motion, forced-colors resilience, and error announcement once, then keep those properties through change. A component library does not remove the need for page-level testing, but it moves recurring correctness from individual memory into reusable infrastructure.

Automated checks remain necessary and insufficient. They catch missing names, invalid roles, some contrast failures, and structural regressions quickly, but the source hub notes that automation finds only a fraction of accessibility issues. Keyboard traversal exposes unreachable controls and obscured focus. VoiceOver or NVDA exposes reading order and announcements. Zoom and magnification expose relationships lost outside a designer’s full viewport. Real users expose whether technically conforming behavior is actually usable.

There is one precise concession: not every accessibility defect has equal consequence, and a bounded informational prototype may reasonably sequence remediation rather than block all learning. The boundary is whether the prototype is being used for a consequential decision or presented as a usable service. Once people depend on it, known barriers are correctness defects with owners and deadlines—not polish debt for an eventual redesign.

I would review accessibility the way I review reliability: define the supported operating envelope, test critical paths across representative conditions, preserve evidence, and prevent regressions at shared boundaries. Visual hierarchy must expose control priority, but the same priority must remain legible without color, animation, vision, a pointer, or perfect concentration. A system is not correct because its preferred path works. It is correct when the people it claims to serve can perceive, operate, understand, and recover from what it does.