gsnedders

AJAX has spread far and wide, moving into territory it was never meant for, harming accessibility, even though this can often be avoided with little more than a fallback page for those user agents that don't support it.

The back button has meaning

Using AJAX to replace large portions of content on a page is very bad practice, as it breaks various basic browser features, such as the back/forward buttons and bookmarking. While there are Javascript hacks to get the back button working in some browsers, they are still no more than hacks; furthermore, these hacks don't get the forward button or bookmarking working at all in any browser.

Multi-page forms

Many sites have forms that span multiple pages, and use AJAX to send off data, and get appropriate data for the next page. There are two problems with this practice:

• If you want to return to the previous page and want to edit what you entered, you cannot do so without redoing all the previous pages.
• If the user agent doesn't support AJAX, and there is no fallback page, then the form become unusable.

The first problem has a simple solution: have a back button; whereas the second requires a fallback page, preferably that looks identical to the AJAX form, just with each page being sent off to the server separately.

A lot of the above is also true for forms with just a single page: if you rely on AJAX to submit a form, it quite simply won't work in browsers which don't support it.

So, where can you use AJAX?

To add extra functionality that improves the user experience on the site, and where nothing is lost by it not being there, or, to submit small changes to data, with (fully functional) fallback for browsers without support for AJAX, where the fallback looks identical.

Some examples:

• Updating content in a page, such as on a shoutbox
• A delete button, to remove a list item or other small piece of content, with a fallback for browsers without support for AJAX (such as the same page, with a query string on the URL, such as delete=20)

Wow, is there that little to it?

Yeah. Most of it just boils down to using AJAX only where appropriate, and not using it everywhere you can. While this may seem insanely simple, there are many major sites that abuse these simple accessibility rules. It should take nothing more than a few minutes just to think, is AJAX really sensible here? Is anything lost to those who can't use it, or do I need a provide fallback for those who can't?

Here's a list of things that you have no problem doing with standard text, yet are often not doable when some method of using non-standard fonts in a web page is in place.

1. Select the header.
2. Start selecting the header (from the left of the first letter), and continue selecting down.
3. Start selecting the text, and continue selecting up to just above the top of the header.
4. Start selecting the header, from the middle, and continue selecting down.
5. Start selecting the text, and continue selecting up to the middle of the header.

After each stage, copy and paste it before checking the content is what you started with on the web page.

sIFR

sIFR unquestionably has it's problems, for one it's dependent on Flash and Javascript; however, it is well tested, and has many advantages over other methods. That said, I have my doubts as to how well it'll do. So, onto the testing (which is being done on the sIFR home page).

1. Pass.
2. Fail. While we get the header, we don't get any of the body.
3. Pass.
4. Fail. Like 2, we don't get any of the body.
5. Fail. We get the whole header, not just up to where the cursor is.

2 out of 5.

Phark Method

Mike Rundle of Phark offered a solution that uses text-indent to hide the text, by moving it waaayyyy off to the left of the page, moving it off the canvas, and therefore invisible.

1. Fail. The text is far to far off to the left to be selected.
2. Fail. The text is far to far off to the left to be selected.
3. Pass.
4. Fail. The text is far to far off to the left to be selected.
5. Fail. The text is far to far off to the left to be selected.

1 out of 5.

Conclusion

What are, in my opinion, the two most used image replacement methods, did not do all that well in what is, for me at least, an in important usability test.

All I can say is watch this space, for my suggestion for an accessible and usable (or at least, in browsers that support certain parts of CSS3 ;)) image replacement method.