11 Tricky Moments and Useful Tips of Accessibility Testing

Accessibility testing like any other kind of testing has some specific features that would be advisable to take into account before testing is started. Below you can find tips and tricks related to the accessibility testing process.

1. Discuss with a customer the necessity of accessibility compliance at the proposal development stage. Define what causes such a necessity (desire to increase the number of potential users, customer’s internal policies, legislative requirements, etc.) and the accessibility level that needs to be reached. This allows you to properly plan further development and testing activities.

2. Plan and design application architecture keeping in mind the required accessibility level to avoid or at least reduce possible expenses and the waste of time caused by further rework. Not all solutions, technologies, and third-party components (if you are going to use some) can provide accessibility at a sufficient level. Ignoring accessibility compliance at this stage can lead to serious overruns in the future (up to a complete application redesign).

3. Determine who your application end users are in order to define the list of main disabilities that they may have. It will allow you to focus on features, which might be the most important for people with such kinds of disabilities, as well as on main aspects of the usage, which are specific to these users.

4. Be aware of all project parts in order to implement all of them in an accessible way. If it is impossible to do so, agree with the customer beforehand that they will be beyond the scope for accessibility support. It may involve various types of documents generated by the developed system, notifications sent by email, content of attached files, etc. In addition, you have to remember about such rarely used application parts such as, for instance, a 404 error page, etc.

5. Take into account all third-party components, which will be presented only within a production version or which will contain real content only on production.

• Example 1: version under test might not contain CAPTCHA that will be available on production and which should be verified as well.
• Example 2: advertisement section of a website (if any) may contain blinking ads that may lead to an epilepsy attack for a user.

6. Use WCAG as the main guideline to carry out accessibility testing. Despite the fact that this standard aims to ensure web-content accessibility, most of its recommendations can be applied to all other application types.

7. Probably the most complicated part of the accessibility testing is verification of an application with screen reader tools. The following sub-block contains some advice related to usage of screen readers:

• Some commercial testing tools provide a free of charge mode, however this will require a periodic restart of the computer after a certain time (usually every 30-40 minutes). Thus, it can be much more convenient to perform testing on a virtual machine to make the reboot process much faster and easier.
• Behavior of most testing tools (especially with rich functionality) depends on their settings, which are usually quite wide as well. Start by investigating the options to define the mode that best matches your purpose.
• If you use a screen reader tool, it is not convenient to deal with content listening, especially if you are testing an application that uses a language that you do not speak. Use the speech history or speech viewer functionality of your screen reader to make the testing process easier.
• Be aware that various combinations of testing tools can provide different results (e.g. different combinations of screen readers and browsers) and different levels of reliability with the results. For testing, try to use the same tools that end-users will use to access your application. The most commonly used screen readers as well as their combinations with different browsers can be found on this page of the latest Screen Reader User Survey #8 (September 2019) conducted by WebAIM organization.
• Keep in mind that third-party tools can also have their own issues, so incorrect behavior is not always related to a tested application and it can depend on the testing tool that is used.

8. There are a lot of tools that can perform accessibility testing (at least of some type) automatically. However, keep in mind that it is impossible to check all aspects of an application accessibility automatically – human judgment and experience are indeed necessary for that.

Automatic evaluation tools cannot determine whether an application is accessible or not, they can only assist in that. In addition, results provided by these tools can sometimes be erroneous or misleading.

9. Thus, automated accessibility testing alone is not sufficient – you will still need manual testing to ensure your content is actually accessible.

10. Be aware that there are 2 kinds of gestures that are used on mobile devices when the accessible mode is turned on:

• gestures addressed to accessibility tools;
• gestures addressed straight to an application (they differ from those that are used in an ordinary mode and which are familiar to most of us).

These features should be considered at the design stage. If you are going to use some specific custom gestures within your app, make sure they do not overlap with the standard ones of both types mentioned above.

11. Keep in mind that if it is impossible or difficult to use just one of the components of an application, it can make it useless for a user with a disability.

The involvement of people with disabilities for testing allows you to appreciate the usability issues these people may face when accessing your application. Users should be skilled but not experts, with their assistive technology. Bear in mind that people with disabilities may require more time to complete tasks and they may need some time to familiarize themselves with the application before attempting to use it.

Visually, the main flow of the accessibility testing process can be presented as follows:

Picture 5. Main steps of accessibility testing flow

Summary and Conclusion

Accessibility support, as well as accessibility testing, is becoming an integral part of a development process for an increasing number of applications in the modern world. Accessibility compliance is not always a cheap and easy process, but we can make it easier and less expensive if it is properly planned. The basis for compliance with accessibility standards needs to be laid out as early as possible for any project to make the development process more efficient.

Keep in mind that accessibility testing is just one of the assistive technologies that defines issues which already exist.

The only way to avoid such issues and achieve higher accessibility is to lay out the relevant practices at the design and development stages. Experience has shown that further implementation of accessibility features can be unreasonably expensive if it has not been done from the outset of a project.

• #Establishing Quality Process
• #Industry Standards Compliance
• #Mobile Solutions
• #Software Testing