Prioritize the barriers that stop users—not the deviations that are easiest to count

Category: Accessibility

An accessibility audit can produce a long list of deviations. The problem is that the list rarely tells the organization what to fix first. Poor contrast in a decorative detail, an incomprehensible error message in an order form and a menu that cannot be used with a keyboard can all be deviations. The consequences, however, are very different.

A more useful prioritization therefore does not start with the number of errors, but with the question: Which barriers prevent people from completing the most important tasks on the website?

This approach does not replace WCAG. The guidelines provide necessary and testable requirements. But when time and budget are limited, you also need a method for choosing the right order in which to carry out the work.

Start with tasks, not individual pages

Users rarely come to a website to assess a single isolated page. They need to find a service, understand the terms, fill out a form and receive confirmation that their enquiry has been submitted. A barrier early in this chain can make the rest of the solution irrelevant.

First, choose three to five tasks that are important to both the user and the organization. These could include:

• ordering a service or product
• submitting an application or enquiry
• finding prices, opening hours or contact information
• changing an existing agreement
• reading important information about rights or deadlines

Then describe the entire journey for each task. Include navigation, information pages, logins, forms, error messages and confirmations. This makes it clear where a technical or visual weakness actually breaks the user journey.

Assess each task through four user needs

For each critical task, you should examine whether the user can perceive the content, understand it, operate the solution and recover from errors. These four questions make it easier to connect WCAG work to practical design and development.

1. Can the user perceive the content?

Look for information conveyed only through sight, color or sound. Low contrast can make text, buttons and form fields difficult to detect. Missing text alternatives can hide the meaning of images from screen reader users. Instructions that only point to the red box work poorly for people who cannot perceive the color.

Check contrast with measurement tools, but also assess the solution in actual use. Text that technically meets a minimum requirement can still be difficult to read when placed over an image, set in very thin lettering or viewed on a mobile screen in daylight.

2. Can the user understand what will happen?

Accessibility is also about language, sequence and expectations. A button labeled “Continue” says little if the user does not know whether the next step is payment, confirmation or more questions. Long paragraphs, unclear headings and unexpected changes make the task more difficult for many people.

Use specific field labels and action-oriented buttons. Explain why you are requesting information when the need is not obvious. Divide extensive forms into understandable sections, and show users where they are in the process.

3. Can the user operate the solution?

All essential functions must be usable without a mouse. Test with Tab, Shift and Tab, Enter, Space and the arrow keys where relevant. The focus indicator must be visible, and the focus order must follow a logical path through the content.

Pay particular attention to menus, dialog boxes, date pickers, filters and custom drop-down lists. Such components may look correct but lack the necessary keyboard support. A typical warning sign is that focus disappears, becomes trapped in a component or moves to an unexpected location.

4. Can the user identify and correct errors?

Error handling is often crucial in forms. It is not enough to mark a field with a red border. The error should be explained in text, associated with the correct field and made available to screen readers. Users must be told both what is wrong and how to fix it.

If submission fails, information that has already been entered should be preserved as far as possible. This is particularly important in long forms. Having to start over is more than an annoyance; it can cause users to abandon the entire task.

Create a barrier map showing impact and scope

Once the tasks have been tested, the findings can be collected in a simple barrier map. Each finding should contain more than a technical description.

• Task: What is the user trying to do?
• Barrier: What prevents or delays the task?
• Affected ways of using the solution: Does it affect, for example, keyboard use, screen readers, magnification or reduced color vision?
• Impact: Does the task become difficult, very demanding or impossible?
• Scope: Does the problem occur in one place or in a component used throughout the website?
• Action: What needs to change in the design, code or content?
• Responsibility: Who can actually fix the problem?

This provides a better basis for decision-making than a list of general statements such as “poor contrast” or “missing label.” The developer needs to know which component is involved. The designer needs to understand the visual context. The content owner must be able to determine whether the text contributes to the problem.

Prioritize combinations of barriers

Some issues become far more serious when they occur together. For example, a form may have weak field labels, low contrast, unclear focus, and error messages that are not read aloud. Each weakness can be recorded separately, but users experience them as one interconnected obstacle.

Therefore, assign high priority when several of these conditions are present:

1. The barrier prevents an important task from being completed.
2. It affects multiple user groups or ways of using the service.
3. It occurs in a reused component.
4. The user receives no explanation or alternative way forward.
5. The issue may result in loss of information, time, or money.

An inaccessible main menu should normally take priority over a minor visual issue on a rarely visited information page. An issue in a shared form field may be more important than several individual deviations because fixing it improves many forms at once.

Test the form as a continuous conversation

Forms should not be assessed field by field alone. Read them as a conversation between the organization and the user. Are the questions asked in a natural order? Are required fields clearly identified before the user submits the form? Are examples and formats explained? Does the user receive confirmation after submitting?

Then test the entire form with a keyboard and screen reader. Listen to how labels, help text, options, and error messages are presented. The visual design may suggest relationships that do not exist in the code. Two fields may appear under the same heading on screen but be read aloud without that context.

Also try submitting the form with missing or incorrect information. Check where focus moves, whether errors are read aloud, and whether it is easy to navigate to the fields that need to be corrected.

Use WCAG as a quality framework, not as the entire prioritization

WCAG provides a shared language for what must be perceivable, operable, and understandable. This makes the requirements verifiable and reduces room for subjective judgment. At the same time, compliance with individual requirements should not be the only goal.

A solution can meet many formal requirements and still be unnecessarily difficult to use. Long instructions may be correctly coded but difficult to understand. A focus indicator may be visible but so subtle that it is difficult to follow through a long process. A button may have sufficient contrast but unclear text.

The practical quality assessment should therefore combine three perspectives:

• WCAG: Does the solution meet specific, testable requirements?
• Task: Can the user complete what they came to do?
• User experience: Is the journey understandable, predictable, and reasonably efficient?

Distribute actions across design, development, and content

Accessibility work quickly stalls when all findings are sent to developers. Many barriers require other types of action. Low contrast may be caused by the color palette. Unclear error messages may be a content issue. Inadequate labels may require both text changes and technical associations in the form.

Therefore, sort actions according to who needs to contribute:

• Design: contrast, focus indicators, visual structure, touch targets, and states
• Development: semantics, keyboard support, focus management, and technical communication of status
• Content: headings, instructions, button text, labels, and error messages
• Product owner: prioritization, acceptance criteria, and trade-offs between actions

Conclude each action with a clear check: Which task should be retested, using which method, and what must work before the issue can be closed?

The goal is fewer obstacles, not just fewer deviations

A website does not become inclusive because the list of deviations gets shorter. It becomes inclusive when more people can find information, understand their options, and complete tasks without being stopped by the design.

By organizing the work around critical user tasks, you create a prioritization that management, designers, developers, and content owners can all understand. WCAG shows which requirements must be met. Keyboard testing, screen readers, and contrast measurements reveal specific barriers. The task perspective shows which of them should be addressed first.