Live Regions: ARIA Attributes Implementation

[kahun...@gmail.com]

I am wondering what the expected behavior of live regions is.

Is it to find additions/subtractions (changes of display property
also) of descendent ELEMENTS or text-nodes too?

For example, in NVDA/FF3,

if I change the display of

<p aria-channel="main" aria-relevant="additions" aria-atomic="true"
aria-live="polite">foo</p>

directly through the style property or with a className change NVDA
will announce when the element has been displayed or hidden.

However, not in JAWS 10. In order to get JAWS 10 to announce the
change I have to wrap the element like so and change the display of
the descendant p element:
<div aria-channel="main" aria-relevant="additions" aria-atomic="true"
aria-live="polite">
<p>foo</p>
</div>

I have a case where it is preferable to not have to do the former (put
the aria attributes on the element directly), but this does not work
for JAWS10. What is expected? Is JAWS10 not implementing this
correctly, or is NVDA going above and beyond?

[Aaron]

I meant to say that I have a case where I don't want to have to wrap
the element. I want to just put the aria attributes directly on the
element whose display property is variable.

[David Bolter]

Hi,

I suggest having a look at the codetalks aria-live examples; this one
will probably serve you well:
http://codetalks.org/source/live/atomic_true.html

Note: aria-channel was removed from the spec.

Hope this helps,

David

On May 20, 4:48 pm, "kahunaco...@gmail.com" <kahunaco...@gmail.com>
wrote:

[David Bolter]

aria-live is really about marking regions as live. I'm not sure how
you would do it on a leaf.

[Aaron]

I realize what live regions is trying to solve. But noticed that it
could conceivably address a common problem. A lot of pages have
toggler controls which toggle the display of an element after clicking
on some "master" element (the relationship between the master and
slave elements are usually next siblings). The problem with this type
of control is that when users using screen readers click on the master
node (which should be an anchor link) they have no idea that the next
node has changed display.

Wrapping the node that has its display changed with a div with ARIA
live region attributes sort of solves the problem in FF3/JAWS and FF3/
NVDA. Or at least it tells the user when the node is made visible,
since subtractions don't seem to be supported yet. My questions are
these:
1) Am I off-base here? Are live regions supposed to announce when
elements change display from none to block or vice versa--or just
additions/subtractions to the DOM?

2) What is the spec? NVDA allows me to not even wrap the slave node. I
can just put ARIA live region attributes directly on the slave node
and when the node changes display from none to block, it announces the
content change. JAWS requires me to wrap the slave node with a div. Is
JAWS not following the spec, or is NVDA being too permissive?

[Aaron Leventhal]

Just to throw something in here, you may want to use aria-expanded on
the master node, and have aria-controls point to the id of the slave.

<div tabindex="0" role="button" aria-expanded"="false" aria-
controls="panel1">Show panel</div>
<div id="panel1">...</div>

The aria-controls probably won't get you much in today's screen
readers (yet). But. the aria-expanded will. When you focus something
with aria-expanded="false" or aria-expanded="true" the screen reader
will inform the user that there is something expandable here. and
whether or not it is currently expanded.

Ultimately people argued that aria-expanded was useful for more than
just buttons, tree items, etc. but also for regions of text. You could
potentially have a header for a region that's focusable. It's really a
summary of the region. If you toggle it the region expands to show the
contents.

It'd be worth exploring the options, and also checking with the ARIA
style guide on W3C to see if they have any examples. If not I suggest
they should add that.

The other thing is that, when a user action such as a key press or
mouse click is what toggles visibility of a region in the page,
Firefox automatically tells the screen reader event-from-user-
input=true. Thus, a screen reader can potentially decide based on this
automatic info whether or not to read what is expanded. If you want to
force it one way or another as far as whether it's read, use aria-live.

I'm not sure what you were saying about not being allowed to wrap
nodes, etc. However, I suggest you will get much farther faster if you
post a link to an example or two and specifically state. Just use
pastehtml.com. It is free and allows both HTML and JavaScript. Just
say what the expected and actual behavior are.

- Aaron

[Aaron]

"...you may want to use aria-expanded on

the master node, and have aria-controls point to the id of the slave.
"

-I will try this

"The other thing is that, when a user action such as a key press or
mouse click is what toggles visibility of a region in the page,
Firefox automatically tells the screen reader event-from-user-
input=true. Thus, a screen reader can potentially decide based on
this
automatic info whether or not to read what is expanded. If you want
to
force it one way or another as far as whether it's read, use aria-
live."

- Not sure I understand what you mean here. I guess FF fires an event
when a user clicks an element that changes display of another element,
and screen readers can hook into that event? But FF3 doesn't read
anything (with JAWS or NVDA) without some kind of ARIA.

"I'm not sure what you were saying about not being allowed to wrap
nodes, etc."

