a11y: The Path to Ensuring Web Accessibility

Michael Alterio
priceline labs
Published in
9 min readOct 1, 2019

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect” — Tim Berners-Lee, W3C Director & inventor of the World Wide Web

Here at Priceline, our mission is to be the “best travel dealmakers in the world.” In order to do that, we put our customers at the center of everything we do, ensuring they get the very best deal, so they can experience the moments in life that truly matter. This goal is achieved through our commitment to ALL types of customers. With that in mind, Priceline has software engineers, as well as product managers and UX designers, working to ensure that our applications are accessible and easy-to-use for travelers with disabilities. In today’s global and ever-changing society, web accessibility is key, and Priceline is putting this objective at the forefront.

Defining Web Accessibility

Web accessibility, which is often abbreviated as the numeronym “a11y,” focuses on removing obstacles that often arise when persons with disabilities interact with web applications. Users who have disabilities interact with day-to-day tasks differently than those who do not, and thus interact with websites differently through the use of various devices known as assistive technologies (AT).

When developing a webpage, it is easy to make the assumption that all users will interact in the same way. However, this is often not the case. Importantly, users with disabilities interact with websites, and even the computer itself, differently than those who do not have a disability. Not all users can see and use a keyboard, mouse and/or touch screen. Making this assumption can lead to an experience that works well for some, but creates issues that range from simple annoyances to challenges for others, which ultimately makes the website inaccessible.

In order to solve this problem, it is necessary to create a POUR website which is accomplished by focusing on the four guiding principles of accessibility, for which it gets its abbreviated name: (1) perceivable information and user interface; (2) operable user interface and navigation; (3) understandable information and user interface; and (4) robust content and reliable interpretation. If websites are well designed and implemented in line with these principles and accessibility rules, which are outlined in Web Content Accessibility Guidelines (WCAG) 2.0, then there is a greater chance that content and functionalities will be accessible for all.

Now that we understand the definition and principles of accessibility, we next must shift our focus to the challenges faced on the web by persons with disabilities (visual, auditory, motor and cognitive), as well as the different solutions we can implement to creating accessible websites.

Four Categories of Disability — Challenges & Solutions

1. Visual (Low Vision, Color-Blindness & Blindness)

Low Vision: Users with low vision impairments generally have difficulty perceiving content that is small, does not enlarge well, or does not have sufficient contrast. To see content more clearly, low vision users typically use a screen magnifier — an assistive technology that gives users the ability to zoom in on a small area of the screen. A solution to making text more legible on our applications when enlarged, is to use true text as much as possible. Furthermore, sites with low contrast can be difficult to read for people with low vision. In order to combat this problem, we must maximize the contrast of our webpages including graphics, fonts and backgrounds to at least 4.5:1 in most cases. (Learn more about Contrast and Color Accessibility)

Color-Blindness: Since color-blind users have difficulty perceiving the difference between certain color combinations, a solution is to ensure that colors are not the only method of conveying important information.

Blindness: For blind users, a computer monitor and mouse are not very useful. As a result, keyboard input is used as the primary means of navigation. Developers must ensure all webpage content and functionality are accessible via the keyboard. This is accomplished by adding keyboard event handlers.

Additionally, we must make specific modifications to HTML elements in order for screen reader technologies to identify and process content. Screen readers convert text into synthesized speech so that blind users are able to listen to web content. When implementing accessibility support for screen readers, there are many principles and checkpoints to consider. Below are just a few of these with examples of where Priceline has had success:

  • Declare language of document (e.g. <html lang="en">) — lets screen readers load the proper pronunciation rules and allows visual browsers to display characters more accurately
  • Provide text descriptions, in alt text, for images and graphics
  • Ensure link text makes sense out of context (e.g. word content in such a way that the link text describes the destination of the link)
  • Enable elements to receive tab focus by adding tabindex
The use of tabindex has already been successfully implemented on Priceline’s Rental Car checkout application. As seen above, we added tabindex to links and buttons to ensure keyboard focusability in a sequential order.
  • Add screen reader only content when needed — information hidden from the UI, but available only to screen readers (e.g. reusable React component that uses CSS to place elements offscreen)
Priceline’s design-system team has also already created a React component named <SrOnly>. This component is a wrapper that takes its children and places them offscreen. As a result, this content will be read out by a screen reader, but not visually displayed on the UI. (View SrOnly Component)
  • Use ARIA roles, states and properties

What is ARIA?

Accessible Rich Internet Applications, oftentimes referred to as WAI-ARIA or simply just ARIA, allows us to apply specific attributes onto HTML elements, which then modify the way those elements are translated in the Accessibility Tree. The Accessibility Tree, a structure produced by platform Accessibility APIs, is a subset of the DOM tree and exposes accessibility information to assistive technologies, such as a screen reader, based on element semantics and their affordances (e.g. this is an interactive button or just a generic group).

To be clear, ARIA does not modify element appearance or behavior, nor add focusability or keyboard event handling. What ARIA does do, however, is the ability to:

  • Add semantics (to elements where no native semantics already exist)
