clarifying existing live region announcement behavior on creation/rendering of new live regions #2116
Conversation
Review feedback from dominic
@pkra @spectranaut Can you help me understand the problem with this RFC-2119 change? Yes, it's a change, but it's not "errant." |
The github action being used for this is not that smart. This won't stop us from merging the PR. cc @daniel-montalvo in case there are better options known on the W3C end. |
|
FWIW we could at least change the language of the message and replace "introduces errant" with "contains no". From what I recall, GitHub Actions don't provide a warning-level, which might be more appropriate. Ideally, we could make it possible to manually dismiss the "failure" (like we can with IPR check). |
|
Discussed briefly during PR triage at today's meeting: https://www.w3.org/2024/02/01-aria-minutes.html#t02 |
| <p>When the [=ARIA/property=] is not set on an <a>object</a> that needs to send updates, the priority level is the value of the nearest ancestor that sets the <pref>aria-live</pref> attribute.</p> | ||
| <p>The <pref>aria-live</pref> attribute is the primary determination for the order of presentation of changes to live regions. Implementations will also consider the default level of priority in a <a>role</a> when the <pref>aria-live</pref> attribute is not set in the ancestor chain (e.g., <rref>log</rref> changes are <code>polite</code> by default). Modifications to live regions which are <code>assertive</code> will be presented immediately, followed by <code>polite</code> items. User agents or assistive technologies can choose to clear queued changes when an assertive change occurs. (e.g., changes in an assertive region can remove all currently queued changes)</p> | ||
| <p>When live regions are marked as <code>polite</code>, assistive technologies SHOULD announce updates at the next graceful opportunity, such as at the end of speaking the current sentence or when the user pauses typing. When live regions are marked as <code>assertive</code>, assistive technologies SHOULD immediately notify the user of modifications to the live region. Because an interruption might disorient users or cause them to not complete their current task, authors SHOULD NOT use the <code>assertive</code> value unless the interruption is imperative.</p> | ||
| <p>Typically, assistive technology will only convey <em>changes</em> to a live region, not the initial contents of a live region. To ensure content in a live region is announced, authors SHOULD create a rendered but empty live region as early as possible (such as on page load), and then modify the content of the live region when the author expects changes to be spoken or brailled. The exception to this live region convention is <code>alert</code>, due to system accessibility notifications events required for the role. While an <rref>alert</rref> is a live region, its content is announced by assistive technology when the alert is rendered on the page and when the content changes.</p><!-- Duplicate paragraph in #live_region_roles. Synchronize any changes to these paragraphs. --> |
There was a problem hiding this comment.
I'm not sure why GH isn't showing inline diffs in this lower section. I didn't change all that much. There's a new paragraph at the end, and the phrase "politeness" is now "priority in several places, along with a few other editorial changes.
Closes #1216
Codifies existing UA behavior for live regions, especially in the context of creation and initial rendering, where only
alertlive regions are announced.PR tracking
Check these when the relevant issue or PR has been made, OR after you have confirmed the
related change is not necessary (add N/A). Leave unchecked if you are unsure. Read the
Process Document or
Test Overview for more information.
Test, Documentation and Implementation tracking
Once this PR and all related PRs have been been approved by the working group, tests
should be written and issues should be opened on browsers. Add N/A and check when not
applicable.
Preview | Diff