Go mouse-less for an hour – Insight into Accessibility Testing

Computer mouse has become a device that plays a significant role in the IT industry. It truly does wonders to make our work easier. Yet, I’d like to challenge you all to use only the keyboard for navigation purposes for an hour and surf your web application or system to get a completely new level of experience.

Now it’s time to think about an answer for the following question.

Did you come across any obstacles or difficulties when using your application without a mouse?

This is one instance where Accessibility Testing comes in to our picture.

Image 01: Considering the user’s perspective of Accessibility

Why is Accessibility Testing Important?

It is important to ensure that our product innovation deliveries are done to everybody who consumes it including people with special needs. According to World Health Organization, over a billion people (about 15%) around the world have some form of disability. Did you ever assume the percentage to be this high? These users might be the users of your application as well.

If technology empowers individuals with special needs, it has a great ability to inspire their lives in various ways. By performing Accessibility Testing, we can ensure that everyone regardless of the age or the ability can use any application. So that no one will be missed out from this digital era. This is why Accessibility Testing is needed!

Further, Accessibility Testing is not only focusing on validating usability aspects, but also it ensures that an application can be accessed by people with several disabilities including visual, auditory, speech, physical, cognitive, learning, language, and neurological disabilities. Besides, being on the IT industry, it is our responsibility to implement software products beyond the traditional standard rules. So that it can be accessed by anyone and everyone!

Image 02 : Accessibility Testing

How to Perform Accessibility Testing?

Accessibility Testing can be done using both manual and automated testing methods. However, it involves in depth manual test inspection of individual pages & all the functionalities in order to do an effective Accessibility Test. There are various online tools which can be used for Accessibility Testing. Some of the accessibility technologies include speech recognition software, screen readers, screen magnification software, braille embossers, voice recorders, special keyboards and many more. By using Assistive Technology, we can support people with disabilities to perform activities they were previously unable to do or had difficulties in accomplishing.

Test Strategy and Approach:

In the beginning of Accessibility Testing, it is normal to feel it as a struggle. Reason being, the team members are required to use solely the keyboard. This could be tricky to start with as we are so used to rely on keyboards. However, when you start to work with screen readers, that experience itself would feel like a whole other world.

Accessibility Testing can include:

Reviewing the application structure
Example – Reviewing header navigation & header order
Testing keyboard compatibility
Example – Verifying tab order index
Testing media
Example – Audio/video and captions
Testing assistive technology devices
Example – Using screen readers
Real user experience monitoring

Legal Compliance

An interesting fact is that government organisations around the world have come up with legalizations with related to Accessibility aspects. It requires the software products to be accessible by people with special needs. Therefore, Accessibility Testing is important to ensure these legal compliances in order to avoid potential lawsuits. At the moment you might feel like making your product accessible isn’t a necessity. Yet, it sure will be in the future. You could be charged for violation fines which can really damage your company financially.

Web Content Accessibility Guidelines (WCAG)

WCAG contains a series of guidelines to improve Web Accessibility. Whether the testing is automated or manual, compliance check should be done according to Accessibility Testing guidelines. This is an essential part when working with accessibility. There are several standards for accessibility. Such as,

W3C’s WCAG 1.0
W3C’s WCAG 2.0
Section 508 etc.

Out of all these guidelines, WCAG 2.0 is accepted worldwide. These standards provide information on how to make a web application or system accessible. Design, Development &Testing should ideally be compliant to these accessibility guidelines.

WCAG is based on four principles

Principle 01 : Perceivable
Information and user interface elements should be delivered to users in a way that they can process and understand. Example: By providing text alternatives for non-text content, it can be easily transformed into other forms of communication such as large print, braille, speech, symbols or simpler language.

Example: By providing text alternatives for non-text content, it can be easily transformed into other forms of communication such as large print, braille, speech, symbols or simpler language.
Principle 02 : Operable
Users should be able to successfully use buttons, controls, navigation & other user interface components.

