How accessible this service is
We want as many people as possible to be able to use this service. It is built and tested against the WCAG 2.2 AA standard.
What we do to keep it accessible
- Every page works without JavaScript. Booking, amending and cancelling are plain server-rendered forms. Scripts only make them smoother, so a blocked, failed or slow script never removes a way to do something.
- Everything is reachable by keyboard. Every control is a real button, link or field, focus is always visible, and focus is restored to the control you used after a page updates in place. Where the interface offers dragging — reordering questions on a form — the same thing can be done with the arrow keys or a labelled button.
- Colour contrast is tested in both light and dark themes. Text contrast is checked automatically against every background it can appear on, in both themes, on each change. Where a project sets its own brand colour, a separate readable shade is derived for text rather than using the brand colour directly.
- Automated checks run on every change. The axe accessibility engine runs against the booking flow, the attendee pages, the help library and the admin console — in both themes — and a failure blocks the change.
- It works on a phone. Layouts are tested at phone, landscape-handset and desktop sizes. Data tables become stacked cards on small screens rather than scrolling sideways, and touch targets are enlarged for touch input at any screen width.
- Forms explain what went wrong. Validation happens on the server, so it cannot be bypassed. Errors appear in a summary at the top of the form, linked to each field, and focus moves there. Fields that ask for your own details tell the browser what they are, so they can be filled in for you.
What is not accessible yet
We are not aware of any part of this service that fails the WCAG 2.2 AA standard. That is not the same as there being nothing to find — what our testing does and does not cover is described under how we tested this service.
How we tested this service
Automated accessibility checks run against the booking journey, the attendee pages, the help library and the administrative console — in both the light and dark colour themes — every time the service changes, and a failure stops that change from being released. Keyboard-only operation is tested the same way.