Accessibility
A traveller using WAYFINDER may be stressed, in a noisy airport, on a phone, with limited battery. Accessibility here is not a checklist exercise — it is the difference between the product working and not working.
Conformance target
WAYFINDER is built towards WCAG 2.2 Level AA. Where a requirement could not be fully met, it is listed under known limitations rather than left unstated.
Keyboard support
Every interactive element is reachable and operable with a keyboard alone. The navigation menu, the language listbox, the tabbed product preview, the source disclosure panels and the whole assistance flow support Tab, Shift+Tab, Enter, Space, Escape and arrow keys as appropriate. Focus is always visible, and focus returns to the control that opened a menu when that menu closes.
Screen readers
Status changes are announced through polite live regions, so a refresh that finds new information is reported without interrupting. The language selector sets the document language, so text is pronounced in the correct language. Decorative graphics are hidden from assistive technology, and every icon that carries meaning is paired with text.
Colour and contrast
Body text, labels and interface controls meet or exceed a 4.5:1 contrast ratio against their background. Colour is never the only way information is conveyed: verified facts, recommendations, alerts and uncertain information each carry a distinct icon and a text label in addition to their colour.
Motion
Animations are short, purposeful and used to explain a change in state. The reduced-motion preference is respected: when it is set, transitions and animations are effectively removed and smooth scrolling is disabled.
Touch targets
Primary controls are at least 44 by 44 CSS pixels, and the layout is designed so that important actions remain reachable on narrow screens without horizontal scrolling.
Forms
Every input has a programmatically associated label. Help text and error messages are linked to their input, and errors explain how to fix the problem rather than only stating that something is wrong.
Known limitations
- Arabic is supported for the interface and for AI-generated explanations, but the interface catalogue is less complete for Arabic than for English. Missing strings fall back to English rather than showing blank space.
- The announcement translator depends on an AI provider being configured. When it is not, the product says so and shows the original text instead of failing silently.
- Automated accessibility testing has not been run against the deployed build. The claims above describe the implementation, and manual keyboard testing has been performed through the main flow.
Found a barrier? See the product limitations for the data-side constraints.