Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Draft guidance section for live region roles and attributes #78

Open
9 tasks
mcking65 opened this issue Aug 13, 2016 · 6 comments
Open
9 tasks

Draft guidance section for live region roles and attributes #78

mcking65 opened this issue Aug 13, 2016 · 6 comments
Labels
Practice Page Related to a page within the practices section of the APG

Comments

@mcking65
Copy link
Contributor

mcking65 commented Aug 13, 2016 •
edited
Loading

This guidance section will cover the following roles, states, and properties:

  • alert
  • log
  • marquee
  • status
  • timer
  • aria-atomic
  • aria-busy
  • aria-live
  • aria-relevant

It should also explain what kinds of updates the spec says should trigger a live region. @JAWS-test asked about the following list of possibilities and concerns in issue #1138.

  • Insert into DOM
  • Remove from DOM
  • add role=alert to an existing node
  • Change visibility (display:none, hidden, aria-hidden)
  • Change the position (e.g.: left:100px)
  • Change the color (e.g.: color:red)
  • Change the size (e.g. width:100px)
  • Change transparency (e.g. opacity:0;)

However, the output differs depending on whether these changes are made to the parent element, the element with role=alert, a direct child element, or a nested descendant element.
The output also varies depending on which Javascript method is used to insert element nodes into the DOM.

When working on this issue, there is some old content that may be useful in the file aria-practices-DeletedSectionsArchive.html.
The relevant section can be seen here:
https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#docmgt
@mcking65 mcking65 added this to the 1.1 PR milestone Aug 13, 2016
mcking65 added a commit that referenced this issue Aug 14, 2016
@mcking65
Removed sections that require major rework to fix incorrect guidance.
eabf6ca 
In addition to the below, This commit also moves the landmark section after the example section.

Moved each of the following sections from aria-practices.html to aria-practices-DeletedSectionsArchive.html
and created associated issues for drafting new versions.
1. Section "General Steps for Building an Accessible Widget with WAI-ARIA" and created issue #73.
2. Section "Other Widget Authoring Practices"., primarily about aria-valuenow, there is no specific need to raise an issue for this section.
3. Section "Relationships" and raised issues #74, #75, #76, and #77.
4. Section "Managing Dynamic Changes" and created issue #78.
5. Section "Presentation Role" and created issue #79.
6. Section "Form Properties" and created issue #80.
7. Section "Drag-and-Drop Support" and created issue #81
8. Section "Math" and created issue #82.
9. Section "Reusable Component Libraries" and created issue #83.
10. The following 4 Appendix sections related to background on ARIA and created issue #84
A. Background on WAI-ARIA
B. Filling the Gaps for Content Delivered to Desktop Browsers
c. Building Accessible Applications with WAI-ARIA
D. Reasons for Adopting WAI-ARIA
11. The following design patterns:
A. Accordion and updated issue #53.
B. Autocomplete and updated issue #31.
C. Combobox and updated issue #31.
D. Datepicker and updated issue #57
E. Dialog (Non-Modal) and updated issue 59.
F. Dialog (Tooltip) and added issue #85.
G. Landmarks and added issue #86.
H. Popup Help (aka Bubble Help) and added issue #87.
I. Rich Text Editor and added issue #88.
j. Site Navigator - General and added issue #89.
K. Site Navigator - Tree and added it to issue #89.
L. Site Navigator - Tabbed Style and added it to issue #89.
M. Tree Grid and added issue #91.
N. Wizard and added issue #92.
@mcking65 mcking65 mentioned this issue Aug 15, 2016
Closed
@jnurthen jnurthen modified the milestones: 1.1 Q4 PWD, 1.1 PR Aug 15, 2016
tatermelon pushed a commit to tatermelon/aria-practices that referenced this issue Aug 19, 2016
@mcking65 @tatermelon
Removed sections that require major rework to fix incorrect guidance.
572cdf3 
In addition to the below, This commit also moves the landmark section after the example section.

