Are Glossaries Evil? (4th August 2007)

(Commenting on Too much accessibility - double expanded acronyms from RNIB’s Web Access Centre Blog. My comment was causing a Connection was reset error.)

It’s a perennial issue with many aspects to it. I'm fully agreed about the avoidance of duplicated expansion, though.

In response to Bim’s comment:

    1. Finding links in web pages is normal web use.
    2. HTML 4 defines a glossary value for the rel attribute which can be exposed by browsers and ATs.
    3. “Glossary” is a well established and widely used name for providing descriptions of terms.
    4. BSL has ‘finger spelling’ for words which are not native to it.
  2. This is normal when foraging for further information about anything.
  3. Browsers usually have Find in page to make this easy.
  4. This is normal after finding the further information being saught. The Back button makes this easy.
  5. Both cursor and scroll position are retained when going Back. A device which does not do this is lacking a useful feature.

From what I can tell, the user experience for a Glossary is like the normal experience of finding further information about something?

Some comparisons I’d make between the available solutions:

  1. Tooltips in web browsers are usually not displayed onFocus. This makes <abbr title> and <acronym title> inaccessible to sighted users without a pointing device. title values are usually unavailable in small screen devices, too. In contrast, a glossary can be used in any web device.
  2. <abbr title> and <acronym title> are rarely used on the web, so users are likely to be unfamiliar with how they work. I’ve seen them cause confusion and annoyance for sighted mouse users, for example. In contrast, clicking a link to get more information about something is common and familiar.
  3. Expanding the title for every instance of every shortened term considered uncommon by the author everywhere on the web would surely bog users down? In contrast, a glossary is on-demand: users only get expansions when they need them.
  4. Once a user has looked up the expansion to a term, they will probably remember it for next time.
  5. Judgements about the commonality of shortened terms are very subjective. The presence or absence of <abbr title> and <acronym title> may not match a user’s need, so they’ll need to go elsewhere to look up the term. A glossary can be more thorough.
  6. Marking up many or all shortened terms will tend to:
    1. increase the costs of production and maintainance;
    2. make the website slower to build;
    3. make pages slower to add;
    4. and increase the download of every page to some extent.
    In contrast, a glossary only requires adding and maintaining one page, where each term is added just once.
  7. Online abbreviation databases are fairly exhaustive and readily available from web searches. Search engines are probably a more familiar way to find information than hovering the mouse over text styled with a dotted bottom border.
  8. In the current WCAG 2.0 documents, using the link element to link to a glossary or providing a glossary pass the unusual words and abbreviations guidelines. This is to better accomodate the different experiences users have, from what I can tell.
  9. Operating systems could let users query the nearest word for its definition. For example, Dictionary in Mac OS X.

I currently mark up nearly all shortened terms. The labour of doing this does not seem well balanced with its effectiveness. Glossaries are a solution which seem much better to me. But Bim’s comments at the bottom of that article are making me think twice, which is always helpful. c{:¬)