Designing for Everyone: Accessibility Improvements in Airline Ticketing

When I joined a startup focused on travel technology, part of the journey involved an interesting assignment: the effort to improve accessibility on their website. I knew we were about to challenge some long-standing assumptions. What I didn’t expect was how transformative the process would be—not just for the product, but for the mindset of the team behind it. Accessibility isn’t a feature you tack on at the end; it’s a philosophy that reshapes how you build, design, and think.

Starting with Empathy

Before touching a single line of code, I worked closely with our design team to build awareness around accessibility. I demonstrated how screen readers like VoiceOver and NVDA interact with our current booking flow. We navigated the site without a mouse, relying solely on keyboard and audio cues. The experience was eye-opening. What looked polished on the surface quickly revealed itself to be riddled with barriers. The team was surprised—and motivated. That moment of shared discomfort became the spark for everything that followed.

Phase One: Ditching Pixels for Relative Units

Our first technical step was to eliminate most px values across the system. We replaced them with relative units like rem and em, which scale more gracefully across devices and user settings. This change is especially important for visually impaired users who rely on browser zoom—often up to 200%—to navigate interfaces. With relative units, our layout and typography remain readable and functional, rather than collapsing into chaos.

We kept px values only where precision was essential: drawing crisp lines and defining base font sizes. Everywhere else, we embraced flexibility.

Phase Two: Contrast That Includes, Not Just Impresses

Next, we tackled color contrast. This wasn’t just a technical audit—it was a collaborative discussion between marketing, design, and front-end teams. We challenged legacy brand colors that looked great in ads but failed contrast checks in real-world usage. We introduced a new palette that balances visual identity with readability, ensuring that users with low vision or color blindness aren’t excluded.

This phase required tough decisions. But the outcome was a design system that feels intentional, inclusive, and still visually compelling.

Phase Three: Native First, Custom When Necessary

We then re-evaluated our use of custom UI components. While custom dropdowns and modals can look sleek, they’re notoriously difficult to make accessible. We decided to embrace native HTML elements wherever possible—<select>, <button>, <input type="date">, and semantic tags like <fieldset> and <label>.

This shift brought immediate benefits: better compatibility with screen readers, reliable keyboard navigation, and a more consistent experience across browsers. We still use custom elements when necessary, but only with accessibility baked in from the start.

Phase Four: Managing Focus and State with Precision

One of the trickiest challenges was managing focus and state transitions. Popups, expanded items, and dynamic components needed to communicate their status clearly to assistive technologies. We implemented proper ARIA roles and attributes to ensure that users were informed when something opened, closed, or changed context. Focus management became a discipline in itself—ensuring that users never felt lost, even when the DOM shifted beneath them.

Phase Five: Communicating Change in Real Time

Accessibility isn’t just about structure—it’s about feedback. We introduced live regions to announce changes in form status, booking progress, and error handling. We also gave users keyboard shortcuts to check the current state of their session: press P to view purchase details, press V to see registered passengers, and so on. This was one of the most complex phases, as navigating a dynamic DOM with a keyboard alone is a challenge. But it was worth it—users gained control and clarity in a space that often feels chaotic.

Phase Six: Guarding Against Regression

Once the improvements were in place, we focused on ensuring they stayed that way. We implemented automated accessibility tests, end-to-end flows, and unit checks. But we also recognized that no amount of automation can replace human intuition. Manual testing remained essential—especially for screen reader behavior and keyboard-only navigation.

The Struggle of Balancing Accessibility with Business Realities

Although interesting, revenue is still the main driver. Some design changes—particularly those aimed at users with intellectual or motor disabilities—weren’t adopted. Focus groups of users without disabilities found these versions too unfamiliar or visually unappealing. As a result, certain implementations didn’t move forward.

Still, we were proud of what we achieved in terms of visual assistance. We made meaningful progress, even if not every idea made it to production. Accessibility is a journey, and every step counts.

The Outcome: WCAG AA Certification and a New Mindset

In the end, our efforts were validated: an external accessibility consultancy granted us WCAG AA certification. But more importantly, we built a culture of inclusion. Accessibility is no longer an afterthought—it’s part of our design language, our development process, and our product strategy.

---

I've created a small demo about accessible airline ticketing. It has valuable insights/possibilities you can explore in your project. Use Voiceover/keyboard navigation to experience it fully.

I hope it can give you some insights and motivate you to hop on the accessibility revolution :)