Re: Including content modes in 4.1

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..."

This is based on my understanding of these documents:
http://www.w3.org/International/O-charset.html
http://www.w3.org/International/O-fonts.html
http://www.w3.org/International/O-MissCharGlyph
http://www.w3.org/International/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/

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 20:40:08 UTC