Microsoft applies accessibility best practice fairly solidly on the desktop, but the same couldn’t be said of its recent online efforts.

Redmond has often been seen to lag behind the rest of the online industry and resentments have built up over the years, particularly fuelled by the development of Internet Explorer.

So it’ll be welcome news from Microsoft that Sharepoint 2003 – a release pockmarked by deficiencies in both usability and accessibility – has been replaced by Microsoft Office SharePoint Server (MOSS) 2007, complete with numerous interface improvements.

However what we’re seeing are quick wins rather than big changes: some attention has been given to (easily altered) markup and the visual styles of out-of-the-box skins.

For better or for worse?

MOSS: hasn’t aged so well

The origins of Sharepoint’s critical accessibility issues – and these are still more or less the same in MOSS 2007 as they were in Sharepoint 2003 – lie in Microsoft’s dogged commitment to delivering the functional equivalent of WinForms in a browser.

The practical result is a sort of Frankenstein’s Monster of desktop and web paradigms, onerously dependent on client-side scripting to hold it all together.

Closer inspection of this scripting suggests that MOSS 2007 is in fact potentially less accessible than 2003.

An uphill slog

If we can do without bells and whistles on the front-end, it’s not especially difficult to publish a semantically valid, usable and accessible Sharepoint intranet.

It’s just that we have to customise to comply, to the extent that the cost-benefit of Sharepoint is much diminished by the considerable resources required to make it seaworthy.

Administrative concerns

Assuming we’re ready to receive visitors to our newly-compliant Sharepoint front-end, let’s turn to that Microsoft speciality: the delegation of administration. Here’s where the complexity of transferring WinForms literalism to the web starts to take its toll.

The technology required to leverage the power of the Sharepoint’s administration interface is also the heartbeat of the product, but some assistive technologies won’t support it. An assistive technology user can access a carefully modified website, but she won’t feasibly be able to administer it. Unless, it seems, we’re prepared to put our hand in our pocket again.

The cost of concessions: “More Accessible Mode” and the Accessibility Kit for Sharepoint

In his article on expected accessibility improvements for MOSS 2007, Microsoft’s Lawrence Liu envisaged a “‘more accessible’ mode that allows users with special needs to identify themselves so that we can change the way some of our dynamic content is rendered” (note the choice of the phrase “more accessible”, rather than plain “accessible”).

Indeed, now that we have the finished product, Liu’s follow-up remark is more accurate, with the ‘more accessible mode’ being made available “… so that third parties can create solutions catered to screen reader users”. The implication being that “more accessible” properly equates to “more development”: this mode still appears to depend upon at least some out-of-the-box client-side scripting to function properly.

A requirement for extra development in MOSS 2007 is honestly acknowledged by Microsoft, though Redmond obviously stops short of seeing that as a potential negative.

Some organisations have made the investment: there is a collection in the public domain today of websites (numbers still in single figures) that have been created to meet accessible standards. And it’s clear that in these examples, MOSS 2007′s rich functionality is missing. Nor can we guess whether or not these examples are capable of being administered accessibly.

As the respected creator of accessibility test engine CynthiaSays, provider and vendor HiSoftware has partnered with Microsoft to develop an Accessibility Kit for Sharepoint (AKS), which will target MOSS 2007. AKS will “deliver a kit that can significantly reduce the time, knowledge, and effort required to implement a Sharepoint-based web site”, say Microsoft and HiSoftware in a joint statement.

There are at the time of writing no published release dates.

While-U-Wait: Master Pages, User Controls and Web Parts

In the meantime, general experience of .NET development has already raised the issue of how to guarantee good markup from programming, a task that has become slightly easier since the release of .NET 2.0.

Developers must first produce accessible, valid Master pages. Rather than out-of-the-box Master pages, this process should start with a minimal template, such as an example made available by Microsoft.

Thereafter the quality of markup output by .NET 2.0 user controls can be improved upon quite significantly using delegate controls or CSS-Friendly Control Adapters.

