In one paragraph
ARIA progressbar nodes must have an accessible name means a tested progress indicator lacks an accepted name identifying its task. Connect a meaningful label and expose a known numeric value only when progress is determinate. Text such as forty percent inside the bar is not automatically its name. Review status announcements and the overall operation separately from this naming check.
Why it matters
Users need to know what is progressing, especially when several operations appear on a page. Uploading invoice and Exporting report are different subjects even if both currently show forty percent. The name should identify the task, not merely repeat Progress bar.
A determinate indicator has a known value within its range. An indeterminate one should not report an invented percentage. A decorative spinner, a step-navigation list, and a bounded measurement may call for different semantics from a progressbar.
Progressbar is not automatically a live-announcement solution. Frequent value changes can be noisy if every update is forced into speech, while a silent failure can leave users waiting indefinitely. Provide useful status communication without assuming the role will announce every event exactly as desired.
How WebAuditOS evaluates this finding
The supplied aria-progressbar-name rule selects applicable explicit progressbar roles and checks supported ARIA names or a title fallback. Descendant percentage text alone does not satisfy its documented naming paths.
Serious impact maps to high severity. Native progress without an explicit role and indicators absent by scan time can escape this selector. The rule does not validate truthful percentages, correct indeterminate handling, status timing, cancellation, or successful task completion.
How to fix it
- Identify the actual process and whether this is task progress, a read-only measurement, or navigable steps. Do not label every animated visual as a progressbar by default.
- Prefer a suitable native progress element where it fits. For example:
<label for="report-upload">Uploading report</label>
<progress id="report-upload" value="40" max="100">40%</progress>The example represents known progress. Use real application data and preserve a usable control for cancelling the operation if the product offers cancellation.
- For a necessary custom progressbar, provide the task name through aria-labelledby or another appropriate author-supplied name. Review bounds and current value according to the role's definition instead of copying a meter implementation blindly.
- When progress is unknown, omit the current-value declaration as appropriate to the native or ARIA design. Do not show zero, ninety-nine percent, or an advancing synthetic estimate as a supposedly exact measured value.
- Keep visible and programmatic progress consistent. Provide useful human wording when units or staged work make a bare percentage misleading, without erasing the subject of the task.
- Design completion, failure, and cancellation feedback deliberately. Use appropriate status communication and focus behaviour for the task, rather than forcing a live announcement on every animation frame.
- Test slow networks, short-lived loaders, retry, errors, and multiple concurrent processes. A spinner removed before the scan can still have been inaccessible while users needed it.
- Rescan relevant rendered states and perform manual operation tests. Name presence is one requirement, not proof that the application communicates progress accurately or recovers from failure.
What the fix can break
Repeatedly changing the name to include a percentage can make the subject unstable. Keep task identity and value separate unless a tested design requires otherwise.
Aggressive live announcements can interrupt reading, while missing error feedback can make an ended operation appear still active. Choose a meaningful update strategy.
Do not make a purely informational bar focusable just so users hear it on Tab. Review the normal reading and status experience without adding unnecessary keyboard stops.
Questions
Does text inside the bar count as its name?
Not under this explicit-role naming rule. Associate the task label using an appropriate method.
Should unknown progress have aria-valuenow=0?
Not merely to satisfy a validator. Indeterminate progress should not claim a known current value.
Will every change be announced automatically?
Do not rely on that. Test the target combinations and provide suitable status feedback without excessive noise.
Which related checks help?
Review meter names, custom field names, and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared serious in axe-core 4.13.0, so every failure arrives as high - even though, in human terms, an unnamed progress bar is usually less disruptive than an unnamed control.