Bruce Lawson's personal site

SharePoint and Web Accessibility

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.

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 justify why you don’t meet this checkpoint.

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

(Last Updated on )

Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)

12 Responses to “ SharePoint and Web Accessibility ”

Comment by JackP

Of course, there’s a big difference between “is not accessible to disabled users” and “doesn’t comply with WCAG 1.0”.

Anything that fails the former – as Adrian’s comments would suggest – needs to be improved or you’re seriously failing people. Anything that fails the latter but not the former is likely to be bad practice (e.g. tables for layout) but not necessarily a show-stopper in terms of whether or not someone can use the site.

It boils down to what should websites be mandated to achieve. Must we legally mandate accessibility for those with disabilities? (I’d say yes). Must we mandate good practice? (I’d say no, but I would still want to encourage it).

And it sounds to me that MOSS is moving towards achieving accessibility for those with disabilities (albeit not quite there, even with 2007) but with considerably more problems when compared the ‘good practice’ parts of WCAG 1.0 – which is still generally used as the accessibility ‘benchmark’.

Comment by Matt Machell

I think my biggest problem with Sharepoint is the amount of round the houses patching, tweaking and correcting you have to do to get it to play nice. It’s a sink for time and energy, when it shouldn’t be.

Comment by Uwe Wiedemann

I also think that MOSS 2007 is not accessible for blind persons. I will remember that MOSS 2007 is a authoring tool and it has not only to fulfill WCAG but also ATAG (Authoring tool guidlines) because MOSS excludes not only persons that use the content made by this tool but it excludes also person within the enterprise that is using MOSS 2007. From this point of view we are light years away of an accessible MOSS. We have also not found so much benefits of AKS. The next step should be to add a good heading managment because headings are not at there logical place where they should be from the point of view of a screenreader user and headings are a very important navigation tool for blind persons (much more important then access keys). (There should be no breadcrumbs or other things between a heading and its content.) Another point is that the lists are horrible because in the standard views the first column contains frequently no content but only a radio button.

There is frequently a misunderstanding of testing web content or authoring tools by disabled people. If they are experts in accessibility then they can be tester for some content or authoring tool, but if they have not this expertise they can only be a test person, i. e., a person that is observed by a person that is an expert for accessibility. Maybe Microsoft and HiSoftware have not made a difference between these two different roles of disabled persons in the test process.

Comment by Adrian Higginbotham

Good round-up I see HiSoftware don’t really address the fact that currently most of their development and v2 plans seem to focus on output as pages and sites rather than the user interface. Serve the larger market first – makes good sense and I’d be disappointed if they did otherwise but doesn’t help me when colleagues upload a batch of files to a share working area in 5 seconds flat and it takes me 20 minutes to do the same thing one file at a time.

Comment by Bruce

Interesting, Ivan. Thanks.

The Equality and Human Rights Commission might be single A compliant, but its homepage contains errors preventing it meeting AA compliance (largely html validation errors). It’s riddled with inline styling, obtrusive JavaScript, the home page has this charming markup

<p><strong><font color="#cb1e4a" size="4">

to look like a heading – thereby not fully conforming to WCAG checkpoint 3.5 “Use header elements to convey document structure and use them according to specification. [Priority 2] For example, in HTML, use H2 to indicate a subsection of H1. Do not use headers for font effects.”

He doesn’t mention whether he uses AKS or not. I don’t doubt that it’s possible to force Sharepoint to produce ugly, bloated code that almost meets priority AA, with a hell of a lot of work and voodoo magic.

My point is – why bother, when most of the new generation Content Management Systems do a better job out of the box?

Comment by David McElroy

Nice article, thanks. Without going about it myself does anyone know of an article that lists what points SharePoint does and doesnt meet out of the box and out of the box with accessability mode?

On the last comment
“My point is – why bother, when most of the new generation Content Management Systems do a better job out of the box?”

You have to bother when you are stuck in an organisation who already have SharePoint/MOSS 2007 and it needs to become accessible.

Comment by Doug

Unfortunately- some of us don’t have the option of using another cms. We have to give every effort to seeing if we can make it work, because that’s what they want. In a year- maybe we can convince them.

So for now, I have to find ways to make this accessible. Especially for the state of kansas (which I do sites for city, county and state agencies) which is strict on enforcing section 508 as well WCAG standards.

I am currently researching web parts that are compliant and finding ways to make a more compliant template.

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.