The goal of accessibility testing

The main goal of accessibility testing is to check if the webpage is accessible to users with different disabilities.

When testing for accessibility, we need to keep in mind that not all users experience a website the same way. Some users might be blind, color blind, deaf, or have cognitive or motor impairments. Blind users will use screen readers, so we need to check that the screen reader programs can read our page and that they can do so in an easily navigable and understandable way. Users with other visual impairments might have issues reading our page if the color contrasts are not properly set or if we use only colors to communicate the meaning. Users with neurological or cognitive impairments might find it difficult to comprehend content that is too flashy or is moving too fast. Content that is presented in an illogical or complicated manner will also be less accessible. Users with motor impairments might have problems with content that requires specific gestures and receives input too fast or unexpectedly.

How to know if a website is accessible

When checking if a website is accessibility compliant, we should refer to Web Content Accessibility Guidelines, aka WCAG.

WCAG is a set of success criteria based on four principles and organized into three different levels (more on that later) that defines how to achieve accessibility conformance. It is peer-reviewed, it is backward compatible, and it is not technology-specific. A success criterion is what determines the conformance to WCAG. That means that WCAG will tell you what you need to do to increase the accessibility of your website, but it won’t tell you how to do it.

For example, guideline 1.1 – Text Alternatives will tell you to “Provide text alternatives for any non-text content so it can be changed into other forms people need”. This means that if a blind person visits the website and there’s an informative chart on it somewhere, we need to provide a way for that user to be able to access the information this chart is conveying. In this case, we can, for example, use an alternative text that the screen reader will read to the user when they reach the chart while browsing the page.

WCAG versions and structure

The current WCAG 2 has several versions, and the success criteria in them are all backward compatible. This means that you can refer to the new 2.2 version when it comes out and not worry if you miss something from 2.0. Here is a quick reference link for WCAG 2.1, where you can filter out the guidelines by levels and other parameters.

The four principles of WCAG are that the website’s content should be perceivable, operable, understandable, and robust. It means that the content on the page: - should be easily perceivable by different types of users, - should be operable in multiple ways (keyboard navigation, mouse navigation), - should be easily understandable (for example, the usage of simple language and intuitive and logical hierarchy of content), - should not break or become inaccessible when used by different technologies (the most basic example here is multi-browser support).

All these principles are defined on three different levels: A level, which is the most basic one and contains the minimum requirements; AA level, which contains A level and expands upon it; and AAA level, which ensures full accessibility compliance. We should focus our efforts on achieving the first two levels – A and AA since the AAA level can be difficult to comply with and covers some very specific cases.

Organizing accessibility testing on a project

There are multiple approaches to accessibility testing, and you will need to find your own, depending on the project specifics. It will depend on the client’s wishes, your familiarity with accessibility testing, the time you will have, and the project’s development phase.

On some projects, accessibility will be a part of development from the start, and on some, it will be brought up later along the road. Either way, accessibility conformance should be a team effort, from design to project management – not just the QA’s responsibility.

While this handbook doesn’t give a one-size-fits-all approach to organizing your accessibility testing way of work, it can give some guidelines and checklists to help you find your way around it. For starters, accessibility testing can be performed manually, by automation, with different testing tools available on the web. While free tools can help you discover some of the accessibility issues on a web page, they will not find all of them. You will have to do most of the job manually. When prioritizing what to test, it would be best to perform accessibility testing as part of your regular testing, but if time is an issue, focus on the main functionalities of your app.