using an attribute to categorize the @alt state [was Baby Steps or Backwards Steps?]

This is example example where  Ian hasn't even taken his own advice.   
He has rightly suggested that we all focus on problems statements and  
use-cases. The changes he's made to the draft certainly reflect an  
important problem-statement /use-case.  However, the solution fails  
to benefit from the WG process. Many of the topics slowly developing  
on the  wiki have benefitted form many back and forth threads  
discussing the topic. Even the issue of different purposes for images  
has been discussed in a manner similar to that shown in the changes  
to the draft.


On Aug 16, 2007, at 1:35 AM, Gregory J. Rosmaita wrote:

>
> 3 questions:
>
> 1. why not raise the issue on public-html?

Indeed, some of the discussion have already considered this topic.

> 2. why not cross post your concerns/issues to the WHAT WG list
>    and the w3c-wai-au@w3.org list, which exists precisely to
>    address authoring tool issues;
>
> 3. how does leaving alt out entirely when an image is not "purely
>    decorative" "better" serve someone merely by indicating the
>    presence of an image?

I think a better approach might be to add a new attribute to  the | 
img| element (and maybe the other embedded content elements too).

I can't think of a good name for this attribute, but consider  
something like @embedrel (required) for now (name suggestions  
welcome). The value of this attribute would reflect the scenarios  
identified in the recent changes to the draft. missing, icon,  
decorative, seecontext, seefallback. The value 'missing' would be the  
default value, unless '@a't had a string (or perhaps some other  
contingencies for content backwards compatibility )  so not setting  
either @alt or @embedrel would be considered 'missing'.

Considering the scenarios in the draft:
  • A key part of the content that has no textual alternative  
(missing; @alt could be left off)

This is the default value. Editing UAs, converting UAs, and content  
management UAs should ensure "missing" is set unless the author  
inputs a string in length greater tha n into the value of the @alt  
attribute.

• An image in an e-mail or document  intended for a specific person  
who is known to be able to view images (missing)

I think the email delivery situation is not really different than  
HTML delivery so perhaps the same keywords should apply.

  • Icons: a short phrase or label with an alternative graphical  
representation (icon)

  • A purely decorative image that doesn't add any information but is  
still specific to the surrounding content (decorative). Typically CSS  
would be the preferred approach for these images.

These last two (not the same order as the draft) are the trickiest to  
capture in a keywords that authors will understand. Perhaps others  
could come up with better keywords here. The main difference here
  • A phrase or paragraph with an alternative graphical  
representation (seefallback; alt required)
  • A graphical representation of some of the surrounding text  
(seecontext; alt may be omitted)

To set the keyword missing and to leave it off would basically mean  
the same thing. However by requiring authors to at least set the  
value of the @embedrel attribute, the conformance checking process  
would raise awareness of the need to consider alternative text for  
images and other media.

in the future, HTML5 conforming aural browsers could easily help  
users distinguish between these states for any particular non-text  
embedded content. Authors could easily set "decorative" or "icon"  
when adding large numbers of decorative and icon content. A  
contentious  author could recognize the image fit the graphic  
representation scenario and set the attribute value to 'seecontext'.

Conformance checkers could easily tell at least whether the document  
meets particular criteria. For example, it would be able to tell when  
@embedrel is missing or set to an invalid value and notify the  
author. If @embedrel is set to 'missing' or '

This may be a complication, but I think the default values could be  
handled based on the state of the @alt attribute. I most cases the  
default would be 'missing'. However, if the element had exactly  
alt='' the default value could be 'decorative'. The other values  
would require explicitly setting the value. These defaults would map  
fairly closely to the current practices (I think but others may have  
other information).

Take care,
Rob