Moved each of the following sections from aria-practices.html to aria-practices-DeletedSectionsArchive.html
and created associated issues for drafting new versions.
1. Section "General Steps for Building an Accessible Widget with WAI-ARIA" and created issue w3c#73.
2. Section "Other Widget Authoring Practices"., primarily about aria-valuenow, there is no specific need to raise an issue for this section.
3. Section "Relationships" and raised issues w3c#74, w3c#75, w3c#76, and w3c#77.
4. Section "Managing Dynamic Changes" and created issue w3c#78.
5. Section "Presentation Role" and created issue w3c#79.
6. Section "Form Properties" and created issue w3c#80.
7. Section "Drag-and-Drop Support" and created issue w3c#81
8. Section "Math" and created issue w3c#82.
9. Section "Reusable Component Libraries" and created issue w3c#83.
10. The following 4 Appendix sections related to background on ARIA and created issue w3c#84
A. Background on WAI-ARIA
B. Filling the Gaps for Content Delivered to Desktop Browsers
c. Building Accessible Applications with WAI-ARIA
D. Reasons for Adopting WAI-ARIA
11. The following design patterns:
A. Accordion and updated issue w3c#53.
B. Autocomplete and updated issue w3c#31.
C. Combobox and updated issue w3c#31.
D. Datepicker and updated issue w3c#57
E. Dialog (Non-Modal) and updated issue 59.
F. Dialog (Tooltip) and added issue w3c#85.
G. Landmarks and added issue w3c#86.
H. Popup Help (aka Bubble Help) and added issue w3c#87.
I. Rich Text Editor and added issue w3c#88.
j. Site Navigator - General and added issue w3c#89.
K. Site Navigator - Tree and added it to issue w3c#89.
L. Site Navigator - Tabbed Style and added it to issue w3c#89.
M. Tree Grid and added issue w3c#91.
N. Wizard and added issue w3c#92.
@mcking65 mcking65 modified the milestones: 1.1 PR, 1.1 Q4 PWD Dec 12, 2016
@mcking65 mcking65 added documentation Practice Page Related to a page within the practices section of the APG labels Jan 19, 2017
@mcking65 mcking65 changed the title Draft guidance section for aria-live Draft guidance section for live region attributes Jan 27, 2017
@jnurthen
Copy link
Member

Note https://www.w3.org/Bugs/Public/show_bug.cgi?id=28611 about aria-busy when drafting this section

@carmacleod
Copy link
Contributor

Would be great to also have some live region examples.
Here's one for status role: https://carmacleod.github.io/playground/status-role.html

@carmacleod carmacleod changed the title Draft guidance section for live region attributes Draft guidance section for live region roles and attributes Sep 26, 2018
@zcorpan zcorpan mentioned this issue May 3, 2019
Closed
@mcking65 mcking65 modified the milestones: 1.1 APG Release 4, 1.2 CR Aug 14, 2019
This was referenced Aug 24, 2019
Closed
Open
@JAWS-test
Copy link

JAWS-test commented Aug 25, 2019 •
edited
Loading

I would like to make the following proposal for live regions and ARIA roles with implicit live regions:

An output of the live region should be made:

  • only with aria-live=polite or aria-live=assertive (explicit or implicit) and without aria-busy=true (implicit or explicit)

With aria-relevant=all/additions/text:

  • Inserting a node into the DOM (only for aria-relevant=all/additions)
  • Changing or inserting text content in an existing node (only for aria-relevant=all/text)
  • Change visibility:
    • from display:none to display:block/inline/inline-block etc.,
    • from hidden to without hidden
    • from visibility:hidden/collapse to visibility:visible
    • from aria-hidden=true to aria-hidden=false
    • for display:none, visibility:hidden and aria-hidden=true also if the attribute or CSS property is removed

However, it should be noted that the actual visibility of the element is relevant, i.e. if I use

<div hidden>
  <div hidden role=alert>
    alert
  </div>
</div>

and remove the hidden at the inner div, the live region should not be output, because the outer div is still hidden. As soon as the hidden is removed from the outer div, the live region should be output.

