W3C home > Mailing lists > Public > wai-xtech@w3.org > November 2007

Re: Request for PFWG WAI review of Omitting alt Attribute for Critical Content

From: Joshue O Connor <joshue.oconnor@cfit.ie>
Date: Thu, 15 Nov 2007 11:33:15 +0000
Message-ID: <473C2E7B.2000009@cfit.ie>
To: Al Gilman <Alfred.S.Gilman@IEEE.org>
Cc: wai-xtech@w3.org

Hi Al,

Some comments to your post below.

> Let's see if there are some candidate points that we think might
> be agreeable.
> * good ALT is good practice
> I think that HTML WG and the WAI would all agree that images which
> are critical content SHOULD have text, at least an appropriate value
> of @alt and in some cases a further long description.

I certainly would. At the moment using @alt and @longdesc are the best
methods we have. Of course if another were to come along that was in
theory and also practice better, I would support that.

> *  function and need for @alt=""
> I think that the WAI would say an example where an image is
> an interpretation of the accompanying text material is an
> inappropriate use for @alt="".  This obscures the point that
> there are cases where *no text equivalent* is the right
> text equivalent.  Conventionally, this has been encoded
> @alt="".

These are cases where the user experience is in no way diminished by the
lack of an accessible text alternative, so yes. In as much as the user
can already glean sufficient information for the text within the document.

> WCAG2 doesn't say that this encoding has to be preserved,
> but the 'cowpaths' principles of the HTML WG suggest that
> to change it would be regarded as unnecessary thrashing of
> the authoring community.

IMO removing this method of hiding non-essential images could be a step
back, if there is evidence to indicate that it has become a method that
authors can easily use, are used to etc, which I would guess that it is.
However, to take a step back for a second,  in terms of paving the
cowpaths, I would rather examine whether this a method of marking up
content is actually best practice and not merely galvanize it if it isn't.

> ** points of confusion
> * critical content images, or all images
> The issue has been stated as "must critical content <img> elements
> have an @alt attribute set?" whereas the present and plausible
> candidate rule in the syntax would be "must *all* <img> elements have
> an @alt attribute set?"
> The point here is that "critical content images" is not a syntactic
> category.  Whether the image is critical content or not is a matter
> that requires human judgement -- it lies outside the realm of markup
> aside from the convention that @alt="" is used to signal that the
> image is best ignored in voicing.  But that's a semantic distinction,
> not syntax.

Yes. I agree that this is confusing as the value or use of an image is
often a subjective value judgement. However, maybe this is not really
the issue as much of this discussion has taken place around within the
context of  Flickr and other applications that deal with a large volume
of images that may or may not have appropriate ways of dealing with
images with no alt, inappropriate keywords and so on. So maybe this
point is moot and rather an appropriate mechanism or algorithm is need
in order for applications that are not successfully capable of making
these value judgements can still confer meaning etc to humans who use
assistive technology.

> * the issue at hand doesn't impact use of @alt=""
> Conscientious authors can use @alt="" the way we want in either
> case.  The markup coming from authors who care is unaffected.
> What is changed is the relationship between the markup coming
> from authors who don't care and the syntax rules of the specification.
> * the role of validation in gaining uptake of accessible markup
> This is an area where there are likely to be divergent assumptions
> among the people involved in the discussion.  We need to surface
> these assumptions.

Indeed. Merely validating is not enough either as there is still no way
to assess the quality of alternate content and whether its appropriate
etc. Unless there could be some context sensitive validator developed
which parsed webpage content  and checked it against some  appropriate
schema and looked for alt text etc that it could flag to the user as
being inappropriate or likely to be inappropriate therefore generating
an error or a flag to the author.

> One perspective is that the web has exploded with a muddle-through
> level of conformity to spec, but not strict conformity to spec.  When
> we got onto this topic during the Plenary session, Dan Connolly
> volunteered that the fraction of spec-conformant HTML on the web
> was "zero to several decimal places."


> The other perspective is that the language specification is the W3C
> authoritative statement on what is right and "nothing happens unless
> it is a MUST."
> I think we have some talking to do before reaching an agreement on
> this topic.
> One possible outcome is that the syntax does not require @alt but
> that the specification says that all critical content <img> elements
> SHOULD have a meaningful @alt set and that decorative <img> elements
> (steal exact wording from WCAG2) SHOULD have @alt="".

And here is the disconnect or at least a potential area for confusion.

> This could be viewed as too weak a statement of principle,

It could and the result could be that authors think it is therefore
unimportant and not understand the context of the suggestion and its

> but on the
> other hand, the HTML WG is trying not to write a specification that
> is almost-universally violated.

There will still be lazy authors, WYSIWYG jockeys and the like
regardless. IMO how all of this effects the end user and in particular
people with disabilities using AT is of prime importance. Of course
authors are still important :-)

>We in accessibility need to hear them
> out, and see if our campaigns are actually made more difficult by the
> absence of the MUST in the syntax, or if the hard stuff is there
> anyway, independent of the syntax rule.

The use of a MUST in the syntax sends a message of importance to the
author. On another level, what happens if the MUST attribute is missing
or present is out of the hands of the authors and in the hands of the
browser makers, etc. But I think at the author level the signal they get
from the way the spec is worded has an impact on them and how they work.

> But I seriously doubt
> that we will get them to say browsers should fall over and fail to
> process a page where there is one <img> with no @alt.

Of course it should not be a show stopper and stop the page from rendering.

> The differences in estimation of author behavior has to do with how
> much making the attribute a syntactic requirement moves authors
> from case 1 to 2b or to 2c.

At the very least, if they are made aware that it is a requirement they
are then aware that it has some purpose, some value. The logical thing
is then to ask "What is it for"?, "Why has it value?" and this will
hopefully spur them on to try and understand the subtleties of its use.

Received on Thursday, 15 November 2007 11:33:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:44 GMT