Re: some reflections on @alt usage

Hi Al,

taking up one point in particular:

>The text alternative will frequently be provided by @alt but WCAG provides for other markup means in principle.

If this point is agreed, then the question can be recast:

As an accessibility requirement should HTML5 require that some form of
related text is always explicitly associated with an image in cases
where the image does not have a "text alternative" provided.

for example these would be conforming:

<img aria-describedby="desc1">

<p id="desc1"> image caption text</p>

or

<h1 id="label1"> related heading text</h1>

<img aria-labelledby="label1">


or

<figure>
<img>
<legend>image caption</legend>
</figure>

or
<h1 id="label1"> related heading text</h1>
<figure>
<img labelledby="label1">
</figure>


or a new attribute

<img relatedtext="related">

<p id="related">text that is not a text alterntive but is about the image</p>

or

<img alt="pork scratchings" relatedtext="related">

<p id="related">From very humble beginnings as a regional food, Pork
Scratchings are now a national snack.  Recent press publicity and
mentions in such TV soaps as Coronation Street and Eastenders have
made Pork Scratchings a household name.</p>


BUT instances where there are no explicitly associated text would not:
examples

<p><img></p>

or

<figure>
<img>
</figure>

or
<p><img></p>
<p>text related to the image but not associated</p>


This goes some way to resolving the issue of "no alt being available"
as even in systems where the alt cannot be provided or is not
provided, the design of the system can and I would suggest most always
does incoporate relationships between text that is related to the
image. As predefined markup containers for different types or related
information are commonplace.
example include:
titles
descriptions
captions
comments,
notes
really any metadata.

If such distinctions between ,text alternative, description, label etc
are provided within the markup language (as they are or could be) it
would be easy enough for the AT to provide options to the user on how
they want the content announced in relation to an image.

This means that the important requirement that *some* textual content
that is relevant to an image is programmatically associated with the
image, even when the most desirable, a "text alternative" value
provided using alt attribute is unavailable.

regards
stevef

On 22/04/2008, Al Gilman <Alfred.S.Gilman@ieee.org> wrote:
>
> 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
>
>


-- 
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 Thursday, 24 April 2008 13:29:28 UTC