Re: Images and alternative text

Robert J Burns 2008-08-11 21.01:

> Aug 11, 2008, at 7:42 PM, Leif Halvard Silli:
>> Robert J Burns 2008-08-11 13.26:

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


So the @alt text keywords - AKA curly brackets/@tagged - solve a 
different problem that what @role solves. The former solves the 
problem of finding meaningful @alt text. Whereas @role does not 
affect the content of @alt at all. [But see my two questions 
regarding role="decorative" and alt="" below.]

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


I don't see these i18n advantages. Yes, it is clear that @role 
needs to be localized. But that is merely a fact, and does not 
have any bearing on @alt, whether @alt contains keywords or a real 
textual equivalent.

>> Regarding @tagged [...]
>>
>> 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).


Will role="decorative" trumph the @alt text in for example
<img alt="spacer" role="decorative" src="src" > ?

Is the role of role="decorative" to confirm that 'I really meant 
to say alt=""'?

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

I don't understand how we can already do, with existing attributes 
and values, what {} and/or @tagged can do. Please explain.

Those newly proposed @role values are fine, but can still only 
cover some general use cases. The @alt "keywords" are as flexible 
as the author wish (as I see it, anyway). And needs to be, since 
they will be read by users.

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

Here is how I would link @role and the 'tagged' keyword:

The 'tagged' keyword should only permitted together with certain 
of the @role attributes. It should not be permitted alone. And it 
should for instance not be permitted together with role="button" 
or role="decorative".

However, with role="photograph" or if we could say 
role="album-photo", then 'tagged' could be added -- 
role="album-photo tagged" -- to indicate that the author "saved 
time" by only using some keywords in the @alt text. (Allthough, 
perhaps role="album-photo" would be enough ...)
-- 
leif halvard silli

Received on Monday, 11 August 2008 22:53:00 UTC