MikePadgett.com

Microsoft’s Office Sharepoint Server 2007 clears up some problems with cosmetic improvements, but delivers enough new ones out-of-the-box to remain beyond the reach of assistive technology users. Significant development will be necessary to ensure a basic level of accessibility.

Improvements in Sharepoint 2007

Microsoft applies accessibility best practice solidly in the desktop environment, but the same couldn’t be said of its recent online efforts. Redmond has often been seen to lag behind the rest of the online industry and resentments have built up over the years, particularly fuelled by the development of Internet Explorer.

So it’ll be welcome news from Microsoft that Sharepoint 2003 - a release pockmarked by deficiencies in both usability and accessibility - has been replaced by Microsoft Office SharePoint Server (MOSS) 2007, complete with numerous interface improvements.

Yet a roughly sketched summary of these improvements reveals a list of probable quick wins: due attention has been given to (easily altered) markup and some visual properties of out-of-the-box skins.

For better or for worse?

Indeed the origins of Sharepoint’s critical accessibility issues - and these are still the same in MOSS 2007 as they were in Sharepoint 2003 - lie in Microsoft’s dogged commitment to delivering online an interface with functionality equivalent to WinForms.

The practical result is a sort of Frankenstein’s Monster of the desktop and web paradigms, and to render such an interface the product must rely heavily upon client-side scripting.

Closer inspection establishes the argument that MOSS 2007 is in fact potentially less accessible than 2003. For, with the utilisation of bitesized asynchronous calls to the back-end (AJAX), the reliance on client-side scripting has increased exponentially.

Accessibility is not impossible…

Let us clarify the position here. Provided that the bells and whistles are left unpealed and unblown, it is not especially difficult to put in front of visitors a W3C-compliant, usable and accessible Sharepoint site. What’s problematic is that the cost benefit of Sharepoint’s many and various ways to automate groupware activity is somewhat diminished by the effort required by a standards-conscious organisation to make it seaworthy. Indeed, the message is plain enough: we have to customise to comply.

… it’s just going to take a lot of extra development

Assuming we’re ready to receive visitors to our newly compliant Sharepoint site, the other shortfall of WinForms literalism is rooted in the delegation of administration. Delegation is essential to the Windows system but not as easily translated to groupware and in Sharepoint there’s a lot of functionality to expose. As soon as we cross the boundary between Read and Write, the ongoing assurance of accessibility is all but impossible to sustain.

In simple terms, the technology required to leverage the power of the Sharepoint’s administration interface is the heartbeat of the product, yet assistive technologies can’t support it. That’s another plain message: an assistive technology user can access our compliant site, but she can’t feasibly administer it. Unless we invest a great deal more resources, of course.

The cost of concessions: “More Accessible Mode” and the Accessibility Kit for SharePoint

In his article on expected accessibility improvements for MOSS 2007, Microsoft’s Lawrence Liu envisaged a “‘more accessible’ mode that allows users with special needs to identify themselves so that we can change the way some of our dynamic content is rendered” (note the choice of the phrase “more accessible”, rather than just “accessible”).

Indeed, now we have the finished product, Liu’s follow-up remark is more accurate, with the ‘more accessible mode’ being made available “… so that third parties can create solutions catered to screen reader users”. The implication being that “more accessible” definitely equates to “more development” since this mode still appears depend upon at least some out-of-the-box client-side scripting to function properly.

A requirement for extra development in MOSS 2007 is honestly acknowledged by Microsoft, though Redmond stops short of interpreting that as a negative. And some organisations have made the investment: there is a collection in the public domain today of websites (numbers still in single figures) that have been created to meet accessible standards. What’s obvious is that all of MOSS 2007’s rich functionality is missing. Moreover, we cannot know whether they’re capable of being administered accessibly too, which is my principal concern noted above.

As the respected creators of accessibility test engine CynthiaSays, provider and vendor HiSoftware has partnered with Microsoft to develop an Accessibility Kit for SharePoint (AKS), which will target MOSS 2007. AKS will “deliver a kit that can significantly reduce the time, knowledge, and effort required to implement a SharePoint-based Web site”, say Microsoft and HiSoftware in a joint statement.

There are as yet no published release dates.

Master Pages, User Controls and Web Parts

General experience of .NET development tells us that it is more difficult to plan the workflow of developers with regard to the division of markup and programming, though this has become slightly easier since the release of .NET 2.0. Sharepoint adds a further dimension to the exercise in that it actually needs to be administered during development.

Developers must first produce accessible, compliant Master pages. A straightforward method of doing so is to step away from out-of-the-box Master pages and make use of a minimal template, such as the example made available by Microsoft.

The quality of markup that constitutes the output of .NET 2.0 user controls can be improved upon quite significantly using delegate controls or CSS-Friendly Control Adapters.

Unlike similar devices in other products, MOSS 2007’s Web Parts are rarely configurable, which contributes to the significant issue of controlling accessibility by output, given the often poor quality of Web Part markup.

Most Web Parts exhibit one or more of the following issues:

• HTML tables for layout, or improperly marked up for data
• Obtrusive Javascript that fails to provide alternatives
• Inline styles rather than applying external CSS by class or ID
• Multiple instances of ID attributes instead of unique IDs
• Fixed rather than relative units

Accordingly, it is essential that simple semantic markup is used in order to achieve maximum flexibility and optimal accessibility, otherwise all the hard work done on fine-tuning the Master and other user controls will be compromised.

Conclusion: fit for purpose?

As groupware, Sharepoint is an excellent concept: it enables the design of a domain-level information architecture, with the potential for a structured taxonomy, and a single point of origin for access, audit and workflow.

In practice however, MOSS 2007’s scalability and adaptability could be open to question. For reasons of brevity, the scope of this article is limited to web content publishing, but I’ve also experienced procurement evaluation processes (in which MOSS 2007 was one option) in the areas of Knowledge Management, EDRM and Project Management. Sharepoint tries hard to be a lot of things to a lot of people and in each of these cases, the positive noises were tempered by concerns about accessibility and more immediately, the impact on specialised governance.

In October 2007, the Intranet Benchmarking Forum published a report on the suitability of Sharepoint for an organisation intranet and its findings were mixed, while earlier in the year respected analyst CMSWatch considered MOSS 2007 inappropriate for web publishing scenarios.

Organisations looking to develop an adequately accessible MOSS 2007 solution for both visitors and administrators will need to make a significant investment and to accept the probable loss of Sharepoint’s richer functionality.

If Microsoft Office integration (or lock-in, depending on the reader’s interpretation) isn’t a key deliverable, then consideration should be given to a content management platform with a lighter footprint that wraps in good accessibility as standard and offers greater flexibility at the front-end.