You’ve probably already heard we should make all our front-end work accessible. It helps make sure everyone can have the best experience when using the digital services, products, or platforms we've created.
But how do we know whether our work is accessible? The most efficient way is to make testing part of our routine.
In this post I'll share some freeby tools and strategies that I use from my local dev environment and that you can start using today.
Browser extensions
First, I check the page being tested with a browser extension. This is the best way to catch the most obvious issues.
The three browser extensions recommended by gov.uk are:
Although it is not a browser extension, the Lighthouse tab in the Chrome DevTools is also useful and will give you similar results.
It's important to keep an eye out for false positives!
Keyboard navigation
Next, I check that the page can be navigated using only a keyboard with the following key combinations:
- Tab or Shift + Tab to move focus to next or previous focussable element
- Spacebar or Shift + spacebar to scroll down or up a page
- Return key to click a focussed element
- Arrow keys to navigate within menus and lists
As you move around the page, you should look out for the following:
- Can you tell which element, if any, has focus?
- Can you reach and interact with all enabled, clickable elements (buttons, links, form fields)?
- Is the order in which these clickable elements get focus logical? or does focus jump around?
- Is focus lost at any point? This may happen if the focussed element is hidden.
- If there is a modal, external widget, or iframe in the page, can you navigate in and out of it? Can you open and close it as expected?
Screen readers
Testing with a screen reader, is slightly less straight-forward as we must also think about which browser we’re using for the tests.
The recommended browser pairings for the three main screen readers are:
- JAWS with IE or Chrome
- NVDA with Firefox
- VoiceOver with Safari
Which screen reader?
JAWS is the most widely used screen reader in real life. However, it is proprietary software and its license is not cheap. As a consequence, most developers will only be able to test against it if their workplace owns a license.
NVDA is Open Source and the second most popular screen reader, although a version exists for Windows only. So if you work with a Mac or Linux laptop you may need to install it in a virtual machine.
VoiceOver comes built-in with iOS so, again, if you work with another operating system, you’ll need to use a virtual machine.
The recommendation is to test your work against as many screen readers as you can get hold of as they sometimes give different results.
How to use them?
Each screen reader has its own combination of keystrokes, so I’d advice downloading a cheatsheet and spending some time becoming familiar with them.
You can find all the screen reader cheatsheets on the Deque website.
Once you’ve got some practice under your belt, you’re ready to start testing your frontend work.
Here’s the steps and what to check for each:
- Page navigation:
- Is the main site navigation useable? Does it include a skip to content link?
- If there is a secondary navigation element, is its purpose announced?
- Are all regions, headings, and links well defined and findable?
- If there is a form:
- Can you interact with all its elements as expected?
- Test also the unhappy path. If a warning or error is displayed, does the screen reader announce it?
- Read the whole page through.
- Is any information missed?
- Is there any repetition?
- Is anything read that could lead to confusion?
I realise this is quite a lot of information. And that it can potentially also be perceived as quite a lot of extra work!
What worked best for me was to add the checks to my workflow one at a time, in the order mentioned above. Once I was familiar and comfortable with one, I added the next.
Just think of the time saved by not having to go back to fix accessibility issues! Plus the satisfaction of delivering top quality work. Priceless!
Top comments (0)