Skip to content
QualityLogic logo, Click to navigate to Home

5 Simple Accessibility Tests Everyone Can Do and Why They Aren’t Enough

Home » Blogs/Events » 5 Simple Accessibility Tests Everyone Can Do and Why They Aren’t Enough

In the United States, approximately 20% of the population experiences some form of disability and 10 % of cases are considered severe. This equates to three out of every 10 families being affected by disability. You spend time on app design or site SEO to drive traffic, but are you reaching everyone you could? The differently-abled are in the workforce and spend discretionary dollars, too, so you want them to be able to use your site or app without trouble.

What is Accessibility Testing?

Accessibility testing sounds simple but isn’t. Accessible design is the practice (and the law!) of making sure your digital content or platform can be used by the differently-abled. When we think of disabilities, we may think of the inability to see or to hear, but true accessibility accounts for a broad range of different ways-of-being. This includes differences in auditory, cognitive, neurological, physical, verbal, and visual processing. These differences mean that accessibility is more than simply testing your site with a screen reader (although that’s a good start)!

Testing your site or app for this significant portion of the population begins with knowing there are legal requirements for accessibility in place. The Department of Justice (DOJ) published the Americans with Disabilities Act (ADA) Standards for Accessible Design in September 2010. These standards state that all electronic and information technology must be accessible to people with disabilities. These standards, the Web Content Accessibility Guidelines 2.0 (WCAG), use four areas to determine if web or app content is considered accessible. These are:

• Perceivable: Users must be able to perceive the information being presented
• Operable: Users must be able to operate the interface
• Understandable: Users must be able to understand the information as well as the operation of the interface
• Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

The WCAG provides a detailed set of guidelines for making web content accessible to people with a wide variety abilities. It is comprehensive, but incredibly detailed, and quite difficult to gain a rapid understanding of. The WCAG is also over 1000 pages combined! Without memorizing all 1000 pages, there are basic usability tests that can be done without exhaustive knowledge of accessibility technologies, laws, and experiences.

5 Simple Accessibility Tests Everyone Can Do

1. Imagine this: Navigation via keyboard

Without being able to see, you have no visual referent of where you are on a site. You navigate via tab hierarchy built into the site’s code. This means site structure must be presented in a logical manner. To interact, you use your keyboard, rather than the mouse, to navigate. Interaction is simple, the ‘Tab’ key allows you to move forward in the tab order. The ‘Shift’ and ‘Tab’ keys at the same time will move you backwards in the tab order and pressing ‘Enter’ will follow links. Understanding this, how do you check your site for functionality with assistive devices?

Solution: Test by using your keyboard only

To do this simple test, just unplug your mouse and keyboard. Navigate your site using only the keyboard and check these 3 areas:
• Can you interact with all controls, links, and menus using only the keyboard?
• Can you see what item has focus at all times?
• Does the focus order match the intended interaction order?

2. Imagine this: Images that don’t make sense

Tabbing along, you hear the screen reader say “Image”. Since you can’t see you’re wondering, “Image of what?” Is it an informational image or one that’s purely decorative? It matters because you want to know the information, but obviously don’t need to ‘see’ the decorations. Without alt-text to guide you, there’s no way to tell if you’re missing important information or being distracted by details not relevant to your experience.

Solution: Check for alt-text
  • Informative visuals should have comprehensive alt-text accessible to an assistive device. Decorative images can be set to null (alt=””) to be ignored by the reader.

You’re tabbing along at about 300 words per minute, or 16 syllables per second, and hear this, “Click here”. You stop, puzzled. Without a referent, “click here” means nothing to you.

  • Make sure the link text on your website make sense out of context? ‘Click here’ and ‘more’ are two common examples of non-descriptive link text that can cause a website to suffer poor accessibility. A better link text would say “Click here for more information on xyz”, using a complete sentence to indicate what the link is.

4. Imagine this: Hearing impaired

You’re hearing impaired. The site you’re on has media content, but you can’t hear a thing. Frustrated, you check your speaker’s volume control only to discover the fault lies with the site, not your hardware.

Solution: Check for captions and transcripts
  • Ensure your website supplies subtitles or written transcripts so that media content is accessible to hearing impaired users.

5. Imagine this: Reduced Vision

You have reduced vision and use high-contrast mode with resized text to read a site. The site you just visited (and you really wanted to purchase a fabulous gadget from) doesn’t support either. You’re both bummed AND irritated. You won’t be purchasing from a company who obviously isn’t inclusive.

Solution: Turn on high-contrast mode and resize the text
  • High-contrast gives low-vision users a convenient means of improving their ability to successfully use the computer by changing the foreground and background colors to create higher contrast. Adjusting the text size on a website is another strategy employed by low-vision users to navigate a site. Check this by scrolling with the wheel of your mouse while holding down the control key.
  • With high-contrast mode turned on, interact with the site. Change text size as you do to make sure your site supports both actions in combination.

Meeting ADA Guidelines Goes Deeper Than These Basic Accessibility Tests

Without extensive knowledge of assistive technologies, and how people with disabilities use computers, a tester cannot truly understand accessibility and all that accessible web testing requires. While there are simple accessibility tests you can perform on your own, meeting the ADA guidelines — and engaging differently-abled users — goes much deeper than the basics listed here. Making your website or mobile app truly accessible to all takes more than running tests with a screen reader, with mic and sound turned off, or without a mouse. Your site and app need to work across a broad range of platforms and with all popular assistive technologies.

If you’d like more information about QualityLogic’s accessibility testing solutions, follow this link.

Contact Us


Paul Morris, Director of Engineering & Accessibility Services

Paul Morris started his career as a chemist with the United Kingdom’s Laboratory of the Government Chemist (LGC). During his tenure at the LGC, he developed an aggressive degenerative eye condition called retinitis pigmentosa, a genetic disorder of the eyes that eventually causes a loss of vision, and he had to leave the chemistry field. However, along with the change, came opportunity. While Paul transitioned to an administrative position with the UK Ministry of Defense, he also began teaching himself how to code. As the course of his career evolved, in 1999, he moved to the United States, where he was offered a job as a test technician for QualityLogic. Now, more than two decades later, Paul is QualityLogic’s Director of Engineering and Accessibility Testing Services.

During his career with QualityLogic, Paul has had the opportunity to explore all aspects of QA testing, while simultaneously benefitting from the use of assistive technologies. He is recognized as an accessibility subject matter expert for both user experience and development and is certified in JAWS technology, a screen reader developed by Freedom Scientific that provides speech and Braille output for computer applications. Paul also has expertise in Ruby, JAVA, Python, and is an SQL administrator.

While a shift from chemistry to a career in software testing may have seemed unlikely, Paul is grateful for the course his life has taken. QualityLogic has inspired his passion to solve the problems he sees now and discovers the challenges yet to come. Paul shares his experiences in QA Engineering and Digital Accessibility often through blogs, presentations, and training of his team and QualityLogic clients.