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-conditional-conte
nt>

Received on Friday, 14 May 2004 20:12:57 UTC