XHTML as a Horizontal Case Study

Steven Pemberton, CWI, Amsterdam and W3C
Chair, W3C HTML and Forms Working Groups
Editor in chief, ACM/interactions

The Horizontal Activities

XHTML 2

The aims of XHTML2 include:

• As generic XML as possible
• Less presentation, more structure
• More usability
• More accessibility
• Better internationalization
• More device independence (single authoring)
• Less scripting

In fact, many of these things are intertwined.

An Example: img

<img src="pic.gif" alt="Me, en route">

This was badly designed in three ways:

1. It wasn't backwards compatible: browsers that didn't know about <img> just showed nothing at that point.
2. It didn't allow for any fallback apart from the 'alt' text. In other words you can only use a type of image that all browsers understand (GIF or JPEG usually). This has seriously held back the acceptance of PNG images, which have far superior user-experience properties to either GIF or JPEG.
3. The alternative text is just plain text: you can't mark it up in any way.

Image Maps

HTML 2 had server-side image maps, that indicated that the image was clickable:

<img src="buttons.gif" ismap>

A problem with this is that the clickable areas were defined on the server, so the browser could give no feedback about where was clickable. For usability this was bad; for accessibility it was a disaster!

Later versions of HTML added client-side image maps, where the clickable areas were defined in the document:

<img src="buttons.gif" usemap="#buttonsmap">

This improved both usability and accessibility.

Long descriptions for accessibility

A facility that was added to HTML 4 was the ability to give a link to a 'long description' of an image:

<img src="temps.gif"
     longdesc="temps.html"
     alt="Average temperatures">

The problem with this solution is that hardly anyone uses it (it's inconvenient to use) and there is little browser support for it.

Fixing images

In designing XHTML 2 we decided to do away with a separate concept of an image altogether. Now we just say that there is an equivalence between an external resource and an internal one. For instance

<table src="temperatures.png">
<caption>Average monthly temperatures</caption>
<tr> <th>Jan</th> <th>Feb</th>....
<tr> <td>0</td>   <td>-4</td>...
</table>

A browser that can do images will display the image; others will display the table. Essentially we have moved the longdesc into the document.

This aids device independence, accessibility, and even usability.

Support for multiple types

The new image facilities allow for fallback:

<abbr src="w3c.png"
      title="The World Wide Web Consortium">
     <span src="w3c.gif">W3C</span>
</abbr>

But better still, the type attribute has been extended to mesh with the HTTP 'accept' headers:

<abbr src="w3c" type="image/*" title="...">W3C</span>

<abbr src="w3c" type="image/png, image/gif"
      title="...">
   W3C
</abbr>

Navigation lists

Web Content Accessibility Guidelines recommends using the client-side image map <map> element to indicate navigation blocks. XHTML2 introduces the navigation list:

<nl>
<label>W3C A to Z</label>
<li href="/WAI/">Accessibility</li>
<li href="/Amaya/">Amaya</li>
...

This gives accessibility, but also helps device independence (can use a menu on a small screen instead of a list).

Navigation lists also replace <map> for image maps.

Structure

The <h1> <h2> etc headers have long been an accessibility problem.

<h2>Chapter 1</h2>
...
<h3>Section 1</h3>
...

is now:

<section>
<h>Chapter 1</h>
....
   <section>
   <h>Section 1</h>
   ...
   </section>
</section>

Ruby, Whitespace

Ruby is a type of presentation used in East-Asian languages. Markup has been added to support this.

Whitespace behaviour used to be defined in both HTML and CSS. It has now been moved entirely to CSS.

Events

HTML events are a disaster

• For device independence
• For accessibility
• For authoring
• For document repurposing

Problems include:

• Device properties are encoded (e.g. onclick)
• Document structure and scripting are entwined rather than separated out
• Scripting language is hard-wired in document.
• Can't add new event types

XML Events

The new event mechanism is extensible for new event types and 'abstract' events can replace the old device-dependent ones (e.g. 'activate' instead of 'click')

It is independent of scripting language

You can entwine event markup in the document, or separate it out

<a onClick="...javascript..." ...>

becomes

<a ev:event="activate" ev:handler="#myhandler" ...>

Advantages: more types of events, other types of scripting (e.g. declarative), more device independence, more accessibility

XForms

Controls are device independent and accessible

Example Form Control

<input ref="/person/date">
  <label>Date of birth</label>
  <hint>Please enter your date of birth</hint>
</input>

A user agent has a default presentation.

If the user agent supports it, a stylesheet can be used to define other presentations.

Another example control

<select ref="icecream/flavors">
  <label>Flavours</label>
  <item><label>Vanilla</label>
        <value>v</value></item>
  <item><label>Strawberry</label>
        <value>s</value></item>
  <item><label>Chocolate</label>
        <value>c</value></item>
</select>

This example covers both radio-button style selection, and menu selection: not encoded in the control.

A current problem: Frames

As an example of poor usability, current frames are a disaster!

• The [back] button works unintuitively in many cases.
• You cannot bookmark a collection of documents in a frameset.
• If you do a [reload], the result may be different to what you had.
• [page up] and [page down] are often hard to do.
• You can get trapped in a frameset.
• Search engines find HTML pages, not Framed pages, so search results usually give you pages without the navigation context that they were intended to be in.

Frames continued

• Since you can't content negotiatiate, <noframes> markup is necessary for user agents that don't support frames. Search engines are 'user agents' that don't support frames! But despite that, almost no one produces <noframes> content, and so it ruins web searches (and makes builders of such sites look stupid!)
• There are security problems caused by the fact that it is not visible to the user when different frames come from different sources.

Currently devising XFrames, a replacement for Frames.

Conclusions

Device independence, accessibility and usability are surprisingly closely related.

Even though website builders may not yet know it, device independence, accessibility and usability have a major economic argument in their favour. Spread the word!

More information: www.w3.org