Accessibility Statement

Transit information is public information. A rider who uses a screen reader, navigates by keyboard, enlarges text, or needs strong contrast must be able to find out when the bus comes. We design and test our software so that transit agencies can publish route information everyone can use. That is a requirement of the product, not a feature of it.

We aim to meet WCAG 2.1 Level AA across the rider-facing pages RoutePress generates and the dashboard your staff use. WCAG 2.1 Level AA is the standard the Department of Justice's 2024 Title II rule adopts for public entities, and it fully contains the WCAG 2.0 AA that Section 508 incorporates.

Accessibility should be demonstrated, not simply claimed. Automated testing runs as part of every release, so the rider-facing pages stay accessible as the product changes, and we would rather show you the method than assert a result.

• An automated accessibility checker, every change. Every change is tested with Google Lighthouse, which uses the industry-standard axe-core accessibility engine. We test both kinds of page RoutePress produces (the route pages you embed and the System Map), and at the time of this statement both score 100, with no failing automated check.
• Keyboard operation, driven in a real browser. Automated checks are supplemented with browser-based keyboard testing. A second suite opens the rider pages in Chrome and verifies they can be operated using only the keyboard: Tab navigation, arrow-key navigation, Enter and Escape, and opening and moving through route and stop content.
• Contrast measured, not eyeballed. Every text and background colour combination is evaluated automatically against the standard's contrast requirements during testing, which stops a later design change from quietly introducing insufficient contrast.
• Colours from your feed are computed, not chosen. Route colours come from each agency's GTFS data. Rather than picking badge text colours by hand, we calculate a contrasting one for every route badge.

An automated checker identifies many common issues but cannot evaluate every aspect of accessibility: no tool can judge whether a label is meaningful, whether an instruction is clear, or whether content is organised in the most understandable way. For that reason a clean run is evidence, not a certificate. RoutePress has not been audited by an independent third party, and we would rather tell you that than imply a certification we do not hold. We evaluate and improve accessibility continuously as part of building the product, and we will update this statement as our testing practices evolve.

Accessibility is built into every rider-facing page RoutePress generates. Today that means:

• Timetables are real tables. Each stop is a proper column header, so a screen reader announces which stop a time belongs to instead of reading a grid of numbers without context.
• Pages carry meaningful landmarks and headings. Each page has a main landmark, a real page heading, and clearly labelled regions for the map, the timetable, the route summary and the service alerts.
• The page language is declared so screen readers use the correct pronunciation rules.
• All page controls are keyboard accessible. Direction selectors, day selectors, timepoint toggles and alert controls are real buttons, reachable in a logical order, drawn with a visible focus indicator, and they communicate their current state to assistive technologies.
• Stops can be selected from the keyboard. Every stop column heading is a button. Riders move between stops with the left and right arrow keys, open a stop's details with Enter, and close them with Escape. A wide timetable can also be scrolled sideways from the keyboard.
• Changes are announced, not just shown. Selecting a stop updates a card elsewhere on the page, and the page announces that through a status region. A screen reader hears which stop was selected without having to go looking for the change.
• Nothing is available only on the map. An interactive map is never the only way to reach information: every stop, time and service alert drawn on it is also present in the timetable, the stop list and the alerts card, all of which a screen reader can read and a keyboard can operate. Map controls such as zoom and compass are standard keyboard-accessible buttons.
• Accessible names match visible labels. Every control's spoken name contains the words printed on it, so someone driving the page with voice-control software can say what they see and have it work.
• Contrast is verified by measurement. Every text and background pair in the page design is checked against the standard's ratios automatically, so a later design tweak cannot quietly drop below them.
• Route badge text is calculated for readability. We analyse each agency's route colour and automatically select black or white text for whichever gives the stronger contrast.
• Motion is restrained and respectful. Rider pages carry a single animated element, the live-data indicator, and it stops animating for anyone whose browser asks for reduced motion.
• Pages support zoom and text scaling. Responsive layouts and relative sizing let content reflow without clipping or loss of functionality.
• No barriers to access. Riders need no account, no mobile app and no cookie consent to reach schedules, maps or service information.

Most of this is handled automatically by RoutePress, but some content comes directly from your agency and stays under your control. We would rather name those parts than let you discover them in a review.

• Content you supply passes through unchanged. The printable PDFs you link to, your logo, your badge images and the wording of your manual service alerts are yours, and we display them without modifying them. A PDF that is only a scanned image does not become accessible by being linked from an accessible page. Wherever possible, provide a searchable, text-based one.
• Route colours come from your feed. We compute readable badge text for any colour you publish, but we cannot stop two routes from being given colours that are hard to tell apart, or a line colour that reads faintly against the basemap. If you would like guidance on choosing an accessible route palette, we are happy to help.

And if you hit something we have not named here, please tell us. That is more useful to us than a polite silence.

Transit agencies generally have their own legal obligations: the Americans with Disabilities Act, Section 508, and often state or local requirements. RoutePress pages are embedded in your website, so your site as a whole is what gets assessed: your navigation, headings, and surrounding content matter as much as our embed does.

If you are answering an accessibility review, a procurement questionnaire, or a VPAT request, write to us. We will answer specific questions about how the embed behaves rather than send you a boilerplate claim.

If any part of RoutePress is difficult or impossible for you to use, we would like to hear about it. Email hello@getroutepress.com. If you can, include:

• The page you were visiting
• What you were trying to do
• Your browser and operating system
• Any assistive technology you were using, such as a screen reader or voice control

If you cannot give us all of that, do not worry. Write to us anyway, and we aim to reply within five business days.

Accessibility reports go to the front of the queue. If a rider cannot read a schedule, that is a defect, and we treat it like one.

See also our Privacy Policy and Terms of Service, and the FAQ for how the product works.