Accessibility (WCAG)

Software that works for only some people is broken for the rest. Building to accessibility standards (WCAG) means our product works for people using a keyboard, a screen reader, or magnification, and for people who see colour and motion differently. That is a large share of real users. It is the right thing to do, it is often a legal and certification requirement, and it makes the product better for everyone.

Accessibility is usability for people with disabilities, and in practice it means better usability for all. The standard we build to is WCAG, which has four principles: content must be Perceivable, Operable, Understandable, and Robust. Most accessibility comes from doing the basics well: semantic HTML, keyboard support, enough contrast, labels on inputs, and not relying on colour alone.

Like security, accessibility is far cheaper to build in than to add later, and adding it late is painful. It is also often required, both by equality law and by certification and procurement (see Marketplace & Certification Readiness). So an inaccessible product can block a sale or create legal risk, on top of shutting out people who should be able to use it.

Build it in

• DoUse semantic HTML: real buttons, headings, lists, labels, and landmarks. Then assistive technology understands the page without extra work.
• DoMake everything work with the keyboard alone, with a visible focus indicator and a sensible focus and tab order. Never trap or hide focus.
• DoLabel form fields and controls, link errors to their inputs, and give images meaningful alt text (or empty alt for decoration).
• DoMeet the minimum contrast levels, and do not use colour alone to carry meaning. Pair it with text, an icon, or a pattern.
• ConsiderUsing ARIA only where semantic HTML cannot express the pattern, and using it correctly. Wrong ARIA is worse than none.
• ConsiderRespecting user preferences such as reduced motion, and supporting zoom and magnification up to standard levels without breaking the layout.
• AvoidRebuilding native controls (dropdowns, checkboxes, dialogs) from scratch when an accessible native or well-tested component exists. Custom widgets often lose keyboard and screen-reader support.

Verify it

• DoTest with a keyboard and a screen reader while building a feature, not afterwards. Automated checks catch only a fraction of the issues.
• DoRun automated accessibility linting and scanning in the pipeline to catch regressions cheaply (missing labels, contrast, roles).
• ConsiderIncluding accessibility in the definition of done and in code review for any user-facing change (see Code Review).
• NeverShip a user-facing feature that a keyboard or screen-reader user cannot operate, where the domain requires it to be usable.

Self-review checklist

• AskCan I complete this whole flow using only the keyboard, with visible focus?
• AskWould a screen-reader user understand each control, label, and error?
• AskIs meaning ever conveyed by colour alone, and does text meet contrast minimums?
• AskAm I using semantic HTML, or re-inventing controls that lose accessibility?