- 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
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 UTC