E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 6 (In chronological order)

From: Robert Fentress
Date: Thu, May 28 2015 2:18PM
Subject: Am I understanding aria-relevant="removals" correctly?
No previous message | Next message →

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

From: Bryan Garaventa
Date: Thu, May 28 2015 4:48PM
Subject: Re: Am I understanding aria-relevant="removals" correctly?
← Previous message | Next message →

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.

From: _mallory
Date: Fri, May 29 2015 12:46AM
Subject: Re: Am I understanding aria-relevant="removals" correctly?
← Previous message | Next message →

On Thu, May 28, 2015 at 04:18:32PM -0400, Robert Fentress wrote:
> 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.

Actually, the word atom means "not-cuttable". Tomos, to slice, with the
negating "a" in front of it.
The word originally meant "the smallest unbreakable single unit", so
aria-atomic would mean "everything in this aria-atomic box is a single
unbreakable unit." Yeah, atoms were so named before we discovered
sub-atomic particles, meaning atoms are now poorly named. But hey,
starfish aren't fish either :P

Perhaps the spec writers expected authors to be familiar with database
theory (ACID) or similar.

_mallory

From: Robert Fentress
Date: Fri, May 29 2015 7:25AM
Subject: Re: Am I understanding aria-relevant="removals" correctly?
← Previous message | Next message →

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

From: Robert Fentress
Date: Fri, May 29 2015 7:28AM
Subject: Re: Am I understanding aria-relevant="removals" correctly?
← Previous message | Next message →

Yes, _mallory, I eventually understood what they were getting at. It just
didn't strike me as intuitive initially. Like you said, I'm sure it made
sense in the context they were coming from.

On Fri, May 29, 2015 at 2:46 AM, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
>
>
> Actually, the word atom means "not-cuttable". Tomos, to slice, with the
> negating "a" in front of it.
> The word originally meant "the smallest unbreakable single unit", so
> aria-atomic would mean "everything in this aria-atomic box is a single
> unbreakable unit." Yeah, atoms were so named before we discovered
> sub-atomic particles, meaning atoms are now poorly named. But hey,
> starfish aren't fish either :P
>
> _mallory
> > > > >



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

From: Bryan Garaventa
Date: Fri, May 29 2015 12:09PM
Subject: Re: Am I understanding aria-relevant="removals" correctly?
← Previous message | No next message

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.