Prioritization of accessibility problems

Customers are often overwhelmed by the test reports, which are by the way poorly prepared. Due to scarce resources, the first question is often how to prioritize the findings from such test reports. There are various approaches that I would like to present here. Some of these approaches can also be used for project-related implementation of accessibility, but as I said, the focus is on implementing findings from tests.

In general, it must be said that the consultant can do the prioritization, at least with most of the methods presented here. As a rule, however, the customer must also be involved. The consultant cannot know the customer's internal processes in detail, nor the resource planning. It may be worthwhile to design the presentation of the test results in such a way that all relevant parties are involved and at least the major problems can be integrated directly into the project planning. With good moderation, something like this can be done in 1.5 to 2 hours. Pre-sorting would be important here; there is no point in discussing and prioritizing all the findings.

If you want the consultant to prioritize, you should include this directly in the assignment. I always had this integrated directly in my reports, but I can't speak for all consultants. You can also ask for a sample test report to determine how well you can work with it. PowerPoint, for example, may be good for presentation purposes, but it is bad for clarity, filtering and sorting, or transferring to ticket systems.

Prioritization means that you weight the problems so that you can solve them one by one. This does not mean that you simply let lower-prioritized problems fall to the back.

Prioritization according to WCAG criteria

Prioritization according to WCAG criteria is the simplest form. It can be carried out directly by the customer, since the test reports usually state which conformance level the problem is assigned to.

Since A criteria are considered an absolute must for an accessible application, they can be prioritized over AA criteria, which are mandatory in most countries but have less weight than A criteria.

The advantage of this is that you have an objective assessment, whereas all the other methods presented are based on expert assessments but are subjective to a certain extent.

Prioritization according to severity

Prioritization according to severity usually requires that you have a good knowledge of digital accessibility. However, the service provider can take care of this, as it is a small additional effort for them.

How is the impact estimated? There are several indications for this:

  • It affects important components of the website, for example components that appear on every subpage, such as the main navigation. Or it affects an important component, such as the contact form.
  • It is a problem that completely excludes certain groups. One example is a keyboard trap in an important component. The footer, for example, is usually not an important component, but the search mask is.
  • It is a problem that affects several components or target groups, for example limited usability via keyboard.

Division by roles

Division by roles can also be useful. I differentiate between design, development and editorial. For example, it is usually easier to fix editorial problems than design or development problems. The service provider can also take care of this, but usually the person responsible for the project has a deeper insight into the internal processes and the service provider can only make an assessment.

A clean separation is not always possible. Sometimes it happens that editorial texts have been hard-coded in, so an editor cannot get to them. The design can theoretically be changed easily, but often requires lengthy discussions and must ultimately be implemented by the development team.

Prioritization based on simplicity

From the perspective of those affected, this is not necessarily the best option, but sometimes makes sense: Prioritization is based on what can be fixed most easily. The advantage is quick wins for the customer, which may motivate them to continue. However, a problem should not be neglected because it is difficult to fix.

The prioritization square

A combined approach is the prioritization square, as I would like to call it for lack of other terms. Imagine a square divided into four sections.

  • Top left are the problems that are easy to fix and have a big impact.
  • Top right are the problems that are easy to fix and have a little impact.
  • Bottom left are the problems that are difficult to fix but have a big impact.
  • Bottom right are the problems that are difficult to fix and have a little impact.

Prioritization goes from left to right and from top to bottom.

Incidentally, in my experience there is no connection between the severity of a problem and the effort required to fix it. The fact that some developers have problems improving keyboard usability is not because keyboard usability is difficult to implement. It may be because they have no experience with the topic and need to learn it, or because they did not implement it from the beginning. There are countless patterns for this and other challenges.

More on Testing & Evaluation