Re: some reflections on @alt usage

Al Gilman wrote:
> * 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.

Ok, but I guess you are suggesting that this will happen at the 
author/validator level, as passing this information down the chain to 
the end user will probably be pretty useless. If we look at the 
authoring process as a chain and a flag or warning from a validator or 
even a client side application that deals with graphical content, helps 
the author(s) fix it, then fine.

> 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.  

Yes, this is needed and in many ways *has* been going on for many years, 
hence my own reservations about making @alt optional as IMO it sends the 
wrong message and /may/ undo some of the good work that has been done to 
instill the habit for authors of using @alt.

>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.

I don't really follow. If I am parsing this correctly this comment seems 
to say that the fact that a tool will flag an error or message about 
missing @alt then this is a good way of educating people as to the 
importance of @alt? And that this would not happen if the images have 
@alt in the first place? This doesn't make sense to me.


> ** 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.  

Good point. But surely this is exactly what @alt already does. The 
quality aspect is a judgement that is subjective - and left up to author 
to decide. This is the beauty of it, that it can be used for both kinds 
of images (as such) and this is in the hands of the author.

>>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.

Ok but suggesting that there are conditions where the @alt can be 
omitted is analogous to suggesting that there are circumstances where 
its ok to upload blank graphics, or images with nothing in them (in 
principle).

> 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"

I agree.

> .. could not confirm this with the user community.
> 
> +1 to "required @alt is persuasive in training sessions"
> 
> Accessibility staff get limited time [...]
> +1 to "Missing @alt cues repair, and this is useful."

Where is the greatest load? What has been the most effective way of 
sharing examples of best practice? Though showing examples of how things 
work and work well, or by showing broken examples?

> 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.

Yes, and these heuristics need to be improved and modified. For example, 
if through some kind of UA preferences a screen reader user could choose 
to /not/ trigger heuristic evaluation when an image with no @alt is 
given focus then this could be a good thing for end users. Then the user 
has made a choice to be informed of each instance of a graphic or not, 
rather than having a useless heuristic make a stab at it. If they can at 
least choose /not/ to, then the idea of an optional @alt would be more 
appealing - in the light of this use case.

> 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.


+1, as writing a description for these images is an entirely subjective 
assessment and ultimately a quality judgement used in psychological 
assessment etc, and is not suitable to illustrate some deficiency in 
what @alt should be in principle used to do.

Cheers

Josh

Received on Wednesday, 23 April 2008 22:14:25 UTC