At the risk of going on too much about the issue of accessibility enabling applications; here is my current state of thinking regarding the tendency for organisations to want to strongly brand and apply accessibility rules to an internally facing SharePoint application (as opposed to a SharePoint website). It’s written a white paper…

We often find our clients ask us about branding for intranets. This is commonly followed by questions about how accessible the intranet will be and whether it meets W3C standards.

It is fair to say that most SharePoint applications help manage communications, documents and a range of types of information. It is sophisticated in the way it allows users to navigate between and link types of information and activity together. It provides a means of collaboration and a degree of visibility of and to co-workers and other colleagues, whether internal or external to the employing organisation.

Although the features can be accessed through client applications, it is mostly used via a browser. We note, at this point, that it is our firm belief that intranets (whether developed in SharePoint or not) are applications not websites. I have been wondering what other applications are similar in order that we can benchmark the attitudes towards branding and accessibility of those compared with a typical SharePoint application.

It strikes me that Outlook Web Access (OWA) is a pretty close match. It has many similar functions to SharePoint (though with some difference in emphasis and definite differences in mode of use); like SharePoint, it is used for communication and collaboration, as well as acting as a document and information repository. Also like SharePoint,  Outlook Web Access is browser enabled and large numbers of users (especially in the NHS) use a browser to drive the application. However I have never (ever) heard a communications team insist that OWA has a third of the screen filled with their logo or that it is tested against W3C in order to provide accessibility.

On the matter of branding,  I’m generally relaxed as I see the value of an attractive user interface and something that supports the brand of the organisation (recognising that a brand is so much more than a logo stuck on the top left and a bunch of colours); so long as the branding doesn’t interfere with the usability of the application by compromising the functional design, minimising the working area or consuming budget that would be better spent developing the feature set. Ultimately this is a business decision in which the budget holders need to decide how much to invest in what aspects of the technology and the suppliers should be resolute in exposing the cost of the iterative design process.

As for accessibility, that’s a much more challenging debate as it is tempered by various laws relating to disability.

So, firstly, let’s establish that the law as it relates to websites does not apply here. There is a legal requirement, no matter how sparsely implemented,  for publically accessible websites to meet accessibility standards, since there is generally no knowledge of who may wish to use the site as a source of information, entertainment, etc.  However intranets are not websites just because they run in a browser. As observed above, other applications that serve somewhat similar functions are rarely treated as websites; intranets often are because (for largely historical reasons) they often have elements that look a lot like a website. Cellos look quite like guitars – but we don’t treat them the sam

So what about employers and the software systems they purchase? The law here does not seek to single out particular classes of software application and require them to meet higher standards. Instead the employer does have a duty to make ‘reasonable adjustments’ to workplaces and working practices to make sure that people with a disability are not at a substantial disadvantage compared to other people. What is considered ‘reasonable adjustment’ will depend on many different things, including:

• the cost of making the adjustment
• the amount the adjustment will benefit the employee
• the practicality of making the adjustment
• whether making the adjustment will affect the employer’s business/service/financial situation.

The Disability Discrimination Act (DDA) doesn’t outlaw the sale or purchase of inaccessible software, but any systems that are implemented must not discriminate against disabled people. A revision to the DDA that came into force at the end of 2006 introduced the Public Sector Duty to promote disability equality (also known as the Disability Equality Duty). Government employers and service providers will in future have to consider accessibility when they specify and buy software.

So it seems that there is a need to consider accessibility in software applications, though not to meet any particular standard and nor to apply web standards to internal applications. And, in an environment of an increasing number of browser based applications, including clinical systems, finance and HR systems, certainly not to single out  intranets while letting others off the hook. That would seem to be discrimination indeed.