W3C home > Mailing lists > Public > public-html@w3.org > May 2008

Re: alt and authoring practices

From: James Graham <jg307@cam.ac.uk>
Date: Sun, 04 May 2008 14:24:29 +0100
Message-ID: <481DB90D.5010605@cam.ac.uk>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
CC: Henri Sivonen <hsivonen@iki.fi>, HTML Working Group <public-html@w3.org>

Daniel Glazman wrote:
> Henri Sivonen wrote:
>> How about a checkbox labeled "Purely Decorative" and a text field 
>> labeled "Textual Alternative" (if the checkbox is checked, disable 
>> text field and emit alt=""; if the checkbox is unchecked and text 
>> field empty, emit no alt attribute)?
> Because you think average editing tool users are going to understand
> that ??? Bwahaha, to say the least. No, that's not a workable solution
> for very average users.
> Think simple, think MacWrite, a piece of software anyone could
> understand in 5 minutes w/o having to read any manual.

I think the current behavior of KompoZer (the Nvu fork that is shipped 
with the current Ubuntu release) is both an example of a UI that is too 
hard for normal users and the harm that comes from a mandatory alt 
attribute requirement combined with the desire of tool authors to 
produce markup that passes automated conformance checks. I don't know 
how much the KompoZer UI has changed from the Nvu UI in this area.

The simplest way to insert an image in KompoZer is to go to the image 
icon on the toolbar. This presents a dialog a bit like so (omitting 
things that are unimportant for the current discussion):

|             Image Properties               |
| Image Location:                            |
| |___________________________________| [...]|
| [ ] URL is relative to page location       |
|                                            |
| Tooltip: |________________________________||
|                                            |
| (o) Alternate text |______________________||
| ( ) Don't use alternate text               |
|                                            |
| [Help]                       [Cancel] [OK] |

The OK button is enabled as soon as an image has been selected.

If one selects an image and then presses OK you get a modal alert like so:

|                               Alert                                 |
| If the image is relevant to the content of the document, you must   |
| supply alternate text that will appear in text only browsers, and   |
| that will appear in other browsers when an image is loading or      |
| when image loading is disabled.                                     |
|                                                                     |
|                                                              [ OK ] |

Pressing OK returns you to the previous dialog; despite the OK button in 
the image properties dialog being enabled there doesn't appear to be any 
way to insert an image without taking further action. This is presumably 
to ensure that some alt text is entered.

Let's consider a typical user "Andrew" and how he might react to this 
set of dialogs. Andrew's goal is to insert an image into his personal 
homepage. Andrew clicks the large "Image" icon on the toolbar and sees 
the Image Properties dialog box. Here, he successfully selects the file 
he wants to include and, not seeing anything else critical to his goal, 
click OK. Unexpectedly, for Andrew, KompoZer blocks him for achieving 
his goal, instead popping up a long wordy alert. This is suddenly 
looking much more complex than he had expected from his experience with 
programs such as Microsoft Word.

Not believing that inserting a picture can be so complex as to need a 
paragraph of explanation Andrew skim reads the alert and picks up that 
it has something to do with the alternate text. He quickly realises that 
he has to change something in the "Alternate text" set of radio 
controls. Not being aware of the issues involved he takes the path of 
least resistance and selects "Don't use alternate text", clicks OK and 
sees that his image has been inserted.

Unfortunately KompoZer has put <img alt=""> in the source of Andrew's 
document; the one single value that makes it least likely that users of 
non-graphical browsers will even be aware of the image's existence.

Even if Andrew decides to insert some alternate text rather than using 
the image dialog, the fact that he is doing in response to a 
flow-disrupting modal dialog makes it unlikely that he will write well 
considered, useful alt text. As far as I can tell KompoZer doesn't offer 
a view of the document that has images disabled, so it is difficult for 
Andrew to understand the effect that his choice of alt text has on the 
user experience in that situation.

If a user — Beth, say — inserts an image by drag and drop, the situation 
is even worse; KompoZer puts the local path of the image in the alt 
attribute. This is hostile to AT users who will have to listen to the 
path of the image read out instead of the — possibly more useful — 
AT-specific behaviour in the face of missing alt information. It's also 
not likely to be useful information for other users of non-graphical 

The behaviour of Kompozer when inserting images is a good case study of 
the effect of encouraging tool authors to stuff required pieces of 
syntax with meaningless values to pass automatic conformance checks. I 
would be surprised if the UI decisions in KompoZer didn't lead to a 
excess of actively harmful alt values compared to what you would get 
without the program trying to enforce the presence of the attribute at 
all costs. The problem is made worse by the fact that KompoZer fails to 
provide tools to guide users through basic manual conformance and 
accessibility checking — tools that would help users to understand the 
real issues that need to be addressed when producing accessible pages.

"Mixed up signals
Bullet train
People snuffed out in the brutal rain"
--Conner Oberst
Received on Sunday, 4 May 2008 13:25:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:17 GMT