E-mail List Archives

Search E-mail List Archives for

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

From: Dan Conley
Date: Wed, May 26 2010 10:00AM
Subject: abbreviations
No previous message | Next message →

Apologies if this has been discussed ad nauseam already.

I know Jared has said in the past that WebAIM has shifted away from
abbreviating from abbreviating common terms like HTML. I've considered
this -- I expand things like PDF and etc, which probably do more harm
than good -- but haven't actually changed anything yet, as our grant is
nearly up and I plan on doing a site revamp if/when we're refunded.

I'm being forced to confront the issue now, though, as I'm formatting a
long article on HIV/AIDS, and I think having the text 'Human
Immunodeficiency Virus/Acquired Immune Deficiency Syndrome' repeated at
least once a paragraph would get wordy (and confusing) very quickly.

So: is this something I should just let slide without a tag? Should I
give them plain <abbr> tags? I don't know how screen readers would
approach it, or if people are used to hearing 'hiv' pronounced and can
auto-correct it in their head.

--
Dan Conley
Information Specialist
Center for International Rehabilitation Research Information and
Exchange (CIRRIE)
University at Buffalo, Health Sciences Library B6
Phone: (716) 829-5728
= EMAIL ADDRESS REMOVED =
http://cirrie.buffalo.edu

From: Geof Collis
Date: Wed, May 26 2010 10:15AM
Subject: Re: abbreviations
← Previous message | Next message →

Hi Dan

Personally I dont use <abbr> tags, I always expand the abbreviation
or acronym the first instance on a page and I have JAWS set to ignore
them. I just dont consider it that important but I'm willing to
listen to counter arguments.

cheers

Geof

At 11:02 AM 5/26/2010, you wrote:
>Apologies if this has been discussed ad nauseam already.
>
>I know Jared has said in the past that WebAIM has shifted away from
>abbreviating from abbreviating common terms like HTML. I've considered
>this -- I expand things like PDF and etc, which probably do more harm
>than good -- but haven't actually changed anything yet, as our grant is
>nearly up and I plan on doing a site revamp if/when we're refunded.
>
>I'm being forced to confront the issue now, though, as I'm formatting a
>long article on HIV/AIDS, and I think having the text 'Human
>Immunodeficiency Virus/Acquired Immune Deficiency Syndrome' repeated at
>least once a paragraph would get wordy (and confusing) very quickly.
>
>So: is this something I should just let slide without a tag? Should I
>give them plain <abbr> tags? I don't know how screen readers would
>approach it, or if people are used to hearing 'hiv' pronounced and can
>auto-correct it in their head.
>
>--
>Dan Conley
>Information Specialist
>Center for International Rehabilitation Research Information and
>Exchange (CIRRIE)
>University at Buffalo, Health Sciences Library B6
>Phone: (716) 829-5728
> = EMAIL ADDRESS REMOVED =
>http://cirrie.buffalo.edu
>
>

From: Susan Grossman
Date: Wed, May 26 2010 10:18AM
Subject: Re: abbreviations
← Previous message | Next message →

On Wed, May 26, 2010 at 8:02 AM, Dan Conley < = EMAIL ADDRESS REMOVED = > wrote:

> Apologies if this has been discussed ad nauseam already.
>
> I know Jared has said in the past that WebAIM has shifted away from
> abbreviating from abbreviating common terms like HTML. I've considered
> this -- I expand things like PDF and etc, which probably do more harm
> than good -- but haven't actually changed anything yet, as our grant is
> nearly up and I plan on doing a site revamp if/when we're refunded.
>
> I'm being forced to confront the issue now, though, as I'm formatting a
> long article on HIV/AIDS, and I think having the text 'Human
> Immunodeficiency Virus/Acquired Immune Deficiency Syndrome' repeated at
> least once a paragraph would get wordy (and confusing) very quickly.
>
> So: is this something I should just let slide without a tag? Should I
> give them plain <abbr> tags? I don't know how screen readers would
> approach it, or if people are used to hearing 'hiv' pronounced and can
> auto-correct it in their head.
>
>


I use the acronym tag and add a little style so that it "shows" for sighted
users when moused or tabbed who want to know what it is also. Multi-purpose
and users have commented they like this. Guess it would also depend on your
audience and the usage.

Susan R. Grossman

From: deblist
Date: Wed, May 26 2010 10:48AM
Subject: Re: abbreviations
← Previous message | Next message →

Presumably it should depend on the common usage of the acronym.
Far more people are going to recognize "HIV/AIDS" than will
recognize "Acquired Immune Deficiency Syndrome".

The standard practice for sighted users in formal documents would
be to define the term in the first usage along with the acronym,
and then use the acronym throughout. E.g.:

"Acquired Immune Deficiency Syndrome (AIDS)".

Surely that would also be best practice for screen reader users?

-deborah

From: Dan Conley
Date: Wed, May 26 2010 11:12AM
Subject: Re: abbreviations
← Previous message | Next message →

The issue as I understood it (and I admit that my accessibility training
is now a few years old, but the content of the site hasn't changed much,
so I assume/hope it's all still relevant) is that the nature of the web
allows for users to jump into a page without starting at the top, and so
it's possible they would have missed that first expansion (each article
has a table of contents with links to each h2, so if they wanted to they
could skip the introduction).

What I didn't realize then, and what my issue really is now, is that
there are some acronyms ('Portable Document Format') that actually may
be MORE confusing spelled out than in abbreviated form. Out of context I
think AIDS could go either way (we're a rehab site, so communication
aids, etc), but in an article about HIV and AIDS it seems unnecessary.
(Originally my concerns were also for users with intellectual
disabilities, but while we do provide less technical versions of complex
articles on the whole these are still aimed at rehab professionals, so...)

Thanks for everyone's responses so far. At least there isn't an
overwhelming chorus of people telling me how wrong I've been all this time.

Dan Conley
Information Specialist
Center for International Rehabilitation Research Information and
Exchange (CIRRIE)
University at Buffalo, Health Sciences Library B6
Phone: (716) 829-5728
= EMAIL ADDRESS REMOVED =
http://cirrie.buffalo.edu

On 5/26/2010 11:48 AM, = EMAIL ADDRESS REMOVED = wrote:
> Presumably it should depend on the common usage of the acronym.
> Far more people are going to recognize "HIV/AIDS" than will
> recognize "Acquired Immune Deficiency Syndrome".
>
> The standard practice for sighted users in formal documents would
> be to define the term in the first usage along with the acronym,
> and then use the acronym throughout. E.g.:
>
> "Acquired Immune Deficiency Syndrome (AIDS)".
>
> Surely that would also be best practice for screen reader users?
>
> -deborah
>

From: Conyers, Dwayne
Date: Wed, May 26 2010 11:27AM
Subject: Re: abbreviations
← Previous message | Next message →

= EMAIL ADDRESS REMOVED = ink wired:

> Surely that would also be best practice
> for screen reader users?


When doing work for Fed and State sites, that is standard practice... but *first use* is relative. I typically do first use per page on multi-page sites.

If collapsed divs are used on a single page, then I will play it by ear, considering the user may read all sequentially or could skip to one or more at random.


--
The generation that took acid to escape reality is now taking antacid to deal with reality
http://blog.dwacon.com
http://www.twitter.com/dwacon

From: Denis Boudreau
Date: Wed, May 26 2010 12:51PM
Subject: Re: abbreviations
← Previous message | Next message →

Hey all,

Like Geoff, I never use the <abbr> or <acronym> tags. Never been a great fan. I always preferred defining the first occurence of the abbreviation or acronym in content instead.

Geof, were you implying that Jaws will read the content of the <abbr> or <acronym> element if it's defined by the @title? What weould Jaws read if it stumbled across:

<acronym title="North Atlantic Treaty Organisation ">NATO</acronym>
<abbr title="Monday">Mon</abbr>

My understanding has always been that by default, Jaws would not read the @title attribute on anything but <img>, <area>, <input> or <frame>. Can it read it on <acronym> or <abbr> too?

Besides that, Ben Meadowcroft had an interesting article on the subject a couple of years ago that sums up really well how I feel about using <abbr> and <acronym>: <http://www.benmeadowcroft.com/webdev/articles/abbr-vs-acronym.shtml>;.

Part of my dislike for those tags also goes back to a few years ago, when one or the other wasn't properly supported in MSIE (can't remember which one if was or what the support problem was). Now, part of this may be based on misunderstandiong from my part, but both tags have always felt broken to me for a few reasons:

the differences in interpretation between most dictionnairies and what the W3C defines
the inconsistent use of both terms in the HTML spec (the W3C mixes both terms in the standard)
the lack of device independancy (in this case, the mouse) and won't be usable with the keyboard only
it's not visible to sighted users unless their mouse hovers over the content
etc.

I'd much rather explain what the acronym or abbreviation means on it's first occurence in the page (other than navigation or headings, for obvious reasons) by presenting it explicitely first, then give out it's acronym or abbreviation in parenthesis. A side practice would be to do the exact opposite, but always on the first occurence (still, excluding headings or navigation). Examples :

blah blah blah NATO (North Atlantic Treaty Organisation) blah blah blah
blah blah blah North Atlantic Treaty Organisation (NATO) blah blah blah

Other possibilities could include refering to footnotes on the same web page, or using a glossary on the website for example. As imperfect as these two options may be, both are more interesting to me than relying on the <abbr> or <acronym> tag.

--
Denis Boudreau
www.twitter.com/dboudreau




On 2010-05-26, at 11:16 AM, Geof Collis wrote:

> Hi Dan
>
> Personally I dont use <abbr> tags, I always expand the abbreviation
> or acronym the first instance on a page and I have JAWS set to ignore
> them. I just dont consider it that important but I'm willing to
> listen to counter arguments.
>
> cheers
>
> Geof
>
> At 11:02 AM 5/26/2010, you wrote:
>> Apologies if this has been discussed ad nauseam already.
>>
>> I know Jared has said in the past that WebAIM has shifted away from
>> abbreviating from abbreviating common terms like HTML. I've considered
>> this -- I expand things like PDF and etc, which probably do more harm
>> than good -- but haven't actually changed anything yet, as our grant is
>> nearly up and I plan on doing a site revamp if/when we're refunded.
>>
>> I'm being forced to confront the issue now, though, as I'm formatting a
>> long article on HIV/AIDS, and I think having the text 'Human
>> Immunodeficiency Virus/Acquired Immune Deficiency Syndrome' repeated at
>> least once a paragraph would get wordy (and confusing) very quickly.
>>
>> So: is this something I should just let slide without a tag? Should I
>> give them plain <abbr> tags? I don't know how screen readers would
>> approach it, or if people are used to hearing 'hiv' pronounced and can
>> auto-correct it in their head.
>>
>> --
>> Dan Conley
>> Information Specialist
>> Center for International Rehabilitation Research Information and
>> Exchange (CIRRIE)
>> University at Buffalo, Health Sciences Library B6
>> Phone: (716) 829-5728
>> = EMAIL ADDRESS REMOVED =
>> http://cirrie.buffalo.edu
>>
>>

From: Geof Collis
Date: Wed, May 26 2010 1:21PM
Subject: Re: abbreviations
← Previous message | Next message →

Hi Dennis

It would appear that by default my version of JAWS 10.0 has the
abbreviation and acronym turned off and that's just the way I like it.

I tested your examples and got NATO and Mon.

cheers

Geof
At 01:52 PM 5/26/2010, you wrote:
>Hey all,
>
>Like Geoff, I never use the <abbr> or <acronym> tags. Never been a
>great fan. I always preferred defining the first occurence of the
>abbreviation or acronym in content instead.
>
>Geof, were you implying that Jaws will read the content of the
><abbr> or <acronym> element if it's defined by the @title? What
>weould Jaws read if it stumbled across:
>
><acronym title="North Atlantic Treaty Organisation ">NATO</acronym>
><abbr title="Monday">Mon</abbr>
>
>My understanding has always been that by default, Jaws would not
>read the @title attribute on anything but <img>, <area>, <input> or
><frame>. Can it read it on <acronym> or <abbr> too?
>
>Besides that, Ben Meadowcroft had an interesting article on the
>subject a couple of years ago that sums up really well how I feel
>about using <abbr> and <acronym>:
><http://www.benmeadowcroft.com/webdev/articles/abbr-vs-acronym.shtml>;.
>
>Part of my dislike for those tags also goes back to a few years ago,
>when one or the other wasn't properly supported in MSIE (can't
>remember which one if was or what the support problem was). Now,
>part of this may be based on misunderstandiong from my part, but
>both tags have always felt broken to me for a few reasons:
>
>the differences in interpretation between most dictionnairies and
>what the W3C defines
>the inconsistent use of both terms in the HTML spec (the W3C mixes
>both terms in the standard)
>the lack of device independancy (in this case, the mouse) and won't
>be usable with the keyboard only
>it's not visible to sighted users unless their mouse hovers over the content
>etc.
>
>I'd much rather explain what the acronym or abbreviation means on
>it's first occurence in the page (other than navigation or headings,
>for obvious reasons) by presenting it explicitely first, then give
>out it's acronym or abbreviation in parenthesis. A side practice
>would be to do the exact opposite, but always on the first occurence
>(still, excluding headings or navigation). Examples :
>
>blah blah blah NATO (North Atlantic Treaty Organisation) blah blah blah
>blah blah blah North Atlantic Treaty Organisation (NATO) blah blah blah
>
>Other possibilities could include refering to footnotes on the same
>web page, or using a glossary on the website for example. As
>imperfect as these two options may be, both are more interesting to
>me than relying on the <abbr> or <acronym> tag.
>
>--
>Denis Boudreau
>www.twitter.com/dboudreau
>
>
>
>
>On 2010-05-26, at 11:16 AM, Geof Collis wrote:
>
> > Hi Dan
> >
> > Personally I dont use <abbr> tags, I always expand the abbreviation
> > or acronym the first instance on a page and I have JAWS set to ignore
> > them. I just dont consider it that important but I'm willing to
> > listen to counter arguments.
> >
> > cheers
> >
> > Geof
> >
> > At 11:02 AM 5/26/2010, you wrote:
> >> Apologies if this has been discussed ad nauseam already.
> >>
> >> I know Jared has said in the past that WebAIM has shifted away from
> >> abbreviating from abbreviating common terms like HTML. I've considered
> >> this -- I expand things like PDF and etc, which probably do more harm
> >> than good -- but haven't actually changed anything yet, as our grant is
> >> nearly up and I plan on doing a site revamp if/when we're refunded.
> >>
> >> I'm being forced to confront the issue now, though, as I'm formatting a
> >> long article on HIV/AIDS, and I think having the text 'Human
> >> Immunodeficiency Virus/Acquired Immune Deficiency Syndrome' repeated at
> >> least once a paragraph would get wordy (and confusing) very quickly.
> >>
> >> So: is this something I should just let slide without a tag? Should I
> >> give them plain <abbr> tags? I don't know how screen readers would
> >> approach it, or if people are used to hearing 'hiv' pronounced and can
> >> auto-correct it in their head.
> >>
> >> --
> >> Dan Conley
> >> Information Specialist
> >> Center for International Rehabilitation Research Information and
> >> Exchange (CIRRIE)
> >> University at Buffalo, Health Sciences Library B6
> >> Phone: (716) 829-5728
> >> = EMAIL ADDRESS REMOVED =
> >> http://cirrie.buffalo.edu
> >>
> >>

From: Denis Boudreau
Date: Wed, May 26 2010 2:51PM
Subject: Re: abbreviations
← Previous message | Next message →

Hi Geoff,

Perfect. Exactly what I hoped. Thanks.

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

That makes it an absolutely irrelevant solution to describe abbreviations or acronyms (from my perspective of course).

I stand with what I was saying earlier: explain what the acronym or abbreviation means on it's first occurence in the page (other than navigation or headings, for obvious reasons) by presenting it explicitely first, then give out it's acronym or abbreviation in parenthesis. Seems like the best option to me, a win-win situation for everyone.

--
Denis Boudreau
www.twitter.com/dboudreau




On 2010-05-26, at 2:23 PM, Geof Collis wrote:

> Hi Dennis
>
> It would appear that by default my version of JAWS 10.0 has the
> abbreviation and acronym turned off and that's just the way I like it.
>
> I tested your examples and got NATO and Mon.
>
> cheers
>
> Geof
> At 01:52 PM 5/26/2010, you wrote:
>> Hey all,
>>
>> Like Geoff, I never use the <abbr> or <acronym> tags. Never been a
>> great fan. I always preferred defining the first occurence of the
>> abbreviation or acronym in content instead.
>>
>> Geof, were you implying that Jaws will read the content of the
>> <abbr> or <acronym> element if it's defined by the @title? What
>> weould Jaws read if it stumbled across:
>>
>> <acronym title="North Atlantic Treaty Organisation ">NATO</acronym>
>> <abbr title="Monday">Mon</abbr>
>>
>> My understanding has always been that by default, Jaws would not
>> read the @title attribute on anything but <img>, <area>, <input> or
>> <frame>. Can it read it on <acronym> or <abbr> too?
>>
>> Besides that, Ben Meadowcroft had an interesting article on the
>> subject a couple of years ago that sums up really well how I feel
>> about using <abbr> and <acronym>:
>> <http://www.benmeadowcroft.com/webdev/articles/abbr-vs-acronym.shtml>;.
>>
>> Part of my dislike for those tags also goes back to a few years ago,
>> when one or the other wasn't properly supported in MSIE (can't
>> remember which one if was or what the support problem was). Now,
>> part of this may be based on misunderstandiong from my part, but
>> both tags have always felt broken to me for a few reasons:
>>
>> the differences in interpretation between most dictionnairies and
>> what the W3C defines
>> the inconsistent use of both terms in the HTML spec (the W3C mixes
>> both terms in the standard)
>> the lack of device independancy (in this case, the mouse) and won't
>> be usable with the keyboard only
>> it's not visible to sighted users unless their mouse hovers over the content
>> etc.
>>
>> I'd much rather explain what the acronym or abbreviation means on
>> it's first occurence in the page (other than navigation or headings,
>> for obvious reasons) by presenting it explicitely first, then give
>> out it's acronym or abbreviation in parenthesis. A side practice
>> would be to do the exact opposite, but always on the first occurence
>> (still, excluding headings or navigation). Examples :
>>
>> blah blah blah NATO (North Atlantic Treaty Organisation) blah blah blah
>> blah blah blah North Atlantic Treaty Organisation (NATO) blah blah blah
>>
>> Other possibilities could include refering to footnotes on the same
>> web page, or using a glossary on the website for example. As
>> imperfect as these two options may be, both are more interesting to
>> me than relying on the <abbr> or <acronym> tag.
>>
>> --
>> Denis Boudreau
>> www.twitter.com/dboudreau
>>
>>
>>
>>
>> On 2010-05-26, at 11:16 AM, Geof Collis wrote:
>>
>>> Hi Dan
>>>
>>> Personally I dont use <abbr> tags, I always expand the abbreviation
>>> or acronym the first instance on a page and I have JAWS set to ignore
>>> them. I just dont consider it that important but I'm willing to
>>> listen to counter arguments.
>>>
>>> cheers
>>>
>>> Geof
>>>
>>> At 11:02 AM 5/26/2010, you wrote:
>>>> Apologies if this has been discussed ad nauseam already.
>>>>
>>>> I know Jared has said in the past that WebAIM has shifted away from
>>>> abbreviating from abbreviating common terms like HTML. I've considered
>>>> this -- I expand things like PDF and etc, which probably do more harm
>>>> than good -- but haven't actually changed anything yet, as our grant is
>>>> nearly up and I plan on doing a site revamp if/when we're refunded.
>>>>
>>>> I'm being forced to confront the issue now, though, as I'm formatting a
>>>> long article on HIV/AIDS, and I think having the text 'Human
>>>> Immunodeficiency Virus/Acquired Immune Deficiency Syndrome' repeated at
>>>> least once a paragraph would get wordy (and confusing) very quickly.
>>>>
>>>> So: is this something I should just let slide without a tag? Should I
>>>> give them plain <abbr> tags? I don't know how screen readers would
>>>> approach it, or if people are used to hearing 'hiv' pronounced and can
>>>> auto-correct it in their head.
>>>>
>>>> --
>>>> Dan Conley
>>>> Information Specialist
>>>> Center for International Rehabilitation Research Information and
>>>> Exchange (CIRRIE)
>>>> University at Buffalo, Health Sciences Library B6
>>>> Phone: (716) 829-5728
>>>> = EMAIL ADDRESS REMOVED =
>>>> http://cirrie.buffalo.edu
>>>>
>>>>

From: John Foliot
Date: Wed, May 26 2010 2:57PM
Subject: Re: abbreviations
← Previous message | Next message →

= EMAIL ADDRESS REMOVED = wrote:
>
>
> Surely that would also be best practice for screen reader users?

Surely web accessibility is for more than just developing for screen
readers? <grin>


Denis Boudreau wrote:
>
> Geof, were you implying that Jaws will read the content of the <abbr>
> or <acronym> element if it's defined by the @title? What would Jaws
> read if it stumbled across:
>
> <acronym title="North Atlantic Treaty Organisation ">NATO</acronym>
> <abbr title="Monday">Mon</abbr>

See my comment above...

>
> My understanding has always been that by default, Jaws would not read
> the @title attribute on anything but <img>, <area>, <input> or <frame>.
> Can it read it on <acronym> or <abbr> too?

You are correct in stating that by default, JAWs (as one of many
screen-readers on the market) does not read out the title attribute values
on any element that has a title attribute. However, this alone is not, nor
should it be, a reason or non-reason to use any HTML mark-up or attribute
when appropriate. There is a very old axiom in some accessibility circles
which suggests "author proposes, user disposes", and in this case it is
quite apropos:

WCAG2, Guideline 3.1 Make text content readable and understandable

Guideline 3.1.4 - Abbreviations: (Ensure) A mechanism for finding the
expanded form or meaning of abbreviations is available.

Success Technique H28: Providing definitions for abbreviations by using
the abbr and acronym elements states:

"It is always appropriate to use the abbr element for any
abbreviation, including acronyms and initialisms. When using HTML 4.01,
XHTML 1.0 or XHTML 1.1, initialisms and acronyms may be marked up using
the acronym element. XHTML 2.0(*) proposes eliminating the acronym element
in favor of the more general abbr element."
-
http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#H28-descr
iption


See also:
http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G102

(* Note to self - contact the WAI WG on referencing XHTML 2 in this
document. FWIW, HTML5 is also obsolescing the acronym element in favor of
<abbr>)


> Besides that, Ben Meadowcroft had an interesting article on the subject
> a couple of years ago that sums up really well how I feel about using
> <abbr> and <acronym>:
> <http://www.benmeadowcroft.com/webdev/articles/abbr-vs-acronym.shtml>;.

Times change, so should opinions...

The 'difference' between acronym and abbreviation is one of those "how
many angels on the head of a pin" discussions/debates that just goes
'round and 'round. For the sake of providing appropriate fallback
information to our users, it's a moot point: providing the expansion is
what is important, not what we call it.


>
> Part of my dislike for those tags also goes back to a few years ago,
when
> one or the other wasn't properly supported in MSIE (can't remember which

> one if was or what the support problem was).

You are correct: early versions of IE did not support the <abbr> element.
Since IE 7 this has not been the case however, and if we want IE 6 to die,
we need to just stop supporting it - please(?).


Geof Collis wrote:
>
> It would appear that by default my version of JAWS 10.0 has the
> abbreviation and acronym turned off and that's just the way I like it.

Again, this is one of those 'author proposes, user disposes' situations.
Geoff might not want to hear acronyms and abbreviations expanded, however
he is not the only user out there <grin> and I personally take the stance
that a belt and suspenders approach to content mark-up is always the
better approach - we can never assume anything of our users: some users
might *want* to have this information. I have also seen (but cannot find
the URL today) a neat example of mixing a bit of JS and Print CSS to
"write out" in a printed version of an HTML document the <abbr> value - a
value-add proposition for those with cognitive issues (for example).


Dan Conley wrote:
>
> The issue as I understood it (and I admit that my accessibility training

> is now a few years old, but the content of the site hasn't changed much,

> so I assume/hope it's all still relevant) is that the nature of the web
> allows for users to jump into a page without starting at the top, and so

> it's possible they would have missed that first expansion (each article
> has a table of contents with links to each h2, so if they wanted to they

> could skip the introduction).

Yep, that's a fair synopsis. Again, for power-users of screen readers,
they quite often do not have the title attribute values read aloud for
them, as is their choice. However, in many modern user-agents today,
<abbr> and <acronym> also render on screen traditionally with a dotted
line under the abbreviation, and mousing over them traditionally provides
a tool-tip: again, this could benefit those with cognitive issues related
to difficulty in reading skills, or second-language issues. Sometimes it
can be helpful to the main-stream population as well. (An old story from
my early Government of Canada consulting days: the main branch responsible
for Canada's governmental policy tracking and enforcement is called the
Treasury Board Secretariat, or as it is often referred to in Ottawa - TBS.
Yet in the United States, TBS is the Turner Broadcasting System...)


> What I didn't realize then, and what my issue really is now, is that
> there are some acronyms ('Portable Document Format') that actually may
> be MORE confusing spelled out than in abbreviated form. Out of context I

> think AIDS could go either way (we're a rehab site, so communication
> aids, etc), but in an article about HIV and AIDS it seems unnecessary.
> (Originally my concerns were also for users with intellectual
> disabilities, but while we do provide less technical versions of complex

> articles on the whole these are still aimed at rehab professionals,
so...)

So this is actually the trickiest part of the whole discussion - when is
it appropriate to *not* use an acronym/abbreviation expansion? Like many
things related to accessibility, this becomes a judgment call we must make
(coupled with consistent implementation/usage). The most oft quoted
example is Radar (which was actually RADAR - RAdio Detection And Ranging),
but numerous other examples exist, including the 3 Dan mentions here: PDF,
HIV and AIDS, where in fact those abbreviations have entered our
collective vocabulary as bona-fide 'words'. In this case, using some
common judgment (based on the premise that you/we have a general idea of
our target audience) can be applied: a rehab site targeted at medical
professionals likely needs not expand on AIDS.

(One test I use is to do a Wikipedia and www.merriam-webster.com query on
the acronym or abbreviation - if it's there then I go with the assumption
that is has become a mainstream 'word' in its own right. For example, AIDS
at Wikipedia has its own page, but my other example of TBS leads to a
Wikipedia disambiguation entry, thus AIDS likely does not need the
expansion, TBS does)

Cheers!

JF

From: Geof Collis
Date: Wed, May 26 2010 3:00PM
Subject: Re: abbreviations
← Previous message | Next message →

Hi Dennis

I'm not sure where I read it but that is also the method I have
adopted because of it.

I also have to wonder how using it will help someone who cant use a mouse.

cheers

Geof

At 03:51 PM 5/26/2010, you wrote:
>Hi Geoff,
>
>Perfect. Exactly what I hoped. Thanks.
>
>It means that Jaws will NOT support the @title in <abbr> and <acronym>.
>
>That makes it an absolutely irrelevant solution to describe
>abbreviations or acronyms (from my perspective of course).
>
>I stand with what I was saying earlier: explain what the acronym or
>abbreviation means on it's first occurence in the page (other than
>navigation or headings, for obvious reasons) by presenting it
>explicitely first, then give out it's acronym or abbreviation in
>parenthesis. Seems like the best option to me, a win-win situation
>for everyone.
>
>--
>Denis Boudreau
>www.twitter.com/dboudreau
>
>
>
>
>On 2010-05-26, at 2:23 PM, Geof Collis wrote:
>
> > Hi Dennis
> >
> > It would appear that by default my version of JAWS 10.0 has the
> > abbreviation and acronym turned off and that's just the way I like it.
> >
> > I tested your examples and got NATO and Mon.
> >
> > cheers
> >
> > Geof
> > At 01:52 PM 5/26/2010, you wrote:
> >> Hey all,
> >>
> >> Like Geoff, I never use the <abbr> or <acronym> tags. Never been a
> >> great fan. I always preferred defining the first occurence of the
> >> abbreviation or acronym in content instead.
> >>
> >> Geof, were you implying that Jaws will read the content of the
> >> <abbr> or <acronym> element if it's defined by the @title? What
> >> weould Jaws read if it stumbled across:
> >>
> >> <acronym title="North Atlantic Treaty Organisation ">NATO</acronym>
> >> <abbr title="Monday">Mon</abbr>
> >>
> >> My understanding has always been that by default, Jaws would not
> >> read the @title attribute on anything but <img>, <area>, <input> or
> >> <frame>. Can it read it on <acronym> or <abbr> too?
> >>
> >> Besides that, Ben Meadowcroft had an interesting article on the
> >> subject a couple of years ago that sums up really well how I feel
> >> about using <abbr> and <acronym>:
> >> <http://www.benmeadowcroft.com/webdev/articles/abbr-vs-acronym.shtml>;.
> >>
> >> Part of my dislike for those tags also goes back to a few years ago,
> >> when one or the other wasn't properly supported in MSIE (can't
> >> remember which one if was or what the support problem was). Now,
> >> part of this may be based on misunderstandiong from my part, but
> >> both tags have always felt broken to me for a few reasons:
> >>
> >> the differences in interpretation between most dictionnairies and
> >> what the W3C defines
> >> the inconsistent use of both terms in the HTML spec (the W3C mixes
> >> both terms in the standard)
> >> the lack of device independancy (in this case, the mouse) and won't
> >> be usable with the keyboard only
> >> it's not visible to sighted users unless their mouse hovers over
> the content
> >> etc.
> >>
> >> I'd much rather explain what the acronym or abbreviation means on
> >> it's first occurence in the page (other than navigation or headings,
> >> for obvious reasons) by presenting it explicitely first, then give
> >> out it's acronym or abbreviation in parenthesis. A side practice
> >> would be to do the exact opposite, but always on the first occurence
> >> (still, excluding headings or navigation). Examples :
> >>
> >> blah blah blah NATO (North Atlantic Treaty Organisation) blah blah blah
> >> blah blah blah North Atlantic Treaty Organisation (NATO) blah blah blah
> >>
> >> Other possibilities could include refering to footnotes on the same
> >> web page, or using a glossary on the website for example. As
> >> imperfect as these two options may be, both are more interesting to
> >> me than relying on the <abbr> or <acronym> tag.
> >>
> >> --
> >> Denis Boudreau
> >> www.twitter.com/dboudreau
> >>
> >>
> >>
> >>
> >> On 2010-05-26, at 11:16 AM, Geof Collis wrote:
> >>
> >>> Hi Dan
> >>>
> >>> Personally I dont use <abbr> tags, I always expand the abbreviation
> >>> or acronym the first instance on a page and I have JAWS set to ignore
> >>> them. I just dont consider it that important but I'm willing to
> >>> listen to counter arguments.
> >>>
> >>> cheers
> >>>
> >>> Geof
> >>>
> >>> At 11:02 AM 5/26/2010, you wrote:
> >>>> Apologies if this has been discussed ad nauseam already.
> >>>>
> >>>> I know Jared has said in the past that WebAIM has shifted away from
> >>>> abbreviating from abbreviating common terms like HTML. I've considered
> >>>> this -- I expand things like PDF and etc, which probably do more harm
> >>>> than good -- but haven't actually changed anything yet, as our grant is
> >>>> nearly up and I plan on doing a site revamp if/when we're refunded.
> >>>>
> >>>> I'm being forced to confront the issue now, though, as I'm formatting a
> >>>> long article on HIV/AIDS, and I think having the text 'Human
> >>>> Immunodeficiency Virus/Acquired Immune Deficiency Syndrome' repeated at
> >>>> least once a paragraph would get wordy (and confusing) very quickly.
> >>>>
> >>>> So: is this something I should just let slide without a tag? Should I
> >>>> give them plain <abbr> tags? I don't know how screen readers would
> >>>> approach it, or if people are used to hearing 'hiv' pronounced and can
> >>>> auto-correct it in their head.
> >>>>
> >>>> --
> >>>> Dan Conley
> >>>> Information Specialist
> >>>> Center for International Rehabilitation Research Information and
> >>>> Exchange (CIRRIE)
> >>>> University at Buffalo, Health Sciences Library B6
> >>>> Phone: (716) 829-5728
> >>>> = EMAIL ADDRESS REMOVED =
> >>>> http://cirrie.buffalo.edu
> >>>>
> >>>>

From: Denis Boudreau
Date: Wed, May 26 2010 3:18PM
Subject: Re: abbreviations
← Previous message | Next message →

Hey John,

On 2010-05-26, at 3:58 PM, John Foliot wrote:

> = EMAIL ADDRESS REMOVED = wrote:
>>
>> Surely that would also be best practice for screen reader users?
>
> Surely web accessibility is for more than just developing for screen
> readers? <grin>

Surely you understand that while accessibility != developing for screen readers, it is still an important part of a complete breakfast.

Huh, I mean, an important part of an efficient approach to ensure that some users with specific types of limitations have access to content. ;p

Screen readers are but one of the many elements I raised earlier on, device independency and browser support being equally important elements to consider in the equation.


> Denis Boudreau wrote:
>>
>> Geof, were you implying that Jaws will read the content of the <abbr>
>> or <acronym> element if it's defined by the @title? What would Jaws
>> read if it stumbled across:
>>
>> <acronym title="North Atlantic Treaty Organisation ">NATO</acronym>
>> <abbr title="Monday">Mon</abbr>
>
> See my comment above...

See my comment to your comment above. ;p

/Denis

From: John Foliot
Date: Wed, May 26 2010 3:21PM
Subject: Re: abbreviations
← Previous message | Next message →

Geof Collis wrote:
>
> I'm not sure where I read it but that is also the method I have
> adopted because of it.
>
> I also have to wonder how using it will help someone who can't use a
mouse.

Sorry Geoff, this is simply the wrong perspective to be taking here: don't
develop for specific devices or software, develop according to standards.
Any other strategy will end up biting you in the back end at some point in
time.


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

It means nothing of the sort. It is simply a user setting that can be
adjusted in a particular piece of software, and what JAWS does versus what
NVDA does (versus what Voiceover does, and HAL, and WindowEyes, and...) is
already a hugely different kettle of fish. Again, developing for a piece
of software or a specific device is the wrong way forward - develop to the
standards and let the software/end user make the choice of how and what
they will consume your information.

>>
>> I stand with what I was saying earlier: explain what the acronym or
>> abbreviation means on it's first occurence in the page (other than
>> navigation or headings, for obvious reasons) by presenting it
>> explicitely first, then give out it's acronym or abbreviation in
>> parenthesis. Seems like the best option to me, a win-win situation
>> for everyone.

This is not a wrong strategy, but it is not a complete strategy either
(IMHO)

JF

From: John Foliot
Date: Wed, May 26 2010 3:27PM
Subject: Re: abbreviations
← Previous message | Next message →

Denis Boudreau wrote:

> Surely you understand that while accessibility != developing
> for screen readers, it is still an important part of a complete
> breakfast.
>
> Huh, I mean, an important part of an efficient approach to ensure
> that some users with specific types of limitations have access
> to content.

Correct, which is why *not* using <abbr> simply because, in its default
setting, JAWS (a commercial software package that runs on one operating
system) does not voice out the value string is a wrong reason for not
using <abbr>. This setting can be changed in JAWS quite easily, but more
importantly adding <abbr> when required also enhances accessibility for
some *other* users who may not be using a screen reader.

Bottom line: use <abbr> when appropriate.

JF

From: Geof Collis
Date: Wed, May 26 2010 3:42PM
Subject: Re: abbreviations
← Previous message | Next message →

Hi John

Nice try but I dont buy your argument. :O)

cheers

Geof

At 03:58 PM 5/26/2010, you wrote:
> = EMAIL ADDRESS REMOVED = wrote:
> >
> >
> > Surely that would also be best practice for screen reader users?
>
>Surely web accessibility is for more than just developing for screen
>readers? <grin>
>
>
>Denis Boudreau wrote:
> >
> > Geof, were you implying that Jaws will read the content of the <abbr>
> > or <acronym> element if it's defined by the @title? What would Jaws
> > read if it stumbled across:
> >
> > <acronym title="North Atlantic Treaty Organisation ">NATO</acronym>
> > <abbr title="Monday">Mon</abbr>
>
>See my comment above...
>
> >
> > My understanding has always been that by default, Jaws would not read
> > the @title attribute on anything but <img>, <area>, <input> or <frame>.
> > Can it read it on <acronym> or <abbr> too?
>
>You are correct in stating that by default, JAWs (as one of many
>screen-readers on the market) does not read out the title attribute values
>on any element that has a title attribute. However, this alone is not, nor
>should it be, a reason or non-reason to use any HTML mark-up or attribute
>when appropriate. There is a very old axiom in some accessibility circles
>which suggests "author proposes, user disposes", and in this case it is
>quite apropos:
>
>WCAG2, Guideline 3.1 Make text content readable and understandable
>
>Guideline 3.1.4 - Abbreviations: (Ensure) A mechanism for finding the
>expanded form or meaning of abbreviations is available.
>
>Success Technique H28: Providing definitions for abbreviations by using
>the abbr and acronym elements states:
>
> "It is always appropriate to use the abbr element for any
>abbreviation, including acronyms and initialisms. When using HTML 4.01,
>XHTML 1.0 or XHTML 1.1, initialisms and acronyms may be marked up using
>the acronym element. XHTML 2.0(*) proposes eliminating the acronym element
>in favor of the more general abbr element."
>-
>http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#H28-descr
>iption
>
>
>See also:
>http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G102
>
>(* Note to self - contact the WAI WG on referencing XHTML 2 in this
>document. FWIW, HTML5 is also obsolescing the acronym element in favor of
><abbr>)
>
>
> > Besides that, Ben Meadowcroft had an interesting article on the subject
> > a couple of years ago that sums up really well how I feel about using
> > <abbr> and <acronym>:
> > <http://www.benmeadowcroft.com/webdev/articles/abbr-vs-acronym.shtml>;.
>
>Times change, so should opinions...
>
>The 'difference' between acronym and abbreviation is one of those "how
>many angels on the head of a pin" discussions/debates that just goes
>'round and 'round. For the sake of providing appropriate fallback
>information to our users, it's a moot point: providing the expansion is
>what is important, not what we call it.
>
>
> >
> > Part of my dislike for those tags also goes back to a few years ago,
>when
> > one or the other wasn't properly supported in MSIE (can't remember which
>
> > one if was or what the support problem was).
>
>You are correct: early versions of IE did not support the <abbr> element.
>Since IE 7 this has not been the case however, and if we want IE 6 to die,
>we need to just stop supporting it - please(?).
>
>
>Geof Collis wrote:
> >
> > It would appear that by default my version of JAWS 10.0 has the
> > abbreviation and acronym turned off and that's just the way I like it.
>
>Again, this is one of those 'author proposes, user disposes' situations.
>Geoff might not want to hear acronyms and abbreviations expanded, however
>he is not the only user out there <grin> and I personally take the stance
>that a belt and suspenders approach to content mark-up is always the
>better approach - we can never assume anything of our users: some users
>might *want* to have this information. I have also seen (but cannot find
>the URL today) a neat example of mixing a bit of JS and Print CSS to
>"write out" in a printed version of an HTML document the <abbr> value - a
>value-add proposition for those with cognitive issues (for example).
>
>
>Dan Conley wrote:
> >
> > The issue as I understood it (and I admit that my accessibility training
>
> > is now a few years old, but the content of the site hasn't changed much,
>
> > so I assume/hope it's all still relevant) is that the nature of the web
> > allows for users to jump into a page without starting at the top, and so
>
> > it's possible they would have missed that first expansion (each article
> > has a table of contents with links to each h2, so if they wanted to they
>
> > could skip the introduction).
>
>Yep, that's a fair synopsis. Again, for power-users of screen readers,
>they quite often do not have the title attribute values read aloud for
>them, as is their choice. However, in many modern user-agents today,
><abbr> and <acronym> also render on screen traditionally with a dotted
>line under the abbreviation, and mousing over them traditionally provides
>a tool-tip: again, this could benefit those with cognitive issues related
>to difficulty in reading skills, or second-language issues. Sometimes it
>can be helpful to the main-stream population as well. (An old story from
>my early Government of Canada consulting days: the main branch responsible
>for Canada's governmental policy tracking and enforcement is called the
>Treasury Board Secretariat, or as it is often referred to in Ottawa - TBS.
>Yet in the United States, TBS is the Turner Broadcasting System...)
>
>
> > What I didn't realize then, and what my issue really is now, is that
> > there are some acronyms ('Portable Document Format') that actually may
> > be MORE confusing spelled out than in abbreviated form. Out of context I
>
> > think AIDS could go either way (we're a rehab site, so communication
> > aids, etc), but in an article about HIV and AIDS it seems unnecessary.
> > (Originally my concerns were also for users with intellectual
> > disabilities, but while we do provide less technical versions of complex
>
> > articles on the whole these are still aimed at rehab professionals,
>so...)
>
>So this is actually the trickiest part of the whole discussion - when is
>it appropriate to *not* use an acronym/abbreviation expansion? Like many
>things related to accessibility, this becomes a judgment call we must make
>(coupled with consistent implementation/usage). The most oft quoted
>example is Radar (which was actually RADAR - RAdio Detection And Ranging),
>but numerous other examples exist, including the 3 Dan mentions here: PDF,
>HIV and AIDS, where in fact those abbreviations have entered our
>collective vocabulary as bona-fide 'words'. In this case, using some
>common judgment (based on the premise that you/we have a general idea of
>our target audience) can be applied: a rehab site targeted at medical
>professionals likely needs not expand on AIDS.
>
>(One test I use is to do a Wikipedia and www.merriam-webster.com query on
>the acronym or abbreviation - if it's there then I go with the assumption
>that is has become a mainstream 'word' in its own right. For example, AIDS
>at Wikipedia has its own page, but my other example of TBS leads to a
>Wikipedia disambiguation entry, thus AIDS likely does not need the
>expansion, TBS does)
>
>Cheers!
>
>JF
>
>
>
>
>

From: Geof Collis
Date: Wed, May 26 2010 3:45PM
Subject: Re: abbreviations
← Previous message | Next message →

Sorry John, still dont buy it, I'll expand the
acronym/abbreviation the first time it appears on a page, the user
has some responsibility in taking it from there.



At 04:18 PM 5/26/2010, you wrote:
>Geof Collis wrote:
> >
> > I'm not sure where I read it but that is also the method I have
> > adopted because of it.
> >
> > I also have to wonder how using it will help someone who can't use a
>mouse.
>
>Sorry Geoff, this is simply the wrong perspective to be taking here: don't
>develop for specific devices or software, develop according to standards.
>Any other strategy will end up biting you in the back end at some point in
>time.
>
>
> >>
> >> It means that Jaws will NOT support the @title in <abbr> and <acronym>.
>
>It means nothing of the sort. It is simply a user setting that can be
>adjusted in a particular piece of software, and what JAWS does versus what
>NVDA does (versus what Voiceover does, and HAL, and WindowEyes, and...) is
>already a hugely different kettle of fish. Again, developing for a piece
>of software or a specific device is the wrong way forward - develop to the
>standards and let the software/end user make the choice of how and what
>they will consume your information.
>
> >>
> >> I stand with what I was saying earlier: explain what the acronym or
> >> abbreviation means on it's first occurence in the page (other than
> >> navigation or headings, for obvious reasons) by presenting it
> >> explicitely first, then give out it's acronym or abbreviation in
> >> parenthesis. Seems like the best option to me, a win-win situation
> >> for everyone.
>
>This is not a wrong strategy, but it is not a complete strategy either
>(IMHO)
>
>JF
>

From: Denis Boudreau
Date: Wed, May 26 2010 3:48PM
Subject: Re: abbreviations
← Previous message | Next message →

Hi again,

On 2010-05-26, at 4:18 PM, John Foliot wrote:

>>> It means that Jaws will NOT support the @title in <abbr> and <acronym>.
>
> It means nothing of the sort. It is simply a user setting that can be
> adjusted in a particular piece of software, and what JAWS does versus what
> NVDA does (versus what Voiceover does, and HAL, and WindowEyes, and...) is
> already a hugely different kettle of fish. Again, developing for a piece
> of software or a specific device is the wrong way forward - develop to the
> standards and let the software/end user make the choice of how and what
> they will consume your information.

Sorry, what I meant to say was that Jaws will not support @title by default since it's configured to support @alt instead.

Of course, I agree with you that we should not develop according to tools, but according to standards. I've been advocating in that sense forl onger than I care to admit. But as much as I'd like everything to fit perfectly into place, sometimes we have no choice but to take into account the limitations of those tools if we want to reach the targeted audience.

Screen readers might - and do - deal with stuff differently (as they should, since they're more business-driven than standards compliancy driven), but just like for certain browsers, what the most popular does or prefers is what we have to deal with. It'S always been that way and probably partially ever will be.

I could decide to use only <abbr title=""> or <acronym title=""> because it's the "right" thing to do, but if 70% of users can't get the info because Jaws decided on certain default settings, I am not helping the people I do this for in the first place.


>>> I stand with what I was saying earlier: explain what the acronym or
>>> abbreviation means on it's first occurence in the page (other than
>>> navigation or headings, for obvious reasons) by presenting it
>>> explicitely first, then give out it's acronym or abbreviation in
>>> parenthesis. Seems like the best option to me, a win-win situation
>>> for everyone.
>
> This is not a wrong strategy, but it is not a complete strategy either
> (IMHO)

If you mean to say that we should do something like this, then I can certianly agree with you:

...blah blah blah <acronym title="North Atlantic Treaty Organisation">NATO</acronym> (North Atlantic Treaty Organisation) ...blah blah blah.

I could buy into this, but it still seems kind of overkill (and potentially redundant for some) to me.


--
Denis Boudreau
www.twitter.com/dboudreau

From: Denis Boudreau
Date: Wed, May 26 2010 3:54PM
Subject: Re: abbreviations
← Previous message | Next message →

Hey, me again.


On 2010-05-26, at 4:28 PM, John Foliot wrote:

> Denis Boudreau wrote:
>
>> Huh, I mean, an important part of an efficient approach to ensure
>> that some users with specific types of limitations have access
>> to content.
>
> Correct, which is why *not* using <abbr> simply because, in its default
> setting, JAWS (a commercial software package that runs on one operating
> system) does not voice out the value string is a wrong reason for not
> using <abbr>. This setting can be changed in JAWS quite easily, but more
> importantly adding <abbr> when required also enhances accessibility for
> some *other* users who may not be using a screen reader.

But most Jaws users will never change this because they need the @alt support more than they need the @title's. I'm guessing the approach is similar with other screen readers, is it not?

So unless something drastically changes with time, this might always be a problem.

Screen readers developers make us choose between @alt and @title because otherwise, users risk getting the information twice from otherwise well-intentioned authors who don't realize both would be read aloud.

I don't really see that behaviour changing anytime soon.. :/


> Bottom line: use <abbr> when appropriate.

But who would benefit? What's the real incentive?

Screen reader users will not see it,
User agents do not seem to interpret it,
Mouseless users will not benefit from it.

Sure the HTML spec likes it, but what kind of real gains does that entail for users?

Maybe the spec got that part wrong. The idea is good, but in reality, authors make it impossible to implement.

We've seen that happen with other elements or attributes in the past (summary, longdesc, acceskey, etc.), so why not with <abbr> and <acronym> too?

--
Denis Boudreau
www.twitter.com/dboudreau

From: John Foliot
Date: Wed, May 26 2010 3:57PM
Subject: Re: abbreviations
← Previous message | Next message →

Geof Collis wrote:

> Nice try but I dont buy your argument.

Which argument Geof?
The one where I point to the WCAG 2 Success Criteria URL that states that
<abbr> should be used?
Or the one where I confirm that <abbr> will be in HTML5?
Or the one where I suggest that expanding on an abbreviation or acronym
helps more than just users of JAWS?
Or that JAWS is not the only user-agent out there that we should be
developing for?
Or the one where I suggest that "author proposes, user disposes" is the
best path forward?
Or the one where I state that in many modern user-agents today, <abbr> and
<acronym> also render on screen traditionally with a dotted line under the
abbreviation (which could aid those sighted users with cognitive
disabilities)?

Or is it simply because:

>
>Geof Collis wrote:
> >
> > It would appear that by default my version of JAWS 10.0 has the
> > abbreviation and acronym turned off and that's just the way I like it.

I respect your right to have an opinion, but I disagree with you, and I've
stated why.

JF

From: djconley
Date: Wed, May 26 2010 4:12PM
Subject: Re: abbreviations
← Previous message | Next message →

Woo -- nice discussion everyone.

It's odd that the rationale behind alt or title is 'so they don't get it twice.'
Couldn't it read one or the other if it was the only thing present and the
specified option if both were? I don't know why they'd (by default?) choose alt,
which is only used on images (...right?)

I don't expand an abbr tag if there's an explanation next to it, but still use
the tag. So: North Atlantic Treaty Organization (NATO), and then
later Geof Collis wrote:
>
> > Nice try but I dont buy your argument.
>
> Which argument Geof?
> The one where I point to the WCAG 2 Success Criteria URL that states
> that should be used?
> Or the one where I confirm that will be in HTML5?
> Or the one where I suggest that expanding on an abbreviation or acronym
> helps more than just users of JAWS?
> Or that JAWS is not the only user-agent out there that we should be
> developing for?
> Or the one where I suggest that "author proposes, user disposes"
> is thebest path forward?
> Or the one where I state that in many modern user-agents today,
> and also render on screen traditionally with a dotted line
> under theabbreviation (which could aid those sighted users with cognitive
> disabilities)?
>
> Or is it simply because:
>
> >
> >Geof Collis wrote:
> > >
> > > It would appear that by default my version
> of JAWS 10.0 has the> > abbreviation and acronym turned off and
> that's just the way I like it.
> I respect your right to have an opinion, but I disagree with you, and
> I'vestated why.
>
> JF
>

From: Geof Collis
Date: Wed, May 26 2010 4:42PM
Subject: Re: abbreviations
← Previous message | Next message →

No John, the one where you say I HAVE to use it.

I wont use the tags but I'll expand an abbreviation/acronym once in
an article or document and as you say "where appropriate" that is
where I think it is appropriate not on every single instance



At 04:58 PM 5/26/2010, you wrote:
>Geof Collis wrote:
>
> > Nice try but I dont buy your argument.
>
>Which argument Geof?
>The one where I point to the WCAG 2 Success Criteria URL that states that
><abbr> should be used?
>Or the one where I confirm that <abbr> will be in HTML5?
>Or the one where I suggest that expanding on an abbreviation or acronym
>helps more than just users of JAWS?
>Or that JAWS is not the only user-agent out there that we should be
>developing for?
>Or the one where I suggest that "author proposes, user disposes" is the
>best path forward?
>Or the one where I state that in many modern user-agents today, <abbr> and
><acronym> also render on screen traditionally with a dotted line under the
>abbreviation (which could aid those sighted users with cognitive
>disabilities)?
>
>Or is it simply because:
>
> >
> >Geof Collis wrote:
> > >
> > > It would appear that by default my version of JAWS 10.0 has the
> > > abbreviation and acronym turned off and that's just the way I like it.
>
>I respect your right to have an opinion, but I disagree with you, and I've
>stated why.
>
>JF
>

From: Geof Collis
Date: Wed, May 26 2010 6:39PM
Subject: Re: abbreviations
← Previous message | Next message →

Hi John

Now I know where I read it:

Examples of Success Criterion 3.1.4
An abbreviation whose expansion is provided the first time the
abbreviation appears in the content.

The name, "World Wide Web Consortium," appears as the first heading
on the organization's home page. The abbreviation, "W3C," is enclosed
in parentheses
in the same heading.

http://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-located.html

cheers

Geof

At 04:18 PM 5/26/2010, you wrote:
>Geof Collis wrote:
> >
> > I'm not sure where I read it but that is also the method I have
> > adopted because of it.
> >
> > I also have to wonder how using it will help someone who can't use a
>mouse.
>
>Sorry Geoff, this is simply the wrong perspective to be taking here: don't
>develop for specific devices or software, develop according to standards.
>Any other strategy will end up biting you in the back end at some point in
>time.
>
>
> >>
> >> It means that Jaws will NOT support the @title in <abbr> and <acronym>.
>
>It means nothing of the sort. It is simply a user setting that can be
>adjusted in a particular piece of software, and what JAWS does versus what
>NVDA does (versus what Voiceover does, and HAL, and WindowEyes, and...) is
>already a hugely different kettle of fish. Again, developing for a piece
>of software or a specific device is the wrong way forward - develop to the
>standards and let the software/end user make the choice of how and what
>they will consume your information.
>
> >>
> >> I stand with what I was saying earlier: explain what the acronym or
> >> abbreviation means on it's first occurence in the page (other than
> >> navigation or headings, for obvious reasons) by presenting it
> >> explicitely first, then give out it's acronym or abbreviation in
> >> parenthesis. Seems like the best option to me, a win-win situation
> >> for everyone.
>
>This is not a wrong strategy, but it is not a complete strategy either
>(IMHO)
>
>JF
>

From: ckrugman
Date: Thu, May 27 2010 4:18PM
Subject: Re: abbreviations
← Previous message | Next message →

This is ridiculous. All professional articles use standard abbreviations and
acronyms such as HIV. As a blind person with a master's degree and
additional advanced training to think that a person relying on accessibility
with screen readers or other accessibility tools would not be aware of
accepted societal abbreviations is insulting. This goes way beyond concepts
of accessibility and reasonable accommodation. I don't know where this
originally came from but a reader of an article or visitor to a web site
that relies on accessibility tools may have a disability but stupidity is
not a disability that needs to be accommodated when making the internet
accessible.
Chuck
----- Original Message -----
From: "Dan Conley" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, May 26, 2010 8:02 AM
Subject: [WebAIM] abbreviations


> Apologies if this has been discussed ad nauseam already.
>
> I know Jared has said in the past that WebAIM has shifted away from
> abbreviating from abbreviating common terms like HTML. I've considered
> this -- I expand things like PDF and etc, which probably do more harm
> than good -- but haven't actually changed anything yet, as our grant is
> nearly up and I plan on doing a site revamp if/when we're refunded.
>
> I'm being forced to confront the issue now, though, as I'm formatting a
> long article on HIV/AIDS, and I think having the text 'Human
> Immunodeficiency Virus/Acquired Immune Deficiency Syndrome' repeated at
> least once a paragraph would get wordy (and confusing) very quickly.
>
> So: is this something I should just let slide without a tag? Should I
> give them plain <abbr> tags? I don't know how screen readers would
> approach it, or if people are used to hearing 'hiv' pronounced and can
> auto-correct it in their head.
>
> --
> Dan Conley
> Information Specialist
> Center for International Rehabilitation Research Information and
> Exchange (CIRRIE)
> University at Buffalo, Health Sciences Library B6
> Phone: (716) 829-5728
> = EMAIL ADDRESS REMOVED =
> http://cirrie.buffalo.edu
>
>

From: Denis Boudreau
Date: Thu, May 27 2010 4:42PM
Subject: Re: abbreviations
← Previous message | Next message →

Chuck,

You are missing the point. It's not a matter of assuming that blind
people wouldn't know what sighted people would. It's a matter of
making sure that all users have a fair chance of understanding what an
acronym or abbreviation actually means.

Not all abreviations and acronyms are widely known. For instance can
you tell me what MDEIE means? Or SGQRI for that matter? Google will or
might tell you, but no users should have to resort to a search engine
to understand what any page or piece of content is talking about.

