Re: Technique 5.6 (abbr in TH)

aloha, chris!

i agree that we should encourage the use of both the ABBR element and the ABBR
attribute in TH, but am unsure as to whether it is practical to encourage them
to use both...

as a start, i would push that (at least until the issue is further clarified by
GL and PF), that we prompt according to the parameters set forth in my original
post -- namely:

1) if the TH name is longer than X characters (X being a number to be agreed
upon by the ER-IG), use the ABBR attribute to provide a tersified version

for example, if the ER tool encountered:

<TH>Percentage of Domestic Pigs That Can Fly</TH>

it would prompt for an abbreviated version of the TH text.  Note: A hard-coded
limit should be placed on the number of characters that can be used for the
ABBR attribute; this limit should correspond to the number which is used to
toggle between "Suggest Use of the ABBR attribute" and "Suggest Use of the ABBR
element". 

[side note: while i'm philosophically inclined to limit the number of
characters allowed in the ABBR attribute definition, practically, this may be a
very bad idea -- i'd rather have an abbreviation for a verbose header be a bit
more verbose than 5 or 6 characters (which would, in effect, force the author
to define a pseudo-acronym for the contents of TH)

for example, i'd find 

<TH abbr="Domestic Fliers">Percentage of Domestic Pigs That Can Fly</TH>

far more useful than

<TH abbr="PDPTCF">Percentage of Domestic Pigs That Can Fly</TH>

:end side note]

2) if the TH name is less than X characters, use the ABBR element to provide an
expansion for the terse header text

example:

if the ER tool encounters the following:

<TH>% of D.P.</TH>

it would prompt for an abbreviation:

<TH><ABBR title="Percentage of Domestic Pigs That Can Fly">% of
D.P.</ABBR></TH>

[side note 2: in attempting to devise an example, i have convinced myself of
the inherent limitations of using a numeric toggle as a determinant...  it may
well be that this is a case where a simple algorithm will not suffice, so
perhaps, Chris, your suggestion that the ER tool prompt for both is the best
(currently available) solution to this impasse]

gregory.

At 09:37 AM 11/24/99 Chris wrote:
>Thanks for the clarification on the ABBR attribute and the ABBR element.
>
>Can't we use both?
>If the TH name is long then use the ABBR attribute to provide a short
>version.
>If the TH name is abbreviated then use the ABBR element to provide the long
>version.
>
>Perhaps both could be used at the same time - Example:
><TH ABBR="pigs group"><ABBR TITLE="National Organization For The Advancement
>Of Flying Pigs">N.O.F.T.A.O.F.P</ABBR></TH>
>
>Chris
>
>----- Original Message -----
>From: Gregory J. Rosmaita <unagi69@concentric.net>
>To: Evaluation & Repair Interest Group <w3c-wai-er-ig@w3.org>
>Sent: Tuesday, November 23, 1999 11:06 PM
>Subject: Technique 5.6 (abbr in TH)
>
>
>> 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 14:50:07 UTC