Re: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption
On Wed, 4 Sep 2013, Jukka K. Korpela wrote: 2013-09-04 0:09, Ian Hickson wrote: To a user, even “(an image)” is better than lack of alt attribute I disagree. The lack of an alt attribute can be used by user agents to substitute the string (an image), in which case it is the same, or it can be used to do far more, e.g. image recognition, OCR, etc. This isn't academic, these technologies exist today. There is nothing that makes that makes that impossible, or more difficult, if the element has an alt attribute. If the element _has_ alternative text, the presumption is that that text is the equivalent of the image, and therefore replacing that text with the results of OCR is likely a step backwards. That is, in the ideal scenario, a user shouldn't have to ever know they were missing images; nor should they in any way suffer from missing those images, because their textual alternatives would convey the same information seamlessly. It's only when the alternative text is inadequate that you want to be falling back to OCR, etc. And the best way to indicate that it's inadequate, is to not include it at all. If you mean that programs would actually do such things if and only if the alt attribute is absent, then this is very speculative. Let’s worry about that when browsers are actually capable and willing to do such things at all. They are capable now; like I said, this is not academic, this technology exists and is deployed by some of the browser vendors (just not in the browser products yet). We are worrying about it now because we put it off until now and now is the time to worry about it. There is an essential difference between lack of an alt attribute and a more or less generic value used for it, as in alt=(an image) or in alt=(image: horse5) (automatically generated e.g. from an image URL that ends with horse5.png) or in alt=(photo of Hixie). Lack of the alt attribute says absolutely nothing about the image; it might represent a word as an image, or be pure decoration, or be so complicated that writing a textual alternative would be major challenge in content production. Someone who hears, says “image – horse five” at least gets some idea of what the image is about, and even “an image” as opposite to whatever a speech browsers says about img ... alt= is an improvement: the user can know that the author tried to find a textual replacement for the image but couldn't. I disagree. It's not better to hear [image indication from AT] an image than it is to hear just [image indication from AT]. If you want to give it a caption, you can put it in the title=, where a competent AT can then say things like [image indication from AT] Image of Hixie, and a really competent AT can say something like [image indication from AT] Image of Hixie. A smiling face with brown hair and a beard. But if you have an alternative text of (photo of Hixie), then a UA that outputs that as [image indication from AT] photo of Hixie. A smiling face with brown hair and a beard would have to make the experience in _well_ written cases dramatically worse than ideal. For example, it would make a case like Multiply img src=theta.gif alt=π by two turn into something like Multiply [image indication from AT] Pi. A two dimensional line art picture of a table. By two or Multiply [image indication from AT] Pi. Pi. By two, which are both significantly worse than the ideal, which would at worst be Multiply [image indication from AT] pi by two and at best just be Multiply pi by two. To the non-validator user agent, that attribute means nothing. It's a non-conforming attribute with no semantics to any software outside content generators and conformance checkers. It is presented as a non-conforming attribute that can be used to get a clean validation report, i.e. to make a validator report a document as valid, as conforming. Correct. This is grossly illogical and misleading. Granted. Anyone who uses a validator has the right to know whether the document is valid or not, to the extent that this can be programmatically determined. And it is, if the attribute is not valid. Indeed. That's why validators are allowed to point it out. There's an explicit statement to that effect, and there's no explicit requirement to not report the missing alt= in the first place (the requirement is phrased the other way around quite carefully). Here's a proposal: The character U+FFFC OBJECT REPLACEMENT CHARACTER, which is “used as placeholder in text for an otherwise unspecified object” [the quote is from the code chart entry in the Unicode Standard] be used as the value of an alt attribute to indicate that it was not possible to write an adequate alternate text for the image. This typically means that the image comes from a source external to the system that generates the HTML document and the system cannot analyze it or otherwise find a
Re: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption
On Sat, 8 Jun 2013, Jukka K. Korpela wrote: 2013-06-08 0:13, Ian Hickson wrote: On Sun, 2 Jun 2013, Jukka K. Korpela wrote: The purpose presented is to avoid markup generators from being pressured into replacing the error of omitting the alt attribute with the even more egregious error of providing phony alternative text. This is rather speculative, and it seems to lead to various attempts that are more or less self-contradictory. It's not that speculative, your e-mail is a response to a markup generator implementor who feels pressured in exactly this way! And who wrote that generator-unable-to-provide-required-alt is... inadequate. Just because the solution is inadequate doesn't mean the problem isn't real. You were saying the problem wasn't real; I was pointing to a counterproof. I would be the first to agree that the spec isn't perfect. Authors of generators always have the option of generating things like alt=(an image), which can hardly be worse than lack of alt attribute. It's worse because it prevents authors from being able to find images that are lacking good alternative text, and because it makes it less likely that future user agents will try to automatically figure out what the alternative text should be (since one is already provided). To a user, even “(an image)” is better than lack of alt attribute I disagree. The lack of an alt attribute can be used by user agents to substitute the string (an image), in which case it is the same, or it can be used to do far more, e.g. image recognition, OCR, etc. This isn't academic, these technologies exist today. which is what generator-unable-to-provide-required-alt really means To the non-validator user agent, that attribute means nothing. It's a non-conforming attribute with no semantics to any software outside content generators and conformance checkers. To analyze which images lack good alternative texts, you need to look at the images in their context. It’s just wrong to assume that they can be identified using some simple automated analysis. If you don't write bad alternative text (like (an image)), but sometimes write no alternative text at all, then detecting images without good alternative text is the same as detecting images with no alternative text. Certainly, detecting images with present but bad alternative text is a much harder problem -- that's why we should discourage the use of bad alternative text such as (an image). And future user agents won’t try to figure out what the alternative text should be, any more than current browsers do such things. It is just wishful thinking to expect such processing, and if browsers tried to do such things, they would just mess things up. We are far closert to this than I think you realise. Try doing image searches in G+, for exmaple (assuming you have a lot of photographs in your G+ stream). Even with virtually no context, no captions, no incoming links from other pages, and so forth, G+ image search can return accurate results for searches like house, tree, cat, and so forth. It's not at all a stretch to imagine the next stage of this technology is the ability to describe an image. It won't happen tomorrow, maybe not even next year, but HTML is likely to be with us for decades more. On Tue, 18 Jun 2013, Steve Faulkner wrote: img src=... title=image If you have a caption from the user (as opposed to replacement text), then this is a perfectly valid option. It's as valid as the figure case, and means the same thing. the above statement is bad advice: browsers map title to the accessible name in accessibility APIs when alt is absent, so-- ...so the browsers are buggy. This is not unusual. File bugs. :-) Indeed, since you've demonstrated yourself able to write code, you could just go and fix the bugs directly. :-) This behavior doesn't appear to be due to a bug, its by design, the title attribute is used as an accessible name of last resort for all elements and its implemented pretty much in the same (interoperable) way in all browsers. That doesn't mean it's not a bug. Writing specs for the lowest-common-denominator is not the way we'll get a usable, accessible Web. We might sometimes be forced to when there are compat requirements with massively deployed content that Web author are relying on that prevent certain behaviours from being fixed, but this really doesn't apply in the case of ATs, since the vast majority of authors have never tested how their pages work in ATs. I don't understand what you are saying here, can you elaborate? Which part is unclear? On Thu, 20 Jun 2013, Martin Janecke wrote: Unfortunately -- although its verbosity is there to prevent any misunderstanding for its use -- it might leave the impression that a generator writing img src=...
Re: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption
2013-09-04 0:09, Ian Hickson wrote: To a user, even “(an image)” is better than lack of alt attribute I disagree. The lack of an alt attribute can be used by user agents to substitute the string (an image), in which case it is the same, or it can be used to do far more, e.g. image recognition, OCR, etc. This isn't academic, these technologies exist today. There is nothing that makes that makes that impossible, or more difficult, if the element has an alt attribute. If you mean that programs would actually do such things if and only if the alt attribute is absent, then this is very speculative. Let’s worry about that when browsers are actually capable and willing to do such things at all. There is an essential difference between lack of an alt attribute and a more or less generic value used for it, as in alt=(an image) or in alt=(image: horse5) (automatically generated e.g. from an image URL that ends with horse5.png) or in alt=(photo of Hixie). Lack of the alt attribute says absolutely nothing about the image; it might represent a word as an image, or be pure decoration, or be so complicated that writing a textual alternative would be major challenge in content production. Someone who hears, says “image – horse five” at least gets some idea of what the image is about, and even “an image” as opposite to whatever a speech browsers says about img ... alt= is an improvement: the user can know that the author tried to find a textual replacement for the image but couldn't. To the non-validator user agent, that attribute means nothing. It's a non-conforming attribute with no semantics to any software outside content generators and conformance checkers. It is presented as a non-conforming attribute that can be used to get a clean validation report, i.e. to make a validator report a document as valid, as conforming. This is grossly illogical and misleading. Anyone who uses a validator has the right to know whether the document is valid or not, to the extent that this can be programmatically determined. And it is, if the attribute is not valid. Here's a proposal: The character U+FFFC OBJECT REPLACEMENT CHARACTER, which is “used as placeholder in text for an otherwise unspecified object” [the quote is from the code chart entry in the Unicode Standard] be used as the value of an alt attribute to indicate that it was not possible to write an adequate alternate text for the image. This typically means that the image comes from a source external to the system that generates the HTML document and the system cannot analyze it or otherwise find a suitable text replacement. You could even add a statement like this: User agents that present the value of an alt attribute to the user may express the value of U+FFFC using a generic expression like “some image”. They may also apply technologies that process the image trying to recognize its content and then express the result suitably, e.g. “an unrecognizable image” or “an image of a horse” or (in the case of having recognized that the content is scannable as text) “Hello”. – It’s of course possible that people would then use alt=#fffc; to silence validators even when they could easily write real text there. But they can anyway use alt= for such purposes if they want to. Yucca
Re: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption
On Sun, 2 Jun 2013, Martin Janecke wrote: I'm in charge of a code generator and while it is not widespread at all, my opinion might be shared by others who make code generators: This new option is too verbose � especially for something that has no meaning for the document it is contained in. And it kind of sounds as if the particular generator using this attribute is more inapt than other generators who output img src=� alt=image As developer of a code generator I don't feel inclined to use this new non-conforming attribute instead of an inappropriate img src=� alt=image or It would definitely be unfortunate if you wanted to use that instead of img src=... generator-unable-to-provide-required-alt. img src=� alt= or This is, per the spec, a valid last-resort option for you to use (and if you have any reason to believe the image is decorative, it's the best option as well). img src=� title=image If you have a caption from the user (as opposed to replacement text), then this is a perfectly valid option. It's as valid as the figure case, and means the same thing. While I can imagine why an accessibility evangelist would want a conformance-checker-silencer to be as unattractive to use as possible, that really defeats its purpose, if it also deters code generator programmers. The goal isn't to make it unattractive per se, it's to make it obvious that it means that it was a markup generator that was forced into the bad position of having to output invalid code against its will, in such a way that an author wouldn't conclude that it makes sense to mark up the page this way in order to get around validators. Previously, conformance checkers had been silenced by a single meta name=generator content=� in cases of missing alt-attributes. This solution effectively removed any urge to use an inappropriate alt-text for me as a code generator developer. Yeah. As I recall, this approach wasn't popular with validators, amongst others. :-( I don't know whether someones writes something like �� which the following figure illustrates� instead of �� which is illustrated by fig. 3� somewhere in the text above a figure. But this difference decides whether using the figure element conforms with the spec. So a code generator can only use something which is structurally and optically identical to the figure element but does not have the theoretical requirement to be movable to a different place in the document, e.g.: div class=figure img src=� div class=caption�/div /div And here conformance checkers will complain about the missing alt-attribute again � If you use img src=... title=... it'll work (and be correct, insofar as anything missing alt text can be correct). On Sun, 2 Jun 2013, Jukka K. Korpela wrote: The purpose presented is to avoid markup generators from being pressured into replacing the error of omitting the alt attribute with the even more egregious error of providing phony alternative text. This is rather speculative, and it seems to lead to various attempts that are more or less self-contradictory. It's not that speculative, your e-mail is a response to a markup generator implementor who feels pressured in exactly this way! Authors of generators always have the option of generating things like alt=(an image), which can hardly be worse than lack of alt attribute. It's worse because it prevents authors from being able to find images that are lacking good alternative text, and because it makes it less likely that future user agents will try to automatically figure out what the alternative text should be (since one is already provided). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption
2013-06-08 0:13, Ian Hickson wrote: On Sun, 2 Jun 2013, Jukka K. Korpela wrote: The purpose presented is to avoid markup generators from being pressured into replacing the error of omitting the alt attribute with the even more egregious error of providing phony alternative text. This is rather speculative, and it seems to lead to various attempts that are more or less self-contradictory. It's not that speculative, your e-mail is a response to a markup generator implementor who feels pressured in exactly this way! And who wrote that generator-unable-to-provide-required-alt is... inadequate. Authors of generators always have the option of generating things like alt=(an image), which can hardly be worse than lack of alt attribute. It's worse because it prevents authors from being able to find images that are lacking good alternative text, and because it makes it less likely that future user agents will try to automatically figure out what the alternative text should be (since one is already provided). To a user, even “(an image)” is better than lack of alt attribute, which is what generator-unable-to-provide-required-alt really means. And in the case of user-submitted images, “(a user-submitted image)” might be even better. Lack of alt can mean just about anything; there are millions if not billions of images without alt attribute just because an author did not think of the issue. A generic text “(an image)” at least suggests that it’s a content image with no obvious alternate text. To analyze which images lack good alternative texts, you need to look at the images in their context. It’s just wrong to assume that they can be identified using some simple automated analysis. And future user agents won’t try to figure out what the alternative text should be, any more than current browsers do such things. It is just wishful thinking to expect such processing, and if browsers tried to do such things, they would just mess things up. Yucca
Re: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption
2013-06-02 20:21, Martin Janecke wrote: While I can imagine why an accessibility evangelist would want a conformance-checker-silencer to be as unattractive to use as possible, that really defeats its purpose, if it also deters code generator programmers. The purpose presented is to avoid markup generators from being pressured into replacing the error of omitting the alt attribute with the even more egregious error of providing phony alternative text. This is rather speculative, and it seems to lead to various attempts that are more or less self-contradictory. Lack of alt attribute is not a mortal sin, but neither should it be accepted when accompanied with special incantations. It is simply an error to be reported. Validators are being improved to let users silence errors by type. This should be enough to deal with the issue. Authors of generators always have the option of generating things like alt=(an image), which can hardly be worse than lack of alt attribute. Yucca
