The “UK Accessibility Roundtable for Microsoft Office SharePoint Server 2010″, a HiSoftware event at Microsoft’s offices in London Victoria. The day revolved around several demos of SharePoint 2010 and Compliance Sheriff, and was fleshed it out with some quite good accessibility information. These are my notes on the event, with a lot of interspersed commentary.

A simple rule for good web sites: content is golden. In an accessibility context, structured content is golden. It a core responsibility of the site owner to ensure this is followed (not just the developer). When you examine this issue, you can then understand why few organisations will ever produce accessible PDFs.

After the 10 previous posts on WYSIWYG editors, I have compiled all the ‘tips’ into a checklist of things to look for in an editor. At this stage, I’d like to ask for any comments, questions or criticisms before I start applying it to editors.

If the editor has followed the earlier HTML and CSS guidelines, many accessibility issues have been avoided already. This post is essentially a list of things a WYSIWYG editor could do to help authors not create accessibility barriers.

The accessibility of the interface is just as important as the accessibility of the code the editor outputs. The key aspects to focus on are the ‘perceptability’ of controls (e.g. alt text) and ease of using a keyboard only.

Having cut down what authors can use, they can just about edit regular text articles. However, I haven’t met many clients who would be happy with just that! There are certain things that require the addition of code, this is how to do it.

Each of the editors I’ve been looking at allows the addition of tables, but none of them allow the easy insertion & manipulation of a data table, i.e. one with headings. I deal with data tables quite a lot for windsurfing results, and the only program I’ve found for decent table editing is Dreamweaver.

Adding images in an easy and accessible way is a vital part of a modern WYSIWYG editor, and one of the things the almost all of the implementations I’ve come across get wrong. There are several levels of implementation, from adding images from other locations, to creating and choosing from a library of images and other assets.

With a WYSIWYG interface, there has to be an area that appears as it will when published, which means to change bits within it, you need one or more toolbars. This is an exploration of what those toolbars should do.

The second building block of a modern WYSIWYG editor is how the styles are defined and added. Styles should be applied by class to standard HTML, but what kind of import methods would be best, and how would they surface in the interface?