Re: some reflections on @alt usage (and summary of research so far)

Ian Hickson 2008-08-23 00.45:

> The following arguments impacted the decision [...]


[the idea to reject role="photo" in favour of alt="{photo}]

 
>  * Introducing attributes for features that are supposed to be an 
>    indicator of a problem (lack of alt text, in this case) isn't good 
>    language design, as it brings it too much into prominence.

I don't see "lack of alt text" as "an indicator of a problem". But 
if we introduced @role, /then/ @alt would be come an indicator.

Today, whether you write alt="" or alt="spacer", there is nothing 
which indicates any problem. Both could be wrong. Both validate.

>  * An attribute would almost certainly be copied around unintentionally 
>    by authors leading to it being at least as unreliable as the special 
>    syntax if not more.


Should we anticipate1 that the role of a particular photo will 
change much and often depending on its context?

For the photo website use case, I have proposed role="albumphoto". 
  I do not think it would hurt much if that attribute would follow 
by if the image was copied to another context. Instead, it could 
help. There are a bunch of other possible @role-s which probably 
would work in many contexts: role=spacer, role=decor, 
role=potrait, role=mathexpression, role=text etc.

Of course, an author should try to ensure he uses right role. But 
the danger of copy-pasting seems exaggerated in this case.

>  * An attribute introduces a whole class of extra conformance errors and 
>    complications, such as what to do when it is used with or without the 
>    alt="" attribute.


I actually thought we were /looking/ for ways to do better 
validation - that's how I have understood Henri. Without @role, a 
validator cannot check much more than whether @alt is or isn't there.

As for the what User Agents are to do when @alt is lacking and 
@role is present, well - I guess that should be a simpler thing to 
answer than the question of what the UA should do when neither 
@role nor @alt is present?

The problems which can arrise when the @role value contradicts the 
content of the @alt mostly are that @alt may have text when it 
should have been empty (alt="spacer"). Or that it is empty when it 
should have had text. Both these are even today a problem, except 
that they are impossible to deteect. @role would at least make 
them detectable, and thus possible to act upon.

> All the above led to what the spec says today, which is the alt={...} 
> idea.
> 
> Since the above, however, it has been pointed out that one problem with 
> the alt="{...}" idea exists that wasn't previously considered, namely that 
> it makes it harder for systems that _are_ trying to automate alternative 
> text creation to do so, since they now have to avoid accidentally using 
> the {...} syntax. This dramatically lowers the attractiveness of the {...} 
> idea, leaving pretty much only omitting alt="" for these cases as a 
> least-worse option.

Exactly that problem could be avoided by the introduction of 
@role, as you could link the syntax to the particular @role.

(Having @role would not mean, in my view, that Flickr should not 
try to repair the lack of user-inserted @alt text. Like Al said, 
they should put their clever "something" there. But with 
role="albumphoto", they could do so wihtout having to think about 
having to avoid the {...} syntax.)
-- 
leif halvard silli

Received on Saturday, 23 August 2008 03:46:49 UTC