Usability, Accessibility and Markup

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

A Thought Experiment

What are the features of websites that you go back to regularly, that differentiate them from websites with the same purpose that you don't go back to?

Differentiating features

Forrester did some research on this:

Differentiating features

Forrester did some research on this:

Differentiating features

Forrester did some research on this:

Differentiating features

Forrester did some research on this:

Differentiating features

Forrester did some research on this:

Differentiating features

Forrester did some research on this:

(the rest is noise: 14% and lower)

How do you justify accessibility?

If there are good economic reasons for supporting usability, how about accessibility?

The Kiss of the Spiderbot

"Google is, for all intents, a blind user. A billionaire blind user with tens of millions of friends, all of whom hang on his every word. I suspect Google will have a stronger impact than [laws] in building accessible websites."

...

"In a world where Google likely has a valuation several orders of magnitude higher than any chrome such as flash, graphics, audio, interactivity, or "personalization", I see a heady revision."

Karsten M. Self

This is not just theoretical; a major Dutch bank has reported that its Google visibility shot up once they made their site accessible.

Designing for Usability and Accessibility

It is possible to design markup for usability and accessibility.

For instance HTML 2 had 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 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" map="#buttonsmap">

This improved usability, but also accessibility.

HTML is a mess!

Rather than being designed, HTML just grew, by different people just adding stuff to it.

There are three versions of classical HTML:

  1. Loose/transitional, which is just a garbage can of whatever anybody fancied adding to the language before it got transferred to the W3C, and in particular is full of accessibility problems.
  2. Frameset, which we know is a walking talking usability disaster.
  3. Strict, which is the closest we could manage at the time to the HTML we really wanted.

The XHTML Family

XHTML is a family of XML-based markup languages being designed.

Currently it consists of:

Example of XHTML running on a phone

An XHTML site from 1999 viewed on a mobile phone

There are more browsers on phones now than on desktops

5 Japanese women browsing the web on their phones while waiting for a train

The Design of Notations

There is an amusing platitude that goes "A camel is a horse designed by committee".

This is of course an insult to camels, which are perfectly designed for their environment. You just trying putting a horse in a desert and see what happens.

Something that wasn't designed by a committee as it happens is the <img> tag in HTML. This element specifies an image for inclusion in a page, and has the form

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

The (bad) design of <img>

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 to make it italic or whatever.

An alternative design

