E-mail List Archives
Thread: WCAG 2 draft and abbreviations
Number of posts in this thread: 20 (In chronological order)
From: Peter Weil
Date: Thu, May 31 2007 8:50AM
Subject: WCAG 2 draft and abbreviations
No previous message | Next message →
I know this topic has been discussed previously on this list, but I
still have some quesitons about it.
My colleagues and I are trying to come up with some best practices
for tagging and expanding abbreviations and acronyms. Most copy we
receive contains a large number of these things -- alas, we have no
control over this.
We all agree that including tags with expansions or explanations is
the best technique currently available (see exception below). But we
are still uncertain whether to tag and expand only the first
occurrence or all occurrences (leaving aside the question of how to
accomplish this efficiently). One colleague proposes tagging the
first instance after each header (h1 through h6).
To complicate matters, often the first occurrence in the copy we
receive already contains the expansion -- this satisfies one of the
'acceptable' techniques:
"provide the full form before providing the abbreviated form"
Example: "The United Nations High Commissioner for Human Rights
(UNHCR) was established in 1950 to provide protection and assistance
to refugees."
In these cases, what should we do with additional occurrences? Tag
and expand, tag with no title attribute, or nothing?
This brings up another question: do the abbreviation and acronym tags
(aside from their semantic correctness) in and of themselves help in
any way with accessibility, or is the expansion (title attribute)
always needed to make them useful?
How are others approaching this problem?
--
Peter Weil, Web Developer
University Communications
University of Wisconsin-Madison
Phone: 608-262-6538
Email: = EMAIL ADDRESS REMOVED =
From: Tim Beadle
Date: Thu, May 31 2007 9:10AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On 31/05/07, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
> Example: "The United Nations High Commissioner for Human Rights
> (UNHCR) was established in 1950 to provide protection and assistance
> to refugees."
This technique is a hangover from the print world, where you can't
obviously have an <abbr> or <acronym> element to expand the
abbreviation.
I'd replace that with <abbr title="The United Nations High Commission
for Human Rights">UNHCR</abbr> for the first occurrence, or the first
occurrence after each H1 if that's your chosen solution.
I started suggesting a clever print style sheet solution involving
attribute selectors (as per
http://www.alistapart.com/articles/goingtoprint) but would have ended
up with the abbreviation and the expansion transposed. It's the end of
a long day here, so I'll leave it to others to take up the baton on
that one; suffice it to say that it *may* be possible to create the
above example in print CSS (in supportive browsers, at least).
Best regards,
Tim
From: Patrick H. Lauke
Date: Thu, May 31 2007 9:30AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Quoting Tim Beadle < = EMAIL ADDRESS REMOVED = >:
> On 31/05/07, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
>> Example: "The United Nations High Commissioner for Human Rights
>> (UNHCR) was established in 1950 to provide protection and assistance
>> to refugees."
>
> This technique is a hangover from the print world, where you can't
> obviously have an <abbr> or <acronym> element to expand the
> abbreviation.
>
> I'd replace that with <abbr title="The United Nations High Commission
> for Human Rights">UNHCR</abbr> for the first occurrence, or the first
> occurrence after each H1 if that's your chosen solution.
I disagree on this. Depending on context, I would write out the full
form + abbreviation in brackets, regardless of whether it's a holdover
from print or not...it makes it immediately usable by all users.
As for the remaining occurrences, again: depends on context, but I'd
try to mark all occurrences up with ABBR.
P
--
Patrick H. Lauke
From: Jared Smith
Date: Thu, May 31 2007 10:20AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On 5/31/07, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
> I know this topic has been discussed previously on this list, but I
> still have some quesitons about it.
I'm glad you asked. I've been pondering these same questions.
> But we
> are still uncertain whether to tag and expand only the first
> occurrence or all occurrences
The WCAG 2.0 techniques document says that if you use abbr, you should
expand all occurrences. I'm not certain I agree. Instead of abbr, you
can also link to definitions (though I definitely disagree that all
instances of the abbreviation should be linked), provide a glossary,
or provide access to a dictionary.
I think all of this is more of a user agent issue - something that the
browser should provide. As recommended in Patrick Lauke's article
(http://www.webstandards.org/learn/articles/current-browsers-uaag10/),
browsers (and most certainly screen readers) should have options to
"Do not expand", "Expand at first occurrence", or "Always expand"
abbreviations.
Also note Patrick's point about the lack of keyboard access to expand
abbreviations.
> To complicate matters, often the first occurrence in the copy we
> receive already contains the expansion -- this satisfies one of the
> 'acceptable' techniques:
>
> "provide the full form before providing the abbreviated form"
This only applies to abbreviations that are not part of common
language. This is, of course, relative to the audience. If you were
posting a message to this list, which would be more accessible, "HTML"
or "HyperText Markup Language (HTML)"? I have issues with a
requirement that all abbreviations be expanded in full form when many
abbreviations shouldn't be.
If there were a way to identify the full form with the abbreviation,
then things would certainly be much easier. Something like:
<expansion for="html">HyperText Markup Language</expansion> (<abbr
id="html">HTML</abbr>)
Then in all successive occurrences, you'd use <abbr
id="html">HTML</abbr>. And in cases where the full form doesn't exist,
simply use title.
> This brings up another question: do the abbreviation and acronym tags
> (aside from their semantic correctness) in and of themselves help in
> any way with accessibility, or is the expansion (title attribute)
> always needed to make them useful?
I'm not aware of any user agent that does anything with an abbr that
is missing the title attribute. I suppose user agents could (should?)
use the non-titled abbr to identify abbreviations that have already
been titled. At the same time, they could do this without the
additional abbr's by simply matching the text - at least in most
cases. Here's an example of where this could be problematic:
<p>I graduated in Instructional Technology (IT). <abbr
title="Instructional Technology">IT</abbr> was an excellent degree,
even though it is usually identified as Information Technology.</p>
The problem here is the word "it" in the second sentence. We can't
assume that user agents would be able to identify this as a word and
not another occurrence of the abbreviation. This then argues for
marking up all successive abbreviations, though I see no need for them
to always include the full title (even though WCAG 2.0 requires it)
when the user agent should properly identify them.
> How are others approaching this problem?
I used to title all instances, but anymore, I'm wondering if titling
just the first instance would suffice. In some ways, because (proper)
browsers style all occurrences of abbr, this can be a bit distracting
and perhaps DECREASE accessibility.
I also want to point out that WCAG 2.0 *finally* clarifies that all
acronyms can also be abbreviations. Thus, you never need to use
acronym at all, though you can where it's appropriate - assuming you
understand where it is appropriate (even the WCAG 2.0 documentation
gets it wrong).
Jared Smith
From: Jukka K. Korpela
Date: Thu, May 31 2007 10:30AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On Thu, 31 May 2007, Peter Weil wrote:
> My colleagues and I are trying to come up with some best practices
> for tagging and expanding abbreviations and acronyms.
It's mostly futile. The important things are
a) to avoid abbreviations
b) to explain them loud and clear in content proper if you use them.
Whether a word is an acronym is irrelevant for most practical purposes.
If you know what "radar" means, you don't need to know how the word was
formed, and the history wouldn't even help you much if you didn't know the
word.
> Most copy we
> receive contains a large number of these things -- alas, we have no
> control over this.
If you _cannot_ control the content, you cannot be held responsible for
its accessibility or other qualities. If you just _don't_, it's a
different matter.
> We all agree that including tags with expansions or explanations is
> the best technique currently available
No we don't. Tagging abbreviations is virtually useless, and partly
harmful (e.g., when it creates an enigmatic "dotted underline"). I thought
this was fairly well known about people who actually aim at accessibility.
There is no evidence on the usefulness of such markup. If a user needs an
explanation for an expression - be it a special symbol, a difficult word,
or an abbreviation - it is certainly a bad idea to hide such information
inside an attribute, instead of making it available and accessible to all.
> Example: "The United Nations High Commissioner for Human Rights
> (UNHCR) was established in 1950 to provide protection and assistance
> to refugees."
That's fine. If you need to refer to the institution later on the same
page, just use the abbreviation you have explained. You don't need any
tags for that.
> This brings up another question: do the abbreviation and acronym tags
> (aside from their semantic correctness) in and of themselves help in
> any way with accessibility, or is the expansion (title attribute)
> always needed to make them useful?
The answer is simple: No.
(I'm intentionally reading the question differently from what you meant.)
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Loretta Guarino Reid
Date: Thu, May 31 2007 10:40AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
I just wanted to clarify that WCAG 2.0 does not say that if you use
abbr, you should expand all occurrences. Using abbr is also a
technique listed when you are just providing the abbreviation
expansion on the first occurrence. See the sufficient techniques
section of "Understanding Success Criterion 3.1.4 (Abbreviations)":
http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/#meaning-located
The working group would appreciate suggestions for how to make this clearer.
Thanks,
Loretta
On 5/31/07, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> The WCAG 2.0 techniques document says that if you use abbr, you should
> expand all occurrences. I'm not certain I agree. Instead of abbr, you
> can also link to definitions (though I definitely disagree that all
> instances of the abbreviation should be linked), provide a glossary,
> or provide access to a dictionary.
From: Jared Smith
Date: Thu, May 31 2007 10:50AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On 5/31/07, Jared Smith wrote:
> Something like:
>
> <expansion for="html">HyperText Markup Language</expansion> (<abbr
> id="html">HTML</abbr>)
>
> Then in all successive occurrences, you'd use <abbr
> id="html">HTML</abbr>.
Scratch that. The value for id must be unique on each page, so this
obviously wouldn't work. But, if I've already expanded the
abbreviation, why shouldn't the user agent know how to further expand
<abbr>HTML</abbr>? This is certainly allowable within the HTML spec,
but is not identified in the User Agent Accessibility Guidelines.
Perhaps it should be?
Jared
From: Jared Smith
Date: Thu, May 31 2007 11:00AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On 5/31/07, Jukka K. Korpela < = EMAIL ADDRESS REMOVED = > wrote:
> It's mostly futile. The important things are
> a) to avoid abbreviations
> b) to explain them loud and clear in content proper if you use them.
Sure, but we all use abbreviations all the time. And it often isn't
useful to explain them fully every time they occur.
> Whether a word is an acronym is irrelevant for most practical purposes.
> If you know what "radar" means, you don't need to know how the word was
> formed, and the history wouldn't even help you much if you didn't know the
> word.
I think this is the key. If the context and audience clearly
understand what an abbreviation means, there certainly is no need to
expand it and most definitely no need to *always* expand it.
> > We all agree that including tags with expansions or explanations is
> > the best technique currently available
>
> No we don't. Tagging abbreviations is virtually useless, and partly
> harmful (e.g., when it creates an enigmatic "dotted underline"). I thought
> this was fairly well known about people who actually aim at accessibility.
>
> There is no evidence on the usefulness of such markup. If a user needs an
> explanation for an expression - be it a special symbol, a difficult word,
> or an abbreviation - it is certainly a bad idea to hide such information
> inside an attribute, instead of making it available and accessible to all.
But for abbreviations, this is not the fault of the markup, it's the
fault of the user agents for not presenting them in a useful and
accessible way.
Jared
From: Jared Smith
Date: Thu, May 31 2007 11:10AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On 5/31/07, Loretta Guarino Reid < = EMAIL ADDRESS REMOVED = > wrote:
> I just wanted to clarify that WCAG 2.0 does not say that if you use
> abbr, you should expand all occurrences.
> See the sufficient techniques
> section of "Understanding Success Criterion 3.1.4 (Abbreviations)":
>http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/#meaning-located
That's the page I was referring to. It indicates that for the first
occurrence of an abbreviation, I can do one of:
1. Provide the abbreviation after the expanded form
2. Link to a definition
3. Use abbr or acronym
For all occurrences of an abbreviation, I can use one of:
1. Link to the definition (I would argue that one link to the
definition would typically be better than 20 links in the same page to
the same definition)
2. Provide a glossary using the link element
3. Provide a function to search an on-line dictionary (many or perhaps
most abbreviations will not be found in a dictionary)
4. Use a dictionary cascade (I have no idea what this is)
5. Use abbr or acronym
Doesn't this mean that if I use abbr alone, I must expand every
occurrence? Or am I misinterpreting something?
Jared
From: Christophe Strobbe
Date: Thu, May 31 2007 11:20AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Hi Jared,
At 18:13 31/05/2007, Jared Smith wrote:
>On 5/31/07, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
>(...)
>
>The WCAG 2.0 techniques document says that if you use abbr, you should
>expand all occurrences. I'm not certain I agree.
Actually, the WCAG 2.0 techniques document does not describe
requirements, but provides techniques to meet certain requirements.
When you start from "Understanding Success Criterion 3.1.4
(Abbreviations)" [1], you'll find two alternative situations:
* Situation A: If the abbreviation has only one meaning within the Web page;
* Situation B: If the abbreviation means different things within the
same Web page.
So if you have a page where you use IT as abbreviated form for
Instrucational Technology, where other instances of IT on the same
page mean Information Technology, you have situation B and you need
to provide an expansion or abbreviation for all occurences of "IT".
[1] http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/#meaning-located
Best regards,
Christophe
--
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group
on Document Architectures
Kasteelpark Arenberg 10 bus 2442 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
From: Peter Weil
Date: Thu, May 31 2007 11:30AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On May 31, 2007, at 11:25 AM, Jukka K. Korpela wrote:
> It's mostly futile. The important things are
> a) to avoid abbreviations
> b) to explain them loud and clear in content proper if you use them.
> If you _cannot_ control the content, you cannot be held responsible
> for
> its accessibility or other qualities. If you just _don't_, it's a
> different matter.
I can feel some of that futility, but I do want to explore what, if
anything, web developers can do. I'm not so much concerned with being
held responsible as I am with coding the content in a way that might
help readers comprehend it more easily. Our writers are essentially
print writers, and it's up to us (the web team) to translate the copy
into the most effective (and accessible) html we can.
>
>> We all agree that including tags with expansions or explanations is
>> the best technique currently available
>
> No we don't. Tagging abbreviations is virtually useless, and partly
> harmful (e.g., when it creates an enigmatic "dotted underline"). I
> thought
> this was fairly well known about people who actually aim at
> accessibility.
>
By "we" I meant my colleagues and I. Honestly, I have not heard or
seen much about tagging abbreviations as 'harmful'.
> There is no evidence on the usefulness of such markup. If a user
> needs an
> explanation for an expression - be it a special symbol, a difficult
> word,
> or an abbreviation - it is certainly a bad idea to hide such
> information
> inside an attribute, instead of making it available and accessible
> to all.
I don't know whether this is true or not. I thought that adding the
title attribute to these tags is supposed to make the information
available, not hide it.
--
Peter Weil, Web Developer
University Communications
University of Wisconsin-Madison
Phone: 608-262-6538
Email: = EMAIL ADDRESS REMOVED =
From: Christophe Strobbe
Date: Thu, May 31 2007 11:40AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Hi Jared,
At 18:13 31/05/2007, Jared Smith wrote:
>(...)
>I also want to point out that WCAG 2.0 *finally* clarifies that all
>acronyms can also be abbreviations. Thus, you never need to use
>acronym at all, though you can where it's appropriate - assuming you
>understand where it is appropriate (even the WCAG 2.0 documentation
>gets it wrong).
The point is that there are basically two definitions of "abbreviation":
(a) shortened form of a word (a strict definition)
(b) abbreviated form (which encompasses (a), acronyms, initialisms, ...)
With regard to acronyms, many people have stated that if an
abbreviated from composed of initial letters cannot be pronounced as
a word, it should not be called an acronym. Is that what you are
referring to when you say that "the WCAG 2.0 documentation
gets it wrong"? I have checked over 20 dictionaries and linguistic
references in 5 different languages (admittedly a small sample [1])
and found no consistency with regard to the pronunciation of
acronyms. That's why WCAG doesn't require that acronyms can be
pronounced as a word.
Best regards,
Christophe
[1] part of the list is at
<http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JulSep/att-0851/AbbreviationAcronym.html>;.
--
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group
on Document Architectures
Kasteelpark Arenberg 10 bus 2442 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
From: Christophe Strobbe
Date: Thu, May 31 2007 11:50AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Hi Jared,
At 18:38 31/05/2007, Jared Smith wrote:
>On 5/31/07, Jared Smith wrote:
>
> > Something like:
> >
> > <expansion for="html">HyperText Markup Language</expansion> (<abbr
> > id="html">HTML</abbr>)
> >
> > Then in all successive occurrences, you'd use <abbr
> > id="html">HTML</abbr>.
>
>Scratch that. The value for id must be unique on each page, so this
>obviously wouldn't work.
Right, but you could reverse the direction of the reference:
<expansion id="html">HyperText Markup Language</expansion> (<abbr
definedby="html">HTML</abbr>)
Then in all successive occurrences, you'd use <abbr
definedby="html">HTML</abbr>.
Best regards,
Christophe
--
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group
on Document Architectures
Kasteelpark Arenberg 10 bus 2442 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
From: Loretta Guarino Reid
Date: Thu, May 31 2007 12:00PM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Hi, Jared,
On 5/31/07, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On 5/31/07, Loretta Guarino Reid < = EMAIL ADDRESS REMOVED = > wrote:
> > I just wanted to clarify that WCAG 2.0 does not say that if you use
> > abbr, you should expand all occurrences.
>
> > See the sufficient techniques
> > section of "Understanding Success Criterion 3.1.4 (Abbreviations)":
> >http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/#meaning-located
>
> That's the page I was referring to. It indicates that for the first
> occurrence of an abbreviation, I can do one of:
> 1. Provide the abbreviation after the expanded form
> 2. Link to a definition
> 3. Use abbr or acronym
>
> For all occurrences of an abbreviation, I can use one of:
> 1. Link to the definition (I would argue that one link to the
> definition would typically be better than 20 links in the same page to
> the same definition)
> 2. Provide a glossary using the link element
> 3. Provide a function to search an on-line dictionary (many or perhaps
> most abbreviations will not be found in a dictionary)
> 4. Use a dictionary cascade (I have no idea what this is)
> 5. Use abbr or acronym
>
> Doesn't this mean that if I use abbr alone, I must expand every
> occurrence? Or am I misinterpreting something?
If the abbrevation only has one meaning in the Web page (Situation A),
then you can satisfy WCAG 2.0 either by just providing the
abbreviation expansion for the first occurrence, or providing it for
all occurrences. (Providing it for the first occurrence and some other
occurrences, as suggested in this thread, would also be ok.)
Regards,
Loretta
From: Jukka K. Korpela
Date: Thu, May 31 2007 12:10PM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On Thu, 31 May 2007, Christophe Strobbe wrote:
> I have checked over 20 dictionaries and linguistic
> references in 5 different languages (admittedly a small sample [1])
> and found no consistency with regard to the pronunciation of
> acronyms. That's why WCAG doesn't require that acronyms can be
> pronounced as a word.
If the word "acronym" has no consistent meaning, it should not be used -
especially in a normative document. Introducing it as separately defined
technical term would be possible in principle, but WCAG cannot change
HTML, where "acronym" is a hopelessly messed-up word.
"Acronym" was Microsoft word for abbreviation. That's why IE _still_ does
not recognize <abbr> (except in the sense that IE 7, finally, includes it
into the parsed document tree). It's time to stop trying to make sense of
this nonsense. Those tags are useless, or worse. Concentrate on making
textual content of web pages understandable to all people, using other
means than such markup.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Alastair Campbell
Date: Tue, Jun 05 2007 9:50AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
Jukka K. Korpela wrote:
> It's time to stop trying to make sense of
> this nonsense.
I'm afraid I glazed over when trying to follow the HTML5 / WAI arguments
on abbreviations, so please forgive my intentional naivety.
Given that the user requirement is for adding explanatory text, could we
not just have an element for both acronym & abbreviations (and more?)
which takes a title attribute?
<abbr> seems to be the more generic, and given recent support, now seems
to be a good time to put down in WCAG2 techniques (and possibly HTML5):
Just use <abbr title="explanation">text</abbr>
Is there need for more than one element?
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html
From: Jukka K. Korpela
Date: Tue, Jun 05 2007 11:00AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On Tue, 5 Jun 2007, Alastair Campbell wrote:
> Given that the user requirement is for adding explanatory text,
Which user requirement? People may need explanations for various things -
like uncommon words, odd symbols, strange formulations, difficult points,
and even abbreviations.
> could we
> not just have an element for both acronym & abbreviations (and more?)
> which takes a title attribute?
Where do the "element" and "attribute" come in the user requirements.
Users want explanations, not markup. If markup helps them in finding and
using the explanations, fine. But if you can, for example, see a strange
expression explained when you first encounter, what would you need some
markup for? More importantly, if you _don't_ see an explanation, does it
help that there is some invisible markup that might make some browsers
present you some information in some circumstances?
> <abbr> seems to be the more generic, and given recent support, now seems
> to be a good time to put down in WCAG2 techniques (and possibly HTML5):
> Just use <abbr title="explanation">text</abbr>
>
> Is there need for more than one element?
Is there need for an element? What is the tangible benefit? We have
already seen the tangible drawbacks: authors throw in some markup and
attributes and think that they have actually explained an abbreviation.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Keith Parks
Date: Tue, Jun 05 2007 11:30AM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On Jun 5, 2007, at 9:50 AM, Jukka K. Korpela wrote:
> On Tue, 5 Jun 2007, Alastair Campbell wrote:
>
>> Given that the user requirement is for adding explanatory text,
>
> Which user requirement? People may need explanations for various
> things -
> like uncommon words, odd symbols, strange formulations, difficult
> points,
> and even abbreviations.
But isn't it less a question of the *user* needing additional markup,
but rather the *machines*, specifically speech synthesizers, needing
additional information?
For instance, a reader ought to be able to tell, through experience
and context, that the "US" in US Olympic Team is an abbreviation, to
be pronounced "you ess". But how does the speech synthesizer know
this? Do they have that level of logic and interpretation built into
them?
It would seem like a structural tag saying that "These letters are
not an ordinary word, but are to be pronounced as initials" would be
helpful, outside of any explanation of what they stand for, which I
agree ought to be part of regular flow of text, as is typical when
following proper writing style.
-Keith
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.keithparks.com
http://www.sa.sdsu.edu/communications
----------------------------------------------------------
A riddle wrapped in a mystery inside an enigma, served with a side of
slaw.
From: Jukka K. Korpela
Date: Tue, Jun 05 2007 12:10PM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | Next message →
On Tue, 5 Jun 2007, Keith Parks wrote:
> But isn't it less a question of the *user* needing additional markup,
> but rather the *machines*, specifically speech synthesizers, needing
> additional information?
Both points are basically fictional.
> For instance, a reader ought to be able to tell, through experience
> and context, that the "US" in US Olympic Team is an abbreviation, to
> be pronounced "you ess". But how does the speech synthesizer know
> this? Do they have that level of logic and interpretation built into
> them?
Maybe they have. Maybe they just have a vocabulary that says that "US" in
capital letters shall be read letter by letter, rather than as the word
"us". Maybe it's a program option.
But how would abbr markup address the issue? Being an abbreviation does
not mean any particular pronunciation. Some abbreviations are read as if
they were words, some are read letter by letter (sometimes by the letter
names of a foreign language), and some are expanded. This may also depend
on style. Besides, if pronunciation were really the issue, why would you
want to indicate specifically the pronunciations of abbreviations? Special
symbols, foreign words, and even common words may have special
pronunciation issues as well.
> It would seem like a structural tag saying that "These letters are
> not an ordinary word, but are to be pronounced as initials" would be
> helpful,
Is it structural? The abbreviation "USA" _means_ pretty much the same, no
matter whether I read it as a word, or pronounce its letters by their
values in my native language, or in English, or some other language, or
spell it out as "United States of America".
If <abbr> were understood in the meaning you suggest, then quite a lot of
<abbr> tags around have the wrong meaning.
If you want markup that indicates pronunciation, it should be independent
of indicating something as an abbreviation. The main problem with such
markup is that few people would use it and few programs would support it,
in a vicious circle.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: Hoffman, Allen
Date: Tue, Jun 05 2007 12:30PM
Subject: Re: WCAG 2 draft and abbreviations
← Previous message | No next message
>Maybe they have. Maybe they just have a vocabulary that says that "US"
in capital >>letters shall be read letter by letter, rather than as the
word "us". Maybe it's a
>program option.
It is both. synthetic speech has such options, exception lists are
vast, and there are lots of rules applied. They don't all get it
perfect.
Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303