Quick Website Accessibility Testing Checklist

Let’s start with the fundamental question. 

What is Accessibility Testing? Why does it matter?

Accessibility Testing is a software testing technique that checks if a website or app is easily usable by every user on the internet, including individuals with disabilities or special needs. Often considered a sub-category of usability testing, it ensures that specific, unchangeable conditions do not prevent a person from accessing online resources as easily as anyone else. 

Accessibility testing is significant and should be included in testing pipelines for two significant reasons:

• WHO states that 1 billion people live with some form of disability. Even if, say, 20% of them access the internet regularly (and the number is possibly much higher), that’s 20 million people who cannot use regular websites without assistive technology of some kind.

By not optimizing a site for such individuals via accessibility testing, organizations will miss out on major traffic and revenue from their target audience. Additionally, when the world is trying to be more inclusive of differently-abled individuals, a lack of optimization in this regard can make a site or brand look regressive or indifferent to customers’ needs.

• To be more accommodating of people with special needs, many governments have passed laws that require software to be designed with disabled individuals in mind. Some examples of these laws are the Americans with Disabilities Act – 1990, Disability Discrimination Act – 1995 (UK), Disability Discrimination Act – 1992 (Australia), Disability Act of 2005 (Ireland). Accessibility Testing is required for the software to align with these laws. Lack of it can lead to penalties or prosecution. 

This article will focus on providing a checklist to ensure the optimal accessibility of websites. Use this website accessibility testing checklist to verify that a site is ready to be navigated, in its entirety, by disabled or differently-abled users. 

Why run Accessibility Testing on Real Devices?

Before moving on to the web accessibility testing checklist, let’s take a moment to address why accessibility tests should be conducted on real browsers and devices.

Disable and differently-abled individuals need websites and apps to be viewable, perceivable, and usable in specific ways. Unlike other users, they cannot switch over to another website quite as easily since 70% of websites are inaccessible to persons with disabilities (PWD).

If accessibility-related bugs show up when someone is using a website, they will face serious troubles, and may not always be able to find the necessary information at another website. This is especially true of government websites. In the absence of such essential information, these users could face serious problems, which they shouldn’t have to simply because web developers/stakeholders didn’t go the extra mile and run accessibility tests. Additionally, these issues might get missed out on emulators/simulators, due to their limited functionality.

To ensure that such bugs do not show up to end users, execute these tests in real user conditions a.k.a real browsers and devices. BrowserStack’s real device cloud offers 3000+ real browsers and devices for instant access and comprehensive testing. 

Run Accessibility Tests on Real Devices

What to consider when making a website accessible

When running accessibility tests on a website, start with figuring out what the unique needs of specific users might be. For example, the site should be optimized for:

• Vision Impairment: Individuals may have partial or significant trouble viewing a website. They may also have to deal with color blindness or be unable to handle visual effects like flashing effects, strobe-like lights, etc.
  
• Hearing Disabilities: Some users may suffer from deafness or have a partial hearing. Not all of them may be using hearing aids or other assistive equipment.
• Physical Disabilities: Users may have reduced motor functions, making it difficult to operate a keyboard or a mouse.

Of course, other conditions should ideally be taken into account, such as cognitive disabilities and limitations with memory or perception. However, the impairments listed above serve as a good starting point for accessibility testing. 

Accessibility testing requires sites to align with the Web Content Accessibility Guidelines (WCAG). The WCAG seeks to build a singular standard matching needs of differently-abled individuals and the concerns of organizations and government.

The WCAG requires web content (text, image, sound, code, video) to be POUR (Perceivable, Operable, Understandable, and Robust).

• Perceivable: Information must be completely visible to their dominant senses.
• Operable: The UI must work on the interaction that users can perform.
• Understandable: The web content and interface should be easily understood by users.
• Robust: The website should be equipped with assistive technologies to allow for maximum compatibility with users. 

Website Accessibility Testing Checklist

