Re: Regarding the <abbr> tag

Ben,

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

Yes.  I think it's important that it gets text both gets read outloud 
correctly when on screen readers and displays correctly (via expanded 
form) via braille output devices.  (For your example, the QUT would likely 
make sense when read, but need to be spelled out completely on a braille 
output device, because braille presents acronyms - like QUT - and 
abbreviations differently.)

My primary suggestion was that we should provide the option (but not 
require) the alt attribute to be used as an alternative to what was 
presented which could be read.  While the title would define the term as 
already stated in the spec. 

>The example looks like the @title and @alt attributes repeat
>themselves. 

True, but there are often articles, conjunctions, and prepositions in the 
expanded versions of words that are not included in the short versions. 
These might need to be read by a screen reader (to make it 
comprehendible), but not displayed to an average definition of the 
abbreviation.

>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]

I have to agree here, on the repetitive side.

Then is there any reason why the spec can't be defined as simply <abbr 
title="University of Missouri">Mizzou</abbr> where a title attribute in 
the <abbr> tag automatically defines the abbreviation?  That way any time 
we encounter <abbr>Mizzou<abbr> in the future we have the definition 
already defined (without the need for <dfn>).  Then it might not be over 
burdensome to use the alt tag as I'm suggesting in places where it would 
be read outloud correctly.

I'd like to make it a point to note that even if this group doesn't take 
the above suggestion and drop the <dfn> tag and chooses to keep <abbr> 
usage as defined in the spec, it still makes sense to provide the option 
of using the alt attribute to describe the way text should be spoken.

> We have enough trouble getting authors to fill in this information (or 
any metadata not obviously visible), without needed it twice.

I don't really think that some authors not conforming is a reason to 
prevent others from providing even greater accessibility. 

Look forward to your responses,

Wesley Upchurch





"Ben Boyle" <benjamins.boyle@gmail.com> 
01/25/2008 09:32 PM

To
Wesley.Upchurch@semcoinc.com
cc
"public-html@w3.org WG" <public-html@w3.org>
Subject
Re: Regarding the <abbr> tag






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
twice.

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
Technology">QUT</abbr></dfn>)"

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.

cheers
Ben


[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
>
> THE FOLLOWING COMES FROM
> 
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
>