RE: Use cases for aria-relevant?

Thanks, I see what you mean. If kept it would be good to revise that text I think to make this clearer.

Other than the most widely used version of this, such as role=status which implicitly uses aria-live=polite, it seems to me that the two most useful aspects of this would be (1) the announcement of newly added text nodes, and (2) the announcement of the removed text node. All of the other combinations seem to add noise without meaning.

In the first case, where added text nodes are announced, you already know the value for announcing content changes.

For the second though, where removed text nodes are announced, this may be useful in cases like group live chat dialogs where certain users are logged in, and if they suddenly go offline their user names would disappear from the list. When this occurs the name could then be announced as being removed. This might be useful in other cases too.

All the best,
Bryan





Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com

From: Aaron Leventhal <aleventhal@google.com>
Sent: Monday, April 09, 2018 3:01 PM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Cc: ARIA Working Group <public-aria@w3.org>
Subject: Re: Use cases for aria-relevant?

Bryan,

Regarding that wishy washy "optional attribute" wording: to clarify what we were trying to say, perhaps unsuccessfully: the browser is required to present DOM changes as well as the ARIA live properties (atomic, relevant, live, busy). The screen reader should look at these properties but may consider them hints rather than definitive. For example, if the screen reader has its own useful heuristics, settings or site-specific scripts, it's free to decide what is ultimately the best experience. For example, perhaps a screen reader has a 4-way setting for live regions: speak all, none, use website markup, or "smart" where it makes up its own mind. The ARIA spec authors didn't want to preclude that possibility, that a screen reader could decide to do something "better". We couldn't predict the future and know how good of a job authors would do, or how willing users would be to tweak page-specific settings, or whether ATs would develop useful heuristics (e.g. maybe it's always useful to speak changes that come as the direct result of a keypress). You get the idea -- maybe it needs to be reworded.

- Aaron




On Mon, Apr 9, 2018 at 5:36 PM Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>> wrote:
Hi,
Actually there is a very simple reason why aria-relevant doesn’t work reliably across browsers, which I remember bringing up here in the past but didn’t hear anything back.

According to the spec, browsers don’t apparently have to do anything with this attribute.

“aria-relevant is an optional attribute of live regions. This is a suggestion to assistive technologies, but assistive technologies are not required to present changes of all the relevant types.”
http://www.w3.org/TR/wai-aria-1.1/#aria-relevant


I mentioned this in the past, saying that nobody can ever expect this attribute to do anything useful if it’s not even necessary for browsers to pay attention to in the first place.


Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709<tel:(415)%20624-2709> (o)
www.LevelAccess.com<http://www.LevelAccess.com>

From: Aaron Leventhal <aleventhal@google.com<mailto:aleventhal@google.com>>
Sent: Monday, April 09, 2018 1:52 PM

To: ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Use cases for aria-relevant?

Does anyone know of any examples of aria-relevant being used in a helpful way in shipping software?

I have concerns about this attribute. The PFWG originally added it to ARIA because theoretically a screen reader should be informed about any changes and be able to receive hints on whether those changes are useful. What happens when a user leaves a chatroom and their name is removed from a sidebar list? It seemed bad to develop a standard where it wasn't even possible to have removals of content be presented.

The default, aria-relevant="additions text" is to speak content being added and text changes. This is by far the most useful value, and I'm not sure any other value has ever been used in real life in a successful way.

For any other value to be useful, we'd need to know that AT/Browser combinations have been tested and provide a useful experience. For example, is a user informed that the element was removed? Or will the screen reader just read the element the same way it would have if the element was added?

I'm pretty skeptical of the real-world value of this attribute and wonder if it's causing more harm than good, as authors may not understand what it does, and implementations may not all treat it the same way. (For example, Mac Chrome and Safari are not treating aria-relevant="text" exactly the same for live changes that insert an entire text node).

Right now, it's almost certain that if an author used this attribute it was because they were confused by its purpose and maybe thought it was a helpful bandaid for fixing a bug, and it probably wasn't.

Thoughts?
Aaron