RE: Question around WCAG 1.0 (should be: changes in natural language)

Jukka writes:
>Quite possibly. For the word "cordon-bleu", this is probably not fatal;
>anyone who would understand the properly pronounced expression within
>English text presumably recognizes the mispronunciation as well.

Phill replies:
A very good point - it doesn't matter in the case of "cordon-blue", whether
pronounced as a Texan, Englishman, Frenchman, or with a Japanese accent.
And as Jukka points out in the next paragraph, the opposite is also true,
that if lang tags are added when unnecessary it will cause confusion and be
inaccessible because of the change in pronunciation.

>And, in general, though perhaps not in this case, "too good" pronunciation
>can be poor esthetics and poor accessibility. When foreign words occur in
>running text, it can be rather distracting to utter them "right", with
>genuine intonation and phonetic features that may strongly distinguish
them
>from the surrounding flow of text.

Phill continues:
My recollection of the original intent of WCAG 1.0 Guideline 4 [see note 1]
was to only use the lang attributes when confusion and true inaccessibility
would occur if the change in language was not maked-up.  Because only the
change was critical to accessibility, marking the whole document's primary
language was a priority 3 [see note 2], while marking the change in-line
was identified as a priority 1 [see note 3].  But somehow, in my opinion,
through private interpretations and lack of clear rationale, explanations,
and techniques, the Guideline and checkpoints have wandered into an i18n
(internalization) and translation discussion and misses the true
accessibility issue.  The key word in the guideline, that many people fail
to read, is the word "may" as in the last sentence of Guideline 4; "When
... natural language changes are not identified, they may be indecipherable
when machine-spoken or brailled."

Let me try to explain the difference between translation and accessibility.
If a blind individual using a speech synthesizer doesn't understand German,
marking a phrase of text in German in an otherwise Finnish text may not
make the German text any more accessible - he/she would hear the German
text in a Finnish accent following Finnish pronunciation rules - just as
much accessible gibberish to the blind individual as the sighted user
seeing gibberish German text surrounded by otherwise understandable Finnish
text.  But, if the another blind individual does understand German, and
[this is a big and] marking the phrase in German would cause the phrase to
be pronounced differently than the surrounding  text *such that* it
communicated a different meaning then that could be an accessibility issue.
The sighted user would see the understandable German text and the blind
user would hear the understandable German text because it was pronounced
correctly.  In other words, if the phrase were pronounced with the same
rules as the surrounding text and therefore communicated a different
meaning than if the phrase had been pronounced with the proper
pronunciation rules - different than the surrounding text, then
accessibility would be an issue.

The problem [or should I say opportunity?] is that it is rare for true
inaccessibility to occur because of mispronunciation.  I still haven't
found even 1 real example to point to.  Only theories at this point, and
perhaps a contrived example, but I don't even have a contrived example to
share.  The example in the WCAG techniques document [see note 4] is not
helpful.  It says:
"2. Similarly, speech synthesizers that "speak" multiple languages will be
able to generate the text in the appropriate accent with proper
pronunciation. If changes are not marked, the synthesizer will try its best
to speak the words in the primary language it works in. Thus, the French
word for car, "voiture" would be pronounced "voter" by a speech synthesizer
that uses English as its primary language."

Not true!  I tried two different English speech synthesizers and a French
synthesizer, all three sounded out "voiture" differently than "voter" - so
we need a better example.

Anyone got a good contrived example?  Better yet, a real example - real
meaning a live web site with changes in natural language text that if not
pronounced correctly, would mean something different that the sighted user
would see that the synthesizer user wouldn't hear?

Even the success criteria for public draft WCAG 2.0 Checkpoint 1.5 level 2
[see note 5] needs to be changed to include the true accessibility issue.

Note 1: WCAG Guideline 4 Clarify natural language usage

http://www.w3.org/TR/WCAG10/wai-pageauth.html#gl-abbreviated-and-foreign
Note 2: WCAG Checkpoint 4.3 Identify the primary language
      http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-identify-lang
Note 3: WCAG Checkpoint 4.1 Identify changes in natural language
      http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-identify-changes
Note 4: WCAG Techniques:  Identifying changes in language
      http://www.w3.org/TR/WCAG10-HTML-TECHS/#changes-in-lang
Note 5: WCAG 2.0 Checkpoint 1.5 Provide for unambiguous
      http://www.w3.org/TR/WCAG20/#natural-lang

P.S. I'll even take a Braille example, as long as it works when
contraction's are turned off.  In other words, a real live web site with
changes in natural language that when Brailled communicates a different
meaning to the Braille user than what is seen by the sighted user.

Regards,
Phill Jenkins
IBM Research Division - Accessibility Center
http://www.ibm.com/able

Received on Monday, 25 November 2002 16:05:06 UTC