WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Analyzing <abbr> solutions

for

Number of posts in this thread: 7 (In chronological order)

From: Kynn Bartlett
Date: Thu, Mar 23 2006 11:30AM
Subject: Analyzing <abbr> solutions
No previous message | Next message →

On 3/23/06, Penny Roberts < = EMAIL ADDRESS REMOVED = > wrote:
>
>
> However, I am one of the x% of people who would have been dyslexic
> had
> I not developed coping strategies very early on. I have a very poor
> memory for some things (like acronyms!): is that attributable to the
> brain patterns/links that cause dyslexia? I don't know. [Memory
> malfunction is a facet of dyslexia for some sufferers.]
> [...]
> Anyone with impaired memory through age, stroke etc.. People with motor
> disabilities? Using an assistive device which is voice activated or
> controlled by limited physical motion or by mouth might find it
> fatiguing to seek out the first instance of the acronym (and equally
> fatiguing working through the additional text if it were written in full
> every time). Possibly some forms of dyslexia.


Ah, there you go -- finally a discussion of what users with disabilities
benefit from <abbr>. I am glad to see this discussed.

So we have:

1. People with various cognitive impairments may benefit from being able to
expand an acronym or abbreviatioin.

2. People who might have problems navigating a document easily may not be
able to easily find the acronym or abbreviation.

These are likely valid (although we'd need actual concrete data on user
patterns to determine if these really represent user scenarios that happen),
so the next question becomes "how do we address these?"

Using the screenreader example, this may be case of user agent support. A
browser might be able to identify a fragment as being an acronym if it's
defined once with <abbr>, and then provide a link back to it on demand. A
decent searching function could address 2, especially if there is a
jump-back-to-where-I-was function.

Large problems can result when the expectation is that all acronyms and
abbreviations must be provided with expanded forms via <abbr>, including the
fact that it greatly increases the size of the text.

Consider the following:

"Cascading Style Sheets (CSS) is a language created by the World Wide Web
Consortium (W3C) for use with HTML and XML documents. The W3C's current
recommendation is CSS level 2, although they've published a draft for CSS
2.1. You can read more about CSS at the W3C's web site."

This is not an unreasonable paragraph to write; the acronyms CSS and W3C are
expanded (in normal English text) on first appearance as they're likely not
familiar to the target audience of the paragraph -- since the purpose of the
paragraph is to explain what CSS is. HTML and XML are presumed to be
familiar enough that they're not spelled out.

Total characters (without links): 275

Here's a version with <abbr> used every time:

"<abbr title="Cascading Style Sheets">CSS</abbr> is a language created by
the <abbr title="World Wide Web Consortium">W3C</abbr> for use with <abbr
title="HyperText Markup Language">HTML</abbr> and <abbr title="eXtensible
Markup Language">XML</abbr> documents. The <abbr title="World Wide Web
Consortium">W3C</abbr>'s current recommendation is <abbr title="Cascading
Style Sheets">CSS</abbr> level 2, although they've published a draft for
<abbr title="Cascading Style Sheets">CSS</abbr> 2.1. You can read more about
<abbr title="Cascading Style Sheets">CSS</abbr> at the <abbr title="World
Wide Web Consortium">W3C</abbr>'s web site."

Total characters: 635

Note that in this case, the <abbr> substitutes for the normal English
parenthetical expansions of CSS and W3C -- since we're required to use
<abbr> and not required to expand it in text (which, IMO, is a serious
writing flaw), there's a disincentive to add an extra 54 characters
(bringing the total to 689).

I'd suggest that a better rule than "expand all abbreviated forms with
<abbr>" is "provide expanded versions on first appearance of unfamiliar
abbreviated forms with <abbr title>, AND mark subsequent appearances of the
abbreviated forms with <abbr> (with no title)."

This would allow user agents to track which abbreviated forms have been
expanded and provide tooltips for each if desired, but not require redundant
and repetitive markup for subsequent appearances. Example:

"<abbr title="Cascading Style Sheets">CSS</abbr> is a language created by
the <abbr title="World Wide Web Consortium">W3C</abbr> for use with HTML and
XML documents. The <abbr>W3C</abbr>'s current recommendation is
<abbr>CSS</abbr> level 2, although they've published a draft for
<abbr>CSS</abbr> 2.1. You can read more about <abbr>CSS</abbr> at the
<abbr>W3C</abbr>'s web site."

Total Characters: 379

To this text (but not the preceeding) you can apply a simple CSS rule:

abbr[title]:before { content: attr(title) " ("; }
abbr[title]:after { content: ")"; }

With such a rule applied, the text above is identical, when shown in a
reasonable browser, to the original version (with the English, non-markup
expansion).

(This won't work if you use <abbr title> on every occurence, though.)

Thoughts?

--Kynn



From: Patrick H. Lauke
Date: Thu, Mar 23 2006 5:00PM
Subject: Re: Analyzing <abbr> solutions
← Previous message | Next message →

Kynn Bartlett wrote:

> I'd suggest that a better rule than "expand all abbreviated forms with
> <abbr>" is "provide expanded versions on first appearance of unfamiliar
> abbreviated forms with <abbr title>, AND mark subsequent appearances of
> the abbreviated forms with <abbr> (with no title)."

Not sure if it's already been thrown into the mix (I only skimmed the
myriad of replies on this thread), but what about not being able to
define "first appearance" (if a user followed a link to a named anchor
or fragment identifier, landing somewhere after the first occurrence in
the source code, or if a user skipped entire paragraphs etc)

P
--
Patrick H. Lauke
___________
re

From: Kynn Bartlett
Date: Fri, Mar 24 2006 7:40AM
Subject: Re: Analyzing <abbr> solutions
← Previous message | Next message →

