Re: some reflections on @alt usage

Thanks al,

My only addition is that alt="" should be flagged for attention incase it 
was put there automatically without thought or understanding of its intended 
consequences.

----- Original Message ----- 
From: "Al Gilman" <Alfred.S.Gilman@IEEE.org>
To: "W3C WAI-XTECH" <wai-xtech@w3.org>
Cc: "Ian Hickson" <ian@hixie.ch>
Sent: Tuesday, April 22, 2008 4:54 PM
Subject: some reflections on @alt usage



Reference: discussions of if and when the HTML5 specification should
tell authors to omit the @alt attribute, in the TR page draft at
http://www.w3.org/TR/html5/#the-img
.. and on this list.

Caveat 1: these are personal perceptions, not PFWG consensus

Caveat 2: I'm not going to try to give direct answers to the questions
that have been asked of PFWG.  I want to get some ideas out here that
address

(1) the 'feasible range' of a solution that all can live with

(2) the considerations that should be weighed in selecting a solution
within that feasible region.

** Summary:

* Cautions to editor:

1. The two examples offered for when a missing @alt might be the highest
and best markup available to the encoding sofware are ill-chosen.
They don't pass accessibility review as exemplifying the logical
conditions they are supposed to represent.

2. Don't say that this markup advice is for *important* images where
you don't know what to provide as a text alternate.  The 'important'
restriction is not appropriate.  The same markup approach should
apply for
unimportant images where you don't know that they are unimportant.
And make
it clear that the "human didn't bother" case is included.  It probably
represents the lion's share of the missing @alt attributes out in the
wild today;
so if we are going to try to address this as a common case,
unknown-to-be-decorative images should be included and not just other
unknown-what-to-say images thought to be 'important.'

* Cautions to the 'required is required' advocates:

3. The HTML5 draft is attempting to provide markup for what has
in practice been a common case: insufficient human thought has
been applied to the web-posting of an image for there to be a
known-good @alt value for that image.  That is to say, known
to the software module that is performing the markup encoding of
the content on its way to the web.  While there are downsides
to eliminating the simple statement "@alt is required," there are
upsides to the fact that the information provided to client-side
repair activity is of greater accuracy.

4. WAI has at least in some cases set a precedent for a prominent
informative reference to the WAI Recommendations as an acceptable
alternate to a copy-in of WAI Guideline provisions or a normative
reference to them.

for example SpecGL:
http://www.w3.org/TR/qaframe-spec/#address-other-topics

5. The real pain if HTML5 is more subtle about "text alternate"
requirements than just saying "@alt is required; Do It," comes
in accessibility education.  But don't underestimate the power of
running code.  If the author's tools flag @alt problems more
consistently; that replaces many many hours of lecture time in
the classroom, in terms of "good text alternates" that wind up
in the live Web.  It matters less what reference appears in the
footnote at the end of the discrepancy-explanation.  More that
the author gets alerted to the discrepancy more consistently.
HTML WG and HTML5 specification can help us
get there; do consider reasonable alternatives.

** longer, stream-of-unconsciousness mutterings

+1 to "web pages where the page doesn't know what to say as the @alt
value are common."

Note 1:  The language in the 22 January 2008 draft poisons the debate
by talking
only about "important" images where a suitable @alt value is not known.
That is misleading.  Most of the time, if you know the image is
important,
you have something better to say that "I don't know" by way of an @alt
value.  If you don't know what to say in @alt, you don't know if it is
'important' or not.  If the specification is going to state conditions
under which the @alt attribute is to be omitted, they should be "I don't
know" conditions spanning both important and decorative (but unknown
decorative)
images as well.

in: http://www.w3.org/TR/html5/#the-img
..where it says "A key part of the content that doesn't have an
obvious textual alternative"

Note 2:  In particular, most accessibility experts will not agree that
the photo upload use case is one where the authoring tool could not
come up with something that is better than nothing.  So the example
adds more heat than light.

Something on the order of

$userScreenName's Nth photo [ uploaded | taken ] $date [ $time ]

is something that uses information the generator of the HTML access
page for the uploaded image files has available and is arguably better
than nothing.

-1 to "bad @alt is worse than no @alt in many situations"

.. could not confirm this with the user community.

+1 to "required @alt is persuasive in training sessions"

Accessibility staff get limited time to educate developers.  They
don't have time for subtleties.  A clear DoIt tends to get action.

.. interpretation:  If @alt is not required, there is damage to the
accessibility outreach effort; some mitigating measures to offset
this should be considered.

Possible mitigating measures include things like:

(a) where the specification says that the missing @alt is undesirable,
it instead say is contrary to the applicable W3C Recommendation and
cites WCAG.

(b) in its processor provisions, HTML5 says that authoring tools
should provide a conformance checking function, and that in the shipping
default configuration of that conformance checking function, a
missing text
alternative (Note 3) will be flagged as a defect, with a help trail
that leads
back to the WCAG standards.

Note 3: the test should be that the "text alternative"
http://www.w3.org/TR/WCAG20/#text-altdef
as described in WCAG2 is not defined by the markup.  It is within the
purview of the HTML5 specification to provide that the legend of a
figure
structure is in the search list to be the text alternate for the image
in that structure, for example.  The text alternative will frequently
be provided by @alt but WCAG provides for other markup means in
principle.

On the other hand...
+1 to "Missing @alt cues repair, and this is useful."

Present client-side processing is centered around the following pattern:
if @alt="" the image is ignored.  if @alt is not there, processors may
and sometime do attempt some sort of repair.  The filename of the image
is commonly used as a substitute.

Note 4:  In the case of the Specification Guidelines (SpecGL) the WAI
agreed that
the SpecGL document should not re-ordain what was already ordained in
the
WAI Guidelines, but rather should include an informative but conspicuous
reference to the WAI Guidelines at critical points of relevance.

http://www.w3.org/TR/qaframe-spec/#address-other-topics

This is a precedent for having the HTML5 specification cite the WCAG
requirement for a text alternative; rather than substituting a different
requirement, or making a normative re-statement that creates two
documents
purporting to be the origin of the same requirement.

Note 4:  The Rorschach test example is also not a valid example of what
it attempts to illustrate.  It is clear from the following WCAG language

<quote
cite="http://www.w3.org/TR/2007/WD-WCAG20-20071211/#text-equiv-all">
  (3) a test or exercise that must be presented in non-text format,
(4) primarily intended to create a specific sensory experience, then
text alternatives at least provide descriptive identification of the
non-text content
</quote>

.. that there are appropriate things to say in a text alternate in this
case, and why not use @alt to say them?

In other words, "ink blot" or "test stimulus" would, either of them, be
appropriate @alt values and in 'no way' is there is no way to provide
an appropriate text alternative.

Al

Received on Tuesday, 22 April 2008 21:30:18 UTC