Website Accessibility Testing Checklist
A quick checklist to run accessibility testing on your website. Assess website accessibility by keeping these guidelines in mind. Check out the list.
Join the DZone community and get the full member experience.
Join For FreeAccessibility 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.
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 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. Check out Screen Readers for Accessibility Testing.
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.
Published at DZone with permission of Shreya Bose. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments