New SC proposal: After initial page load, programmatic notification is provided for each visual indicator that content is loading or the page is busy.

[DavidMacDonald]

Short Name

Notification of Loading/Busy:

SC Text

After initial page load, programmatic notification is provided for each visual indicator that content is loading or the page is busy or change of screen orientation.

Suggested Priority Level

Level AA

Related Glossary additions or changes

Programmatic notification: Notification by software from data provided in a user-agent-supported manner such that the user agents can extract and present this notification to users in different modalities, without further action by the user, except for focusing on the control which caused the change, or activating the control which caused the change.

What Principle and Guideline the SC falls within

Principle: Perceivable

Proposed new Guideline 1.5:
Notification: Make it easier for users to know about changes to dynamic content

Description (Intent)

The purpose of this Success Criterion is to ensure screen readers users such as those who are blind or who have low vision, are aware that a page is reloading or busy when changes are happening to a web page and there is a visual indication. Some users who are blind get confused if the page orientation changes and things drop off the page.
Dynamic changes to a page sometimes cause the page to become inactive for a period of time while it is being updated. Users of assistive technology may think the page has crashed and may loose their work if they either reload the page or leave the page thinking the browser crashed. This notification will ensure they are aware that something is happening in the background, the way that sighted users are aware when they see a spinning icon or the words "loading". If there is no such visual indication there is no requirement in the Success Criterion to provide programmatic notification, only when there is a visual notification, is there a requirement to make that notification also programmatic. This is not about the initial wait to load a new page. Those are announced to screen readers.

Specific Benefits of Success Criterion 1.5.1

• Users who are blind will know if a shopping cart was successfully updated, or if form was successfully submitted, or if there were errors on their form.
• Helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a control will be accidentally activated or action will occur unexpectedly.
• Individuals who are unable to detect changes on the page will be able to know what people who can see those changes know.

Justification and Evidence

This issue is currently a best practice recommended by most WCAG evaluators, and most evaluators have come across situations where a screen reader user became confused because the page paused to load something, and they thought there was a crash. There is a long thread on the mail archives which started here: https://lists.w3.org/Archives/Public/w3c-wai-gl/2016AprJun/0808.html. The current wording is a result of those discussions and has good momentum from working group members on the list.

There was an issue which filed against WCAG for WCAG next. See Issue 12 here https://www.w3.org/WAI/GL/wiki/Post_WCAG_2_Issues_Sorted

Testability

This can be tested programmatically or functionally. In the code identify elements that are updated and ensure they have programming that exposes the user to this new data. this is primarily accomplished with aria-live. Functionally a screen reader can be run while the page is updating to determine changes to the page are announced to the user.

Related Resources

Resources are for information purposes only, no endorsement implied.
This is also in the Pearson guideline 5 http://wps.pearsoned.com/accessibility/115/29601/7577872.cw/index.html

Techniques

• Using aria-live to notify a user of changes in content

Notes for working group

• This may be combined with M15 which is "notification of change of content."
• The last 4 words of the SC say "or change of screen orientation". Notification of screen orientation change may not be possible by the author unless the author is forcing a change in the layout. So the phrase is at risk and may be dropped off if it can be demonstrated that this a function of the user repositioning the device.

[DavidMacDonald]

This needs an MAFT Label.

[jnurthen]

Need to provide a threshold. sometimes a busy indicator appears for a fraction of a second. In these cases we would not want the busy notification for a screen reader user as it would be distracting noise. If busy is announced to a screen reader user we also then need to announce when the load is complete too otherwise a screen reader user may assume that the page is still busy.

[DavidMacDonald]

There have been a number of comments about screen orientation. I agree and propose removing it, so the SC says:

"After initial page load, programmatic notification is provided for each visual indicator that content is loading or the page is busy."

James: We could say something like "unless the image apprears for less than 2 seconds" but how can we determine if the indicator will only appear for a split second or not? It probably has a lot to do with the user's environment.

So the SC simply requires a programmatic (aria-live) around a rotating gif.
Something like this.
<span aria-live="polite" class="visuallyHidden">loading</span><img scr="rotating-gif" ... >

[jnurthen]

@DavidMacDonald I don't think that is useful. If you are going to notify a user that something is loading you also have to tell them when it is done loading. Otherwise how are they to know what has happened?

[joshueoconnor]

Today on the call David said that he could merge this SC with #2 as an example - so this can be closed.

[DavidMacDonald]

I have moved this over as an example of Issue #2 as per @jnurthen suggestion.