Unlike many of the widgets and plugins of other, comparable products, MOSS 2007′s own Web Parts are rarely configurable (presumably because of their proprietary nature), which contributes to the issue of accessibility, since these same Web Parts typically spit out execrable markup.

Most such Web Parts exhibit one or more of the following issues:

• HTML tables for layout, or improperly marked up for data
• Obtrusive Javascript that fails to provide alternatives
• Inline styles rather than applying external CSS by class or ID
• Multiple instances of ID attributes instead of unique IDs
• Fixed rather than relative units

Accordingly, it is essential that simple semantic markup is used in order to achieve maximum flexibility and optimal accessibility, otherwise all the hard work done on fine-tuning the Master and other user controls will be compromised.

Conclusion: fit for purpose?

Web-based groupware promises much for the future: information architecture, findability, collaboration and a single point of origin for access, audit and workflow.

The debate on how far Sharepoint achieves the definition is open. At the time of writing (October 2007) the Intranet Benchmarking Forum published a report on the suitability of Sharepoint for an organisation intranet and its findings were mixed, while earlier in the year respected analyst CMSWatch considered MOSS 2007 inappropriate for web publishing scenarios.

Whether or not Sharepoint does the job in a general sense, organisations for whom a high level of accessibility is important (in an ideal world, that would be all organisations) should be concerned about MOSS 2007.

Organisations looking to develop an accessible MOSS 2007 solution for both visitors and administrators will need to make significant investment in development and to accept the probable loss of much of Sharepoint’s richer functionality.

If Microsoft Office integration (or lock-in, depending on the reader’s interpretation) isn’t a key deliverable, then consideration could be given to a content management platform with a lighter footprint that wraps in a high level of accessibility as standard and offers plenty of flexibility at the front-end.

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]

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].

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 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 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.

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.

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 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.

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?

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.

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, be sure your CMS does too!

At last, a bit of consistency on web 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…

J recently pointed out to me a website she’s been looking at called Heavy Backpack. It’s billed by its makers as a “Creative Catalogue” – in other words a mini portfolio for each of its contributors and there are some outstanding examples of graphic design in there with the usual derivative stuff.

Heavy Backpack

But the site itself is what interested me first. It looks attractive, along similar lines as K10K or any number of those horrible awards sites that all present us with a cutting edge mostly made out of Flash.

Now, of course I realise that the right way to do this kind of magazine (or catalogue or whatever) site is to mute your design so as to let the content do the talking, but being a person interested in the details, I couldn’t help but notice as the site slowly loaded that there were so many images on the page.

My interest was piqued and I dived right into the source code to see what efforts had been made.

Few. 27 validation errors in HTML 4.01 Loose. A cherry pick of the accessibility issues includes those perennial favourites tiny type, iframes and almost no alt attributes.

The team that put Heavy Backpack together is Wade Studios, an Australian business with a good client list. Very talented graphic designers, clearly, but as web designers they ain’t.

In the last year, I have become increasingly convinced that to call yourself a web designer today means that you are a proficient XHTML/CSS coder, a standards evangelist and well-versed in usability and accessibility best practices. So says Zeldman, so says O’Shea and all that lot, so says Nielsen, and so say I. A graphic designer is not a web designer.

Quote:

“Too many graphic designers have tried to force the Web to be what it is not, in the process creating ineffective and sometimes unusable websites. Quality web design is driven by information architecture design principles. Graphic design should support these principles.” – Gerry McGovern

Graphic design houses ignored the Internet. It was low culture for a long time and there was no money in it. But today, interactive projects can rival those in other media in scale and value and now these same graphic design houses are selling their web capabilities where they can’t get through the door on the back of print alone.

But in truth, the fuddy old Art Directors don’t understand websites. Just as some design houses tried to stay aloof when DTP was adopted by all walks of employee (even though the product was crap, it was certainly cheap) they also missed the boat with the Internet.

Hence why the code is neanderthal, or worse, art program-generated.

Hence also why it’s pretty but without practicality.

[See also: Design Choices Can Cripple A Website by Nick Usborne, 08/11/2005 A List Apart]