Web Parts accessibility limitations in MOSS

The support of accessibility (WCAG 1.0) in Web parts on pages in MOSS is limited. Stay with ASP.NET controls and leave the Web parts until your users really need that personalization functionality. When they do you can add personalization support and start using the WebPartZones in MOSS, and accept the accessibility limitation. This article outlines these limitations and discusses some consequences.

The WCAG standard

The W3C standard “Web Content Accessibility Guidelines 1.0 (WCAG 1.0)” ( http://www.w3.org/TR/WCAG10 ) covers a wide range of issues and recommendations for making Web content more accessible. The document 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, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, photosensitivity and combinations of these. Following these guidelines will also make your Web content more accessible to the vast majority of users, including older users. It will also enable people to access Web content using many different devices - including a wide variety of assistive technologies.

What is Web Parts?

Web Parts are server-controls (portlets) that can be placed on a web page where the end-user is given the possibility to edit content, appearance and behaviour of the portlet directly from within the web browser. By integrating Web Parts into web pages using WebPartZones and WebPartPages in MOSS, the end-user can also add, remove, move around, maximize and minimize WebPart-portlets. When the end-user make changes to these portlets or pages, the changes can be saved and reused in later browser sessions.

The big advantage with web parts is that it gives the end-user the possibility to personalize the content of a web site dynamically without the involvement of an administrator or a developer. It is also possible to import and export personalized WebPart-settings between different pages and sites. ASP.NET 2.0 has built-in support for WebParts. Basically, WebParts in ASP.NET are common server controls, but with the difference that it has support for personalization through the WebPart-interface. To get the full potential out of Web parts (that is, the personilazation functionality), the Web parts one must put the in a WebPartZone using a WebPartManager store and retrieve personalization data to a database (a MS SQL Server or Sharepoint Server) is also required. One can also put a common ASP.NET server control in a WebPartZone. These control will in that case be wrapped in a GenericWebPart-contol.

Accessibility limitations when using Web Parts

The implementation of WebPartZones in MOSS is hardcoded (unlike the corresponding classes in IBM Websphere. They are just as poorly implemented, but at least open to rewrite as you please) and doesn't support the accessibility guidelines on a number of instances:

• WebPartZones uses HTML tables for its graphical design whitch breaks the 5.3 guideline in WCAG 1.0.

• WebPartZones does only support only personalization if You use javascript, which breaks guideline 6.3 in WCAG 1.0.

• At the time of writing, the rich user interface of Web parts only works with Microsofts own web browsers:
  - WIN IE 6.0 and above
  
  It doesn’t work very well in the following browsers:
  - WIN Firefox 1.5 and above
  - WIN Opera 9 and above
  - MAC Safari 2.0 and above
  - MAC Firefox 1.5 and above
  - MAC Camino 1.0 and above
  - Linux Firefox 1.5 and above
  - Linux Konqueror 3.4 and above
  
  This breaks the guideline 6.4 in WCAG 1.0. This means that pages that uses web parts will be hard to use in other browsers other than Internet explorer. The pages will not be adapted to mobile user interfaces and devices used by for instance vision imparired people.

A WebPart can also run outside MOSS and works in this scenario like any other ASP.NET server control. It may not rely on personalized data. I can, however, not see any advantage in developing controls as Web parts instead as web controls unless they are going to be used as personalizable portlets in WebPartZones.

PS. This article partly builds upon the work of Martin Odhelius.

@Copyright 2007, Tomas Elfving