WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Bryan Garaventa
Date: May 28, 2015 4:48PM

It's important to understand the events being triggered by the browser, as well as compatibility issues that you will encounter during testing.

Firstly, the attributes described including an explanation of each with some additional code samples can be found at
http://whatsock.com/training/#hd25

The specific demo of aria-relevant that works in Firefox + JAWS within the above referenced section, is at
http://whatsock.com/training/demos/lr/aria-live-polite-removals.html
(Confirmed using JAWS16 + Firefox on Win7)

This works because the text events fired by Firefox reflect the DOM node that is removed, which is then passed to the AT (JAWS16 in this case), so that the removed text of that node is subsequently announced.

This is the opposite of the text event that is fired when a DOM node is added, which is how aria-live="polite" by itself works, so that the newly added text node is passed to the screen reader and announced.

This removal feedback doesn't work in IE11, because live regions using JAWS16 are mostly broken in IE+JAWS16, and the correct events may not be firing properly in IE in any case.

The following LinkedIn article explains a bit of news regarding this and how it may impact future support levels in IE in the future:
https://www.linkedin.com/grp/post/4512178-6009113313206616068

It doesn't appear that NVDA supports aria-relevant correctly in this case either at present, since nothing is announced when the DOM node is removed.


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Robert Fentress
Sent: Thursday, May 28, 2015 1:19 PM
To: WebAIM Discussion List
Subject: [WebAIM] Am I understanding aria-relevant="removals" correctly?

Hey, folks.

So, I'll be honest, I've been a bit hazy about the relationship between aria-relevant and aria-atomic, so I started going through the states and properties section of the ARIA spec (
http://www.w3.org/TR/wai-aria/states_and_properties) in a little more detail, while testing things out in Deque University's very useful, Live Region Playground ( https://dequeuniversity.com/library/aria/content-feedback/liveregion-playground),
and I think I'm starting to get a better handle on it. I'd like to run it by you, though, to see if I'm right.

Let's work from the Deque's HTML code as a reference, listed below:

<div id="fixture" role="status">
<div>
<div id="static">
<h3>Static Content</h3>
<div>The changing content will take place below.</div>
</div>
</div>
<div id="update"><div><span class="added">Added Content</span> #1</div></div> </div>

If, on $('#fixture'), I set aria-atomic="true" and aria-relevant="removals", then, when I remove the contents of $('#update'), everything that remains in $('#fixture') will be presented to the user. It will *not* read the removed content, as one might, at first, think. This is because aria-relevant determines what *triggers* content in the live region to be presented, while aria-atomic determines *how much* of the content in the live region to be presented.

As best I can tell, the value of aria-atomic has exactly the opposite effect of what you would expect in normal English. One would expect (I would, anyway) that saying you wanted something to be atomic meant that you only wanted a part of it, because an atom is a tiny piece of something.
However, setting aria-atomic to true has the opposite effect, meaning that it presents *everything*. The way I keep it straight in my head now is that "atomic", in this instance, means an indivisible whole.

So with the example I gave above, the expected behavior seems pretty clear. However, if I set aria-atomic="false" and aria-relevant="removals"
and then I remove the contents of $('#update'), the spec seems slightly less clear to me and I'm not entirely sure what would happen. In describing the aria-atomic property, the spec says, "2. If aria-atomic is explicitly set to false, assistive technologies will stop searching up the ancestor chain and present only the changed node to the user." This *probably* means that nothing is presented to the user, since the changed node, $('#update'), contains nothing now. Would this also be the case if I removed the node itself?

Testing this all out in JAWS and NVDA with Internet Explorer and Firefox suggests that none of these screen reader/browser combinations completely supports aria-relevant="removals" in the way I'd expect. This makes it hard to verify that I am interpreting the specification correctly. To those who've really gotten into the weeds on this, can you confirm that I've gotten this right or could you provide further clarification?

Thanks,
Rob

--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061