Re: Images and alternative text

Hi Leif,

On Aug 11, 2008, at 7:42 PM, Leif Halvard Silli wrote:

>
> Robert J Burns 2008-08-11 13.26:
>
>> On Aug 10, 2008, at 3:22 PM, Smylers wrote:
>>> James Graham writes:
>
>>>> [...] an alternative proposal with similar semantics [...]
>>>> a boolean attribute to image called no-text-equivalent
>>>> [...]
>
>
> @no-text-equivalent is proposed as a boolean. Wheras alt="{photo}"  
> presents and textual alternative to the lacking textual equivalent.  
> Thus, they are not similar.
>
>> Both suggestions (the separate attribute and the special syntax for  
>> the alt attribute) were both discussed at length long before Ian  
>> made the suggestion. An obvious contender for the former is the  
>> role attribute (requiring it for all non-text media). For the  
>> latter, I think the problems with legacy UAs are too great to take  
>> such a proposal seriously anymore.
>
> Regarding obvious contender: a role="no-text-equivalent" would  
> probably not be so interesting to have. I think @role rejects the  
> idea behind @no-text-equivalent.

I don't think role='no-text-equivalent' was the proposed solution. The  
idea was that if the role attribute was present with one or more of  
several predefined values (other than 'decorative') than the non-text  
media should be treated as non-decorative with either the text  
equivalent displayed or if there is no text equivalent an appropriate  
indication drawn from the role keywords. This gets away from the  
problems with no-text-equivalent (such as the value becoming incorrect  
when a subsequent author adds the text equivalent but fails to remove  
the boolean attribute or value).

> As for role="photo" vs. alt="{photo}, the latter is intended to be  
> read by the user. Wheras @role needs interpretation by an UA before  
> eventual presentation to the user. @role therefore "suffers" from a  
> limited set of values, in English. Thus for @role there seems to be  
> an UA localisation problem.

To me this is another disadvantage of the curly brace proposal. It  
would be far better (for internationalization/localization as well as  
other reasons) to have pre-determined values that UAs could interpret  
than simply place anything an author wants between braces and hope  
that they do not mean the literal text within the braces (the TeX  
example is just one of many possible problems). The curly brace syntax  
is also a problem with existing UAs, since now the user will have to  
listen to endless utterances of "open-curly-brace photo close-curly- 
brace'.


> Regarding @tagged (see my previous reply and the examples below):  
> @tagged is basically the same idea that Ian has presented. Without  
> his syntax and without any clashes with {TeX} or other syntaxes.
>
> Ex. 1: <img src=src alt="photo" tagged >
> Ex. 2: <img src=src alt="Mum and dad." tagged="photo" >
>
> @tagged might look similar to @role. Therefore I want to describe  
> the differences: It seems to me that @role speaks about the entire  
> IMG element. Wheras both Ian's propoisal as well as @tagged are only  
> meant to say something about how the content of @alt should be  
> interpreted.

However, the role attribute would imply something about the alt=''  
null value. In that case the presence of role='decorative *" would  
strengthen the implication that the image (or other non-text media)  
was purely decorative. The absence of any role values would leave the  
ambiguity of the current state for alt='' (in other words the UA would  
not know whether the image was decorative or the alternative text was  
simply missing).

> Thus, there is nothing which prevents us from having both @role and  
> @tagged simultaneously. Though it would of course be possible to  
> have role="tagged" to say the same thing as the boolean variant of  
> @tagged.

The problem with tagged is that it is an extra attribute or value when  
the same information can already be conveyed through existing  
attributes and values (or with only newly proposed role values such as  
'decorative', 'photo', 'cartograph', etc.).

> As long as @tagged and/or Ians curly brackets syntax only speak  
> about how the content of @alt should be interpreted, then the  
> question of requiring @role on all non-text media elements becomes a  
> different question. (Unless, of course, we go for role=tagged.)

Again, I think the keyword 'tagged' becomes redundant once role  
becomes required. The keyword tagged is not intuitive for authors, but  
requiring authors to select from among certain role values would be  
intuitive for authors. The use of 'tagged' or other attributes  
requires a shift for authors into an esoteric HTML syntax whereas  
selecting from among some role values does not. For example, authors  
will have no trouble identifying an image as a 'photograph' or a  
'barchart'. However, 'tagged' does not immediately convey to an  
authors what it means.

Take care,
Rob

Received on Monday, 11 August 2008 19:03:09 UTC