Our approach
Useful access information, trail by trail.
“Accessible” is not a single yes-or-no label. We want players to understand the actual route, interaction and venue requirements before deciding whether an experience works for them.
What we plan to publish
Specific details for real routes.
Each trail will be reviewed individually. Information will be updated when routes, waypoints or recommended venues change.
Surfaces and movement
Distance, gradients, steps, kerbs, cobbles, narrow sections and step-free alternatives.
↗Places to pause
Seats, rest opportunities, accessible toilets and useful nearby facilities.
↗How clues are experienced
Audio, visual, reading, dexterity and environmental requirements.
↗Access beyond the pavement
Separate information for pubs, attractions and other suggested stops.
↗Designed, tested, improved
Accessibility should shape the route.
We intend to consider access while experiences are being designed—not add a vague accessibility statement after the route is finished.
Some historic streets and venues can present barriers that the app cannot remove. Where that happens, trail pages should explain the limitation plainly and identify alternatives where possible.
Digital access matters too
The website has been built with semantic headings, keyboard-accessible navigation, visible focus styles, reduced-motion support and responsive type. The app’s own interaction requirements will be described separately as the product is tested.
Help us improve
We want future reviews to include people with lived experience of different access needs. Contact and feedback details will be added before public testing begins.
Work in progress
No blanket promises.
Until a route has been reviewed, its page will say that access information is still in progress. When details are known, we will publish them where they are most useful: beside the trail itself.