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.get开发者_如何学PythonElementById('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.
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.
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
加载中,请稍侯......
精彩评论