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

On Wed, 16 Apr 2008 15:37:21 +0200, Harry Loots <harry.loots@ieee.org>  
wrote:

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

>> <harry.loots@ieee.org>  wrote:
>>
>> > On Wed, 16 Apr 2008 11:25:17 +0200, Charles McCathieNevile wrote:
>> >> ... Adding magic values is likely to mess
>> >> up  existing workflows...
>> >
>> > 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 [new] behaviour...
>> means that most of today's tools
>> ... 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?

Most existing tools today work, based on the assumption that alt="" means  
"there is nothing that needs to be said about this image in the ordinary  
flow of text" and img elements that have no attributes just mean the tool  
has to do its best to figure out how to solvethe rpoblem that the page was  
badly authored.

User agents generally present nothing when alt=""
Authoring tools that get it right check for no alt attribute, and prompt  
for something useful. Which can be "" (the empty string) or " " (space) or  
something else. Most authoring tools do not add a value if they do not  
have any information.

Flickr, it seems, is a prominent exception - right now it does the wrong  
thing (this is by report - I no longer use flickr and haven't gone back to  
log in just to check) and adds alt="" automagically, whether there is a  
description[1] (in which case that is reasonable) or not[2]. On a page  
full of photos[3] it just repeats the title of the photo, which is  
generally reckoned as a bad alt text. There are other prominent exceptions  
- and we should fix what they do. This discussion is substantially about  
whether they add alt="" in order to claim validity to the spec, since the  
outcome "we" are trying to establish is that they do not automatically add  
this value.

...
>> [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 ;)
>
...
>> > If ALT="" is used for [when nothing is supplied] 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. ... 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!

Do you mean end users can't cope? This is properly handled by their user  
agent (or UA/AT combination if applicable) providing them the information  
that there is an image. Mine does so by putting a little box in the  
layout, and putting the alt in the little box.

> Either way, if we agree that the omission of alt, ... should be
> dealt with by UAs in a specified way,

I doubt we will agree on many details of the "best" way to deal with this.  
I think the requirements in the User Agent Accessibility Guidelines [4]  
already clarify what information needs to be available, but how various  
systems present that is properly a matter for competing software to  
determine on their own. All we are likely to really agree on is the  
meaning of the syntax when an img element is present, but it has no alt  
attribute at all, and maybe also when that attribute is present but has  
the value of the empty string (both these cases are currently explained in  
the existing draft. The argument is about whether they should be represent  
valid HTML 5.

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

There are a lot of techniques. Turning on the program is one, setting the  
preference for what it does in the case of missing information is another,  
setting a user style sheet is another (my user-mode stylesheet in Opera  
pretty much gives me the same information that is presented to a jaws  
user, although it doesn't make as much effort to find something useful  
with which to replace alt when the attribute is not there).

This is a solved problem. If your particular software does it wrong, file  
a bug or change software.

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

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

My paragraph above says "it is equivalent *FOR*SCREEN*READERS* and  
*IT*IS*NOT*EQUIVALENT* for a whole raft of other technologies for which  
the alt attribute is important". Which is exactly what I read you saying.

[1] http://flickr.com/photos/evamen/2375249026/in/photostream/
[2] http://flickr.com/photos/evamen/2374420061/in/photostream/
[3] http://flickr.com/search/?q=evamen
[4] http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content  
(admittedly UAAG is written in complex language. Now that I work for a  
user agent developer I believe even more strongly than I did that more  
care should be taken to ensure that it is easy to read and understand  
specifications like this). Have a look also at the draft of UAAG 2.0  
(bearing in mind that it is a first public working draft, especially  
principles 3.1, 3.2, 3.4 and 3.5 at  
http://www.w3.org/TR/UAAG20/#principle-perceivable

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Wednesday, 16 April 2008 15:41:15 UTC