Automated testing tools help you find accessibility issues in your Information Technology (IT), like websites or web applications. These tools range from browser add ons that will alert you to issues in specific pages, to cloud services that will scan websites and provide you with a report.
You will still need an understanding of web technology to interpret the results. Automated testing tools will also only surface about 40% of the potential issues in your IT. Actually inspecting your IT with a checklist while doing manual functional testing is also required.
We do recommend an “automated testing first” strategy, however, because:
- it will identify with little effort a large proportion of any problems your IT may have
- it will give you a quick idea of the accessibility of your IT
- it will narrow down the number of manual functional tests you need to perform afterwards
Test case-driven vs view-driven testing
When doing automated or functional testing you may choose a route through your IT determined by what you consider to be the critical paths. This test case-driven approach has the benefit that it will shed light on the most important areas of your IT so that you can address them first. It will also highlight inconsistencies between views as you follow a workflow. It does require preparation of the test cases, however.
View-driven testing involves examining each view as a thing in itself, without reference to others. It is quicker to get off the ground, but you may miss some “whole picture” issues or issues that have an impact on some critical functionality.
Which testing regime you choose will depend on many factors. If the IT is mostly informational, and you are confident that the information architecture is clear and efficient, view-driven testing is adequate. If the IT is interactive and requires user input and decisions, test case-driven testing is highly recommended. Imagine if the login screen is inaccessible and you did not follow the “User can log in” test case, for example.
Tools for documents
If your IT is not web-based, the most common authoring tools provide you with ways to check the accessibility of the documents you are creating. Instructions:
- Word 2016 and older versions, Word 365
- Powerpoint 2016 and older versions, Powerpoint 365
- PDF (Microsoft)
If you have a limited technical background:
If your IT is static, public and voluminous and you would like to check many pages in one go:
Other tools for web-based IT
- Web Disability Simulator
Lets you simulate color blindness, low vision, dyslexia and more.
- Colour Contrast Analyser
Most automated testing tools will find contrast problems, but occasionally they are not able to do so with accuracy because of diverse reasons. When this is the case, the Colour Contrast Analyser browser add on is invaluable.
Produces a lightweight report of the structure of a page (headings and landmarks).
Useful to inject styles into a page - provide visible focus, highlight all images without an alt attribute, etc. You will seldom need to use this, but it will be very useful when you do. Requires some knowledge of CSS.
- Photosensitive Epilepsy Analysis Tool (PEAT).
A Windows tool to help authors determine whether animations or video in their content are likely to cause seizures.
Using the tools
We can only provide documentation and support for a limited number of tools.
U-M has a limited number of licenses for the axe Expert extension for Chrome. If you download it, let the accessibility team know so that we can register it. If we run out, you can use axe DevTools. Screencasts below will be using Attest, the old version of axe Expert.
- Access axe Expert
When page loads, right click on it, choose Inspect. In bottom page switch to Worldspace tab.
- Using axe Expert Analyze
- axe Expert Analyze: the issues view. Filtering and sorting.
- axe Expert Analyze: a single issue view. Inspect node, highlight element, read solutions, learn more.
- axe Expert Page Insights
- axe Expert Export report
- axe Expert Change the ruleset to WCAG 2.1, the current university standard.
Accessibility Insights for the Web
Again - the testing engine is axe, so the reports will have some similarities to axe Expert. It does provide a bit more scaffolding and support documentation. See the screencasts below.
axe Monitor is intended to help units and departments that have a large web presence make their offerings accessible. It is a server based spidering service that uses the axe engine to provide reports on entire static websites. The university has a limited number of licenses and we want to reserve these for folks that are going to take an active role in monitoring and remediating core informational websites. See more information on U-M's axe Monitor system.
WAVE & Tota11y
Totally has a limited range of what it tests for, but it is very helpful as it displays the test results directly on the page you are examining.
As mentioned above, automated testing is just the first step. With that done your manual functional testing can focus on the things that automatic testing will likely miss.
You should perform simple non-technical tests designed specifically to surface issues that will not be reported by automated testing.