W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2004

RE: [Techniques] Drft General Technique for GL 3.1 L2 SC1

From: Jason White <jasonw@ariel.its.unimelb.edu.au>
Date: Fri, 31 Dec 2004 19:00:52 +1100
Message-ID: <16853.1844.472576.537902@jdc.local>
To: Web Content Guidelines <w3c-wai-gl@w3.org>

Gregg Vanderheiden writes:
 > 1)  Yes - this whole guideline (and all of the programmatically located
 > provisions) is based on the cascading dictionary concept (or a comprehensive
 > dictionary).    When we put these in we said that they could stay only as
 > long as we were able to solve that.  but if we arent - then we need to
 > remove them -- not change them to programmatically determined.   That has
 > not been discussed at all.

To amplify the latter point, there are good reasons for this: until
and unless software techniques are developed that enable natural
 language to be understood, the best a computer can do is to locate a
definition, or set of definitions, associated with a given word. It
can't reliably ascertain which definition is applicable in context.

A user agent, gateway, proxy server or whatever could consult a
standard set of dictionaries selected by the developer, the user, or a
combination of both. However, if different "assistive technologies"
consult different sets of dictionaries, how is the content developer
supposed to know whether the requirement is met. A tool analogous to 
a spelling checker could in principle identify words in a document
that don't appear in a certain set of dictionaries, but if this set is
different from that on which the user's hypothetical assistive
technology relies, the latter may not be able to locate the required

It might be suggested that the author could nominate dictionaries in
metadata attached to the content, but this wouldn't address the
problem as the author's chosen dictionaries might be of a different
kind than the user requires. Suppose for example the user needs
dictionaries that give translations into another language (for example
a sign language or a symbol set), but the author nominates
dictionaries offering definitions in the primary language of the
content. The latter wouldn't help this particular user at all, yet the
requirement would be satisfied, and a more appropriate dictionary
might nonetheless exist.

For words that aren't found in any of the dictionaries searched by the
hypothetical checking software, what is the author to do? Is providing
a written definition in a glossary sufficient? Exception would have to
be made of course for proper nouns, which are words, but for which
definitions can't be provided (the name refers to the entity named).

 >  RE User agent issue.   There is a user agent component to this in that
 > the user agent would have to do something with the information provided.
 > 3) RE comment regarding pronunciation being in the SC. --  the question
 > wasnt whether pronunciation was in the SC.  You are correct - it was.  but
 > it was only programmatically located - not programmatically determined.
 > that was the problem. 

So, if I have a text to speech algorithm for English that converts
words into phonemes (this is essentially the first step in speech
synthesis) then does this mean that the pronunciation requirement is
redundant for all English content? Sometimes the results of the text
to speech algorithm will be wrong. In those instances, does the
requirement fail to be satisfied? Bear in mind that different text to
speech systems make different errors and have different dictionaries
of exceptions. What happens to the requirement if the content is
written in a language (e.g., an indigenous language) for which there
are no text to speech systems?

Also, what counts as "programmatically locating" the pronunciation of
proper nouns? Does a plausible pronunciation in the natural language
of the content suffice, or must it be possible to find a pronunciation
in the language from which the name originated? In the latter case how
can this be practically achieved?

There are serious ambiguities and problems here that demand further
Received on Friday, 31 December 2004 08:01:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:51 UTC