Accessability: GWT, ARIA and JAWS screen-reader

81 views
Skip to first unread message

Dvae

unread,
Mar 15, 2010, 2:58:27 PM3/15/10
to Google Web Toolkit
We have developed a small GWT 1.5.2 application to implement an
intranet inside our portal. It consists of two panes, content and
navigation/search; implemented as a HorizonatalSplitPanel containing a
ScrollPanel for the content and a DecoratedTabPanel which contains a
Tree for the navigation. So far, so good.

For mouse-wielding sighted users, it all works as expected. Clicking
TreeItems in the navigation causes the content ScrollPanel to get new
content.

For keyboard-wielding screen-reader users, however, it's not so good.
One can tab around to get focus to the navigation. One can arrow-key
around the navigation tree to update the content pane (sighted users
can see the content pane updating). But the updates to the content
pane are inaudible in the screen-reader JAWS.

After reading the documentation at http://code.google.com/webtoolkit/doc/latest/DevGuideA11y.html
, I added the following lines to the constructor for our content
ScrollPanel:
com.google.gwt.user.client.Element e = this.getElement();
Accessibility.setRole(e, "document");
Accessibility.setState(e,"aria-live", "rude");
Accessibility.setState(e,"aria-atomic", "true");
Accessibility.setState(e,"relevant", "additions");

I've also tried with role="region", with other rudeness levels, and
without the aria-atomic and relevant attributes. I've verified that
the html delivered to the browser does contain the correct attributes
on the div (div class="contentBrowserPanel" relevant="additions" aria-
atomic="true" aria-live="rude" role="document" style="overflow: auto;
position: relative;").

According to http://wiki.codetalks.org/wiki/index.php/How_to_use_ARIA_Live_Regions_for_dynamic_content
, this should do exactly what I want.

But still no love from the JAWS. We are using Windows XP, Firefox 3,
IE 7, and JAWS 11. I thought the problem might be that JAWS is
confused with the iframes GWT used to implement the
HorizontalSplitPanel. But my visual-impaired user who originally
reported the problem reports that none of JAWS iframe-reading commands
caused it to properly read the content pane.

Has anyone run into similar issues? I saw one post where the author
just decided to make a non-AJAX version available from a hidden link.
We may have to go that route eventually, but I was hoping there is a
simple solution.

Reply all
Reply to author
Forward
0 new messages