Re: some reflections on @alt usage

On 4 Aug 2008, at 6:37 AM, Ian Hickson wrote:

> On Tue, 22 Apr 2008, Al Gilman wrote:
http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0367.html
>>
>> 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.
>
> For background: The case for which alt="" was "optional" was the case
> where an image was to be included on a page without the author  
> knowing the
> contents of the image, and thus without having the ability to write
> actual alternative text.
>
> The spec has now been updated to use a different solution for this  
> case.
> Instead of saying that the alt="" attribute must be omitted if no
> alternative text can be provided, it now says that if no  
> alternative text
> can be provided, that the _kind_ of image (photo, diagram,  
> painting, etc)
> must be given in the alt="" attribute, surrounded by curly brackets.
>
> This enables ATs to detect when the alt="" text isn't actually an
> alternative, and allows them to then highlight such images to the  
> user, to
> indicate that an image is present but not in a useful form.
>
> I would very much appreciate a new review of the relevant parts of the
> HTML5 specification:
>
>    http://www.whatwg.org/specs/web-apps/current-work/multipage/ 
> embedded0.html#alt

PFWG is committed to continuing to review the state of HTML5 as it  
evolves.
Our working rendezvous point for the state of that evolution is

http://www.w3.org/html/wg/html5/

The move to include something of a categorical description when a  
highest-and-best
alternative is not available is (personal opinion) a positive
step.  The curly-braces syntax is questionable and under review in  
PFWG and
pros cons and alternatives I expect to be the subject of more  
comments anon.

>> 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.
>
> I don't understand what this means. How do things "pass accessibility
> review as exemplifying the logical conditions they are supposed to
> respresent"? Could you elaborate?

I did elaborate.  Elsewhere in the page.  You didn't associate.  Which
makes one of my points, sorta.

The two are the photo-upload scenario and the Rorschach test example.

In the photo upload case there are indeed better things that the site
can say than you admit (when considered with a good background in
disability access).  In the Rorschach test WCAG spells out what
you should provide as a text alternative.  Something that "appears  
somewhere else
on the page" doesn't meet the technical requirements for a text  
alternative,
as the user's working memory of what is on the page is limited.
  (more below)

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.
>
> Could you provide an example? When would there be an unimportant  
> image for
> which alternative text is required (i.e. it's not decorative) and for
> which the alternative text isn't available?

In the batch-upload scenario, the site wrapping the uploaded photos  
doesn't
know which files are key moments from the vacation and which are useless
blurs containing only a fuzzy swipe of the user's foot.  You don't know
it's important until you know what is in the image and what it  
contributes
to the story it is embedded in.

>> And make it clear that the "human didn't bother" case is included.
>
> According to HTML5, if the human didn't bother, the page isn't  
> compliant.

This is statement at variance with the attempt to cover the photo  
upload case.
I don't agree with this interpretation of the draft as posted.

>> 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.'
>
> How can the author not know if the image is decorative or not?

See discussion of photo-upload scenario above.  You are the ones  
separating
the actor (photo site software writer) that is coining the markup  
from the
other actor, the tourist who understands what is shown in the  
images.  It is
that split of the 'author' into two asynchronous actors that makes  
this possible.
If we had a FrontPage user in an interactive session inserting an  
image, the
story would be different.

>> 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.
>
> While this is clearly true (people calling themselves accessibility
> experts have stated they do not agree that a site accepting uploaded
> photos may not know what the image represents), I do not intend to  
> pander
> to accessibility experts. My goal is to make the spec actually improve
> accessibility.

in your own judgement, it would sound like.  Your judgement in these
matters would be more accurate if you listened more attentively to the
institution of the WAI.  Details below.

> Most readers of the spec won't be accessibility experts.

+3

> Since it is in fact verifiably the case that photo upload sites do not
> know what the uploaded photos are, I do not see a problem with  
> saying that
> such cases are cases where the sites could not come up with something
> other than "this is probably a photo".

Look back over my comments, and the kinds of information that you are
offering should be put in the curly braces.

The identity of the photo-uploader, the date/time when it was taken or
uploaded, an image sequence number, any tags attached, and labeling  
or other
text associated with groups it has been included in are significantly
helpful to the user.

My personal preference would be to get that info in the DOM in formally
specified relationship to the image, and then see what makes sense to
put with the image itself that is terse, and serves two functions:
inform the user about the image and distinguish this image from others.
It won't necessarily meet WCAG, but that doesn't mean it isn't better
than nothing.

>> 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.
>
> Sure, but that information is already on the page, it's not an  
> alternative
> to the image. It wouldn't be appropriate in the alt="" attribute.

You seem to be assuming that the use can associate this information  
correctly with
the image.  The world in which the speech-only user experiences a web  
page
is smaller than that.  If the relationship of the "also on the page"  
text
to the image is machine-interpretable, as for example 'legend' on  
'figure'
then the AT can help the user make the association.  In the absense  
of such
a formal relationship, the redundancy can be more positive than  
negative.

Simply being "somewhere else on the page" is not enough.  This is  
where your
ability to discern what constitutes actual accessibility is showing its
weakness.  Stay tuned.

>> .. interpretation:  If @alt is not required, there is damage to the
>> accessibility outreach effort; some mitigating measures to offset  
>> this
>> should be considered.
>
> Alt is now required even in these cases.

Yes.  Good.

>> 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?
>
> Because in that example, all such things are already said in a manner
> applicable to all users, not just those who cannot see the image.

Once again, 'just being there in the page' is not enough.  You haven't
escaped from your visual experience of the Web enough to understand  
that the
speech-only browser has to browse the page, and not "read all contents."
Seletive reading within the page is necessary for them to be able to use
the web in finite-enough time for it to be productive.
So these users skim pages in a different way, and the individual image
features have to be linked to their supporting information by formally
defined patterns to make the usability of the information survive.

> Including them in the alt="" attribute would show redundant  
> information,
> causing an unpleasant user experience for screen reader users.

Link stammer where the icon @alt and the link text say the same thing
immediately repeated is indeed annoying and wasteful.  It  can and  
should
be avoided.  But natural communication is rife with redundancy, and some
redundancy between a terse @alt value and something said at a distance
is beneficial, not detrimental.  If the something at a distance is not
machine-discoverable by a known pattern of relationships in the markup,
repeating some of this information in a way that is machine-associated
with the image is functionally essential.
>
> Thanks for the feedback.

Thanks for the iteration.

Al

> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'
>

Received on Tuesday, 19 August 2008 18:37:19 UTC