March’s article on SharePoint explained in some detail the “powerful and rather scary” services of the latest version. I believe that using SharePoint to publish to the web or to an intranet may contravene the Disability Discrimination Act, as the system doesn’t publish in a manner that adheres to internationally-recognised accessibility guidelines.

The accessibility guidelines

In 1999, the Web’s “governing body”, the W3C, published guidelines called the Web Content Accessibility Guidelines (WCAG). These guidelines contain a set of checkpoints which are organised into three levels of priority based on the checkpoint’s impact on accessibility.

Priority 1 is the most important: “A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.” Out-of-the-box, Sharepoint fails to meet one of the priority 1 requirements (checkpoint 6.3: “Ensure that pages are usable when scripts ”¦ are turned off or not supported”). It could be argued that this checkpoint is overly-restrictive nowadays – the guidelines were written in 1999 when support for JavaScript was considerably more primitive than now. The proposed revision of the guidelines (WCAG 2.0, which is still in draft) is a lot more forgiving of JavaScript. However, if your organisation uses the WCAG guidelines as a benchmark, you would need to be able to defend why this checkpoint is not met.

I believe that the minimum level at which the duties under the DDA are met is the more demanding Priority 2 checkpoints, which are defined: “A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents”. The DDA says “a provider of services discriminates against a disabled person if ”¦ for a reason which relates to the disabled person’s disability, he treats him less favourably than he treats or would treat others to whom that reason does not or would not apply”(see DDA section 20).

Sharepoint breaks several of the priority 2 requirements by using tables to lay out the page rather than Cascading Style Sheets, and by generating incorrect code that means nothing to non-Microsoft web browsers. As well as being difficult for disabled people to consume content published by Sharepoint, it is also very difficult (or impossible) for a disabled user to author content or publish it with Sharepoint, as it fails to comply with the Authoring Tools Accessibility Guidelines (ATAG).

Admitting the problem

Microsoft has attempted to address these deficiencies by partnering with a company called HiSoftware to develop the Accessibility Kit for Sharepoint (AKS). The future AKS version 2 promises to correct some of the incorrect code emitted by Sharepoint that breaks Priority 2 checkpoints and correct some of the ATAG failures, but the current version does not.

Meanwhile, Microsoft acknowledges that Sharepoint isn’t WCAG compliant, but claims that “SharePoint makes a good job of being accessible for people using AT” (see accessifyforum). It’s certainly the case that WCAG compliance doesn’t guarantee every disabled visitor can access content; neither does failure to comply guarantee that a disabled user has no hope of accessing the site. They are general guidelines, although they have been referred to as an accessibility benchmark in legal actions – for example, the terms of settlement to conclude an investigation by New York Attorney General into the accessibility of Ramada.com and Priceline.com travel websites (see OUT-Law).

The best thing to do is test the system with end-users rather than rely exclusively on guidelines. Adrian Higginbotham is a project manager and accessibility specialist at a government department, and “a visually impaired screenreader user who uses MoS2007. Or tries to anyway”. He told me that “under Sharepoint 2003, access to calendars is not possible, data entry for blogs and wikis etc is so hit-and-miss that it isn’t viable on a week by week (let alone day by day) basis, reading collaborative content is easier, and document management is possible but cumbersome. In trials of MoS2007 some things seem to have improved significantly and others not at all.”

He is uncertain of the value of the Accessibility Kit for Sharepoint: “Adding the AKS kit to MoS2007 seems to this end-user at least to give no obvious benefits and in some aspects to be a step back from the out of the box features. To the screenreader user using Sharepoint 2007 for office productivity tasks, there seems to be little or no perceivable benefit to using AKS, and while the out-of-the-box product is a significant improvement on the previous version it is still some considerable way from an intuitive, accessible tool.”

Dana Simberkoff of HiSoftware says that the AKS beta was tested with customers to ensure accessibility of the content: “Microsoft (and HiSoftware) have worked very closely with a large number of customers, partners, assistive technology users and stakeholders”. How can it be that those customers have a very different experience than that of Adrian? The answer is that not every person with a disability has the same needs and difficulties. Ensuring compliance with the Disability Discrimination Act requires testing, rather than just plugging in a box and leaving it running.

AKS is in active development: Simberkoff says that Microsoft and HiSoftware are “very committed to continuing improvements in the accessibility of SharePoint.” and notes that “while AKS is not a ‘magic pill’, it is intended to truly simplify the process for SharePoint developers”. Certainly, some expert Dutch and Portuguese web developers have had good successes with Sharepoint and the AKS, using a commercially-available third party add-on and customising the out-of-the-box behaviour.

CMS caveat emptor

Sharepoint isn’t the only system that can be used to make intranets or websites, of course – and it certainly isn’t the only one that produces code that is unhelpful to people with disabilities, or requires 20/20 vision and a mouse to operate. An absolutely vital part of deploying a new web site is testing it for accessibility, particularly one that emphasises its “Web 2.0” credentials such as collaboration, user-generated content and the like. Never assume that a product supplied by a big-name organisation guarantees that the way you use it will meet your obligations under the DDA.

If you are thinking about buying such a system, you should read the British Standards Institution’s “PAS 78: Guide to good practice in commissioning accessible websites” [Full disclosure: I was part of the review panel]. This was developed in 2006 in conjunction with the Disability Rights Commission (now the Equality and Human Rights Commission), and is a free download. There are informative appendices containing questions for non-technicians to ask suppliers of web developers and manufacturers or resellers of Content Management Systems. PAS 78 also recommends testing any systems with people with disabilities, and gives advice on how to accomplish this.

Note

One of the editors of WCAG 2, John Slatin, died recently of leukaemia, leaving his widow with considerable medical bills (they lived in the USA). A group of well-known accessibility experts (including Bruce Lawson) are volunteering to do expert accessibility reviews of people’s websites, in return for a $500 donation to a fund to raise money to help John’s widow. See knowbility for more on this.