This repository has been archived by the owner. 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

Projects
None yet
@DavidMacDonald
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

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Nov 17, 2016

Member

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

Member

awkawk commented Nov 17, 2016

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

@WilcoFiers

This comment has been minimized.

Show comment
Hide comment
@WilcoFiers

WilcoFiers Nov 23, 2016

There are more than x notifications per minute.

You'll still need to fill this in.

There are more than x notifications per minute.

You'll still need to fill this in.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 1, 2016

Contributor

This needs an MAFT Label.

Contributor

DavidMacDonald commented Dec 1, 2016

This needs an MAFT Label.

@jnurthen

This comment has been minimized.

Show comment
Hide comment
@jnurthen

jnurthen 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?

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 4, 2016

Contributor

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.

Contributor

DavidMacDonald commented Dec 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 5, 2016

Contributor

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.
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jnurthen

jnurthen Dec 6, 2016

  • The word immediately needs defining in (1). What is immediately? If there is a < br > between the control and the content - is that immediatly following? How much - and what type of content - is allowed between the control and the content?
  • Isn't the loading indicator in #3 an example of this? Why does it need to be a separate SC? Can't we combine #3 into #2?

jnurthen commented Dec 6, 2016

  • The word immediately needs defining in (1). What is immediately? If there is a < br > between the control and the content - is that immediatly following? How much - and what type of content - is allowed between the control and the content?
  • Isn't the loading indicator in #3 an example of this? Why does it need to be a separate SC? Can't we combine #3 into #2?
@lseeman

This comment has been minimized.

Show comment
Hide comment
@lseeman

lseeman Dec 6, 2016

Contributor

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

Contributor

lseeman commented Dec 6, 2016

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

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 6, 2016

Contributor

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

Contributor

DavidMacDonald commented Dec 6, 2016

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

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 6, 2016

Contributor

@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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jnurthen

jnurthen 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.

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 11, 2016

Contributor

@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.

Contributor

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 joshueoconnor added the COGA label Dec 13, 2016

@joshueoconnor

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Dec 13, 2016

Contributor

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

Contributor

joshueoconnor commented Dec 13, 2016

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

@joshueoconnor

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Dec 13, 2016

Contributor

We also need a definition for control.

Contributor

joshueoconnor commented Dec 13, 2016

We also need a definition for control.

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Dec 19, 2016

Contributor

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

Contributor

WayneEDick commented Dec 19, 2016

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

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Dec 19, 2016

Contributor

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

Contributor

WayneEDick commented Dec 19, 2016

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

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Dec 19, 2016

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?

Contributor

WayneEDick commented Dec 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mapluke

mapluke 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 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

This comment has been minimized.

Show comment
Hide comment
@mapluke

mapluke 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.

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 13, 2017

Contributor

@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)

Contributor

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 referenced this issue Jan 14, 2017

Closed

Feedback #54

@rachaelbradley

This comment has been minimized.

Show comment
Hide comment
@rachaelbradley

rachaelbradley Jan 14, 2017

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.

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.

@mapluke

This comment has been minimized.

Show comment
Hide comment
@mapluke

mapluke Jan 15, 2017

@DavidMacDonald
Your seven-word explanation of "Programmatic notification" is exactly what I would have expected it to mean. The problem I have is that the 52-word multi-clause sentence that is supposed to explain it is, in my view, almost impossible to parse. COGA guidelines suggest only one idea per sentence. Depending on how you count them there are probably six or seven ideas in this sentence! Maybe this can be re-examined and re-drafted to clearly say what is intended - it probably needs more than one sentence.

mapluke commented Jan 15, 2017

@DavidMacDonald
Your seven-word explanation of "Programmatic notification" is exactly what I would have expected it to mean. The problem I have is that the 52-word multi-clause sentence that is supposed to explain it is, in my view, almost impossible to parse. COGA guidelines suggest only one idea per sentence. Depending on how you count them there are probably six or seven ideas in this sentence! Maybe this can be re-examined and re-drafted to clearly say what is intended - it probably needs more than one sentence.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 16, 2017

Contributor

@mapluke Updated the definition to simplify to one idea per sentence, also made a plain language pass of the Success Criteria proposal, to remove overly technical terms. The technical terms can be considered at a later date if necessary for accuracy, but propose this simpler version for the first draft.

Contributor

DavidMacDonald commented Jan 16, 2017

@mapluke Updated the definition to simplify to one idea per sentence, also made a plain language pass of the Success Criteria proposal, to remove overly technical terms. The technical terms can be considered at a later date if necessary for accuracy, but propose this simpler version for the first draft.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 16, 2017

