Website ADA compliance: an order of work that holds up
Bringing a website to ADA compliance is a sequence, not a scramble. This is the order that survives contact with a deadline.
Start with the pages that carry risk
Not every page carries the same exposure. A marketing page with a broken carousel is a nuisance. A checkout, a claim form or an account screen with a keyboard trap is the complaint someone actually makes.
Sort your pages into three groups before you test anything: money and personal data, services a person has no alternative to, and everything else. Test in that order. If the work stops early, it stopped in the right place.
Five failures we find first
- Fields with no name. The label sits visually beside the input but is not bound to it, so a screen reader announces an edit box and nothing else.
- Focus that goes nowhere. A modal opens without taking focus, the page behind keeps scrolling, and Escape does not close it.
- Meaning that lives in an image. A chart, a status icon or a product photo with no text alternative, so the information does not exist for a screen reader.
- Colour doing the work alone. An error is red, a required field is red, and nothing says either in words.
- Documents bolted on. A tagged PDF that reads in the wrong order, because nobody listened to it end to end.
Each of these is cheap to fix once it is named, and expensive to find late. The free ADA compliance checker catches the first of them on any page you paste in, and our WCAG 2.2 checklist covers the rest by hand.
Third party code you do not control
A chat widget, a payment frame, a consent banner and an analytics overlay all arrive as somebody else's markup. They frequently break keyboard access, and they are outside your release cycle.
You still have options. Test the widget and take the finding to the vendor in writing, with a criterion and a reproduction. Where a vendor will not fix it, replace it, and where you cannot replace it, name it in your statement as a known limitation rather than pretending it is not there.
Write the accessibility statement
A statement is the page that says what you have done, what you know is still missing, and how a reader reports a barrier. It is the first thing a buyer or a complainant looks for, and the cheapest page on this list to publish today.
Ours is at accessibility statement and you are welcome to copy its structure: the standard we test against, the date of the last check, the known gaps, and a contact route. Where you claim conformance, name the version and the level, because a claim you cannot evidence is worse than no claim at all.
Recheck after every release
Accessibility regresses the way any other quality does. A new component, a new banner or a new payment provider reintroduces the barrier that was fixed last quarter.
Write the checks down as cases your own team can run, then run the same set on every release. That is what our test case creation and regression testing services are for, though a spreadsheet and a willing tester go a long way.
Where the deadlines stand
The law moves, and the deadlines for public sector work in the United States moved recently. We keep the dated changes, with their sources, on the accessibility news page rather than repeat a date that may already be wrong.
What does not move is the work. A site that passes WCAG 2.1 Level AA tests the same way whether the date is April 2027 or April 2028, and the reasons to do it are older than either deadline.