The key to writing accessible AJAX-based web applications is to not let AJAX replace server-side technology, but instead live side-by-side with it. So, say you want to replace something inside a DIV tag on your page. The most immediate solution that comes to mind is to do an AJAX request to the server, get the bits of content you want, and then push it into the DIV with a DOM method. Right.

But what happens if JavaScript is disabled or not supported? Nothing. That's why you need to write server-side logic for doing the exact same action. So the link or button you are clicking to insert content X into element Y on the page should do the exact same thing server-side as client-side (with AJAX).

This is not at all as hard as it sounds. I've made a framework in .NET that does this automatically for you; all you have to do is identify the element you want content pushed into, the URI of the content and then what link that should execute this action. What happens then is that a regular A element with an HREF attribute gets added to the page and an ONCLICK event is added to that element. If JavaScript is enabled and XMLHTTPRequest of some sort is supported, the content is fetched and added to the page client-side, but if not, the ONCLICK event handler will not cancel bubbling and the HREF will be taking the click instead. And when it is, the user are taken to a URI that tells the server that element X should be filled with content Y. And the best part is that the URI isn't has horrific as it may sound, since the values in the URI are just references to the values stored in the ASP.NET control that the server has full control of.

This will work in any other server-side framework, but it does of course need to be built.

Oh, and remember that it's not only blind people that suffers from JavaScripted web pages. Google and all of its spider bot friends does too.

re: Asbjørn Ulsberg's approach

That takes care of user agents that are not using JavaScript, but what about the combination of a screenreader with a JavaScript-enabled companion browser? Content added via XMLHTTPRequest after the page has loaded is missed by the screenreader.

"The question is, is it possible to be 100% accessible(Check the accessibility issues) with any framework?"

Ajax != framework. We have frameworks built around it, but Ajax itself can't (accurately) get called a framework.

"I think Ajax may not be adopted by every one without addressing the accessibility issues, because no body wants to develop Ajax/Non-Ajax versions of the application."

Just like with any language or pattern, it can get as accessible as you make it. That doesn't mean you have to have two versions of your site for those who can't use Ajax-driven UIs, it just means that (as with all web technologies) you need to design your application with certain things in mind.

Just like PHP, lots and lots of people dove head-first into hitting the server without refreshing the page without actually taking the implications of that into consideration.

And in response to David K: you can have an accessible Ajax interface that works with screenreaders (see http://ajaxian.com/archives/ajax-and-screen-readers and http://ajaxian.com/by/topic/accessibility/ in general for more info). Unfortunately, articles on using Ajax and screenreaders probably don't sell advertising as well as more flashy topics...

In response to Shawn comment "Ajax != framework. We have frameworks built around it, but Ajax itself can't (accurately) get called a framework."
I totally agree. Ajax is not a framework. Vendors are working to overcome the Accessibility issue and obviously they provide the solution in their framework. Thats what MB Technologies did in their Bidnows framework. Hence I mentioned "The question is, is it possible to be 100% accessible(Check the accessibility issues) with any framework?"

In response to Asbjørn Ulsberg idea :
This idea is good as you can update the element with href instead of ONCLICK event handler incase if there is no JavaScript/XMLHttpRequest support.

"And when it is, the user are taken to a URI that tells the server that element X should be filled with content Y."

How can you get the access of element X on server side to fill it with content Y? You mentioned that you made a .NET framework that does this. Could you explain in detail how to acheive this?

Hari,

What I did in ASP.NET was to instrument both the JavaScript event handler and the server-side event handler with server-side code. So basically, you have a DynamicPlaceHolder control with an ID and a DynamicHyperLink control with a reference to that ID.

When the DynamicHyperLink gets rendered, it has a HREF value that takes the user to a new page which instructs the DynamicHyperLink control to fetch the content it has assigned to it and insert this into the DynamicPlaceHolder.

It also has an ONCLICK attribute with an event handler that gets the required parameters to do the same stuff with Ajax. It's not difficult at all. What I did too, but which isn't necessary, is to have the same server component serve the content to both server- and client-side, but on client-side I transform the returned XHTML with XSLT to several lines of JavaScript which actually builds up a DOM representing the XHTML fragment.

The XSLT itself is not more than 100 lines of code, and for every element it generates a 'document.createElement("element-name")', for every text node it generates a 'document.createTextNode("text-content")' and so on. It is fully recursive and assigns the whole DOM created to a variable passed in as a parameter to the XSLT document. It was very fun writing. :-)

Thanks Asbjørn Ulsberg for the explanation. But I have one more question. Correct me if I am wrong, you are using a JavaScript event handler, that means it works only if JavaScript is enabled. I thought you are talking about the solution where JavaScript is disabled. What I understand is, this solution works with out Ajax/XMLHttpRequest.

Could you explain how you implmeneted the JavaScript event handler? Is it sits on client side or server side? You mentioned "When the DynamicHyperLink gets rendered", how you render this when the page is already loaded? I still oculdn't understand how you force some portion of the page to get loaded with the new data without javascript. There has to be some mechanism which forces to get rendered. Am I missing anything?

Hari,