Let’s go over a general list covering the aspects that must be considered and covered under website accessibility testing.

• Insert Alternative Text Tag on Visual Assets

Users with visual impairments require screen readers to interpret web content. However, screen readers do not actually translate images. They read the underlying code and convey what the image contains to the user.

Ensure that the ‘alt’ text attribute is in place for each image tag. This will allow the screen reader to read the image description aloud. Otherwise, the user will miss out on a significant part of the website’s offering.

• Add Contrasting Colors

If colors on the website do not sufficiently contrast, it might be difficult for visually impaired users to perceive them. WCAG recommends 1.4.3 Contrast (Minimum), 1.4.6 Contrast (Enhanced), 1.4.11 Non-text Contrast.

• Accommodate Keyboard Navigation

Individuals with reduced motor functions may not be able to use a mouse or use a keyboard. They may require assistive technology such as voice-operated commands or a sip-and-puff device. Websites should be optimized to accommodate such necessities.

• Resize Text to be Viewable

This is undoubtedly more of a challenge for designers, but ideally, the text should be large enough to be viewable to users with low vision. The text does need to align with images and links without visual and functional anomalies, which doesn’t make it the most straightforward task in the book.

• Interactive Elements should be operable

Elements such as drop-down menus, clickable images, etc., should be operable via keyboard or voice commands (for those with limited motor function). Ensure that they can be operated via assistive devices without issue.

• Improvise with Headlines and Descriptions

Each web page should have a unique title that clearly describes the page content. Again, this helps screen readers translate the page a user is on. Use header tags (H1, H2, H3) to demarcate content and help users read and absorb with greater ease. Clearly marked sections make it convenient for readers with cognitive disabilities. Headers also let screen readers vocalize the page the same way a reader would go through it.

• Add Subtitles and Captions to Videos

Videos should have clear captions (ideally, in multiple languages) so that users with compromised hearing can clearly understand what is being said. This isn’t just useful for anyone suffering from deafness, but also for someone who might want to consume video content in a public space with no earphones. They can simply read the subtitles and get what they need without bothering anyone with noise.

• Flashing Lights or Blinking Bright Elements

Flashing lights or any elements that are both blinking and bright might trigger seizures for anyone stricken with epilepsy or similar conditions. Generally, having such aesthetics won’t look too good on a site or app, but if you must implement them, ensure that brightness, flashes, and blinking is not too intense or oppressive so as to trigger any episodes.

How to solve this? Run Quick Accessibility Tests on BrowserStack

On BrowserStack’s real device cloud, QAs can run both manual and automated accessibility tests. 

• To run accessibility tests manually on BrowserStack Live, sign up for free, choose the real browser-device duo you want to test on, and use the Screen Reader feature for non-visual navigation testing.
• To run automated accessibility tests, use axe, a fast and lightweight tool that checks a document against accessibility rules and guidelines, and generate a report highlighting any violations and pointing out the aspects for which guidelines have been met. 

By running accessibility tests on websites with Automate and axe, you can verify if a site complies with the WCAG and other guidelines (as verified by the axe-core library), ensuring your website is accessible to all users on the Internet. 

As mentioned before, all accessibility tests on BrowserStack will be executed on real browsers and devices – both latest and older models. This includes multiple versions of all major browsers (Chrome, Edge, Firefox, Safari, IE and more) as well as thousands of desktop and mobile devices (Android, iOS, Windows). You won’t have to limit your tests with the inadequacies of emulators and simulators.

Try Accessibility Testing on Real Device Cloud 

Accessibility testing is essential to make software inclusive and cater to users with alternative requirements due to specific conditions. To ensure that none of your users are unable to get the best of your site or app due to insufficient testing, include accessibility tests into the QA roadmap right from the beginning i.e. the brainstorming phase. As the world moves towards more considerate and empathetic approaches towards customer care and success, accessibility tests are poised to become an essential part of any software development pipeline.