Recently I had a meeting with HiSoftware about the Accessibility Kit for SharePoint that they’ve made (and is available on CodePlex), and it was quite interesting. Making a SharePoint system accessible requires knowing how much of the system to make accessible, and to what level of accessibility. As with branding, doing the whole system would probably be prohibitively expensive. However, making certain areas (such as a WCM site) accessible is quite feasible.

Even if a SharePoint system is developed to be accessible, there is a governance issue in make sure that new content is also accessible. HiSoftware provide the Accessibility Kit (for free) to help develop an accessible site – though custom work will always be required. They also provide several commercial products to facilitate governance of new content and ensuring that it is accessible. I think that these will be useful sometimes, so it’s not a bad sales pitch.First off it would be good to ask, what is accessibility? Well, accessibility is making a program or web site work for people with a wide range of interaction devices. At one level, making a website work in Opera is making it more accessible; however, usually accessibility is used to refer to making a website work for users with a range of disabilities. For example, a website that showed a video might have a transcript of the speech, or images that have “alternate text” that screen-readers can read to blind people. Colour is also an important issue – you’ve got to make sure that a site will work for various different types of colour blindness. So is text size – SharePoint uses a ‘fixed size’ font, so visually impaired users can not make it bigger or smaller in the browser, and this is a big no-no. For example, these images show a typical SharePoint system in IE7 with the text-size in the browser set to biggest and smallest:

As you might notice, some of the content changes size – but more of the text on the page, including all the navigation, doesn’t.

Accessibility is a complex subject as users could use all sorts of weird user interface devices, such as text only browsers, screen-readers, Braille displays, etc.. Consequently, accessibility always has a question of how far you go. Certain ‘levels’ of this are embodied in the WCAG 1.0 ratings ( A, AA, AAA, etc. ) by the WAI.

What HiSoftware have done is produce a toolkit that fixes a number of these issues (or, at least, makes it easier for you to fix them). It isn’t a solution – you don’t just plug it in and suddenly you’re accessible. In fact, there isn’t anything in it that I don’t think I could program, but their point is simply “why reinvent the wheel”. It’s a good point, and I certainly think that we can find a use for it.

The Accessibility Kit is being developed and released in stages. Stages 1 and 2 have been released already:

1. WCM – Accessibility stuff for WCM sites only
2. Collaboration – Accessibility stuff for collaboration sites (wikis and blogs)

Future additions will include an accessible Rich Text Editor control (neither the MOSS or Telerik ones are). This is something of a Holy Grail. The kit itself is open-source (it would be hard for it not to be), and it is free.

One of the things that I took away was how it’s necessary to treat Accessibility like branding – when a customer asks for an accessible SharePoint system, we’ve got to ask “which bits?” Building a SharePoint System that is accessible throughout is a massive undertaking. If you can restrict the scope of the bits that need to be accessible, then that’s a good idea. For example, why bother making My Sites accessible if it’s only internal users using them, and there is no internal requirement for accessibility?

There are problem areas that we discussed:

• Libraries and lists – as there are some complex user interactions going on in there (List menus, List ordering, Views, View menu, ListItems menu and submenus to name a few)
• Administration pages – the same problem as branding, they’re not really designed to be modified. Note that some ‘Administration’ pages are visible to normal users…
• Web Part Zones – don’t produce good code for screen-readers and the like.

Further, some companies may insist on XHTML-Strict compliance – this isn’t really the same as accessibility, though you can use similar techniques to try and achieve it. With SharePoint this is very hard and (I believe) of limited value.

The biggest thing that got my attention was actually HiSoftware’s sales pitch (but they have a good point – really). Although we can build an accessible site, content will then be authored by the users. It’s unlikely that they know anything about accessibility, let alone how to write so that their site remains accessible. Thus, we need to have some way of ensuring compliance with accessibility rules, guiding users in how to fix content, locating content that needs fixed on the site, etc.. This then brings us into contact then with the world of compliance too – make sure that, for example, rude words aren’t used in the content. HiSoftware produce a number of tools to help do this:

• A plugin for SharePoint Designer to help designers make accessible pages/page layouts, etc..
• A feature for SharePoint to allow content authors to test the pages they’re writing
• A program for crawling and checking accessibility and compliance of your site
• Processes and workflows to support enforcing compliance (sort of like advanced ‘Content Approval’ workflows, but allowing things like users to pass content to a technical team if they don’t know how to make it comply).

See their MOSS solutions page for more details. HiSoftware seem to have come to SharePoint from a website accessibility and compliance management background and have realised that this is something missing in SharePoint 2007…