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

+1 to what Bryan said.  I think we are being too soft on AT vendors by
making "suggestions."  That said, It makes sense that enumerated attribute
values should override any values implied by a particular role.

Mark

On Fri, May 29, 2015 at 6:40 PM, Bryan Garaventa <
bryan.garaventa@ssbbartgroup.com> wrote:

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