Re: Foundation for text techniques

Thank you, Adam, for starting this thread this way.  This is a model we should
all aspire to follow.

At 11:34 PM 2001-12-06 , Adam Victor Reed wrote:
>I am planning to write the techniques document on accessibility text
>(alt, title and longdesc parameters of tags presenting content that
>would not be universally accessible without those parameters) over the
>winter break, so this discussion cames just in time. I am not claiming
>that my current understanding of the relevant issues is necessarily
>correct, but if I my understanding diverges either from relevant facts
>or from the concensus of this group, I need to know it now. So please
>comment on the following summary:
>
>1. The default (pictorial or animated) content and the ALT text are
>alternatives: when one is presented, the other isn't. Thus the
>ALT parameter contains text which IS presented whenever the
>corresponding visual is NOT being accessed, and that is NOT
>normally presented when the visual IS being acccessed.
>

AG::  See separate post on when ALT and image should both be shown.

>Constraint: In common ("visual") browsers, the presentation of the
>ALT text normally uses the same real-estate that would contain, if
>the user chose to load images, the corresponding visual. To maximize
>the likelihood of fitting in the reserved area, the ALT text should
>be as brief as possible.

AG:: This discussion puts the priorities backward.  Yes, the ALT should be
succinct.  But it should also be sufficient.  Any user agent that doesn't
allow
one to display the whole ALT instead of just what fits in the layout is
broken,
per the User Agent guidelines.

Succinctness is of value, here, to aural and to visual users.  One should also
think about front-loading, so that in the case that the reserved layout region
crops the ALT, the part that shows is usually sufficient to get the general
idea.

Do screen readers read the cropped ALT display or the ALT as in the source
code?  How does this work in screen reader scenarios where there is a visual
layout on the screen and an aural readout based on how the user drives the
reading cursor around?

>2. According to the HTML recommendation,
><<http://www.w3.org/TR/REC-html40/struct/global.html#adef-title>http://www
.w3.org/TR/REC-html40/struct/global.html#adef-title>,
>the TITLE parameter's function is to "offer advisory information
>about the element". This means that the TITLE text is an optional
>addition to whatever content (visual or ALT) is already displayed.
>The presentation of the TITLE text in the user agent usually depends
>on user actions, or on user-specified browser options. In visual
>browsers, the TITLE text is normally available as a "tool tip", that
>is, as text which pops up when the mouse cursor is positioned over
>the element area, regardless of whether the element area contains the
>default element or its ALT text.
>

AG;:

The logical model in HTML 4 is not adequate.  This is written up at

 behavior matters (why is a TITLE not a title?)
 <http://lists.w3.org/Archives/Public/wai-tech-comments/2001Jul/0001.html>h
ttp://lists.w3.org/Archives/Public/wai-tech-comments/2001Jul/0001.html

The discussion that you offered used format-neutral language in part, but the
discussion is specific to HTML 4.

In SVG we simplified things to a 'title' and a 'desc' which are both
syntactically sub-elements but are neither one normally shown and both
function
as attributes, giving properties to the 'g' object that they are in.  Nowever
the specification language describing this 'title' property is the same
ambiguous "advisory information" language as in HTML 4 which does not
disambiguate a) something that could replace the object and b) supplementary
information that depends on the prior comprehension of the object.

So this is on the list of problems for possible reform in XHTML 2.0.  Because
of the popularity of the toolTip or onMouseOver behavior, it seems to make
sense to preserve the capabilty to put in a construct for amplifying remarks
that will flash at you or be peekable on command.  My current leaning,
however,
is to do here what I have been trying to get people to do with CAPTION and
SUMMARY in TABLEs in HTML.  That is to say define the SUMMARY as supplementary
to the CAPTION and recommend that in cases where the SUMMARY is to be
displayed, to display the CAPTION, if any, first.  That would give authors a
target to shoot at that they can deal with.

Similarly, here, for navigation purposes we want for any notable thing in the
navigation space we want a title which is a fit standalone replacement for
that
thing.  What you would put in a table of contents.  But based on the behavior
of the legacy HTML binding to behavior, the TITLE attribute is authored as
supplementary, not titular.  Maybe this means we add ALT to lots of things. 
This is eating my words, but I am ready to learn.  From a PF perspective, we
should come up with a "highest and best" logical model which covers
alternative
behaviors in different delivery contexts, and figure out a migration path from
what we have in HTML and browsers today to XHTML 2.0 and UAAG 1.0 behavior in
the future.

For the longer descriptions, and for your delectations in writing what you are
working on, please also read through the case study at

 affective messaging and effective mode-crossing
 <http://lists.w3.org/Archives/Public/wai-tech-comments/2001Aug/0001.html>h
ttp://lists.w3.org/Archives/Public/wai-tech-comments/2001Aug/0001.html

Al

>In non-visual (text, auditory etc) browsers, the presentation of the
>TITLE text may depend on whether an ALT text string is also available.
>Such browsers may present the TITLE text automatically if ALT is not
>found. If ALT text is available, the presentation of TITLE text
>depends on a user-set option, or on user input. Users of text browsers
>generally prefer that if ALT and TITLE are both displayed, the TITLE
>be presented in parentheses after the ALT. (I'd like input from list
>users on what is preferred by users of auditory and other browsers.)
>
>4. LONGDESC is a separate resource which provides, for users unable to
>access the visual in full detail, all the information that a user to
>whom the visual is fully accessible would be able to extract from it
>if she examined the visual exhaustively. It should be usable not only
>by users who require ALT, but also by users who can extract casually
>adequate information but not complete detail from the visual itself.
>For example, a colored image might convey information equivalent to an
>adequate ALT even to a color-blind user, but this user then might use
>the LONGDESC resource for access to details that others could deduce
>from colors in the image. The LONGDESC resource should be available
>through a user action, such as a link in a menu displayed when the
>menu button is depressed over the image in a visual browser. (How do
>users of auditory browsers prefer to access LONGDESC?)
>
>Is the above a reasonable starting point for the techniques document?
>-- 
> Adam Reed
> areed2@calstatela.edu
> 
>Context matters. Seldom does *anything* have only one cause.
>

Received on Friday, 7 December 2001 15:51:29 UTC