I think it's important to add that developers looking to make sites such as team sites (WSS workspaces) accessible, will not achieve it. It is also virtually impossible to make any type of application pages accessible without moving your SharePoint environment out of Microsoft support. Any type of page where a user edits documents, uploads documents or performs any type of administration cannot be made accessible. To make an accessible web site that meets any international standards, you can only use the publishing site and then you really need to start from the ground up with a new master page. Be careful too about training your content authors, a page accessible today may not be tomorrow if the toolset available to content authors means the required standard will be lost.

Contrary to the previous statement from Kezoe, you can achieve an accessible collaboration portal, but it does take a lot of effort, and you don't have to make your environment "unsupported" to do so.

I have been working with a team at Content and Code (www.contentandcode.com) who have just released a fully accessible collaboration portal (including document upload, discussion boards, custom lists and even accessible back-end administrative pages) for the Royal National Institute for the Blind, to WCAG 2.0 standards and we are now working on further projects in accessibility including a potential accessibility framework.

The main thing is that you have to have a very deep understanding of how SharePoint works in order to create a full accessible environment, and the effort involved (and the calibre of resource you will need to achieve it) does not come cheap or easy.

SharePoint RenderingTemplates are probably the most vital step in overriding the OOB user interface, allowing you to swap out large portions of the rendering markup through supported methods. For some of the other in-accessible interfaces (Date Time Control, Multiple Lookup ... I'm looking at you!) you can also override using Control Adapters.

Obviously the surrounding layout markup and CSS can always be achieved using your own ASPX pages, master pages and CSS.

The most important aspect is that you stick to supported methods and technologies to achieve this, and there is plenty of flex in the framework to do it.. you just have to know every single step that SharePoint goes through to generate those pages!

If you do decide that you must replace an out of the box page ("Access Denied" is a classic) then make sure you use something that can be switched on and off (such as HttpModules or control adapters) as this allows you to easily "roll back" your customisations, allowing the original functionality to shine through (and putting your solution back in a "supported" state)!