Making MOSS accessible: a lost cause?

As an accessibility evangelist and someone from an open source background who fell head first into this new world of SharePoint and.NET programming I can tell you that this task is not for the faint-hearted. The effort required to make MOSS even remotely accessible (and I’m not just talking priority 1 and 2 checkpoints)is gargantuan.

To add to all the advice already given elsewhere, the most future-proof steps required to make your WCM sites accessible include:

1. Specify an XHTML loose doctype in your custom master. Caveats:
   • You can’t use a strict doctype without losing functionality (because non-compliant code will not render as expected, if at all).
   • You can’t specify a doctype in your system master without losing valuable functionality (Datasheet View and Image Library functions notwithstanding).
2. Rewrite all the layout code found in masters and layouts to be compliant. This is about the best start you’ve got. This includes:
   • Using custom CSS wherever possible. Delete built-in style calls and let your base HTML selector styles do the work.
   • Use custom ID selectors for layout to overwrite anything rendered by core.css. This also allows you to add all your skip link anchors and makes using a style switcher that much simpler.
   • Go as far as to remove the csslink tag in your master page if you’re really game and see what happens. I managed to reduce all native SharePoint CSS to 101 lines and call it last as an override.
3. Don’t use the MS Minimal Master. It fails to include useful (if not essential) placeholders.
4. Use Data Form Web Parts wherever you can.
   • Output for these can be controlled with XSL.
   • They don’t have to live within Web Part Zones.
5. Visit Heather Solomon’s site and grab her minimal master (infintely more usable) and the CSS cheat sheets can be invaluable.
6. Develop in FireFox first. FireBug is your new best friend. Then test in IE, use the Developer’s Toolbar, and add any ‘fixes’ to your CSS override.
7. Having gone to all this trouble the last thing you need is for your content editors to spoil all your hard work by pasting content from Word!
   • Get Telerik or a similarly standards-compliant editor.
   • Provide a Writing For The Web content editor’s guide which includes simple steps on producing nice, clean, legible copy.

Even after employing all the recommendations made here, at the end of the day you still have to accept certain limitations and realities. We have managed to come out of this exercise with accessible master pages (and some layout pages) but there is little control over content that is rendered at run-time. Everything I’ve found either re-writes the rendered code after the fact or just helps to bloat it in another way.

Much of the controls that make up a page use seriously flawed legacy code. If only all web parts included the XSL editor!

Last time I looked the AKS did little more than add summary="layout" and slightly deplete the concentric ring of nested tables that make up a typical page. And while the Telerik editor _produces_ compliant code, it’s my understanding that it is still rewritten at page load by the ASP render class.

Best piece of advice? Just keep hammering MS on the SharePoint forums and hope that future versions will one day get there. I use a number of aliases. ;)