Accessibility in product teams

The pipeline

Accessibility fails most often not because nobody cared, but because it entered the process too late to fix cheaply. It belongs at every stage, not just QA.

The cost of fixing an accessibility issue rises the later it's caught, a missing label costs nothing to add at design time, and considerably more once it's shipped and someone else has to find it.

Annotations & handoff

A design file that only shows what something looks like leaves accessibility as a guess for whoever builds it. A handful of annotations closes that gap.

• Accessible name: what should assistive technology call this element, if it's not obvious from the visible label?
• Role or trait: what type of control is this, if it's custom-built rather than a native one?
• State: selected, expanded, disabled, invalid, whatever applies.
• Focus order: where does this sit in the sequence, and where does focus go after an interaction?
• Grouping: should related elements be announced together, or separately?
• Hidden or decorative content: what should be excluded from the accessibility tree entirely?

Not every field applies to every component, and native controls often provide most of this automatically. The annotation only needs to cover what isn't already handled by choosing the right underlying element.

Definition of done

"Accessible" needs a concrete definition, or it quietly becomes optional under deadline pressure.

Accessibility debt is worth naming explicitly, the same way technical debt is. An issue that's tracked and prioritised is very different from one that's simply forgotten because nobody wrote it down.