Example: Keyboard focus should be implemented in order for a keyboard user to follow the links to social media sites of an application.
Principle 03 : Understandable
Information given in the user interface and how to operate the system should be easily understandable.

Example: Required fields in a registration form could be presented with an asterisk mark. If there is no such indication, user will not understand the reason why the form cannot be submitted.
Principle 04 : Robust
Application should be designed to operate on a wide variety of technologies. Customers should have the flexibility to choose the technology they prefer to interact with the application and it’s content.

Example: An application requires a specific browser version to make use of its functions. If user does not have that particular browser version installed, then there will be no way for that user to experience the features of the application.

Myths

There are several myths around accessibility. Establishing an accessibility culture in project teams might be challenging as it requires debunking these myths. Let’s have a look at some of those misconceptions.

MYTH 01: A small percentage of your audience will need an accessible web application.

REALITY: Not even close! Accessible applications can be useful and benefit users more than you may realize. It is not necessarily needed to have some form of disability in order to get the benefit of it.

Example of the benefited individuals:

Elderly population
Users with low vision or hearing
Users with cognitive limitations
Users with neurological disabilities
Users with situational or temporary disabilities
Users with physical disabilities

MYTH 02: Web accessibility is time-consuming, expensive and extra effort is needed.

REALITY: Not really! It is important to focus on accessibility implementation and testing from the very beginning of the development life cycle. It should be initiated during the Design & Development stages. That way you can save time, effort, and cost in the long run. However, if you wait to test accessibility at the end, major rewrites could be needed from the design itself to make the site accessible. So being a little proactive about accessibility from the beginning would benefit the whole project.

MYTH 03: Accessibility will be guaranteed just by using automated testing tools

REALITY: Apparently not! Accessibility testing tools could be very needful and helpful. Yet, these automated tools cannot replace manual testing. Usage of automated testing tools will be effective only when it is coupled with manual testing as many of the WCAG checklist points cannot be solely tested by using tools and it requires human judgment. Hence we cannot purely rely on tools. Manual testing is also required with the right balance in order to develop your application truly accessible.

Example: A tool has the capability to test if an image has an ALT text description. Yet, the tool is not able to verify whether the given description is meaningful.

MYTH 04: Tend to believe that accessibility testing cannot be automated.

REALITY: Truth is that running a browser extension or integrating an accessibility tool in an automated test is a simple step. Frameworks such as Appium & Selenium can be easily used for accessibility test automation with easy maintenance as they are platform independent. Even though manual testing is essential for accessibility, a certain portion of the test scenarios could be automated. At the same time there could be certain accessibility test scenarios which cannot be automated at all. Therefore, identifying the test automation scope correctly is important.

MYTH 05: Only developers are responsible for ensuring Accessibility.

REALITY: Ensuring accessibility is a responsibility of every single person in your team. Not just the Developers or QA. This process should be done as a collaborative activity with the help of Project Managers, Business Analysts, UI/UX Engineers, Developers and QA. It will be more efficient and compliant if Accessibility is applied into the team culture.

Wrapping Up

Now it is the best time to debunk all the accessibility myths you had all these years and start applying it to your applications today. It would create a wonderful experience among your team and your customers.

As Google says, “Everyone should be able to access and enjoy the web. We’re committed to making that a reality.” Point well taken! Good accessibility is directly proportional to a delightful customer experience. It is our responsibility to make it a reality!

References

Disability and health :
https://www.who.int/news-room/fact-sheets/detail/disability-and-health
Web Content Accessibility Guidelines :
https://en.m.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
Accessibility Principles:
https://www.w3.org/WAI/fundamentals/accessibility-principles/
Google Accessibility :
https://www.google.com/accessibility/
Image 01 Source:
https://dynomapper.com/blog/27-accessibility-testing/275accessibility-testing-considering-the-user-s-perspective-of-accessibility
Image 02 Source:
https://dynomapper.com/blog/27-accessibility-testing/275-accessibility-testing-considering-the-user-s-perspective-of-accessibility