Do they have any more source codes available at all for AJax?

The burden is either on the software that is to be compatible with assistive technology or on the assistive technology itself. If developers are expected to produce content that is cross-browser compatible and universally accessible, the browser and screen reader interfaces could be more accommodating to us. I’m sure that if it were easy and inexpensive for programmers to deal with cross browser issues and assistive technology, developers would be happy to bring their content to the widest range of users. But we all know this isn’t so. In the case of browser compatibility, it is general standards compliance and improved standards that together make it feasible to generate cross-browser apps. The same is true for accessibility. We need updated standards and updated technology. This is not a fight against accessibility, it’s a defense against outmoded specifications. Section 508 is in the process of being updated with the help of the w3c, and rightly so. If the standards are improved along with compatible screen readers, perhaps the task of developing accessible, rich applications will become more more mainstream.

The other question pertains to how we characterize this problem. When we ask that a rich app be accessible, this is not really correct. What we really mean is that the content and services behind the rich app are accessible. If the rich features fronting data and services impute higher usability for unimpaired users, then we’re really talking about a presentation level interface issue. If we are clear and consistent and clear about this, then we shouldn’t be trying to make a rich app accessible but rather provide accessibility to the content and services through assistive interfaces.

For instance, the services of a federal building need to be accessible to wheelchair users, but the stairs do not. The stairs are a usability interface to the building to access services. However, a ramp is typically provided so that a wheelchair bound person can use assistive technology (i.e. the wheelchair) to access the services via an interface (the ramp) that is compatible with said assistive technology. The stairs don’t and can’t be made compatible. That doesn’t really make sense.

In some cases, the lines between services and the mode of delivery become blurred. If the two are coupled, then equivalent facilitation may not be possible. For instance, an interactive online pool game or a simple streaming video are both content services that deliver an experience that cannot be separate from its delivery vehicle (i.e. mode of presentation). Therefore, a blind person simply cannot watch a movie or enjoy an interactive online pool game. In fact, this doesn’t make sense. Should a flower shop stop selling roses because some people have no sense of smell? There really is no alternative interface that provides equivalent facilitation. Is it possible to create a device that samples the air and computes mappings for some input device that can be delivered directly to the brain… possibly… but that’s not an appropriate concern of the florist. However, should such a device be created, should the florist also sell device-compatible sprays… perhaps.

Likewise, rich applications have purpose that is tailored to a regular user (not an elite user). If my sense of smell is unimpaired, am I elite? Assistive technology in the form of screen readers is meant for certain types of interfaces and content, especially those meant to be read, such as text documents. Some usability experiences associated with rich apps are simply not convertible to a screen reader interface, and if they can’t, they shouldn’t be expected to. That’s simply illogical.

My conclusions:

1. improve standards and technology
2. improve awareness for all concerned
3. don’t expect all apps to be universally available
4. continue to work toward greater accessiblity of content and services where it makes sense
5. take pains to be very clear about the problems, and the discussion from problem to solution
6. continue to sell lots of nice smelling flowers

I’m sorry, but I can’t let your “70 million” comment go unchallenged. I believe most would agree that when speaking about Ajax (or Web 2.0) and accessibility, we are almost always speaking of it’s use by the blind or visually impaired.