With aria-relevant=all/removals:

  • Removal of a node from the DOM

  • Remove text content

  • Change the visibility with

    • display:none
    • hidden
    • visibility:hidden/collapse
    • aria-hidden=true
      The difference between new content and removed content should be noticeable (e.g. JAWS outputs "removed")

  • Changing from aria-busy=true to aria-busy=false or removing aria-busy=true (but only if one of the above changes has additionally taken place in the time of aria-busy=true)

For most of the above methods, it should work if

  • the parent or an ancestor element or
  • the element with the live region is changed or
  • the child or a descendant element.

The first two variants (ancestor element or element itself) cannot work with aria-relevant=all/removals if the live region is removed from the DOM. In this case the live region should only work if the change of visibility (via CSS, hidden or aria-hidden) is done at the element or ancestor element. A live region that no longer exists cannot lead to any output.

For all CSS methods (display, visibility) it should work if

  • a class is added or removed,
  • the class definition is changed,
  • the content of the style attribute is changed,
  • the style attribute is added or removed.

It should not matter which JavaScript method is used to insert, change or delete DOM nodes or HTML/ARIA attributes.

An output should not be made:

  • if the live region is already present in the source code when the page is loaded
  • if the ARIA role (or ARIA attributes - see open questions) for live regions are added to the DOM later (i.e. assigned to an existing node)
  • aria-busy=true
  • aria-live=off
  • use of aria-relevant or aria-atomic without aria-live=political/assertive
  • when changing visibility with CSS properties other than those described above, such as
    • opacity
    • color
    • background-color
    • width
    • height
    • position
    • left, right, top, bottom
    • overflow
    • clip
  • when changing other CSS properties
  • if the change takes place within an area in the live region that is hidden (e.g. aria-hidden=true or display:none)
  • if an identical output of the same content has already occurred (e.g. aria-hidden=true and display:none is removed - these are two of the changes described above, but should only lead to one output)

