Progress bars show the progression of a system operation: downloading, uploading, processing, etc., in a visual way. They can represent either determinate or indeterminate progress.
Progress bars are used to visually show the progression of a system operation such as downloading, uploading, processing, etc. By default, progress bars have a blue fill that shows the progress.
When a progress bar needs to be placed on top of a colored background, use the over background variant. This progress bar uses a static white color regardless of the color theme. Make sure the background offers enough contrast for the progress bar to be legible.
Progress bars should have a label that gives context about the operation being performed. Use an ellipsis at the end of the label text to communicate that the process is in progress. In rare cases where context is sufficient and an accessibility expert has reviewed the design, the label could be undefined. These progress bars should still include an aria-label in HTML (depending on the context, “aria-label” or “aria-labelledby”). The label is always placed above the track.
Progress bars can have a value label that gives detailed information about the progress (e.g. "60%" or "2 of 8"). This value label works alongside the label and should not be displayed if the label itself is not displayed. It should also not be displayed if the progress is indeterminate. Similar to the label, the value label is always placed above the track.
The width of a progress bar can be customized appropriately for its context. The default width is size-2400 (192 px on desktop and 240 px on mobile).
Progress bars come in 2 sizes: large (default) and small. Use the large size when there is a single operation displayed prominently on the page. Use the small size when there are multiple operations happening at the same time in a more confined space (e.g., tables, cards, etc.)
A progress bar can be either determinate or indeterminate. By default, progress bars are determinate. Use a determinate progress bar when progress can be calculated against a specific goal (e.g., downloading a file of a known size). Use an indeterminate progress bar when progress is happening but the time or effort to completion can’t be determined (e.g., attempting to reconnect to a server).
The value shows the progress of a system operation, from 0 to 1, such as downloading, uploading, processing, etc. This is not applicable when a progress bar is indeterminate.
From the design point of view, each component has a number of options. These options and their names are platform agnostic, and each implementation should adapt these to fit into their framework.
default / over background
text / nothing
text / nothing
small / large
yes / no
number (0 to 1)
Not applicable when indeterminate.
The minimum width of a progress bar is 48 px and the maximum width of a progress bar is 768 px, for both desktop and mobile platform scale. Smaller progress bars should only be used in places where it’s not necessary to have a label.
When the label is too long for the available horizontal space, it wraps to form another line. The value is always shown in full and never wraps or truncates.
Both progress bars and circles can show either determinate or indeterminate progress. The given area should help determine if a progress bar or circle is best for that space. Progress bars are preferred in vertically narrow areas (tables, cards, etc.) Use a progress circle for full page loading or in very small areas. Use a progress bar in a loader dialog.
Use the built-in style for showing a label associated with the operation. The built-in style always has a left aligned label and a right aligned percentage value above the track. The label should be in sentence case. Add an ellipsis ("...") to the end to show that the action is in progress (e.g., "Loading data..." or "Updating settings...").
Do use the built-in label style.
For RTL (right-to-left) languages, the layout of the progress bar is mirrored for both determinate and indeterminate options. The label is right-aligned, the value is left-aligned, and the fill progresses from right to left. Keep in mind that the placement of the percent sign differs depending on the locale.
|Apr 24, 2020||6.0.0|
|Dec 12, 2019||5.1.1|
|Aug 22, 2019||5.1.0|
|Apr 19, 2019||5.0.0|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
Works properly across all four color themes (lightest, light, dark, darkest).
Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).
Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).
Text has a contrast ratio of at least 4.5:1 for small text and at least 3:1 for large text (WCAG 2.0 1.4.3).
Visual information required to identify components and states (except inactive components) has a contrast ratio of at least 3:1 (WCAG 2.1 1.4.11).
UI language and information design considerations have been incorporated into component design.
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Includes content standards or usage guidelines for how to write or format in-product content for the component.
Works properly across various locales and includes guidelines for bi-directionality (RTL).
Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.
All design attributes (color, typography, layout, animation, etc.) are available as design tokens.
Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.
Includes a downloadable XD file, generated by code using design tokens defined in Spectrum DNA, and shows multiple options, states, color themes, and platform scales.
Component is included in the Spectrum for Adobe XD plugin.