Re: some reflections on @alt usage

On 19 Aug 2008, at 5:35 PM, Ian Hickson wrote:

>
> On Tue, 19 Aug 2008, Al Gilman wrote
>
>> In the Rorschach test WCAG spells out what you should provide as a  
>> text
>> alternative.
>
> Could you elaborate? I haven't been able to find where in the WCAG
> documents it is made clear what could be said that would actually help
> accessibility here.

In the material that has been clipped out from the initial post in *this
thread*
http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0367.html
.. you were told:

<quote
cite="http://www.w3.org/TR/WCAG20/#text-equiv">
Test: If non-text content is a test or exercise that must be  
presented in non-text format, then text alternatives at least provide  
descriptive identification of the non-text content.

Sensory: If non-text content is primarily intended to create a  
specific sensory experience, then text alternatives at least provide  
descriptive identification of the non-text content.</quote>
</quote>

I could see classing the Rorschach stimulus image under either of  
these with the same conclusion: say something.

For more guides to useful references keyed to issues in HTML5 see
Laura Carlson's recent post at
http://lists.w3.org/Archives/Public/wai-xtech/2008Aug/0107.html

>
>
>>>> 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.
>
> In the context of an HTML document, though, those pages are  
> objectively
> important regardless of whether they may be unimportant in the  
> context of
> the wider photoset. They are the "content" of the page, which is  
> important
> by definition.

No.  There is no objective importance.  Importance is for the user to  
revise
as they browse the page.  The author gets to express their estimate  
of the
importance.  In the case of the bulk upload, the author hasn't taken  
that
opportunity.  The page template's guess that the wasted exposure is  
important
is meaningless.  As is your 'definition' that it is important.

>>>> 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.
>
> None of the photos are decorative in that example, and you know this
> ahead of time, before the photos have even been uploaded.

No, the photos were bulk uploaded.  They are all the images the camera
retained.  You don't know how important they are because the person
who shot them has not reviewed them before they went into the online  
system.

>> 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.
>
> I have no idea what what that means. Could you explain it in simpler
> terms? I still don't know how an author can not know if the image is
> decorative or not.

When they haven't looked at the image, only pressed the shutter button
and uploaded the camera contents after three weeks of pressing the
shutter button.  It is the bulk-upload case.  It's your use case.

The 'not possible' case has been justified on the basis of "we have
to tell the site pasting the user's undocumented image into a pro-forma
page what to do with the attribute."  This is what I mean by you are
splitting the author.  The original author is the vacationer pressing
the shutter button.  But they don't look at the image or add text to
it.  The site puts it into some HTML pages.

Do these have to be conforming?  To what?  Those are interesting
questions.  What is the point of authoring directives in HTML5 if there
is no follow-through?  The browsers are instructed to ignore what it
directed at the authors.

>>>> 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.
>
> The spec says:
>
> # When it is possible for alternative text to be provided, for  
> example if
> # the image is part of a series of screenshots in a magazine  
> review, or
> # part of a comic strip, or is a photograph in a blog entry about that
> # photograph, text that conveys can serve as a substitute for the  
> image
> # must be given as the contents of the alt attribute.
>  -- http://www.whatwg.org/specs/web-apps/current-work/#a-key
>
> That seems pretty cut and dry to me.

It has a gratuitous "when it is possible..."  So far all the 'not  
possible'
examples offered are either contradicted by what WCAG says should be
in the text alternative, or a closet 'didn't bother' as when you say
"We have to tell the site how to format it when the uploading user
didn't provide anything."

Don't get me wrong.  My personal opinion is that we should still look
at what is the best non-conforming-to-WCAG thing to do in repair cases
such as the bulk upload.  And there is a live question as to whether
this belongs in HTML specification or WCAG techniques.  But we should
take it on.  However with a note that this is a "close, but no cigar"
situation as far as meeting accessibility standards.

> Could you cite the part of the spec
> that says that "not bothering" is a valid reason to not include
> alternative text? If there is anything that can be read that way, it
> should be fixed.

"When it is possible..."

>>>> 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.
>
> With all due respect, I would rather base my judgements on verifiable
> research and on logical arguments than on blanket assertions that seem
> counter-intuitive.

Well, the assertion that the un-screened image is 'objectively important
in the context of HTML' while in fact its importance is unknown in  
human terms
is more 'blanket assertion that seems counter-intuitive' than  
'verifiable
research' or 'logical argument.'

>> 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.
>
> That information is significantly helpful to all users, and should  
> (and
> is) exposed to all users.
>
>
>> 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).
>
> Could you elaborate on this? What could be said that isn't already  
> being
> said?
>
>
>> 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.
>
> This is so diametrically opposed to my own experiences that I would  
> need
> significantly more evidence of this to be convinced of it. Do you  
> have any
> research you could show to demonstrate this remarkable assertion?
>>

This sounds as though your intuition is conditioned by your own  
experience,
and not from listening to blind or dyslexic users, or the teachers of
severly learning disabled people.

Ask Joshue <joshue.oconnor@cfit.ie>.  He has spent far more time with  
PWD
using computers than you or I.

>> 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.
>
> I think this dramatically undersells the user. If a page contains a  
> title,
> and a comment, and an undescribed image categorised as a photo, users
> would have no trouble associating the description comments and the  
> title
> with the photo.

Yes, but the rule is not limited to such simple pages.

It would apply to an image that appears in a typically cluttered start
page.  And it is for that latter worst case that we should frame the  
rule.

>> 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.
>
> Merely having the image on the page links the information to the  
> image.
> Why is this not sufficient? I do not understand what user interface  
> you
> are imagining that would make this more usable than what we have now.
> Could you elaborate? Why would a sighted user have less trouble
> associating disparate information in a Web page with an image on  
> the Web
> page than a user without image support?

The eye flits around the screen and the user gets a 40,000-foot idea of
what is there.  The ear can't.  It takes longer to listen.  This is why
at the page level, screen readers offer a synthesized summary on  
entry to
a page.

So the eye picks up associations cued by vertical alignment, box  
outlines,
and the like that are unavailable through the linear TTS readout.

On the other hand, the screen reader does verbalize some of the  
structure
such as saying 'link' to cue that what follows is a hyperlink.  These
choices as to what to say and what to left unsaid are best left to the
assistive technology and their user-preference settings.

But if it's in the formal structure it is available for the AT, the
PWD user's desktop, to frame skimming modes and drill-down capabilities
that make all the information available in a usable way.

One of the things that assistive technology supports is a drill-down  
query
for more information.  There are commands that, when on a table cell,  
read
out the text content of all the cells found by following @headers  
references.

The assistive technology will use labeling on contexts to orient the  
user
after a change of context.  And to clarify terse, context-dependent  
labels
on low-level items.

Screen reader user skim pages by tabbing through and listening to link
contents, or stepping from header to header, very often.

It's the same reason that form control labels have to be formally  
associated
with their 'input' elements.  The association needs to be defined in the
markup.

As presented at TP2006 (best viewed in FireFox 2.0+)
http://www.w3.org/2006/03/01-Gilman/tree2.xhtml

Al

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

Received on Wednesday, 20 August 2008 14:20:20 UTC