Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

New SC Proposal: Programmatic notification is provided for each change in content that indicates an action was taken or that conveys information #2

Closed
DavidMacDonald opened this issue Aug 14, 2016 · 45 comments

Comments

@DavidMacDonald
Copy link
Contributor

DavidMacDonald commented Aug 14, 2016

Current versions of SC and Definitions

SC Short Name

Change of content

SC Text

Programmatic notification is provided for each change in page content unless one or more of the following is true:

  1. There is a programmatically determinable relationship between the new content and the control that triggers it;
  2. The user has been advised of the behavior before using the control;
  3. The change in content is not a result of a user action and not related to the the primary purpose of the page.

Editor's Note for next draft: "The working group is seeking input to account for situations where there is frequent, or constant updating."

Suggested Priority Level

Level AA

Related Glossary additions or changes

  • Change of content: changes made to a web page after it has been delivered to the user agent, whether or not initiated by the user
  • primary purpose of the page: If removed, the page would loose it's meaning or main reason for existing.

What Principle and Guideline the SC falls within

Principle: Perceivable

3.2

Description (Intent)

This Success Criteria is intended to help users of assistive technology be aware of changes that many users can easily see and understand.
There are a number of cases where content changes on a page after it is loaded. Users who are blind or have low vision that rely on a screen reader may have trouble knowing that information on a page changed. They may be working on the part of the page which is not near where changes have occurred on a page. It may be on a part of the web page that they have already read and wouldn't consider reviewing that part of the page for unannounced changes.

These messages would be very short in nature, such as:

  • "Your shopping cart has been updated, 5 items"
  • "Your form was successfully submitted."
  • "There are 5 results for your search"
  • "There are 3 errors on this form"
  • "Scores updated"
  • "content loading" (when a busy indicator is onscreen)

Examples of situations where this type of notification would be appropriate include:

  • Interactive controls may change the page based on a users selection
  • Filter / sort selections of data already displayed on page add/remove content
  • Additions and subtractions to/from a cart
  • A notification that 'support by chat' is available for this task at hand, or
  • Results of form submission when they are displayed on same page
  • A global error message placed above the form saying "form submission failed etc." or a thank you message after completion of a multi-step process,
  • On switching from grid view to list view,
  • In data table when sort column is changed,
  • On selecting a different pagination link
  • When a graphical spinning "busy" signal notifies visual users.

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.

Note: SC 4.1.2 covers notification of changes in content that are a result of a change in the state of a control, such as selecting a new Tab in a tabbed interface, opening and closing a menu, clicking a link or button that opens up a dialog or tooltip. The text of 4.1.2 is "... states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies."

Specific Benefits of Success Criterion

Users of assistive technology will know what changed on the page, and will be able to make decisions based on that information.

Benefits

  • 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 something changed on the page that they were unaware of. 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 show/hide content etc, and ensure they have programming that exposes the user to notifications about this new data. 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

This is also in the Pearson guideline 5 http://wps.pearsoned.com/accessibility/115/29601/7577872.cw/index.html

COGA has a similar notification SC which is a little wider currently. https://rawgit.com/w3c/coga/master/extension/rapid-and-direct-feedback.html

Techniques

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

possible narrowing of scope to user initiated changes

Editor note: we are seeking input about whether to limit this success criteria to user initiated changes by inserting the word "user initiated" before the word "change" and removing the last bullet.Editor note: we are seeking input about whether to limit this success criteria to user initiated changes by inserting the word "user initiated" before the word "change" and removing the last bullet.

@awkawk
Copy link
Member

awkawk commented Nov 17, 2016

