Different types of people use the Internet to travel, but not all of them interact with travel sites the same way. Accessibility paves the way to a more inclusive online world. This poses a distinct challenge to developers.

Here’s our story on making our travel app accessible.

Understanding the Problem First-Hand

When my team decided to take accessibility head on we didn’t know where to start.

To better understand the problem, the first thing we did was to interact with the website with our eyes closed and using Mac’s Voice Over.

It was a nightmare.

I had no idea what was going on. I didn’t understand what the screen reader was doing. There was no fluid interaction between me and the application, even though I knew it by heart.

This is a troublesome reality to face for a development team.

Adding accessibility after the fact was going to be a very daunting task.

What We Didn’t Know that We Didn’t Know

We started to learn how blind people use the Internet and interact with their devices. Here’s a great video that explains this.

We started using Chrome’s aXe tool extension to find any outstanding problems in our application. Some color changes were made, some tags were changed to the HTML.

aXe recommended that we add aria-labels, but we didn’t even know what that was. We looked into ARIA, the website for Accessible Rich Internet Applications. It has a bunch of recommendations on making apps accessible, including,

  • Guidelines on how we should manage the tab index in our website.
  • HTML tags that the screen reader can understand.

Making Our Travel App Accessible

We had to upgrade our headers. Some used the <h#> tag and others were made to look like headers with brute force CSS. Instead, we used the aria-header attribute. This allows screen readers and other assistive technology to understand and tell the user it is a header.

Here’s a list of attributes you can use for ARIA purposes.

Another helpful thing was adding the right role to different elements. Our app allows for a lot of interaction. For example, we have cards showing the user’s loyalty program for several airlines. A user can click on any of these cards and see more details on their account. They can also take different actions, like using their loyalty points to make a purchase.

Unfortunately, these cards are not an HTML button. The assistive technology therefore doesn’t know that it can be clicked, and the user can’t access it. What a bummer.

To solve this, we added a role=”button” to the element and, voilà, we have a button. Here’s a list of roles you can use, with the attributes you can use them with.

As the research went on, the application started coming together to be fully usable with keyboard navigation and screen-readers.

And that’s when the real problems started.

Difficult Decisions on Accessibility

Design problems weren’t the only issue. There were several difficult technical aspects as well.

We had never made accessible sites before and we spent a lot of time researching what to do and how to do it. The learning curve was steep.

The way we had set up the application included modals, notification banners, sidebars, and other elements. They ranged from difficult to painful when it came to making them accessible.

Notification Banners

For example, with the notification banners, we needed to alert the user and read the banner. And we needed to keep the interaction smooth


In the case of the sidebar, we wanted to keep the focus on it when it’s open and make it possible to tab over all menu options. However, making this work in modals and sidebars took quite some time.

We were also unsure whether to make the user tab over to an icon in order to close the sidebar or to close by using the escape key.


Think of a case where there is a timer on the screen. The user needs to complete the purchase of a ticket in five minutes. How do you make that timer accessible for people who can’t see it?

Seat Assignments

When choosing a seat, the J row may be in the back of a small plane, but in the middle of a large one. On other planes there are A, C, D, and F seats, with no B or E seats. Visually it’s simple to figure that out, but it also needs to be made accessible.

There are many elements that are so intuitive for sighted people and very much an obstacle for the visually impaired. It’s only when we use the app with assistive technologies that we realize that maybe our UX design is missing something.

Even after spending a couple of months working on making our apps accessible, we were audited and were found lacking. We missed some major stuff due to our lack of experience.

We continue to work on fixing all of these issues.


On top of it all, we needed to make sure that the code worked in different browsers. Unsurprisingly, things that work well for VoiceOver on Chrome didn’t work so well on Firefox or Android.

Our Test Engineer found several tricky bugs that had us slamming our heads against a wall.

Think of Accessibility from the Start

Applications should be designed from the start with accessibility in mind. The design should be intuitive for those who depend on assistive technologies.

Developers need to work with the ARIA guidelines from the very beginning.

In some countries, travel-related services are legally required to be accessible.


This has been a growing experience for me personally. I am more empathetic towards those who require accessibility tools to interact with the Internet. I think that these users will appreciate the effort to provide an enjoyable experience for them.