Accessibility may affect feasibility of Sharepoint intranet

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…

Accessibility row over Better Connected 2007

In the ring: getting into the accessibility square-off

A very public row broke out recently over a report concerning the results of a survey published by Socitm entitled Better Connected 2007, which surveyed the level of accessibility of 544 local authority websites.

The brouhaha centred upon the methods employed by Socitm to generate metrics amounting to a thumbs up or down.

The ink on the publication had barely dried when the influential PSF weighed in conspicuously with vocal criticism of “continued peddling of what can at best called ill-informed pontificating and at worst out and out drivel.”

Better Connected is one such example, and the Insight team behind it add insult to injury by clipping town halls for £395 a pop as they vacuum up cash like the most opportunistic of privateers while cowering behind and milking their quasi-official .gov.uk status for every penny they can. [1]

To be accessible or not to be accessible: is that the question?

The methodology consisted of a programme of automated testing, followed by human testing conducted by the RNIB, an organisation which has been seen to take a leading role in the promotion of accessibility best practice in recent years.

Acrimony surrounds the report’s implication that sites that did not meet the W3C’s WCAG were deemed to have “failed”, contributing to a generally gloomy bigger picture in which the site of only one local authority was rated ‘excellent’, 64 others reached Level A Conformance (compared to 62 in 2006) and the rest presumably trailed even basic standards.

The overwhelming issue highlighted by PSF and others [2] is that reliance upon WCAG, automated testing and narrow criteria does not make for an accurate assessment of accessibility, generating instead sensational headlines and more spin based on a “dodgy methodology which fails (and therefore implies inacesssibility of) perfectly good websites … This is doing more harm than good” [3].

Accessibility is not black and white

Are false impressions being created? Certainly a great deal of energy has been spent mooting just that, but away from the glowering flames, there’s also the year-on-year grinding negativity of Better Connected to worry about.

The RNIB’s Donna Smillie suggests that there’s something inherently wrong about seeing accessibility as a boolean [4], yet there can be little doubt that many do make that mistake.

Though the context of Smillie’s statements is intended to support Better Connected, doesn’t the report - and the study as a whole - encourage a pass/fail view of things, attempting as it does to generalise into a digestible format what is a wide-ranging and often laborious area of practice treated in varied meticulous ways by hundreds of different organisations?

This is after all a quantitative study, not a qualitative one.

Flash is 10

Flash icon

Flash is ten years old, as the BBC reports, and for any Internet technology still around after a decade that’s a considerable achievement.

When I started out in web design, it was almost the only medium I worked in, reflecting the tastes of the time. That was before the Flash backlash, led by the arch-headline-grabber himself Jakob Nielsen’s vociferous take on the matter.

Since then, the paths of Flash and I have diverged considerably. I rarely work with it nowadays.

Inappropriate Flash

Inappropriate Flash harms user experience

I haven’t seen developers breaking new ground lately, in the way every week used to bring extensions of Flash’s seemingly limitless capabilities in two dimensions.

Just at the time when Flash was in the corner licking its wounds, good old HTML enjoyed a renaissance with the adoption of web standards and increased accessibility. Today, JavaScript has taken markup into orbit and in a curious irony, it has also saved Flash from a further beating from the Eolas patent mess.

A few major successes have been brought to us by Flash in recent times. Yahoo has finally done the obvious and released a Flash mapping interface and YouTube’s video relies totally upon Flash’s video capabilities, of course.

YouTube logo

Indeed, it’s the video stuff that ensures Adobe’s trusty plug-in is still relevant today, since the tech corporate’s vision of an all-purpose application delivery medium still looks years away, with a muted response to Flex and Microsoft’s competing Avalon (now imaginatively retitled WPF) technology tied to the long-delayed Vista.

“It’s a bit chaotic. There’s lots of noise, lots of activity. That’s great; there’s a huge amount of innovation” said Adobe’s Kevin Lynch [1] when asked about the future of Flash. Not a straight (or strong) answer.

In times past, Macromedia always managed to brave the storms, so perhaps Adobe can keep the tide in its favour.

21st century job

Remember when a job was something to be proud of? When a job was a job for life?

Thatcher's children

Before you complain and click “Back” dear reader, let me assure you that this is not an article about the long-term effects of Thatcherism.

No Sir/Madam, this is an article about breaking free from the strictures of bad jobs and worse job titles and proposing a new role for the 21st century. It’ll come as no surprise to you that I’m trying to occupy this role myself.

I’ll call the role Information Designer. This isn’t a new job title - it already means something in Designland, but that definition isn’t nearly enough. It’s also a very basic job title, because the job should come with a wide brief and enough autonomy for the individual to firm up that brief. Indeed, Information Design already exists as a body of disciplines, but the job specs are always highly fragmented.

The Information Designer that I envisage is someone who, in the simplest terms, makes sense of complex information and communicates it effectively so that information is converted to knowledge.

The work includes elements of:

  • Business intelligence
  • Data analysis
  • Web design (plus usability and accessibility)
  • Graphic design (plus typography)
  • Training and presentation delivery
  • [Insert relevant disciplines here]

There are quite a few skillsets here, including those of web designer, graphic designer and information architect. I think that, just as web people need to have a good grasp of several technologies, so too should the 21st century Information Designer be very capable in each of these disciplines, rather than having to outsource bits of it to freelancers.

The London Underground, sort of

The 21st century Information Designer role has precedents. While designers could still avoid being pigeonholed, the range of Otl Aicher’s work comes close to my concept, as does the utility of Harry Beck’s solution to the mapping of the London Underground in 1931.

The Information Designer is a designer since his/her work is all about finding solutions, but the information could be absolutely anything considered complex needing logical organisation and it’s this latter aspect that goes beyond visual design.

Accessibility and web applications

What AJAX is not

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.

Having your cake and eating it: but AJAX is not accessible

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.

Rolling with the punches: illustration of a boxer

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?

Languages and the public sector

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

Berlitz Paris language school poster

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):

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.

WCAG 2.0: clear as mud?

Accessibility symbol

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.

Playing CMS catch-up

Illustration of a fountain pen

If you’ve spent time designing and building usable, accessible web pages to hand over to developers, you probably have to resist the urge to stand over them while they’re at work.

Assuming you pick up on every little issue, you’re justifiably proud by the time release comes along.

Then, like a house of cards, your delicate, pristine code comes tumbling down when users start editing content.

I would chance to claim that the overwhelming majority of CMS products publish horrific, nay rude, HTML created in those oh-so-friendly WYSIWYG editors.

And when you fix some of the worst offenders in the source view, the Editor goes and validates against you and your well-meaning hard work.

It’s a problem to which today’s BBC News article alludes when discussing accessibility failures on government websites.

So to all those who strive for web standards, I say, make sure your CMS does too!

About time for accessibility

Accessibility symbolAt 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…