Guideline for live regions #1027
Conversation
|
Need to add guidance that explains what types of DOM changes the spec says should trigger live regions. (related to issue #1138) |
|
I think this is covered under the
whereas this PR currently says
I think the descriptions here should match those in the ARIA spec, and then give some examples (e.g. how changing CSS #1045 introduces a section about accessibility trees, so this section can reference that. |
zcorpan
force-pushed
the
zcorpan/live-regions
branch
from
88ca5a1
to
2dbf2b4
Compare
|
If there are interoperability bugs in the area for dynamic updates, I think that should be addressed in the ARIA spec (if it needs changes), tests and bug reports. If there are implementation bugs that make something not suitable as best practice right now, then it seems reasonable to have APG call that out, however. Are there such cases that we should cover in APG? (I'll wait a bit with converting this to HTML, since this may need more rounds of edit and review.) |
|
Per https://w3c.github.io/html-aam/#html-element-role-mappings Credit to @scottaohara for this finding: https://www.scottohara.me/blog/2019/07/10/the-output-element.html I think this section should at least include an example of |
I think it would be good if the chapter on Live Region in ARIA practices could be expanded to include more details on the correct implementation. There are several open questions (#78 (comment)) and many bugs that can be seen in the implementation, both in the assistive technology and the browsers (for JAWS see https://github.com/FreedomScientific/VFO-standards-support/issues?q=live+region) as well as with the web developers. With WCAG 4.1.3, however, correct implementation is becoming increasingly important. |
|
Support for output seems not to be good: FreedomScientific/standards-support#268 |
|
I agree that correct implementation is important, but I think changing APG is not an effective way to fix bugs in implementations. APG is about how to use ARIA, not how to implement ARIA. Per http://w3c.github.io/aria-practices/#browser_and_AT_support it also does not describe or work around bugs in the implementation of ARIA. If you think APG should take a different stance on discussing bugs in implementation, please file a new issue. |
|
I don't think that APG should be concerned with browser and assistive technology bugs, but should contain good examples and detailed explanations of Live Regions, so that the many bugs of browser manufacturers and developers can be avoided. For example, there is a long chapter on Accessible Name in the APG preview (Chapter 5), which in itself is superfluous, because everything about it can be found in https://www.w3.org/TR/accname-1.1/ . But Chapter 5 of APG explains very well for developers the things that are hard to understand in https://www.w3.org/TR/accname-1.1/. |
|
For many of my test cases at https://github.com/FreedomScientific/VFO-standards-support/issues?q=is%3Aopen+is%3Aissue+author%3AJAWS-test+live+region I can't tell myself what a correct output of the screenreader should be like. I can only report an error that the output is not consistent. But which browser makes it right? As long as this cannot be clearly derived from the ARIA specification, there is a need for improvement in the ARIA specification on the one hand and for further explanations in the APG on the other. |
|
OK, I think this section could do more to explain the issues with live regions and go into more detail. It sounds like this topic could use some teleconference time or TPAC time to discuss what the issues are that APG should cover. |
|
If there is something specific to dicuss and the relevant parties are going to be there I am happy to put it on the TPAC agenda. To do this please add the F2FCandidate label to the relevant issue AND provide the requested details in w3c/aria#1001 |
|
I will be there. |
|
@jnurthen I don't recall if we discussed this at TPAC. :) Should we discuss this on next week's telecon? |
|
Add a link to second layout grid example |
|
@mcking65 wanted a more thorough list of cases that trigger live regions. Currently that section mostly links to the accessibility tree section, which has new content in #1045 -- but still doesn't enumerate all possible cases. I haven't had bandwidth to address this. But I think it's also not clear from the relevant specifications how CSS affects the accessibility tree, so it's difficult to state anything with confidence in APG. |
|
The ARIA Authoring Practices (APG) Task Force just discussed The full IRC log of that discussion<MarkMccarthy> TOPIC: aria-live guidance<MarkMccarthy> Matt_King: we have a PR for this, carmacleod put a bunch of comments in here <MarkMccarthy> carmacleod: yeah... [chuckle] <Jemma> https://github.com//pull/1027 <MarkMccarthy> Matt_King: since you added info, did you want to discuss? <MarkMccarthy> carmacleod: it was mostly editorial. the one thing that isn't is role=region <MarkMccarthy> Github: https://github.com//pull/1027 <Jemma> https://github.com//pull/1027#discussion_r366310011 <MarkMccarthy> carmacleod: do we want to take the role off completely, with a blank div? <MarkMccarthy> carmacleod: i believe that, probably, it was written that way because it made sense and the examples didn't want to use something that wasn't discussed yet, so region was used (vs status or something similar) <MarkMccarthy> carmacleod: so, do live regions need a role? should they have a status role? be on a div? etc.? <jamesn> q+ <MarkMccarthy> Matt_King: they can be just on a div, paragraph, li, anything. so we don't want to necessarily use role=region; not to mention confusion of live-region and role=region <sarahhigley> :D <sarahhigley> <div aria-shouty-bits="extra-shouty"> <MarkMccarthy> Matt_King: live content is same as any content, so we can fix the examples, but you raise a question that might not be adequately addressed in the guidance <MarkMccarthy> Matt_King: such as what should the live region be on <jamesn> q- <Jemma> https://www.w3.org/TR/wai-aria-practices-1.2/#aria_lh_region <MarkMccarthy> Matt_King: we listed the properties in the beginning, with a table in the beginning summarizing differences between everything. maybe there's an oversight, or and editorial bias... <MarkMccarthy> Matt_King: maybe we should get rid of some of these things that don't need to be there very often (like marquee, log) <MarkMccarthy> Matt_King: perhaps some bias on my part that we didn't summarize those. did you find the structure confusing? <MarkMccarthy> carmacleod: no, it made sense. but, you don't want to use the roles before describing them. it's a spec thing. <MarkMccarthy> Matt_King: we DO want to describe the properties, though. <MarkMccarthy> carmacleod: so, maybe we delete role=region <MarkMccarthy> carmacleod: but, one of those had a label. a contacts list where Alice came online. maybe that should be a landmark. so a landmark region? <MarkMccarthy> carmacleod: but, that depends on the app etc. but a contacts list is a landmark IMO <jamesn> agree with the contacts list one remaining a landmark <MarkMccarthy> Matt_King: a few people including Scott and Bryan, JAWS-test maybe; we've thought about what the reliable changes are that trigger a live region to activate <MarkMccarthy> carmacleod: 5.1.4 (triggering live regions) discusses some of that, and I called that out too as needing more <MarkMccarthy> carmacleod: there's lots of info that implies what triggers stuff, but needs lots more concrete description <MarkMccarthy> Matt_King: is there someone that can help out with this? <jamesn> https://w3c.github.io/core-aam/#mapping_events_visibility is where this should be defined isn't it? <MarkMccarthy> Bryan: I've actually wanted to research this, and probably could. technically, it also works when a DOM node is added; when CSS is added. this all depends on whether AT picks it up and announces it, that's the unreliable bit <MarkMccarthy> Matt_King: I should go back and discuss with an eng. I was working with here; we found a way that seemed pretty reliable, but I don't remember what we did. I remember it being super easy <MarkMccarthy> Matt_King: in anyone's experience - is there a really short list of ways that ALWAYS work? <MarkMccarthy> sarahhigley: NO <MarkMccarthy> sarahhigley: [chuckle] <MarkMccarthy> Bryan: most reliable is adding HTML to an element with aria-live="polite" <MarkMccarthy> sarahhigley: doesn't always work though <MarkMccarthy> Matt_King: what we did was take content out, put it back in to the element, and then it'd work. kind of depended on how different the content was <MarkMccarthy> sarahhigley: other considerations though like memory, DOM weight, focus, <MarkMccarthy> sarahhigley: there's weird stuff that happens <MarkMccarthy> sarahhigley: probability of it not working scales w/ complexity of code. and sometimes also, it just doesn't work because the moon isn't full [chuckle] <MarkMccarthy> Bryan: recently, we've been trying to make error handling more reliable, devs want to automatically render an error tooltip that, upon rendering, is announced. So the live region is being added to the page, and that's what they want announced. <MarkMccarthy> Bryan: it works sometimes, but is not reliable <MarkMccarthy> Matt_King: seems like if there are some *mostly* reliable techniques, we should add them here <MarkMccarthy> sarahhigley: yeah, there are some I can think of. but they have a few caveats, like where the live region is located in proximity to another element; if a region should be pulled in; pulling content out of the region; etc. <MarkMccarthy> Bryan: similarly, I think it's really weird. and, it's good to say you can't fully rely on live regions to make something hugely accessible <MarkMccarthy> Bryan: people also put role=alert on something, expecting it to be announced when a page is rendered, and it isn't. <MarkMccarthy> sarahhigley: except sometimes it is! <MarkMccarthy> Matt_King: but it's not distinguished? <MarkMccarthy> sarahhigley: some screenreaders do that, NVDA i think? <MarkMccarthy> MarkMccarthy: yes <MarkMccarthy> Jemma: a suggestion - why don't we put *all* this info into one place and we can start there? a comment or new issue about status of this topic and we can figure out next steps <MarkMccarthy> Bryan: I don't think it's wise to make a compatibility table, but listing ways content can be added and how that affects live regions and vice versa. that should be fairly easy to distinguish and won't change *as much*. <MarkMccarthy> Bryan: also, our goal is to standardize support, and this should help. <MarkMccarthy> CurtBellew: does it help to associate those methods with a use case? <MarkMccarthy> Bryan: yes and to identify different methods to recommend a live region, what constitutes a supported live region <MarkMccarthy> Matt_King: we could change that section on triggering live regions to something like "triggering AND common use cases" and listing some use cases along with reliable methods <carmacleod> Live region guidance issue: https://github.com//issues/78 <MarkMccarthy> Matt_King: maybe that's a good idea. I'm happy to help clean up editorially, if folks could add comments to the issue. <MarkMccarthy> carmacleod: there's already a bunch of comments from JAWS-test about what works/doesn't. they've listed many things they've noticed so far <Jemma> https://github.com/FreedomScientific/VFO-standards-support/issues?q=live+region <MarkMccarthy> Matt_King: even if we had like 4 common scenarios; form field error, something on single page apps, on page load; those could be good. sarahhigley, Bryan, MarkMccarthy could you add some comments to that? <Jemma> loved solution! <MarkMccarthy> CurtBellew: something else to consider is an incoming chat message <MarkMccarthy> sarahhigley: or also app-wide push notifications |
|
I am very much in favor of to specify clearly when a live region must be output by AT. Then, in the next step, a ticket can be opened at the manufacturer of the AT, if this does not work as specified. I don't think it's useful to list what the current state of live region output is, because that doesn't solve the problem of not being clearly specified. Once the specification clearly states what must result in the output of a live region, the problems in the AT can be fixed. |
|
To clarify some of the areas where live regions are important in practice and expound on what I said in the meeting, I have some examples here that are all valid. Combobox, where the first suggested item is automatically announced using a dynamic live region. To identify the dynamic results of drag and drop widgets when actions are performed. Dynamic error handling for inline errors. Dynamic tooltips when focus remains on the same input to guide user responses. Dynamic chat implementations for new message feedback during user interaction. A simple checkbox control to identify a shopping cart experience. As I said during the call, live regions must never be relied upon to ensure accessibility, but using live regions can significantly enhance accessibility for accessible implementations. |
That may be the current situation, but that must change. Live region must function reliably. One reason for this is e.g. the WCAG, SC 4.1.3 |
|
"That may be the current situation, but that must change. Live region must function reliably. One reason for this is e.g. the WCAG, SC 4.1.3" I agree totally that live regions must function reliably and as expected. However, it's important to note that having live regions alone cannot guarantee accessibility. E.G. Within JAWS, you can disable the announcement of llive regions in the Verbosity dialog (Insert+V), which will make your guaranteed accessible app totally inaccessible if it relies solely on live regions. |
|
I’m a bit confused by this justification of aria-live being able to be turned off. In application contexts with custom controls that don’t easily map to existing native concepts, aria-live is a primary modality for conveying information to a screen-reader user. Is there some sort of stateful buffer being proposed or some other mechanism that can act as a replacement? Otherwise, what is the alternative that cannot be turned off, which can also guarantee accessibility?
|
|
Hi Sina, I'm not justifying anything, and unfortunately there is no alternative in many cases for a user to receive this information, in which case it must be announced reliably. My point is though, that the screen reader provider allows for this to be turned off, and we as developers have no control over this. If a user does so, then they will not be able to access the functionality unless it is accessible on the page in some other fashion, such as through basic navigation commands. E.G. Providing invisible error alerts that are announced is not a sufficient mechanism for displaying an error if it cannot also be arrowed to within the page during standard navigation. |
I can disable the output of a lot of content, ARIA roles, etc., in JAWS. However, this is the responsibility of the user and is not a problem of live regions. By reliable output, I mean output in the default setting of the respective AT, or in a setting with high verbosity. As soon as this works reliably, I am satisfied. |
|
I completely agree with this:
“E.G. Providing invisible error alerts that are announced is not a sufficient mechanism for displaying an error if it cannot also be arrowed to within the page during standard navigation.”
But, I also agree that many things can be turned off by the user, and that is on them once done, so that always having an equivalency for aria-live must not be required; however, in the case of errors, that makes total sense.
|
I'm always looking to see if something else can work too-- not because a screen reader user can turn off announcements (I agree that's on the user), but for screen mag and Braille-only it's still an issue. In theory, screen mag could have bugs filed against them to add live regions for non-local error messages. |
Like this FreedomScientific/standards-support#15 ? |
|
Wouldn’t concerns around screen magnifiers and related AT need to be addressed in presumably visual ways, whether they are stateful or not? The modality of consumption for liv regions is screenreader delivered audio or Braille, right?
|
Could be, wouldn't have to be. Right now I get control names read out but not states in ZT and it's helpful for those with issues reading the names visually. Other magnifiers don't do any audio and I'm not thinking those ones should add it for live regions... I'm just thinking of the ones who already do some audio. In Real Life, developers are generally running on the assumption "live regions are for people who don't see [some obvious visual change OR alert text]" but they don't tend to realise the effects of limited viewports. If screen mag could read out live regions the way some read out control names, more users would get that benefit.
Is someone delivering Braille? Last I heard (a long while back), there were good reasons not to, but that left the issue unsolved for deaf-blind users. The SR portion of course gets the live region, but if you can't hear your screen reader, you're not getting what is sometimes essential information. It's something I'm always thinking about and keep wondering if anything in standards or guidelines could help. Maybe even just good docs reminding developers and designers about limited viewports would help? |
|
These comments around interplay between aria-live and screen magnification are super helpful, so thank you for that.
I agree that aria-live needs to be figured out for Braille. It’s not fair, especially to those who are deaf-blind, that this channel of information is not presented, and I can think of so many trivial ways screen readers could make this available, not the least of which is a simple keystroke that let’s you review the last 10 alerts, with a one character notifier of their existence, or a flash message if the user so chooses. It would be a small engineering ask and a monumental usability win, but sadly, I don’t run screen reader dev teams.
And, given how you use screen magnification, this idea that aria-live may be needing to be spoken even though other things are not being spoken also makes a lot of sense.
That answers my query, so thank you.
|
| </tr> | ||
| <tr> | ||
| <td><code>aria-busy</code></td> | ||
| <td>Defers content updates. Not specific to live regions. See the <a href="#aria-busy">next section</a>.</td> |
There was a problem hiding this comment.
| <td>Defers content updates. Not specific to live regions. See the <a href="#aria-busy">next section</a>.</td> | |
| <td>Defers announcement of content updates. Not specific to live regions. See <a href="#defer_exposing_content_updates_using_aria-busy">Defer Exposing Content Updates using aria-busy</a>.</td> |
|
From the call last week, here are four common situations where I frequently come across use cases for live regions:
My team and I also have a general live region guideline based on anecdotal feedback and preferences from screen reader users that live regions should not be used for changes that are immediate and predictable, or part of the expected functionality of a control. So, for example, we would not recommend using a live region for announcing results in a combobox dropdown, or the result of a drag & drop; instead we would recommend making the control's name, role, states, and description adequate for the user to understand what is going on. |
|
Sina:
This reminds me of a comment made I think by Derek about NVDA on Twitter. There's no queue (and this is deliberate) although I'm unfamiliar with any possible queueing in the refreshable braille part of things. Which relates to Sarah's point:
React developer Flarnie ran into exactly this and "solved" it with a manual setTimeout() :( (thread: https://twitter.com/ProvablyFlarnie/status/1166141795652141059 ...unfortunately some replies by one NVDA developer appear to be gone. Specifically, another NVDA developer (Derek) replied about queues in this sub-thread https://twitter.com/stommepoes/status/1166247305433026560) I like Sarah's point #3 and have heard of people being specifically unhappy that the place where they expect to see these records do not find them there. Regarding point #4 when offering remediation in audits, groups I've worked with have had trouble with things like large changes happening within a large table (rows being added or removed) in-place using JavaScript... we're certain nobody wants to suddenly start hearing all that new content, but instead a dedicated, short message only saying there were changes. Or even a system-bell type thing (for some apps which are used regularly by users, not one-off websites users have no chance or inclination to spend time learning). I have seen developers put |
|
@StommePoes good clarification on point 4 😄. I definitely would recommend a live region announcement along the lines of "N results found", not literally the content of every search result/filtered row 😅. Regarding using a timeout to solve focus/live region conflict -- I've tried this, and it didn't work reliably for me unless the timeout was longer than the full focus announcement (which would be impossible to determine ahead of time). Sounds like it's time for even more live region testing 😁 |
The following note is being added to the aria-errormessage example in ARIA PR #1157. Does this seem helpful?
|
|
Mal, thanks for the clarifications, but I can’t think of a single technical reason why queueing can’t happen for previous messages, Braille or otherwise. It just sounds like dogma sans any evidence, instead of a fact-based reason for not doing something. I’ve heard many such claims over the decades, and pretty much all of them have come down to some combination of not wanting to do or prioritize something, rather than it being hard or impossible. Hey, I could be completely wrong, though. At any rate, that’s probably quite off topic here, so happy to discuss elsewhere if interested.
As far as usage of aria-live, we generally advise folks to simply announce that there are N errors, set focus (only if appropriate) to the errors list which should be displayed on screen or the first component with said error, where the error is clearly associated with the field through some change that ends up modifying accessible name, and then to follow other best practices around invalid and required states. Obviously, moving someone’s focus is treated as sacred, and only done with the utmost care. Also, following the principle of semantic prioritization, an announcement of “has error” is appropriate, IMHO, to come first, before the original label announcement, but if-only-if this is tested well, to ensure it doesn’t happen on a blank form, for example. Original invalid due to empty is not error 😊.
I very much hope nobody is ok with large swaths of text being slammed into an aria-live region, polite or assertive, as that’s completely and utterly useless based on basic first principles (no examples or code needed, just cognitive science around working memory and lack of navigability). If we are trading horror stories really quick. Mikrotik routers used to have a web interface with aria-live=assertive around the bandwidth block, so anytime there was a single kb/s of change on the network, which of course is literally every single second, it would update, making the entire interface completely unusable, until of course I removed it by injecting JavaScript into the address bar (so fun!).
|
At least with JAWS, the value in aria-live seems to have no effect. Therefore, it would be useful to name the affected field in the blur event error message so that the AT user knows what the error message refers to |
| </p> | ||
|
|
||
| <p> | ||
| When this attribute is omitted, the user agent will use the closest ancestor that has <code>aria-atomic</code> set to <code>true</code> or <code>false</code>, |
There was a problem hiding this comment.
| When this attribute is omitted, the user agent will use the closest ancestor that has <code>aria-atomic</code> set to <code>true</code> or <code>false</code>, | |
| When this attribute is omitted, the user agent will use the value of <code>aria-atomic</code> from the closest ancestor that has <code>aria-atomic</code> set to <code>true</code> or <code>false</code>, |
|
Replaced by #2989 |
Fixes #78
Preview | Diff