RE: Foundation for text techniques

See comments inline....

-----Original Message-----
From: Al Gilman [mailto:asgilman@iamdigex.net] 
Sent: Friday, December 07, 2001 1:01 PM
To: w3c-wai-gl@w3.org
Subject: 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.

[CS] This is user-configurable, at least in Internet Explorer.  On the
Advanced tab in Internet Options, check the "Always expand ALT text for
images" checkbox under accessibility and uncheck "show pictures" under
multimedia.  The image placeholders will be expanded to fit the ALT
text.

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?

[CS] There's another issue with the length of both ALT and TITLE.  As
attributes, they can't have line-breaks in them.  Unless he has a tool
doing a line-wrapped view of the alt-text, this places a practical limit
on the length of ALT or TITLE text that an author can reasonably
maintain.  In my experience, that practical limit is somewhere around 10
words (2 or 3 inches of screen real-estate when viewing the HTML).

>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 19:39:03 UTC