[Techniques] Drft General Technique for GL 3.1 L2 SC1

The proposal below is part of the first draft of material for the
General Techniques for Guideline 3.1, the guideline that contains some
key requirements about language use. It's my hope that this material can
be included in the next internal working draft, and that it will
eventually make its way-- duly modified and corrected-- into the next
public working draft.
 
Guideline 3.1 L2 SC1: requirs: 
<current>
The meanings and pronunciations of all words in the content can be
programmatically located. 
</current>
 
It would be very helpful if people with knowledge of writing systems for
languages that do not use Roman or romanized alphabets would review and
make suggestions for corrections, additions, deletions, etc.

 
<proposed>
 
Short-name for this technique:
Pronunciation for users

Task
Information about the pronunciation of a run of text is explicitly
associated with the 
run of text where meaning depends on pronunciation.
 
Description
There are many languages in which a run of text may mean different
things 
depending on how the text is pronounced. This is common in East Asian 
languages as well as Hebrew, Arabic,  and other languages; it also
occurs in 
English and other Western European languages.  Users with disabilities
that make 
it difficult to use contextual cues as a guide to pronunciation and
meaning benefit 
when information about how to pronounce potentially ambiguous text is
available.
 
Techniques for associating content with information about pronunciation
vary 
depending upon the type and language of the content. For example, Ruby 
Annotation is appropriate for indicating pronunciation in some
languages, such as 
Japanese, Chinese, and Korean.  However, Ruby may be unnecessary in 
languages where Unicode fonts can include diacritical marks that 
convey pronunciation.
 
Ruby Annotation allows the author to annotate a "base text," providing
both a 
guide to pronunciation and, in some cases, a definition as well.  Ruby
is commonly 
used for text in Japanese and other East Asian languages.  Ruby
Annotation is 
defined as a module for XHTML 1.1.
 
There are two types of Ruby markup: simple and complex. Simple Ruby
markup 
applies to a run of text such as a complete word or phrase. This is
known as the 
"base" text.  The Ruby annotation that indicates how to pronounce the
term is 
usually displayed immediately before the base text, and is shown in a
smaller font. 
(The term "Ruby" is derived from a small font used for this purpose in
printed 
texts.)  Simple Ruby markup also provides a "fallback" option for user
agents that 
do not support Ruby markup.
 
Complex Ruby markup makes it possible to associate a single base text
with more 
than one annotation.  In such cases, the first annotation would
typically 
indicate pronunciation and the second would provide the meaning.
Complex Ruby 
markup also makes it possible to divide the baste text into smaller
units, each of 
which may be associated with a separate Ruby annotation.  Complex Ruby 
markup does not support the fallback option.
 
Note: The primary reason for indicating pronunciation through Ruby or
any other 
means is to make the content accessible to people with disabilities who
can read 
and understand the language of the content if information about
pronunciation is 
provided. Creating explicit association between the content and the
pronunciation 
information ensures that pronunciation information remains available if
the 
presentation format is adapted to meet the user's needs. 
 
Editor's note: Complex Ruby markup may be sufficient to satisfy this
success 
criterion when pronunciation and meaning are provided in separate
annotations of 
the same base text
 
Editor's Note: As an additional benefit, it has also been suggested that
Ruby 
Annotation might be used to make content accessible to people who use
symbolic 
languages together with or as an alternative to conventional text.  For
example, a 
symmbol image could be used as a Ruby annotation above a base text.
Such 
practices might benefit people whose speech or reading are impaired as
the result 
of stroke or other injury to the brain, or from other causes. (See A.
Judson, M. 
Lundalv, B. Farre, and L. Nordberg, <a 
href="http://dewey.computing.dundee.ac.uk/ccf/cop/#d0e876"
<http://dewey.computing.dundee.ac.uk/ccf/cop/#d0e876> >Concept Coding 
Framework</a>) However, the Ruby 1.0 Specification does not support use
of 
images, so implementation of this suggestion would depend upon a change
in the 
Ruby specification.
Resources
<a href="http://www.w3.org/TR/ruby/" <http://www.w3.org/TR/ruby/> >Ruby
Annotation</a>
<a href="http://ncam.wgbh.org/salt/guidelines/sec11.html"
<http://ncam.wgbh.org/salt/guidelines/sec11.html> >IMS Guidelines for 
 
Topic-Specific Accessibility</a>
HTML Techniques
<a 
 
href="http://www.w3.org/TR/WCAG20-HTML-TECHS/#lang-att_change"
<http://www.w3.org/TR/WCAG20-HTML-TECHS/#lang-att_change> >Identifyin
 
g language changes</a>
CSS Techniques
<a href="http://www.w3.org/TR/css3-ruby"
<http://www.w3.org/TR/css3-ruby> >CSS 3 Ruby</a>
</proposed>
 

"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web  <http://www.ital.utexas.edu/>
http://www.utexas.edu/research/accessibility