Re: ABBR and ACRONYM

to follow up on what Pawson, David said:
> 
> 	Its when we don't tag them up that we are into guessing games.
> 	Right tagging will support right treatment [which is where this
> 	thread started if I remember rightly].
> 
> 	regards, DaveP.

If we want access to the information, we need to be open to
solutions based on informed interpretation of words as well as
scrupulous tagging.

Syntax-based guessing that a word is an acronym or initialism is
a piece of cake.  Is the word all uppercase?  {if yes: Is the
context all uppercase? {if no: Bingo!}}

So client software functions compete with server markup to fill
this need.  We shouldn't prune off alternative opportunities for
relief until the problem has actually gone away.

In the WAI-UI group I would think that the speech-access
community should be pushing the browser people as to how they use
and share dictionaries.

The access adapter is not the only piece of software that may
have access to a dictionary.  In fact, if we want authors to ever
employ the distinction between "acronyms" and "initialisms" we
had better infiltrate the spell-check dictionaries of popular
word processors and not stop at screen-readers.  If the system
interpreting the HTML has a resident dictionary it can do a very
good job of recognizing acronyms and commonly used initialisms
and attaching phonetic markup for the ones where the normal
pronunciation practices don't work.  The screen reader doesn't
need to know whether the author or the browser pasted the
phonetics on the item.  Or it may know it can check the installed
word-processor's dictionary that the system has told it is
available on the system side of the accessibility API.

As Dave and Jason and Max have all pointed out, there are more
customers for pronunciation information that just screen readers.

Participate in WAI-UI and ask the holders of dictionaries how
they propose to share them.

Al Gilman

Received on Monday, 2 February 1998 12:34:23 UTC