On 3/23/06, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
> Not sure if it's already been thrown into the mix (I only skimmed the
> myriad of replies on this thread), but what about not being able to
> define "first appearance" (if a user followed a link to a named anchor
> or fragment identifier, landing somewhere after the first occurrence in
> the source code, or if a user skipped entire paragraphs etc)


It hasn't been said, but you're right, that's a big problem.

Which is why I think that the general algorithm for defining expansion
should go something like this:

1. The browser looks over the whole page, and finds all the <abbr> tags.
2. It makes an internal table to represent mappings of "abbreviated
version" (from the content of the <abbr>) and "expanded version" (from any
title attributes on the <abbr>s).
3. If there's not a title element on something that's an <abbr>, match the
content back against the most recent previous occurrence of that abbreviated
version, and use that expanded version.
4. Display the expanded version on first appearance (both visually and in
synthesized speech) and cue (visually and by sound icon) on later
appearances. The first appearance would be in display/render/reading order,
so if you jump to an anchor the next one after the anchor is "first."

Now, nobody does this, so again, pie-in-the-sky thinking of the "wouldn't it
be nice?" variety. The user agents really should do something like this, it
would be real nice and cut down on redundant markup as well as providing
direct (not activated) access to the expanded version on first appearance.

Anyway. :)

--Kynn



From: Patrick H. Lauke
Date: Fri, Mar 24 2006 11:20AM
Subject: Re: Analyzing <abbr> solutions
← Previous message | Next message →

Kynn Bartlett wrote:

> Which is why I think that the general algorithm for defining expansion
> should go something like this:
>
> 1. The browser looks over the whole page, and finds all the <abbr> tags.
> 2. It makes an internal table to represent mappings of "abbreviated
> version" (from the content of the <abbr>) and "expanded version" (from
> any title attributes on the <abbr>s).
> 3. If there's not a title element on something that's an <abbr>, match
> the content back against the most recent previous occurrence of that
> abbreviated version, and use that expanded version.
> 4. Display the expanded version on first appearance (both visually and
> in synthesized speech) and cue (visually and by sound icon) on later
> appearances. The first appearance would be in display/render/reading
> order, so if you jump to an anchor the next one after the anchor is "first."
>
> Now, nobody does this, so again, pie-in-the-sky thinking of the
> "wouldn't it be nice?" variety. The user agents really should do
> something like this, it would be real nice and cut down on redundant
> markup as well as providing direct (not activated) access to the
> expanded version on first appearance.

Yup, the user agents should really start to become a lot smarter in this
respect. An additional method that would be quite smart: adding a
vocabulary file in RDF format or similar to the page via a LINK, and
have the UA refer to it for expanded versions of abbreviations etc.

Who knows...maybe one day we'll get there with all of the Semantic Web
malarkey *grin*

P
--
Patrick H. Lauke
___________
re

From: Kynn Bartlett
Date: Fri, Mar 24 2006 2:10PM
Subject: Re: Analyzing <abbr> solutions
← Previous message | Next message →

On 3/24/06, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
> Yup, the user agents should really start to become a lot smarter in this
> respect. An additional method that would be quite smart: adding a
> vocabulary file in RDF format or similar to the page via a LINK, and
> have the UA refer to it for expanded versions of abbreviations etc.


I think even a link to a page with definitions in <dl> would work. We don't
need an RDF format, necessarily, although it would be good for automatic
definition ability.

This can be done NOW:

<link rel="glossary" href="termsdefined.html" title="Terms Defined">

I think it's supported in, what, Lynx?

--Kynn



From: Tim Beadle
Date: Fri, Mar 24 2006 2:20PM
Subject: Re: Analyzing <abbr> solutions
← Previous message | Next message →

On 24/03/06, Kynn Bartlett < = EMAIL ADDRESS REMOVED = > wrote:
> I think even a link to a page with definitions in <dl> would work. We don't
> need an RDF format, necessarily, although it would be good for automatic
> definition ability.
>
> This can be done NOW:
>
> <link rel="glossary" href="termsdefined.html" title="Terms Defined">
>
> I think it's supported in, what, Lynx?

And Opera, too, I think.

Tim




From: Penny Roberts
Date: Sat, Mar 25 2006 6:00AM
Subject: Re: Analyzing <abbr> solutions
← Previous message | No next message

Kynn Bartlett wrote:

> 1. People with various cognitive impairments may benefit from being able
> to expand an acronym or abbreviatioin.
>
> 2. People who might have problems navigating a document easily may not
> be able to easily find the acronym or abbreviation.
>
> These are likely valid (although we'd need actual concrete data on user
> patterns to determine if these really represent user scenarios that
> happen), so the next question becomes "how do we address these?"


Sadly it seems we run into the old problem: there doesn't seem to be
much research going on. I've been looking on various databases (e.g.
Medline and PsychInfo) but so far have found very little to go on. Of
course the problem as with all literature searching is knowing what
keywords are likely to be relevant.
If I find anything I'll certainly post it but I won't be around for a
few days so don't expect anything yet.

>
> Using the screenreader example, this may be case of user agent support.


Indeed: and isn't that also a perennial problem? So much of what is
discussed on here boils down to: user agents don't fully support this so
we can't do it; or user agents should be doing this so we shouldn't
provide workarounds.


> Large problems can result when the expectation is that all acronyms and
> abbreviations must be provided with expanded forms via <abbr>, including
> the fact that it greatly increases the size of the text.


OK, I agree that page size should be kept to a minimum but is that an
accessibility problem? I can see that it is a problem if it adds to the
actual screen length: it means more to navigate through; but is the
additional download time also an accessibility problem (I'm not trying
to argue here, I genuinely want to know)?


Penny