- From: Robert J Burns <rob@robburns.com>
- Date: Mon, 5 May 2008 13:44:34 +0000
- To: James Graham <jg307@cam.ac.uk>
- 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>
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
text'></a>
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,
Rob
[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