/accessibility

Accessibility

Statement reviewed 25 August 2026 · owner: engineering · applies to the rider map, the website embed, and this site

The rider map is built to WCAG 2.1 Level AA. We publish a conformance report that says so criterion by criterion, and it names the one criterion we do not meet yet. You can read it before you talk to us.

1. Where we stand today

• Supports every WCAG 2.1 A and AA criterion in the report, with one exception, below. Criteria that do not apply to the product (audio, video, motion input, financial transactions) are marked Not Applicable rather than claimed.
• Does not support SC 2.2.2, Pause, Stop, Hide. Vehicle positions update by themselves and there is no control to pause them. Section 2 is what that means and what happens about it.
• Not yet tested: a full screen-reader pass with NVDA and VoiceOver. It is scheduled before the first paid deployment and the report will be reissued with its results. We would rather write that sentence than imply coverage we don't have.

2. The criterion we do not meet

The map refreshes itself roughly every twenty seconds, and each vehicle's freshness is re-derived once a second. WCAG 2.2.2 says a rider must be able to pause content that updates automatically, and the map has no pause control. There is no short-duration exception that covers it. This is a real failure, it is the single Does Not Support row in the report, and it is published rather than smoothed over.

A pause control is built before the first paid deployment. When it ships, the criterion is re-tested, the report is reissued with the new row, and this page changes with it. Until then, every other way of reading the same data works: every vehicle on the map is also a row of text with its own status, in the same order, reachable by keyboard and announced by a screen reader.

3. What was actually tested

The report lists this in full. In short, against the live deployment rather than a development build:

• An automated audit (Lighthouse, axe-core rules) of the map and the embed, mobile emulation, scoring 98 of 100 on both.
• A manual keyboard walk of every interactive control, with focus visibility confirmed by computed style, and no keyboard trap found.
• Reflow at a 320 pixel viewport with no horizontal scrolling, and the WCAG 1.4.12 text-spacing override applied with nothing clipped.
• Accessibility-tree inspection of each rider screen, in both light and dark themes.
• Colour contrast checked by machine on every build: 34 text assertions in this app, 52 across the product line, each required to clear 4.5:1. A failing pair fails the build, so contrast cannot regress quietly between releases.

4. Built so the map is not the only way in

• Every vehicle is a row of text as well as a dot, with its own status, in the same order as the map.
• State is carried in words, never in colour alone: "Live", "Delayed", "No signal", "No data today".
• A vehicle that stops reporting is removed within five minutes and described in plain text ("No data from Bus 31 since 3:42 PM") instead of being left on the map as a stale dot. Not knowing is a fact we tell you, and screen-reader users get it in the same sentence everyone else does.
• Feed state is announced without stealing focus, and every control is a real button with a visible focus ring.

5. What this statement does not cover

The report covers the rider-facing surfaces named above. The agency staff console is a separate surface and a future edition covers it, after its own evaluation; it shares the rider app's stylesheet, contrast gate and component patterns, which is a reason to expect a similar result and not a substitute for testing it. One rider view added after the evaluation, a shared single-vehicle tracking link, is named in the report as not separately tested. This marketing site is built to the same standard and is not itself in the report.

6. Tell us about a barrier

If any part of a Miles Tracking map is hard or impossible for you to use, tell us. Say which page or which agency's map, what you were trying to do, and what happened. If you use assistive technology, naming it helps us reproduce the problem. A person who works on the product reads it, and a real barrier is a bug, not a feature request.

Email contact@milestracking.com. If you need any information on this page or in the report in a different format, ask at the same address and we will send it.

7. Why this is our job and not yours

ADA Title II obligations attach to your web content, including content delivered through a vendor. A rider map on your website is your web content, so an inaccessible one is your exposure. We treat conformance and the paperwork that proves it as ours to produce, which is the argument the riders page makes at length.