- From: Al Gilman <alfred.s.gilman@ieee.org>
- Date: Fri, 22 Aug 2008 17:23:12 -0400
- To: Dave Singer <singer@apple.com>
- Cc: HTML WG <public-html@w3.org>, Doug Schepers <schepers@w3.org>, Karl Dubost <karl@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
On 22 Aug 2008, at 5:50 AM, Dave Singer wrote: > > Al, thanks for the thoughtful reply. A couple of comments below... > > At 11:06 -0400 21/08/08, Al Gilman wrote: >> [reordered a bit] >> On 21 Aug 2008, at 8:26 AM, Dave Singer wrote: >> >>> >>> We just went through extensive discussion and communication with >>> other groups to work out how to make alt mandatory, and make it >>> clear how to abide by that mandate in a whole host of situations, >>> with examples. >> >> Your editor, at least, give ample evidence of not having >> understood what we told you. What >> you say below suggests you don't either. > > There seems to be plenty of misunderstanding floating around, yes. > (I didn't notice where you highlighted a misconception on my part, > though.) > > The detailed comments you supplied were informative and helpful, > much more so than the general comments I've previously seen, thank > you. > > (For what it's worth, and avoidance of doubt, I am not happy with > there being any situation in which alt is optional, and I'd like to > think of a way of dealing with the escape in 4.7.2.1.10, for example). > >> The injection of the curly braces inside the value of @alt would >> appear >> to be an actual problem with the current text. > > Well, this was one of the very few ideas that came up to deal with > the situations where alt text is not known at the time of HTML > generation. Now, I know that we'd all prefer that such situations > not arise, but then I'd also prefer that cars not jump traffic > lights; I still look both ways when crossing at a green pedestrian > crossing signal :-). > >> http://www.w3.org/html/wg/html5/#alt >> >> We haven't seen how it is of any real use to the user or the AT. > > Let's see if I can review. > > As I recall, what seems to happen today (when alt text is > unavailable at the time of HTML generation) is one of > * missing alt attribute (a conformance violation) > * an empty alt attribute (implies, incorrectly, that the image is > decorational or already described) > * some 'nonce' string for the alt text (such as alt="this is an > image"), which deliberately obscures the fact that alt text is > unknown. > I think, and I would have thought you would agree, that these are > all rather unsatisfactory Let's see if I can clarify what I think the cases are. If the agent putting the markup together really doesn't have a clue (not the Flickr case) then I don't really have a problem with it being absent and non- conforming. And since the browser isn't going to care, the author doesn't need to either. If they take the syntax error that says "you need an @alt value" we should teach them to think, and if they really can't say anything meaningful, just shrug and move on. [Note Flickr has demonstrated that photo-sharing sites can already do better than that.] In Ian's favorite case (not successfully isolated by the rule in the draft) of a page with one photo on it (the only <img>? not likely) and all about that photo, I would consider a 'nonce' text alternate of @alt='the photo' would be pretty good. And under these circumstances a null alt of @alt="" wouldn't be too bad. Of course an @aria-labelledby pointing to the page title which holds "what might have been a figure legend but isn't" would be better. However in the real Flickr case there is known metadata about the photo and Flickr has been synthesizing an @alt value. Call what Flickr has been doing 'something.' That 'something' is better than nothing and better than '{something}'. If there is a real desire from the AT industry for a clue that the value of @alt is a repair value and not an authored value, this should be folded into the requirements for @role or some other indication. You could also convey this with EARL published about the page. http://www.w3.org/TR/EARL10/ >> It adds >> either processing burden on the AT to strip the braces or serious >> nuisance >> in the spoken audio for the user to listen the TTS announce them. >> If the >> best the author can do is sub-standard, but better than nothing: >> just do it; >> don't apologize. > > This seems to suggest that you *prefer* something like alt="this is > an image", but I find this hard to believe. (discussed above) > >> >> Is there any evidence from AT builders that they feel the distinction >> made by the curly braces would be valuable enough in tuning the user >> experience that they would argue for the inclusion of the braces? > > > But at the very least, a UA given a value in {} can now know that > (a) the image would ideally have had alt text and (b) it does not. No, it does have a text alternative for the image. Not perfect, but it has something. It is suitable as a replacement for either of the two replacement use cases I know about 1) when image loading is turned off and the text is presented in an image border 2) when a screen reader reads the page, and inserts 'image' and the @alt value in the TTS stream. http://tinyurl.com/56mhhb > It can, in some sense both (i) relay the HTML generator's apology > and (ii) try some kind of recovery action. Yes, this would involve > improving UAs, I agree, and specifically AT UAs. I'm sorry to hear > you think it unlikely that AT UAs would wish to handle being > explicitly informed of the case when alt text was known to be both > desirable and unavailable. A text alternative is not unavailable if a repair has been attempted. > In general, this falls into the category of telling the UA and > hence the user the truth, on the grounds that the truth, even if > it's unpalatable, can generally be handled better than lies or > obfuscation. This is how it ought to be of "real use to the user > or the AT". I learned a long time ago that "The people with the answers see the world through a more fine-grained reticle (system of categories) than the people with the questions." Your 'truth' is observed with regard to a fine distinction that in most actual cases the user would prefer to don't-care. > (I must admit I had some idea that the values inside the braces > would come from some sort of 'normal set' of suggestions, so that > UAs could, if desired, recognize them and do the best they could > for recovery. That's not the current state of the draft, and I had > an offline exchange with Ian on that.) Defined values, such as which of the WCAG sub-cases to SC 1.1.1 applies, and other ideas along those lines, are grist for a metadata discussion about @role and other metadata vehicles. But don't overload it on @alt. @alt should contain something to say. Without layers of micro-syntax. If the UA needs to attempt repair, it is better decided on the user side than pushed from the server. "Just say what it is, not what to do with it" is germane, here. The user side can always attempt a repair; doesn't need permission from the server. > I'm sure if there are better ideas, we are all listening. I'm now convinced that _you_ are listening. Many thanks. Al > -- > David Singer > Apple/QuickTime >
Received on Friday, 22 August 2008 21:23:54 UTC