Contributor

Issue 54 covers

  • Changes that involve actions that have a "success or failure" outcome
  • Visual feedback of that success or failure
  • Programmatic Feedback (i.e., aria-live) of that success or failure
  • Audio feedback of that success or failure that is self generated from the browser and web page (not a via screen reader)
  • Settings to turn off this self generating audio feedback

Issue #2 covers

  • All changes in content (not just success failure), so they don't need to be triggered by the user... (i.e., baseball score update, or stock change)
  • Is limited to programmatic feedback (i.e., aria-live) not visual or self generating audio

Issue 2 has the following exemptions

  • Has exceptions for when a user clicks a button and the new content follows immediately after the button
  • allows an exception if there the code "aria-controls" makes an programmatic association between the button and the new content, which could then be somewhere else on the page
  • If there is a warning to the user that new content will be inserted when they click something beforehand then no notification is necessary
    changes not related to the primary purpose of the page are exempt from notifications (i.e., advertisements that refresh)
  • if there are more than x notifications a minute there is an exemption.

I tried an early attempt to merge #54 by adding bullet 6 to Issue #2

The only thing this leaves out of #54 is the self generating audio feedback and the requirement for personalization to turn it off. I think that is a requirement that is too wide for the current web, until personalization on web pages becomes main stream.

#54 is simpler to understand. #2 has already been through the painful grooming process of adding exceptions, which is what makes Wayne say it seems complicated. But I think any notification SC will end up with a list of exceptions like #2.

There is also a consideration about WCAG SC 4.1.2 which overlaps, and requires notification to changes to components. But I don't think we can easily morph "component" into something that would be satisfactory for either Issue #54 or #2. So we can park that for now, understanding that someone might bring it up during discussions.

We could add back in the audio feedback part of #54 for the group to access which would be something like this for bullet 6

  1. The user action results in a success or failure response from the page, in which case visual feedback, audio feedback which can be turned off, AND a programmatic notification are provided
Contributor

DavidMacDonald commented Jan 16, 2017

Issue 54 covers

  • Changes that involve actions that have a "success or failure" outcome
  • Visual feedback of that success or failure
  • Programmatic Feedback (i.e., aria-live) of that success or failure
  • Audio feedback of that success or failure that is self generated from the browser and web page (not a via screen reader)
  • Settings to turn off this self generating audio feedback

Issue #2 covers

  • All changes in content (not just success failure), so they don't need to be triggered by the user... (i.e., baseball score update, or stock change)
  • Is limited to programmatic feedback (i.e., aria-live) not visual or self generating audio

Issue 2 has the following exemptions

  • Has exceptions for when a user clicks a button and the new content follows immediately after the button
  • allows an exception if there the code "aria-controls" makes an programmatic association between the button and the new content, which could then be somewhere else on the page
  • If there is a warning to the user that new content will be inserted when they click something beforehand then no notification is necessary
    changes not related to the primary purpose of the page are exempt from notifications (i.e., advertisements that refresh)
  • if there are more than x notifications a minute there is an exemption.

I tried an early attempt to merge #54 by adding bullet 6 to Issue #2

The only thing this leaves out of #54 is the self generating audio feedback and the requirement for personalization to turn it off. I think that is a requirement that is too wide for the current web, until personalization on web pages becomes main stream.

#54 is simpler to understand. #2 has already been through the painful grooming process of adding exceptions, which is what makes Wayne say it seems complicated. But I think any notification SC will end up with a list of exceptions like #2.

There is also a consideration about WCAG SC 4.1.2 which overlaps, and requires notification to changes to components. But I don't think we can easily morph "component" into something that would be satisfactory for either Issue #54 or #2. So we can park that for now, understanding that someone might bring it up during discussions.

We could add back in the audio feedback part of #54 for the group to access which would be something like this for bullet 6

  1. The user action results in a success or failure response from the page, in which case visual feedback, audio feedback which can be turned off, AND a programmatic notification are provided
@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 16, 2017

Contributor

OR we could just leave them separate for the first draft

Contributor

DavidMacDonald commented Jan 16, 2017

OR we could just leave them separate for the first draft

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 17, 2017

Contributor

@rachaelbradley if we separate then you can leave out the "programmatic notification" part of #54 because it's required here. The note about overlap would have to be if there is a "success/failure" response to a user action then both apply. #54 only covers success/failure related actions.

some result in potentially confusing changes in context (for example: sending an email where the email closes).

I think the handling of sending an email and closing the dialogue is best handled under the exception number 3

