How to test your website’s accessibility

Automated testing

Firstly we’ll look at an automated tool that we use to gauge the general level of accessibility on a website.

WAVE

WAVE (Web Accessibility Evaluation) is a valuable tool that can identify accessibility and colour contrast issues on your website. At Graphite, we use the WAVE Chrome extension but you can also run tests on their website.

After running a WAVE test, the tool returns a summary of its findings. Errors and contrast errors are the most important sections to focus on, as they raise website features that don’t conform to Web Content Accessibility Guidelines (WCAG). The alerts, features, structural elements and ARIA sections can be useful for an overview of web page structure, but generally don’t offer as much value.

In the ‘Details’ tab, you can find all of the flagged accessibility and contrast errors. For each finding, if you click the red icon you’ll be taken to the highlighted area on the web page. Clicking the ‘i’ icon will take you to the reference tab and provide more information about the accessibility error, including how to fix the issue, and links to any related WCAG standards.

At this stage, we make a note of the errors and colour accessibility issues and add them to the project backlog so we can address them at a later date.

It’s important to note that automated testing won’t reveal all of the accessibility issues on your website. Users interact with websites in a variety of ways, and automated testing can’t cover all of these use cases. 

Manual testing

As well as automated testing we also need to consider mouse, pointer, mobile, keyboard, and screen reader accessibility. 

Testing accessibility with a mouse

Let’s start with the first of these cases: mouse and pointer accessibility on desktop, and users who access your website by scrolling and clicking with their mouse, touchpad or similar device. 

A good starting point is to hover over links and buttons to ensure that they look ‘clickable’. To help identify whether a link or button appears to be clickable or not, ask yourself the following questions when hovering; Does the mouse cursor icon change to the finger icon? Do links and buttons change colour? If links and buttons fail the minimum check here, they should be flagged as an accessibility issue. 

Radio buttons, checkboxes and their labels should also be tested to ensure that they’re easy to toggle on and off. It’s vital that anything clickable looks clickable. 

Testing accessibility on mobile, tablet and touch devices

You can start some simple accessibility testing by trying to click on links and buttons. Anything clickable should be large enough to comfortably press with a finger or thumb. UX experts, Nielsen Norman Group, suggest that touch targets should be at least 1cm × 1cm. Though we code websites in digital units (pixels, percentages, and rems) they don’t take into account physical space on a phone screen.

We also need to test whether users can access dynamic content on their touch screen device. Let’s imagine that on our desktop website, users can hover over a link to reveal a mega menu, from which they can access extra content. Can a user access the same content on a touch device? Does the mega menu open when the user taps the link? Think of some typical dynamic actions that users may take on your desktop website and think about how they should work on mobile and touch devices. Test them and add any irregularities or bugs to your project backlog.

Testing accessibility with a keyboard

To ensure your site is accessible for users who cannot use a mouse or have visual impairment, it’s important to test that you can complete essential tasks using just your keyboard. For example, can you navigate to a page by using the tab button alone? Can you submit a form by pressing Enter? Can you open a mega menu and access the child links? When you tab through web pages using your keyboard, can you see which part of the page you’re focused on? There are so many vital actions that keyboard users could be prevented from taking if such scenarios aren’t looked at.

Testing accessibility with a screen reader

At Graphite we are still expanding our expertise in this area and have found this WebAIM article on Testing with screen readers to be an essential read.

The article also recommends that developers ‘pay more attention to the principles, guidelines, and best practices of accessibility, rather than to the differences between screen readers.’ 

Test your website in a popular and free screen reader (NVDA for Windows, VoiceOver for Mac and iOS), learn useful keyboard shortcuts, and test your website using the guidelines suggested on expert accessibility resources, such as this article from Indiana University.

Accessibility should always be a vital consideration when building a website. To summarise, we suggest starting your website accessibility testing with an automated tool, like WAVE, and moving onto a variety of manual tests, which cover mouse, touch, keyboard and screen reader accessibility, noting down areas that fail your test throughout. While testing, you may find it useful to refer back to the Web Content Accessibility Guidelines. After testing, we suggest writing up your notes into tasks for your project backlog and discussing them with your development team. Ideally, testing will become part of the iterative process in developing robust and inclusive websites.