[html4all] Request for review of alt and alt value for authoring or publishing tools
Charles McCathieNevile
chaals at opera.com
Wed Apr 16 08:40:18 PDT 2008
On Wed, 16 Apr 2008 15:37:21 +0200, Harry Loots <harry.loots at ieee.org>
wrote:
> On Wed, 16 Apr 2008 14:40:18 +0200, Charles McCathieNevile wrote:
>> <harry.loots at 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
More information about the List_HTML4all.org
mailing list