Accessibility is a design constraint, not a retrofit
An accessibility audit at the end of a project will find the cheap problems and miss the expensive ones. Missing labels and low contrast are code fixes; a navigation model that only makes sense if you can see the whole screen at once is a redesign. The difference is decided months earlier, in decisions a designer makes without necessarily realising that accessibility is what they are deciding.
What can automated testing actually find?
A useful minority of issues, and a predictable set of them: missing alternative text, insufficient colour contrast, form fields without labels, missing document language, duplicate identifiers. These are worth catching automatically because they are cheap to find and cheap to fix, and every team should run such a check in the build.
What automation cannot judge is whether anything makes sense. It cannot tell you that the alternative text says image of a graph, that the labels are technically present and mutually indistinguishable, that the tab order marches through the page in an order nobody would choose, or that a status message updates silently so a screen reader user never learns the operation succeeded.
So a clean automated report means the obvious defects are absent. It is not evidence that anyone can use the product, and treating it as such is the most common way organisations convince themselves they are compliant while remaining unusable.
Which decisions cannot be fixed later?
Anything structural. If the interface depends on seeing several regions at once, on hovering to reveal meaning, on colour alone to distinguish states, on drag and drop with no alternative, or on a timing the user cannot control, the fix is a redesign rather than a remediation. These are all design-time decisions and all of them are cheap to avoid and expensive to reverse.
Navigation model is the biggest of them. A screen reader user or a keyboard user moves through content in sequence, so a layout that scatters related controls across the page, or hides primary actions behind hover, becomes a memory exercise. This is invisible when the design is reviewed on a large screen by people using a mouse.
The second is content. Reading level, sentence length, link text, headings that describe rather than decorate, error messages that say what to do next: these are design decisions with a large accessibility effect, and they benefit everybody, which is the reason they rarely get made in an audit context. Nobody schedules a remediation project to rewrite the microcopy.
| Problem | Found by tools? | Fixed how | Decided when |
|---|---|---|---|
| Contrast below threshold | Yes | Change a token value | Any time, cheaply |
| Form field without a label | Yes | Code change | Any time, cheaply |
| Meaning carried by colour alone | Partly | Add a second signal: icon, text, pattern | Design time, cheap; later, awkward |
| Illogical focus order and lost focus | No | Restructure the markup and the layout | Design and build time |
| Status changes announced to nobody | No | Add live regions and design the message | Design time, the wording is a design decision |
| Interaction requiring hover or drag only | No | Design an alternative path | Design time, otherwise a redesign |
Does designing for accessibility make products worse for everyone else?
No, and the evidence is in the constraints themselves. Sufficient contrast helps anyone using a phone outdoors. Captions help anyone in a quiet office. Keyboard operability is what power users want anyway. Clear error messages reduce support contacts from every user. Larger touch targets help anyone on a train.
The genuine trade is with visual fashion rather than with usability. Low-contrast grey text, invisible focus rings, ultra-thin typefaces and controls that only appear on hover are aesthetic preferences, and accessibility does constrain them. That is a real cost and it is worth being honest about, because pretending there is no tension is what makes designers dismiss the whole subject.
Where a genuine conflict arises, it is usually in dense professional tools, where experienced users want information density that works against readability. The resolution is a preference rather than a compromise: let the user choose density, which is more work than either extreme and better than both.
What should you require when hiring a designer?
Ask them to describe how a keyboard user completes a flow they designed. Anyone who has taken this seriously will answer immediately and mention focus order, skip links, where focus goes when a dialogue opens and where it returns when it closes. Anyone who has not will talk about contrast ratios, because that is the part everybody knows.
Ask what they specify for focus states, error identification and touch target size. These are ordinary parts of a design specification for a practitioner and are missing from most files, which makes the answer a fast filter.
Then ask whether they have watched anyone use a screen reader. Not whether they have used one themselves for ten minutes, which teaches only that it is confusing, but whether they have watched a proficient user, who navigates by headings and landmarks at high speed. Designers who have seen that make different structural decisions afterwards, permanently.
What test can you run today without any tools?
Unplug your mouse and complete your main task with the keyboard. Note every point where you cannot see what is focused, where a dialogue traps you, where the order surprises you and where something can only be reached by hovering. That takes ten minutes, requires no expertise and will find issues that no automated scan reports.
Then zoom the browser to two hundred per cent and try again. Layouts that hide content, cut off buttons or force horizontal scrolling at that zoom level are failing a large group of people who are nowhere near being registered as visually impaired.
Third, turn the display to greyscale for five minutes and use the product. Everything that becomes ambiguous was relying on colour alone. All three tests are things a non-designer can run this afternoon, and together they will tell you more about your product than the summary page of most audits.
Common questions
- Can accessibility be added after a product is built?
- Partly. Contrast, labels, alternative text and missing attributes are code fixes at any stage. Structural problems are not: an interface that depends on seeing several regions at once, on hover to reveal meaning, on colour alone to distinguish states, or on drag and drop with no alternative, requires redesign rather than remediation. Those decisions are made at design time and are cheap to avoid and expensive to reverse.
- How much do automated accessibility tools catch?
- A useful minority, covering a predictable set of defects: missing alternative text, low contrast, unlabelled form fields, missing page language and duplicate identifiers. They cannot judge whether anything makes sense, so they will pass alternative text reading image of a graph, an illogical tab order, indistinguishable labels and status messages that update silently. A clean report means obvious defects are absent, not that the product is usable.
- Does accessibility make designs worse?
- It constrains visual fashion rather than usability. Low-contrast text, invisible focus rings, very thin typefaces and hover-only controls are the aesthetic preferences that genuinely conflict, and being honest about that tension matters. The constraints themselves help everyone: contrast helps outdoors, captions help in quiet offices, keyboard operability is what power users want, and clear error messages reduce support contact from all users.
- What accessibility questions should I ask when hiring a designer?
- Ask how a keyboard user completes a flow they designed. Practitioners answer immediately and mention focus order, skip links and where focus moves when a dialogue opens and closes, while others default to talking about contrast ratios. Ask what they specify for focus states, error identification and touch target size. Ask whether they have watched a proficient screen reader user work, which changes structural decisions permanently.
- How can a non-designer test accessibility quickly?
- Three checks, about twenty minutes total and no tools required. Unplug the mouse and complete the main task by keyboard, noting lost focus, trapping dialogues and hover-only controls. Zoom the browser to two hundred per cent and look for cut-off buttons, hidden content or horizontal scrolling. Then switch the display to greyscale and note everything that becomes ambiguous, since it was relying on colour alone.
