[html4all] Blue-sky thinking (ALT attribute)

[Robert Burns]

Hi John,

On Sep 25, 2007, at 3:16 PM, John Foliot wrote:

> Moved to the public list:
>
>> Debi Orton wrote:
>>> Hi John,
>>>
>>> I'm not sure I follow what you're proposing.  I'm not seeing why a
>>> developer -- who's already objecting to adding alt attributes at all
>>> -- would be more willing to supply alt="_none" in lieu of alt="".  I
>>> understand the part about how AT would handle that particular
>>> artifact, but I don't understand what it would do to improve the
>>> provision of alt values for visual items.
>>>
>>> Can you explain this aspect more fully?
>>>
>>
>> Currently the editors are stating that alt="" is for images that have
>> no need of an alternative text - spacer.gif kind of things or other
>> embellishments (that should reside in CSS, but whatever).  What they
>> are looking at is images that *should* have alternative text, but
>> doesn't - the kind of photos that would be uploaded via their cell
>> phones (their scenario).  They are suggesting in those contexts that
>> not having an alt attribute should be allowed, rather than
>> "polluting" the web with useless or redundant alternative text.  They
>> can't seem to budge from the idea of an instance when there would be
>> no useful alt text provided, thus not adding an alt attribute should
>> be permitted.
>>
>> My concern is that allowing an image to exist without an alt
>> attribute opens the door to abuse (as we saw with Anne's blog example
>> of the building in Boston), and so I'm suggesting that to be "in
>> conformance" an image *must* contain an alt value, and along with the
>> already reserved alt="" that another reserved value would be
>> alt="_none" - for instances when there should be alternative text,
>> but none has been provided.  While this does not really address the
>> accessibility of the image itself (it still has no usable alternative
>> text), it *does* preserve the requirement of all images must contain
>> the alt attribute.  This eliminates the "backward slide" that I am
>> most concerned about.
>>
>> The other thing is that it's not so much a value that a content
>> author would use in a traditional HTML editor (although it
>> could/would port over to that
>> environment) but more in instances like Flickr, where the interface
>> either does not allow (this should be fixed), or more likely because
>> of the volume of imagery being added (coupled with user apathy or
>> ignorance) results in no alternative text being supplied - in that
>> case default to _none ('cause that is what has been supplied - none
>> or nothing).  It's accurate, truthful, concise, and because it would
>> be standardized in the spec it would be something that user agents
>> could reliably be programmed to deal with.
>>
>> Does that make sense?

I and others raised a similar proposal to the HTML WG. Sander  
objected that it would be a nuisance for users of legacy AT UAs  
(e.g., having to hear "underscore none" spoken). In light of the  
proposed solution by the editor I think legacy ATs are clearly not a  
major concern and so I think using keywords would be far superior  
than the blunder in the current draft.

This proposal also led to the proposal on the wiki to use a separate  
role attribute and DOM attribute to provide more information to UAs,  
users and more information from authors about embedded content [1].

Take care,
Rob
[1]: <http://esw.w3.org/topic/HTML/EmbeddedContentRoleAndEquivalents>