Designing and developing accessible web sites on top of SharePoint 2007 gets more and more attention in the community. But the more developers try to reach the required accessibility or standards compliancy level, the more challenges they face and the more questions pop up. One of such questions is which doctype should be used for standards compliant and accessible web sites.

As for SharePoint 2007 the answer is simple

: XHTML - it is the only possibility. SharePoint 2007 is built upon ASP.NET 2.0: it makes use of the ASP.NET 2.0 runtime and enriches it with extra functionality. ASP.NET 2.0 has been designed to render XHTML output. Although the compliancy level can be set in web.config not all controls adjust their output to this configuration. Furthermore the runtime itself uses hidden fields for State Management: all these fields contains the ID attribute which begins with \_\_ (double underscore). Unfortunately such names are allowed only in XHTML so there is no chance for fallback to HTML 4.01 unless you want to rewrite the ASP.NET 2.0 runtime.

The choice for XHTML as the only possible doctype for ASP.NET 2.0 and SharePoint 2007 applications is quite odd knowing it’s the only doctype so far officially not supported by Microsoft browsers. According to the specification all XHTML pages should be served with the application/xhtml+xml mime-type. This allows the parser (no matter whether it is a User Agent or another information system) to process the file as if it was an XML document. None of the Internet Explorer versions can deal with the application/xhtml+xml mime-type. Microsoft Internet Explorer 6.0 doesn’t render the page at all and Windows Internet Explorer 7.0 renders it as an XML document. Although there are some tricks available to bypass this default behavior and you could vary the doctype depending on the User Agent requesting the page using content negotiation and browser headers, it would lead to serving two different content versions - both standards incompliant. Because of the ASP.NET 2.0 framework XHTML remains the only doctype allowing you to achieve standards compliancy.

Luckily XHTML pages can be served with the text/html mime-type known from the HTML 4.01 pages. All currently available Internet browsers parse XHTML pages correctly regardless of the mime-type. Even the W3C Validation service returns no errors during the validation of an XHTML page served with the text/html mime-type - not even a warning.

There are some major drawbacks for using the text/html mime-type with XHTML pages though. These are important particularly when you want to process XHTML pages by external information systems. In such situations the complexity of such documents arises as there are some workarounds required. One of the elements affected by the incorrect mime-type are the JavaScript scripts and CSS styles within the XHTML document which required additional markup for their comments. Using in-page script and style elements isn’t a best practice yet it’s definitely quite a plausible scenario.

Another major issue is the output produced by the authoring tools available in SharePoint 2007. The standard Rich Text Editor (RTE) produces output which is far from XHTML compliant. Even it’s well known substitute from Telerik can’t do anything about it as the generated markup (which is XHTML compliant) is being altered on saving by SharePoint 2007 runtime.

Knowing all this, the perfect choice would be the XHTML 1.0 Transitional doctype. Unfortunately some accessibility guidelines, among which the Dutch government guidelines (Webrichtlijnen: http://webrichtlijnen.overheid.nl), don’t allow you to use the Transitional variants. This has serious consequences for the authoring environment and the content presentation. Because the XHTML pages are being processed like XML documents, even the smallest syntax error will result in an XML error message instead of rendering the document. SharePoint 2007 standard authoring environment produces standards incompliant markup. Furthermore SharePoint 2007 doesn’t even allow you to use external tools as the markup is being modified on save anyway.

By eliminating the possible solutions we came to the presentation layer of SharePoint 2007. As it is highly customizable - especially in Publishing Sites - it seems almost a perfect solution. Well it is, almost. You can very easily encapsulate the required logic in a custom control. The downside is, you will end up cleaning the output on the run-time so caching the rendered page will be required in most environments.

Summary

As a developer of an accessible or a standards compliant web site built upon SharePoint 2007 you have to deal with multiple challenges. First of all you have to use the XHTML doctype. If you’re lucky you can apply the Transitional variant which will support you while dealing with the incompliant markup created by the SharePoint 2007 RTE. No matter if you use the Strict or the Transitional variant of XHTML you are very likely to need to do something about the markup generated by SharePoint 2007. As there isn’t much choice left you will end up with a custom control responsible for rendering the markup compliant with the the XHTML standard. It doesn’t seem to be the perfect solution but it works. Getting it done in a real life scenario will require a caching solution to suppress the extra load caused by content cleansing on the run-time.

Technorati Tags: SharePoint 2007, SharePoint, MOSS, WCM, Accessibility, Best Practices