bestkungfu weblog

(This is kind of artificial, me blogging my own XML session, but at least everybody knows I’m not going to disagree with the speaker. I thought he was very well-dressed.)

I gave a basic overview of the Web Accessibility Initiative, what we produce in terms of guidelines, education and specification review. (I left out the Protocols and Formats paper on CAPTCHA, because I’ll be presenting on that at CSUN, and I’d hate to have nothing to talk about between now and then.)

I did a quick introduction on the Web Content Accessibility Guidelines, and how it’s been adopted by governments and corporations around the world. I then focused on the range of authoring tools, including conversion tools, WYSIWYG tools, multimedia tools, and, of course, CMS. I said that the one I’ve been highlighting everywhere I’ve been speaking this year has been CMS, given the comparatively large quantity of content locked up in them, and the relatively few templates that could be made accessible. (Yes, blogging software developers, I’m talking about you in the set of content management system vendors.)

The Authoring Tool Accessibility Guidelines 1.0 document has been a W3C Recommendation since the end of 2000. Conforming to ATAG indicates that the tool has done just about everything a tool can do to ensure the corresponding level of WCAG conformance. It breaks down to four categories for CMS vendors and developers to focus on:

Accessible content

Valid content is the starter. Valid’s good. You should be valid. And semantically-rich, too: screen readers and other assistive technologies understand and represent lists to users meaningfully. But if you’re just doing line breaks between links, you’re probably already broken. CMS tools should know how to fix common accessibility problems as they arise. But they should also be smart enough not to strip out markup it doesn’t understand. That’s been a problem with lots of tools to date, and has resulted in lots of wasted effort.

Accessible collateral

Most CMS products have databases for binary content (images, video, etc.), and that kind of data store needs to have room to attach, retrieve and edit metadata. Capture alt text on images, but don’t tie them one-to-one to the image. Sometimes, images mean different things, and users should be able to represent that to the user at will.

Accessible templates and documentation

Guide the user with your educational and bundled content. Anybody who’s designed a system that comes with templates knows that lots of users leave most of what’s there in place when they develop on top of it. (Submitted for your approval: most Movable Type blogs.) If the templates are inaccessible, not only did you break potentially thousands of sites, you don’t get to pull it back. And worse, your template is now considered to be best practice, so even as people evolve, they’re still apt to screw it up based on your example. Fix your broken markup before you ship. Then, in your documentation, point out the accessibility-related features of your publishing process, and make sure all of your code samples implement good accessible design.

Accessible interface

Did you know that people with disabilities even write Web content? It’s true! The interface to your CMS’s business end needs to be accessible to users with disabilities, too. When dealing with ActiveX, Java, or script-based HTML editing tools, make sure that users with script turned off can add or manipulate content. Make sure that your JavaScript calls don’t infect the href attribute: put that stuff in the events, and link to usable content with the href. If the CMS has a Web interface, it should conform to WCAG. If it’s standalone, it should conform to the accessibility guidelines of its host operating system. Every major windowing system has a list of guidelines for accessibility. Use ‘em. They’re good for you, and they just may make you rich.

It was a fun session. I also do weddings and bar mitzvahs, and if you have a roomful of interested developers, who knows, maybe I’ll come to your house or place of business. Especially if it’s in Hawaii. Please, let there be a cache of authoring tool developers in Hawaii.

My slides are public, as is the paper on accessible content management systems I wrote for the conference.

Special thanks to Tim Bray for lending me the stupid DVI-to-VGA adapter I always lose when I go out giving presentations.