Sharepoint Accesibility: Down and Dirty on the Front Line

Introduction

For one of my current projects, I've been tasked with making a Sharepoint site match up to our exacting Accessibility standards.

Out of the box, Sharepoint only nods in the direction of Accessibility. The default templates don't validate and only tick a few Web Accessibility checkpoints. Somehow we are going to have to 'mangle' the code produced by Sharepoint and massage it into something a bit more acceptable.

There are a couple of techniques we can employ to help us along the road to Accessible Sharepoint. I'll be looking at these techniques over the next few posts.

To start with, we need to make sure ASP.Net can produce the accessible code we require.

First stop: Built in Controls.

This has nothing to do directly with Sharepoint. I'm talking about the built in ASP.Net controls, but a fair few sharepoint web parts rely on these controls, so they need a little work.

Microsoft have supplied a way to re-skin these controls by using Control Adaptors. In essence, control adaptors overwrite the default output methods of a control with custom methods allowing you to customise a controls output.

Fortunately, a lot of the work has already been done for us! Microsoft have already released some free (and open source) CSS Friendly Control Adaptors (CFCA) which turns the 80's table based layout of most controls into something a lot easier to style with CSS and a lot more accessible.

Installing these into a Sharepoint installation is not too tricky. There are a number of sites out there that explain the process. Unfortunately, all these sites install the control adaptors into the main website. I just wanted a solution that could be packaged alongside the website and re-distributed cleanly.

I'll show you how to get CFCA working for one User Control: The ASP Menu Control. In its raw state, the menu produces some really nasty table-in-table mark-up when what we ideally need is a nice, clean, nested unordered list.

1. Download and install the CFCA package onto the PC that hosts your sharepoint site.
2. Copy MenuAdapter.vb and WebControlAdapterExtender.vb into your sharepoint sites virtual directory.
   
   Mine for example is: C:\Inetpub\wwwroot\wss\VirtualDirectories\bffs80\App_Code
   
   (where bffs80 is the name and port of the website)
   
   If you don't have an App_Code directory, create one.
3. Now, we need to tall ASP to use our control adaptors for all instances of menu controls in the site.
   
   Add the following code to the file: C:\Inetpub\wwwroot\wss\VirtualDirectories\bffs80\App_Browsers\compat.browser
   
   It needs to be just inside <browsers>
   

       <browser refid="Default">
       <controladapters>
       <adapter controlType="System.Web.UI.WebControls.Menu"
                adapterType="CSSFriendly.MenuAdapter" />
       </controladapters>
     </browser>
   

4. That *should* be it. If you refresh your webpage, the site menus should now be a lot more CSS friendly.

Next time, I'll take a look at what the Accessibility Kit for Sharepoint has to offer.

Who are you?

Perhaps we shouldn’t be surprised that methods of identifying ourselves on the internet are proving quite controversial. After all, the UK’s National ID Card scheme is having a far from easy ride into reality, with, quite correctly, many questions being asked about security and privacy. So, when systems are proposed which would allow internet users to have just a single identity which they could use when signing in to all their web sites, we should expect a similar level of scrutiny.

Richard’s earlier blog entry (Shibboleth in 60 Seconds, 25/01/2008) outlined one such single sign-on system, which Futurate are implementing in an application for the Joint Information Systems Committee. In JISC’s case, the single sign-on is currently envisaged for use on web sites and web-enabled applications within the organisation and its affiliates, but in theory the technology could provide internet users with their single identity on the web.

The heavyweight contender in single sign-on is OpenID, with technology leaders such as Microsoft, Google and Yahoo lending their support to the OpenID Foundation. Unlike Shibboleth, with OpenID a user can create their own identity independently of the organisations which will ultimately want to verify that identity.

It’s important to note that your OpenID only replaces a username and password; no trust has been established with the sites where you use it to sign-on. So you will probably still have to go through a registration process in order to access the facilities provided by a site. However, organisations could choose to operate OpenID for single sign-on to their own applications – much as JISC have opted to do with Shibboleth, which holds personal (rather than internet persona) details of users and can also hold the permissions they have been granted on the organisation’s applications.

The advantage of OpenID is that it is open source and relatively easy to set up, whereas integration of Shibboleth can be quite complex – there is that trust relationship to protect after all. The idea of using OpenID as a web wide personal identifier also has its detractors. There are arguments that the less tech-savvy users would be vulnerable to phishing attacks, and just because a user has a verified OpenID doesn’t mean they pose no threat – you don’t actually know who they are!

With the momentum gathered behind OpenID, it seems inevitable that it will enjoy a high take-up (there are already around 160 million ids, and over 10k sites supporting OpenID sign-on) and it’s possible that in the future we may need to have an OpenID to access certain facilities – in the same way you currently need a Google Mail account to use Google Analytics. It’s easy to see the advantages of only having to remember one username and password, but then you only have to loose the one identity (or have it stolen) to be completely exposed.

The debate about OpenID, and indeed the single sign-on concept itself, will most likely run for a few years yet. Personally, after spending a few hours reading just a small selection of the articles and blogs on the subject, I find myself curiously comfortable with my numerous internet identities and persona – maybe it’s a control thing.

Bye Bye Bobby

In the olden days of web accessibility when being concerned about digital inclusion wasn't very fashionable, Bobby was part of everybody's life. It wasn't perfect, but it worked and Futurate would routinely use it as part of our QA process.

Then Bobby was acquired by Watchfire. It became WebXact but it was still available albeit in a pumped-up, enterprise focused edition. However I looked for it today and it seems that WebXact is no more. Instead Watchfire have a tweaked, slightly baffling website with news items such as IBM's Watchfire Team Demonstrates Dangling Pointer Remote Command Exploitation at Black Hat USA 2007 Briefings (!) and Bobby has become part of IBM's Rational Policy Tester Accessibility Edition (is someone going to tell the RNIB)?

It looks like it's Cynthia Says for me from now on.....

It's a pity that the increasingly sophisticated software tools that are available don't seem to be having the desired effect on levels of public sector compliance, however given that the Rational Policy Tester website uses tables for layout, vendor commitment to really helping resolve the issue is probably fairly low....

Local Government Websites: Less Accessible Than Ever?

Somewhat depressingly the 2008 'Better Connected' annual report by The Society of Information Technology Management indicates that local Government websites are actually less accessible now than they were a year ago. This is based on a survey of 552 websites that used automated testing tools and input from the RNIB to evaluate compliance with W3C WAI Single A (single A is the lowest compliance level. Double A is the minimum legal requirement for public sector websites).

According to the report only 6.7% were Single A compliant, compared to 11% in 2007, which is a frankly terrible statistic. This news comes in as version 2.0 of the W3C WCAG edges towards completion and the BSI announces that it is to develop a new technical standard for accessibility.

If the public sector finds it difficult to meet the requirements of just one set of web accessibility guidelines (WCAG 1.0) its ability to get to grips with WCAG 2.0, WCAG 1.0 and the forthcoming accessibility standard from BSI is questionable.

Hopefully the work of IST/45 will create some clarity, and it's proposal that the standard will be available in just 12 months certainly suggests confidence given the apparently never-ending gestation period for WCAG 2.0.