Designing for everyone: accessibility improvements in airline ticketing

When I joined a travel-technology start-up, one of my assignments was to improve the accessibility of its website. I knew we were about to challenge some long-standing assumptions. What I didn’t expect was how much the work would change: not only the product, but the way the team behind it thought. Accessibility isn’t a feature you add at the end. It reshapes how you design, build and think.

Starting with empathy

Before touching a line of code, I worked with our design team to build awareness. I showed how screen readers like VoiceOver and NVDA handled our booking flow, and we went through the site without a mouse, relying on the keyboard and audio alone. It was eye-opening: what looked polished on the surface turned out to be full of barriers. The team was surprised, and motivated. That moment of shared discomfort started everything that followed.

Phase one: relative units instead of pixels

Our first technical step was to replace most px values with relative units like rem and em. Many people with low vision set a larger default text size in their browser. Type set in px ignores that setting; type set in rem follows it. Layouts sized the same way grow with the text instead of breaking around it, and stay usable when people zoom in.

We kept px only where precision mattered, such as crisp lines and borders. Everywhere else, we chose flexibility.

Phase two: contrast that includes, not just impresses

Next came colour contrast. It wasn’t only a technical audit but a conversation between marketing, design and front-end. We challenged legacy brand colours that looked great in ads but failed contrast checks in real use, and introduced a palette that balances the brand’s identity with readability, so people with low vision or colour blindness aren’t left out.

It took some tough decisions. The result was a design system that feels intentional, inclusive and still visually strong.

Phase three: native first, custom when necessary

We then took a hard look at our custom components. Custom dropdowns and modals can look sleek, but they are notoriously hard to make accessible. We chose native HTML wherever we could: <select>, <button>, <input type="date">, and semantic elements like <fieldset> and <label>.

The benefits were immediate: better screen reader support, reliable keyboard navigation and a more consistent experience across browsers. We still build custom components when we need to, but with accessibility designed in from the start.

Phase four: managing focus and state

One of the trickiest parts was focus and state. Pop-ups, expanding items and other dynamic components had to tell assistive technologies what they were doing. We added the right ARIA roles and attributes, so people were told when something opened, closed or changed. Focus management became a discipline of its own: making sure nobody felt lost, even when the page changed underneath them.

Phase five: communicating change as it happens

Accessibility isn’t only about structure; it’s about feedback. We added live regions to announce changes in form status, booking progress and errors. We also gave people keyboard shortcuts to check the state of their session: P for the purchase details, V for the registered passengers, and so on. Single-key shortcuts need care: speech-input users can set them off just by talking, and screen reader users already move around a page with single letters. So, as WCAG asks, people could switch them off, or remap them to a key combination. This was one of the most complex phases, because moving through a page that keeps changing, with a keyboard alone, is hard. It was worth it: people gained control and clarity in a process that often feels chaotic.

Phase six: guarding against regression

Once the improvements were in place, we made sure they stayed. We added automated accessibility tests, end-to-end flows and unit checks. But no amount of automation replaces people: manual testing stayed essential, especially for screen reader behaviour and keyboard-only navigation.

Balancing accessibility with business realities

However interesting the work, revenue still drove the decisions. Some changes, particularly those aimed at people with intellectual or motor disabilities, weren’t adopted: focus groups of people without disabilities found those versions too unfamiliar or unappealing, so they didn’t go ahead.

We were still proud of what we achieved in visual accessibility. Not every idea reached production, but the progress was real. Accessibility is a journey, and every step counts.

The outcome: WCAG AA and a new mindset

In the end, an external accessibility consultancy audited the site and confirmed that it met WCAG AA. More importantly, we built a culture of inclusion. Accessibility stopped being an afterthought and became part of our design language, our development process and our product strategy.

I built a small demo of accessible airline ticketing that shows some of these ideas. Try it with VoiceOver or the keyboard alone to get the full experience. I hope it gives you ideas for your own projects, and a reason to start.