RE: [techs] Acronyms and abbreviations

Ben wrote:

<snip>
At the same time, I think we need to be thinking about a solution that
gives
authors and users more options by working toward increasing
responsibility for
user agents to make the user aware that conditional content is present
each time
an element containing it is encountered. Not sure what to propose at the
moment,
</snip:

This is actually a very tricky proposition, too.  To take one example--
that doesn't involve acronym or abbreviation--the current version of
JAWS (5.0) announces mouseovers and clickable mouseovers by default.  It
can be nice to know that there's something there, but it can also be
crazy-making on pages where there are dozens of clickable mouseovers.  I
have a very good verbal memory, but the constant refrain of "mouseover"
and "clickable mouseover" drives everything else from my head.


I think this is user-configurable-- but now I can't find a setting that
will let me turn it off...

At any rate, the point is that there's a tradeoff between providing
information about every element on the screen and generating Too Much
Information, i.e., noise. This may be one of those things where we
should actively encourage developers to conduct user testing, because
the line between meaningful information and noise will move depending on
the size and complexity of the page, the number of acronyms or other
elements with additional information, etc.

John

"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web http://www.utexas.edu/research/accessibility 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Ben Caldwell
Sent: Friday, May 14, 2004 7:10 PM
To: w3c-wai-gl@w3.org
Subject: RE: [techs] Acronyms and abbreviations



John wrote:

> OK-- how does this sound as a practical suggestion for What to Do 
> Today?
> 
> - Provide the full meaning of each acronym or abbreviation, in context

> or in markup, the first time the acronym or abbreviation appears in 
> any form that users experience as a "page."

As John mentioned earlier in this thread, the problem with answering the
question of what can be done today is that the only reliable method for
delivering acronym and abbreviation expansion is to provide the
expansion in context. 

From an author perspective today, odds are as good (if not better) that
the user will have no idea an acronym expansion exists as they are that
the user will encounter the expansion. So, why bother to include them at
all?

I agree that this is a case where we need to be actively encouraging
user agent and AT developers to improve end-user interaction with
conditional content. However, I think we need to look beyond the WCAG
2.0 guidelines and techniques to fully address the issue.

Checkpoint 2.3 [1] of UAAG 1.0 currently requires the following:

[snip]

2.3 Render conditional content (P1) 

    1. Allow configuration to provide access to each piece of
       unrendered conditional content "C".
    2. When a specification does not explain how to provide access to
       this content, do so as follows:
          + If C is a summary, title, alternative, description, or
            expansion of another piece of content D, provide access
            through at least one of the following mechanisms:
               o (1a) render C in place of D;
               o (2a) render C in addition to D;
               o (3a) provide access to C by allowing the user to query
                 D. In this case, the user agent must also alert the
                 user, on a per-element basis, to the existence of C
                 (so that the user knows to query D); and
               o (4a) allow the user to follow a link to C from the
                 context of D.
          + Otherwise, provide access to C through at least one of the
            following mechanisms:
               o (1b) render a placeholder for C, and allow the user
                 to view the original author-supplied content associated
                 with each placeholder;
               o (2b) provide access to C by query (e.g., allow the user
                 to query an element for its attributes). In this
                 case, the user agent must also alert the user, on a
                 per-element basis, to the existence of C; and
               o (3b) allow the user to follow a link in context to C.

[end snip]

The problem that this discussion of abbreviations and acronym expansion
raises is that one of the mechanisms for satisfying this checkpoint
(provision, 2 item
1a) doesn't seem to get us to where we would like to be in terms of
accessible content. 

Question: Do the problematic user agent behaviors that John and others
have described in this thread related to rendering title attributes meet
UAAG 1.0? In reviewing UAAG and the spec, I think item (1a) raises some
important issues for authors, user agents and end users alike. 

Here are some examples where I rendering conditional content instead of
the original content becomes problematic:

[example 1]

<acronym title="Rapid Automatic Cryptographic Equipment">RACE</acronym> 

With the acronym "RACE" above, pages that use this acronym frequently
are either confusing in that the user may not realize that the acronym
exists or that the page is using the word race. Or, expansion may make
reading the page tedious in cases where the full expansion is read
repeatedly. 

Along the same lines, last time I checked, there were 36 occurrences of
"WCAG" in the front matter of our guidelines. Should each of them be
marked as acronyms? Should someone reading through the document with a
screenreader have to change the settings in their user agent in order to
avoid hearing "Web Content Accessibility Guidelines" 36 times before
getting to the first guideline?

[end example 1]

[example 2]

... and I finally got <a href="boat.htm" title="Track my progress in
restoring an old 1957 wooden runabout.">my old boat</a> put in the water
this weekend.

In this case, allowing user agents to render conditional content in
place of the original is even more problematic. While not being aware of
the presence of the title attribute gives users less information about
the link than they may have otherwise had and really isn't an issue,
reading title in place of the original yields a completely nonsensical
sentence (... and I finally got Track my progress in restoring an old
1957 wooden runabout put in the water this weekend).

[end example 2]

Regarding what to recommend today, I think it makes sense for us to be
advising authors to provide expansions in context or markup on first
occurrence. One step further, we might consider also recommending that
the first occurrence always be identified in context. This is more a
question of good writing style, but it greatly reduces the burden on
users to uncover expansions that are provided via markup. 

At the same time, I think we need to be thinking about a solution that
gives authors and users more options by working toward increasing
responsibility for user agents to make the user aware that conditional
content is present each time an element containing it is encountered.
Not sure what to propose at the moment, but will try to send something
to the UAAG list regarding these issues soon to verify that my
understanding of UAAG is accurate and get their input on these issues.

Thoughts?

-Ben

[1]
<http://www.w3.org/TR/2002/REC-UAAG10-20021217/guidelines#tech-condition
al-conte
nt>

Received on Sunday, 16 May 2004 18:40:29 UTC