- What I am saying is that if the element that is changing display
(after a click or enter keypress on its previous sibling element) is
wrapped in a div with live region attributes FF3/JAWS FF3/NVDA read
the content when the display changes from none to block. If I put the
ARIA live regions attributes directly on the element that is changing
display, w/o wrapping it in a div JAWS does not say the content when
the display changes from none to block.

[Aaron]

Oh here is the example:
http://www.pascarello.com/tempFiles/jig/doc/ncbitoggler-ex.php#sibling-minimal

[Aaron]

Aaron, I tried doing the role="button" aria-expanded as you mentioned.
I did not try the controls attribute. I could not get FF3/JAWS10, or
NVDA Jaws10 to tell me about the state of the control.

Does anyone know if it is possible or the best practice for having a
screen reader tell the user what state a single toggling pair are in?
Thanks.

[David Bolter]

In theory you should be able to put the live attributes on the link,
and use aria-owns="your_sometimes_shown_node_id". I'm not sure if we
have tested that case though...

[Aaron Leventhal]

No, I don't think any ATs do that, and until now I hadn't heard it
suggested.

- Aaron

[Aaron]

So, any suggestions of what works best for this situation? So far
doing this:

<a href="#">Click me to show the next para</a>
<div aria-relevant="additions" aria-atomic="true"
aria-live="polite">
<p>sometimes I am shown</p>
</div>

seems to work best in real life, at least in FF3/JAWS10, FF3/NVDA.

At the very least it announces when the node is made visible.

Or am I missing something with suggestion to do aria-expanded? At
least without doing aria-controls and just aria-expanded, my
combination of screen reader and browser does not work.

[Aaron Leventhal]

You don't need to put aria-relevant="additions" because the default
value of aria-relevant is already "additions text". The only time you
generally really need to use aria-relevant is if removals are also
important.

You don't really need aria-atomic in this case either, since you are
showing or hiding the entire thing at once anyway.

I'm not sure why aria-expanded didn't work for you. It would be good
to file a bug on NVDA & JAWS if toggling aria-expanded on an object
that has focus doesn't read out the state change.

Feel free to submit test cases. It will help improve things for
everyone. Like I said you can put them on pastehtml.com or anywhere
you want.

- Aaron

[Aaron]

Do I submit test cases here, or on codetalks?

[Aaron Leventhal]

I suggest that you just submit them here for now, and if you get
really into it, the codetalks folks can fold you in more.

- Aaron

[Aaron]

Great I will write a test case up. Thanks for all your help.

[Aaron]

Here is a test case as per Aaron's suggestion. When I listen to it in
FF3 or IE7 and JAWS10, it does not inform me of any changes in the
slave's display.
http://pastehtml.com/view/090528BLg2jRs2.html

I wonder if the master and slave must have a parent child relationship
instead of siblings...

[Aaron]

So it sounds like Mozilla is working on this for the next release?

On May 28, 11:01 am, Aaron <kahunaco...@gmail.com> wrote:
> Here is a test case as per Aaron's suggestion. When I listen to it in
> FF3 or IE7 and JAWS10, it does not inform me of any changes in the

> slave's display.http://pastehtml.com/view/090528BLg2jRs2.html

[Aaron Leventhal]

aria-expanded change reporting and aria-live should already work in
Firefox 3.5 betas.

- Aaron

[Aaron]

I tested in FF3.5. aria-expanded/collapsed works only with NVDA, not
with JAWS10. Is this to be expected?

Also, when I expand and have live regions set on the slave element, no
screen reader reads the slave content if there is no wrapper for the
content.

For example:

<h2>
<a href="#" role="button" aria-expanded="true" aria-
controls="slave">Master</a>
</h2>
<p id="slave" aria-hidden="true" aria-live="polite" aria-
relevant="additions">Slave</p>

[Schnabel, Stefan]

I know that aria-expanded/collapsed is maybe a UAP (Universally Applicable Property, is it?), but
what is the use case for an "expanded" button? Or should toggeling of Regions work generally this way? Then I would better take a link instead or a button with aria-pressed (toggle button).

Anyway, it is the Region (the slave) that is toggled not the master (the button), so I think

<p id="slave" aria-expanded="true/false"

Has to be updated accordingly.

- Stefan

[Aaron Leventhal]

Expanded is supposed to work on a button, but it could be that JAWS
assumes that the expanded state is not useful on a button. I agree,
that pressed might work better.

Someone should send a note to Freedom Scientific.

- Aaron

[Aaron]

Typo on my part. When the master has aria-expanded="true", by script
updates the slave accordingly has aria-hidden="false"

[Aaron]

I will send a note to freedom scientific. Do you have a contact there?

The problem--obviously--with this aria business is its implementation.
It is good in theory, but the real use cases for it given browser/
screen reader implementation are very limited.

