A Technical Architects View

Introduction

In recent years the public sector has been under increasing pressure to actively promote disability equality when undertaking software development. For web projects, the W3C standard, ‘Web Content Accessibility Guidelines (WCGA)’ covers a wide range of issues and recommendations for making web content more accessible.

WCAG standard

WCAG 1.0 (http://www.w3.org/TR/WCAG10 ) contains principles, guidelines, and success criteria that define and explain the requirements for making web-based information and applications accessible. "Accessible" means usable to a wide range of people with disabilities. Following these guidelines will also make web content more accessible to the vast majority of users, and enable people to access it using many different devices.

What’s the requirement?

Although there is currently no mandated minimum level of requirement, it is widely accepted that the minimum level required to comply with UK law is Priority 1 of the WCAG, at the very least, this means the removal of some of the most obvious barriers to a disabled visitor to a website.

UK directive

The UK Government and the RNIB both advise that organisations should surpass Priority 1 to at least Priority 2 to make a website truly useable by disabled visitors. According to a statement made about “Delivering Inclusive Websites”;

The minimum level of accessibility for all Government websites is Level AA of the W3C guidelines. Any new site approved by the Cabinet Sub-Committee on Public Engagement and the Delivery of Service (DA(PED)) must conform to these guidelines from the point of publication.

Continuing standalone sites had to achieve this level of accessibility by December 2008. Websites which failed to meet the mandated level of conformance would be subject to the withdrawal process for .gov.uk domain names, as set out in Naming and Registering Websites (TG101).

EU Directive

In 2002, the European Parliament set the minimum level of accessibility for all public sector websites at Level AA. However, a recent survey of public sector services showed that 70% of websites in the European Union failed to conform to Level-A of the W3C guidelines. E-inclusion is a European policy initiative which aims to ensure that ICT (Information & Communications Technology) is usable by a wider population; and to promote the use of ICT to achieve social inclusion objectives.

What is MOSS?

Microsoft Office SharePoint Server 2007 (MOSS) provides an extensible framework for building web applications. This includes content managed publishing websites for internet, extranet and intranet applications.

Key solution Requirements

Drawing upon the accessibility requirements of public sector organisations, and taking into account UK & EU directives, combined with Parity’s experience of delivering successful enterprise web solutions, we believe the key requirements MOSS needs to deliver are:

o XHTML 1.0 Strict mark up

o Compliant CSS2.0

o Facilitate development of web sites up to WCAG-AAA

o Provide multilingual and taxonomy support by default

o Provide an extensible scaleable architecture

o Provision a solution that accelerates development

What are the issues?

Out of the box MOSS 2007 applications are typically constructed using Web Parts which are building blocks that allow web applications to be extended. The inclusion of web parts on a page is done through WebPartZones. Zone implementations are hardcoded and do not support the accessibility guidelines on a number of instances:

o WebPartZones uses HTML tables for its graphical design breaking the 5.3 guideline in WCAG 1.0.

o WebPartZones only support personalization if you use JavaScript, which breaks guideline 6.3 in WCAG 1.0.

o Web parts are poorly implemented in some browsers which breaks the guideline 6.4 in WCAG 1.0

Supplementary to the issue of Web Parts, MOSS 2007 output rendering is also a subject for concern and requires various work around’s to overcome these shortcomings.

Accessibility Kit for SharePoint

Microsoft partnered with accessibility technology vendor HiSoftware to build the toolkit however there are significant limitations with this product most noticeably:

o AKS targets WCAG-AA (which means it cannot achieve AAA)

o There are fundamental drawbacks with using Web Parts which the AKS solution does not address

o AKS is very limited around invalid HTML markup – so this approach is likely to need supplementary software (i.e. XHTML is not addressed)

o Using control adapters will have a detrimental effect on performance due to the intensive cpu requirements for string manipulation (i.e. scaleability implications)

o This approach still requires sites to be built from the bottom up and does not fast track the construction process

o Integration of supplementary code or third part products is still required for areas such as advanced search, taxonomy and multilingual support.

Overview

Due to the significant short comings in AKS, Parity realised that we needed our own solution to the problem. We have engineered our own Software Development Kit (SDK). the Parity Solution Framework. This SDK not only delivers accessibility, it also provides a framework to address the key solution requirements – with multilingual capabilities at its core.

Initially, the Parity Solution Framework concentrated on Publishing sites only, however it has been extended into other areas such as document management systems.

What is the

Parity Solution Framework ?

The Parity Solution Framework is made up of a number of core of artefacts:

o Argo API (Application Programmers Interface)

o SharePoint Master pages, Page Templates & default features

In addition to the above there are some complementary tools that are used to expedite repetitive activities and accelerate development for example:

o Content Migration (from any external website into MOSS)

o Export/Import of Site Content (between MOSS web applications)

High Level Architecture

The following diagram illustrates how Argo is embedded within MOSS:

Key Design Principles

The Parity Solution Framework has been designed and built based upon industry standards and patterns. At its core the rendering engine overcomes the limitations that are inherent in the standard out of the box solution by providing developers total control over the implementation of look and feel. This flexibility is delivered through techniques which allow XML to be converted into XHTML using XSL. Since Master Pages (and hence the page template derivatives) are all based upon a pre-defined style (i.e. derived from the CSS2.0) we are easily able to re-skin a web application using the Parity Solution Framework approach and achieve cross browser compliance significantly less effort when compared with a more traditional approach.

Benefits

Although the Parity Solution Framework may be viewed as a “starter for 10”, it is more than that. The initial version provided an opportunity to rapidly build and deploy accessible publishing websites. Taking advantage of some of the key benefits including:

o Ability to re-skin the default site to rapidly prototype and develop customers solutions.

o Reduce time to market when provisioning a new web site

o Reduce costs for “out of the box” equivalent web sites

o Software re-use can realise savings up to 80%

o Standard, consistent mark-up and naming to simplify both development and support.

o Detailed and relevant documentation to help increase developers productivity

Standard Functionality

Although the Parity Solution Framework is constantly evolving and incorporating additional functionality the initial release contained the following standard functionality within the SDK:

o Support for Government metadata standards (Dublin core, egms etc)

o Search

o Advanced Search

o A to Z

o Sitemap

o FAQs

o Jobs

o Events

o Feedback

o Font sizing and colour scheme switching

Beyond Accessibility

Although a key driver behind the Parity Solution Framework was the need to meet accessibility requirements, the current implementation has gone significantly beyond this. A default search capability provides rich search options (for inclusion or exclusion of word combinations, free text and wildcard options), with support for scopes, multilingual and taxonomy based filtering.

The core API capability has been designed for extension upon provider models. This approach means that the default implementations for search and taxonomy, for example, can be extended to allow alternatives solutions to be incorporated with minimal effort.

For example a customer may have a classification system that is a variation of the Dublin Core meta data standard or the Integrated Public Sector Vocabulary (ISPV) – this can be easily substituted as the default Taxonomy model with out any recompilation or re-deployment.

Alternatively a client may want to use an alternative search engine such as FAST or Concept Search. The Parity Solution Framework API search provider model allows their seamless.

Next Steps?

Parity Solution Framework is evolving. Its code base is being used on development projects and is realising tangible benefits in terms of cost savings for both Parity and its customers. The component design of Argo has been built based upon extensibility and re-use – and we are already seeing examples of where this can be exploited. Enhancements will be made to the Parity Solution Framework by incorporating functionality as it is developed on projects increasing the capability of the core offering.

We are using the Parity Solution Framework to re-develop the parity website and intranet – so we are in fact, “eating our own dog food”.

Finally…

As the SharePoint wave continues many customers are beginning to realise that they need to make more investment to meet their compliance obligation and realise the benefits they expected.

Some organisations may not realise that the gravity of the situation and the extend to which they are not compliant.