How to test for web accessibility: an introduction

To properly test your site for accessibility, you need guidelines. The Web Content Accessibility Guidelines (WCAG). There are three levels: A is for basic accessibility, AA is the global standard, and AAA is the strictest level, for special applications. In the European Union, we need to comply with WCAG 2.1 AA for the web. In the United States, WCAG 2.1 AA 2.0 is the legal standard at the moment.  

A good writeup is provided by the W3C: How to Meet WCAG (Quick Reference). 

These guidelines can help you make sure your site is accessible to people with a disability. But there are also many best-practice testing tools out there that can help you enhance the user experience for all visitors to your site.

Test not only at the end, but during each phase in the creation of a web project: information architecture, design, coding, and content. Testing only at the end could well mean a lot of rework—refactoring code, for instance, or worse yet, starting from scratch. So testing along the way, and making adjustments as you go, will likely save you time and money. 

For each phase, there are three important items to test for.

A consistent navigation structure is key. It makes it easier for visitors to find what they’re looking for.

How to test for good navigation structure: Make sure the main menu is always in the same place, and that it always works in the same way. Do the same for the footer. Perform user testing on your wireframes: make sure that users can find the information they need quickly and easily.

Ensure consistency across the board in the names of actions, links, and other functionalities and components

How to test for consistent naming: Take a critical look at the names of links and buttons, especially for important functionalities such as search, the menu, and links to the homepage. Is the text of embedded links and on buttons consistent? Are the look and feel the same?

It may be helpful to discuss any consistency issues with your designer.

Not every visitor searches for information in the same way, so it is helpful to have more than one way to find information on your site. How to test for findability: Make sure your site offers more than one way to find information—for example via the main navigation, through a search form, and on a sitemap (or an overview of links in the footer).

When you read from the top down, does the story of the content make sense? Visitors who are blind do not have an overview of a web page as a whole.  They read from the top down. So do search engines.

How to test for the logical order of the content: Read from the top down, making sure the order of headings and of the content below each heading makes sense, and that information is grouped together in a logical and easy-to-understand way.

Elements that are placed close together are considered by default to belong together.How to test for proximity: Make sure that all elements that belong together are grouped together. And zoom in, in the browser, up to 400% with the keys Ctrl+ or Cmd+ on your keyboard. Can you still see what is related to what—for example, a label and the associated input field in a form?

The last thing you want is for visitors to your site to have difficulty actually reading what it says. Making sure there is enough of a contrast in colour between text and background is one way to ensure easy readability.

How to test for appropriate colour contrast: The WCAG has specific guidelines on how to test for colour contrast, and there are many tools out there that can also help.In your design, too, you can use the colour contrast analyser for Sketch and colour contrast checkers for Stark. You can also do a manual check with the contrast checker from WebAIM. In your browser, you can use WAVE, for instance. And you can find other ways to do this check on the Color Contrast Tools page on WebAxe.

The first thing to test here is the code itself, for HTML5 and accessibility issues. These tests can be done automatically and are quite useful, but they can catch only some issues. The key thing, again, is to test during development and not only at the end. That will save you a lot of refactoring, and thus a lot of effort.

Some integrated development environments such as PhpStorm add helpful inline error messages for accessibility or HTML5 validations.

The W3C Markup Validation Service allows you to check your HTML for errors.

Axe DevTools by Deque adds a tab to the inspector that lists accessibility issues that have been found. Deque also offers axe Linter, which analyses pull requests in GitHub. Axe is the best tool that developers have right now for automated accessibility testing.

And last but not least: browsers such as FireFox and Chrome add error warnings such as for missing labels or colour-contrast issues in the inspector.

Note: Automated accessibility testing cannot catch all issues. You will also need to test manually and with a keyboard.

Another element to test for is the user’s ability to navigate with the keyboard. Does all functionality work with the keyboard alone? It is important to be able to make a website navigable with a keyboard . And the skill is easy to learn. Make sure your browser settings have been adjusted to allow for keyboard navigation.

How to test the basics of keyboard navigation: Make sure you have the following functions in place:

Check, for example, whether a menu or an accordion opens and closes, and whether all form controls work.

Check to make sure every focusable element has an accessible name. 

For a link that will be the link text; for a button, the button text; and for a form control, the label. The accessible name is announced by a screen reader. That tells blind visitors where the link goes, what happens when they press a button, and what to fill out in a form. Read The perfect link and Every input needs a label for a bit more context.How to test for accessible naming: Browser extensions such as Axe DevTools and WAVE give warnings if an accessible name is missing. But they cannot check whether a name makes sense. Go over your work and check if the accessible names also make sense when you cannot see the items in their context.

Headings are the backbone of your content. A heading must describe the content below it.

How to test for an appropriate heading structure: Make sure the title of the main page has been assigned a level-1 (H1) style, and that it occurs only once per page. The title should indicate what the page is about. The other headings are used to structure the rest of the web page, much like the table of contents in a book. There should be no gaps between style levels (H1 > H2 > H3…).

The browser add-on HeadingsMap shows the header structure of a web page at a glance. You can download the add-ons: HeadingsMap for Chrome and HeadingsMap for FireFox.

The text displayed in a link must be meaningful and must be understandable outside it’s context. Text such as “Click here” and “Download” are meaningless, for example. In the post The perfect link, we explain the whys and wherefores in more detail.

How to test for clarity the text displayed in links: Look over the web page. Imagine you don’t know the context around the links you see. Read only the text displayed. Can you figure out where the link goes? A link is a promise, not a surprise.

Visitors with a visual impairment may not be able to see what is on an image. A short descriptive alternative text (alt text) can thus be useful.

But if an image is purely decorative, it doesn’t need an alt text. In that case only the text value can be left empty: the alt attribute should still be present. Most good content-management systems add the attribute by default.

How to test for alternative text with images: The easiest way is to use the browser add-on WAVE by WebAIM. This tool gives a range of accessibility information, and generates a list of missing alternative texts. WAVE comes as an online checking tool and as a browser add-on for Chrome and FireFox.

Now that you’ve read this post, you can already address some accessibility issues on your website. But there are, of course, other tests you can do, such as: test for screen reader feedback on dynamic changes and determine the reading level. 

The courses listed here, for instance, go deeper into the hows and whys of accessibility testing: