Re: abbreviation exposition and pronunciation

Gregory J. Rosmaita wrote:
> on 3/31/2007, Matthew Raymond, in a post archived at:
> http://lists.w3.org/Archives/Public/public-html/2007JanMar/0792.html
> 
> wrote, citing my example of X H T M L T M, quote:
> 
> This is a bad example. "TM" should have been either "™" or it 
> should have been markups up as an abbreviation. One could also make 
> the argument that the screen reader should have provided some 
> indication that the "TM" was in superscript. 
> unquote
> 
> GJR responds:
> 
> 1. since when have all W3C web documents complied to the 
> letter of the consortium's own law?

   So you're saying that people would actually code the following?

| <acronym title="[...]">XHTMLTM</abbr>

   First of all, the trademark isn't part of the acronym, so it should
go outside:

| <acronym title="[...]">XHTML</abbr>TM

   Not to mention that "TM" is itself an abbreviation, and should be
marked up as such.

   And before we go on, keep in mind that this was originally a
discussion about whether it was harmful to pronounce both acronyms and
initialisms by spelling them out. Considering the fact that "XHTMLTM"
has no vowels, one could hardly pronounce it by sounding out the letters
as if it were a word.

   No argument from me that the user agent should do a better job of
figuring out how to pronounce "XHTML<sub>TM</sub>", but new markup won't
save us because proper HTML 4.01 markup would have probably solved the
problem in the first place.

   Or are you suggesting that there isn't a way to markup up XHTML(TM)
using HTML 4.01 in such a way that it's properly pronounced by screen
readers? If so, is that a deficiency of HTML 4.01, or the screen readers?

> 2. dipping down into the document source to make sense 
> of a document is not only often necessary, but 
> essential, which is why it is a requirement of the 
> User Agent Accessibility Guidelines [note 3]; of 
> course, a knowledge of the pertinent markup language 
> is necessary on the end users part, which sounds to 
> me like an undue burden to place upon the shoulders 
> of a user who is simply attempting to accomplish a 
> task autonomously;

   I'm not following you here. There's no data loss by pronouncing the
letters. If I say "N-A-T-O", you can figure out that it's NATO, even
though it's not commonly pronounced that way. If I say "ping", "ming" or
"sequel", what does that mean? Do I intend to defect, buy a vase or
watch the second movie? In such situations, you're forced to guess what
my pronunciation means from its context.

> Matthew also wrote, in reference to i18n and a11y, quote:
> This is another bad example, because it's an abbreviation and not an 
> acronym. (I actually despise these kinds of abbreviations, by the 
> way.) Furthermore, the expansion of this abbreviation is easily 
> readable by a screen reader.
> unquote
> 
> 3, i don't understand why you don't find the examples 
> valid;  they come from the quote real world wide web 
> unquote and are all the more distressing because they 
> were generated by standards-setting organizations 
> designed to remove barriers to understanding, not 
> erect new ones; how many instances of i18n in w3.org 
> space, not to mention other standards organizations, 
> provide such an expansion?  precious few.

   My main argument was that the initialism-vs-acronym distinction was
unnecessary. I fail to see how abbreviations that qualify as neither
have anything to do with it. If the author really wants a particular
pronunciation, they can use audible CSS.

> 4. you assume too much on the part of the screen-reader: 
> verbosity settings are extremely individualistic, and 
> while in theory, it might be advantageous to have aural 
> indications for every single element on the client-side 
> set on by default, most end users would soon disable a 
> good deal of such aural indicators, in the interest of 
> receiving aural output as quickly, or slowly, as 
> possible, depending upon the user's particular need at 
> a particular time;

   Ah, so what you're saying is that we should add a markup feature only
a tiny handful of authors will use so that we can make sure users of
screen readers aren't annoyed by acronyms being spelled out. The problem
with that idea, other than the unwarranted burden on implementors, is
that most people won't put forth the extra effort to use <abbr> or
<acronym>, let alone add an attribute to distinguish between concepts as
fine grained as initialisms and acronyms.

> moreover, end users will quickly
> grow tired of having THEIR prosady and pronunciation 
> rules manipulated by an author who may never have heard 
> a text-to-speech engine operate, or whose level of 
> granularity the end user finds grating.

   If the user doesn't like a particular pronunciation given through
CSS, they can use their user style sheet to override.

