During our first steps as A11Y testers, we learnt a lot that we would like to share with the QA community. In this article, we will talk about our experience as quality assurers when we are faced with the challenge of starting to include accessibility testing in our projects.
As Quality Assurers we are often asked the following questions:
- Why is accessibility testing important?
- How do you start with accessibly testing?
- What are the best practices to approach it?
The aim of this article is to answer these questions by explaining what accessibility testing is, what it means to be accessibility compliance, while also examining A11Y use cases, and useful QA tools to help you along your way.
Come join us
Interested in working with innovative technologies? We're hiring!
What Is Accessibility Testing?
Accessibility testing is a type of non-functional manual and automated testing that is derived from usability testing.
When we validate "accessibility", we are attempting to corroborate that the system is usable by as many people as possible, especially for people with disabilities, such as vision impairment, hearing disabilities, and any other physical or cognitive conditions.
When conducting accessibility testing, we focus on validating that the system complies with the following principles:
What do Accessibility Testing Principles focus on?
These principles that we follow during our accessibility testing look for the following traits:
Perceivable:
The content must be available to users via sight, hearing and/or touch.
Operable:
The system must be keyboard accessible, navigable and compatible with different input methods.
Understandable:
The content must be readable and predictable, with clear labels and instructions.
Robust:
The system must work with variety of assistive technologies, browsers and devices.
What does it mean to be Accessibility Compliance?
As touched on, accessibility testing is required to meet the needs of all users, specifically those with disabilities.
This is not a mere personal whim, but it is also about validating that our system complies with the following laws:
Americans with disabilities (ADA):
This law states that all domains like public buildings, schools and organizations should make the technology accessible to everyone.
Rehabilitation Act, section 504 and section 508:
Section 504 accommodates all people with disabilities to access workplace, education & other organizations and section 508 accommodates access to technology.
Web content accessibility guidelines (WCAG):
These guidelines suggest ways that can help to improve the accessibility of a website.
A11Y Testing Use Cases
As QAs taking our first steps in this type of testing you may ask yourself where should I start, and should I keep an eye on?
Here are some A11Y testing scenarios:
- Labels - Used by assistive technologies, such as VoiceOver or TalkBack.
- Text contrast - Ratio of text or images to the background color.
- Impact area size - Area designated for user interaction.
- UI view hierarchy - Determines the ease of navigation of the Android application.
- Dynamic font size - Option for users to increase the font size to fit their needs.
Are you familiar with other A11Y use cases? Let us know of any in the comments section.
Empowering manual and automated testing
As with all forms of testing, accessibility testing is something that you will get used to with practice. It is important to know that manual accessibility testing is fundamental and one of the best ways to ensure that a system is accessible. This is mainly because there is still no tool that can replace human understanding.
Therefore, manual testing is essential to detect problems that cannot be detected by automated tests, as the latter often cannot cover all scenarios, or their reports may include false positives and negatives.
In saying that, we emphasize that manual accessibility test results are considered much more reliable and trustworthy than those that are 100% automated. Does this mean that it is not advisable to do automated accessibility testing? The answer is simple...no.
Manual and automated testing are always complementary and are certainly an excellent strategy to optimize time, effort, and resources. Relying on tools that can be used to automate, can quickly provide you with some information about the degree of accessibility of the system.
There are many tools available and it will be part of your journey to investigate which ones can be the one that best suits your project and its needs. The following are some of the most renowned and popular: Lighthouse, axe, WAVE, JAWS, WebAIM, and the W3C toolbox.
Final tips on Accessibility Testing
As a best practice, we suggest that you always make sure that someone in your team understands how to interpret the results of an automated testing tool as well as knowing how to apply the correct solutions.
It's also important to keep in mind that while the results generated by automated testing tools may be more global or generic, a report written by an accessibility expert will always be specific to the system, and will include realistic and tailored solutions based on the needs of the project.
We hope that this breakdown on accessibility testing will help you on your QA journey no matter what stage of your career you find yourself in. Thanks for reading and stay tuned for more QA related tips and content from the Rootstrap team!
