It's #FrontendFriday - How to test accessibility?

As part of the JavaScript conference in Munich, we were able to listen to a number of interesting talks. One very interesting talk for me was the talk by Anuradha Kumari on the topic Decoding web accessibility through testing (Link to the public presentation on the topic). This talk was about the importance of accessibility on the web, what we need to pay attention to and what tools are available to help us.

What is accessibility?

Making resources and services available to everyone, regardless of their impairments.

 

According to the World Health Organization There are approximately 15% (1 billion) people living with some form of disability. As we develop for our users, we must also include this part of humanity so that they are not marginalized.

There are the following basic types of impairment (among others):

• Visual
• Auditory
• Motorized
• Cognitive

How do we test accessibility?

The WCAG presents the so-called POUR principle as the basis for its guidelines.

• Perceivable (perceptible)
  
  Information and components of the user interface must be presented to users in such a way that they can perceive them.
• Operable (operable)
  
  Components of the user interface and navigation must be operable.
• Understandable (understandable)
  
  Information and operation of the user interface must be comprehensible.
• Robust (Robust)
  
  Content must be robust enough to be interpreted by a wide range of user agents, including assistive techniques.

Keyboard

A basic type of accessibility is navigating using only the keyboard. Here you can simply check whether all relevant elements are completely accessible via the keyboard.

Important buttons

• Tab
• Shift + Tab
• Enter key
• Space bar
• Arrow keys
• ESC

What should we pay attention to?

• Are all interactive elements accessible and can you interact with them?
• Is it clear which interactive element you are currently on in the application?
  • outline: none or similar can lead to problems here.
• Check whether you can fall into a "focus trap". This means that you are "trapped" in a part of the application and can no longer get out using the tab navigation.
• Is there a tab-index > 0? Basically, you do not need a tab-index that is greater than 0.

Screen Reader

There are many different screen readers:

• NVDA - Windows (free of charge)
• Mac voiceover utility - Mac OS (free of charge)
• JAWS - Commercial product
• ORCA - Linux (free of charge)
• And many more...

What should we test with a screen reader?

• Landmarks
  • Give the application a structure
  • Screen readers use landmarks for navigation
  • <header>, <main>, <nav>, <…> Use elements instead of <div id="“header“">
  • Do not use too many landmarks
• Use the alt attribute for images
  • alt="", if the image is only decorative and does not need to be read aloud
  • alt="Enter description here", for informative images
  • Never leave images without alt attributes. The screen reader will then try to interpret this image. If the alt attribute remains empty, this image is automatically skipped
• Use form label
  

  <label> E-Mail eingeben:
   <input type="email" id="email" />
  </label> 
  
  oder 
  
  <label for="email">E-Mail eingeben:</label>
  <input type="email" id="email">

  
  

  In both cases, the text "Enter e-mail" is displayed here by the screen reader

• Are dynamic changes announced?
  • By the attribute aria-live="polite". See: aria-live
• Are actions comprehensible?

Browser tools and extensions

• DevTools
  • In DevTools, you can access accessibility via the Elements -> Accessibility tab. Here you can see basic elements such as the aria-label or the value of an element. You can also see the accessibility tree of the website.
• Lighthouse
  • In DevTools, you can generate an accessibility report via the Lighthouse tab. This is very rudimentary and only checks the most important parameters.
• Axe extension
  • A powerful browser tool that can check the web application in the browser. It works in a similar way to Lighthouse, but is much more comprehensive. You can highlight all errors and call up information on the errors.

Automated tools during development

What can we test?

• Page title
• Headings and HTML structure
• Aria validations
• Color contrast
• Caption alternatives

What tools can we use for this?

• Axe-Core
  • Axe is an accessibility testing engine for web applications.
  • It can be used together with Cypress, Selenium or the Axe CLI.
• eslint-plugin-jsx-a11y
  • Plugin for eslint and to link code during development.

 

Learn more about software development