I'm wrapping up a Firefox AJAX book and finished a couple of chapters for another AJAX book recently, so I've been in this space fairly heavily of late. One of the big reasons that I've come to endorse XForms (especially if you have an XBL-type engine handy) is the fact that it can in fact do much if not most of the things that AJAX can do in a framework oriented approach that on the other hand satisfies the Section 508 accessibility guidelines. I know that XForms has taken a while to hit critical adoption, I suspect that this resides more in the fact that it needed enough people who were used to thinking in an XML MVC mode than anything, but I can definitely see as the need for some consistent "AJAX Framework" grows that XForms may increasingly be seen as the obvious next step.

Kurt,
Thank you for pointing to XForms. Frankly, I didn't know that XForms can do most of the things that Ajax can do. I never got a chance to look into it, but I will give a shot at it.

Hari,

If you know ASP.NET, you also know that when you build custom web controls, you can give them all of the properties you like and expose these so they can be set either programmatically or with markup (HTML) in the ASP.NET page. When you add a DynamicHyperLink to your page, you need to assign the following properties with values: PlaceHolderID (string), ContentURI (string) and Replace (bool).

When a DynamicHyperLink renders as the page renders, it creates an HTML A element with a HREF pointing to a URI that will invoke a method inside DynamicHyperLink that loads ContentURI inside PlaceHolderID. The Replace property tells if the content inside the PlaceHolder should be replaced or appended to.

An ONCLICK attribute also gets added to the A element. This attribute calls a JavaScript method with the parameter of the client-side ID of the PlaceHolder (a DIV element) to insert the content into, plus the URI of the content to insert. If JavaScript is disabled, the HREF attribute takes presedence and everything is done server-side. If JavaScript is enabled, the JavaScript method is executed, and if everything goes smoothly, 'false' is returned from the method (this causes bubbling from the ONCLICK attribute to the HREF attribute to cancel). If something goes wrong (e.g. XMLHTTPRequest is not supported), 'true' is returned from the method and bubbling will not be canceled, so the HREF will be executed instead and everything will happen server-side. Quite fail-safe.

A rendered DynamicHyperLink typically looks something like this:

<a href="page.aspx?load=dl:1" onclick="return loadContent('hyperlink1', '/content.xml');">Load content!</a>

The question actually is are you going to stifle a real jump in technology for 95% of the people for the minority 5%? The answer is no.

So what will happen is developers will find a way to make it work for those with problems. That might mean pushing them to a smaller alternate site, dealing with it in other various ways, or simply dealing with the fact that some of your users can't access the app.

Not everything has to be 508. Not everything has to be accessible to everyone, particularly for business sites that target a certain groups. That's just reality in play.

I agree with Tom. Section 508 compliance is mandatory for the government, but I'm sure that there are plenty of successful sites/web apps out there that are not compliant and have not intention of being so. Basecamp, for example, just won't work properly if you shut off javascript. Sometimes your audience dictates your technology, but sometimes you can allow yourself to dictate the technology for your audience. It all depends.

I agree with Tom :

"That might mean pushing them to a smaller alternate site, dealing with it in other various ways, or simply dealing with the fact that some of your users can't access the app."

I think showing nice message is more than enough and if you can provide non-JavaScript version thats much better. Most of the sites inlcuding GMail, Google Maps shows that you can't access this site if the java script is turnded off and provides non-JavaScript versions. Surprisingly Google calendar, Google video doesn't show any message and looks horrible if JavaScript is turned off. Most of Windows live sites shows the message, but no non-JavaScript versions. Yahoo is the best site which provides non-JavaScript versions every where in their portal.

Well honestly any developer who builds a site that HAS to use AJAX technologies to operate is not doing their job.

AJAX is meant to provide a rich user interface layer ON TOP of a completely functional website that doesn't require javascript or XMLHttpRequest. It was never meant to be the sole way of accessing a site.

Unfortunately the hype has led some irresponsible developers into developing sites that are AJAX-functional only. This doesn't mean that AJAX is bad in any way, it just means that some developers are taking shortcuts. AJAX doesn't make a developer's job easier, it increases their workload as a tradeoff for simplifying the experience for end users with AJAX-capable browsers.

I hate articles like this because they bash a very useful technology when the technology itself isn't flawed at all (unlike Flash). In fact its an incredibly useful, semantic, standards-friendly way of creating a rich user interface on the web, which I might add no other method has managed to do.

But how about this: An AJAX, web-based screen reader. Which actually adds to the freedon of the reading impaired user...

I always have terrible trouble with comment-related plugins that require me to put some line in the comment loop; I can never seem to find the right spot. Can anyone tell me where I should put the php line in my comments loop? I haven not modified anything much, and I would be very grateful. Thanks!

As outlined above, AJAX allows feature-rich, dynamic web applications which use server-side processing without requiring the traditional "submit data — retrieve web page" methodology. Using XMLHttpRequest, data is transmitted behind the scenes of your web application and JavaScript is used to manipulate the application interface and display dynamic information. This allows more streamlined applications that require less processing and data transmission because entire web pages do not need to be generated for each change that occurs. Instead, one web application reflects all of the changes that occur. JavaScript can also be used to allow higher levels of interactivity than allowed through HTML itself
Landauer