Web Directions North » Blog Archive » Web Apps

Web Apps - Ajax Kung Fu Meets Accessibility Feng Shui

Note: check the podcast and download the presentations to get all the details that were likely missed in this entry.

Jeremy Keith

• jeremy = john the baptist, derek = jesus christ
• “AJAX” is just a word, but that’s ok - it’s a good buzzword (it saves time to describe something that would otherwise take longer to say)
• problem is AJAX gets associated with another buzzword that decreases its importance (”2.0″)
• term comes from JJ Garret/Adaptive Path
• AJAX gives the illusion of speed
• “Ajax is a way of communicating with the server without refreshing the whole page” - Jeremy Keith
• the important bit is “communicating with the server”
• Ajax isn’t: DHTML, DOM Scripting - you can do cool things with them, but they don’t communicate with the server
• AJAX: Asynchronous JavaScript And XML - more a “backcronym” because he came up with the word first
• isn’t really a good acronym, because the point is asynchronous communication with the server
• other things that could, based on the definition, be described as Ajax: Flash, frames, iframe (because they all communicate with the server without refreshing the page)
• XMLHttpRequest is what most people mean when they say Ajax
• it’s one thing to define Ajax, another to define accessibility
• one way: universality - access for any user agent (anyone can access your content)
• another: progressive enhancement (begin with the content, add structure, then presentation, and finally behavior)
• content, structure ((X)HTML), presentation (CSS), behavior (Ajax)
• problem is that most web apps these days are built Ajax-first (users without JavaScript don’t get the content)
• example: Amazon’s rating system (your selection is stored without refreshing the page, and a great example of Ajax - creates illusion of speed)
• another good example: Flickr (editing the title of a photograph - enter title in a form, form processes data without refreshing the page; allows you to complete a task faster, without waiting)
• yet another example: Google Maps: dragging maps
• and yet again: meebo (chat client in the browser, all Ajax)
• Ajax implementations are on a sliding scale: from simple documents to complex applications
• in Jeremy’s opinion, Ajax is better used for things at the document end of the scale - makes it easier to use progressively; complex applications make it more difficult to provide access to the content because of the amount of reliance on Ajax
• if you’re planning to make an app that isn’t accessible, look to Flash and similar technologies instead of Ajax
• in communication between the browser and the server (thin client, classic model)
• with a fat client, the front end (browser) does a lot of the processing - not a good idea, browser support issues, unstable environment; if you have the option between processing on the browser or on the server, choose the server
• traditional web is like a self-service restaurant: you get your food, sit down, get up again for more food, etc. etc.
• Ajax is like getting a waiter for your web site: you raise your hand, the waiter comes over, takes your order, gets your food and brings it to you - if you’re going to add a waiter to your web site, use a “dumb waiter”
• enter Hijax - applying progressive enhancement to Ajax
• Hijax model: build a traditional web site, where the entire application and site works normally: page refreshes, etc.
• to the user, the browser seems to be doing all the work (”deceptively fat client”), even though it is all occurring on the server
• if you want to build an Ajax application, start without it, and add the Ajax after the fact
• example: Jeremy shows an example of a music shopping cart, allowing shopping cart additions and ratings without any page refresh
• rather than sending a full page, hijack the individual parts of the page you need to update - the whole page will continue to work without Ajax, without the illusion of speed, but will still function
• rule/paradox? plan for Ajax from the start, implement Ajax at the end
• classic example of communicating with the server with Ajax: forms - log on, comment, add to cart,
• example of a contact form: validation appears to happen in the browser (ala JavaScript), but is actually happening on the server. Logic remains on the server, JavaScript is just a dumb waiter, shuffling the data back and forth, but not touching it otherwise
• another example of when to use Ajax: links - rate this, table sorting (temptation is to do it in JavaScript, but you don’t have to - you can do it with DOM Scripting, but letting the server handle it is much better)
• don’t worry about extra server load - if your complaint is that too many users are using your system, that’s a good complaint: you can increase server load, improve queries, etc. (vs. fixing a user’s browser, or a user that doesn’t have JavaScript, etc.)
• be careful about using interactions such as: drag ‘n’ drop (if you’re going to borrow such conventions from the desktop, you can’t do it half-assed - be prepared to do a lot of work to mimic the interaction)
• another to be careful about: mouse over (e.g. Snap previews - mousing over a link shouldn’t initiate an action)
• be careful about going beyond traditional web interactions with Ajax
• “WTF?” Ajax is scaring people - you have to tell the user what’s going on, so they know something’s happening (borrow conventions from Flash developers, they’ve been dealing with the same issues for years)
• also need to tell users what just happened - e.g. yellow fade technique ala 37signals
• must think beyond the browser: traditionally, the browser tells the user something is happening or has happened (browser logo spinning, progress bar, etc.) - with Ajax, you have to notify and communicate with the user
• don’t make assumptions about users: test, see how users interact with your UI choices, and improve it as needed
• universality is easy - access for any user is harder, and is accessibility
• Audience question: mousing over can be useful (e.g. book details when mousing over a book title) - Jeremy’s answer: depends on context, and such interaction can be useful, but he still prefers clicking on a link to initiate interaction
• Audience question: it’s easy to say that processing on the server is better, but in the real world, latency and other issues may make for a sub-optimal user experience. Jeremy’s answer: that’s the point of communicating with the user, telling them what’s happening - it’s a design issue, but there’s still a benefit to the user in that they can still interact with other parts of the page while one area is busy communicating with the server
• Audience question: regarding JavaScript libraries (general question). Jeremy’s answer: they can be used for good or for evil, and can be used for very powerful things - should be used responsibly, and not without understanding. If you use a library to save time, but you still understand how it works and what it does, that’s a good approach