If anything, it's more a matter of making sure that people dealing
with cognitive limitations would understand as well (or at the very
least, that they'd have a fair chance at understanding).

No one implied anything about screen reader users. That is besides the
point. If anything, all we said was that for users with visual
disabilities, extra care had to be taken so the tools they are using
would also be able to interpret whatever signification was provided
through the mechanism put in place.

/Denis

Sent from my iPhone.


On 2010-05-27, at 17:19, < = EMAIL ADDRESS REMOVED = > wrote:

> This is ridiculous. All professional articles use standard
> abbreviations and
> acronyms such as HIV. As a blind person with a master's degree and
> additional advanced training to think that a person relying on
> accessibility
> with screen readers or other accessibility tools would not be aware of
> accepted societal abbreviations is insulting. This goes way beyond
> concepts
> of accessibility and reasonable accommodation. I don't know where this
> originally came from but a reader of an article or visitor to a web
> site
> that relies on accessibility tools may have a disability but
> stupidity is
> not a disability that needs to be accommodated when making the
> internet
> accessible.
> Chuck
> ----- Original Message -----
> From: "Dan Conley" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Wednesday, May 26, 2010 8:02 AM
> Subject: [WebAIM] abbreviations
>
>
>> Apologies if this has been discussed ad nauseam already.
>>
>> I know Jared has said in the past that WebAIM has shifted away from
>> abbreviating from abbreviating common terms like HTML. I've
>> considered
>> this -- I expand things like PDF and etc, which probably do more harm
>> than good -- but haven't actually changed anything yet, as our
>> grant is
>> nearly up and I plan on doing a site revamp if/when we're refunded.
>>
>> I'm being forced to confront the issue now, though, as I'm
>> formatting a
>> long article on HIV/AIDS, and I think having the text 'Human
>> Immunodeficiency Virus/Acquired Immune Deficiency Syndrome'
>> repeated at
>> least once a paragraph would get wordy (and confusing) very quickly.
>>
>> So: is this something I should just let slide without a tag? Should I
>> give them plain <abbr> tags? I don't know how screen readers would
>> approach it, or if people are used to hearing 'hiv' pronounced and
>> can
>> auto-correct it in their head.
>>
>> --
>> Dan Conley
>> Information Specialist
>> Center for International Rehabilitation Research Information and
>> Exchange (CIRRIE)
>> University at Buffalo, Health Sciences Library B6
>> Phone: (716) 829-5728
>> = EMAIL ADDRESS REMOVED =
>> http://cirrie.buffalo.edu
>>
>>

From: ckrugman
Date: Thu, May 27 2010 5:18PM
Subject: Re: abbreviations
← Previous message | Next message →

The proper format for the acquired immune deficiency syndrome is "AIDS" in
all capital letters. This avoids any potential confusion.
Chuck
----- Original Message -----
From: "Dan Conley" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, May 26, 2010 9:11 AM
Subject: Re: [WebAIM] abbreviations


> The issue as I understood it (and I admit that my accessibility training
> is now a few years old, but the content of the site hasn't changed much,
> so I assume/hope it's all still relevant) is that the nature of the web
> allows for users to jump into a page without starting at the top, and so
> it's possible they would have missed that first expansion (each article
> has a table of contents with links to each h2, so if they wanted to they
> could skip the introduction).
>
> What I didn't realize then, and what my issue really is now, is that
> there are some acronyms ('Portable Document Format') that actually may
> be MORE confusing spelled out than in abbreviated form. Out of context I
> think AIDS could go either way (we're a rehab site, so communication
> aids, etc), but in an article about HIV and AIDS it seems unnecessary.
> (Originally my concerns were also for users with intellectual
> disabilities, but while we do provide less technical versions of complex
> articles on the whole these are still aimed at rehab professionals, so...)
>
> Thanks for everyone's responses so far. At least there isn't an
> overwhelming chorus of people telling me how wrong I've been all this
> time.
>
> Dan Conley
> Information Specialist
> Center for International Rehabilitation Research Information and
> Exchange (CIRRIE)
> University at Buffalo, Health Sciences Library B6
> Phone: (716) 829-5728
> = EMAIL ADDRESS REMOVED =
> http://cirrie.buffalo.edu
>
> On 5/26/2010 11:48 AM, = EMAIL ADDRESS REMOVED = wrote:
>> Presumably it should depend on the common usage of the acronym.
>> Far more people are going to recognize "HIV/AIDS" than will
>> recognize "Acquired Immune Deficiency Syndrome".
>>
>> The standard practice for sighted users in formal documents would
>> be to define the term in the first usage along with the acronym,
>> and then use the acronym throughout. E.g.:
>>
>> "Acquired Immune Deficiency Syndrome (AIDS)".
>>
>> Surely that would also be best practice for screen reader users?
>>
>> -deborah
>>

From: John Foliot
Date: Thu, May 27 2010 6:12PM
Subject: Re: abbreviations
← Previous message | Next message →

< = EMAIL ADDRESS REMOVED = > wrote:
>
> This is ridiculous. All professional articles use standard
> abbreviations and
> acronyms such as HIV. As a blind person with a master's degree and
> additional advanced training to think that a person relying on
> accessibility
> with screen readers or other accessibility tools would not be aware of
> accepted societal abbreviations is insulting. This goes way beyond
> concepts
> of accessibility and reasonable accommodation. I don't know where
> this
> originally came from but a reader of an article or visitor to a web
> site
> that relies on accessibility tools may have a disability but
> stupidity is
> not a disability that needs to be accommodated when making the
> internet
> accessible.
> Chuck


And an article about the ADA is about what Chuck?

This is not about insulting anyone's intelligence, but it is about
ensuring accurate and complete information for all consumers of the data
when required. As I mentioned in a note on this thread yesterday, some
acronyms and abbreviations have become part of our normal language, such
as 'words' like AIDS and HIV. However it is not always as clear cut, and
it is incumbent on the content producer to remove ambiguities whenever
possible. Again, as a general rule of thumb, when *I* am not sure I turn
to Wikipedia and Miriam-Webster: if they have dedicated entries to the
term (as both do for AIDS) then I let it slide; however if Wikipedia has a
disambiguation page (as they do for ADA -
http://en.wikipedia.org/wiki/Ada), then I ensure that the <abbr> element
is used. That is neither insulting nor paternal, it is due diligence and
appropriateness.

JF

(BTW, I was thinking of the American Diabetes Association -
http://www.diabetes.org - in my first sentence...)

From: John Foliot
Date: Thu, May 27 2010 6:24PM
Subject: Re: abbreviations
← Previous message | Next message →

Geof Collis wrote:
>
> No John, the one where you say I HAVE to use it.

FWIW I've never said anyone HAS to do anything - you are free to do as you
wish. I make my opinions and recommendations available to those who might
ask, and give supporting reasons and URLs to back those reasons. If you
chose to not take the suggestion, that's fine too.

****
As a follow up to yesterdays discussion, I pinged a daily user of NVDA,
and someone who is actively involved/interested in NVDA's development, but
who works for Mozilla as an accessibility specialist: Marco Zehe. This is
what he wrote back:

"NVDA doesn't do any special processing with the title attribute, but when
present, the "read current object" command, NVDA+NUM PAD 5, will read the
title as the name for the text frame object Firefox creates. For example
if you have this snippet:

<p>This <abbr title="Non-Visual Desktop Access">NVDA</abbr> screen reader
is not an <acronym title="People can't memorize computer industry
acronyms">PCMCIA</acronym> device.</p>

and navigate to "NVDA" using the virtual cursor, then press NVDA+NUM PAD
5, NVDA will read "non-visual desktop access text frame". But they do
currently not give an automatic indication that a particular word is an
acronym or abbreviation."

(I read this BTW as the title attribute on *any* element, not just ABBR)

So, if JAWS can't or won't expose the title attribute on demand it is a
flaw with the software, not of the code specification. It is too bad that
NVDA doesn't notify the user that there is a title value to the ABBR
element, but maybe that is a good thing: there is such a thing as too much
information as well. However it is confirmed that if you use the ABBR
element with a title value, users of NVDA at least can query what the
abbreviation or acronym means and be informed of such.

That's why I will do it. Y'all are free to do as you choose <grin>.

JF

From: Geof Collis
Date: Thu, May 27 2010 6:36PM
Subject: Re: abbreviations
← Previous message | Next message →

Hi John

What I got from all of this is "there is such a thing as too much
information" :O)

cheers

Geof

At 07:26 PM 5/27/2010, you wrote:
>Geof Collis wrote:
> >
> > No John, the one where you say I HAVE to use it.
>
>FWIW I've never said anyone HAS to do anything - you are free to do as you
>wish. I make my opinions and recommendations available to those who might
>ask, and give supporting reasons and URLs to back those reasons. If you
>chose to not take the suggestion, that's fine too.
>
>****
>As a follow up to yesterdays discussion, I pinged a daily user of NVDA,
>and someone who is actively involved/interested in NVDA's development, but
>who works for Mozilla as an accessibility specialist: Marco Zehe. This is
>what he wrote back:
>
>"NVDA doesn't do any special processing with the title attribute, but when
>present, the "read current object" command, NVDA+NUM PAD 5, will read the
>title as the name for the text frame object Firefox creates. For example
>if you have this snippet:
>
><p>This <abbr title="Non-Visual Desktop Access">NVDA</abbr> screen reader
>is not an <acronym title="People can't memorize computer industry
>acronyms">PCMCIA</acronym> device.</p>
>
>and navigate to "NVDA" using the virtual cursor, then press NVDA+NUM PAD
>5, NVDA will read "non-visual desktop access text frame". But they do
>currently not give an automatic indication that a particular word is an
>acronym or abbreviation."
>
>(I read this BTW as the title attribute on *any* element, not just ABBR)
>
>So, if JAWS can't or won't expose the title attribute on demand it is a
>flaw with the software, not of the code specification. It is too bad that
>NVDA doesn't notify the user that there is a title value to the ABBR
>element, but maybe that is a good thing: there is such a thing as too much
>information as well. However it is confirmed that if you use the ABBR
>element with a title value, users of NVDA at least can query what the
>abbreviation or acronym means and be informed of such.
>
>That's why I will do it. Y'all are free to do as you choose <grin>.
>
>JF
>
>

From: Jukka K. Korpela
Date: Thu, May 27 2010 10:12PM
Subject: Re: abbreviations
← Previous message | Next message →

= EMAIL ADDRESS REMOVED = wrote:

> The proper format for the acquired immune deficiency syndrome is
> "AIDS" in all capital letters.

According to some authorities or just opinions, maybe. According to some
other authorities or opinions, "aids" shall be written in lowercase because
it is pronounced as a word (i.e., it is an acronym in the original sense of
that word).

> This avoids any potential confusion.

Even when read aloud?

There are always possibilities for confusion, and in this particular case,
you don't even need much imagination.

On the other hand, using <abbr> or <acronym> markup would help remarkably
little if at all in reducing confusion. To begin with, the vast majority of
people use browsing software that either ignores such markup completely or
uses it in misleading ways, like underlining the element's content in a
manner that suggests that it is some kind of a link, even though it isn't.

So recognizing the problems does not mean that we should use some particular
techniques purported to solve them, when they actually don't.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

From: John Foliot
Date: Thu, May 27 2010 11:21PM
Subject: Re: abbreviations
← Previous message | Next message →

Jukka K. Korpela wrote:
>
> On the other hand, using <abbr> or <acronym> markup would help
> remarkably
> little if at all in reducing confusion. To begin with, the vast
> majority of
> people use browsing software that either ignores such markup completely
> or
> uses it in misleading ways, like underlining the element's content in a
> manner that suggests that it is some kind of a link, even though it
> isn't.

Hi Jukka,

How/what would you propose be done instead? If we can agree that a
mechanism that aids in disambiguation is a good thing - yet currently
<abbr> is failing at that - is there a better way? Should user agents do
more, or should we look to another mechanism instead? With on-going work
within HTML5, and an accessibility Task Force at the W3C (that involves
browser makers) currently very active, could a better solution be put
forward? Now is the time to specifically define what we need and what we
should have.

Does anyone on this list have any ideas?

JF

From: Geof Collis
Date: Fri, May 28 2010 6:36AM
Subject: Re: abbreviations
← Previous message | Next message →

I have an idea, why not just use the current example that I posted,
expand the abbreviation in the first instance and be done with it. :O)

At 12:23 AM 5/28/2010, you wrote:
>Jukka K. Korpela wrote:
> >
> > On the other hand, using <abbr> or <acronym> markup would help
> > remarkably
> > little if at all in reducing confusion. To begin with, the vast
> > majority of
> > people use browsing software that either ignores such markup completely
> > or
> > uses it in misleading ways, like underlining the element's content in a
> > manner that suggests that it is some kind of a link, even though it
> > isn't.
>
>Hi Jukka,
>
>How/what would you propose be done instead? If we can agree that a
>mechanism that aids in disambiguation is a good thing - yet currently
><abbr> is failing at that - is there a better way? Should user agents do
>more, or should we look to another mechanism instead? With on-going work
>within HTML5, and an accessibility Task Force at the W3C (that involves
>browser makers) currently very active, could a better solution be put
>forward? Now is the time to specifically define what we need and what we
>should have.
>
>Does anyone on this list have any ideas?
>
>JF
>
>

From: Dan Conley
Date: Fri, May 28 2010 7:21AM
Subject: Re: abbreviations
← Previous message | Next message →

> I have an idea, why not just use the current example that I posted,
> expand the abbreviation in the first instance and be done with it. :O)

And then someone skips to an anchor halfway down the page and misses it.

I think what's perhaps the most important thing I've gotten out of this
discussion is that many people don't care about abbreviations, and those
people have and use the ability to ignore them completely. The abbr tag
isn't being forced down anyone's throats (which was my initial fear).

There are some instances where an abbreviation isn't necessary. My
example of HIV in an article titled Human Immunodeficiency Virus is a
pretty obvious example. But I'm very hesitant to say I'm going to
approach this on a case by case basis, because then I declare myself the
gatekeeper of what's 'obvious' or not, which won't be the same from
person to person.

If something is an abbreviation, shouldn't it by definition be given the
abbreviation markup? If you don't like the underline it can be styled
away. If people ignore it then that seems, for the most part, to be by
their design (and if not, then in each of the articles I work on and in
any well written document I'd expect there to be the 'expand on first
use' practice anyway)

Dan Conley
Information Specialist
Center for International Rehabilitation Research Information and
Exchange (CIRRIE)
University at Buffalo, Health Sciences Library B6
Phone: (716) 829-5728
= EMAIL ADDRESS REMOVED =
http://cirrie.buffalo.edu

On 5/28/2010 7:36 AM, Geof Collis wrote:
> I have an idea, why not just use the current example that I posted,
> expand the abbreviation in the first instance and be done with it. :O)
>
> At 12:23 AM 5/28/2010, you wrote:
>> Jukka K. Korpela wrote:
>>>
>>> On the other hand, using<abbr> or<acronym> markup would help
>>> remarkably
>>> little if at all in reducing confusion. To begin with, the vast
>>> majority of
>>> people use browsing software that either ignores such markup completely
>>> or
>>> uses it in misleading ways, like underlining the element's content in a
>>> manner that suggests that it is some kind of a link, even though it
>>> isn't.
>>
>> Hi Jukka,
>>
>> How/what would you propose be done instead? If we can agree that a
>> mechanism that aids in disambiguation is a good thing - yet currently
>> <abbr> is failing at that - is there a better way? Should user agents do
>> more, or should we look to another mechanism instead? With on-going work
>> within HTML5, and an accessibility Task Force at the W3C (that involves
>> browser makers) currently very active, could a better solution be put
>> forward? Now is the time to specifically define what we need and what we
>> should have.
>>
>> Does anyone on this list have any ideas?
>>
>> JF
>>
>>

From: Geof Collis
Date: Fri, May 28 2010 7:48AM
Subject: Re: abbreviations
← Previous message | Next message →

So whose fault is it if they dont start at the beginning of the
content? That doesn't make any sense. Perhaps we should have a
tag that says start here in case you miss any
accessibility features on this page?

If people use the abbr and acr tags, what happens if someone prints
off the page? Copies from one medium to another? The real meaning
doesn't go with it so how does that help?
At 08:21 AM 5/28/2010, you wrote:
> > I have an idea, why not just use the current example that I posted,
> > expand the abbreviation in the first instance and be done with it. :O)
>
>And then someone skips to an anchor halfway down the page and misses it.
>
>I think what's perhaps the most important thing I've gotten out of this
>discussion is that many people don't care about abbreviations, and those
>people have and use the ability to ignore them completely. The abbr tag
>isn't being forced down anyone's throats (which was my initial fear).
>
>There are some instances where an abbreviation isn't necessary. My
>example of HIV in an article titled Human Immunodeficiency Virus is a
>pretty obvious example. But I'm very hesitant to say I'm going to
>approach this on a case by case basis, because then I declare myself the
>gatekeeper of what's 'obvious' or not, which won't be the same from
>person to person.
>
>If something is an abbreviation, shouldn't it by definition be given the
>abbreviation markup? If you don't like the underline it can be styled
>away. If people ignore it then that seems, for the most part, to be by
>their design (and if not, then in each of the articles I work on and in
>any well written document I'd expect there to be the 'expand on first
>use' practice anyway)
>
>Dan Conley
>Information Specialist
>Center for International Rehabilitation Research Information and
>Exchange (CIRRIE)
>University at Buffalo, Health Sciences Library B6
>Phone: (716) 829-5728
> = EMAIL ADDRESS REMOVED =
>http://cirrie.buffalo.edu
>
>On 5/28/2010 7:36 AM, Geof Collis wrote:
> > I have an idea, why not just use the current example that I posted,
> > expand the abbreviation in the first instance and be done with it. :O)
> >
> > At 12:23 AM 5/28/2010, you wrote:
> >> Jukka K. Korpela wrote:
> >>>
> >>> On the other hand, using<abbr> or<acronym> markup would help
> >>> remarkably
> >>> little if at all in reducing confusion. To begin with, the vast
> >>> majority of
> >>> people use browsing software that either ignores such markup completely
> >>> or
> >>> uses it in misleading ways, like underlining the element's content in a
> >>> manner that suggests that it is some kind of a link, even though it
> >>> isn't.
> >>
> >> Hi Jukka,
> >>
> >> How/what would you propose be done instead? If we can agree that a
> >> mechanism that aids in disambiguation is a good thing - yet currently
> >> <abbr> is failing at that - is there a better way? Should user agents do
> >> more, or should we look to another mechanism instead? With on-going work
> >> within HTML5, and an accessibility Task Force at the W3C (that involves
> >> browser makers) currently very active, could a better solution be put
> >> forward? Now is the time to specifically define what we need and what we
> >> should have.
> >>
> >> Does anyone on this list have any ideas?
> >>
> >> JF
> >>
> >>

