- From: Charles McCathieNevile <chaals@opera.com>
- Date: Sun, 27 Apr 2008 11:51:15 +0200
- To: joshue.oconnor@cfit.ie, "Al Gilman" <Alfred.S.Gilman@ieee.org>
- Cc: "W3C WAI-XTECH" <wai-xtech@w3.org>, "Ian Hickson" <ian@hixie.ch>
On Thu, 24 Apr 2008 00:13:36 +0200, Joshue O Connor <joshue.oconnor@cfit.ie> wrote: > Al Gilman wrote: >> * Cautions to the 'required is required' advocates: >> 3. The HTML5 draft is attempting to provide markup for what has >> in practice been a common case: insufficient human thought has >> been applied to the web-posting of an image for there to be a >> known-good @alt value for that image ... While there are downsides >> to eliminating the simple statement "@alt is required," there are >> upsides to the fact that the information provided to client-side >> repair activity is of greater accuracy. > > Ok, but I guess you are suggesting that this will happen at the > author/validator level, as passing this information down the chain to > the end user will probably be pretty useless. If we look at the > authoring process as a chain and a flag or warning from a validator or > even a client side application that deals with graphical content, helps > the author(s) fix it, then fine. The idea behind making @alt optional is that having a *validator* warning ahs meant that tool makers above the author in the chain are putting destructively bad alt in, rather than failing validity. (Where "destructively bad" means that it does more harm than good - see below) >> But don't underestimate the power of >> running code. If the author's tools flag @alt problems more >> consistently; that replaces many many hours of lecture time in >> the classroom, in terms of "good text alternates" that wind up >> in the live Web. It matters less what reference appears in the >> footnote at the end of the discrepancy-explanation. More that >> the author gets alerted to the discrepancy more consistently. >> HTML WG and HTML5 specification can help us >> get there; do consider reasonable alternatives. > > I don't really follow. If I am parsing this correctly this comment seems > to say that the fact that a tool will flag an error or message about > missing @alt then this is a good way of educating people as to the > importance of @alt? And that this would not happen if the images have > @alt in the first place? This doesn't make sense to me. I don't think that is what the comment says, but it is a large part of what I am saying and think it does make sense. Let me put it another way: Today's (good) accessibility tools look for missing alt and say "you have a problem". They look for blank alt (alt="") and say 'make sure this image really is unnecessaryto understanding the content'. The best then also look for filenames and a few other identifiable things people use as defaults, by magic heuristics, and they say 'is there really nothing better you can say about this?'. The most basic test is "is there an alt attribute"? Every "generic" accessibility tool I have ever heard of checks that. If you just put *something* in, then the most fundamental test becomes useless. >> ** longer, stream-of-unconsciousness mutterings >> +1 to "web pages where the page doesn't know what to say as the @alt >> value are common." >> Note 1: The language in the 22 January 2008 draft poisons the debate >> by talking only about "important" images where a suitable @alt value is >> not known. Agreed. >>> If the specification is going to state conditions >>> under which the @alt attribute is to be omitted, they should be "I >>> don't know" conditions spanning both important and decorative (but >>> unknown decorative) images as well. > > Ok but suggesting that there are conditions where the @alt can be > omitted is analogous to suggesting that there are circumstances where > its ok to upload blank graphics, or images with nothing in them (in > principle). Well, that depends on the language. IMHO the specification should not say "It's OK to have no alt", but it should say "although no alt is bad, an alt that is made up for a default, especially generic labels like 'photo' or a null value, is generally far worse, so ommittng the alt attribute is the lesser of two evils". >> Note 2: In particular, most accessibility experts will not agree that >> the photo upload use case is one where the authoring tool could not >> come up with something that is better than nothing. So the example >> adds more heat than light. >> Something on the order of >> $userScreenName's Nth photo [ uploaded | taken ] $date [ $time ] >> is something that uses information the generator of the HTML access >> page for the uploaded image files has available and is arguably better >> than nothing. >> -1 to "bad @alt is worse than no @alt in many situations" > > I agree. I think this needs to be more nuanced. Poorly authored alt is better than nothing. But some stock phrase shoved in willy-nilly is not. The example above is (while important to today's web) extremely specific to a class of content. >> .. could not confirm this with the user community. >> +1 to "required @alt is persuasive in training sessions" >> Accessibility staff get limited time [...] I don't actually find this terribly persuasive. >> +1 to "Missing @alt cues repair, and this is useful." If Missing @alt triggers a warning taht you need to repair then it can be valuable. This discussion really boils down to a need to understand why the guys at Flickr, My.Opera, Picasa, and some other representative 3rd parties made the particlar decisions they made in each case. >> Present client-side processing is centered around the following pattern: >> if @alt="" the image is ignored. if @alt is not there, processors may >> and sometime do attempt some sort of repair. The filename of the image >> is commonly used as a substitute. > > Yes, and these heuristics need to be improved and modified. For example, > if through some kind of UA preferences a screen reader user could choose > to /not/ trigger heuristic evaluation when an image with no @alt is > given focus then this could be a good thing for end users. I was under the impression that the user *can* do this, although it depends on the software they are using. (My stylesheet for opera does do this, and I was thinking of making a couple of varieties - one that removed all the things with no alt and another the things with alt=''). >> Note 4: The Rorschach test example is also not a valid example of what >> it attempts to illustrate.... >> .. that there are appropriate things to say in a text alternate in this >> case, and why not use @alt to say them? Agreed. 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 Sunday, 27 April 2008 09:52:10 UTC