dive into mark

Joe Clark: Flash MX: Clarifying the Concept. An in-depth look at the accessibility features of Macromedia’s latest revision of Flash. It makes the point that Section 508 is what is driving these features. Section 508 is a U.S. federal law that, among other things, mandates that all federal web sites meet a minimal set of accessibility guidelines. (Flash 5 met virtually none of them.)

Macromedia has taken serious steps to fix [Flash's] accessibility deficiencies. There’s still a lot that’s missing, but Macromedia is aware of nearly everything that needs to be done and will presumably fix it all. (They have no choice, really, if they want to keep the U.S. government as a customer.)

… That’s the real reason Macromedia is going to all this trouble. It is also true that the company now believes accessibility is the right thing to do for all the usual ethical and business reasons, but the inciting incident was the prospect of permanently losing U.S. government sales.

Furthermore:

As it turns out, accessibility is much more sweeping than it appears on first blush. Two categories of software — programs used to create websites, and browsers — must themselves be accessible. It’s not enough for data (like a .html or .swf file) to be accessible; all the software you use to create, view, browse, or enjoy those files has to be accessible, too. In the Web Accessibility Initiative terminology, this is known as authoring-tool and user-agent accessibility.

I was trying to make this point several months ago during the great CSS-versus-tables debate (see Moral Arguments Aside), but it got lost in the general chaos and confusion and accusations of zealotry. So here is the same point again, from the article, put as simply and unzealously as possible:

It is not widely understood that 508 regulations have been in effect and enforceable since June 21, 2001. They’re not coming down the pike; they’re here already. In practice, there is no actual enforcement; we are living in a kind of grace period. But the requirements eventually will be enforced, and noncompliant products could not be bought by the U.S. government thereafter.

For those who are curious about what constitutes an “authoring tool”, the W3C lays it out for you in the Authoring Tool Accessibility Guidelines 1.0:

The term “authoring tool” refers to the wide range of software used for creating Web content, including:

• Editing tools specifically designed to produce Web content (e.g., WYSIWYG HTML and XML editors);
• Tools that offer the option of saving material in a Web format (e.g., word processors or desktop publishing packages);
• Tools that transform documents into Web formats (e.g., filters to transform desktop publishing formats to HTML);
• Tools that produce multimedia, especially where it is intended for use on the Web (e.g., video production and editing suites, SMIL authoring packages);
• Tools for site management or site publication, including tools that automatically generate Web sites dynamically from a database, on-the-fly conversion tools, and Web site publishing tools;
• Tools for management of layout (e.g., CSS formatting tools).

So that would certainly include Macromedia’s Flash authoring tool, as well as HTML authoring tools like DreamWeaver and FrontPage. Oh, and every weblogging tool on the market, open source, freeware, or commercial.

Here is the W3C’s list of priority 1 checkpoints (”tool must satisfy all these requirements”) for web authoring tools, and how I interpret them to apply to weblogging software:

1. “Ensure that the author can produce accessible content in the markup language(s) supported by the tool.” (Weblogging tools that allow editing of all underlying HTML templates and allow entering HTML content directly would be in compliance. Tools that have uncustomizeable templates, or partial templates like auto-generated calendars, or that do not allow entering HTML content directly, would need to make sure that their auto-generated content was already accessible. The point of these guidelines is not to make software vendors do all the work (in fact, in some cases it precludes them from doing work, see below), but to make sure that the software doesn’t stand in the way of the user who wants to use the tools to make accessible web sites. So raw HTML editing is good enough, but inaccessible uncustomizeable templates are out.)
2. “Ensure that the tool preserves all accessibility information during authoring, transformations, and conversions.” (This applies not only authoring original content, but also importing content. Tools like Radio which aggregate news and allow the author to repost it would need to make sure they don’t lose any information in the process, like title attributes on links in the reposted content.)
3. “Ensure that the tool automatically generates valid markup.” (All auto-generated content must validate. Also, all proprietary markup formats must have published DTDs so that content in these formats can be validated. Note that this does not force you to use the latest HTML or XHTML; even very old HTML can validate, as long as its DOCTYPE is defined correctly, and HTML 4.01 Transitional is an extremely forgiving specification.)
4. “Do not automatically generate equivalent alternatives. Do not reuse previously authored alternatives without author confirmation, except when the function is known with certainty.” (No auto-generated ALT tags on images! This one surprised me, but it makes sense. There’s really no way to automate useful text alternatives; the author needs to be responsible for this themselves. The tool can make this easy or hard, but it can’t automate the process.)
5. “Document all features that promote the production of accessible content.” (Documentation is essential. That’s why I have an accessibility statement. Weblogging tools should have one too. Furthermore, all documentation must itself comply with at least the priority 1 checkpoints of the Web Content Accessibility Guidelines 1.0.)
6. “Allow the author to change the presentation within editing views without affecting the document markup.” (Switching between WYSIWYG mode and raw HTML mode can’t lose information. Some weblogging software allows this, using Microsoft’s WYSIWYG HTML editing form, so this checkpoint would apply to them.)
7. “Allow the author to edit all properties of each element and object in an accessible fashion.” (I believe that any tool that allows raw HTML editing would comply with this requirement, again with the caveat that all HTML templates for auto-generated content must be customizeable.)
8. “Ensure that the editing view allows navigation via the structure of the document in an accessible fashion.” (For web-based editing tools, this means using the accesskey attribute in editing forms.)