W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2003

RE: Abbreviations and Acronyms: [techs] Latest HTML Techniques Draft

From: Brian Kelly <B.Kelly@ukoln.ac.uk>
Date: Fri, 12 Dec 2003 15:54:36 -0000
To: 'Charles McCathieNevile' <charles@sidar.org>, 'Christian Wolfgang Hujer' <Christian.Hujer@itcqis.com>
Cc: 'David Woolley' <david@djwhome.demon.co.uk>, www-html@w3.org, w3c-wai-ig@w3.org
Message-ID: <00fd01c3c0c8$3e5584d0$d513268a@ukoln.ac.uk>

Since the conventional meanings of acronym and abbreviations differ in
different countries and what may be an acronym in some circle may be an
abbreviation (or initaliism) in others, should we not be designed an
imfrastructure which takes on board the real-world fuzziness?

By this I mean the ability to have alternatives - e.g. FAQ may be
treated as letters or as a word; if as a word it is pronounced as foo;
bar; etc. and the expansion is foo; bar, etc.

Note that my suggestion for allowing a range of meanings is to be able
to distinguish between a strict definition, a chatty explanation, etc.
For example, the FAILTE project www.failte.ac.uk says that FAILTE
standards for Facilitating Access to Information on Learning Technology
for Engineers.  However the Web page goes on to say that failte  is the
gaelic word for WELCOME, and is pronounced something like 'fawl-sha'.
It *may* be useful to be able to provide markup to differentatite
between, say, a formal meaning and an explanation (I say *may* as
clearly there is a cost to doing this.)

The other point I would make is that for XHTML 2.0 we should learn
lessons from HTML.  I recebntly wrote a case study on our use of
Abbreviations and Acronyms - see  

http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-30/

The motivation for using the tags was to enable an automated glossary to
be produced - see work in progress at
http://www.materials.ac.uk/acronyms/
 
It was seeing the different approaches which raised some of the policy
issues described in the case study.  The other lesson was QA for such
metadata (for which users tend to get a visual opportunity to spot
errors).

This glossary approach is interesting as it illustrates the
interoperability angle, as opposed to the speech browser issue, which is
only concerned with consistency in the page itself.

Brian
 

> Hi,
> 
> Sidar's WCAG2-espa group has discussed this a bit, and the emerging 
> consensus basically agrees with what Christian says below 
> (which saves 
> me a lot of typing ;-).
> 
> The point about expanding all instances, not just the first, is 
> important to work with current technology - a paper presented 
> by Sofia 
> Celic looked into this. It's the kind of thing tools should 
> do anyway - 
> it's a pretty simple search/replace type script.
> 
> cheers
> 
> Chaals
> 
> Le Friday, 12 Dec 2003, à 22:02 Australia/Melbourne, 
> Christian Wolfgang 
> Hujer a écrit :
> 
> > My point:
> > - - since acronyms aren't neccessarily pronouncable, it's 
> required to
> > differ
> > between acronyms and abbreviations for speech browsers; a separate, 
> > e.g.
> > class based scheme is required anyway, since for <abbr title="for
> > example">e.g.</abbr> you'd might want to make an exception from the 
> > rule to
> > speak the title and want to spell out the element content 
> instead. So 
> > you'd
> > need at least three classes to be implemented in an aural 
> stylesheet:
> > * spell out element content
> > * read title
> > * read element content
> >
> > - - the semantic value of marking up an abbreviation that is an 
> > acronym different from those abbreviation that aren't is very very 
> > little, for me it even has no value at all; I'd rather wish for a 
> > <person/> element than for a
> > differentiation between those abbreviations that are acronyms and 
> > those that
> > aren't.
> >
> > - - Also, for transformations with XSLT <acronym/> gives no extra
> > value.
> > Expanding <abbr>e.g.</abbr> and <acronym>Laser</acronym> using a 
> > database
> > works all the same.
> >
> > So differing between those two kinds of abbreviations that are
> > acronyms and
> > that aren't isn't that important at all, I think. So I vote for 
> > dropping
> > <acronym/> (XHTML 2.0 probably does so).
> >
> > I think the WAI HTML Techniques Draft should state that 
> it's important
> > to
> > markup abbreviations at all, but it's not so important to 
> markup those
> > special abbreviations that are acronyms as such.
> >
> > Also I suggest that abbreviations are always marked up, not just the
> > first
> > time, maybe the title can be given only the first time.
> >
> --
> Charles McCathieNevile                          Fundación Sidar
> charles@sidar.org                                http://www.sidar.org
> 
> 
Received on Friday, 12 December 2003 10:56:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:13 GMT