Accessibility testing for beginners
A practical guide
The best way to be sure a website is accessible is to design and develop with accessibility in mind from day 0. But we also know our experiences are often far from ideal… so if you’re going to test the accessibility of a website, where can you start?
I’ve recently been in charge to find and report accessibility issues on the website of the company I work for. Probably 3–4 years ago I wouldn’t know where to begin but, thanks to my #100ThoughtsOnInclusiveDesign, I had some ideas and some helpful links.
I’ll try to report my experience, being as practical as possible, hoping that it could be helpful to actually start testing.
If you need to learn something more about accessibility I have a couple of suggestions at the end.
Setting your tools
How to collect issues
You can use this template from Harvard University to report all the issues.
It includes:
- a table to collect your issue;
- some examples;
- a list of WACG 2.1 criteria ready to use;
- a Severity Matrix to help you define the impact of any issue.
Tip: having your template ready to use from the beginning is helpful to personalize it with what you need (useful links, the list of what to analyze, and the pages to check — see below).
What to analyze
The A11y Project checklist is a good track to helping you decide what to analyze on each page you’re checking.
This checklist is complete and exhaustive, and you can use it directly online. I didn’t check everything: I chose, among all these elements, the most relevant items for my analysis (for instance a check on some specific media was, for the moment, out of scope for me).
The next step is to make a list of each page and flow you need to consider. And, you are ready to go!
Testing tools and methods
There are a lot of tools to check different aspects of accessibility.
I decided to use these browser extensions for a first global check:
- Wave (available for Firefox, Chrome, and Edge, or online), which makes an exhaustive record of a lot of issues (alt text, labels, page hierarchy and order, etc.);
- Web Disability Simulator (Chrome) and Silktide (Chrome) to have an overview of how some users perceive the website (colors and content).
Note: some issues (mainly everything that has something to do with content) are identifiable only by checking manually so I supported the analysis with some manual techniques: I’ll explain for each type of issue what I did.
What I checked
1. Page language
For each page be sure the HTML metadata <lang> is set, and that it’s set in the language the page is written in.
Why is it important? A screen reader will base its reading on this information and will read the text with the pronunciation of a speaker of the language you have set.
How to check? WAVE will identify if a language is set, but it can’t tell you if the language set is coherent with the text on the page: read the text yourself or read it through a screen reader to identify inconsistency. Unfortunately, if you don’t know the language in which the page is written it can be tricky to identify this issue.
2. Page title
Why is it important? The <title> identifies a page. It’s useful for the user orientation: browsers display it as the tabs labels (when many tabs are open) and it’s the first thing screen readers read.
How to check? You can read it in the browser tab label, but, if it’s too long, you can check the HTML source.
What to check?
- is brief and describes the page;
- differs the page from the other on the website;
- has the most relevant information first (eg: About | Website name).
3. Headings
Verify if there is, for each page, an <h1>. It describes the page content (as <title> do). There should be only one: having multiple H1 it’s not formally forbidden, but, since it’s useful to identify the most relevant theme on the page, it would be easier with less entropy.
Headings from <h2> through <h6> are useful to express page information hierarchy, so it does not make sense to skip heading levels.
Why is it important? Headings are helpful to understand the overall organization of the page content, especially for people with some learning disabilities or screen reader and keyboard users.
How to check? Tools like WAVE will highlight the presence of the headings, content, instead, has to be manually checked.
4. Keyboard
Be sure that the page is navigable through the keyboard, that each active element has a visible focus, and that the page hierarchy is respected.
Why is it important? Often screen readers users also use the keyboard to navigate, but also people with hand tremors navigate through the keyboard.
How to check? Manually, with your keyboard (use your tab key to move through items).
5. Color
This article is a good reading about color and accessibility.
Here you are a quick recap:
3.1) Test if there is a sufficient contrast ratio between text and background, on the page but also for each button, banner, or element.
How to check? Foreground and background colors should have a 4.5:1 contrast ratio at Level AA and a 7:1 contrast ratio at Level AAA. Do not worry if it doesn’t means a lot to you: automatic tools will highlight each critical ratio. I used directly WAVE extention, but this contrast checker or this accessible color palette generator are also useful.
3.2) Be sure that color is not used as the only way to convey information, for instance in an error message, in an exercise explanation, in data visualization, etc.
Why is it important? Color-blind people may not be able to perceive that information.
How to check? Browser extensions such as Web Disability Simulator and Silktide can show you the page as a color-blind person and it will be simpler to identify these kinds of issues.
6. Alt-text in images
Why is it important? <alt-text> provides images descriptions screen readers can read. It can also be useful for users with slow connections because it adds context before images are loaded.
How to check? Automatic tools (such as Wave) can easily tell you if an alt-text is present or not, but they can’t tell you if it’s relevant. The easiest way to manually check if an alt-text is present and if it’s useful is, in my opinion, to disable the images on the page (in Chrome you just have to click on the lock in the navigation bar and open the settings).
How to check if it’s relevant? Here are some further readings ;)
- How to write an image description
- Are you making these five mistakes when writing alt text?
- How to write alt-text descriptions for image accessibility
- And if you’re dealing with more complex objects you’ll find some useful tips here.
7. Buttons and links labels
Be sure that buttons and links have useful microcopy, that explains the action and/or the destination.
Why is it important? Knowing what will happen is useful for everyone, but in particular users with a cognitive disability will benefit from more context and explanations. Also, screen reader users will find that useful.
How to check? Manually, maybe listening to a screen reader parsing the page.
8. Forms
It’s essential that forms are navigable through keywords. But it’s also important that each field is associated with a useful label.
Why is it important? Labels give context and are useful for screen readers users.
How to check? WAVE can help you identify if each form field has a label. Coherence, instead, has to be checked manually.
9. Errors
Errors should be prevented anytime it’s possible by giving clear instructions and guiding the user, but when it’s necessary to show an error be sure that:
- errors can be easily detected and that the message is near the “problem”;
- error messages are written in a simple way, that any user can understand, using no jargon;
- color is not the only way to identify errors.
Why is it important? Designing better error messages is helpful for everyone, but it is necessary, in order to understand where is the error and how to deal with it, for people using screen readers, people with low vision using a magnifier, people with cognitive disabilities, and color blind people.
How to check? Unfortunately, this is not only a manual check, but some errors are tricky to identify. Try to stress the page, but also ask for a list of all the messages to developers.
What’s next?
Rate the severity of each issue in order to give priorities. And define which role is responsible for addressing the issue (you will find both in the template suggested at the beginning).
After that you’re testing phase is on pause and you can begin fixing issues.
