Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

aria-live and JAWS

I'm trying to get an aria-live region to work correctly with JAWS 11 and IE8.

Using the code below, I can get JAWS to announce the new value when the button is clicked, but the behaviour is not what I would expect.

JSFiddle of this example

<!DOCTYPE html>
<html>
<head></head>
<body>
    <button onclick="document.getElementById('statusbar').innerHTML = parseInt(document.getElementById('statusbar').innerHTML) + 1">Update</button>
    <div id="statusbar" aria-live="polite">0</div>
</body>
</html>

Using my JAWS11/IE8 configuration, on each click of the button I hear:

Click number  HTML Value (after click)  JAWS says
------------  ------------------------- ---------
1             1                         "Update button 0"
2             2                         "1"
3             3                         "2"

The problem, and my question is: how do I make JAWS announce current value of the aria-live region, rather than the previous value of the aria-live region?

I'd also be interested in how other screen readers will handle this functionality.

like image 947
Daniel Nitsche Avatar asked Aug 02 '11 07:08

Daniel Nitsche


People also ask

What is an aria live region?

The aria-live attribute makes it possible for an AT (such as a screen reader) to be notified when error messages are injected into a Live Region container. The content within the aria-live region is automatically read by the AT, without the AT having to focus on the place where the text is displayed.

What is the difference between aria live assertive and aria Live polite?

aria-live="polite" indicates that the screen reader should wait until the user is idle before presenting updates to the user. This is the most commonly used value, as interrupting the user with "assertive" might interrupt their flow.

What does aria atomic do?

In ARIA live regions, the global aria-atomic attribute indicates whether assistive technologies such as a screen reader will present all, or only parts of, the changed region based on the change notifications defined by the aria-relevant attribute.


2 Answers

Your code is correct. Apparently, the "1 behind" has been discovered. From the link, it looks as if using aria-atomic="true" may fix the problem. However, the example as given does work properly in IE9 and Firefox.

If you haven't stumbled across them already, check out the test-cases on codetalks and accessibleculture.org. There are a lot of subtle differences to be aware of. Just don't be surprised when the tests fail! Over the past year or so, I've come across a few (inadequate) tricks which may help you.

Method 1: role="alert"

The alert role is supposed to be equivalent to aria-live="assertive", but older versions of JAWS didn't handle it properly. Check out these examples from February 2011, which states that:

If you are looking to support JAWS 10 in IE7 or IE8 at all, it is likely best to double up on alerts with both role="alert" and aria-live="assertive". While this is somewhat redundant since, by definition, the alert role is to be processed as an assertive live region, doing so does allow JAWS 10 to automatically announce the updated alert's contents in those two browsers.

Both Firefox4+ and IE9 do not require this. But it would be something like this:

<div id="statusbar" role="alert" aria-live="assertive">
  Contents will be spoken when changed
</div>

Method 2: focus forcing hack

By dynamically creating a DOM element and forcing focus to it, you can "trick" most screen readers into reading the contents. It's hackish, but effective...and somewhat the point of the Create and Focus example. Simplified, you can do something like this:

<div id="statusbar" role="alert"></div>

$('#statusbar')
  .clear()
  .append('<div tabindex="-1">' + newString + '</div>')
  .children().first().focus()
;

Merely hiding/showing the contents instead actually works fairly well most of the time. However, VoiceOver's focus lingers on the element and does not speak its contents when shown again. Thus, removing it from the DOM seems to be the most foolproof method for now. I don't like it, but such is the state of things.

like image 78
Courtney Christensen Avatar answered Sep 21 '22 00:09

Courtney Christensen


If you are using JAWS, i think you need also to configure the default mode; because the screen reader have a "read only" mode. this problem can be solved via press:

(Insert + z) to turn on/off the read-only screen readers.

http://www.mozilla.org/access/qa/win-webcontent-jaws.html

like image 27
Ahmad AlMughrabi Avatar answered Sep 19 '22 00:09

Ahmad AlMughrabi