(Last Updated on )
I work in the legal sector, so occasionally read the industry magazine Internet Newsletter for Lawyers. Last month they had an article bigging up the wonders of SharePoint, so I wrote in to the editor asking why they hadn’t mentioned its accessibility problems. The editor asked me to write them an article; as their mag is subscription-only, I reproduce it here.
I’m very grateful for the help given to me by Dana Simberkoff of HiSoftware and Adrian Higginbotham.
SharePoint accessibility: Introduction
I read March’s article “SharePoint – powerful and rather scary” and couldn’t help noticing that the scariest aspect of SharePoint wasn’t discussed at all. 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.
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.
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.
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.
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 Assistive Technologies” . 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.
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 MOSS2007. 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 MOSS2007 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, AT 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 PAS 78 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.