- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Sun, 24 Jan 2010 18:35:36 +0000
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Shelley Powers <shelley.just@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Matt May <mattmay@adobe.com>, John Foliot <jfoliot@stanford.edu>, HTML WG <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
- Message-ID: <55687cf81001241035s46ed390bk70ff599b0a2a5b9f@mail.gmail.com>
hi maciej, >When alt is completely missing, most browser + screen reader combos will read the filename. That is simply a fact. for JAWS and window eyes at least if the alt attribute is missing the usual behaviour is to ignore the image. Only if the image is the sole content of a link will the AT announce something else (e.g. src attribute content). there is more detail available here: http://www.paciellogroup.com/resources/articles/altinhtml5.html regards steveF 2010/1/24 Maciej Stachowiak <mjs@apple.com> > > On Jan 24, 2010, at 8:04 AM, Shelley Powers wrote: > > > On Sun, Jan 24, 2010 at 9:52 AM, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: > >> On Sun, Jan 24, 2010 at 12:39 AM, Matt May <mattmay@adobe.com> wrote: > >>> On Jan 23, 2010, at 9:46 PM, Tab Atkins Jr. wrote: > >>>> On Sat, Jan 23, 2010 at 9:24 PM, Shelley Powers < > shelley.just@gmail.com> wrote: > >>>>> Then there's the issue of performance -- authoring tools only have to > >>>>> try to determine the alt text once. Do we really want every user > agent > >>>>> to attempt the same process every time the web page is opened? For > >>>>> every image? > >>>> > >>>> What's the alternative? If neither the author nor the authoring tool > >>>> fills in the alt-text, do we just shrug our shoulders and say "Sorry, > >>>> blind people, guess you're out of luck."? > >>> > >>> I don't think Shelley is to blame for how the web has functioned up to > this point. (If she is, I'll invite her to the CSUN Conference to > apologize.) I'd also like to remind you that not only is this kind of > functionality not in any shipping browser, I'm not aware of anyone who's > working on it. If you want to frame it that way, do your thing, but it seems > to me that you're being unnecessarily adversarial here. Her point is clearly > something user agent developers will encounter if they implement any repair > techniques on images. > >> > >> ? This functionality *is* in shipping browsers, though it's very > >> limited. Right now they may 'repair' missing alt-text by subbing in > >> the filename. They don't do OCR or statistical analysis on the image, > >> but this can easily become reasonable to do in the future (or even > >> now, for ATs that *rely* on alt-text - I expect OCRing images to give > >> a pretty decent benefit). > > > > The use of the filenames typically happens with the authoring agents. > > File names, or titles of post are fairly common. And again, when the > > author sees the result, they are more likely to do the correction when > > the material is posted. > > When alt is completely missing, most browser + screen reader combos will > read the filename. That is simply a fact. What authoring tools do is > interesting, but doesn't factor into it. Using *no* repair techniques is > something that no reasonably accessible browsing solution does. (Of course, > many image filenames are terrible, and screen readers don't pay attention to > whether they have something human readable, but that's exactly why better > repair techniques are worth considering. Try using a screen reader sometime, > it is quite educational to see what the experience is like.) > > > > > And this action occurs once, when the material is created. Think about > > the CPU usage if Chrome performs OCR on every single image in a photo > > gallery that don't have the alt text. Frankly, no user agent would do > > this -- it would be irresponsible, and a misuse of the user's > > computing resources. > > A sane implementation would do it only when an assistive technology that > needs the text is being used, and only on demand. That's how substituting > filenames works - doesn't bother to truncate the URL into a filename until > that particular image is visited. The way screen readers typically work, you > have a virtual "cursor" that's over some place in the document, and that's > the only place you need full info for at that particular moment. Also, OCR > is not actually that computationally expensive. > > > And then one browser does this, another does that, a screen reader > > does a third option, another user agent does a fourth -- this is what > > we want? I will repeat: we are better off with them not doing > > anything. > > Screen readers do all sorts of different things today to adapt content that > is not properly accessible. And that's ok. It's a quality-of-implementation > issue. > > > > > In addition, OCR can not determine author intent. We, the visually > > capable can, when we look at the entire image in context, because of > > some silly expression, or some other obviousness with the image. All > > OCR can do is a vague translation of some of the contents -- the > > context is completely lost. It does not convey author intent. It > > can't, it never will. > > Nor does the filename typically convey author intent. But screen readers do > in fact read it when alt is missing, and things are ok. > > > > > The alt text is an author responsibility. Anything else undermines this. > > > >> > >>>> It seems pretty obvious that the correct solution for accessibility is > >>>> to address this issue at *all* levels. The earlier the better, but > >>>> it's not excusable to fail users with accessibility needs when we > >>>> *can* do something to help them. > >>> > >>> The creation of @alt content is the sole responsibility of the author, > and facilitated by the authoring tool. @alt is the product of what the > author intends to communicate. > >>> > >>> Once it has left the author's control, anything created anywhere else > in the lifecycle of that content (server, user agent, assistive technology, > display) is a degradation, because it is trying to reconstitute the author's > intent, without ever knowing it for certain. None of us are saying that > browsers should be prevented from doing more for users. The absence of a > MAY, which was what the original issue here sought, does not equal the > presence of a MUST NOT. > >> > >> Sure, a decent inferred alt is still worse than if the author supplied > >> some alt themself. But no alt is worse than that. The only thing > >> worse than no alt at all is a completely wrong inferred alt. If it > >> was reasonable to think that most such inferred alts would be > >> completely wrong, I'd agree with you, but it's not. There are very > >> reasonable methods of inferring alt text that work well on many > >> images. > >> > > > > They do not exist now. > > > > I suggest that the browser companies work with the accessibility task > > force, to see about where this type of information can be cleanly > > incorporated, and into what document. In the meantime, let's leave the > > alt attribute cleanly defined. > > > >>>> I'm just behind a slight softening of the spec text, as Lachlan and > >>>> Maciej have suggested. > >>> > >>> Between the two, I prefer Maciej's idea of stripping out the specific > advice and pointing to UAAG. More importantly, though, I think this advice > belongs somewhere in Section 5 ("Web browsers"), not connected to @alt. What > is being discussed here has more to do with browser functionality than it > does with one specific attribute (especially given that it applies equally > to image inputs and imagemap areas, and that OCR techniques could for > example also be useful in the case of background images, canvas and plugin > content as well). > >> > >> That doesn't seem disagreeable. > >> > > > > Then it seems we are in agreement on this. Again, though, I would > > recommend that those concerned work with the accessibility group to > > determine what information should be presented, in what document, and > > where in the document. > > I'm kind of confused. On the one hand, you say it would be terrible for > browsers to every use repair techniques for missing alt, but on the other > hand, here you say that it's fine to allow repair techniques and cite UAAG's > info on the topic. > > Regards, > Maciej > > > > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Sunday, 24 January 2010 18:36:57 UTC