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

Re: alt and authoring practices

From: Robert J Burns <rob@robburns.com>
Date: Mon, 5 May 2008 13:44:34 +0000
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, Henri Sivonen <hsivonen@iki.fi>, HTML Working Group <public-html@w3.org>
Message-Id: <75AA1D97-A5FC-4E85-A887-DF1AC50E0332@robburns.com>
To: James Graham <jg307@cam.ac.uk>
Hi James,

On May 4, 2008, at 1:24 PM, James Graham wrote:

I wanted to follow up a bit regarding authoring tool UI and inserting  
images. I think that raising the level of authoring tools will have  
the greatest impact on improving general interoperability and  
accessibility (since conformance shouldn't be a goal in itself).

So first I'll recap your statement of the current KompoZer app and  
state how I think both the UI and the HTMl language can be improved to  
facilitate what is a very common authoring situation.

[best viewed in a monospaced font]

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

Here would be a better approach (both for the HTML5 recommendation and  
for any particular authoring tool of this genre):

When inserting an image either through a drag & drop or through the  
invocation of a menu (or otherwise) command.

|             Image Properties                 |
| Image Location:                              |
| |<filled in for the drag & drop
                  empty otherwise>| [...]       |
| [ ] URL is relative to page location         |
| [ ] Hyperlink to:                            |
|| |__________________________[...]            |
| [ ] URL is relative to page location         |
|                                              |
| Tooltip(title): |___________________________||
|                                              |
| Alternate equivalent text:                   |
| ( ) Image is merely decorative               |
|                         (no alternate text)  |
| (o) Image is neither decorative nor iconic   |
|                         (no alternate text)  |
| ( ) Image is iconic                          |
|  alternate text: |_________________________| |
| ( ) Image of (rich) text: provide            |
|  equivalent plain  text: |_________________| |
|                                              |
| [Help]                       [Cancel] [OK]   |

The OK button should be enabled as soon as an image has been selected.  
However, if the hyperlink checkbox is selected, then the "Image is  
neither decorative nor iconic" and "Image is merely decorative" should  
be disabled and the "Image is iconic option" should be selected (only  
one of two remaining options). if, upon clicking ok, no URI is  
provided for the hyperlink, an alert should require it.

If no alternate text is included even though this image is iconic, the  
UI should throw up an alert like:

|                  Alert                 |
| Failing to include alternate text will |
| make this link (icon) unusable to users|
| in some browser settings.              |
| Would you like to:                     |
|                                        |
|                             [ Cancel ] |
|       [ Return to add alternate text ] |
|                     [ Override alert ] |
Pressing cancel, cancels the entire image insertion process. Pressing  
the second option returns the user to the previous dialog and changes  
the selection to "Image is iconic" (disabling the other choices if not  
already disabled). Pressing "Override alert" causes the image  
insertion process to complete, leaving a non-conforming image markup  
(unless we improve the HTML5 draft).

Selecting iconic image and not providing any alt text should lead to  
the same alert and the same markup if overridden.

So this process has several possible outcomes:

1) for a decorative image: <img src='aURI' alt=''>
2) for a neither decorative nor iconic image:
      <img src='aURI' alt='' role='m' >
                 based on the wiki  proposal[1] where 'm' indicates  
meaningful image
3) for an iconic image:
        <img src='aURI' alt='user provided alt text'>
4) for an iconic image with a hyperlink:
        <a href='aLinkedURI' ><img src='aURI' alt='user provided alt  
5) for an image of text:
        <img src='aURI' alt='user provided equivalent text'>
6) for an image of text with a hyperlink:
        <a href='aLinkedURI' ><img src='aURI' alt='user provided  
equivalent text'></a>
7) for an iconic image or rich text image but alt user overridden:
        <img src='aURI' role='icon missingfallback' >
8) for an iconic image or rich text image with a hyperlink but alt  
user overridden:
         <a href='aLinkURI' ><img src='aURI' role='icon  
missingfallback'  ></a>

This provides a decent UI that assists users  users with no knowledge  
of HTML  produce valid HTML5 (provided that HTML5 does the right  
thing here). For legacy aural browsers and screen readers, problems  
may persist in the two last cases (5 and 6). In those cases the user  
has chosen to ignore best practice and confirmed that choice in a  
follow up dialog alert. HTML5 can provide a mechanism for HTML5 aware  
aural browsers and screen readers to provide special treatment in  
those cases different than that of the decorative or non-decorative  
and non-iconic photograph with no alternate for this document.

This last category of images is probably the most discussed scenario.  
These images are not necessarily decorative in the strictest sense of  
that term. Strictly decorative images could best be handled through  
CSS, but with these meaningful images (often photographs), CSS is an  
inappropriate abuse of the separation of concerns. However, there's  
also no use in including a text equivalent in the alt attribute since  
we have other mechanisms to handle subject descriptions or  
experiential (visual) descriptions of such media.

The most important situation where we want to ensure we have  
meaningful alt text is in the situation of an image participating  
(particularly alone) as a hyperlink. The other situation of an icon,  
that is not participating as a hyperlink is less damaging to the user  
experience (though still damaging). This UI and markup covers those  
situations quite well leaving only a disruptions for author error or  
more likely blatant author disregard (there's nothing UI nor a markup  
specification can do about that).

Take care,

[1]: <http://esw.w3.org/topic/HTML/EmbeddedContentRoleAndEquivalents?highlight=%28image%29%7C%28alt%29%7C%28role%29 

Received on Monday, 5 May 2008 13:45:13 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:30 UTC