Consider deprecating all special live region roles except alert

[mcking65]

Consider deprecating log, marquee, status, and timer.

They have not proven useful in practice. They are not exposed by most (maybe any) screen reader. They sometimes degrade accessibility. They tend to add author confusion without solving any important accessibility problems.

Adding log to a table, for example, removes table semantics when the table semantics would be more useful than the log role. It would be better to name the table "chat log" if it contains a chat log.

Adding status to a div with status elements doesn't make the status area easier to find or identify. If locating the status area is important, then a div with role region and a name of status would be far better.

If there was a notion that screen reader with a read status function would utilize the status role for that purpose, it is not well thought out. For that to work, there would need to be a status relationship so that the screen reader knows whether or not the current point of regard is in a section of content that has a related status to read.

[mcking65]

Why keep alert. Good question. We could deprecate as well. However, the alert role does recommend that platforms trigger an alert event or sound. None do as far as I know, but it could be particularly useful if they did.

Whether or not this additional platform behavior is best achieved with a role is a good discussion. I think it would be better if alert were another value for aria-live that is like assertive but carries the additional behavior of triggering a platform alert event.

[accdc]

Actually for the alert role, if you just use aria-live="assertive", it won't fire a system alert, but it will only do this if you use role="alert".

E.G You can test this for the alert role at
http://whatsock.com/training/demos/lr/announce%20all/role-alert.html

Using Firefox plus JAWS, click the Test button, then try tabbing away into another application like Outlook, and you will see what the system alert does.

It appears that Chrome Beta has disabled this functionality so it no longer works properly there.

We also have to be careful with getting rid of log and status, because I've seen this many times as part of chat applications over the years, and just deleting these will break all such implementations currently in the wild.

[JAWS-test]

@mcking65 I don't think that's a good idea. Just because the roles are not well supported by the AT and can be misused, they should not be abolished. The fact is that the roles make a lot of sense. And if we abolish them now, many of the pages they have used so far would have to be changed.

They are not exposed by most (maybe any) screen reader.