Derek Featherstone

• start with a brief history of Ajax and Scripting
• early .Net: postbacks, bad for accessibility (posting things to the server without updating the page display)
• in early days of WCAG, JavaScript was either on, or off
• problems with screenreaders and Dreamweaver-created JavaScript prompted Derek to dig into the incompatibilities between older screenreaders and scripting
• at the time of WCAG 1.0, the concept of pages working with JavaScript on or off made sense - Derek prefers a different approach now: when JavaScript is on, make sure content is still accessible
• What about Hijax? The approach is great, but is it enough? How does it fit into making accessible web applications and sites for today?
• example: Chapters (Canadian equivalent of Amazon) - did a massive redesign 2 years ago and it was horrible. No semantic structure, tag soup, everything that could be bad, was. Have now redesigned, using CSS, (X)HTML, tagging - shows example of their “what’s this” link, that works with JavaScript, loads a separate page without JavaScript, but link fails in a screenreader (what’s the best way to address this kind of situation? maybe Hijax isn’t the best solution for everybody)
• Are you a web site or an application?
• Shows example of a job postings site, login form is hidden within the clutter of the page. Remember the purpose of each page.
• use model similar to Jeremy’s - separate content from presentation from behavior
• examples: edgeio, basecamp, air canada (check the podcast, examples/discussion too complex to present here)
• book reference: Designing the Obvious (Robert Hoekman, Jr.) - good for coworkers who don’t “get it”
• example form: username, email address, first name, last name - “username” is the label, plus emphasized text within for more information (same thing with <strong> for error messages). Screen readers will associate the message with the label/field. If a screenreader user leaves one field, goes to another, and returns to the previous field, they will receive updated content (e.g. Ajax), but involves counter-intuitive user action
• Audience question: for a web developer, what screenreader should be used for testing? Derek’s answer: none of them. Take the money you would spend and use it on user testing, it’s much more valuable.
• example of page updating in JAWS 7 - innerHTML vs. Ajax (listen to podcast to hear the example)
• example: username field, checking for availability - what would a screenreader user expect the button to do? Load a page - in this instance, since the page isn’t reloading, take the user to the part of the page that displays the error or success message
• more examples that are difficult to describe…
• the future is emulation - example: xhtml2:role= “alert” - things like this will allow easier communication with screenreaders
• Audience question: is there a better language than (X)HTML to offer visually impaired users a more accurate description of the web? e.g. most of us don’t surf the web using “view source”. Derek’s answer: there are things being worked on, and maybe something other than HTML would be a better solution, but also 95% of the web is crap, and screen readers still have to deal with that.

Posted by Dan Rubin on 14/02/07 at 1:58 am

Images:

The images are downsized due to limited space here. The original dimensions may differ.
Click on the image to open it on a new tab.