Re: Technique 5.6 (abbr in TH)

Pardon me if I put my response at the top.  GL and PF readers, please skip
to the quote to get the context.  I will send separate copies to those two
lists.

This discussion is a useful clarification.

Perhaps we can clarify it just a hair more.

I see action items for GL, ER, and PF coming out of this.

First, a possible clarification:

Note that while the ABBR attribute on TH cells in HTML4 is likely to
generate something unfortunate for speech rendering unless the author is
well coached, it is easy to see how an abbreviation could be beneficial for
Braille rendering.

Let me jump to the PF agenda.  What we need as a reference model for future
[XML applications] format accessibility is 
a) the idea of providing both short and long alternatives
b) a formal indication that the two alternatives are [roughly] equivalent
c) hopefully, a semantic model that makes it clear the relationship in b)
is the same relationship regardless of whether the author has used the long
or short alternative in the primary view of the content which is defined by
the author's encoding of the document.

We need to have a way of recognizing that there is one and the same
semantic relationship which fits to the syntax in reverse order in two
places in HTML4: 
a) in the ABBR element it is the relationship of TITLE attribute to content,
b) in the TH element it is the relationship of content to ABBR attribute.

Hopefully in PF we can use RDF technology to create not just a natural
language observation to this effect, but a machine-interpretable encoding
of this fact.

Now, to turn to the GL impact.  It would be good to have the two scenarios
Gregory laid out both exposed in the WCAT.

And finally, the ER impact:  There may be room for a 'hint' raising the
possibility of adding an ABBR on TH if the TH is long, but it should not be
presented to the author as a 'correction.'

At 11:06 PM 11/23/99 -0500, Gregory J. Rosmaita wrote:
>aloha, y'all!
>
>whilst discharging the action item i accepted at monday's teleconference,
>to ask the GL WG for clarification of WCAG Checkpoint 5.6, i revisited the
>HTML4 section on tables, and discovered that we and GL had been talking
>about 2 different pieces of markup...
>
>when i heard the term abbreviation, i had immediately thought of the HTML4
>element ABBR, use of which (i still believe) makes sense when encoding
>table headers that have been tersified by the author in order to preserve

>the perceived gracefulness and uniformity of column width and header size
>of the table he or she is encoding when it is rendered by a
>visually-oriented user agent...
>
>WCAG approached the issue from the opposite angle, working with the HTML4
>definition of the "abbr" _attribute_ which is related to the TH and TD
>elements...  according to the definition contained in the HTML4 rec
>[reference 1]
>
>quote
>This attribute should be used to provide an abbreviated form of the cell's
>content, and may be rendered by user agents when appropriate in place of
>the cell's content. Abbreviated names should be short since user agents may
>render them repeatedly. For instance, speech synthesizers may render the
>abbreviated headers relating to a particular cell before rendering that
>cell's content. 
>unquote
>
>which is consistent with WCAG Checkpoint 5.6
>
>however, i question whether the WCAG scenario is actually more common in
>the wild than the ERT scenario i outlined during the 22 November telecon,
>an excerpt from which follows -- CR stands for Chris Ridpath; LK for Len
>Kasday; MC for Michael Cooper; and GJR for me...
>
>-- begin excerpt from 22 November ER-IG Teleconference
>CR: Technique 5.6: Abbreviations for Header Labels; if have table header
>that has short word as header, don't need ABBR, but if have verbose header,
>may need ABBR
>
>LK: what does the GL actually say -- does it use the word abbreviations or
>ABBR?
>
>MC: note mentions HTML's ABBR attribute
>
>LK: on face of it, could this mean that GLs are wrongly interpreting ABBR?
>
>CR: [reads technique for checkpoint from WCAG]
>
>LK: does WCAG have it backwards? what is the purpose of this checkpoint,
>and what do they mean by ABBR?
>
>MC: what exactly is the purpose of ABBR in general?
>
>GJR: I think that they mean that if you are using an abbreviation in a
>header, enclose it in an ABBR container if you are using HTML; ABBR is
>important for accessibility because screen readers, for example, usually
>come with a set of abbreviation expansions that have been pre-defined for
>the screen reader's dictionary, so that, for example, when the screen
>reader encounters "Dr." it can expand it to either "Drive" (as in an
>address) or "Doctor"; if you have an address such as:
>       Dr. Smith
>      11 Doe Dr.
>a screen reader might read it as "Drive Smith, 11 Doe Drive"; by using the
>ABBR element in HTML, however, an author could enclose each instance of the
>abbreviation "d r period" in an ABBR, defining the word "Doctor" as the
>expansion for the first instance and "Drive" as the expansion for the

