Indeterminate progress indicator

[benwakefield]

Indeterminate progress indicator

Non-repudiation (Internal Service)

Overview

Provide feedback to the user that a process is actively in progress and should be concluded shortly.

<div id="retrieving1" class="panel result-progress toggle1 show" aria-busy="true">
 <div class="info">
 <p class="event-record lede">Retrieval may take up to 5 minutes</p>
 <div class="busy" aria-hidden="true"><span>.</span><span>.</span><span>.</span>
</div>

.info {
  display:block;
  .event-record.lede {
    display:inline
  }
}

.busy {
  display:inline;
  span {
    font-weight:bold;
    margin-right:0.125em;
    animation-name: processing;
    animation-duration: 1.4s;
    animation-iteration-count: infinite;
    animation-fill-mode: both;
  }
  span:nth-child(2) {
    animation-delay: .2s;
  }
  span:nth-child(3) {
    animation-delay: .4s;
  }
}

For users with mobile accessibility preferences set to Reduce motion:

@media screen and (prefers-reduced-motion: reduce) { }
@media screen and (prefers-reduced-motion) { }

 .busy span {
   animation-play-state: paused;
 }

Is it useful and unique?

• There are no patterns for in progress indicators
• Indicates that a process is actively in progress and should be finished in a relatively short time

GOV.UK Design System criteria

• Simple solution
• Tested positively with users that something was actively happening
• Testing demonstrated that our internal users expect more feedback when delays are encountered
• There are no patterns for this feedback function
• A progress bar indicator which is currently being tested (Beta) is used for dynamic, determinate progress situations, we cannot provide determined (dynamic) progress for technical reasons.
• Ellipsis natively implies that something is unfinished / incomplete
• Animation created with CSS which degrades gracefully
• Can be marked up semantically
• Complies with WCAG guidelines
• Can be given context and styled easily with preceding inline message
• Is not bitmap based

Other components or patterns you've tried

There are no progress indicators patterns.
There is a determinate progress bar pattern currently in testing however this cannot be used as we are unable to establish the length of processing time (only that the wait could be up to 5 mins)

Research on this pattern

User need
When retrieving information from the store I need system feedback so that I know my request is in progress

After the user runs a search on a tax identifier, submission results are returned from short term storage. From these (instant metadata) results a linked original record could be retrieved from long term storage. This creates a break in the user journey which we need to bridge with system feedback. We identified 4 UI states from point of search results to the record being downloaded.

1 of 4 - Retrieval (metadata search results returned from short term storage - CTA to retrieve)
2 of 4 - In progress (Request sent to retrieve original submission from archive - up to 5 mins wait)
3 of 4 - Ready (Original submission ready for download)
4 of 4 - Downloaded (UI feedback showing which records have been downloaded)

Usually the user would not expect to separately action a retrieval request, then download once the file had been returned from archive. This cognitive disconnect caused us to experiment with an indeterminate progress indicator which helped the user understand what was happing and that a waiting time was normal.

State 2 and 3 have to be actioned independently otherwise we’d effectively be asking the browser to download a file without explicit user consent which is a security risk.

Usability testing Round 7 Findings and Usability research R8 in the Non-Repudiation Home space in Confluence.

Gaps
We observed in subsequent usability testing that the UI progress feedback reduced confusion and frustration regarding why a record had to be actively downloaded after waiting for it to be retrieved. It helped mitigate the extra stage in the retrieval journey.

We only prototyped with the animated ellipsis as a starting point however it is a simple and accessible solution to help resolve the need to provide in-progress system feedback.

[stevenaproctor]

Discussed at working group on 9 March. It was considered to be useful and unique but with some questions about implementation. These were about the accessibility of the indicator and providing feedback to all users and the content, "retrieval" and "retrieve", in the example.

[benwakefield]

Can you provide more details on the accessibility questions you have so we can focus further testing. The content "retrieval" and "retrieve" were provided for context only, it was not part proposal / issue raised.

[stevenaproctor]

@adamliptrot-oc Would you be able to summarise the accessibility issues? I know you had concerns about hiding the indicator from a screen reader user and not giving them an indicator that something was happening.

[benwakefield]

The containing state div was marked up:
<div... aria-busy="true">

This should indicate that the overall in-progess state was busy doing something.

Have included full code snippet in original information

[adamliptrot-oc]

Aria busy is probably the wrong attribute to use in this case - aria busy is normally used where you don't want the user to interact with the element/widget until it has finished loading. In this case we want to tell the user the file is being retrieved. Some assistive tech might not expose the element while it has the busy state.
I'd suggest using an aria live region. In the example above the changes would not be announced. It would be possible for the user to kick-off several files retrieval and being alerted as to which are ready to download is important. The region would also need to include the name of the file so when the state changes the file name is included in the announcement (the file name doesn't have to be displayed but should be available to the screen-reader).

[enoranidi]

Hi @adamliptrot-oc, apologies first for not replying back to your response.

So in the original div we have:

<div id="retrieving1" class="panel result-progress toggle1 show" aria-busy="true">
    <div class="info">
        <p class="event-record lede">Retrieval may take up to 5 minutes</p>
        <div class="busy" aria-hidden="true"><span>.</span><span>.</span><span>.</span></div>
    </div>
    <p class="filename">Original_VAT-return_12-15_ABC-Accounting_987654321.ZIP</p>
    <p class="font-xsmall">Submitted on 1 Jan 2016</p>
</div>

where <div... aria-busy="true">

But to use aria-live (based on your suggestion) is this correct?

<div id="retrieving1" class="panel result-progress toggle1 show" aria-live="polite">
    <div class="info">
        <p class="event-record lede">Retrieval may take up to 5 minutes</p>
        <div class="busy" aria-hidden="true"><span>.</span><span>.</span><span>.</span></div>
    </div>
    <p class="filename">Original_VAT-return_12-15_ABC-Accounting_987654321.ZIP</p>
    <p class="font-xsmall">Submitted on 1 Jan 2016</p>
</div>

The div also contains the filename as well - which you mentioned.

Would it also be beneficial to add aria-atomic="true" after aria-live?

[stevenaproctor]

@JSJohal Here is the progress bar I mentioned today. It is not really a progress indicator but may be of some help.

[stevenaproctor]

I wonder if you need the animation at all. The content should be able to convey that something is happening.

[stevenaproctor]

@JSJohal There is this in the GOV.UK Design System backlog too. alphagov/govuk-design-system-backlog#28

[jennifer-hodgson]

To upstream to GOV.UK Design System

[mikeash82]

Upstreamed to the GOV.UK issues backlog alphagov/govuk-design-system-backlog#164