Accessibility statement

What has been done

On gowalkable.app:

• One heading outline per page. Every page has exactly one h1, and sections below it use real heading elements in order, so a screen reader’s page summary matches what a sighted reader sees.
• Semantic structure. Navigation, main content and footer are landmark elements; breadcrumbs are a labelled nav; lists are lists and tables have header cells.
• Keyboard focus. Links and buttons are real links and buttons, so they are reachable and operable with a keyboard. The main call-to-action and the screenshot carousel draw an explicit focus ring; text fields and selects replace the browser outline with a visible border-and-ring of their own.
• Reduced motion is honoured. When your system asks for less motion, the background transition, the pulsing loading placeholders and the looping decorative animations stop. The walking-footsteps animation checks the same setting before it starts.
• Contrast-aware theming. Light and dark are two full colour palettes rather than a filter, chosen so that reading text keeps its contrast in both, and the theme follows your system setting until you pick one.
• Text alternatives. Meaningful images carry alt text — the app screenshots describe what the screen shows, and a shared route’s QR code says what it links to. Decorative icons and ornaments are hidden from assistive technology rather than read out as noise.
• Labelled controls. Buttons that are only an icon carry a text label for screen readers, and form fields are tied to their labels.
• The page language is declared, and it is corrected when you change the language with the site’s picker, so a screen reader pronounces the page with the right voice.
• Text scales. Layouts are built with relative units and reflow rather than fixed pixel frames, so browser zoom and a larger default font size do not clip the content.
• No motion-triggered surprises. Nothing auto-plays with sound, nothing flashes, and there are no interstitials or timed pop-ups.

What has not been audited

This is the honest half. None of the following has been tested, and some of it we already know is imperfect:

• No formal audit, and no conformance claim. Nobody has run this site against WCAG 2.1 or 2.2 at any level, and no external review has been commissioned. We do not claim a level we have not measured.
• No screen-reader testing. The site has not been walked through with NVDA, JAWS, VoiceOver or TalkBack. The semantics above are written correctly as far as we can tell by reading the code, which is not the same as being usable in practice.
• The screenshot carousel on the home page advances by itself and does not currently stop when your system asks for reduced motion. It can be driven with the previous and next buttons, but the automatic movement is a real gap.
• Focus indication is not uniform. Some fields in the route creator show focus only as a change of border colour, which is weaker than it should be, and the site has no single global focus style.
• Maps are visual. The route maps, the live-follow view and the offline map picker convey their information by drawing it. There is no equivalent text description of a route’s shape yet.
• Colour contrast has been designed, not measured. The palette was chosen with contrast in mind in both themes, but the ratios have not been tested systematically, especially for smaller and softer secondary text.
• The interactive surfaces are least tested. The Community composer, the support chat and the route creator involve dialogs, live regions and drag interactions, and none of that has been checked with assistive technology or by keyboard alone.
• The Android app has not been audited either. We have not tested Walkable with TalkBack, with large display and font sizes, or with switch access. Android’s own accessibility settings apply to it as they do to any app, but we cannot tell you how well it behaves under them, so we will not pretend to.
• Some parts of the site are English only. The legal pages, including this one, are not translated, while most of the site is available in eleven languages.

One thing worth saying plainly

Walkable plans routes from map data. That data records some things about a path and not others, and it very often does not record whether a route has steps, a kerb, a barrier, a rough surface or a gradient you could not manage. A route the app suggests is therefore not a claim that the route is accessible to you. We would rather say that than let the omission imply otherwise.

Telling us about a barrier

Email Automat4ed@gmail.com with the subject Walkable accessibility. It reaches a person, not a form.

What helps us reproduce it, if you have it to hand:

• the address of the page, or which screen of the app;
• what you were trying to do, and what happened instead;
• the assistive technology, browser or device you were using, and any relevant setting — text size, zoom level, reduced motion, high contrast.

None of that is required. “This page does not work with my screen reader” is a perfectly good message, and we will ask for the rest if we need it. We read every one, and we will tell you what we can and cannot fix rather than letting it go quiet.

If you would rather use the in-app or on-site help, Support reaches the same place.