Accessibility testing is a topic not often discussed at QA conferences and meetings. In September our Senior QA Engineer and Head of QA Department Anastasia participated in the first web accessibility meet-up with a presentation about accessibility testing. Using the opportunity, we would like to draw your attention to this subject: what accessibility testing is, why we have to make web accessible and how we can do that, and what false myths obscure our understanding of the theme. 
Accessibility testing — what is it?
Accessibility testing is a kind of testing performed to ensure that the tested application can be used by hearing or vision impaired, colour blind, elderly people and other groups of users with special needs. So accessibility testing is an aspect of usability testing.
How is digital technologies’ accessibility expressed in the world where almost everything leads us to web one way or another? For one thing, people with special needs use technologies helping them to deal with software. Here are some examples of such utilities:
- Software for speech recognition — converts voice commands into text, which is received by a computer in an input field;
- Software for reading off the screen — reads aloud the text displayed on the screen;
- Software for scaling-up — scales up the content displayed on the screen, making reading easier for vision-impaired people;
- On-screen keyboard — makes entering text easier for people with fine motor skills issues.
However, people with special needs should ideally use software at their ease without any special utilities, and it lies in our power to make it real.
Why is it necessary to test accessibility?
1. Address people with disabilities as part of the audience
About 20% of the population are people with special needs. It means permanent disabilities (handicap, health deterioration with the increasing years) as well as temporary conditions: trauma, need to hold a child in the arms, work outside by too bright sunshine and even hangover.
2. Law compliance
Governments of many countries ordained that IT products should be accessible for people with special needs.
Therefore, according to such acts as:
- United States: Americans with Disabilities Act — 1990;
- United Kingdom: Disability Discrimination Act —1995;
- Australia: Disability Discrimination Act — 1992;
- Ireland: Disability Act of 2005;
- Russia: Federal Law of 24 November 1995 N 181-FZ (edition of 18.07.2019) "Concerning Social Protection for Disabled Persons in the Russian Federation", Article 14. “Unhindered Access to Information for Disabled people”;
accessibility testing is mandatory to comply with the laws.
What kind of special needs should be considered?
There are quite a few (not only) health-related conditions that can impact the user experience. We’ll name just a few of them as examples.
| Type of disability | Examples |
| Vision disabilities |
|
| Physical disabilities |
|
| Cognitive disabilities |
|
| Hearing disabilities |
|
| Reading disabilities |
|
How to test accessibility?
1. Manually
There is quite a number of ways of accessibility testing depending on the disability type. But such testing ways can turn out difficult for testers without disabilities, this is why a good practice would be working with people with disabilities (given the opportunity), in order to understand which difficulties they can encounter in their user experiences.
If the company doesn’t have a possibility to engage people with special needs into accessibility testing, there is still hope: a good many guidelines for accessibility testing are written for people without disabilities. The easiest way is “shutting out” your senses by turns: trying to use the application without sound, with different degrees of clarity, contrast and saturation of the screen (or even not being able to see the screen at all — for the most responsible ones), using ONLY the mouse or ONLY the keypad etc.
Another way is to benefit from available checklists. For example, such as the one provided on the site guru99:
- Whether an application provides keyboard equivalents for all mouse operations and windows?
- Whether instructions are provided as a part of user documentation or manual? Is it easy to understand and operate the application using the documentation?
- Whether tabs are ordered logically to ensure smooth navigation?
- Whether shortcut keys are provided for menus?
- Whether application supports all operating systems?
- Whether the response time of each screen or page is clearly mentioned so that End Users know how long to wait?
- Whether all labels are written correctly in the application?
- Whether the color of the application is flexible for all users?
- Whether images or icons are used appropriately, so it's easily understood by the end-users?
- Whether an application has audio alerts?
- Whether a user is able to adjust audio or video controls?
- Whether a user can override default fonts for printing and text displays?
- Whether a user can adjust or disable flashing, rotating or moving displays?
- Check to ensure that color-coding is never used as the only means of conveying information or indicating an action
- Whether highlighting is viewable with inverted colors? Testing of color in the application by changing the contrast ratio
- Whether audio and video related content is properly heard by the disability people? Test all multimedia pages with no speakers in websites
- Whether training is provided for users with disabilities that will enable them to become familiar with the software or application?
It is also not forbidden to add your own points: the more possible needs are taken into account in testing, the larger audience your product is meant to cover — and that’s what our final goal is.
2. Automatically
There are quite a lot of tools that can be used for checking software for compliance with accessibility requirements. Below we will introduce some of them as examples so that you could get a look at them on your own:
- Wave
- TAW
- Accessibility Valet
- Accessibility Developer Tools
- Quick Accessibility Page Tester
- aDesigner
- WebAnywhere
- Web accessibility toolbar
Myths about accessibility testing
If accessibility testing is so requisite and hypothetically not too complicated, why hasn't it become obligatory and common praxis as yet? Unfortunately, accessibility testing is still hooped by myths and superstitions. Let’s explore some of them.
Myth: creating an accessible web site is expensive
Fact: it’s not more expensive than any other part of the site testing: the question is, on which stage we start to worry about this side of the quality assurance. It is possible to ensure accessibility beginning from the application’s design stage (mock-ups review and their adaptation for accessibility as early as the design phase), at the same time the testing can be started. It will help to save money as well as time for reworks.
Myth: making an accessible site out of an inaccessible one is expensive and requires a lot of work
Fact: you don’t have to implement all modifications at one time: it will be sufficient to begin with the most important ones. Start with the basic tasks, providing people with special needs with the most necessary ways of interaction with your product.
Myth: accessibility is dull and boring
Fact: accessibility doesn’t mean only one high contrast text page (on the contrary, World wide web consortium doesn’t recommend to use only text on pages). Ensuring accessibility is also a designer challenge: how to make your website attractive and accessible? How to improve user experience, not violating compliance with guidelines on accessibility for all users (see W3C standard: https://www.w3.org/WAI/)? Solving such tasks will definitely not be boring.
Myth: accessibility is only for people with disabilities
Fact: following accessibility standards enhances the general quality and usability of software, which also helps users without special needs. We already mentioned that each of us can happen to be a person with special needs due to an injury, stress or certain circumstances. Moreover, we are all going to grow old sooner or later, and it lies in our power to ensure ourselves a comfortable future where we won’t have to refuse new technologies because of their unavailability and unadjustment to our needs.
