eMusing

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. ;)

Labels: accessibility, MOSS 2007, SharePoint, standards

People seem to get so needlessly confused by this topic. I blame most of it on the lack of any reliable definitions.

Many articles discuss the use of InfoPath for this purpose - indeed even the option in the SharePoint UI for creating a custom template launches InfoPath! But unless your customisations extend to things that cannot be achieved OOTB it's actually so much simpler than that.

There are two fundamental pieces of information which can help explain all this and save you from a world of pain.

1. Your customisations to the Document Information panel found in the big-3 Office apps are made in SharePoint - not the target application.
2. The Document Information panel presented in documents created from a SharePoint library are nothing more than the fields defined in your content types (or an InfoPath form if you opted for this route).

If you're lucky enough to have InfoPath and feel like introducing more complexity then you can create a custom form to manage field validation and other advanced functionality.

For the rest of us, try the following:

1. Add a custom column or two to one of your Document content types.
2. Add the content type to a Document Library.
3. Click the New tab to open a new document (Word by default) and view the Document Information Panel. (Office Button -> Prepare -> Properties. You can also set this to open automatically in your content type settings under Document Information Panel settings .)

You should see all your custom columns. Columns marked with a red asterisk (*) represent mandatory fields. Yes, it's that easy.

Labels: Content Types, MOSS, SharePoint

This seems to be a topic that stumps even the most highly paid SharePoint experts but needn't. After all, the MOSS UI offers everything most enterprises would need, it's just a case of knowing where to look and exercising some not-so-common-sense.

Despite being called MOSS 2007, the base document content types actually use the old Office file formats. Confused? Yep, this is where most people get tripped up. The easiest way to replace these is to create a new document in each of Word, PowerPoint and Excel and upload them for each relevant content type under Advanced Settings -> Document Template.

This will provide you with a good base for any future content types that inherit from these.

DON'T save them as templates, as one might expect. Just as plain .docx, .pptx and .xlsx files. This is another common mistake.

These files will automatically get copied to the content type and every existing and new library to which it has been applied. If you're really curious you can verify this by looking in the hidden Forms folder within any library using the content type.

Labels: Content Types, MOSS, SharePoint

Despite the lack of a setting in the Site settings interface it can be done. It's been documented quasi-officially here and elsewhere but it's actually far simpler than most people make out. Instead of going to all the trouble of disabling and re-enabling the publishing feature, just navigate to the site you want to create the template from and append the following to the end of the URL: /_layouts/savetmpl.aspx Apart from saving time, the benefit of this is that your template will already have publishing features enabled.

Labels: MOSS, Publishing, SharePoint, Site Templates