Accessibility : Accessibility Kit for Sharepoint

There is this tool (? add-on?) exists. But after all it did not help much.

You find a couple of things in the package but we were only interested in what they call HCCE (HiSoftware Compliant Code Engine) and WebZonePart controladapter.

The HCCE is nothing more than a custom base class for Page Layout, and what it does is simple string replacements.
For instance, MOSS Publishing feature generates <SCRIPT> in its output HTML, which violates XHTML. It has to be <script type=”text/javascript”>.
It does this, the replacement in the output. But only if you specify it, exactly as above, one by one, in its config file.
So it is not like, it does the work if you say you want to “comply” to XHTML, or HTML. “Compliant Code Engine”… Funny..

And the other cr*p, WebZonePart controladapter, it is a controladapter. So as you know, it replaces with table with div.
By default, MOSS generates lines like below for each webpart on the page. Of course it all violates standard.
<td id="MSOZoneCell_WebPartWPQ3" orientation="Vertical" name="MSOZoneCell" relatedWebPart="WebPartWPQ3"…

The adapter replaces those with divs. Sounds nice. But my problem was that it does not produces title and border of the part even if you configure you want them.
Luckly, the package contains the source (not for HCCE. HCCE comes only as binary (of debug build…)). So I managed to have them back.


What still remains not OK are those XHTML not compatible codes generated mainly by Rich HTML editor.
The HCCE’s static string replacement does not do anything for this. Here you want to replace, for instance border=0 with border=”0”. And there could be border=1, or 2, or 3, you never know…

For this, I did not find any turnkey solution. However, I found a guy who solved the similar problem in a different CMS by plugging-in a httpmodule of his own.
http://www.codeplex.com/compfilter4umbraco
He uses this library http://www.codeproject.com/KB/dotnet/apmilhtml.aspx , for basic clean-up of markup.

I was not sure if I can plug-in a httpmodule to MOSS, but since I did not have any other more promising alternative, I gave it a try. And voila, it works!!
For the module, I created it from scratch. I did not need any of logics placed specifically for the CMS. Quicker to build one from scratch than to remove those.
But the library, thanks to the author, I did use it, although I changed it a bit.

The challenge I had was that, at the beginning I had all page go thru this filter. It screwed up things.
So, in the end, I made it so that it cleans up only contents, not part coming from masterpage. That works. This is where the rich editor generating codes appear.

Accessibility : XHTML or HTML

The first step for an accessible site is conformance to a standard. A colleague of mine who closely follows this subject told me. It can be XHTML or HTML. Does not matter much as far as we conform to one, he added.

Please contest me if I say something stupid, but in a word, a site created using MOSS 2007 Publishing Feature does not conform to none of the two. You can not configure it to. You have to customize it.

It is based on ASP.NET 2.0 which I believe supports XHTML more than HTML.One of the places that you clearly see it is that it inserts lines like below, which violates HTML scheme.

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />

And you can not configure it to stop doing so.

OK. Let us go for XHTML then. But, thank you MS! It violates it too...
You can see it quite easily, just by inserting an image using its Rich HTML Editor. It generates a line like this.

<img border=0 ... >

Actually, I have the impression that MOSS Publishing feature is designed(?) to create HTML sites. Its OOTB masterpage files have got HTML doctype declaration.I really do not understand why it comes out like this...

Anyway, after having tried both, I saw going for XHTML should be a realistic solution, and started customizing it.

In a couple of posts after this, I would like to talk about the series of tricks that I employed.