MikePadgett.com

Microsoft’s Office Sharepoint Server 2007 clears up some problems with cosmetic improvements, but delivers enough new ones out-of-the-box to remain beyond the reach of assistive technology users. Significant development will be necessary to ensure a basic level of accessibility.
Article continues after the jump…

What AJAX isn’t, in this context

Over the last couple of years, we’ve seen a significant leap forward in computing technologies and on one side of the coin, for the first time the Internet looks capable of delivering on the promise it showed a decade ago.

The flipside is that, during this time, the detritus of the computing has also increased exponentially, with over 95% of emails classified as junk [1] and ever more vocal reports of shady behaviour on the part of software vendors [2,3].

Enter AJAX

Riding the crest of this digital wave, the web technology “warp drive” that brought us Basecamp, del.icio.us and GoogleMaps - defined and described ad nauseam as “Web 2.0″[4] - represents both sides of the coin.

The positives are well-documented, the negatives less so. I decided to zoom in on one particular aspect: the conflict between AJAX [5] and Accessibility. This is not an especially new area of concern, but recently I wanted to check what progress there had been.

AJAX vs. Accessibility: why is there a conflict?

The key front-end advantage of the AJAX programming technique is that data can be served to the client without a page refresh. Small amounts of data are requested and managed by using a powerful scripting language. This language is JavaScript, and the AJAX technique finally shows how powerful it really is.

But therein lies the problem. Assistive technologies such as text-only browsers and screenreader software step over JavaScript altogether. As Joe Clark rightly points out [6], the WCAG 1.0 checkpoints include that:

“if you use applets and scripts: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.” [7]

So how do we use a web application like Google Maps if our assistive technology steps over or mauls the very JavaScript that brings us the functionality needed to navigate the interface and serve maps dynamically? And just what would an alternative accessible page for a map of your hometown contain? Could it be something like David Hawgood’s map of Kent [8]?

Here’s another example: if we choose to validate a form with AJAX, so it’s possible to check for data entry errors in real time as the user fills out the form [9], then isn’t an assistive technology user at risk of entering invalid data?

One step forward, two steps back?

If, like me, you consult on web accessibility issues, then AJAX is a major concern: procurers see the power of an AJAX-ified application but none of the fallout.

People seemed to be all too willing to put aside the years of building awareness, interpreting and implementing standards and complying with the law just as soon as the jaw-dropping cleverness of this powerful (and discriminatory?) approach to web development became clear.

AJAX became a saleable “feature” of web applications, moulded into a point of difference that could be touted by salespeople who very likely had no idea what software had to do with the Achaean strongman.

The sad truth on this angle is that, as Clark succinctly points out, accessibility is also just a product feature.

For procurers whose personal experience of assistive technology amounts to little more than the wearing of spectacles, and whose personal knowledge of the law is as blurry as not wearing those spectacles, accessibility just ain’t sexy.

The response: silence!

One answer to all this might be: change the assistive technology software, not the development techniques. Another might be to simplify the complexity of the offering (often wrongly interpreted as “dumbing down”). In the best tradition of human interaction, the best response is probably to meet somewhere in the middle.

The product of research conducted by James Edwards et al on screenreader reactions to AJAX is predictable: the reactions are unpredictable. [10]

The key finding, for screenreaders at least, seems to be that the whole process of updating content inline, which is what AJAX facilitates, is not picked up at all. This acts out as “I select a button or a link and nothing happens“. Not good.

If AJAX is used almost totally to improve user interaction, Edwards makes a typically valid point: “[i]nteractions are just details, and perhaps what we’ve really been doing is projecting our own desires and preferences onto users for whom they’re not really relevant”.

Rolling with the punches

Imagine a boxing match attended by politicians. If you asked a cross-section of the attendees about the result of the bout, all that you’d learn is that the red corner and the blue corner both won.

Similarly, both of these are true: accessibility best practice is totally on the ropes and AJAX is seeing stars.

On the one hand, progress is both inevitable and inexorable, but on the other, we have come too far towards a best practice for accessibility to lose out now.

Seconds away, round two?

I was asked earlier whether public bodies had a legal duty to publish content in foreign languages.

Consult a specialist in Public or Administrative Law for a better opinion, but as far as I’m aware, apart from Welsh authorities whose requirement is statutory, public bodies govern communications policies by way of a publication scheme under the framework of the Freedom of Information Act 2000.

A few examples of publication schemes include (subject to links remaining correct):

• Department of Health
• Metropolitan Police
• Cabinet Office
• Ministry of Defence

The publication scheme is based on a model from the Information Commissioner’s Office or defined by the public body. This document sets out the range of information to be made available and in what format.

Languages are an important part of accessibility, but public sector web apps will not require internationalisation as part of an accessibility check.

For more information, visit the Information Commissioner’s Office website.

Joe Clark reports that WCAG 2.0, the product of five years’ hard labour by the WAI is a poor effort.

The new raft of guidelines, set to become a standard shortly, closes none of the loopholes afforded by its predecessors whilst maintaining the infuriating trend of being unintelligible to most of its audience.

Whilst much of the same ground is trodden again in respect of the basics, major improvements are unclear or self-contradictory.

“As a working standards-compliant developer [you] are going to find it next to impossible to implement WCAG 2″ says Clark, adding that even if you follow the guidelines, you may not end up with an accessible site.

At last, a bit of consistency on site accessibility could be coming our way, reports the BBC today.

The British Standards Institute has released guidelines in the form of a Publicly Available Specification (PAS) in a valiant attempt to clear up the grand fog that is accessibility for websites.

Details are minimal without shelling out of course, but it would appear that PAS 78, developed by the Disability Rights Commission supports W3C specs and offers something like a definitive body of guidelines for website accessibility…