bestkungfu weblog

Web authoring tools and validation

Filed in: accessibility, Web, Tue, Aug 3 2004 14:10 PT

Tim Bray has a beef with Web authoring tools. And he’s got friends. In a post called “Authoring Pain,” he cries out for a tool that manages to produce valid content:

The state of Web authoring tools is kind of like the state of what we used to call “Word Processing” twenty years ago when I was getting into this business. If everyone’s going to write for the Web (and it looks a lot of people are going to) we need the Web equivalents of Word Perfect and Wordstar and Xywrite and Microsoft Word, and we need them right now. The Atom protocol will give them a standardized way to push the content online, and the fact that it’s all open formats will make it real hard for a monopolist to scoop out the market. So, who’s building them?

This touched a nerve with a number of people, including Jonathon Delacour, who adds:

I’m an advanced content creator who, like Tim Bray, wants the convenience and ubiquity of browser-use together with the advantages of a feature-rich client.

I have feature rich clients coming out of my ears: Microsoft Word, Dreamweaver, TopStyle Pro, CSE HTML Validator. My current workflow is:

  • Write the entry in Microsoft Word (the outliner is passable, the spell check is useful, I love Document View, and it’s easy to add hypertext links).
  • Copy and paste the text into Dreamweaver, where I do the more complex formatting.
  • Validate Dreamweaver’s XHTML with CSE HTML Validator.
  • Paste the validated XHTML into Movable Type’s blog entry text area.

This is, frankly, bullshit. And, I’m beginning to think, part of the reason that lately I haven’t been posting more frequently—writing an entry of even moderate length is unnecessarily painful.

Why can’t Tim and I have a decent WYSIWYG browser-based editor? Or, speaking for myself, even a standalone application with the features I’ve listed?

Well, I have good news, and bad news. The good news is that the functional specification for a tool that creates, repairs and shepherds valid content through the authoring process has already been written, and has been out for four years.

The bad news is that nobody has claimed conformance to it in that time.

Don’t let the A-word fool you. The Authoring Tool Accessibility Guidelines 1.0 Recommendation spends much of its detail on ensuring that content is made, and remains, valid. That’s a key element of Web accessibility, in that it lets assistive technologies spend less time guessing (often wrongly) at what the author intended. There’s an entire guideline dedicated to the production of valid content, along with a set of implementation techniques for getting valid content.

And, of course, some stuff about, you know, prompting for alt text, using device-independent events in script, separating structure from presentation, checking for and repairing accessibility problems, and making the tool itself accessible to authors with disabilities. All good stuff. All stuff everybody who creates content should have as part of their authoring process, but often don’t because the tools get in the way. All stuff that should just be there by now.

I’ve talked to dozens of authoring tool developers since I started at the W3C. Usually, when I bring up ATAG, They’ve been somewhere between noncommittal and dismissive of the needs of users to have valid, accessible output. Especially relative to the development effort necessary to do it. (Hmm. A pattern.) They say they don’t have enough interest from their users to act.

To paraphrase Jonathon: this is, frankly, an opportunity for evangelism. ATAG is your friend. And it needs to be implemented in the full range of authoring tools, from code-based environments to WYSIWYG tools to inline editors to word-processor conversion tools to multimedia production environments. We have a techniques document that covers each category in detail.

But nothing is going to change in this space until users get together, point at a target, and say “go.” The field of Web authoring tools is evolving past the point where looking good in IE and Netscape is the only sign of quality. Valid content is a must for modern designers. Accessibility is a must for corporate responsibility. Tools must work with the user to meet those needs. And eventually, when their developers get a nudge from frustrated users like these, they will.


4 responses to “Web authoring tools and validation”

  1. karl dubost says:

    I don’t completely agree with John Delacour and Tim Bray, I guess I’ll have to explain why… on my Weblog. But there’s something which is missing in their reasoning. Structure editing and visual editing don’t work together.

  2. Jens Meiert says:

    Unfortunately, it’s not only about offering one tool which produces valid and accessible content, but it’s also important that the source code is semantic and the interface is usable […].

    And remembering that there still (and of course) are several problems in automatically assessing and improving a site’s level of accessibility, it currently seems unrealistic that a tool also generates semantic code and provides enough assistance to create an usable interface.

  3. La poutre dans ton oeil
    Authoring Pain ou illusions : Il est amusant de lire certains sujets récurrents sur le Web, cela ne diminue pas forcément leur intérêt, mais le retour des mêmes arguments et des mêmes illusions a toujours le don de me surprendre….

  4. Although, the artificial intelligence has immensely moved forward, it still cannot replace human brains. It’s a good thing to have a content validator and use its results. But be skeptical and rely on your human knowledge.

Powered by WordPress (RSS 2.0, Atom)