The user has been advised of the behavior before using the component.

I think if a "send" button sends the email and closes the window there is no need for notification after the fact. The "send" button should have the following label "Send email and close dialogue" or simply "Send and close"

Contributor

DavidMacDonald commented Jan 17, 2017

@rachaelbradley if we separate then you can leave out the "programmatic notification" part of #54 because it's required here. The note about overlap would have to be if there is a "success/failure" response to a user action then both apply. #54 only covers success/failure related actions.

some result in potentially confusing changes in context (for example: sending an email where the email closes).

I think the handling of sending an email and closing the dialogue is best handled under the exception number 3

The user has been advised of the behavior before using the component.

I think if a "send" button sends the email and closes the window there is no need for notification after the fact. The "send" button should have the following label "Send email and close dialogue" or simply "Send and close"

@mraccess77 mraccess77 referenced this issue Jan 17, 2017

Closed

Orientation #70

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 17, 2017

Contributor

Most recent version after a plain language pass is:

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 reading order.
  2. There is an accessibility supported relationship between the new content and the 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 a result of a user action AND not related to the the primary purpose of the page.
Contributor

DavidMacDonald commented Jan 17, 2017

Most recent version after a plain language pass is:

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 reading order.
  2. There is an accessibility supported relationship between the new content and the 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 a result of a user action AND not related to the the primary purpose of the page.
@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Jan 19, 2017

This feedback is based on a collective review by @PatrickLauke, @IanPouncey, @jspellman and @LJWatson

This SC addresses a valid set of use cases, and appears to be practical and realistic to achieve. We have one small suggestion though...

"1. The change immediately follows the control that triggered it, in the programmatic reading order."

There may be times when a notification would be helpful in this situation. For example, when a control causes a set of search results to be filtered and
the control comes before the search results in the DOM. For this reason, we suggest that this exception is dropped from the SC.

This feedback is based on a collective review by @PatrickLauke, @IanPouncey, @jspellman and @LJWatson

This SC addresses a valid set of use cases, and appears to be practical and realistic to achieve. We have one small suggestion though...

"1. The change immediately follows the control that triggered it, in the programmatic reading order."

There may be times when a notification would be helpful in this situation. For example, when a control causes a set of search results to be filtered and
the control comes before the search results in the DOM. For this reason, we suggest that this exception is dropped from the SC.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 25, 2017

Contributor

@LJWatson @patrickhlauke @IanPouncey @jspellman
I'm a little nervous about removing the exception for new content immediately following the control. Wouldn't that mean that every show/hide button would have to place a live region on the new content... well perhaps the aria-expanded change of state would be sufficient notification in that case. Thoughts?

Contributor

DavidMacDonald commented Jan 25, 2017

@LJWatson @patrickhlauke @IanPouncey @jspellman
I'm a little nervous about removing the exception for new content immediately following the control. Wouldn't that mean that every show/hide button would have to place a live region on the new content... well perhaps the aria-expanded change of state would be sufficient notification in that case. Thoughts?

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 31, 2017

Contributor

@joshueoconnor yes its ready

Contributor

DavidMacDonald commented Jan 31, 2017

@joshueoconnor yes its ready

@joshueoconnor

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Feb 4, 2017

Contributor

@DavidMacDonald Great stuff - please submit a PR against this. @WayneEDick

Contributor

joshueoconnor commented Feb 4, 2017

@DavidMacDonald Great stuff - please submit a PR against this. @WayneEDick

@joshueoconnor

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Feb 17, 2017

Contributor

This seems related to the COGA SC Task Completion #21

Contributor

joshueoconnor commented Feb 17, 2017

This seems related to the COGA SC Task Completion #21

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 28, 2017

Member

Updated the issue description to reflect the FPWD text and reopening issue.

Member

awkawk commented Feb 28, 2017

Updated the issue description to reflect the FPWD text and reopening issue.

@awkawk awkawk reopened this Feb 28, 2017

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Mar 28, 2017

Member

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?

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Mar 29, 2017

Contributor

@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>

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Mar 30, 2017

Contributor

@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.

Contributor

mraccess77 commented Mar 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Mar 30, 2017

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Mar 30, 2017

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Apr 8, 2017

Contributor

@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

Contributor

mraccess77 commented Apr 8, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Apr 11, 2017

Contributor

@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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin Apr 13, 2017

Contributor

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

Contributor

kwahlbin commented Apr 13, 2017

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

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald May 4, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor May 30, 2017

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.

Contributor

joshueoconnor commented May 30, 2017

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 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.