Re: Discussion on Change Proposal for ISSUE-66

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