w3c
Guideline for live regions
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 aria-relevant section, but it can be clearer. The ARIA spec says for additions:
Element nodes are added to the accessibility tree within the live region.
whereas this PR currently says
additions: Element node additions
I think the descriptions here should match those in the ARIA spec, and then give some examples (e.g. how changing CSS display can cause a removal from the accessibility tree).
https://github.com/w3c/aria-practices/pull/1045 introduces a section about accessibility trees, so this section can reference that.
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 output has role=status by default, which makes it a live region.
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 output in the role=status section.
I think the descriptions here should match those in the ARIA spec, and then give some examples (e.g. how changing CSS display can cause a removal from the accessibility tree).
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 (https://github.com/w3c/aria-practices/issues/78#issuecomment-524619306) 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: https://github.com/FreedomScientific/VFO-standards-support/issues/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.
@zcorpan
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/. I would also like to see something like this for Live Regions. Especially since I think that the current ARIA specification contains bugs and ambiguities (https://github.com/w3c/aria/issues/1048, https://github.com/w3c/aria-practices/issues/78#issuecomment-524619306)
@zcorpan:
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 https://github.com/w3c/aria/issues/1001
@jnurthen I don't recall if we discussed this at TPAC. :) Should we discuss this on next week's telecon?
@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 https://github.com/w3c/aria-practices/pull/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 aria-live guidance.
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/w3c/aria-practices/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/w3c/aria-practices/pull/1027
<Jemma> https://github.com/w3c/aria-practices/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/w3c/aria-practices/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. http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20with%20Substring%20Match)/demo.htm
To identify the dynamic results of drag and drop widgets when actions are performed. http://whatsock.com/tsg/Coding%20Arena/Drag%20and%20Drop/demo.htm
Dynamic error handling for inline errors. http://whatsock.com/tsg/Coding%20Arena/Inline%20Form%20Field%20Validation%20and%20Dynamic%20Help%20Tooltips/Inline%20Form%20Field%20Validation%20(Simple)/demo.htm
Dynamic tooltips when focus remains on the same input to guide user responses. http://whatsock.com/tsg/Coding%20Arena/Inline%20Form%20Field%20Validation%20and%20Dynamic%20Help%20Tooltips/Dynamic%20Help%20Tooltip/demo.htm
Dynamic chat implementations for new message feedback during user interaction. http://whatsock.com/tsg/Coding%20Arena/Web%20Chat%20and%20Dynamic%20Message%20Announcement/Web%20Chat%20(Static)/demo.htm
A simple checkbox control to identify a shopping cart experience. http://whatsock.com/tsg/Coding%20Arena/Web%20Chat%20and%20Dynamic%20Message%20Announcement/Dynamic%20Message%20Announcement/demo.htm
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.
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.
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 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.
However, it's important to note that having live regions alone cannot guarantee accessibility.
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.
In theory, screen mag could have bugs filed against them to add live regions for non-local error messages.
Like this https://github.com/FreedomScientific/VFO-standards-support/issues/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?
Wouldn’t concerns around screen magnifiers and related AT need to be addressed in presumably visual ways, whether they are stateful or not?
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.
The modality of consumption for liv regions is screenreader delivered audio or Braille, right?
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.