E-mail List Archives
Re: WCAG 2 draft and abbreviations
From: Jukka K. Korpela
Date: Aug 23, 2007 12:30AM
- Next message: Moore, Michael: "Re: Navigation lists and headers - best practise?"
- Previous message: smithj7: "Re: Navigation lists and headers - best practise?"
- Next message in Thread: smithj7: "Re: WCAG 2 draft and abbreviations"
- Previous message in Thread: smithj7: "Re: WCAG 2 draft and abbreviations"
- View all messages in this Thread
On Wed, 22 Aug 2007, smithj7 wrote:
> In general, using our current but older standards (2003), we
> always follow the print version e.g. Individual Employment Plan (IEP)
> and then use IEP there after.
Such an approach solves the basic problem with abbreviations better than
any markup could possibly do. However, especially in long documents,
readers - particularly those with cognitive disabilites - will have
difficulties in remembering the meanings of abbreviations. Sometimes it's
useful to also provide a list of abbreviations and their expansion,
perhaps on a separate pages. Moreover, an expansion of an abbreviation
should not be expected to present its full meaning to everyone. As any
expression, it may require an explanation. (Think about "SI". That's short
for "Système international". Does the expansion tell what it is about? Or
to take a perhaps extreme example, consider recursive expansions like GNU
= Gnu's Not Unix. :-) )
Abbreviations aren't really that different from other expressions. An
unusual word, or a common word used in an unusual meaning (perhaps as a
technical term completely different from the word's everyday meaning) can
be far bigger an obstacle to understanding than an abbreviation like "USA"
or "IBM".
> However, I also put minutes up on the website. Minutes can't be changed.
They can be annotated. If you think they cannot, you need to write a
separate explanatory document. Markup that may cause some expansion to be
shown in a tooltip or optionally spoken out is tantamount to an annotation
that has, by design, been written so that its content is available to some
users only. So it's a typical compromise: it combines the drawbacks of
both alternatives.
Annotations should be written so that they are available to all and
clearly distinguished from the text proper, especially if the text is
something official. Annotations should be identifiable as made by someone
or some organization, and this is one reason why abbreviation markup won't
do - it's too clumsy to present it that way.
> There were many abbreviations and/or acroynms in the minutes so I used
> the the acroymn tag for all these mysterious letters, after playing
> detective for half.
One of the risks here is that you get the meaning wrong. It is therefore
important that you and only you have been indicated as the source of those
annotations. A wrong annotation should be identified as a wrong
annotation, not an error in the text.
> Note: I used the acroynm because about 65 percent of our customers are
> using IE6.
Does that justify giving semantically wrong information? What happens if
some day some speech browser utilizes <acronym> markup and pronounces,
say, <acronym>IEP</acronym> as a pronounceable word (eye-ep? yep? who
knows?) as it really _should_, if the word "acronym" is taken in its
meaning in cultivated literary English?
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
- Next message: Moore, Michael: "Re: Navigation lists and headers - best practise?"
- Previous message: smithj7: "Re: Navigation lists and headers - best practise?"
- Next message in Thread: smithj7: "Re: WCAG 2 draft and abbreviations"
- Previous message in Thread: smithj7: "Re: WCAG 2 draft and abbreviations"
- View all messages in this Thread