Re: Technique 5.6 (abbr in TH)

re: the GL agenda:

I have put this as an open issue for the techniques document.

I propose that something along the following lines be included as an 
example in the techniques doc.

    <TABLE border="1"
           summary="This table charts the number of
                    cups of coffee consumed by each senator,
                    the type of coffee (decaf or regular),
                    and whether taken with sugar.">
      <CAPTION>Cups of coffee consumed by each senator</CAPTION>
      <TR>
          <TH id="header1">Name</TH>
          <TH id="header2">Cups</TH>
          <TH id="header3" abbr="Type">Type of  Coffee</TH>
          <TH id="header4">Sugar?</TH>
           <TH id="header5"><ABBR title="Congressional Coffee 
Association">C.C.A.</ABBR>?</TH>
      <TR>
          <TD headers="header1">T. Sexton</TD>
          <TD headers="header2">10</TD>
          <TD headers="header3">Espresso</TD>
          <TD headers="header4">No</TD>
          <TD headers="header5">Yes</TD>
      <TR>
          <TD headers="header1">J. Dinnen</TD>
          <TD headers="header2">5</TD>
          <TD headers="header3">Decaf</TD>
         <TD headers="header4">Yes</TD>
          <TD headers="header5">No</TD>
   </TABLE>

re: the ER agenda:
I agree with Chris that we ought to talk about this next week in regards to 
Acronyms.  as initial ideas, I suggest that the following patterns ought to 
trigger the ABBR dialog:

1.  4 or less characters followed by period.  for example:
e.g. (1 character followed by a period, followed by another character then 
period)
etc. (3 characters followed by a period)
N.R.A.

2.  2 or more capitalized characters
WI

3. mixture of characters and numerals:
W3C

4. group of characters with no vowels:
wrt (with regards to)
btw (by the way)

Usually this function is handled by spell checkers picking up unknown 
combinations of characters.  Perhaps what we suggest is that rather than 
replacing an unrecognized combination of characters with something else, 
mark them as an abbreviation (ABBR element) and prompt the author for the 
text, unless it is already in the spell checker.

I'm not sure what to suggest for the "abbr" attribute other than if a 
heading has more than 3 words, ask the author if it can be shortened.  3 is 
arbitrary.

--wendy

At 09:50 AM 11/24/99 , Al Gilman wrote:
>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>
> >--------------------------------------------------------
> >

<>
wendy a chisholm (wac)
world wide web consortium (w3c)
web accessibility initiative (wai)
madison, wisconsin (madcity, wi)
united states of america (usa)
tel: +1 608 663 6346
</>

Received on Monday, 29 November 1999 12:14:28 UTC