W3C Validator for SharePoint 2007

SharePoint 2007 is a very extensible development platform. Thanks to its flexibility the developers keep coming with new features which extend the user experience. One of the areas where the things are still missing is the Web Content Management: accessibility in particular leaves plenty of challenges to be tackled and features to be added by the accessibility enthusiasts and developers. One of these is the W3C Validator for SharePoint 2007.

As I’ve mentioned some time ago we are busy here at Imtech ICT Business Solutions designing, developing and testing our own accessibility toolkit for SharePoint 2007. As the whole solution works perfectly I have started looking for some other ideas on how to extend it and enrich the editors’ experience. One of the ideas I’ve got was incorporating the W3C Validator support into SharePoint 2007.

First of all the requirements. As it’s supposed to be editors’ tool it needs to reside on the Publishing Console. It’s supposed to validate the page: preferably before it’s published so an editor can correct his mistakes if any found. Then the report: embedded into SharePoint 2007 or just a redirect? As embedding might enhance the total experience it would require you to provide new versions of the SOAP response parser (as the response you get from the W3C Validator is in the SOAP 1.2 format). Because most of the people dealing with accessibility and standards compliancy are familiar with the generated output that’s the approach I have chosen.

As our toolkit targets the Dutch standards you might be asking why we haven’t chosen for that one. Well, the Dutch Quickscan supports URL’s only. And because one of the requests was validating the page before actually publishing it it’s a no go unfortunately.

Completing the first step was quite straight forward: simply edit the CustomQuickAccess.xml file. The provisioning of such an alteration is slightly more challenging as the XML file is being provisioned by one of the Publishing Features and you are not allowed to replace during the provisioning a file provisioned by another Feature. And still, even if it was allowed, it wouldn’t definitely be the best practice as the file can already contain other buttons. Replacing the file would remove them from the Publishing Console. Luckily I have done this before and could reuse a method I wrote which is comparable to the WebConfigModification method but then allowing me to edit any XML file.

The validation process turned out to be the most challenging of the whole solution. Looking back at the requirements you will notice that I mentioned validating the page before actually publishing it. Posting the complete page which can contain the Site Actions menu, the Publishing Console and more of the inaccessible items which are required for the proper working of the editors area is unfortunately a no go. Taking this into consideration leaves you with two possibilities.

First of all I’ve been thinking on iterating through the collection of fields available within the Content Type of the requested Publishing Page. Obtaining the values and making a new HTML page of them would be an option. The biggest downside of this approach is that you skip the rendering part of the value: remember once stored value can be displayed in many ways within a Page Layout using various Web Controls and Web Parts. Querying for a value is unfortunately not enough as it passes that stage of rendering and doesn’t check whether a control alters the value making it inaccessible/incompliant. So then I came up with another approach.

If you take a look at the client-side DOM accessible by JavaScript you can see that you are able to obtain an element iterating through the DOM nodes or using for example the element’s ID. Using this approach would allow you to query the page as it is (including the SharePoint menus and toolbars) and then simply pick the content within the given element and send it to the W3C Validator. That led me to a new requirement: be able to set the ID of the content wrapper. We are definitely going to reuse this feature in other projects and because we work with different designers we need to have the possibility to configure this property. Realizing this task was not really difficult using the Ted Pattison’s best practices for developing application pages. As this feature would eventually make part of our compliancy toolkit I have decided to extend the configuration page we already have.

Then again, validation itself using server side DOM. Using the resources available within the .NET framework you are left with the MSHTML assembly if you want to use some DOM features in your .NET code. It does work, but you need to fix its interpretation of your document as it alters it stripping for example quotes from some attributes. Another challenging part is getting the instance of an HTMLDocument. In a Windows Application you would use an instance of the WebBrowser to do this, but does it remain the only way even if you have nothing to do with System.Windows.Forms and all you want is a plain instance of HTMLDocument? Luckily it isn’t. But let me leave you something to research.

Anyway, with the content of the rendered page accessed using server-side DOM, it was the time to send it to the W3C Validator to get the results.

Instead of choosing for the immediate redirect to the W3C Validator I have put another application page between: just to have a status view and to be able to catch any exceptions or errors the validator could have encounter while obtaining the requested Publishing Page and parsing its content.

The whole concept works pretty good. The user is being redirected to the W3C Validator and can precisely see what the reasons of the problems are if any found. In our case: 100% valid thanks to Imtech SharePoint Compliancy Toolkit.

Incorporating the W3C Validator for SharePoint 2007 in SharePoint self we hope to enhance the editors’ experience and make the editing of compliant content easier by allowing them to validate the content they have entered way earlier in the editing process. I hope that I have given you a little idea on how the SharePoint 2007 environment can be extended to make it more user-friendly.

The W3C Validator for SharePoint 2007 is a part of the Imtech SharePoint Compliancy Toolkit. The other ideas I have mentioned? Well, these will follow pretty soon.