Six weeks to launch: a council transport site that fails its own policy
A city council is rebuilding its public transport website, which gets 240,000 visits a month. The new route finder is a custom drop-down built from div elements: it opens on mouse click, closes when the mouse leaves, and has no visible focus indicator. Timetable headers are white text on grey at 3.0:1 contrast, with cell text at 12 px. The live departures panel signals ‘on time’, ‘delayed’ and ‘cancelled’ with green, amber and red dots only. Timetables are still available only as scanned PDFs. The council's accessibility policy requires WCAG 2.2 AA. The rebuild launches in six weeks; the developer says accessibility can be ‘patched afterwards’ and points out that an automated checker scored the pages 86%.
1. Identify the specific barriers, map each to a WCAG success criterion, and rank them. Justify the ranking principle you use.
Read the worked answer
The barriers.
- Route finder built from div elements: not keyboard operable (2.1.1 Keyboard), no visible focus (2.4.7 Focus Visible), and no name, role or state exposed to assistive technology (4.1.2 Name, Role, Value). The ‘closes when the mouse leaves’ behaviour breaks keyboard and screen-magnifier users specifically.
- 3.0:1 header contrast fails 1.4.3 Contrast (Minimum), which requires 4.5:1 for normal text and 3:1 only for large text.
- Colour-only status dots fail 1.4.1 Use of Colour; red/amber/green is also the most common confusion pair, affecting roughly one in twelve men.
- Scanned PDFs fail 1.1.1 Non-text Content and cannot reflow or be read aloud.
Ranking principle: severity of impact on completing the core task, multiplied by the number of users affected. On that basis the route finder is first - it blocks the entire journey, not one detail - followed by the colour-only status (it conveys wrong information, which is worse than none), then contrast, then the PDFs. The PDFs would rank higher if no HTML alternative were planned, because timetables are the site's core content.
2. Critique the developer's two arguments: the 86% automated score, and ‘patch accessibility afterwards’.
Read the worked answer
The 86% score measures the wrong thing. Automated checkers only find what can be parsed from markup: missing alt attributes, computed contrast ratios, some ARIA errors. They cannot test whether the route finder is operable by keyboard, whether focus order makes sense, whether the drop-down announces its state, or whether a timetable grid is comprehensible when read aloud. Common industry estimates put automated detection at roughly a third of accessibility problems, and the more damaging flaw is that a percentage weights all failures equally - one unusable component can sink a page that otherwise scores highly. The score is evidence of some hygiene, not of usability.
‘Patch afterwards’ is a costing argument in disguise. The route finder is a shared component, so fixing it later means reopening the design, re-testing the whole journey, and re-training content authors; retrofits are typically more expensive than building it correctly. More importantly, users in the gap get a service that fails, and for a council that is a legal and reputational exposure, not just a design debt.
The defensible line: throwaway content can wait; anything baked into a shared component cannot.
3. You have six weeks and cannot fix everything. Recommend what to do, in order, and what you would publicly accept as unfinished.
Read the worked answer
Buy the most risk reduction per week.
Weeks 1–2: replace the custom drop-down with native elements. A native select and button give keyboard operation, focus handling and screen-reader semantics for free - cheaper and more reliable than hand-written ARIA. Add a visible :focus style across the site; it is a handful of CSS rules and it unlocks the whole task.
Week 3: contrast and colour. Raise header text to at least 4.5:1, and add text to the status indicators (‘Delayed 6 min’) so colour is redundant rather than load-bearing.
Week 4: generate HTML timetables from the same source data, keeping PDFs as a secondary download. This removes the scanned-image failure at its root.
Week 5: test with people, not only tools - keyboard-only pass, a screen reader, zoom to 200%, and two or three real users including an older person and a screen-reader user.
Week 6: fix what testing found and publish an accessibility statement naming known gaps and a contact route.
Publicly accept: the archive of historical PDF timetables stays as-is for now, stated openly with a remediation date rather than left silent.