How to choose pages/screens for an Accessibility Test

The first Question in an accessibility Evaluation is, how to define the scope of the test. Clients and some service providers tend to set the scope as large as possible. Clients do this because they don't want to make mistakes or misjudge the testing effort and thus the costs. Service providers do this because they want to generate as many billable hours as possible.

This article is about how to define the scope sensibly for clients and service providers.

Content website

A typical content website consists of a few templates or components. The following pages are always included in the scope:

Home/start pAge
A simple content pAge
A complex content page, e.g., with a table
A form page, if available

In our experience, the number of components is so large that it's impossible to test them all. Most of them are rarely or never used anyway. Therefore, it makes sense not to test all components. Rather, only those components that are actually used regularly should be tested.

Process-based websites

I call process-based websites when a process is carried out in a specific order. Examples are online shops or banking. Here, the entire process is usually tested, from the login page to checkout. Experience has shown that errors only repeat themselves after the third page. For a reduced test case, it is therefore useful to test all components such as checkboxes, dropdowns, and so on once.

eLearning

E-learning offerings are a special type of website. They can consist of countless subpages. In this case, I would recommend building the homepage and a separate page with all the components used, such as single choice, multiple choice, drag-and-drop, and so on, which should be filled with real content.

The Exception: Inconsistent Components

Pages or screens that weren't built with recurring components pose a difficult challenge. This shouldn't happen anymore, but it still does. As an outsider, you usually don't know. In this case, the developers have to identify which screens or subpages contain such components and need to be tested.

This also applies if third-party components such as cookie banners were used. They must be tested separately because, as a developer, you usually have no influence on their code.

Documents

Documents are usually the most proliferated. They are usually published and prepared by different service providers. Unfortunately, no useful recommendation can be given here, except that every document type, such as brochures, flyers, and forms, should be tested at least once.

Conclusion

The goal should be to keep the test scope representative, but as concise as possible. The client or their development team must then manage the transfer and identify which errors might occur on other screens and components based on the report.

The goal of accessibility testing isn't to find every minor error; that's not productive. Rather, the goal is to find structural, recurring, and serious errors. The rest is quality assurance, training, and error prevention.