Why bother? Well, I guess you can say that if we start using it
vendors will follow, but the real world is a busy place, and the
investment in understanding it/reporting features that don't work
takes time away from other tasks. How do I justify to the people that
are paying me the time involved in making code work with ARIA when its
implementation just isn't there yet? I would like to use it, but I am
just not seeing the benefits. Correct me please if I am misguided.

[Aaron Leventhal]

Hi Aaron,

I understand, but everything is moving very quickly. You can use Dojo,
which already supports ARIA well, or you can wait another year if you
aren't willing to deal with the "bleeding edge".

IMO it's somewhat true what you're saying. I personally feel that it's
worth doing at least the 80% that works right off the bat with NVDA
and JAWS, and saving some of the more brittle things for later once
you get feedback from users and things mature a bit.

Does anyone have a feedback channel with Freedom Scientific that would
be willing to forward Aarons' feedback & bug reports?

- Aaron

[Aaron]

Aaron, I do appreciate your replies.

When you say Dojo supports ARIA well, I am not sure what you mean? Do
you mean Dijit (their widgets)? Otherwise it's not that hard to update
aria attributes via my scripts. We use jQuery UI, and we customize it
a bit. When we build our own jQuery UI widgets, we add ARIA, but as
I've said I haven't found much benefit to it in my testing.

You say that "...it's

> worth doing at least the 80% that works right off the bat with NVDA
> and JAWS"

What ARIA features are *not* brittle generally? I did test a while ago
landmark roles with FF3 and JAWS/NVDA and those are very useful, but
beyond that I haven't gotten much to work.I'd like to know what I can
reliably use and have it be worth the effort.

Also, I have been struggling for a long time to do a toggler (as I've
shown above) in an accessible way. What do you all think is the best
way to do this?
Use display none on the slave and ARIA, hide the slave visually using
absolute positioning and then showing it using static positioning?

The problem comes down to letting the user know that something (the
slave) on the page changed due to a click event.

Thanks -Aaron

[Aaron Leventhal]

Yes, I mean Dijit. IBM & Mozilla put a lot of effort into making the
Dijit widgets accessible via ARIA.

From my perspective, the most solid parts of ARIA are anything that
emulates an existing desktop widget. I can only speak for Firefox,
because IE8 has come a long way, but in my testing I found a number of
issues. However, as long as you are in Firefox with basic widgets that
you'd see on a desktop it can always be made to work with any screen
reader. In general any screen reader will work with these basic
widgets, as they mapped well to the standard a11y APIs on each platform.

If you move onto widgets that have different semantics than your
standard desktop controls, or use ARIA landmarks, ARIA drag and drop
and ARIA live regions, then you start needing to require a very recent
screen reader, and not everything will work in all cases. For these
cases, on Windows, NVDA works the best, followed by JAWS. On Linux,
Orca works well.

FWIW, I wish others would do a little support on this list as well,
that's what this list is for in part. After all, ARIA is new and
people will run into issues. There are people on this list who have
done a lot of successful work with ARIA already.

If you want to make something speak as it's shown, the best way is to
either use CSS display (to be official you should change aria-hidden
when it's invisible, but that doesn't affect many of the screen
readers). Or, actually remove and insert the node. Either way is fine,
but if you want it to be spoken as it's shown you should but aria-
live="polite" on the container. As for speaking the button states, I
suggest using aria-pressed. That fits along best with standard toggle
buttons on OS button controls, so more screen readers will already be
accustomed to it.

Have you seen the examples on codetalks.org? There are lots and lots
of working examples, so if you need to prove to yourself that stuff
works, go there. You can look at the markup:
http://wiki.codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases

Here is a page on how to file a bug on an ARIA implementation,
including JAWS:
http://wiki.codetalks.org/wiki/index.php/How_to_file_a_bug_on_an_ARIA_implementation

Here is a useful page full of resources:
http://wiki.codetalks.org/wiki/index.php/ARIA_Resources

- Aaron

[James Teh]

On 7/07/2009 5:28 PM, Aaron Leventhal wrote:
> If you ...use ARIA landmarks, ARIA drag and drop

> and ARIA live regions, then you start needing to require a very recent
> screen reader, and not everything will work in all cases. For these
> cases, on Windows, NVDA works the best

It should be noted that NVDA does not currently support landmarks or
drag and drop. However, this is one of the items currently being funded
by Yahoo! and should be available in development builds within a couple
of months. Our live region support is also unfortunately somewhat
incomplete at best. I can't give an ETA on this yet, but rest assured
that it is on our todo list.

Jamie

--
James Teh
Email/MSN Messenger/Jabber: ja...@jantrid.net
Web site: http://www.jantrid.net/

[Rich Schwerdtfeger]

To highlight one of your points, one of the strenghths of aria is its
support for drag and drop, that is far beyond most operating systems.
Consequently, UI component libraries, like Dojo, have not implemented
support yet. The fact that NVDA does not yet implement should not be a
cause for concern.

Rich Schwerdtfeger
Sent from my IPhone handheld