RE: Investigating the proposed alt attribute recommendations in HTML 5

Jon Barnett wrote:
> But specifying alt="" just to prevent the reader
> from announcing a filename seems like a bad workaround that hurts
> semantics.     

Jon, 
Can you expand on this please?  How does a null value of the alt attribute
"hurt" semantics? (I get that it may not be that useful, but hurt?)  And,
conversely, how does substituting noalt (or omitting an alt value at all) in
place of alt="" improve or "help" semantics?

I'm not trying to be smart here; I really want to understand the reasoning.


> Does JAWS first fall back to @title instead of @src?  If so, that
> would be better.  

The reading aloud of the title attribute by JAWS is a user-preference
setting; it cannot be reliably established whether a JAWS user is getting
the @title information or not.  As well, as far as I know, there is no way
of "sniffing" to determine if the user has turned it on or off. 

I would like, as well, to think beyond JAWS: while it might be the market
leader, there are other screen reading tools on the market that do not
behave exactly the same as JAWS, any more than Safari behaves exactly the
same as Opera...

> All of the @alt attributes on that page would serve
> better as @title attributes - they're descriptions, not alternates.
> (And in turn, I wouldn't be opposed to requiring @title when @alt is 
> omitted)

Except, see above...


>> «If this attribute is omitted from an element, then it
>> implies that the title attribute of the nearest ancestor
>> with a title attribute set is also relevant to this element.»
> 
> I don't like how that sounds, and Maciej highlighted that.  It
> implies that the @title in an ancestor <p> applies to an <img>.  It's
> relevant in that the <img> is part of the ancestor paragraph, but it
> shouldn't imply that the @title applies directly to the image...  I'm
> not even sure that sentence is necessary.    

...and so, hopefully this has been flagged in the draft to be revisited.



Meanwhile, Maciej Stachowiak wrote:
> Repetition might beat making the association unclear, but can we come  
> up with markup that lets the association remain clear without the need  
> for repetition?
>
> Do you think that for a photo sharing site, "This is the photo that we  
> are talking about" or other such prefab text would be an improvement  
> on pages where the title is still present?

Again, there are two issues here:  the way that @title is being "consumed"
by the end user (on or off by user-preference in JAWS), as well as current
(anecdotal) information that shows that some non-sighted users "want it
all", whereas others do not:  

Alastair Campbell wrote:
>
> Tighe K. Lory wrote:
>> An example would be a stockphoto of a person ...
>> Putting in alt text would just clutter up what the screen reader says, 
>> and I think make the site less useable.
>
> And my colleague Léonie would argue that if the image conveys something
(even "just" 
> emotive), then she would like to know it's there and what it is supposed
to represent.
>
> That demonstrates the hard-core usability vs holistic experience divide
quite nicely.


It is this un-quantified social factor that needs to be more fully
considered as we move forward.  The HTML 5 Working Group might be coming up
with "engineered" solutions,  but they need to be balanced by user needs,
expectations and requirements/desires.  This requires consulting the actual
end users, rather than other engineers...

JF

Received on Thursday, 30 August 2007 20:56:56 UTC