Progress Bar

A progress bar communicates how far along a process is, using a visual fill and an accessible label or live region to keep all users informed of the current status.

Demo

Observe the progress bar as it advances. Pay attention to whether a screen reader would hear meaningful updates as the value changes. Check that the label clearly identifies what process is being tracked and that the current percentage or step is communicated without relying on the visual fill alone.

What to Observe

• The progress bar has a visible label that describes the process being tracked.
• The current progress value is communicated to assistive technologies, not only shown through the visual fill width.
• For determinate progress, the numeric value or percentage is conveyed to screen readers as it updates.
• The component does not rely on color alone to communicate a completed, in-progress, or error state.
• Live region updates are appropriately throttled — screen readers receive meaningful announcements without being flooded.

Anatomy

[Anatomy image placeholder — will be added when assets are available]

1. Track: The full-width background bar that represents the total range of progress from 0 to 100%.
2. Fill / indicator: The colored portion of the track that grows to represent current completion.
3. Label: The visible text that identifies what process or task the progress bar is measuring.
4. Value text: An optional visible readout of the current numeric progress, such as a percentage or step count.
5. Live region: The programmatic mechanism that announces progress updates to screen readers as the value changes.

Accessibility Behavior

• The progress bar must have an accessible label that describes what is being measured, not just a generic "progress" announcement.
• For determinate bars, the current value and maximum value must be communicated to assistive technologies.
• For indeterminate bars, the component must signal that progress is happening without implying a known completion point.
• Progress updates must be announced to screen readers through a live region or equivalent mechanism.
• Completion and error states must be communicated through text or labels, not only through color changes.
• The bar must not be keyboard-focusable since it is a status indicator, not an interactive control.

Common Mistakes

• Using a plain div with CSS width changes and no accessible attributes, so screen readers receive no progress information.
• Communicating the percentage visually only through the fill width, with no numeric value or text available to assistive technologies.
• Setting up a live region that announces every fractional change, causing an overwhelming stream of updates for screen reader users.
• Conveying a completed or failed state solely through a color change, which excludes users who cannot perceive color.
• Omitting a descriptive label, so users only hear a number with no context about what task is being tracked.

Why This Matters

Users rely on progress bars during file uploads, form submissions, and multi-step workflows. When progress is communicated only through a growing visual fill, screen reader users have no way to know that a process has started, how far along it is, or when it has finished. Poorly implemented live regions can also cause the opposite problem — bombarding users with constant announcements. The goal is meaningful, timely feedback that keeps everyone informed without being intrusive.

Accessibility Validation

This component is validated against internal accessibility criteria aligned with WCAG standards, using our internally developed system, Resonance Specs.

To learn more, please contact us.

Code

Reference Implementation

• Back to Home
• GitHub Code