W3C home > Mailing lists > Public > public-html@w3.org > January 2008

Re: Regarding the <abbr> tag

From: Ben Boyle <benjamins.boyle@gmail.com>
Date: Sat, 26 Jan 2008 11:54:12 +1000
Message-ID: <5f37426b0801251754k33f1e97bv433ac1dfcb322791@mail.gmail.com>
To: Wesley.Upchurch@semcoinc.com
Cc: "public-html@w3.org WG" <public-html@w3.org>

Hi Wesley,

Not sure I've understood your suggestion correctly, or the need behind
it. The example looks like the @title and @alt attributes repeat
themselves. We have enough trouble getting authors to fill in this
information (or any metadata not obviously visible), without needed it

Are you trying to have a place for both:
a. this is the expanded form
b. this is how it should be spoken

I'm not sure it's needed. If it is needed, would it be limited to abbreviations?

I've been to couple of screen reader demos and, as an example, there
was one where they looked at some pages on a website for QUT. This was
pronounced "kwut" by the screen reader. Now, on first encountering
this, most people are not going to know what it means. This issue is
relevant to everyone... regardless of pronunciation, will you know
what "QUT" is?

The use of "kwut" was quite suitable for this screen reader user.
Through personal experience, they knew what it stood for (and were
able to explain it to the audience at the demo). Being a short (one
syllable) word, it is very efficiently spoken, very efficiently
listened to, very efficiently consumed. This is important for a
quality screen reading experience. Having the term spelled out
constantly (Q-U-T) just slows everything down a bit more. Having it
fully expanded and read in full, that is much slower. That may be
wanted when the term is unfamiliar, but beyond that ...

Here's how I imagine it works.
Sceen reader: "Based in Brisbane, kwut is a top Australian university
with global connections ..."
User thinks: hang on, what's "kwut"?
User commands screen reader to go back to that term so they can
investigate it... might get it spelled out (Q-U-T) or the @title read
(if there is one provided in the HTML). I truly don't see how this is
different to what we would do if we encountered "QUT" and didn't
understand what it meant... we'd dig a bit to find a meaning and then
get on with our lives. Maybe it doesn't even matter what it stands
for... from the sentence we know it is a top Australian university
with global connections, right? :)

Truly, I think we authors bother ourselves too much with these
questions. The best advice is clearly stated in WCAG: "Avoid slang,
jargon, and specialized meanings of familiar words, unless defined
within your document." [1][2]

The page I took the QUT sentence from [3] actually uses the title
element to define themselves, and from thereon refer to themselves
almost exclusively as "kwut". No abbr, @title or @alt required.

There are other examples where the abbreviations (or other jargon)
will not be so obvious, where things are more out of context. For
example, if I were blogging about this and wanted to define what "QUT"
was. Typically I'd just do this with text: "Queensland University of
Technology (QUT)"

