My Process on Improving the Accessibility of Hipmunk ✈︎

For Foo Week, I planned to work on a topic untouched on our site, accessibility.

Accessibility Island

I was unaware about web accessibility for a while. During the time I learned web development and worked as a web developer, accessibility had not crossed my mind. I am confused as to why it took so long to crop up, but when it finally did, I felt as I do now, that it’s important for a web site to be usable by all users.

I wasn’t sure how to limit the size of this project so it could be accomplished in the time afforded by Foo Week. I initially chose to tackle the Chrome accessibility audit score. Simply improving a test result number didn’t feel sufficient in making a site accessible, but it was a gateway goal to better understanding accessibility. It’s like judging a prospective college student on only their SAT score. There’s more to the person, and there’s more to accessibility. I wanted to understand the experience of a person approaching a site with a screen reader. I needed to learn how to use a screen reader.

The VoiceOver screen reader is natively available with Apple laptops and phones, reported to be the most popular for Apple users, and I work on an Apple laptop, so this seemed like the most effective option. To use the screen reader, I took the VoiceOver training provided natively on my Apple computer. When I opened the Hipmunk homepage with the screen reader on, I heard everything.

Annoying Screen Reader

Out came a flood of words spoken in a computer voice. The screen was being read. This was overwhelming because I am accustomed to taking in input visually. To use my computer, the internet, I look at the screen, preferably in silence. I prioritize what’s important based on the size, color, and position of the words, images, icons, animations, and videos. However, for those of us who are unable to decipher any or all of these properties or objects, a screen reader may be able to assist. I say “may” because it’s not a guarantee. The way the web site is written plays an important role in how helpful a screen reader can be. When I learned of this, I added another goal, I wanted to make our website usable with a screen reader.

Next I thought about what were the minimum parts of the site for it to be usable. I had a week, so minimum was a good goal. I narrowed it down to the fewest pieces for a flight search. The user starts their path for a search on the homepage. Here, the search form needed to be the most accessible. Once the search form is submitted, the user is taken to a page where the flight options will be displayed. There is an intermediate step between searching for flights and seeing results, and this is waiting. Waiting is visually conveyed in many ways on a site. For Hipmunk, it’s a dancing chipmunk. I needed non-visual ways to tell the user to wait, and when they could begin using the site. Then the last stop on the user’s path was choosing a flight. What are the most important things to know about a flight in order to make a decision? At this point, I had what I needed to test with the screen reader.

VoiceOver has a shortcuts menu to help a user navigate and jump to certain elements, like a table of contents for a site. Inside the VoiceOver menu there are sections for Headings and Links, among other things, which point to these types of elements on the screen. A screen reader reads a web site by reading its HTML. When I was on the homepage with the screen reader, I couldn't find the search form on the menu, just pieces of it. I searched for techniques and learned about ARIA (Accessible Rich Internet Applications), a way to write accessible HTML. ARIA is a set of attributes that a screen reader recognizes and uses to describe an element on the screen. Recall that the menu options Headings, Links, etc. correspond to HTML tags, so the screen reader knows how to read HTML without ARIA attributes. This is a good reason to write semantic HTML and not just divs dressed up as headers, buttons, etc.

Just Put a Div on it

There is a way to describe the hierarchy of importance on a screen through the ARIA “role” attribute. A role helps define the element’s purpose when a semantic HTML tag does not suffice. There are a subset of values for this role attribute that are classified as landmark roles and screen reader users can use landmarks to navigate a site because it appears in the shortcuts menu. With this information, I could make the search form the most accessible by giving it a landmark role. This would convey its importance to a user visiting Hipmunk for the first time, and make it easier to find for returning users.

The next step in the user’s search is waiting for results. I needed a way of indicating this without visuals. Again, ARIA had a solution for this through the “alert” role. This role tells the screen reader to announce a designated text without waiting for the user to focus on this element. Like a notification, it speaks up without being prompted. To indicate the results were ready for browsing, an element with the alert role attribute could be added to the page, which the screen reader would read out. Finally and most importantly, the flight option needed to be described. The "aria-label" attribute, which is read when a user focuses on the element via keyboard or mouse, could be used to create a summary of flight details like time, airlines, and price. Each flight option had an element holding this aria-label which was made focusable, so the user could tab through the list of results and be read the flight summary for each.

Trying to only use the information spoken to me by the screen reader, I attempted to find a flight. I followed the steps of filling out the search form, waiting for results to load, browsing through the flight options, and selecting one to book. At the end of Foo Week, I was able to choose a flight, but the real decider of success will be user testing. Hopefully, now a user with a screen reader can use our flights product.