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.