HTML5 has specified some neat behaviour for the dfn element [4] that
allows me to provide better hooks, to support those situations where
people want to know what QUT is, like so: "Queensland University of
Technology (<dfn><abbr title="Queensland University of

I can then use <abbr>QUT</abbr> throughout my document, and HTML5 UAs
should refer back to that definition ... as required.

Personally I find the dfn/abbr@title to be repetitive too (as I want
to include the full expansion in plain text, not merely within
@title), but we've already been over that ground ... [5]

Possibly this post has travelled away from your original questions. I
hope not, but do clarify if so. I think the optional attribute to
specify types of abbreviations could be pursued as a class (ala
microformats), or with RDFa. With this post I hoped to explain why I
do not see any need to make such a distinction; even the need to
"define jargon" is best practice advice (from WCAG) and not needed in
the HTML spec so long as the mechanisms (dfn, abbr) are in place.


[1] http://www.w3.org/TR/WCAG10-CORE-TECHS/#writing-style
[2] http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-GATEWAY-20030723.html#TECH-writing-style
[3] http://www.qut.edu.au/
[4] http://www.w3.org/TR/html5/#the-dfn
[5] http://lists.w3.org/Archives/Public/public-html/2007Jul/1287.html

On Jan 25, 2008 12:17 AM,  <Wesley.Upchurch@semcoinc.com> wrote:
> After responding to Susan in the Public HTML Comments,  I had more time to
> think about the issue she brought up.  I'm offering the following suggestion
> and thoughts to help solve the problem.
> Wouldn't it make more sense if the <abbr> tag used the alt attribute in
> addition to the title attribute?  I'm suggesting this because I think that
> the use of the title attribute should provide a tooltip to the user to
> define the acronym, but the alt tag should provide an alternative to the
> abbreviation or acronym (sometimes articles like a and then would be
> necessary to make the sentence make sense to viewers requiring accessible
> browsers).  I thought this would provide better compatibility with screen
> readers and braille browsers which may need to display the
> acronym/abbreviation in full for reasons detailed below.
> Otherwise, I might make sense to add a type attribute to the <abbr> tag as
> Susan suggested.  Even better might be to create a <acron> tag (or something
> similar) to use for acronyms and keep the <abbr> tag for abbreviations.  Of
> course both of the suggestions in this paragraph are not really necessary if
> the <abbr> tag provides both a title and an alt tag.
> That way my first example from below would read as follows:
> <abbr title="National Aeronautics and Space Administration" alt="The
> National Aeronautics and Space Administration">NASA</abbr> will be launching
> a rocket in July.
> Thanks for your thoughts and considerations in advance.
> Wesley Upchurch
> http://lists.w3.org/Archives/Public/public-html-comments/2008Jan/subject.html
> From: <Wesley.Upchurch@semcoinc.com>
>  Date: Wed, 23 Jan 2008 12:18:36 -0600
>  To: public-html-comments@w3.org
>  Message-ID:
> <OFF3D8CA23.C81D7B28-ON862573D9.00622043-862573D9.0064C122@semcoinc.com>
> According to the latest working draft: "The abbr element represents an
>  abbreviation or acronym. The title attribute should be used to provide an
>  expansion of the abbreviation. If present, the attribute must only contain
>  an expansion of the abbreviation."
>  It is my opinion (as opposed to that of the Working Group as a whole),
>  that the title attribute serves the purpose of accessibility regardless of
>  whether the text in the <abbr> tag is an abbreviation or an acronym, by
>  defining the full meaning of it (which could be displayed on braille
>  output devices, instead of the standard text, similar to how ALT tags work
>  with images).
>  -----
>  To demonstrate this point I'm giving you an example of both an
>  abbreviation and an acronym:
>  <abbr title="The National Aeronautics and Space Administration
> ">NASA</abbr> will be launching a rocket in July.
>  and
>  We will meet on <abbr title="August">Aug</abbr> 1, 2008.
>  Notice that both of these would make sense to someone utilizing a screen
>  reader or braille browser.
>  ------
>  In addition to the title tag making it unnecessary for to differentiate
>  between abbreviations or acronyms, it is my also personal opinion that
>  such a attribute wasn't included in HTML 5 because HTML is designed to
>  describe the semantics of a document regardless of the language the
>  document is written in.  The fact that contracted English braille has
>  different rules for translating abbreviations and acronyms is specific to
>  braille in the English language is probably another reason for not
>  including such an attribute.
>  Hope this helps.
>  Wesley Upchurch
> From: Susan Jolly <easjolly@ix.netcom.com>
>  Date: Tue, 22 Jan 2008 13:45:49 -0700
>  To: <public-html-comments@w3.org>
>  Message-ID: <E1JHPys-0002Ei-8E@elasmtp-junco.atl.sa.earthlink.net>
>  Contracted English braille has different rules for translating the items it
>  calls abbreviations and the items it calls acronyms. I don't want to start
>  yet another discussion of the differences between abbreviations, acronyms,
>  initialisms and so forth.  However, at the very least the <abbr> element
>  should have an optional attribute for identifying the type of abbreviation.
>  Having to parse the value of the title attribute to make this determination
>  would be undesirable at best and might not always produce the desired
>  result.
>  Sincerely,
>  Susan Jolly
Received on Saturday, 26 January 2008 01:54:23 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:25 UTC