In the above example, we have a custom checkbox element (created using a <div>, which has no built-in semantics). We can use ARIA to modify the <div> role to ‘checkbox’ and state to checked. By adding these semantics, a screen reader will understand this element is a checkbox (instead of a generic group element) and output to the user the checkbox name and state.
  • Modify semantics (e.g. change <button> role to role switch)
  • Add extra labels and descriptions (e.g. <button> element that has no text, only image — use aria-label to provide more descriptive text)
  • Express more UI patterns
  • Express semantic relationships between elements (e.g. “this element over here controls that element over there” — use aria-describedby)
  • Announce live updates (e.g. inform screen readers right away when dynamic content is changed — use role="alert"or aria-live)

(Learn more about ARIA)

2. Auditory

For people with auditory disabilities, multimedia and audio-only content pose a challenge. These include people with mild or moderate hearing loss in one or both ears (“hard of hearing”) to substantial and uncorrectable hearing loss in both ears (“deafness”).

While video content can be used to communicate information visually, audio content needs to have alternatives, such as transcripts and captions. For users with auditory disabilities to perceive content, we must provide both captions and transcripts for multimedia content and provide transcripts for audio-only content.

3. Motor

A motor-skill disability is defined as any disability that affects one’s ability to utilize fine-motor skills, such as making small movements. Motor-skill disabilities can also affect a person’s ability to walk, control hand movements, maintain a steady posture, etc. Assistive technologies for people with motor disabilities may include: a mouth stick, head wand, switch access, sip-and-puff, trackball mouse, adaptive keyboard, eye-tracking and voice recognition software.

When it comes to web accessibility, motor-skill disabilities present a number of specific challenges — such as difficulties with utilizing or controlling the mouse and making accurate keystrokes. Accordingly, it is essential that we make our websites keyboard accessible for those living with motor-skill disabilities.

It’s also important to be aware that while some users may still be able to use either the mouse or keyboard, they may not necessarily be able to control either of these devices with a high level of precision. Therefore, it’s also a good idea to ensure that forms are tolerant of any errors, such as submission errors, data entry errors and the like.

4. Cognitive

Of the four categories, cognitive presents the greatest challenge for web accessibility as it covers a large spectrum of conditions that may be momentary, temporary or permanent. This includes people with Alzheimer’s disease, senility or dementia, intellectual and learning disabilities, depression and schizophrenia, attention deficit hyperactivity disorder (ADHD) and autism disorders.

Even though cognitive impairments present themselves in various ways, people with cognitive disabilities generally share common challenges when it comes to interacting with the web. These challenges include trouble understanding content, forgetting to complete specific tasks and general confusion caused by inconsistent web page layouts.

In order to address the many challenges to web accessibility presented by the various cognitive disabilities, focus should be put on the cognitive skills themselves — attention, memory, perception, language, problem-solving and comprehension. Best practices include:

Consistency

  • Create clean, well-organized and uniform designs (e.g. use consistent fonts, colors, buttons and links; implement consistent navigation)

Focus & Structure

  • Avoid distractions (e.g. remove unnecessary advertisements or sponsored links; adhere from using unusual fonts and animations; avoid clutter by including sufficient white space)
  • Organize content into well-defined groups (e.g. use proper headings and lists; ensure logical reading order; avoid lengthy scrolling; use shorter, multi-step forms)

Readability & Language

  • Use appropriate and simple language (e.g. expand abbreviations; avoid colloquialisms and jargons)
  • Use correct grammar and spelling
  • Ensure text readability (e.g. be careful with line height, letter spacing and font sizes/types)

Orientation & Error Prevention/Recovery

  • Give users control over time-sensitive content
  • Implement clear and accessible form error messages
  • Use underline for links only
  • Allow critical functions to be confirmed and/or canceled/reversed

By taking the above recommendations into consideration for users with cognitive disabilities, we will ultimately improve access for everyone. (Learn more about Cognitive Web Accessibility)

Importance of Creating Accessible Websites — Travel, Business & Social Influences

Besides being a socially responsible company, why should web accessibility matter to Priceline from a business standpoint? According to the World Health Organization (WHO), about 15% of the world’s population live with some kind of disability. In relation to Priceline’s specific customer base, a 2015 study by the Open Doors Organization (ODO) found that more than 26 million people with disabilities traveled for business or pleasure in the previous two years, taking more than 73 million trips. Furthermore, U.S. adults with disabilities spend approximately $17.3 billion annually on their own travel. This is a robust segment of the overall travel industry. By ensuring our applications are accessible, we are opening up the opportunity to engage a much a larger market and more potential for the acquisition of new customers.

Not only does making our web applications more accessible present opportunities in profitability, it also aligns with other best business practices. These practices include mobile web design, device independence, multi-modal interaction, usability and search engine optimization (SEO). In this regard, case studies show that accessible websites have better search results, reduced maintenance costs and increased audience reach, among other benefits.

Finally, there is a strong moral argument to support accessibility: guaranteeing universal access to our services is simply the right thing to do. Accessibility supports social inclusion for people with disabilities as well as others, such as older people, people in rural areas and people in developing countries.

Conclusion

As explained above, web accessibility is essential to accomplishing Priceline’s mission of being the “best travel dealmakers in the world.” Web accessibility increases the amount of customers who book through Priceline while at the same time also presents an inclusive web space that aligns with Priceline’s best business practices. By understanding the types of disabilities and the challenges faced with each disability, Priceline can create websites and applications that are usable by ALL of its customers.

Excited by what we’re doing at Priceline? Visit Priceline’s career site to learn more about our mission, culture and open positions.

--

--

Michael Alterio
priceline labs

Software Engineer @ Priceline | JavaScript Developer