Re: some reflections on @alt usage

I wanted To clarify one point about my previous post:

It would not matter if some or all of the markup containers were empty
intially, as in the case of "comments" on a photo site. The important
thing is that relationships between and image and potentially related
content is defined, for if and when related text is added.

so for example:

<img aria-describedby="commentcontainer">

<p id="commentcontainer"></p>

would be conforming as the relationship is defined for when content is added.

Note:
please don't argue the use of aria-desribedby in  this case as it is
just an *example*, attribute use, some other more appropiate attribute
could be used in this situation.

regards
steve
On 24/04/2008, Steven Faulkner <faulkner.steve@gmail.com> wrote:
> 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
>


-- 
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:50:20 UTC