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> 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
>
> 415.624.2709 <(415)%20624-2709> (o)
>
> www.LevelAccess.com
>
>
>
> *From:* Aaron Leventhal <aleventhal@google.com>
> *Sent:* Monday, April 09, 2018 1:52 PM
>
>
> *To:* ARIA Working Group <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
>