abbreviation exposition and pronunciation

on 3/31/2007, Matthew Raymond, in a post archived at:

in response to my post, archived at:

wrote, citing my example of X H T M L T M:

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. 

GJR responds:

1. since when have all W3C web documents complied to the 
letter of the consortium's own law?

at the time, i was using Lynx [note 1] as my primary means 
of accessing the web, and i continue to use Lynx [note 2] 
to access the wikimedia family of resources and while i 
hand-encode document source;

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;

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.

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 
space, not to mention other standards organizations, 
provide such an expansion?  precious few.

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; 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.  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; 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"

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; 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: <>
or at <>, 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 

<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; }

<!-- ... -->

<Q class="blockquote">
The <acronym title="HyperText Markup Language" 
class="spell">HTML</acronym> element BLOCKQUOTE 
should be deprecated, as it is not a semantic 
distinguisher, but a presentational convention 
carried over from print conventions.  A quote is 
a quote is a quote, no matter <em>how</em> styled, 
no matter <em>how</em> long.  Why should a quote 
of over an arbitrary number of lines have its own 
element, when a <strong>single</strong> quote 
element suffices?  By classing a quote as a 
blockquote, it enables the author to style the 
quote as he or she decides most fit, and the end 
user to restyle it, should that be necessary.

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.


Note 1: <>
Note 2: <>
Note 3: <>

Gregory J. Rosmaita: or

skype: oedipusnj


Received on Thursday, 3 May 2007 15:02:44 UTC