This applies to reading with the arrow keys (see FreedomScientific/standards-support#277). However, the automatic output is correct when the content is changed (if the role explicitly or implicitly has aria-live=polite or aria-live=assertive).

Adding log to a table, for example, removes table semantics when the table semantics would be more useful than the log role.

This applies to all roles. Each ARIA role overwrites the semantics of the HTML element. This is clearly warned in all specifications about ARIA. Therefore every developer should be aware that <table role=log> is wrong and <div role=log><table> is correct.

Adding status to a div with status elements doesn't make the status area easier to find or identify.

This is an error of the AT, which is partly due to the fact that the ARIA specification does not explicitly require this. My suggestion would rather be to adapt the ARIA specification so that the live region roles serve not only as a live region but also as structuring elements, so that they are also correctly perceptible when reading with the arrow keys (output of role and name at the beginning and end). See also: FreedomScientific/standards-support#282

For the difference between aria-live=assertive and role=alert see FreedomScientific/standards-support#293

[scottaohara]

The only one from this list that I'd rather not see go away is status. Not that I'd necessarily want the others to be deprecated... but I do think timer, and marquee in particular could use a good critique.

But back to status... In the testing I've done with the role, and how i've seen it used well in the wild / how I have recommended it be used in projects to convey polite status messages (globally or on a component level), it has worked well.

Additionally, the output element in HTML has the same platform mappings as the status role, so I'd rather we not regress on role parity here.

[eps1lon]

status is currently considered to make client side routing accessible in gatsby (gatsbyjs/gatsby#19290). According to their testing status seems to be the best role to convey client side routing. I'm confused how they arrive at the conclusion that status is well supported in practice while the initial issue description claims it's not.

What would be the alternative if status is being deprecated?

PS: Looks like https://github.com/gatsbyjs/gatsby/pull/19290/files#diff-2d21ea42ec874a0988977e57b17251aaR124-R141 is the important part.

[scottaohara]

all comes down to the way it is being used / implemented I'd imagine. There can be issues with any live region, depending on how it's used / when it is added to the DOM. But as a persistent element in the DOM that has content injected into it, I've found little in the way of gaps with status save for IE11 support.

Gatsby's use is interesting because they've augmented the role by using aria-live=assertive on it as well, making it no longer polite.

[bolonio]

What's the benefit then to augment the role by using aria-live=assertive in the role="status"?. Status was defined to be polite because the content of the status message is not important enough to break the screen reader flow, right? Correct me if I'm wrong.
But I totally agree with you @scottaohara when you said "The only one from this list that I'd rather not see go away is status".

[StommePoes]

I'd rather documentation was clearer and in more places (for example, every tutorial or instructions for widgets which use live regions). Developers don't realise what live regions do to tables as mentioned above, and recommendations to add live regions to tables (for when rows are dynamically added) is not uncommon.

Since many of the live regions (even alerts) that I run into on the web are

• away from where my most recent action took place (not local to my view), and
• require or suggest I interact with the region (an error message alert with a link to "contact support"), or if you're a keyboard-only user and an alert is large and sticky, with a Close button... but is positioned at the very top of bottom of the page, while your focus is in the middle.

it might be better to improve documentation, training, tutorials and instructions for widget components. In the cases above a live region isn't a great idea anyway: if I need to navigate it and cannot see where it is, I have to hunt. If I'm using screen magnification I'll not hear it. Same with Braille-only-- if I'm using a screen reader but I'm deaf/hoh I'll not hear it.

Maybe some of the issues we're seeing with the various non-alert live regions is due to them being peddled a bit hard in the dev world as an easy go-to solution for letting users know stuff (regardless how important that stuff may be), without better informing developers of the repercussions and also the limitations. There are places where it may be better to move focus than use a live region (especially for task-breaking or must-be-interacted-with errors), even with all the dangers that entails.

[aardrian]

@mcking65

Adding log to a table, for example, removes table semantics…

A bit off-topic, but can you share a test case or at least the browser(s) where this happens?

Given that browsers also drop table semantics when using nearly any CSS display property, I feel like filing this bug (if not already filed) might help bolster the case to fix related table semantic bugs.

[aardrian]

Oops. I missed that @JAWS-test asked already, @mcking65. I thought you had a construct like <div role="log"><table> and it was breaking the descendant table. I did not occur to me you were overriding the <table> itself. My fault for reading and commenting from my mobile.

[smhigley]

I'd like to add a thought about marquee:

I've frequently run into challenges with live-updating data, either in a table or (more often) in a graph, or both. Update frequency can easily be over once per second, so a straightforward live region is entirely out.

So far I'm not aware of any solutions using marquee nor have I recommended any, because the practical support isn't there. There is a need for some way of communicating regions with constantly updating information, though.

[DavidMacDonald]

I find "role=status" works fine... provides aira-live=polite and aria-atomic=true in one simple role without the mess ... seems to be well supported in NVDA and JAWS. We've been advocating it as a technique to meet WCAG 2.1 SC 4.1.3 since June 2019 after it tested well.

[mbgower]

Just to add to @DavidMacDonald's comment, we created the new Status Messages SC in WCAG 2.1 specifically to deal with situations where content is added to a screen but DOESN'T take focus. Shopping cart updates, info about search results, etc.
I'd be very sorry to see role="status" disappear. We've created techniques for it (and for the less supported log role) and spent a lot of time stick handling it through to inclusion. I'd encourage anyone planning to deepsix it, to look at the Understanding document and associated techniques we created.
I've already found many situations where Status Message and its associated techniques have solved an issue in a design, and I find that in particular role="status" is quickly understood and typically properly implemented a lot more frequently than a generic live region.

[carmacleod]

Summary:

• status: general consensus is to keep this role (it's well understood, it's used, it's in WCAG, role parity with HTML output element)
• log: some consensus to keep this one (it's used, it's in WCAG, @aleventhal mentioned that the semantic that new content is added to the end could be useful)
• marquee: maybe. see @smhigley's "thought about marquee" in Consider deprecating all special live region roles except alert #1104 (comment)
• timer: general consensus is that this could probably go. @jamesn mentioned that it could theoretically be used if user could ask AT for the value

There's also a general consensus that the spec(s) need to be clearer about some things, e.g.:

• allowing/not allowing on table element, etc
• better informing developers of the repercussions and limitations
• more guidance and examples
  • including what happens with e.g. <table role=log> vs. <div role=log><table>

[JAWS-test]

• marquee and timer are also mentioned at the WCAG
• I think all live regions are useful and would argue for improving the AT support

A modern form of marquee can often be seen on company websites where one sentence starts statically and the second part changes dynamically. A theoretical example would be:

• <h1>Live regions are <span class=change>cool</span></h1>
• <h1>Live regions are <span class=change>important</span></h1>
• <h1>Live regions are <span class=change>helpful</span></h1>

Without the marquee role, there is no way for AT users to notice that the content is constantly changing. aria-live would be inappropriate, since the permanent output of the live region is not desired

[smhigley]

I saw the call transcript, so I just wanted to bring up a couple things about timer and marquee, and live regions in general:

As things stand now, we run a lot of cases were we need better live region capability to handle rich application-like experiences. Here are some of those cases:

• Live data updates, most often in a chart, data table, or list. This could be either at regular customizable intervals, or as-needed. A concrete example would be something like a graph of server memory usage over time, updating every 5 seconds.
• A live countdown, or timer of how long a task has been underway. We run across this quite a lot, actually, and in the most extreme cases have recommended a hybridized live region with user settings to control frequency of update. One example: you're running some sort of process on the cloud. After pressing the "Run" button, a timer of how long the task has been in process appears, along with an updating list of completed steps.
• Non-blocking loading or progress indicators (pretty much the progressbar role, but with better support)
• Many possible parallel loading regions or progressbars

The thing preventing us from using timer and marquee all over the place right now is not a lack of need, but a lack of support. Unless the suggestion is to remove these roles in favor of something better, this seems like a step backwards.

[jnurthen]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

[Consider deprecating all special live region roles except alert](#1104
mcking: I'm wondering if we shouldn't first talk about other aria-live issues.
... we can probably get rid of a few.
... but my concern is that these things in themselves do not provide much.
... not semantically useful.
... e.g., region named log are better in a practice than a log that has no utility for screenreader users.
Aaron: history: we didn't really know what we want to do live regions.
... polite came later.
... makes sense to get rid of marquee, timer.
... I think log might be useful.
... to know that the most recent stuff is on the bottom.
jnurthen: then we should write that into the role.
mcking: I'm not sure a role is the right way to achieve this goal.
... if you're exposing the log role, overwriting e.g., list semantics, then you're reducing accessibility.
jnurthen: that's an author error.
... validators would log an error.
scott: author should have div with role around list.
mcking: there was weak vs strong semantics discussion.
jnurthen: I think we shouldn't drop a role just because it's misused.
mcking: but what is the value?
jnurthen: e.g., Aaron's earlier point
Aaron: screenreader could start at the end. Would that be helpful.
mcking: not sure. don't know what AT devs would find useful.
Aaron: me neither. I haven't watched users encounter log content. I'm guessing lots to improve.
jnurthen: anyone disagree with deprecating marquee and timer?
various: +1
jnurthen: the only theoretical use I see is if screenreader had a feature for "ignore these regions until I ask you"
... for timer.
joanie: orca does this.
... allows the user to override author "creativity"
Aaron: I didn't want to get hooked on log. I just wanted to give AT devs to chime in before we axe it.
jnurthen: joanie do you care what role it is? or just aria-live?
joanie: aria-live.
... deprecating would be fine.
Aaron: historically, marquee came from MSAA having that.
... but let's kill it.
carmacleod: Sarah had a good comment.
<MarkMccarthy> From Sarah: "So far I'm not aware of any solutions using marquee nor have I recommended any, because the practical support isn't there. There is a need for some way of communicating regions with constantly updating information, though."
carmacleod: there's a wcag rule with example.
jnurthen: yes, those would need updating.
mcking: will make a PR.

[cookiecrook]

I believe WebKit exposes all of those roles as live regions with the various default values for aria-live. We also know that web authors still use these conceptually. For example, marquees (conceptually, not necessarily the role or element) are used a chyrons, and I think this is likely to increase as on-demand audiovisual media moves increasingly to the Web.

IMO, we should not remove ARIA concepts that are used conceptually, unless we think the implementation is somehow harmful or useless (like we did with ARIA drag-and-drop)

[carmacleod]

In case it's useful, I did a bit of testing for marquees (due to the recent change of name required to name supported on marquee role). Safari/VO has good support, and VO is the only screen reader to read the aria-label on a marquee (even though it is exposed in all browsers).
Results listed in w3c/aria-practices#1572 (comment)

@cookiecrook I had to look up chyron. 😄

[AutoSponge]

Due to lack of support for role=marquee, I've set widgets to aria-live="off" aria-relevant="additions text" aria-atomic="false". When the widget is focused, switch to aria-live=polite. I think this works in the spirit of marquee and around the issue of support. I'm curious if this "pattern" would replace role=marquee as a named pattern (along the lines of Disclosure which has no associated role) within WAI-ARIA.

[brennanyoung]

Having some aria sugar to control update frequency easily for stuff like timers and live data plots would be extremely useful, this is not very well-handled by juggling between assertive, polite and off.
We use timers A LOT. We also use live updating data views (log and status roles) to express stuff like heart rate, blood oxygen etc. for virtual patients in medical simulations.

No experience or opinion about marquee.