Re: [html4all] Request for review of alt and alt value for authoring or publishing tools

On Wed, 16 Apr 2008 14:40:18 +0200, Charles McCathieNevile wrote:
On Wed, 16 Apr 2008 14:40:18 +0200, Charles McCathieNevile wrote:

> On Wed, 16 Apr 2008 13:56:28 +0200, Harry Loots 
> <harry.loots@ieee.org>  wrote:
> 
> > On Wed, 16 Apr 2008 11:25:17 +0200, Charles McCathieNevile wrote:
> >> (Leaving aside the question of validity and focusing on the effect
> >> on  users) I am with Ian here. Adding magic values is likely to mess
> >> up  existing workflows from user agents through to authoring tools,
> >> system  evaluation tools (the sort of thing that the people who
> >> currently really  care about getting tehir HTML right actually use),
> >> and even websites  explaining how to write good web pages.
> >
> > Are we saying that once the tool has been published it can not be  
> > changed to allow for changes in the way the code is presented?
> 
> Not at all. I am saying that standardising some behaviour other than 
> using  the absence of an alt attribute to signal that there is no 
> decent text  alternative provided means that most of today's tools 
> would not be useful  and would need to be changed. So would most of 
> the tutorial information  around today.
> 
> (If we standardised on alt="" instead then there may be a few tools 
> which  would suddenly work properl, but would be considered broken 
> today).

So if i read this correctly you are suggesting that tools be fixed first to
correctly displayed the 'conventional' value of alt="" - ie, display nothing?
  

> >> Leaving out the alt attribute  where you don't know anything about what
> >> would be a good value (whether  you are a second-rate tool that
> >> never asked, or a lazy or second-rate  author that never bothere to
> >> think about the answer - and I really do mean  that to sound at
> >> least as judgemental as it does) is the simplest approach  to
> >> allowing those who are doing a decent job to improve the web overall.
> >
> > I cannot agree with this viewpoint:
> > we share the viewpoint that where ALT has been provided it is assumed to  
> > have been provided with good intentions, ie, to describe the image to
> > users who may benefit from ALT. On equal terms with this statement where
> > developers deliberately add ALT=" " let's assume for the moment that
> > they do so in the understanding that AT will ignore the image and skip
> > to next segment of text content.
> 
> [modulo minor quibbles about alt not being a description per se, but 
> more  like a "functionally equivalent text", and this being about 
> more than a  handful of users or about screenreaders, sure]

Fair comment - i should choose my words more carefully ;) 


> > Based on the above development practices, we have two scenarios:
> > If ALT is used as described above, users who read or hear the text  
> > alternative to the visual content are presented with either the
> > ALT description or nothing.
> 
> Indeed. Depending on what is most useful.
> 
> > In the case where ALT has been ignored due to laziness, ignorance, or  
> > whatever other reason, the same group of people described above may
> > benefit if the UA announces or inserts text to the effect
> > 'ALT missing/omitted/not supplied/AWOL' or whatever words we choose
> > to tell the user the developer is lazy, second rate or simply
> > ignorant of their needs. If the words 'ALT not supplied/whatever' is
> > heard/appears, the user knows that an image appeared in the content;
> > they do not know if it has value, but at least they can ask
> > someone who can view or see the image if it contains information of  
> > relevance.
> 
> Right.
> 
> > If ALT="" is used for this scenario then the user will not know there is  
> > an image and will not be able to do anything about it.
> 
> Then we really do agree. By *leaving out* the alt attribute, I mean 
> no  attribute is present. Unless some useful alt content has been 
> supplied,  there should be no alt attribute and nothing there. This 
> has been a common  idea in accessibility for something like a decade.

To a point.... 
I'm happy to agree that no alt should be interpreted as the lazy second-rate
couldnt care less.... 
However in practice i have seen to many people who do not know what to do when
they encounter nothing.... Give the same people a string of nonsensical text
such as 'none supplied' and they'll immediately come up with an elegant
solution on how to deal with this!

Either way, if we agree that the omission of alt, whether by total omission or
through reserved value, should be dealt with by UAs in a specified way, how do
we get UA makers to implement this simple convention? How can we get them to
interpret an omitted ALT and advise the user/reader/listener that an image is
present but no equivalent has been provided? 


> 
> Note that while alt="" and alt=" " are, to a screen reader,
>  equivalent -  nothing gets read (unless the user has selected super-
> critical punctuation  sensitivity), they are different to a visual 
> user with images off, since  they potentially change the 
> presentation. They are potentially different  to a braille reader 
> for the same reason. Search engines, software  evaluation frameworks,
>  and other non-visual user agents may also react to  them in 
> different ways.

Minor point: 
agree on equivalence from AT perspective - and you're right it may be
potentially different to other non-visual UAs - i seem to recall (though not
sure i want remember that far back) that Bobby used to complain about alt=""
but accepted alt=" ". 

In practice though alt="" and alt=" " is not equivalent.

Example: 
<img src="foo_1.gif" alt="Ma riding her bicycle"><img src="foo_2.gif"
alt=""><img src="foo_3.gif" alt="Pa riding his bicycle">
will be rendered as 'Ma riding her bicyclePa riding his bicycle' - note the
concatenation of 'bicycle' and 'Pa' 

Best practice suggest that alt values should start and end with a space (where
a value is supplied) and a single space inserted where the intention is to
leave this blank. But that's probably a point for a different discussion....

Received on Wednesday, 16 April 2008 13:38:28 UTC