If <img> had been designed well, firstly it would be called <image> (contractions are OK, but there's no need to overdo it: why <img> when you have <blockquote>?), and secondly it would have a fall-back possibility like this:

<image source="pic.png">
    <image source="pic.gif">
        Me, <em>en route</em> for France
    </image>
</image>

This would display a PNG graphic if the browser knew about them, otherwise a GIF graphic, and if all else failed (or images were turned off) the marked-up text. Browsers which have never heard of the <image> tag would still display something sensible.

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 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.

This aids device independence, accessibility, and even usability (since if the image is unreachable the document is still useful.)

XHTML 2

The new member of the XHTML family is in our minds the real XHTML.

Our aims are:

In fact as I will show, many of these things are intertwined.

Aim: Generic XML

By 'generic XML' we mean: if a facility exists in XML technologies, and it is suitable, use it and not a special-purpose XHTML facility. Try to get missing functionality added to XML. Examples:

Major missing functionality: Linking (XLink insufficient for XHTML's needs).

Advantages: less variability; more interoperability; much of XHTML 2 works already; opportunity to make a cleaner break.

Aim: Less presentation

Remove all presentation-only markup.

Use stylesheets to define presentation.

Advantages: possible to author once, and display on different devices; better presentation possibilities; device presentation not hardwired; CSS has support for devices; more accessibility.

The power of CSS is currently seriously underappreciated, but gaining ground.

(Note: doesn't require CSS to be implemented; just uses its model)

Separating Content and Presentation: Author Advantages

Separating Content and Presentation: Webmaster Advantages

Separating Content and Presentation: Reader Advantages

Separating Content and Presentation: Implementor Advantages

Aim: More structure

Add more structure-oriented markup to make documents richer.

Examples: <l> element instead of <br>. <section> and <h> elements instead of <h1> <h2> etc

Not

I think that I shall never see<br>
A poem lovely as a tree

but

<l>I think that I shall never see</l>
<l>A poem lovely as a tree</l>

Advantages: more presentational opportunities (folding, marquee, numbering) [More shortly]

Aim: More usability

There are two principal 'users' of XHTML:

A current problem: Frames

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

Frames continued

Currently devising XFrames, a replacement for Frames.

Another current problem: Forms

More on this later.

Aim: More accessibility

"Almost every site I go to fails my three-second accessibility test - increasing the size of the type."
Steve Krug, in Don't Make Me Think (2nd edition)

One day we will all be grateful for accessible websites.

As an example of a current problem: <h1>, <h2> etc are mostly terrible for accessibility, because no one uses them right, and it is hard to work out document structure from so little information.

Usability and accessibility are often closely related

For example, as already pointed out, client-side image maps compared with server-side ones:

Client-side image maps give better usability by allowing feedback to the user about where is clickable, and where a click will lead to.

But they also give more accessibility, by allowing accessible software to create an equivalent navigation control.

Structure/Accessibility example

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

is now:

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

Apart from better accessibility, advantages include:

Aim: Internationalization

Aim: Less scripting

Observe how scripting is currently used.

Identify missing markup/functionality.

Add it where possible; try to cover 80% mark

Examples: menus for navigation; forms data checking; folding presentation.

Advantages: more devices, more presentational variations, better search, better accessibility

Aim: Better Semantics

The attributes on <meta> and <link> can be used on any element. For instance:

<body>
      <h property="title">My Life and Times</h>
      ...

is a way of saying that "My Life and Times" is both the <title> of this document, as the top-level heading.

There is also a definition of how this maps to RDF.

There is a lot of potential for better semantics: user experience and accessibility can be improved.

If a browser knows that a piece of text is an address, it can offer to add it to your address book, or find it on a map; if it knows some text is a conference announcement it could offer to add it to your agenda, find hotels, find flights, ...

Role

Another part of the semantic classification allows you to specify the role of an element:

<div role="navigation">...</div>
<div role="main">...</div>

Aim: More device independence

The aim of 'less scripting' has already been mentioned: this clearly increases device independence.

Similarly, no hard-wired presentation means that a document can be styled with different stylesheets for different devices (as supported by CSS2).

There are two other areas where device independence is being addressed: Events and Forms

Events

Current HTML events are a disaster

Problems include:

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

HTML forms were the basis of the ecommerce revolution. XForms improves on them, principally by improving the user experience:

It defines two separate parts: the 'real' form (data, datatypes and submission details), and form controls bound to the data.

Form controls are device-independent and accessible: they specify the intent rather than the presentation.

Advantages: usability, accessibility, device independence

Separating function and user interface

Ajax (despite its age) is generating a lot of buzz at the moment, and rightly so.

But it is only a beginning; in particular having learnt the benefits of separating content and presentation, we now have to learn the benefits of separating function and user interface.

XForms for Web Applications

XForms has everything needed for an application:

People are already using XForms for some pretty exciting applications. xport.net who produce FormsPlayer are doing the most interesting stuff, by using SVG as the stylesheet language. They have produced examples such as a world clock, a contacts database, and even Google Maps in XForms!

world clock in XForms

Google maps in XForms

Google maps in XForms

maps

The interesting thing about this last example is that it is 25K of XForms, compared with 200K+ of javascript...

This is largely thanks to the declarative programming model of XForms, that means that you don't have to deal with lots of the fiddly administrative details.

Bear in mind that empirical evidence suggests that a program that is an order of magnitude larger takes 34 times as much effort; or put the other way, a program that is an order of magnitude smaller costs 3% of the effort...

Conclusions

HTML was originally designed as a structure description language, not a presentational language.

The design of XHTML is truly 'radical': taking HTML back to its roots.

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/Markup, www.w3.org/WAI