From: Dan Conley
Date: Fri, May 28 2010 7:57AM
Subject: Re: abbreviations
← Previous message | Next message →

If we can start punishing users for their actions then I need to go back
through my site and remove all the IE hacks and concessions I've had to
make.

If they print the page then they don't get the abbreviations, yes. But
that's why it should be expanded on first use. If they read it on the
page then there's extra functionality. By your logic we shouldn't link
to anything because tapping on the printed paper won't take them anywhere.

There's functionality which enriches the content but which still conveys
the original intent if ignored or not displayed. Isn't that the whole
point of accessibility?

Dan Conley
Information Specialist
Center for International Rehabilitation Research Information and
Exchange (CIRRIE)
University at Buffalo, Health Sciences Library B6
Phone: (716) 829-5728
= EMAIL ADDRESS REMOVED =
http://cirrie.buffalo.edu

On 5/28/2010 8:48 AM, Geof Collis wrote:
> So whose fault is it if they dont start at the beginning of the
> content? That doesn't make any sense. Perhaps we should have a
> tag that says start here in case you miss any
> accessibility features on this page?
>
> If people use the abbr and acr tags, what happens if someone prints
> off the page? Copies from one medium to another? The real meaning
> doesn't go with it so how does that help?
> At 08:21 AM 5/28/2010, you wrote:
>> > I have an idea, why not just use the current example that I posted,
>> > expand the abbreviation in the first instance and be done with it. :O)
>>
>> And then someone skips to an anchor halfway down the page and misses it.
>>
>> I think what's perhaps the most important thing I've gotten out of this
>> discussion is that many people don't care about abbreviations, and those
>> people have and use the ability to ignore them completely. The abbr tag
>> isn't being forced down anyone's throats (which was my initial fear).
>>
>> There are some instances where an abbreviation isn't necessary. My
>> example of HIV in an article titled Human Immunodeficiency Virus is a
>> pretty obvious example. But I'm very hesitant to say I'm going to
>> approach this on a case by case basis, because then I declare myself the
>> gatekeeper of what's 'obvious' or not, which won't be the same from
>> person to person.
>>
>> If something is an abbreviation, shouldn't it by definition be given the
>> abbreviation markup? If you don't like the underline it can be styled
>> away. If people ignore it then that seems, for the most part, to be by
>> their design (and if not, then in each of the articles I work on and in
>> any well written document I'd expect there to be the 'expand on first
>> use' practice anyway)
>>
>> Dan Conley
>> Information Specialist
>> Center for International Rehabilitation Research Information and
>> Exchange (CIRRIE)
>> University at Buffalo, Health Sciences Library B6
>> Phone: (716) 829-5728
>> = EMAIL ADDRESS REMOVED =
>> http://cirrie.buffalo.edu
>>
>> On 5/28/2010 7:36 AM, Geof Collis wrote:
>>> I have an idea, why not just use the current example that I posted,
>>> expand the abbreviation in the first instance and be done with it. :O)
>>>
>>> At 12:23 AM 5/28/2010, you wrote:
>>>> Jukka K. Korpela wrote:
>>>>>
>>>>> On the other hand, using<abbr> or<acronym> markup would help
>>>>> remarkably
>>>>> little if at all in reducing confusion. To begin with, the vast
>>>>> majority of
>>>>> people use browsing software that either ignores such markup completely
>>>>> or
>>>>> uses it in misleading ways, like underlining the element's content in a
>>>>> manner that suggests that it is some kind of a link, even though it
>>>>> isn't.
>>>>
>>>> Hi Jukka,
>>>>
>>>> How/what would you propose be done instead? If we can agree that a
>>>> mechanism that aids in disambiguation is a good thing - yet currently
>>>> <abbr> is failing at that - is there a better way? Should user agents do
>>>> more, or should we look to another mechanism instead? With on-going work
>>>> within HTML5, and an accessibility Task Force at the W3C (that involves
>>>> browser makers) currently very active, could a better solution be put
>>>> forward? Now is the time to specifically define what we need and what we
>>>> should have.
>>>>
>>>> Does anyone on this list have any ideas?
>>>>
>>>> JF
>>>>
>>>>

From: Duff Johnson
Date: Fri, May 28 2010 8:03AM
Subject: Re: abbreviations
← Previous message | Next message →

On May 28, 2010, at 8:21 AM, Dan Conley wrote:

> >There are some instances where an abbreviation isn't necessary. My
> example of HIV in an article titled Human Immunodeficiency Virus is a
> pretty obvious example.

...and it's not hard to come up with pretty obvious counter-examples too, even within such an article:

"His aids told us everything we needed to know."
"His aides told us everything we needed to know."

> >But I'm very hesitant to say I'm going to
> approach this on a case by case basis, because then I declare myself the
> gatekeeper of what's 'obvious' or not, which won't be the same from
> person to person.

The subject is properly a matter for Standards followed by conforming software implementations. Essentially, the option to identify and use such tags is key.

> >If something is an abbreviation, shouldn't it by definition be given the
> abbreviation markup?

That would be correct best practice. It is up to the consuming software (and the human running the show) to deal with it.

Duff Johnson
Appligent Document Solutions, CEO
US Committee for ISO/CD 14289 (PDF/UA), Chair

22 E. Baltimore Ave
Lansdowne, PA 19050
+1 610 284 4006
+1 617 553 1934 (direct)
= EMAIL ADDRESS REMOVED =
http://www.appligent.com
http://www.twitter.com/duffjohnson

From: Geof Collis
Date: Fri, May 28 2010 8:06AM
Subject: Re: abbreviations
← Previous message | Next message →

What are you talking about?

I've been advocating all along that it should be expanded on its
first instance, just as the WCAG says I can.





