• 6 hours
  • Easy

Free online content available in this course.


Got it!

Last updated on 6/1/23

Test Your Content Using Assistive Technologies


User Testing on People With Disabilities

Ideally, you want to test your products with actual users who experience disabilities. It can be useful to go through your interface with a keyboard or screen reader, but these exercises don’t give you insights into how real users will navigate your site with assistive technologies.

Even if you can test on real people with disabilities, beware that assistive technology users are diverse. The experience of one will not necessarily be representative of other users. A screen reader user who recently went blind is going to use their AT in a very different way from someone who was born without sight. Both experiences should be taken into account, but if you’ve implemented a particular pattern that doesn’t seem intuitive or easy to use, you don’t need to abandon it in favor of a workaround that improves the experience for one individual. It is generally better to stick to established conventions and best practices. The goal of user testing should be to get a varied pool with diverse needs and see how that impacts the experience.

While real user testing is the best approach, as long as you’re aware of the limitations, there are many benefits to conducting testing yourself to make sure the site is meeting basic requirements.

Test Alternative Navigation With a Keyboard

Using a site with a keyboard is helpful because it’s like killing five birds with one stone. Running through the page elements using tab to move forward and shift+tab to move back will identify whether:

  1. All functionality is accessible with a keyboard (SC 2.1.1).

  2. Focus gets trapped anywhere on the page (SC 2.1.2).

  3. There is a "skip to content" link that allows you to quickly move past repeating blocks of navigation (SC 2.4.1).

  4. The focus order of elements is logical (SC 2.4.3).

  5. A focus indicator is visible (SC 2.4.7). 

One thing people often don’t realize is that keyboard accessibility is vital on mobile devices as well. Many smartphones and tablets support Bluetooth keyboards, which can help users who find touch interactions challenging. Users may also increase the size of a website on a desktop until it appears in the mobile view, which often triggers an entirely different navigation menu. If a site you are reviewing has a mobile view, especially if it’s different from the desktop view, you should also test it. Mobile views are most likely to impact keyboard operability and focus order.

You can test mobile websites on a desktop, or connect a Bluetooth keyboard to your device. Note that iOS devices currently don’t fully support keyboard navigation; they allow users to type into fields using a keyboard but not operate apps. Most Android devices do support keyboard operability.

Test Alternative Presentation With a Screen Reader 

Screen Readers on Desktop

As I already mentioned, knowing how to use a screen reader is not the same as being a screen reader user. Keep in mind that your goal is not to simulate the experience of non-visual users, but instead to symptom check the site to uncover underlying issues. For this reason, I don’t generally advocate for turning off the screen while doing screen reader testing, even though it might seem like a closer approximation to a screen reader experience. Instead, look for inconsistencies between the visual design and what is communicated to you by the screen reader. Are there certain states that are only clear visually? Like which tab is selected, or whether a section is expanded or collapsed. Are the images described accurately? Is the structure of the page and content supported through the heading structure and page landmarks?

Before you begin testing, read through either of the following articles, depending on which screen reader you will be using:

Exercise: Use a Screen Reader to Interact With Your Site

Now try it out yourself! Use one of the two screen readers (or both!). Try moving through content in the following three ways:

  1. Reading through all content sequentially.

    • VoiceOver: Ctrl+option (VO keys) and left/right arrows. To drill down into content groups, press VO+shift+down, and VO+shift+up to exit groups.

    • NVDA: Using up/down arrow keys. 

  2. Navigating through only interactive elements and inputs.

    • NVDA and VoiceOver: use tab to move forward and shift+tab to move backward).

  3. By landmark.

    • NVDA: Use the D key to move from landmark to landmark.

    • VoiceOver: Press VO+U to bring up the Rotor menu. Navigate to landmarks using the left/right arrow keys. Move through landmarks using the up/down arrow keys. 

Feel free to try other shortcuts and navigation options from the articles above, such as moving from heading to heading, navigating forms and tables.

Remember to note these in your report if any new issues come up as you’re moving through the site with the screen reader.

Screen Readers on Mobile

You can test interfaces with the built-in screen reader on your mobile device. Because they are touch-based, screen reader interaction will be quite different than the desktop experience.

Although, with the increase of touch gesture support on desktop and laptop computers, you may also be able to use similar interactions as you do on mobile on these devices. On a basic level, you can generally use swipe left and right gestures to move between different elements on the screen.

You can also move between specific types of elements like headings, links, or controls. On iOS, you can do this using the rotor function. Pinch and twist with two fingers to get to the element you want to navigate by, and then swipe left and right to move between them. With TalkBack, you can move between the elements by swiping up and down and left and right.

Let’s Recap!

  • Test for how well the site supports alternative input by navigating it with a keyboard. 

  • Test how well it supports alternative output with a screen reader.

  • Screen readers can be used on both desktop and mobile devices. 

Hopefully, all of the accessibility testing you’ve done was an eye-opening experience! In the next part, we’ll look at how you can design more inclusively from the start; from visual design to interaction, to communicating your accessible designs across different teams. 

Ever considered an OpenClassrooms diploma?
  • Up to 100% of your training program funded
  • Flexible start date
  • Career-focused projects
  • Individual mentoring
Find the training program and funding option that suits you best
Example of certificate of achievement
Example of certificate of achievement