WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: abbreviations

for

From: Geof Collis
Date: May 26, 2010 3:42PM

Hi John

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

cheers

Geof

At 03:58 PM 5/26/2010, you wrote:
> <EMAIL 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
>
>
>
>
>