Using some information from the AFB (http://www.afb.org/Section.asp?SectionID=42&DocumentID=1374) I came up with these numbers for Americans.

Blind or visually impaired: 10,000,000
Legally Blind: 13% of total
Over 65: 55% of total
Computer Users: 15%

Generally, the over 65 crowd either don’t or won’t use the Internet, though there use will grow over time as some of the younger generations get older, but we’re not there yet. If my understanding of the “visually impaired” qualification is correct, then I believe a good portion of them can still see well enough to use a computer, maybe with some assistance (larger screens, software that zooms in on portions of the screen, etc…) and maybe not. So we’re really talking about the “legally blind” as well as a component of people in the “visually impaired” category that must use screen readers to access the web.

So if we say 25% percent of the total blind/visually impaired population are visually impaired enough to need a screen reader, plus the 13% legally blind, we’re talking about 3.8 million. Except that at least 55% of them are over 65, but some of them do use the Internet so I’ll go with 50%. That reduces the total number to 1.7 million. Pretty close to the 1.5 million computer users AFB lists. By no means am I saying this is accurate but I imagine it is a pretty good estimate.

Now I am totally for making the web as accessible as possible for as many people as possible no matter their disability. I just don’t think it helps for anyone to say that 70 million Americans (23% of the total population) can’t use Ajax (web 2.0) applications when that is absolutely not true.

Sorry if I sound a little grumpy about this. I just had a conversation with a co-worker about why we can’t deploy any Ajax or Web 2.0 applications for our users. Something about it being a requirement that those who are disabled MUST have the same web experience as those who are not, and providing alternatives MIGHT not be good enough. So yes, in this case it might be said that a small group of the population is preventing the larger community from benefitting from some of the new “cool” features we would like to provide.

The Bindows framework now leads the market by enabling the fastest time to market for Ajax and Web 2.0 applications that work with leading screen readers, such as JAWS, without requiring any download or installation (zero-footprint).

We spent over a year on this development project and worked closely with The Paciello Group (TPG), international experts in the field of accessible interface design. We’re glad to see that you are highlighting this issue. It’s of major importance to our customers that need a zero-footprint solution with accessibility support for the government and international markets.

Please contact me if you have any questions at ran@bindows.net

From: Freedom Scientific Technical Support [support@freedomscientific.com]
Sent: Friday, April 28, 2006 7:39 AM
To: Kevin Hakman
Subject: Re: AJAX?

Friday, April 28, 2006

Dear Mr. Hakman:

Thank you for contacting Freedom Scientific Technical Support. The JAWS screen reader is scheduled to support the AJAX style of web site design in our up coming release of JAWS 7.10.

If you have any additional questions regarding this or any other issue, please don’t hesitate to contact us.

If replying to this message, Be sure to include all previous correspondence pertaining to this matter so that we might better assist you.

Sincerely,

Dennis G. Godin
Technical Support Specialist
Freedom Scientific Blind/Low Vision Group

http://www.freedomscientific.com
Phone support: 727 803 8600

Our Mission:
To develop, manufacture and market innovative technology-based products and services that those with vision impairments and learning disabilities use to change their world.

At 4/28/2006 08:42 AM, you wrote:

—–Original Message—–
Sent: Thursday, April 27, 2006 8:45 PM
To: Support
Subject: AJAX?, From: khakman@tibco.com
Technical Support – Software

Name is = Kevin Hakman
E-mail address is = khakman@tibco.com

Product =
Serial Number =
Address =

User subject description is = AJAX?

Comment or suggestion = What is the current support for AJAX type
websites and functionality when using JAWS?

* * * End of document * * *

Sincerely,

Dennis G. Godin
Technical Support Specialist
Freedom Scientific

http://www.freedomscientific.com
Phone Support: 727 803 8600

Our Mission:
To develop, manufacture and market innovative technology-based products and services that those with vision impairments and learning disabilities use to change their world.

Is it possible to make all pages ajax enabled and still fully accessible? certainly

Is it possible to do that without duplicating all of your rendering code and/or writing custom functionality to support each instance? certainly

Are there any large scale platforms to support this? not that I know of (but I don’t claim to know much)

A few things that screen reader manufacturers (and standards groups) could do that would be of great benefit to accessibility and coder support for it (sorry if this repeats things previously mentioned):

1) have a browser level flag that marks it as ajax/runtime update enabled. That way they could get the advantage of dynamically generated content (document.write) but scripts could easily check whether to make ajax calls for updates or refresh the page.

2) Add a type of label attribute for tags that is not used by normal browsers and a notification function that can then alert the user to change. (<div id=”section3″ acclabel=”Section 3″></div> ….. on ajax update, script calls document.readNotify(‘section3′)…. the reader then calls out “Section 3 has been updated, would you like to hear the changes?”).

With both things, scripts could quickly and easily be written to support all screen readers with a simple if{} at the start.