Monday, July 17th, 2006

Is AJAX Accessibility a major issue?

Category: Accessibility, Ajax

<>p> With yet another perspective on the wealth of Ajax usability discussion flying around, Hari Gottipati shares his thoughts on his blog on XML.com. Specifically, he’s responding to the eWeek article posted a while back.

inally people realized the disadvantages of Ajax and they are trying to overcome them. The main disadvantage of Ajax is a Web page is not required to reload to change, many screen readers or other assistive technologies used by sight-impaired or otherwise disabled users may not be aware of the dynamic changes. Particularly this is the major hurdle for federal sector because all federal government web sites/applications has to meet the Section 508 of the Rehabilitation Act.

Hari makes the comment that, in the eWeek article, they talk about using the Bindows framework to build compiant web applications, but that they don’t mention how (or what kind of result it will give). He also asks whether it is even possible to create a 100% compiant web application using Ajax in any framework.

If we fail to overcome this issue, we will see the Ajax implementations just to say “ooh look at me I’m web 2.0 too!” or to target the users who enabled JavaScript and using the particular versions of the browsers(by ignoring the blind people). Since majority of users has the latest browsers with Ajax/JavaScript support(90% of browsers have JavaScript enabled), do you think Accessibility is not going to be an issue?

Related Content:

Posted by Chris Cornutt at 7:54 am
13 Comments

+++--
3.6 rating from 39 votes

13 Comments »

Comments feed TrackBack URI

For my personal opinion the accessibility issue in ajax is the prioritary issue because in many nation, for example in Italy, we can’t develop a governement intranet/extranet/portal with AJAX approach if isn’t realy accessible to screen readers.

Comment by Luca Mascaro — July 17, 2006

I think it’s an important issues for some and not for others. For example, if you are designing an app/site that you want to sell to the government, then it’s critical. But if you’re in the private sector developing web apps for whatever audience you want, it might be a non-factor. With 90% of browsers javascript enable, you could easily say to hell with remaining 10%. Maybe a bit cruel, but in the end you can never please everyone anyway. Personally, I’ve built some web apps without taking accessibility into account at all because it just wasn’t worth it. So it really depends.

Comment by Thomas M — July 17, 2006

Section 508 compliance is mandatory for all government work. In practice, this means you can’t use any innovative technologies, because they generally lack accessibility support, and screen-reader companies see third-party developers as a major profit center. So in practice it’s easiest to just pick one of the few older frameworks with excellent 508 support, delivering a less capable product for more money. And the US government is officially OK with this tradeoff.

But if you’re producing a comercial product in an emerging market, accessibility is a hopeless morass of headaches. This doesn’t have to be true–free screen-readers and some co-operation from the browser vendors would make an enormous difference. But if the choice is a commercially-compelling app with accessibility problems, or going out of business, I know how most startups will decide.

If we want to solve AJAX accessibility problems, we need to do it at the Firefox level. I’m even happy to write a check. But I’m not going to try to handle it at the application level before the tools are there, or limit myself to old-style web apps when 99% of users would benefit tremendously from AJAX.

Comment by Eric — July 17, 2006

@Eric, how would a Firefox-level accessibility solution work for people using assistive technology? Don’t they mostly use screen-reader applications as their actual browser? That suggests that Firefox wouldn’t even be in the picture for them, no?

Comment by Mike Ritchie — July 17, 2006

If we want to solve AJAX accessibility problems, we need to do it at the Firefox level. I’m even happy to write a check.

It is mostly there today. Firefox 1.5 provided a working implementation of accessibility roles (http://developer.mozilla.org/en/docs/Accessible_DHTML).

You still need a mature Ajax application framework to manage component-level roles, keyboard navigation, accelerator keys, etc. And the burden is still on the application designer to provide alternate UI for _inherently_ inaccessible interactions like drag & drop. But this is no longer a hopeless problem. If you want to write a check, I know at least one company that can solve it for your application. :)

Comment by Jeff Dill — July 17, 2006

Jeff, is there a way to routinely test the Firefox accessibility support without spending $795 on Window-Eyes? Or is that just the cost of doing business?

Comment by Eric — July 18, 2006

An Ajax app should be developed to “gracefully degrade” to something like a text only version. Use a feature rich interface as default, with a different set of templates for text only, screen readers , wap, and so on.

Other major issue would be Ajax for mobile devices, the market is growing.

Comment by Dea — July 18, 2006

Eric said:
“Jeff, is there a way to routinely test the Firefox accessibility support without spending $795 on Window-Eyes?”

You don’t have to buy a screen reader in order to use it for testing. most screen readers vendors (including gwmicro) have a demo version available, which usually run for about 40 minutes (if you reboot the 40 mins starts again)

Comment by steve faulkner — July 19, 2006

Actually you don’t.. most accessibility testers use MS Object Inspector (inspect32.exe) to do 90% of the work.

Comment by Alexei — July 19, 2006

Alexai said:
“Actually you don’t.. most accessibility testers use MS Object Inspector (inspect32.exe) to do 90% of the work.”

Using the microsft MSAA sdk tools is of limited use in understanding whether screen reading software will announce AJAX generated content as the mechanisms used rely upon a combination of methods including but not limited to the MSAA API.

I would also question the veracity of your statement as regards the number of “accessibility testers” who use such tools.

Comment by steve faulkner — July 19, 2006

Accessible Ajax Forms

There was a post on Ajaxian a few weeks ago on Ajax and accessibility. This got me to thinking about form validation using ajax. It’s nice to be able to provide validation without a page refresh, but what if the user has javascript disabled? I …

Trackback by epiphantastic — August 1, 2006

I’m new to ajax and try to execute a small eg which was downloaded from website but it is not working properly. please Could anyone help me for this query.

Comment by shobha — September 18, 2006

You may or may not already know, but Section 508 is under revision to address concerns specific to Rich Internet Applications. In mid-2006, a panel deemed Section 508 outdated with respect to modern web techniques and has enlisted the w3c to its advisory board.

http://www.w3.org/2006/09/aria-pressrelease.html

As a developer of Rich webapps, Section 508 compliance is a concern since its most recent update occurred in 2001. It’s great to hear that the problems between 508 and Ajax have been recognized by the government and that work is being done to accommodate. Also, I am awaiting feedback from access-board.gov on whether there will be any provisioning for transitional compliance for webapps built after the announcement but before the new rules take effect. We’ll see.

The w3c WAI-ARIA draft indicates what mechanisms will be standardized to allow webapps to communicate semantic details to API driven screen readers, but there I’ve been unable to find any public information about the specifics of the new 508 rules.

Joe Hanink,
Developer,
Bear River, Inc.

Comment by Joe Hanink — February 16, 2007

Leave a comment

You must be logged in to post a comment.