@DavidMacDonald Is this still covered by M15? (doesn't seem to be)

@WilcoFiers
Copy link

There are more than x notifications per minute.

You'll still need to fill this in.

@DavidMacDonald
Copy link
Contributor Author

This needs an MAFT Label.

@jnurthen
Copy link
Member

jnurthen commented Dec 2, 2016

Wouldn't this (as written) require that an advertisment on a page which animates would need to provide notification? If so we need to write something to exclude that case - maybe limit this to content which is related to the primary purpose of the page?

@DavidMacDonald
Copy link
Contributor Author

Responding to James
5. The new content is not related to the the primary purpose of the page AND is not a result of a user action.

@DavidMacDonald
Copy link
Contributor Author

DavidMacDonald commented Dec 5, 2016

Here's a rewrite to combine COGA SC Issue #54 and address James comment.

Programmatic notification is provided for each change in content that indicates an action was taken or that conveys information, unless one or more of the following is true:

  1. The change immediately follows the control that triggered it, in the programmatic reading order.
  2. There is an accessibility supported programmatic relationship between the new content and the user # activated control that triggers it.
  3. The user has been advised of the behavior before using the component.
  4. There are more than 5 notifications per minute.
  5. The change in content is not related to the the primary purpose of the page AND is not a result of a user action.
  6. The user action results in a success or failure response from the page, in which case visual feedback (such as text) AND a programmatic notification are provided.

@jnurthen
Copy link
Member

jnurthen commented Dec 6, 2016

@lseeman
Copy link
Contributor

lseeman commented Dec 6, 2016

Isnt this part of role name state - change of state?

@DavidMacDonald
Copy link
Contributor Author

DavidMacDonald commented Dec 6, 2016

@lseeman 4.1.2 addresses updates only on components ... not other types of content

@DavidMacDonald
Copy link
Contributor Author

DavidMacDonald commented Dec 6, 2016

@jnurthen I've merged issue#3 in as an example.

Immediately was intended to mean it follows it in the DOM, and there is no content between the control and the new content, otherwise it would need to be referenced or announced, which we think gives a lot of flexibility.

@jnurthen
Copy link
Member

jnurthen commented Dec 6, 2016

@DavidMacDonald so my example with a <br> would be ok then as that is not "content" so I stand by my comment that immediately needs defining so it is clear what is allowed and what is not.

@DavidMacDonald
Copy link
Contributor Author

DavidMacDonald commented Dec 11, 2016

@jnurthen "Immediately follows" is a bit hard to scope this way. I think the concern can be addressed by defining "Programmatic reading order" to exclude machine code not typically presented to the end user

"Programmatic reading order"
The order of content presented to the end user.
Note: code used for layout and programming which is typically not presented to the end user is not considered in calculating the programmatic reading order.

@joshueoconnor
Copy link
Contributor

This needs to be clearer around exactly what a component is IMO.

@joshueoconnor
Copy link
Contributor

We also need a definition for control.

@WayneEDick
Copy link
Contributor

How can a user turn these comments off? Sometimes actions can be relevant, but you want to concentrate on what you are doing.

@WayneEDick
Copy link
Contributor

The programmatic reading order looks like "correct reading sequence" already defined in WCAG 2.0 glossary.

@WayneEDick
Copy link
Contributor

This really needs coordination with Issue 54.
It is stated in plain language. There is a problem with the language in Issue 2.

What does this cover that is not covered by Issue 54?

@mapluke
Copy link

mapluke commented Jan 11, 2017

I agree with Wayne that there "is a problem with the language". One example is that it is unclear what the "except" (in the third line of the four line 51 word sentence) "programmatic notification" applies to. I've read this definition several times and I'm still not sure I have fully got the correct intended meaning.

@mapluke
Copy link

mapluke commented Jan 11, 2017

In attempting to co-ordinate with Issue 54, I believe that there is a major difference that must be overcome. Issue 54 states what is really needed by users "programmatically-determinable, rapid feedback in the primary modalities of the content". However, Issue 2 calls for "Programmatic notification", which only requires that a user agent should be able to "extract and present this notification to users in different modalities". This success criterion.would be met if the feedback was presented to users in a different modality to the primary modality of the content, or even if no feedback was actually presented.

@DavidMacDonald
Copy link
Contributor Author

DavidMacDonald commented Jan 13, 2017

@mapluke
There is an overlap of the two proposals, but there are a lot of things in each which are not covered by the other. The main use case for #2 is using "aria-live" regions for blind people for ALL changes in content, not just actions by the user to notify of Success or failure. #54 is calling for visual feedback as well as programmatic feedback, it also asks for audio feedback without Assistive Technology, and it calls for the user to have a choice in this... but ONLY for actions that result in success or failure.

In this SC, Programmatic notification refers to providing the information to the accessibility API. In my experience this is a reasonably well understood part of WCAG for accessibility professionals doing audits. We avoid using the API term in the definition for a number of reasons.

I added exception number 6 to this SC #2 to address Issue #54 (leaving out the requirement for Non AT audio feedback, which is really hard).

The user action results in a success or failure response from the page, in which case visual feedback (such as text) AND a programmatic notification are provided

@WayneEDick
I think Programmatic reading order needs to be in here because it is different from meaningful sequence. Programmatic reading order means the actual order in the code. It means that if a screen reader user can down arrow once or twice and get the new content, the content passes without anything further. Meaningful sequence allows for the content to be anywhere. The SC says the new content can be anywhere, but if it doesn't immediately follow the users current focus, the user should be notified via the accessibility API.

How can a user turn these comments off?

They are programmatic notifications through the API, so the user would turn it off in their AT. (Suppress aria-live notifications)

@rachaelbradley rachaelbradley mentioned this issue Jan 14, 2017
@rachaelbradley
Copy link

Sorry to weigh in late ,but comparing #2 and #54, I question whether we should be combining them. Issue #2 addresses changes in content, regardless of whether it is initiated by the user or not. It is placed in perceivable because the central focus is ensuring users are either aware of the change in content after the page is rendered, either through notification or through encountering the change as part of the natural reading order. Issue #54 focuses on ensuring users receive feedback about the results of their actions in order to avoid mistakes, and is placed under 3.3 accordingly. Not all user actions results in content changes, some result in potentially confusing changes in context (for example: sending an email where the email closes). While there is overlap for actions that result in content changes, I believe merging them leads to an overburdened SC. I suggest we consider reducing the overlap rather than merging them. Below are the wordings of the two success criteria together with #2 slightly edited to reduce the overlap.

#2 Programmatic notification is provided for each change in content that conveys information, unless one or more of the following is true:
1.The change immediately follows the control that triggered it, in the programmatic reading order.
2.There is an accessibility supported programmatic relationship between the new content and the user # activated control that triggers it.
3.The user has been advised of the behavior before using the component.
4.There are more than 5 notifications per minute.
5.The change in content is not related to the primary purpose of the page AND is not a result of a user action.

#54 The success or failure of every user initiated action is clearly indicated to the user by visual, programmatically-determinable, rapid feedback in the primary modalities of the content. Audio feedback is supported.

I would add a note that in cases where a user action results in a change in content, both criteria apply and that clearly written notification that the content changed could be considered to satisfy #54.

@awkawk awkawk reopened this Feb 28, 2017
@awkawk
Copy link
Member

awkawk commented Mar 28, 2017

David, how does a common model that I'm seeing on a lot of news sites fit into this? On a page with a long article, there will be 2-3 paragraphs and then a "read more" button, then another article or page footer information. If you click the "read more" button then the rest of the article is loaded into the page.

Would this fail?

@DavidMacDonald
Copy link
Contributor Author

DavidMacDonald commented Mar 29, 2017

@awkawk the initial state of the page would be something like this.

<p>Lipsum... <a href...>read more</a></p>
<div style="display:none">[rest of the article]</div>
<span id="notification" aria-live="polite"></span>

On clicking "read more" inject text in the <span> node with JS:

<span id="notification" aria-live="polite">full article loaded</span>

@mraccess77
Copy link

@DavidMacDonald I might also want to see an aria-controls in there as well so it's clear what new content was loaded. It's also been my experience that aria-live can be hit or miss to whether it actually works with different screen readers. There is also the challenge of screen readers seeing the new content. While we should good support for DOM mutation listeners it seems screen readers can miss content updates even with aria-live or an alert is used.

@awkawk
Copy link
Member

awkawk commented Mar 30, 2017

Is there a way to do it without ARIA? How would this be done with a native mobile application or software application where "software program" is the unit of evaluation instead of "web page" (per WCAG2ICT)?

WCAG2ICT does apply to WCAG 2.0 but we should be thinking about the impact on it for 2.1.

@DavidMacDonald
Copy link
Contributor Author

DavidMacDonald commented Mar 30, 2017

An alert, popup, inline comment, or any other programmatic notification. We've been notifying people of things for years before ARIA.

@mraccess77
Copy link

@awkawk in IOS native apps you can send screen changed events and screen layout change events that can be detected by the screen reader. These can also be accompanied by a control to focus or a string to announce. https://developer.apple.com/reference/uikit/uiaccessibilitylayoutchangednotification

@DavidMacDonald
Copy link
Contributor Author

DavidMacDonald commented Apr 11, 2017

@mraccess77 I might also want to see an aria-controls in there as well so it's clear what new content was loaded.

That is the intent of the first bullet. We can't say "wai-aria controls" but that is a "accessibility supported relationship between the new content and the control that triggers it."

It's also been my experience that aria-live can be hit or miss to whether it actually works with different screen readers. There is also the challenge of screen readers seeing the new content.

Yes, changing display:none to block doesn't have as good support injecting innerHTML
http://www.davidmacd.com/blog/test-aria-live-display-none.html

@kwahlbin
Copy link
Contributor

We need a definition for "primary purpose of the page"

@DavidMacDonald
Copy link
Contributor Author

DavidMacDonald commented May 4, 2017

Here's a first shot at a definition "primary purpose of the page"

If removed, the page would loose it's meaning or main reason for existing.

@joshueoconnor
Copy link
Contributor

I think drop programmatic from "Programmatic notification is provided for each change in page content unless one or more of the following is true:". It's mentioned in the qualifying clauses.

@awkawk awkawk closed this as completed Aug 24, 2017
@jake-abma jake-abma assigned jake-abma and unassigned WayneEDick Aug 26, 2017
alastc added a commit that referenced this issue Nov 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests