Re: Use cases for aria-relevant?

Bryan, the "buddy list" in chat is the pretend use case we came up with. I
don't think anyone has ever actually done it, which makes me think that
aria-relevant is causing more harm than good. I see it being used
inappropriately.

Also, there is probably a better way of dealing with the chat situation --
a line of text in the chat, or a status line, or an invisible region that
simply says "Freddy has left the chat". That would work today, and that way
there is no ambiguity as to what the point of speaking "Freddy" is.

Aaron

On Mon, Apr 9, 2018 at 6:20 PM Bryan Garaventa <
bryan.garaventa@levelaccess.com> wrote:

> 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 <(415)%20624-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> 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
>
>