WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Robert Fentress
Date: May 29, 2015 7:25AM

Thanks for the reply, Bryan, and for what you've created at whatsock.

In the first URL you provided (http://whatsock.com/training/#hd25), it
states, *'When aria-atomic is undefined or set to "false", only the newest
text should be announced when added to a Live Region container, regardless
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.
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).

Sticking with Deque's example HTML given in my previously, with
*aria-atomic="false"* and *aria-relevant="removals"*, when removing <div>s
containing text from the live region, *$('#fixture')*, this is what happens
with different common screen reader combinations in *Windows 8.1*:

- *NVDA 2015.1 with Internet Explorer 11: *Nothing is presented to the
user
- *NVDA 2015.1 with Firefox 38: *Nothing is presented to the user
- *JAWS 15 with Firefox 38: *Nothing is presented to the user
- *JAWS 15 with Internet Explorer 11: *Nothing is presented to the user
(though, strangely, added content *is *presented)


Using the second example you provided (
http://whatsock.com/training/demos/lr/aria-live-polite-removals.html) with
JAWS 15 + Firefox 38, nothing was presented at all. Perhaps this is a
difference between JAWS 15 and 16 or Windows 7 and 8. I haven't had time
to check yet. Or perhaps we are somehow misunderstanding each other?

Best,
Rob

On Thu, May 28, 2015 at 6:48 PM, Bryan Garaventa <
<EMAIL REMOVED> > wrote:

> 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
> > > at http://webaim.org/discussion/archives
> >
> > > > >



--
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