> and if any
> accuse me of making a comfort, not an accessibility 
> claim, my answer is that a lot of energy, time and 
> money has been put into making fonts and displays 
> easier on everyone's eyes;

   Okay...

a) I don't remember every getting ear strain from listening to hard.

b) Font would seem to be equivalent to voice in this case, not time.

c) The listener may actually be saved time and mental effort in some
cases by not having to guess what the pronunciation-as-a-single-word
means, especially if, contrary to the author, they're used to hearing
the word spelled out. Granted, this would not be the case all the time,
and I could understand how this might get annoying after a while.

d) Screen readers can use dictionaries to determine which words to
pronounce, which users can then change. If an acronym/initialism is new
to the user and not in the screen reader dictionary, pronouncing it as
if it were a single word instead of spelling it out would no doubt
confuse the user.

   Now that I think about it, the best solution may be to allow us users
of screen readers to toggle the pronunciation of an acronym/initialism
and have it saved by the user agent for later.

> the same should be the case
> for the aural user, so that one does not always have 
> to hear the word r e a d always pronounced in the 
> present tense, or r e s u m e as resumé (that is, 
> with the accent on the last syllable) or w o u n d 
> pronounced as wound (as in a cut or a slash) even when 
> it should be capable of reading wound (past tense of 
> wind, which is yet another problematic word in english, 
> for it is invariably pronounced wind (the movement of 
> air) and never wind (the present tense of the verb to 
> wind); live is invariably pronounced as live (the 
> present tense of the verb to live) and never live 
> (as in "James Brown: Live at the Apollo Theater"

   While it would be nice to aid screen readers in this regard, you're
never going to get enough authors using it on a regular basis to justify
its inclusion into HTML. That's especially true of content that starts
as text and is posted on the Web after it is authored. There will never
be the resources to have a person read through each text document and
hand-code markup for specific words to benefit users of screen readers.
And before you mention automated detection of such cases, keep in mind
that the same technology could be incorporated into screen readers directly.

> just like everybody else, speech output users are 
> using computers in order to autonomously accomplish 
> tasks, not learn markup languages and dialects, nor 
> write custom scripts, unless assisted in the 
> process by a wizard or property sheet type interface 
> that allows the user to associate whatever styling 
> he or she deems appropriate to author defined 
> classes and other differentiators, which is why 
> support for aural style sheets is essential;

   No argument here. However, markup should be as easy as possible to
write for the blind and the sighted alike.

> there 
> ARE some acronyms meant to be spelt out, such as
> ADA (expansion = Americans With Disabilities Act),
> and those intended to be spoken as a word, such 
> as HAVA (Help Americans Vote Act of 2002);  if you 
> had an ACSS capable aural renderer that supports 
> the speak property, you can hear this for yourself
> at: <http://www.hicom.net/~oedipus/blog/hava2006.html>
> or at <http://www.ubats.org/>, where the acronym 
> UBATS (United Blind Advocates for Talking Signs) 
> is intended to be spoken as a word, and RIAS (Remote 
> Infrared Audible Signage) spelt out, both controlled 
> by the CSS2 @media aural speak property, as illustrated 
> below:
> 
> <style type="text/css">
> @media screen { 
> q.blockquote { margin-left: 10em; margin-right: 10em; padding: 2em; }
> q.blockquote:before ( content: "quote"; display: none; }
> q.blockquote:after ( content: "unquote"; display: none; }
>  }
> @media aural { 
> acronym.spell { speak: spell-out; }
> strong { stress: 90; pitch-range: 90; }
> em { stress: 75; pitch-range: 75; }
> }
> </style>
[Snip!]

   This would seem like the best way to handle the situation to me. The
different means of pronunciation with regard to acronyms and initialisms
seem largely presentational rather than semantic to me. For instance,
how does saying "P-N-G" as opposed to "ping" change the meaning?

   (The only situation I can think of is when you're using an acronym as
a pun, but then if someone doesn't know the acronym, they may not even
realize the pun existed. By spelling it out, it simple takes longer to
get the pun.)

> and, yes, i am an advocate of using semantically 
> sensible classes, so that they can easily be made 
> perceptible to the average end user in the way that 
> is most fit for his or her needs.

   So what's stopping you from creating a microformat? The screen
readers could support it by simply appending some CSS to their user
style sheets. It's a lot less work than adding a new attribute into the
parser, and it really doesn't take any additional effort from the author
once the microformat's finished.

Received on Sunday, 19 August 2007 08:09:59 UTC