Publicus Blog

Why Manual Accessibility Testing Matters5 min read

Image credit: Karwai Pun and Gov.uk from “Dos and Don’ts on Designing for Accessibility”

How to verify that a website is ADA accessible and 508 compliant

Accessibility is a big topic for public sector websites. Not only can the requirements of an accessible website seem overwhelming and difficult to grasp, but a 2017 study by Gov.uk indicates that automated testing tools do not easily provide a guarantee of the accessibility of a website.

This may come as a shock for many government agencies that rely on automated testing to assure 508 compliancy. With this in mind we’ve compiled a list of the primary areas that are important to manually review to be sure a website is compliant.

If you want to understand accessibility and testing better first, read on, if not, skip to the “Top 5 issues to review for accessibility” below.

Why accessibility matters

“Imagine: You can’t see at all. You use a computer with a screen reader. A mouse is mostly useless to you. You use your keyboard to navigate around interfaces and sites.”

While this is a scenario posed by Adam Morse in The Veil of Ignorance, some or all is reality for the 8.1 million people in the U.S. living with a visual disability.

8.1 million have a visual disability – they might rely on a screen magnifier or a screen reader, or have a form of color blindness

19.9 million have difficulty lifting or grasping – this impacts the use of a mouse or keyboard

7.6 million have a hearing disability – they might rely on transcripts and/or captions for audio and video media

Enter Section 508

Established in September 2010, the Americans with Disabilities Act (ADA) Standards for Accessible Design supports equal access to information for people with the following disabilities:

vision impaired

physical or motor skills impaired

hearing impaired

dyslexia

autism

reading difficulties requiring use of a screen reader

Under the ADA, Section 508 regulates accessibility standards for information technology, including computer hardware, software and documentation. The Web Content Accessibility Guidelines (WCAG) 2.0 from W3 cover a wide range of recommendations for making web content more accessible.​

Although WebAim has created a useful WCAG 2.0 Checklist, the challenge comes when trying to make sense of all the requirements. It helps to understand that many of them pertain to making a website accessible to screen readers. Audio interfaces, such as JAWS or ChromeVox, convert digital text into synthesized speech. Because they read content linearly, the web page must be presented in such a way that a screen reader can make sense of it.

This means images must be described in the alt tags and color can not be used as the sole method of conveying content. Furthermore, since keyboard shortcuts like the tab key are used to navigate content with a screen reader, the page must include correct tags for heading levels and other page layout elements.

Why automated testing isn’t enough

While there are a number of automated testing tools, according to a study by Gov.uk, “No tool will be able to pick up every accessibility barrier on a website. And even if they do detect a barrier, sometimes the results they give will be inconclusive or require further investigation.”

In the study, some of the issues the automated tools missed included:

images without alt attributes

the wrong alt attributes

blank link text

flashing content that didn’t carry a warning

plain language not used in content

This is why they recommend combining automated testing with standard manual quality assurance and user testing.

“A good analogy is to think of a testing tool as like using a spellchecker,” says Gov.uk. “It can certainly help you pick up issues, but it should never be used in isolation. To be most useful, automated tools should be combined with manual inspection and user research.”

1) Image clarity

HTML text that replicates text in an instructional image or infographic

simple rather than contrasting colors for image text

2) Language clarity

plain language

simple content format with headings and bullet lists

text magnification to 200%

hypertext links that make sense out of context, links defined by underline not just color

HTML5

3) Table, graph, chart, and frameset clarity

charts and graphs described in alt tags

content in frames described in text or a non frameset version of the page

table content summarized in HTML text and content that makes sense when read out of table form

4) Audio and video assistance

captions and subtitles for video and audio

HTML transcripts of audio and video

5) Keyboard controls

clickable actions for keyboard shortcuts instead of a mouse

How we can help

Because of these complications, web accessibility and compliancy testing is often maintained by an outside vendor. We’ve recently worked with Washington DSHS, Vermont Judiciary, and Missouri Department of Conservation to establish and define their compliance and testing.

Let us know if we can help with your accessibility questions or concerns.