This accessibility statement outlines the principles, processes, and tools we use at WAYA to ensure our products are inclusive and usable by all users, including those with disabilities. Our goal is to deliver a consistently accessible experience across our platforms, aligning with the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA.

Why accessibility matters

At least 1 in 5 people in the UK reports having a disability. At WAYA, we believe accessibility is a fundamental human right and a core part of delivering great digital products. Whether someone is booking a flight using a screen reader, navigating by keyboard, or dealing with temporary limitations such as a broken arm or low lighting, we want every user to find and book flights easily.

Accessibility by Design

Integration into our Design system

We embed accessibility best practices directly into our design system. Each component and page follows a standardised Accessibility Checklist, reviewed during the design phase. This checklist ensures we consistently address:

• Colour contrast and use of colour

• Text alternatives for images and icons

• Focus management and logical tab order

• Accessible form inputs and error handling

• Clear, simple language

• Responsive and scalable layouts

• Avoidance of motion or animations that cause harm (e.g., seizures, nausea)

Designers are responsible for verifying that these considerations are met and documented before handoff to developers.

Development accessibility practices

Linting and static checks

We use eslint-plugin-jsx-a11y in our codebase, which flags accessibility violations like missing aria attributes, unlabelled buttons, or improper heading order during development. This ensures issues are caught early, as part of every pull request.

End-to-end testing pipeline

We integrate automated accessibility testing into our e2e (end-to-end) pipeline using:

• @axe-core/puppeteer for component-level and UI flow validation

• Cypress tests, enhanced to detect EAA (European Accessibility Act) violations

• Regression checks to ensure accessible behaviour isn't broken during updates

Code reviews

When developers review pull requests, they need to

• Test using keyboard only

• Test using screen reader

• Check colour contrast with Axe devtools

• Zoom in 200%

Testing accessibility

Testing tools

The team uses a variety of tools to validate accessibility at different phases:

• Browser extensions

• WAVE

• Axe

• Lighthouse

• Browser DevTools

• Chrome and Firefox Accessibility tabs

• ARIA live regions, role inspection, and keyboard focus

Manual testing

We complement automated tools with manual checks, including:

• Keyboard navigation testing (Tab, Shift+Tab, Enter, Escape)

• Screen reader testing (VoiceOver, NVDA, or TalkBack depending on platform)

• Colour contrast verification using real hardware

• Testing in high contrast and zoomed display modes

Auditing and continuous improvement

Independent audits

We commit to regular accessibility audits by certified third-party auditors every 6 months. These audits include:

• WCAG 2.1/2.2 and Level A-AA conformance assessment, including:

• Perceivability – ensuring non-text content, captions, colour use, and relationships are available to all users.

• Operability – supporting full keyboard navigation, preventing keyboard traps, and ensuring input methods are accessible.

• Understandability – maintaining clear structure, meaningful labels, and predictable interactions.

• Robustness – ensuring compatibility with assistive technologies and different user settings.

• Assistive technology testing

• User testing with people with disabilities

• Actionable reports and recommendations

Results are documented and prioritised in our accessibility backlog for resolution.

Feedback channels

We actively encourage user feedback and provide a dedicated accessibility contact through our parent company, Dohop, at accessibility@dohop.com.

Any accessibility-related complaints or barriers are investigated promptly.

Training and team responsibility

Accessibility is a shared responsibility:

• Designers ensure every interaction is intuitive and usable from the beginning.

• Developers enforce technical accessibility standards in implementation.

• Product Owners champion accessibility as a business and user need.

• Customer Support escalates user-reported barriers to the product and accessibility team.

Governance and roadmap

Our accessibility lead works with cross-functional teams to:

• Maintain accessibility documentation and processes

• Review audit outcomes and oversee remediations

• Champion accessibility in new initiatives

Summary

WAYA is committed to building accessible, inclusive digital products. Through checklists, automated tests, audits, and a culture of shared responsibility, we aim to meet and exceed accessibility standards to support all travellers, regardless of their abilities.