Perspective

The task can be completed, but it costs more

Successful task completion can hide unequal effort, memory, recovery work and repeated requests for help.

A user completes the task.

That sounds like success.

But it can conceal an important question: what did completing it cost them?

Two people can reach the same outcome while one has to remember more information, recover from more ambiguity, repeatedly request an alternative, switch tools, ask for help, or spend much longer working out what the interface expects.

“Can complete” and “equivalent experience” are not the same measurement.

Interface demands

• Multiple / interacting demands

These describe what the interface requires from the person in this barrier. They are not disability categories and do not imply that everyone affected has the same experience.

What happens

The product does not necessarily block the user outright. Instead, friction accumulates.

Examples can include:

• instructions split across places that must be remembered and combined;
• an error that says something is wrong without explaining how to recover;
• an accessible alternative that exists only after contacting support;
• a process that repeatedly asks a person to explain an access need;
• controls that technically work with assistive technology but require substantially more navigation;
• unnecessary time pressure or interruptions;
• a workflow whose next step is difficult to infer.

Some of these examples can be WCAG failures. Some may be usability or service-design problems beyond a particular success criterion. The distinction matters.

Why it matters

Binary completion data can make unequal experiences disappear.

If testing records only “pass: task completed”, it may fail to capture additional time, cognitive effort, uncertainty, dependence on another person or administrative work.

This is particularly important when the extra work is repeatedly placed on the same users.

How to test it

Do not replace completion with a subjective judgement of “easy”. Add evidence around completion.

For a representative task, observe:

• number of steps and detours;
• repeated navigation;
• errors and recovery attempts;
• information the user must remember;
• places where the next action is ambiguous;
• tool or modality switches;
• requests for assistance or alternative formats;
• time pressure;
• whether the user must disclose or repeatedly explain an access need.

Then compare interaction paths rather than assuming the shortest visual path is the baseline everyone should reproduce exactly.

Can automation detect it?

Usually not as a whole.

Automation may detect individual technical failures contributing to the burden. It cannot determine the total interaction cost of a workflow or whether a person is repeatedly doing compensatory work.

Relevant WCAG

There is no single WCAG criterion for “this task costs this person too much effort”.

Specific causes may map to criteria concerning errors, labels, focus, timing, reflow, target size, redundant entry, accessible authentication and others.

Do not force the overall observation into one criterion merely to make it measurable.

What a pass does not prove

A user completing a task does not, by itself, prove that:

• the task was understandable;
• the effort was reasonable;
• the user was independent;
• recovery was clear;
• the same barrier will not recur next time;
• the service surrounding the interface was accessible.

Completion is evidence. It is not the whole experience.