A 4-step process for testing the accessibility of your designs

An approachable guide to doing an accessibility audit using a screen reader

According to the World Health Organization (WHO), about 15% of the world’s population lives with some form of disability and it can be apparent or non-evident. If designers are serious about designing for inclusivity, then accessibility (a11y) shouldn’t just be a last item on their QA checklist, but a part of every design decision.

Recently, we audited and fixed existing a11y-related issues in my product area at Shopify. I find screen reader usage to be tricky because there’s no single tool to automatically test for screen reader-specific issues. It is an assistive tool so people’s usage varies based on their individual needs.

I wrote this to make auditing easier with helpful links for further reading.

Setting up your screen reader

For this guide, I’m going to use VoiceOver on Mac, a screen reader program that comes on new Mac computers, iPhones, and iPads. If you’re on Windows, you can use JAWS or NVDA. I’ll provide guiding questions and examples of good and bad interactions, so your OS shouldn’t matter.

The first step is to enable your screen reader and get familiar with its keyboard shortcuts.

How will I know if something is an a11y issue?

Reading WebAIM’s article on testing with screen readers reminded me of the differences between how sighted and screen reader users access web content:

“Most screen reader users cannot survey the entirety of a web page with such immediacy. Web content is linear and text-based. They don’t often think in terms of left and right or position on the page. It is irrelevant to them whether the most important content is visually in the middle with the boldest colors and most artistic design.”

When in doubt, I ask myself whether an interaction behaves the way I designed it to. It’s important that a user with vision disability can understand the content and easily navigate the page — primarily using a keyboard — with the same ease that a person without vision disability can. If something behaves unexpectedly or stands out as difficult to use, then it’s worth bringing up to the team for further investigation.

The audit process

I generally test four keyboard shortcuts, as they cover most of the WCAG 2 AA requirements: to navigate focusable elements, to read each item, to read each image, and to navigate headings. Of course, you can go through all keyboard shortcuts if you want to be even more thorough, but this guide should be enough to meet the requirements. Let’s get started.

1. Tab

Tab is used to navigate to the next focusable item and Shift-Tab for the previous. Links and form controls are examples of this. Keep in mind that tab is only used to navigate and shouldn’t automatically select or activate the item.

Am I tabbing in the right sequence?

• The focus order is the same as your reading order which may vary for different languages.

Good example: The order focus on the first row is from left to right (14, 15, 16). Then, the focus on the second row starts in the first focusable item of that row (17).

Is the element’s name, state, label, and placement in a group (if applicable) described correctly and sufficiently?

• A tab is announced as a tab.
• The placement and count of elements in a group are accurate.

Bad example (left): The tab is announced as a link. Good example (right): The tab is announced as a tab and the count is accurate.

• If an icon is used as a button or a link, it should have an aria-label that describes its purpose.

Good examples: Both describe the link and button clearly. A bad example would be if they were labeled as “Add button” and “View icon”.

Am I able to explicitly select or activate the element using the spacebar?

• A button or link is only activated when enter or spacebar is pressed.

Bad example: The popover automatically opened after focusing on the price link. Users shouldn’t be forced to go through the popover when they only intend to skim the page.

Good example: The popover opened only after pressing the spacebar.

If the button opens a modal or popover, does the focus move to its content?

• When the modal is open, the next focus should be on the first element of the modal and I can interact with its content.

Bad example: The focus stays in the background after opening a modal, making it impossible to navigate its content.

Good example: The focus moves to the modal’s content and the user can interact with the elements in it.

• Pressing escape closes the modal and the focus returns to the previous.

Good example: After pressing the escape key, the focus returns to the “More filters” button.

• When the popover or modal has a radio button or checkbox group, I’m able to navigate to the first and last option. The popover shouldn’t automatically close after selecting an option.

Bad example: Pressing arrow up or arrow down key automatically selects the option and closes the popover.

Good example: Pressing arrow up or arrow down key allows the user to navigate the radio button group.

If the element is inherently accessible using a mouse, there is an alternative way to interact with it using a keyboard.

Good example: I can add files to the drag-and-drop area by selecting the “Add file” button.

2. Ctrl-Option- ← →

Ctrl-Option-left or right arrow keys are used to navigate to the previous or next item on the page. I use this to test the reading order and table markup.

Am I navigating in the right sequence?

• The focus order is the same as your reading order, which may vary for different languages.

In a table, is content announced correctly and sufficiently?

• The number of columns and rows is accurate.
• Table header + cell item provides more clarity.

Bad example (left): It’s unclear what “0 to 0” pertains to. Good example (right): Mentioning the table header adds more context to the text.

3. Ctrl-Option-Cmd-H

Ctrl-Option-Cmd-H is used to navigate to the next heading and Ctrl-Option-Cmd-Shift-H for the previous. I use this to test the ease of skimming through the page.

Are headings and subheadings used purposefully and semantically?

• Headings are used as needed (to organize and structure content).
• The page has only one h1 element.
• p doesn’t look like h and vice versa.
• Heading levels (h1, h2, …, h6) are used based on content hierarchy and grouping.

Bad example: The reading order doesn’t start in the page title due to the text field autofocus on page load.

Good example: The reading order starts in the page title.

4. Ctrl–Option–Cmd–G

Ctrl–Option–Cmd–G is used to navigate to the next image and Ctrl–Option–Cmd–Shift-G for the previous. I use this to test image alternative text.

Is the image alt text descriptive and contextual?

• All img tags must have alt attribute.
• The description helps you understand the purpose of the image.

Good example: the alt text describes clearly the purpose of the image.

• More tips on good and bad practices of writing alt text.

Bonus: disabled buttons

A disabled button is used to visually communicate that the action is unavailable until certain conditions are met but they are ignored in the focus order (tab). Does that mean we should always move away from showing disabled elements? Below are important questions to ask:

1. How important is it for the user to access the disabled element at this time? Will they be able to fulfill the task at hand without the element?
2. If it’s important, is there a clear instruction to enable it or a workaround to fulfill the task?

This should allow you to make the right decisions: either by adding context, showing actions only when they make sense, or even rethinking the part of the flow.

Want to learn more? Here are some links and resources I’ve found useful:

• What is disability? by OHRC
• Testing with screen readers and WCAG 2 Checklist by WebAIM
• Image Alt Text: What It Is, How to Write It, and Why It Matters to SEO by HubSpot
• Considerations when writing alt text by Shopify UX
• Aria-disabled by a11y 101

Thanks for reading the article and happy auditing. If you do your audit differently, I’d love to hear about your process below. You can read more of my stories on my personal blog.

Thank you, Devon Persing and Gene Shannon for the insightful feedback and edit.