Open questions

  • What is the difference between aria-live=off and no aria-live? The definition in https://www.w3.org/TR/wai-aria-1.2/#aria-live says: "Indicates that updates to the region should not be presented to the user unless the user is currently focused on that region." This sounds as if the focus is not on the whole region, but only on the updates. That would be a meaningful distinction to an element without aria-live, whereby the roles marquee and timer would also have a meaningful purpose (both have aria-live=off). However, this does not seem to be further specified and does not seem to work with assistive technology (it doesn't work with JAWS at the moment: when the live region with aria-live=off gets focus, everything is output). The question is also what is meant by getting focus: Tab navigation, linear reading? As an alternative to just outputting the updates, there should also be a way to output the entire content. It would be nice to implement it in such a way that an update within aria-live=off can also be output without focusing on user requirements (e.g. via access key).
  • Maybe a live region should also be output if aria-live=off is changed to aria-live=polite/assertive or if aria-live=polite/assertive is added? In itself, this should also work because ARIA attributes can be changed. However, the problem is that the ARIA roles that implicitly have aria-live cannot be added dynamically. So this could be an inconsistency in the different methods to implement a live region
  • Should there be a difference between role=alert and aria-live=assertive? JAWS distinguishes strongly between both live regions, according to the specification there are none. On whatsock.com/training/ from @accdc I found: "It's important to note that, when aria-live=assertive is applied to a container without the use of role=alert, it will not tie into the alert system of the Operating System. This only occurs when role=alert is included". However, I do not know whether this only reflects the test experience or whether this is defined in the specification.
  • Should the specification be based on the currently most widespread implementation by assistive technologies in order to achieve the greatest possible compatibility? If so, extensive tests with different browsers, operating systems and screen readers should be carried out.
  • What should be output if, for example, form fields are inserted in the live region (nothing, only the label, label and value, or even the role)?
  • What should be output if the text content in the live region does not change, but e.g. the alt attribute of a graphic, the value attribute of an inputs field, the selected attribute for option within select.
  • What if the text content does not change within the live region, but only text outside the live region that serves as label via aria-labelledby or label for an element within the live region?
  • Should the live region be output if the focus is not on the page with the live region but in another program, on another browser tab or in the browser menu?
  • Should the role of the Live Region be output when reading with the arrow keys and updating the Live Region (All Live Region roles (like marquee and log) are not output correctly FreedomScientific/standards-support#277, Live Region: The role "alert" is only output if visibility is changed (Chrome) FreedomScientific/standards-support#296)?
  • What is considered a changed node in aria-atomic=false? What if the changed node has the same content as the previous one? (Live region: aria-atomic does not work well FreedomScientific/standards-support#290, Live Region: Inconsistent interpretation of "changed node" with aria-atomic=false FreedomScientific/standards-support#298)
  • Should the page language be taken into account when outputting the Live Region? Should the language change within the live region be taken into account?
  • Should a live region be output if the update is in an iFrame (or other embedded element like SVG, Video) and the live region is outside (see Jaws repeats iframe contents in aria-live region when it becomes visible FreedomScientific/standards-support#111).
  • Which text alternatives for non-text content should be output in live regions?
  • Should CSS text be output in live regions?
  • Do the ARIA attributes for Live Regions have to be on the same HTML element or can they be nested? Can they be nested several times? Does aria-live always have to be the outermost attribute or can aria-atomic also be on the outside? At least aria-atomic should be allowed to be inside aria-live. But should the following also be allowed and work?
<div aria-live=polite>
  <div aria-relevant=removals>
  only removals are output
      <div aria-relevant=all>
      all is output
     </div>
  </div>
</div>

I am open for any changes, as long as there is an exact specification. The current implementation of live regions is very frustrating. When customers ask me how to implement a live regions across platforms and for different browsers / screen readers (in JAWS, the output of live regions changes from version to version), I can only say: Sorry, I don't know, because of the many inconsistencies and errors.

For problems with JAWS, see e.g.

This was referenced Aug 25, 2019
Closed
Closed
@JAWS-test
Copy link

An example of the current situation with the WCAG 4.1.3 example: https://w3c.github.io/wcag/working-examples/aria-role-status-shoppingcart/ (using JAWS 2019):

  • no output in Firefox
  • Output of the number in IE 11
  • Output of number and item in Chrome

This was referenced Aug 28, 2019
Open
Open
Closed
This was referenced Sep 3, 2019
Open
Open
Open
Open
Open
Open
Open
Open
Open
Open
Closed
Open
Open
Open
@JAWS-test
Copy link

JAWS-test commented Sep 10, 2019 •
edited
Loading

The following recommendations are based on testing Live Regions with JAWS 2019 and Chrome, Edge, IE 11, Firefox.
For the recommendations to be published on APG, the published examples should at least also be tested with NVDA, Voiceover, Talkback, and Supernova.
The recommendations are not based on the ARIA specification, but on browser-specific errors. The errors are in part due to the inadequate specification.

General recommendations

Browser specific recommendations

@JAWS-test JAWS-test mentioned this issue Sep 11, 2019
Open
@JAWS-test JAWS-test mentioned this issue Sep 28, 2019
Closed
@carmacleod carmacleod mentioned this issue Jan 23, 2020
Closed
@mcking65 mcking65 modified the milestones: 1.2 Release 1, 1.2 Release 2 Oct 17, 2021
@mcking65 mcking65 removed this from the Launch Redesigned APG milestone May 10, 2022
@JAWS-test JAWS-test mentioned this issue Dec 9, 2022
Open
@JAWS-test JAWS-test mentioned this issue Jan 27, 2023
Closed
@JAWS-test JAWS-test mentioned this issue Apr 4, 2023
Closed
@JAWS-test JAWS-test mentioned this issue May 16, 2023
Open
@mitchellevan mitchellevan mentioned this issue May 16, 2023
Open
@JAWS-test
Copy link

There should be a note about the allowed or recommended length of a live region (especially with aria-live=assertive). See FreedomScientific/standards-support#785

@mcking65 mcking65 mentioned this issue Apr 7, 2024
Draft
@mcking65 mcking65 mentioned this issue Dec 1, 2018
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Practice Page Related to a page within the practices section of the APG
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Guideline for live regions w3c/aria-practices
4 participants
@jnurthen @carmacleod @mcking65 @JAWS-test