WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Am I understanding aria-relevant="removals" correctly?

for

From: Bryan Garaventa
Date: May 29, 2015 12:09PM

Happy to help. :)

> whether the container contains additional text or not.'* So this says to me, as best I can parse it, that if text is removed and aria-relevant is set to "removals" then nothing is voiced, since there is, in that instance, no
> "newest text". This seems to match what I was trying to say before.

Actually no, there are two different events, one that takes place when nodes are added, and another that takes place when nodes are removed.

When aria-live is set to 'polite' and no other attributes are added, it uses the default value of aria-relevant, which is 'additions text'.

This specifies that only newly added text should be announced as the newly added nodes are past to the screen reader via the correct event fired by the browser.

However, if you change aria-relevant to 'removals' instead, you are saying ignore the new text event, and only listen for the text removed event instead, which is then the only event that the screen reader should be parsing at that point.

> However, in your email message, you say *"removed text of that node is subsequently announced."* This has not been my experience thus far (see below).

Granted, this only works in JAWS+Firefox. I've tried the following page using JAWS15 and 16 with the same results, though this is on Win7:
http://whatsock.com/training/demos/lr/aria-live-polite-removals.html

I'm not sure why the Deque example is showing you different results here, but one clue is that they are using a role at the same time, either Status or Log.

There is nothing in the spec that says what ATs should do if it includes both a role and overriding aria-live, aria-atomic, and aria-relevant attributes at the same time, however there may be conflicts in doing this.

For example, if you use role="alert" in addition to overriding attributes such as the following:
<div role="alert" aria-live="polite" aria-atomic="false" aria-relevant="removals"></div>
(Which is technically the opposite of role=alert in every way.)

Still the alert role will take control in browsers like Firefox regardless. This may depend on the browser, but it's not always clear how ATs will handle these differences.

Another thing to keep in mind, the spec notes the following regarding aria-relevant:
"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."
Reference: http://www.w3.org/TR/wai-aria/states_and_properties#aria-relevant

It's no wonder then that there is no reliable way to get these attributes to work together in a cohesive manner, if support by ATs is deemed as optional.

I see this logic as a flaw in both the spec and in the understanding of AT vendors.