FW: [WebAIM] Am I understanding aria-relevant="removals" correctly?

Hi,
I wished to pass this along as a bug in the understanding and implementation of live regions within the spec and by implementers.

Firstly, it's not clear what should happen when a live region includes a role such as Log or Status, and also includes custom attributes such as aria-live, aria-atomic, and aria-relevant.

Logically, it would make sense for the custom attributes to modify the default functionality of the role, thus allowing for customization.

I don't think this is stated anywhere though.

Secondly, the following is stated at
http://www.w3.org/TR/wai-aria-1.1/#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."

The way this is worded, implies that achieving uniformity for the support of live regions is optional, which goes a long way to explaining why they still work so badly across various ATs.

Also, going back to my first question about whether the declaration of a role such as Log or Status can be overridden by custom attributes, the logic of which is undermined by the second statement that support for aria-relevant is optional.

They cannot be both, allowed as a mechanism for overriding live region roles, and allowed to be optionally supported by ATs. These are mutually exclusive.




-----Original Message-----
From: WebAIM-Forum [mailto:webaim-forum-bounces@list.webaim.org] On Behalf Of Bryan Garaventa
Sent: Friday, May 29, 2015 11:10 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] Am I understanding aria-relevant="removals" correctly?

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.


-----Original Message-----
From: WebAIM-Forum [mailto:webaim-forum-bounces@list.webaim.org] On Behalf Of Robert Fentress
Sent: Friday, May 29, 2015 6:25 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Am I understanding aria-relevant="removals" correctly?

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 < bryan.garaventa@whatsock.com> 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:webaim-forum-bounces@list.webaim.org] 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-p

> layground
> ),
> 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
> _______________________________________________
> To manage your subscription, visit http://list.webaim.org/ List 
> archives at http://webaim.org/discussion/archives

> Address list messages to webaim-forum@list.webaim.org
>
> _______________________________________________
> To manage your subscription, visit http://list.webaim.org/ List 
> archives at http://webaim.org/discussion/archives

> Address list messages to webaim-forum@list.webaim.org
>



--
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
_______________________________________________
To manage your subscription, visit http://list.webaim.org/ List archives at http://webaim.org/discussion/archives

Address list messages to webaim-forum@list.webaim.org

_______________________________________________
To manage your subscription, visit http://list.webaim.org/ List archives at http://webaim.org/discussion/archives

Address list messages to webaim-forum@list.webaim.org

Received on Friday, 29 May 2015 22:40:55 UTC