Accessibility

I just got off a long discussion with Alex Hung about the WYSIWYAG mode. When presenting an existing entry in the Rich Text mode, ecto will parse the HTML and give a close as possible styling of the text. However, when switching from Rich Text to HTML mode, ecto has to parse the rich text and generate valid XHTML. At times, the product of this parsing may not give the exact code as the entry was originally formatted in. For example, take this text:

So I said

<br>

eh...

This will produce the following Rich Text:

So I said
eh...

When switching back, ecto produces XHTML:

<p>
blabla
<br />eh...
</p>

In other words, ecto already converts line breaks, and wraps the content in paragraph tags. Spurious whitespace is not retained either.

Alex is right in that it confuses the more experienced user, in particular those that know their HTML and like to use their way of applying tags. As another user observed, it's a tricky balance: Do I make the tool simple to accommodate new or HTML-wary users or do I load it all up with esoteric features so HTML-savvy users can use the Rich Text mode?

WYSIWYG is hard, that's a fact. When I set up to implement this, I used two reference points. One is Blogger's own WYSIAWYG editor that you will see if you use Firefox or other compatible browsers. It's a decent editor aimed for those users who prefer to write entries as is without having to bother with HTML tags.

The other reference point is W3C's Authoring Tool Accessibility Guidelines of which I list the following:

  1. Support accessible authoring practices
  2. Generate standard markup
  3. Support the creation of accessible content
  4. Provide ways of checking and correcting inaccessible content

What I'm trying to say is that, when implementing WYSIAWYG, the target group I had in mind were users who don't care what HTML their entries are wrapped in and just want to blog 'n go, but also the experienced users who want to quickly write an entry that does not contain fancy HTML. ecto's WYSIAWYG will produce the valid XHTML that you can make sure will be correctly displayed in a browser.

This means that the WYSIAWYG editor clearly is not the preview of the entry. The preview function is still there, but it relies on the HTML source and will produce a rendering by taking into account the blog's CSS style.

So, the end result is that ecto can be used in several ways:

  • set the default edit mode to HTML and use ecto like you used ecto 1
  • set the default edit mode to Rich Text and when necessary author the raw HTML directly in HTML mode
  • do all your entries purely in Rich Text

Your mileage proverbially and literally may vary.

The only thing I can see change is when MacOSX Tiger is released. This system upgrade will feature an improved WebKit (the engine behind Safari) that allows for direct editing into webpages. Applying this improved WebKit would mean a more powerful Preview in ecto, one which would reportedly give a 100% true WYSIWYG.

Even then, though, things remain tricky. As massless.org writes:

“Trying to handle the vagaries of the varied HTML expressions of internet content creators is somewhat like eating soup with a fork. There will be an early scramble to define a series of expressions that will match a set that a majority of users will find useful.”

In the meantime, I will work hard to further smoothen ecto's WYSIAWYG. I have only worked on it for 2 weeks, which really is quick, so bear with me for a while. This entry, for example, was authored fully in Rich Text mode after which I switched to HTML mode to apply the PRE tag to the code examples above and removed one spurious SPAN tag.

Posted by Adriaan on September 01, 2004