Web Accessibility — What does it mean and how to test it?

In this article, I will be talking about web accessibility what it is and how we can make our website more accessible; for users with different disabilities using various tools to access the website. Then I will focus on how to prove that our website is accessible to everyone, what are the available tools, and outline what we are using in the QA team in Actum’s Apollo division for testing.

What is Web Accessibility and why we should care about it?

Web Accessibility focuses on helping people with various disabilities like cognitive, auditory, neurological, etc. to use web applications without being limited or frustrated, as effectively and user friendly as possible.

There are many tools that help people with disabilities to use their personal computers like screen readers, braille keyboards, etc. These tools a properly implemented application for their proper working.

Fortunately, these standards and guidelines are described in detail for example here. Thanks to these standards you are able to implement your application the way that it can be used for most of the tools.

Web Accessibility not only helps people with disabilities but also in other areas like, for example:

• Web Accessibility helps to improve application design by making pages well-arranged, avoiding bad color combinations, simplifying page content, etc.
• Another benefit is opening your application to a broader audience by making web applications easy to use.
• The improved design makes your page usable on a wide pallet of devices such as mobile phone, tablet, laptop, desktop. Also, it brings better support on most used browsers like Chrome, Internet Explorer, Firefox, etc.
• Web accessibility also helps developers to improve their code quality and make it more unified.

Testing web accessibility

To test web accessibility, you can use actual software tools used by people with disabilities like screen readers. To test if your web application is following the Accessibility rules on your application, you can use scanners that will go through the page and report back “defects”. Let’s look at some available tools.

• a11y project is a community-driven effort to make digital accessibility easier. This project helps to introduce a variety of tools, books, guidelines, etc. all of which you can find here.
• Deque axe is the standard in Accessibility Testing. Axe is composed of tools like DevTools, Monitor, Auditor, etc. that are helping to test accessibility on your solution. You can find more information here.

Those are basically two main sources of tools used for accessibility testing, but I would like to also mention a couple of others.

• Lighthouse is an open-source Chrome extension which is an automated tool for your web pages.
• WAVE is a suite of tools for evaluating web accessibility. The suite contains extensions for browsers, API, web page.
• SortSite is a web page scanner following W3 WCAG accessibility standards.

CI/CD of web accessibility testing

In Actum’s Apollo division we were looking for an automation accessibility tool that is easy to use and can be integrated into our CI/CD on projects without complicated implementation.

We are using axe cli and axe core which are parts of axe DevTools. Axe DevTools is used by companies like Google or Microsoft. It is well documented and quite easy to use, and we were able to integrate into our pipelines, so it fulfilled our requirements.

What does the solution look like? I will describe the solution to you from a pipeline perspective in the following sequential steps.

1. The first step is to install Node.js if you do not have it already.

2. Now let’s execute a scan on your page with help of axe cli example of command axe www.deque.com, but it is not enough you need to get results so you need to add - - save results.json

3. Now we have JSON with results, but it is not exactly a nice human-readable report. To have a better report I implemented a console app that will generate HTML report for us. We need to install NuGet packages and build our console app

4. In this step, we are executing our console app. My console app needs the JSON result file path and output Html file name. The reason the HTML file output name needs to be defined is because of distinguishing between results from different executions. That is why I am adding date, time, and build to report name.

5. Now we have the HTML report. Console app cleaned data from JSON from unnecessary content to only important data. The final form you can see below.

The report is composed of four main categories:

• inapplicable - contains rules which were not suitable for scanned pages
• incomplete - findings which need manual review so “scanner” was not able to say if it is right or wrong
• passes - the rules which were fulfilled
• violations - the most important section which contains everything that needs to be fixed in QA terminology defects.

6. The last step is to store the HTML report. You can use whatever storage you want. In our delivery unit, we are mainly using Azure blob storage due to the needs of our projects.

Briefly, that is our solution which we are using on our projects and also the end of this article. Thank you for reading!

We are ACTUM Digital and this piece was written by Vlastimil Matějka, QA Team Leader of Apollo Division. Feel free to get in touch.