E-mail List Archives

Re: abbreviations

for

From: Simius Puer
Date: May 28, 2010 10:57AM


My 2 cents worth...

1. Chuck's point about "commonly recognised" abbreviations.

It is always a dangerous notion to assume that what *you think* is common
knowledge actually is in the real world.

For a start you are assuming that all the audience reading the article
share the same native language. Not all your website visitors will have
English as their first language and what might be a common abbreviation in
one language might not be in another. Take the old USSR for example - any
English speaker would recognise this, but in its native tongue it was CCCP.

WCAG 2.0 SC 3.1.4 also reminds us that abbreviation expansion can also
help those with cognitive disabilities.

Both these examples show why you can't take common knowledge for granted.

However, I think it is still a fuzzy area that needs common sense
applied. For example, should "pm" be expanded into its full Latin and then
into English? ...possibly not very useful.

2. Geof's point about only expanding on the first instance & "whose fault
is it if they dont start at the beginning of the
content? That doesn't make any sense."

I have to disagree Geof, it makes perfect sense. This is the medium of
the Web, not print. People don't start at the "beginning" (whether that is
the start of a website, or of a page) and work their way through. Anchor
links are a perfect example of how this might happen.

I fully agree with making the first instance on a page visually expanded,
but you ought to use the <abbr> mark-up after that, especially on longer
content.

The WCAG success criterion is quite confusing on this front as it offers
techniques that mention both "for the first occurrence" and "for all
occurrences" separately, but makes no indication as to when each is
appropriate. It even says that for each scenario a "techniques or
combinations of techniques" is sufficient - well which is it?

Accessibility aside for a moment, this is simply just good practice in
terms of usability!

3. The Abbr vs Acronym debate.

<acronym> has long been hinted at becoming depreciated and it is in
current spec for HTML5.

Thank [insert your own personal deity (or whatever you wish to thank
should you not be religious) here...how's that for 'PC'] for small mercies!

4. Denis "It means that Jaws will NOT support the @title in <abbr> and
<acronym>"

I would not take that as Gospel, especially as Geof said he has
"abbreviation and acronym turned off".

5. User choice

The only reasonable argument I've heard *against *using the <abbr> tag
throughout a document is that it might get repetitive for those using AT.
But, as AT users here have expressed, they often have these turned off.
That is user choice, and I am sure if the need arose they would re-enable
it, even temporarily. This does not make <abbr> an inaccessible choice.
(RE: Denis's point about keyboard users - you can simply add an alternative
CSS)

But this mark-up of the expansion is *not *just for AT users! Using the
<abbr> tag enables various groups user...and that is what accessibility is
about. If I (as an almost entirely non-disabled user) want to hover over a
word to find it's meaning because I don't know it, would you be happy to
discriminate against me?

I am not saying it is <abbr> is enough by itself - but do not restrict
user choice. That is like the whole "forcing new windows" argument all over
again - just let the user decide.

6. Search Engine Optimisation

From the point of SEO, including both versions of a phrase (i.e. in full
and abbreviated) makes perfect sense.

If you think SEO is unrelated to accessibility, think again - how about a
users ability to find what they are looking for in the first place?


My personal approach at the moment is to have the full version and its
abbreviation in the first instance followed up by <abbr> for *all* following
instances. In long documents, or ones with anchors (usually one and the
same) this works well. Provision of a indexed glossary is provided as an
alternative (with a standard link to it site-wide) - not a perfect solution
but it makes the most of commonly available technology.

The last few comments from Denis and Jared about a way forward are spot on!
That idea would make perfect sense from both a content management and the
user agent side of things. Now, I wonder how many years it will take to
come true? Suggest it to the W3C though - they might take it on board.