Progress bar

What is a Progress bar?

A Progress bar shows the user how far through a process they are with a visual cue, providing a quick estimation of a task's remaining length.

When, and why?

A Progress bar should be used when the process will typically take more than 10 seconds, and some types can tell the user the estimated time until completion of an operation. Use of a Progress bar gives a visual expectation of wait time, which will encourage the user to stay until the process has finished, or simply reassure the user that something is happening and the system hasn't frozen.

Good examples of where they would be helpful are when the user is submitting a large form, uploading a file or saving updates to the system settings.

Progress bar types

There are two different use cases for a Progress bar:

1. Determinate Progress bars are used when the system can estimate how long an operation will take. They use a 0-100% scale to display the operation progress.
2. Indeterminate Progress bars are used when the system cannot give an estimated time or track progression with a percentage scale. A looped animation reassures the user that the system is working, but with no indication of the remaining progress.

All Progress bars are available in large, regular and small sizes. The following types of Progress bars are available, separated between determinate and indeterminate Progress bars:

Progress bar properties

The following Progress bar properties are available:

Using a Progress bar

Progress bar frequency

Progress indicators are a great way to visually inform your users the system is processing an operation and if possible how long it will take to complete. However, you should use Progress bar sparingly, and only when an operation is likely to take over 10 seconds. Overuse will make it seem like the application is slow and constantly requires the user to wait. For actions that take less than 10 seconds, consider using the Spinner component.

Live demo

Below, you can find a live demo for an Accordion component. Use the drop-down menus and radio buttons to view the different Button Types and Variants.

Component accessibility

This component has been built to meet the current WCAG AA 2.1 guidelines. We also test these components against the guidelines before release.

Aria tags

Every component in Mosaic requires an appropriate Aria tag to ensure that screen readers can effectively parse the page. Aria tags are provided as part of Mosaic. Please do not override these without good reason.

Ensure that Aria tags are used as appropriate signposts throughout the product.

Colour Combinations

When designing with a Progress indicator, you should be mindful of the colour combinations you are using. The components have been designed with this in mind, but if you are using colours that are not part of the default component, please ensure that there is a clear colour contrast within the parts of the component and between the Progress indicator and the background it is on. To check the contrast, please use WebAIM's contrast checker.

Focus state

A Progress indicator needs to have a focus state - a focus state is when you tab into an element to interact with it. Ensure that users can use their keyboard to focus on the Progress indicator and get a correct reading of progress when using a screen reader.

Icons

An icon needs to have underlying code that describes what action the icon takes. the labels should be specific - for example, a 'bin' icon for delete should be labelled 'delete' not 'bin'.

Key Binding

A Progress indicator needs to be able to be interacted with via a keyboard. Where possible we will provide key-binds within our Mosaic component or there will be default HTML ones. If this isn't the case then please implement logical key-binds for all intractable components.

Movement/Animation

Please refer to the WCAG guidelines for the time-based considerations for animations.