Accessibility is an engineering property, not a compliance checkbox
Accessible products are not audited into existence once a year. They emerge from semantic HTML, tested keyboard paths and contrast decisions made at design-token level.
Sarah Kimani
Head of Accessibility
Organisations treat accessibility as a periodic audit: a consultant visits, files fifty issues, engineering fixes twenty, and the cycle repeats. Products built this way stay permanently half-accessible. Products that treat accessibility as an engineering property simply behave correctly, the same way they behave correctly under load.
Semantic HTML is most of the battle
A button element announces itself as clickable, receives focus in order and responds to Enter and Space without custom code. A div wearing a click handler does none of this. The single highest-leverage accessibility practice is refusing to build custom widgets when HTML ships one: buttons, links, headings in order, lists as lists, labels bound to inputs, landmarks used sparingly and meaningfully.
Custom components are sometimes necessary. When they are, copy the interaction pattern from established references and test with a screen reader, not just a linter. Automated checks catch perhaps a third of real issues; the rest live in keyboard traps, focus loss on re-render and announced-nothing dynamic updates.
Focus is a design material
Visible focus states are not decoration; they are the keyboard user's cursor. Design them at the token level - colour, width, offset - so every component inherits a compliant focus ring by default and removing one requires a deliberate, reviewable decision.
Skip links, logical tab order and predictable focus placement after actions complete are the difference between "technically navigable" and pleasant keyboard use. Test the critical paths with the mouse unplugged. It takes twenty minutes and finds what no scanner will.
Motion, contrast and quiet respectfulness
Respect prefers-reduced-motion. Meet contrast ratios in the palette itself rather than hoping combinations avoid each other. Never encode meaning in colour alone - pair status colours with icons or text labels, because colour-blind users and users of screen readers both consume state through non-colour channels.
None of this is expensive at design time. All of it is expensive at remediation time.