- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Thu, 3 May 2007 10:45:42 -0400
- To: public-html@w3.org, wai-xtech@w3.org
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? 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. 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. 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: <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> <!-- ... --> <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. </Q> 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. gregory. Note 1: <http://lynx.browser.org/> Note 2: <http://en.wikipedia.org/wiki/Lynx_%28web_browser%29> Note 3: <http://www.w3.org/TR/UAAG/> ---------------------------------------------------------------- Gregory J. Rosmaita: oedipus@hicom.net or gregory@ubats.org skype: oedipusnj sites: http://www.hicom.net/~oedipus/ http://ubats.org http://my.opera.com/oedipus/ ----------------------------------------------------------------
Received on Thursday, 3 May 2007 18:08:09 UTC