The Ajax express train rumbles on, threatening to crush anything in its path. Recent discussion has turned to those critical elements of good web development, usability and accessibility. Accessibility is a major issue with Ajax, mainly because anything that relies on JavaScript to function is inaccessible pretty much by default. There are two solutions: either provide a fall-back system where the site remains useful without its Ajax enhancements, or provide a whole separate interface that works without scripting.
Google recently adopted the second option for GMail. From their What’s New page:
Basic HTML view lets you access your Gmail messages from almost any computer running almost any web browser, even old ones (not just IE5.5+, Mozilla, and Safari). Especially great for traveling, since you never know what kind of browser that internet cafe in Siberia is going to have.
Standard accessibility good practice is to avoid text-only versions of pages like the plague, but in my opinion the distinction between web content and a web application make simplified versions of Ajax style applications an acceptable compromise.
More on AJAX and accessibility can be found over on Standards-Schmandards.com.
The usability side of Ajax is interesting as well, mainly because Ajax tricks can severely alter the expected behaviour of the browser. Thomas Baekdal put out a set of suggested XMLHttpRequest Usability Guidelines a few weeks ago, and recently followed it up with an article putting his ideas to practise in the context of a neat business card designer example.
Finally, for those who really can’t get enough Ajax Mike Papageorge has assembled a comprehensive list of working examples.
Related posts:
- Are You Violating the Eolas Ajax Patent? It's true: Eolas has an Ajax patent and is filing...
- Support for IE6: It’s all About Accessibility With the release of IE8, there's excitement in the air...
- Practical Accessibility Tips with WCAG 2.0 Techniques for Web Content Accessibility Guidelines 2.0 is a very...
- 5 Ways to Get Usability Testing on the Cheap Usability testing can increase sales and user satisfaction, and decrease...
- Making Your Web Colors Visible For All – Five Color Accessibility Tools Jennifer takes a look at four web sites and an...
Thanks for the follow on info to AJAX. I read about it the other week but haven’t found the time to delve much further. I personally work towards these standards as much as I can nowadays but haven’t had the chance to implement much of the possibilities to existing projects.
As you say, “the AJAX train rumbles on”!
March 10th, 2005 at 10:23 am
The “text-only version” debate is interesting, because Ajax stuff takes it to a whole new level; you’ve, instead of “snazzy graphical version of site” with “text version for old browsers”, now potentially got “snazzy interactive JavaScripty version of site” with “non-instant-feedback resubmit-the-pages version for old browsers”.
An example like Thomas Baekdal’s business card designer, while neat, is very easy to overlay Ajax stuff onto; other apps are more complex. In extreme situations, it’s entirely possible to entirely rewrite the DOM of a page into a *completely different page* from your Ajax-enabling JavaScript, which would preserve the “works without Ajax” principle but is essentially a complex way of implementing separate Ajax and non-Ajax sites. I still believe that any non-Ajax site could be Ajax-enhanced without splitting off two sites (enabled and non-enabled), but the page may need to be designed with that in mind, in the same way that CSS can overlay HTML and make the page design great but often needs the HTML to be written, at least a little, with the fact that it will be CSSed into shape in the mind of the developer.
This is why separation of behaviour into separate JavaScript files, just like separate CSS files, is a really good idea, and it’s good that ppk is pushing the idea hard.
March 10th, 2005 at 11:39 am
The link to the “comprehensive list of examples” is the same as “putting his ideas…”.
I’d love to see the examples.
March 10th, 2005 at 12:16 pm
I’ve gone down the “Ajax” path in the last week or so. The last startup I was at used this technique quite successfully. I wanted to see how hard it would be and what sort of things I’d see. In the end, I’ve opted to go back to server-side based page generation to achieve exactly what you document – accessibility – as well as things like bookmarking pages and proper search engine indexing. I plan on still rolling out a more interesting interface in the future, but for now I’m going to rely on straight HTML to get my users the content they need, as they are my most important customer. Some of my future sites that are targeting a user base more like GMail may utilize Ajax heavily and may not offer backward compatibility based on the target audience.
March 10th, 2005 at 3:58 pm
What’s Ajax? You mean javascript, remote scripting, RPC?
March 10th, 2005 at 9:33 pm
Please stop calling it Ajax and stroking Jesse James Garret’s ego. He didn’t invent the methodology so he’s got no right to name it. It’s been around for years and has always been called either Javascript Remote Scripting (JSRS), XmlHttpRequest (XHR) or Remote Procedure Call (RPC), depending on how it’s implemented.
March 11th, 2005 at 9:09 am
The correct link for the example list is this one:
http://www.fiftyfoureleven.com/resources/programming/xmlhttprequest/examples
;-)
March 12th, 2005 at 10:55 am
To James Higginbotham. You are right. This technique should not replace your regular page generation for Accesibility and search engine issues. This is mostly a tool for web applications. Which should anyway hava a fallback to regular server based scripts.
One interesting thing is that bandwidth used by xmlHttpRequest can be trimmed to the minimum. With my Instant Edit example (www.ideasfreelance.com/lab/instant_edit) I have some interesting stats.
The field has been updated more that 2,500 times, with an average of 25 Bytes per request. That is about 60k for 2,500 updates.
With regular full-page reload each time the data is edited (the page is about 12k) the same 2,500 editions would have taken almost 30Mb.
Does it pays or not? ;-)
March 12th, 2005 at 11:15 am
CADEX (http://tantek.com/log/2005/02.html#d25t1709) seems to be a more appropriate name that could be agreed on.
And more importantly, check out the work being done by Alex Russell and crew (http://dojotoolkit.org/intro_to_dojo_io.html). Amazing stuff. It helps answer some basic usability issues such as bookmarking and the back and forward buttons.
March 17th, 2005 at 5:26 am
Anyone have experience with using JackBe to build AJAX apps?
March 21st, 2005 at 2:58 pm
Hi all;
I have created a remote scripting framework based on JSP/Servlet as the middle tier, which it is made up as follows (3-tier) :
Client
Browser
(DHTML, JavaScript,
CSS, XMLHttpRequest)
Middle Tier
Servlet, JSP Forms/Reports, JSP Taglibs
(Remote Scripting Request Handler classes,
Data handling JavaBean (Non-EJB))
Database Tier
Any RDBMs (MySQL, Oracle, Informix, MS SQL etc.)
For easy coding , a tool is supplied to help u generate all the necessary data handling JavaBean (non EJB) classes, request handling classes, the javascript file for handling remote scripting.. This will help out at least 80% of your work for building data-centric web-based application… so you can just focus on complex business logic (It’s like Informix Genero .. but it is a remote scripting architecture )
I’m currently working on the documentation .. for more info .. please visit http://www.smartborneo.com
The architecture diagram …
http://smartborneo.com/images/webprocess.gif
The db mapping tool
http://rhae.dunco.com.my/tools/LoginFormServlet
(If anyone interested to try out with a test account, please email me at ketyung@smartborneo.com)
Documentation & guide (Incomplete .. )
http://rhae.dunco.com.my/examples/downloads/Rapid Interactiv Web.pdf
April 3rd, 2005 at 1:18 pm
I built this site in 15 hours using Ajax as the base.
http://rss.omnio.org
I am not a programmer. It is rather easy to start changing the web and how to interact with it….
Dana
October 7th, 2005 at 10:36 am
[...] On a slightly more technical note, many of the social software and services utilize a technology called Ajax; while it is very useful for most people, it should be noted that when implemented incorrectly, Ajax poses an access problem for those learners who are blind or have reduced vision and use screen readers. [...]
December 16th, 2005 at 12:59 pm
Drug here ?
April 27th, 2006 at 10:37 pm
[...] Excellent article on how well screen readers deal with rich interfaces (using ajax) — with research to back it up. [...]
June 2nd, 2006 at 4:05 pm
Please look at http://www.homepage4.com
June 10th, 2006 at 5:39 pm
[...] Usability and accessibility with Ajax [...]
June 20th, 2006 at 10:11 am
public health officials say it could also test a mechanism for tracking victims
[url]http://www.shoes-warehouse.net[/url]of natural disasters or terror attacks through medical tents and shelters.
June 22nd, 2006 at 9:46 pm
I have a big problem with AJAX. If user turn off their javascript on thier browser then my site will not run correctly, how can i check for javascript anable or not ???
July 5th, 2006 at 11:22 am
[...] Usability and accessibility with Ajax The Ajax express train rumbles on, threatening to crush anything in its path. Recent discussion has turned to those critical elements of good web development, usability and accessibility. Accessibility is a major issue with Ajax, mainly because anything that relies on JavaScript to function is inaccessible pretty much by default. There are two solutions: either provide a fall-back system where the site remains useful without its Ajax enhancements, or provide a whole separate interface that works without scripting. [...]
July 10th, 2006 at 3:33 am
[...] Offer an accessible version alongside your dynamic version. Google offer their users the option of a HTML version of its Ajax-powered Gmail application. Two versions of a site guarantee an accessible version of your content but goes against the ideals of the standards based approach. [...]
July 14th, 2006 at 10:06 pm
[...] Usability and accessibility with Ajax The Ajax express train rumbles on, threatening to crush anything in its path. Recent discussion has turned to those critical elements of good web development, usability and accessibility. Accessibility is a major issue with Ajax, mainly because anything that relies on JavaScript to function is inaccessible pretty much by default. There are two solutions: either provide a fall-back system where the site remains useful without its Ajax enhancements, or provide a whole separate interface that works without scripting. [...]
July 15th, 2006 at 12:10 am