At 08:58 AM 5/28/2010, you wrote:
>If we can start punishing users for their actions then I need to go back
>through my site and remove all the IE hacks and concessions I've had to
>make.
>
>If they print the page then they don't get the abbreviations, yes. But
>that's why it should be expanded on first use. If they read it on the
>page then there's extra functionality. By your logic we shouldn't link
>to anything because tapping on the printed paper won't take them anywhere.
>
>There's functionality which enriches the content but which still conveys
>the original intent if ignored or not displayed. Isn't that the whole
>point of accessibility?
>
>Dan Conley
>Information Specialist
>Center for International Rehabilitation Research Information and
>Exchange (CIRRIE)
>University at Buffalo, Health Sciences Library B6
>Phone: (716) 829-5728
> = EMAIL ADDRESS REMOVED =
>http://cirrie.buffalo.edu
>
>On 5/28/2010 8:48 AM, Geof Collis wrote:
> > So whose fault is it if they dont start at the beginning of the
> > content? That doesn't make any sense. Perhaps we should have a
> > tag that says start here in case you miss any
> > accessibility features on this page?
> >
> > If people use the abbr and acr tags, what happens if someone prints
> > off the page? Copies from one medium to another? The real meaning
> > doesn't go with it so how does that help?
> > At 08:21 AM 5/28/2010, you wrote:
> >> > I have an idea, why not just use the current example that I posted,
> >> > expand the abbreviation in the first instance and be done
> with it. :O)
> >>
> >> And then someone skips to an anchor halfway down the page and misses it.
> >>
> >> I think what's perhaps the most important thing I've gotten out of this
> >> discussion is that many people don't care about abbreviations, and those
> >> people have and use the ability to ignore them completely. The abbr tag
> >> isn't being forced down anyone's throats (which was my initial fear).
> >>
> >> There are some instances where an abbreviation isn't necessary. My
> >> example of HIV in an article titled Human Immunodeficiency Virus is a
> >> pretty obvious example. But I'm very hesitant to say I'm going to
> >> approach this on a case by case basis, because then I declare myself the
> >> gatekeeper of what's 'obvious' or not, which won't be the same from
> >> person to person.
> >>
> >> If something is an abbreviation, shouldn't it by definition be given the
> >> abbreviation markup? If you don't like the underline it can be styled
> >> away. If people ignore it then that seems, for the most part, to be by
> >> their design (and if not, then in each of the articles I work on and in
> >> any well written document I'd expect there to be the 'expand on first
> >> use' practice anyway)
> >>
> >> Dan Conley
> >> Information Specialist
> >> Center for International Rehabilitation Research Information and
> >> Exchange (CIRRIE)
> >> University at Buffalo, Health Sciences Library B6
> >> Phone: (716) 829-5728
> >> = EMAIL ADDRESS REMOVED =
> >> http://cirrie.buffalo.edu
> >>
> >> On 5/28/2010 7:36 AM, Geof Collis wrote:
> >>> I have an idea, why not just use the current example that I posted,
> >>> expand the abbreviation in the first instance and be done with it. :O)
> >>>
> >>> At 12:23 AM 5/28/2010, you wrote:
> >>>> Jukka K. Korpela wrote:
> >>>>>
> >>>>> On the other hand, using<abbr> or<acronym> markup would help
> >>>>> remarkably
> >>>>> little if at all in reducing confusion. To begin with, the vast
> >>>>> majority of
> >>>>> people use browsing software that either ignores such markup completely
> >>>>> or
> >>>>> uses it in misleading ways, like underlining the element's content in a
> >>>>> manner that suggests that it is some kind of a link, even though it
> >>>>> isn't.
> >>>>
> >>>> Hi Jukka,
> >>>>
> >>>> How/what would you propose be done instead? If we can agree that a
> >>>> mechanism that aids in disambiguation is a good thing - yet currently
> >>>> <abbr> is failing at that - is there a better way? Should
> user agents do
> >>>> more, or should we look to another mechanism instead? With
> on-going work
> >>>> within HTML5, and an accessibility Task Force at the W3C (that involves
> >>>> browser makers) currently very active, could a better solution be put
> >>>> forward? Now is the time to specifically define what we need and what we
> >>>> should have.
> >>>>
> >>>> Does anyone on this list have any ideas?
> >>>>
> >>>> JF
> >>>>
> >>>>

From: Denis Boudreau
Date: Fri, May 28 2010 9:33AM
Subject: Re: abbreviations
← Previous message | Next message →

Hey John,

On 2010-05-28, at 12:23 AM, John Foliot wrote:

> How/what would you propose be done instead? If we can agree that a mechanism that aids in disambiguation is a good thing - yet currently <abbr> is failing at that - is there a better way? Should user agents do more, or should we look to another mechanism instead? With on-going work within HTML5, and an accessibility Task Force at the W3C (that involves browser makers) currently very active, could a better solution be put forward? Now is the time to specifically define what we need and what we should have.
>
> Does anyone on this list have any ideas?


Well, I may be completely off track here but bear with me for a sec.

One option could be that when a screen reader (or any type of assistive technology for that matter) parses a page and finds either an <acronym title=""> or <abbr title=""> tag, it would store it in some kind of buffer memory (possibly flushed out one page reload or whatever, but temporarily stocked for reference if need be).

So anytime the given abbreviation or acronym is encountered in the page, even if it wasn't tagged, the tools used could refer to that buffer memory and give out the extended meaning.

If such a mechanism existed then we could give out the full detailed version on it's first occurrence (with said abbr/acronym in parenthesis, properly tagged). We wouldn't need to tag all other occurrences in the document with the appropriate HTML tag (along with descriptive @title) since any of them would refer to the one occurrence identified while parsing.

I think that with such a system, everyone would win.

Could that make sense?

--
Denis Boudreau
www.twitter.com/dboudreau

From: Jared Smith
Date: Fri, May 28 2010 10:36AM
Subject: Re: abbreviations
← Previous message | Next message →

On Fri, May 28, 2010 at 8:34 AM, Denis Boudreau wrote:

> So anytime the given abbreviation or acronym is encountered in the page, even if it wasn't tagged, the tools used could refer to that buffer memory and give out the extended meaning.

Precisely! However, to reduce repetition, screen readers should only
read the extended meaning the first time it is encountered anywhere
within the document, even if that occurrence is not the one that is
actually marked up. This way you could fully expand in text the first
instance and then provide the <acronym title="whatever"> or <abbr
title="whatever"> at any other single instance. This would adequately
address the major issues we've discussed.

Of course this doesn't work with many acronyms, such as AT. How would
a screen reader know that it is the acronym AT versus the word "at"
(or AIDS or aids)? In this case, I argue that simply
<acronym>AT</acronym> (without title) would identify acronyms which
are expanded elsewhere in the document. It's stupid simple for user
agents to reference the title attribute value of this acronym
elsewhere in the document.

This is exactly what I recommended when we discussed this a year ago -
http://webaim.org/discussion/mail_thread.php?thread=3805#post11 Of
course, like many things in accessibility, this only works if screen
readers adopt this behavior, which isn't terribly likely.

You do want to avoid things like...
<acronym title="Assistive Technology">AT</acronym> (Assistive Technology)

If a screen reader is set to read the acronym titles, they would hear
"Assistive Technology (Assistive Technology)" with no indication as to
what the actual acronym is. For this reason, I recommend expanding in
text in the first instance and with <acronym> or <abbr> in the next or
next most significant instance.

Jared

From: Simius Puer
Date: Fri, May 28 2010 10:57AM
Subject: Re: abbreviations
← Previous message | Next message →

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.

From: Jukka K. Korpela
Date: Fri, May 28 2010 11:03AM
Subject: Re: abbreviations
← Previous message | Next message →

Jared Smith wrote:

> [...] acronyms, such as AT. How would
> a screen reader know that it is the acronym AT versus the word "at"
> (or AIDS or aids)?

You seem to use the word "acronym" to mean an initialism, specifically one
that should be read by pronouncing its letters (or maybe expanded to the
expression from which it has been formed). This is a common idea and often
reflected in W3C material, but the original meaning, still what the word
means to many people, is...
"a word (as NATO, radar, or laser) formed from the initial letter or letters
of each of the successive parts or major parts of a compound term"
to quote Merriam-Webster (
http://www.merriam-webster.com/dictionary/acronym ).

So it would not be correct at all to read AT as "A T" (ey tee) just because
it has been marked up as an acronym. Quite the opposite: calling it an
acronym should mean that it should be read as a word, like "NATO", "radar",
or "laser"!

We should distinguish between pronunciation and meaning. They are orthogonal
things, logically, though sometimes connected. One of the basic flaws of the
title="..." attribute is that it is supposed to indicate both. Pronunciation
information should be considered as a completely different issue, which is
often relevant to expressions that are not abbreviations in any sense, like
the pronunciation of "record" in English as a verb vs. as a noun.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

From: John Foliot
Date: Fri, May 28 2010 12:15PM
Subject: Re: abbreviations
← Previous message | Next message →

Geof Collis wrote:

> So whose fault is it if they don't start at the beginning of the
> content? That doesn't make any sense. Perhaps we should have a
> tag that says start here in case you miss any
> accessibility features on this page?

Geof,

I guess then that as a screen-reader user you *NEVER* navigate a page
using headers? That search results *NEVER* return back named anchor URLs?
Now you are just being contrary, and defending a point because you don't
want to be wrong.

I'm done.

JF

From: Jukka K. Korpela
Date: Fri, May 28 2010 12:27PM
Subject: Re: abbreviations
← Previous message | Next message →

Denis Boudreau wrote:

> One option could be that when a screen reader (or any type of
> assistive technology for that matter) parses a page and finds either
> an <acronym title=""> or <abbr title=""> tag, it would store it in
> some kind of buffer memory (possibly flushed out one page reload or
> whatever, but temporarily stocked for reference if need be).

I guess that would be in accordance with some underlying ideas behing W3C
WAI recommendations. This does not necessarily make it a good idea, though.

In practice, the <acronym> and <abbr> tags, with the title attribute, may
have undesirable side effects on graphic browsers.

At the logical level, if it's document-wide information about some
abbreviation, it sounds like a candidate for metadata, rather than
element-specific data. It's illogical to say something about a specific
instance of an expression when you really mean all occurrences of it in a
document.

Resolving the potential ambiguity of, say, the string "IT" (is it an
abbreviation for "information technology", or the pronoun "it" in uppercase,
or something else?) is but a small part of disambiguation, and I would not
give it any particularly important role. Abbreviations can be deceptive, but
human beings can deceive each other and themselves with mere words, too.

Basically, I do not believe in any particularly "high-tech" approach here,
and I count even HTML markup, the poor lonesome data format invented in the
early 1990s, as "high-tech" as compared with normal written or spoken text.
When you speak or when you write, say, e-mail or SMS or a book, you don't
have the questionable luxury of using markup for (purportedly) resolving
ambiguities that may arise in your text. You just have to be careful, and
that's what I recommend to web authoring, too. Try to make your context, or
sometimes explicit explanations, disambiguate when needed.

(Disambiguation of words and abbreviations is just one part of the story.
Quite often, expressions are grammatically ambiguous, i.e. can be parsed in
different ways that result in different semantics. Markup is hardly a
solution.)

--
Yucca, http://www.cs.tut.fi/~jkorpela/

From: Geof Collis
Date: Fri, May 28 2010 12:51PM
Subject: Re: abbreviations
← Previous message | Next message →

How am I wrong when I follow the guidelines which I spelled out to
you the other day.

At 01:15 PM 5/28/2010, you wrote:
>Geof Collis wrote:
>
> > So whose fault is it if they don't start at the beginning of the
> > content? That doesn't make any sense. Perhaps we should have a
> > tag that says start here in case you miss any
> > accessibility features on this page?
>
>Geof,
>
>I guess then that as a screen-reader user you *NEVER* navigate a page
>using headers? That search results *NEVER* return back named anchor URLs?
>Now you are just being contrary, and defending a point because you don't
>want to be wrong.
>
>I'm done.
>
>JF
>
>
>
>

From: Jared Smith
Date: Fri, May 28 2010 1:30PM
Subject: Re: abbreviations
← Previous message | No next message

On Fri, May 28, 2010 at 11:51 AM, Geof Collis < = EMAIL ADDRESS REMOVED = > wrote:
> How am I wrong when I follow the guidelines which I spelled out to
> you the other day.

Yes, you expand acronyms the first time they appear. You've now made
this point in at least 6 different posts. We get it. Flooding 1500
inboxes with a pointless rebuke, an "I told you so", or a "prove it"
is wasted bandwidth and decreases the accessibility and usefulness of
this list to everyone. You seeming can't contribute worthwhile
information to the discussions here without being contrary and making
things personal, so your posts will now be moderated and will only
appear if and when I approve them. Geof, I've warned you several times
before and won't do so again.

We're all on the same team here. None of these approaches is wrong or
inaccessible. And nobody is disagreeing that you shouldn't expand the
acronym fully the first time it is used *if it makes sense to do so*.
The various implementations of the markup generally make little
difference at all to true accessibility. This discussion does
highlight how broken <acronym> and <abbr> are in user agents. Let's
focus on possible solutions, eh?

Jared