>second, so as to pass on to the AT the correct expansion for 2 identical
>abbreviations; the ABBR element, therefore, allows for the
>contextualization of abbreviations, and as such is of inestimable utility
>for accessibility, as well as for anyone indulging in mobile computing
>
>MC: ok, that explains the HTML element ABBR, but what about this checkpoint?
>
>LK: WCAG says use terse abbreviation
>
>GJR: my understanding of the purpose of the checkpoint is that an author
>may want to use an abbreviation for a header for formatting purposes, so
>that the table columns won't distort his or her desired layout or the
>perceived gracefulness of the table; if the author has a header that reads
>"Cost of Tractor Part 1294XRQ, model Z299, manufactured by General Motors'
>Construction Parts Plant in Gary, Indiana", he could: (1) abbreviate it, so
>as to keep the heading short and terse; (2) enclose the abbreviation in an
>ABBR, if using HTML, so that anyone using the page visually, can mouseover
>to expand the abbreviation, or, for someone using a screen reader in
>combination with a UA with ABBR expansion set to "on", the AT would speak
>the expanded ABBR when that user queries the header, so that he or she is
>returned something semantically sensible, rather than a short string of
>cryptic characters, such as "TP Z299"
>
>// ACTION GJR: ask GL WG for clarification on ABBR in header checkpoint in
WCAG
>-- end excerpt from 22 November ER-IG Teleconference
>
>so, my question to all of you out there in ER-land is, should we ask the GL
>WG to consider our scenario, or should we let sleeping dogs lie?  
>
>while i understand that my extended riff contained in the excerpt above is
>the illegitimate offspring of a misconception -- namely, my mistaking the
>ABBR referred to by Chris for the element, and not the attribute -- i still
>believe that, on today's overwhelmingly visually-oriented web, table
>headers are more likely to contain actual abbreviations than they are
>verbose statements...  of course, whether or not the headers are verbose
>depends upon a number of factors, including the purpose of the table and
>the issuing organization -- if the printed version of a table generated by
>the Bureau of Labor Statistics, for example, contains a verbose header,
>then it is likely that the hypertextualized version will, as well, in which
>case use of the abbr attribute is the proper repair strategy -- but if a
>table header uses an actual abbreviation, then an expansion for that
>abbreviation should be requested...
>
>should the latter be mentioned as a special case of the Technique (in ERT)
>and the Checkpoint (in WCAG) that cover use of the ABBR element?
>
>should the repair strategy for table headers simply employ a simple
>algorithm -- if the content of a TH is less than 5 characters, prompt for a
>TITLE to be associated with a containing ABBR; if the content of a TH is
>greater than 5, prompt for an abbreviation (using the abbr attribute
>associated with TH and TD)
>
>in any case, i believe that both scenarios need to be addressed by WCAG and
>ERT...

>
>gregory
>
>PS: here is what the HTML4 rec has to say on the subject of ABBR
[reference 2]
>
>quote
>The ABBR and ACRONYM elements allow authors to clearly indicate occurrences
>of abbreviations and acronyms. Western languages make extensive use of
>acronyms such as "GmbH", "NATO", and "F.B.I.", as well as abbreviations
>like "M.", "Inc.", "et al.", "etc.". Both Chinese and Japanese use
>analogous abbreviation mechanisms, wherein a long name is referred to
>subsequently with a subset of the Han characters from the original
>occurrence. Marking up these constructs provides useful information to user
>agents and tools such as spell checkers, speech synthesizers, translation
>systems and search-engine indexers. 
>
>The content of the ABBR and ACRONYM elements specifies the abbreviated
>expression itself, as it would normally appear in running text. The title
>attribute of these elements may be used to provide the full or expanded
>form of the expression. 
>unquote
>
>References
>1. http://www.w3.org/TR/REC-html4/struct/tables.html#adef-abbr
>2. http://www.w3.org/TR/REC-html4/struct/text.html#edef-ABBR
>
>--------------------------------------------------------
>He that lives on Hope, dies farting
>     -- Benjamin Franklin, Poor Richard's Almanack, 1763
>--------------------------------------------------------
>Gregory J. Rosmaita <unagi69@concentric.net>
>   WebMaster and Minister of Propaganda, VICUG NYC
>        <http://www.hicom.net/~oedipus/vicug/index.html>
>--------------------------------------------------------
>

Received on Wednesday, 24 November 1999 08:45:33 UTC