W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2001

Re: Including content modes in 4.1

From: Al Gilman <asgilman@iamdigex.net>
Date: Wed, 18 Jul 2001 21:54:42 -0400
Message-Id: <200107190142.VAA2687391@smtp2.mail.iamworld.net>
To: w3c-wai-gl@w3.org
At 08:49 PM 2001-07-18 , Wendy A Chisholm wrote:
>Victor,
>
>As I understand the specific issue that Lisa raises, there are two types of 
>Hebrew, one with vowel marks and one without.  If someone is presented 
>Hebrew without vowel marks, they might not be able to read it (either 
>through a processing disability of their own or their user 
>agent's).  Therefore, we want to suggest using Hebrew with vowel marks.
>
>One way to generalize this is to say
>"use fonts, languages, API's, and protocols..."
>or
>"use character encodings, languages, API's, and protocols..."
>or
>"use character sets, languages, API's, and protocols..."
>

AG::

Yes, "content mode" is too broad.  But all the alternatives you raise have
good
meanings that aren't what we are after.

I am afraid that we may have to fall back on the general term 'usage' here.
 In
other words, say "Follow usage that is compatible with assitive tranforms.
For
example spell Arabic and Hebrew out with explicit vowel marks, to ensure
Text-to-Speech compatibility."  

The use of the term 'usage' gets the reader thinking in terms of how you use
the features of the natural language.  That is pretty much what we are talking
about when the question is spelling.  What characters you use to indicate a
word is a natural language concern, above the level of character encodings,
and
not implied by just the selection of language in cases such as this where the
langauge is subject to the variation in spelling usage."

It is easy to make clear in the form of a heuristic slogan, "Write it down;
spell it out."  But that catches the direction, but not the extent of the
imperative.

Al

>This is based on my understanding of these documents:
><http://www.w3.org/International/O-charset.html>http://www.w3.org/Internat
ional/O-charset.html
><http://www.w3.org/International/O-fonts.html>http://www.w3.org/Internatio
nal/O-fonts.html
><http://www.w3.org/International/O-MissCharGlyph>http://www.w3.org/Interna
tional/O-MissCharGlyph
><http://www.w3.org/International/O-HTML-tags.html>http://www.w3.org/Intern
ational/O-HTML-tags.html
>
>"content mode" seems too general a term and one that I do not see used in 
>the Internationalization documentation on the W3C site. 
><http://www.w3.org/International/>http://www.w3.org/International/
>
>I also think that we might be able to include this as an example of 
>selecting which (markup) language to use - assuming that with SVG and 
>future support of styling languages one could select or create a Hebrew 
>font with vowel marks over one without.
>
>Regardless, this is a good example to add as part of the rationalization.
>
>Thanks,
>--wendy
>
>
>At 08:59 PM 5/18/01 , Adam Victor Reed wrote:
>>I suggested the addition of content modes to Gudeline 4.1 as a
>>possible way of dealing with the vowel mark problem in Hebrew and
>>Arabic, which was brought to our attention by Lisa Seeman (vowel marks
>>are required to support screen reading in user agents, and for
>>accessibility to people with limited reading ability.) If there
>>is no objection, I would like to see Gudeline 4.1 updated as follows:
>>
>>4.1 Choose content modes, languages, API's, and protocols that support
>>the use of these guidelines.
>>         Content modes (e.g. Hebrew with and without vowel marks,)
>>         markup languages, multimedia formats, software interface
>>         standards, etc., vary in their support of accessibility. When
>>         choosing which technologies and content modes to use, consider
>>         how easy it is apply these guidelines. Where feasible, favor
>>         content modes and technologies that:
>>         * support assistive technology in user agents;
>>         * permit equivalents to be associated with or synchronized
>>           with auditory, graphical, and multimedia content;
>>         * allow the logical structure of the content to be defined
>>           independently of presentation;
>>         * support device-independence;
>>         * are documented in published specifications and can be
>>           implemented by user agent and assistive technology
>>           developers.
>>--
>>                                 Adam Reed
>>                                 areed2@calstatela.edu
>>
>>Context matters. Seldom does *anything* have only one cause.
>
>--
>wendy a chisholm
>world wide web consortium
>web accessibility initiative
>seattle, wa usa
>tel: +1 206.706.5263
>/--
>  
Received on Wednesday, 18 July 2001 21:42:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:11 GMT