Design & UX · master area
Accessibility Design
Keyboard, contrast, focus order, screen-reader names — designed in, not bolted on. A first-class ility, not a last-pass audit.
Owners: Designer Phase it lives in: What We Build → How We Build (Volumes III and IV) The corpus principle this enacts: UX/product ilities are first-class requirements.
Where it lives in the chain
- What We Build · Ilities selection — accessibility is named as a target ility, not assumed
- How We Build · Testing · QA craft — the verification half
How to do this
- Practice — pick the accessibility targets in shaping. "WCAG 2.1 AA, full keyboard, screen reader labels on all interactive elements" is a target. "We'll make it accessible" is not.
- Related craft — Accessibility Testing — the automated and manual checks
- Related craft — UX/Product Ilities
What good design output looks like
- Focus order is drawn in the wireframe. Where does Tab land first, second, third?
- Names are written for every interactive element. "Submit grade for question 4 of 12" is a screen-reader label; "Submit" alone is not.
- Contrast ratios are checked against tokens at design time, not at audit time.
- Errors are not delivered by colour alone. The state name carries; the colour reinforces.
- Keyboard is the primary input the design is tested against; the mouse is the secondary one.
Accessibility designed in is invisible. Accessibility bolted on adds a "Skip to content" link and calls it a day. The first lets a screen-reader user grade the exam the same way Gal does. The second produces a compliance certificate and a frustrated user who can't actually use the product.
Related crafts
- Accessibility Testing
- UX/Product Ilities
- Design System — where the patterns enforce the standard