Re: Brainstorming - abbreviations

More importantly, just as you dont want visual presentation to
overly influence or materialize in the markup, I believe it is
also wrong for things like pronunciations to affect how something
is marked up; for that reason I've always considered the abbr vs
acronym distinction to be mostly bogus.

For the visual case, the right answer to the question "how should
I encode how this should be presented" is usually "use CSS" --
for the spoken case, the equivalent is Aural CSS. 

Attempting to bake in pronunciation rules, either by asking the
Web author to type in some kind of guesed-at pronunciation in the
markup, or by encoding the abbreviation with a special tag  and
then baking into screenreaders the pronunciation rules  are both
approaches that feel extremely flaky.

Laurens Holst writes:
 > Colin Lieberman schreef:
 > >> I object to a "pronounce" attribute, on the grounds that I say "SQL" as
 > >> initials. :)  To make the point more general -- whilst such an attribute
 > >> might be useful for screenreaders to some extent, different people say
 > >> things different ways.  If one website uses "sequel" and one uses "ess
 > >> cue ell", I think that would be confusing.
 > >>
 > >
 > > Fair enough, but if we were chatting face to face, and I asked you 
 > > what your favorite 'sequel' server was, would you really be confused? 
 > > I think most people are quite clever enough to handle those sorts of 
 > > common variations. But, maybe  SQL was a bad example. An 
 > > author-specified pronunciation would be useful for common 
 > > abbreviations like Mr., Sr., etc. (both as an example, and literally 
 > > :) which currently grate on the ears when read by screen readers. 
 > I think you can expect screenreaders to have a big list of abbreviations 
 > and their pronunciation. And if an abbreviation is not on their list, it 
 > can make an educated guess, or the user can add an entry to the list if 
 > it really bothers them. And otherwise, even if the pronunciation is 
 > wrong, it¨s still understandable˘so what, I also say °ess-cue-ell¨ 
 > instead of °sequel¨ (I¨m Dutch, sorry for that ;p) and people get what I 
 > mean :).
 > The only thing that would cover all abbreviations completely is to add 
 > some attribute with a indicating how it¨s pronounced using phonetic 
 > alphabet. Because any other scheme simply doesn¨t cover it. Do you 
 > really think a screenreader can correctly pronounce SQL as °sequel¨ just 
 > because it¨s got an <acronym> tag around it? It will more likely become 
 > something like °escuel¨ or °sekkel¨ or whatever. Similarly, SPARQL ˇ 
 > °sparkle¨, SCSI ˇ °scuzzy¨, XUL ˇ °zool¨. Not to mention that many 
 > abbreviations have no single way of pronunciation. Take Linux as an 
 > example (although not really an abbreviation, I suppose), which can be 
 > pronounced like °leenooks¨, °linnuks¨, °lynuks¨, etc. [1]
 > In practice, you cannot expect people to add that level of detail for 
 > abbreviations. Any other indication of pronunciation is only 
 > complicating things and not providing anything close to complete 
 > coverage. Therefore, <acronym> should go, and <abbr> should stay simple 
 > and only have a title attribute for the purpose of indicating its actual 
 > meaning, which is after all what¨s really important, in case people do 
 > not know the abbreviation.
 > Let the speech software handle the problem. They are very likely already 
 > doing it anyway, judging by the amount of websites that actually uses 
 > <abbr> or <acronym> (read: very few do).
 > ~Grauw
 > [1]
 > -- 
 > Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 > Laurens Holst, student, university of Utrecht, the Netherlands.
 > Website: Backbase employee;
 > begin:vcard
 > fn:Laurens Holst
 > n:Holst;Laurens
 > email;
 > tel;cell:(+31) 020-7507305
 > version:2.1
 > end:vcard

Best Regards,

Title:  Research Scientist      
Google: tv+raman 

Received on Thursday, 15 March 2007 21:20:19 UTC