- Accessibility
- Process
Most accessibility work goes wrong in the same way. The site gets built, someone runs an automated scan a week before launch, a list of colour-contrast failures comes back, and the team spends two days changing hex values. The scan goes green. The site is still difficult to use.
That approach fails because it treats accessibility as a property of the finished markup. Most of it is decided much earlier, in decisions that no scanner can see.
What automated testing does and does not cover
Automated tools are genuinely useful. They are also limited: depending on whose analysis you read, they detect somewhere around a third of WCAG success criteria. They are good at the mechanical things — a missing alt attribute, an input with no label, text below a contrast threshold.
They cannot tell you whether your alt text is useful. They cannot tell you whether the focus order matches the visual order, whether an error message explains how to fix the problem, or whether a heading structure describes the page or merely styles it. Those need a person.
So a perfect automated score is a floor, not a result. We run the tools, and we expect them to pass, but passing them is not the claim.
Where the decisions actually get made
In structure, before design. Heading hierarchy is an outline of the page. If the outline is wrong, no amount of later markup fixes it, because the problem is that the content was never organised.
In design, before build. Contrast, target sizes, focus indicators and the distinction between "colour tells you this" and "colour reinforces this" are all design decisions. Retrofitting them means redoing the design.
In the content model. If a CMS lets an editor publish an image with no alternative text, images without alternative text will be published. The system should make the accessible path the easy one.
What we do on every project
- Heading order is treated as content structure, agreed before visual design begins.
- Colour combinations are checked against contrast ratios during design, not judged by eye.
- Every interactive element is reachable and operable by keyboard, with a visible focus indicator.
- Motion respects
prefers-reduced-motion, because vestibular disorders are not rare. - Forms have persistent labels, and errors are announced to assistive technology rather than signalled by colour.
- Alternative text is a required field where an image carries meaning, and decorative images are marked as decorative.
None of that is exotic. It is ordinary work, done at the point where it is cheap instead of the point where it is expensive.
The honest version
Accessibility work is never finished, and anyone claiming a permanently conformant website is describing a snapshot. What you can reasonably ask of a developer is that they design for it from the start, test with more than a scanner, and fix things when someone reports a barrier.
That last part matters most. If you meet a problem on this site, tell us and we will fix it.
Written by base32.