Ajax: The good, the bad and the confused!

The Twig — Fri, 27 Jun 2008 13:30:00 GMT

When I was just a sapling, Ajax was a mere household cleanser but now it is more widely known amongst us techies as an acronym for Asynchronous Javascript and XML.

Ajax is the stuff that allows web applications to become much more interactive. Rather than the web server sending down whole pages in response to some user input only small parts of the page are refreshed. When using a classic desktop application such as Excel you would get pretty frustrated if your whole screen flickered whilst it was refreshed after entering a value or formula. Ajax starts to bridge the gap between desktop applications and the “click-refresh” web we are used to by making things quicker and more interactive.

One of the biggest challenges with Ajax is maintaining accessibility as many assistive technologies (screen readers and the like) don't implement Javascript. The key to the implementation of Ajax is the concept of graceful degradation. Where accessibility is paramount, Ajax should only be used to enhance the user experience and shouldn’t hinder task completion.

An example of good use of Ajax can be found on the ever-popular Youtube site. The search box at the top of the page will find suggestions dynamically as you type which will represent actual content on the site. If you don't have Javascript enabled or it isn't implemented then you can still enter search terms and browse the site unhindered. This is a nice touch and actually ticks some accessibility guidelines boxes along the way.

Recently I had the unenviable task of renewing my car insurance. I decided to use a popular comparison site in the hope of getting the best deal. When I got to the part of the form that asked me for my occupation and type of business there was a nifty bit of Ajax that would show a list of matching entries as a typed. All well and good! In writing this blog posting I thought I would try turning off Javascript to see what happened. To my surprise I couldn’t take my quote any further as I was given a very unfriendly error message saying “please select an occupation” despite having typed something into the box. The little pop-up thing that helps you select an occupation didn’t work either so effectively at this point I’m totally stuck.

Above is a classic example where Ajax was implemented to make the process easier for the user and more predictable for the organisation concerned with giving me a car insurance quote BUT crucially they forgot to make it degrade gracefully. In this case the end result is disastrous for the organisation because they end up losing my business due to my inability to complete the quote form.

So graceful degradation is the way forward for interactive web applications? Well, yes, but unfortunately at a cost. There is an intrinsic overhead in using Ajax and making it degrade as everything needs to be coded in effect twice (not strictly true but a reasonable rule of thumb). The great danger is that organisations commission web applications and either disregard accessibility (Hotmail being a prime example as it doesn’t work without Javascript) or they underestimate the work required to maintain accessibility whilst making the application as easy to use as possible by providing Ajax enhancements.

One final point with Ajax is the expectation of the user. Ajax isn’t new but its use is only now becoming more apparent. One issue is that users don’t always realise that something has changed on the web page as they expect having clicked a button that they will get a page refresh. Until such times as a high level of interactivity is expected on the web visual cues will be necessary to draw user’s attention to changes. I’ve not yet seen any usability studies on sites that use Ajax but I’m guessing that in some cases people just won’t get it.

All this Ajax talk has got me inspired…..I really must clean that bathroom!

Would you like ice with your page layout sir?

The Twig — Mon, 21 Apr 2008 13:59:00 GMT

Designing an accessible website isn't about compromise but is more about embedding the accessibility requirements into your design process. One of the most important decisions you take is what layout technique you will use.

These days there are a lot to choose from including fixed-width (sometimes call ice), liquid, elastic, etc. - each with their own set of challenges and compromises. In the early days of the web designers didn't need to worry too much as nearly everyone had a screen resolution of 640x480 and widescreen was reserved for your visit to the local cinema.

Now we have PDAs, widescreen and more resolution combinations than you would care to know about. To help you understand the challenges and compromises we'll take a look at the main layout techniques below.

Mixing it up

Fixed width layouts are very common as typically they provide a great deal of predictability of how a design will be represented on a variety of screen resolutions but they don't always work that well on high resolution screens. The net result of this is sometimes a web page that is lost in the middle of the page. Once someone has decided to increase the text size line lengths can also become a problem and the resulting text wrapping can make reading uncomfortable.

Liquid layouts use percentage sizes rather than fixed ones and they are designed to scale to the browser window size. These layouts make the most efficient use of space but multi-column layouts become problematic at lower resolutions and on higher resolutions paragraphs of text can end up as single lines which can look a bit strange.

Elastic designs take the best bits from fixed width and liquid layouts by defining maximum and minimum widths to overcome the problems described above. This is a good compromise and if done properly results in a design that looks great on both smaller resolutions and high ones.

A good example of good elastic design is the website of the General Teaching Council for Scotland (http://www.gtcs.org.uk/) which has a maximum width of approximately 1150 pixels and a minimum width of 800 pixels.

WCAG

The final question to be answered is how all this affects the accessibility of your site. Under WCAG 1.0 there was always a raging debate as to whether a non-liquid layout (that includes both fixed width and elastic) were compliant or not. Rather than attempt to answer that it is worth applying this question against WCAG 2.0 which is currently in working draft status with the W3C.

Strange as it may sound WCAG 2.0 makes no reference to the size and behaviour of structural elements of page but does talk about text sizing under checkpoints 1.4.4 (Resize text) and 1.4.8 (Visual Presentation). The resize text checkpoint falls under Level AA and visual presentation under Level AAA.

Most fixed width layouts would fail checkpoint 1.4.4 due to the requirement that text should be capable of being resized by up to 200% without impairing the functionality of the page especially when multiple columns are used.

Liquid layout easily passes this checkpoint especially when columns are relatively sized based on the text size. Elastic layouts need to be carefully defined in terms of maximum and minimum widths to ensure that they comply with this checkpoint.

The visual presentation checkpoint has some overlap with the resize text checkpoint in terms of the 200% text resize requirement but also introduces some other requirements in terms of layout. There is a somewhat arbitrary requirement that "width is no more than 80 characters" which could cause problems with both liquid and elastic layouts - one way of achieving this is ensuring that blocks of text wrap at a certain width.

Geek-Free Zone

Ajax: The good, the bad and the confused!

Would you like ice with your page layout sir?

Mixing it up

WCAG