EXPEDIA GROUP TECHNOLOGY — SOFTWARE
Responsive Accessibility Guidelines at Expedia.com
Building guidelines that keep pace with your business
If you have ever looked through the Web Content Accessibility Guidelines (WCAG) you know that it contains vital information for making your site accessible. WCAG is the result of monumental research in a variety of physical, visual, auditory, and cognitive disabilities and is the industry standard for web accessibility. Because of the comprehensive nature of the document, however, it can be overwhelming for accessibility newcomers. It can also make the task of digesting the guidelines a considerable undertaking.
At Expedia.com™️ (a brand of Expedia Group™️), in order to better assist our employees in consuming the guidelines, we created The Expedia Accessibility Guidelines (ExAG).
Here I will discuss in more detail why we made these guidelines, how it’s improved the accessibility of our site and mobile applications, and how you can apply the same methods within your own company.
Trials and Tribulations of Accessibility at Scale
Since we began our accessibility program at Expedia.com, we have faced a few obstacles that we set out to solve in 2019:
1. Our employees were relying too much on our internal Accessibility Team to understand what was required of them.
2. Members of the Accessibility Team were inconsistent in the recommendations they provided.
3. The various pages on our site and applications were not as consistent as they could be because different teams were handling accessibility differently.
Now that we are a few years into our accessibility journey, our main focus has been on how to reduce the reliance on our internal Accessibility Team. This means creating documentation and training that empower our employees, specifically our designers, developers, and testers, to own the accessibility of their products. As we started on this goal, we asked ourselves:
What kind of questions are we, the Accessibility Team, consistently receiving?
The majority of questions revolved around the exact requirements to make a specific feature accessible. When asked if they had looked at WCAG the answer was frequently that they were not able to decipher exactly what was required of them. There was so much information that they couldn’t figure out where to go to find their specific answer.
As these questions were brought to our team, we were taking turns monitoring and responding. At the time we did not have a good structure for documenting the guidance we were providing. In an effort to maintain consistency, a lot of time was spent verifying and aligning on our messaging. Because there is not always one definitive answer when it comes to accessibility there were still situations when our recommendations did not match.
Over this time, we were also finding that one of the biggest problems we were facing as an organization when it came to accessibility was consistency in the UI. Specifically, consistency between the components on a page, between the pages in a booking path, and between the paths on our website and mobile applications. WCAG is intentionally written to cover many different technologies and allows for many different ways to satisfy its requirements. This is great in that it allows you to make all websites and applications accessible, however this presents a challenge when you want to maintain consistency throughout your company.
In order to solve these problems, we set out to create our own internal accessibility guidelines that would provide our interpretation of WCAG in a way that fit our company culture and language. Our hope was that this could be a place to provide clear and concise answers to the most common questions we receive, as well as a way to make sure all teams and employees are receiving the same guidance.
Our Solution
In order to create our guidelines and determine what should be included, we started by categorizing all of the bugs we had found over the years. We categorized first by WCAG guideline. From there, each specific violation was identified. This gave us a starting list of the guidelines we wanted to include. We then used feedback from our designers and engineers to put the guidelines into sections that made sense internally. Finally, once all of these guidelines were in place, we went back through each WCAG guideline and filled in where the content was not covered.
However, we needed more than just a list of guidelines. These guidelines needed to be informative enough that a non-accessibility expert could understand them. We knew the guidelines would not be clear without first explaining the effect it can have on our users. We also knew that we wanted to provide details that were as black and white as possible. We wanted someone to easily be able to say:
Yes, this is functioning correctly in the feature I’m working on.
To round out each guideline, we wanted to provide more information to assist in meeting the requirements. This includes examples, both good and bad, tips for writing and testing the code, as well as other helpful resources.
Learnings and Opportunities
We originally released this document internally in February 2019 and in the year following it has been extremely well received. Feedback from our designers and engineers is that they now have a better understanding of WCAG itself. By putting WCAG in the context of our products, and what it specifically means for us, it became more consumable.
We have found that the number of questions our team receives about what is required to make a page or component accessible has greatly decreased. When we do receive questions, if the answer is not currently included in ExAG, we change that. It will either get added as a detail of a current guideline or we will create a brand-new guideline. Having this ability allows us to react quickly as our users’ needs change and as we learn. This is a living document that we will continue adding to with the long-term goal of it being fully comprehensive.
While we created these guidelines with our employees in mind, we hope that they can help you, as they did them. Your specific situation will likely require different guidelines. As you create guidelines for your own company consider the following:
- Who is your audience?
- What assistive technologies do you support?
- What level of WCAG do you support? Do you support any guidelines outside of that level?
- What examples from your product best demonstrate these guidelines?
- Are there specific areas where your employees need more assistance?
