Comments on 30-July-2004 WCAG 2.0 WD and related Techniques documents

(This document is encoded in UTF-8.
Japanese characters are enclosed in <span lang="ja" xml:lang="ja">日本語</span> for your convenience.)

2004/09/10  Takayuki Watanabe <nabe@lab.twcu.ac.jp>

WG2, Web Accessibility International Standards Research Working Group of INSTAC (Information Technology Research and Standardization Center, JAPAN), compared JIS X 8341-3:2004 and July 30th version of WCAG TRs [1-3] and would like to submit the following comments to WCAG WG to enhance international standard harmonization and hopefully to improve WCAG 2.0.  :-)

[1] Web Content Accessibility Guidelines 2.0
  <http://www.w3.org/TR/2004/WD-WCAG20-20040730/>
[2] HTML Techniques for WCAG 2.0
  <http://www.w3.org/TR/2004/WD-WCAG20-HTML-TECHS-20040730/>
[3] CSS Techniques for WCAG 2.0
  <http://www.w3.org/TR/2004/WD-WCAG20-CSS-TECHS-20040730/>



I. Overall comments on WCAG 2.0 

(1) We find some part of WCAG 2.0 is difficult to understand because they are too abstract and too precise.  Reader of WCAG 2.0 may need a manual or handbook.  WCAG had better have more examples that show an example to at least one SC.


(2) How far should WCAG treat accessibility-related usability issues?

WCAG seems to have a policy that usability issues that do not enhance the accessibility of Web content by the disabled more than that by everyone including a person without disability should not be treated.  

Accessibility and usability, however, is not an independent matter but related to each other.  Thus, treating some usability issues in a context of accessibility may be necessary in WCAG because there is no Web content usability guidelines in W3C.

(Actually, ISO/CD 23973 Software ergonomics for World Wide Web user interfaces is discussed in ISO/TC 159/SC4 but it is not yet International Standards.
How do you think about the needs of Web usability guidelines in W3C or ISO?)

Introduction of "WAI International Program Office Activity Statement" (http://www.w3.org/WAI/IPO/Activity.html) says;

"Given the importance that the Web has assumed throughout all areas of society, it is vital to ensure that the Web is accessible to people with disabilities, including people with visual, hearing, physical, cognitive, and neurological disabilities. Solutions developed for Web accessibility also improve usability for non-disabled people. For instance, alternative text for images and animations benefits people with visual disabilities, but also people who access the Web by mobile phones and those using slow connections. Likewise, captioning of audio not only ensures accessibility for deaf or hard of hearing users, but also increases usability of hand-held devices without audio output and audio-enabled devices used in noisy environments, and it facilitates searching for and indexing Web content."

A statement, "Solutions developed for Web accessibility also improve usability for non-disabled people.", is almost same as how JIS X 8341-3 treats usability issues.  WCAG, however, seems to have narrower scope in terms of usability.  We think including examples and techniques by this "Solutions developed for Web accessibility also improve usability for non-disabled people." attitude is also needed in WCAG 2.0.

The Scope section of ISO/IEC Guide71, Guidelines for standards developers to address the needs of older persons and persons with disabilities, mentions both accessibility and usability.  Thus, how far WCAG should treat accessibility-related usability issues is important in terms of international standard.


(3) Older persons should be included in addition to the disabled.

JIS X 8341 standards are "Guidelines for older persons and persons with disabilities."  It is "intended to ensure and improve the information accessibility mainly for older persons, persons with disabilities, and persons with temporary disabilities."  WCAG 2.0 WD, however, is explicitly written only for persons with disabilities and persons with temporary disabilities.  We think WCAG 2.0 had better explicitly say it is also written for older persons, who often have several disabilities. As the number of older persons are getting larger and larger, people becomes aware of WCAG if it says it is written also for older persons.

This is important issue as an international standard because ISO/IEC Guide71 clearly includes older persons.



II. Specific comments on WCAG 2.0

(1) JIS X 8341-3 says "5.2.d) Table elements should not be used for layout.", while WCAG 2.0 WD does not discourage the use of a layout table explicitly.  HTML Techniques has a section 8 "Tables for layout" and says "Avoid layout tables."  We suggest WCAG 2.0 Guideline 4.1 L1 SC1 should talk about, probably as an example, this matter.

Or WCAG 2.0 does not talk about "layout tables" because it is technology specific?   Then, we are afraid that audience of WCAG 2.0 cannot understand its intension correctly because WCAG 2.0 is the first and sometimes the only document people read.  Readers of WCAG 2.0 may not notice that WCAG 2.0 discourages layout tables because volume of HTML Techniques is very large and there is no anchor in WCAG 2.0 that links to the specific HTML technique 8.


(2) JIS X 8341-3 says "5.2.f) Frames should not be used more than necessary. Purpose of each frame shall be made clear when frames are used.", while WCAG 2.0 does not discourage the use of frames.  It is well known that frames have usability problems.  HTML Techniques has a section "14 Frames" and refers to this problem.  We suggest WCAG 2.0 Guideline 2.4 should talk about, probably as an example, this matter.  

Or this issue is also not written in WCAG 2.0 because it is technology specific?  Then, we are afraid that audience of WCAG 2.0 cannot understand its intension correctly.


(3) JIS X 8341-3 says "5.5.b) Information required to understand and operate Web content shall not rely on shape and location alone.".  We think "don't rely on location" is indispensable for accessibility.

In the bad example shown below, a user cannot identify the correct button if a table element is serialized.

Bad example:

<table>
  <tr>
    <td colspan="2">Push the lower right button.</td>
    <td><a href="print.html"><img src="print.gif" alt="print"></a></td>
  </tr>
  <tr>
    <td><a href="cansel.html"><img src="cansel.gif" alt="cancel"></a></td>
    <td><a href="ok.html"><img src="ok.gif" alt="ok"></a></td>
    <td><a href="preview.html"><img src="preview.gif" alt="preview"></a></td>
  </tr>
</table>

Good example:

<table>
  <tr>
    <td colspan="2">Push the lower right [Preview] button.</td>
    <td><a href="print.html"><img src="print.gif" alt="print"></a></td>
  </tr>
  <tr>
    <td><a href="cansel.html"><img src="cansel.gif" alt="cancel"></a></td>
    <td><a href="ok.html"><img src="ok.gif" alt="ok"></a></td>
    <td><a href="preview.html"><img src="preview.gif" alt="preview"></a></td>
  </tr>
</table>

This example shows a problem of HTML table technique but generally it is not technology specific.  Thus, we think WCAG should have L1 SC in Guideline 1.3 about this issue.


(4) Suggestion of an example in Guideline 3.1 (meaning):

Example: use the correct character.

In English, shape of some characters such as '0' (zero) and 'O' (o), and '1' (one) and 'l' (l) resemble each other.  Some languages such as Japanese and Chinese have a lot of similar looking characters and are often mistakenly used.  For example in Japanese, font shape of characters such as '<span lang="ja" xml:lang="ja">ー</span>' (Tyou-on), '<span lang="ja" xml:lang="ja">―</span>' (Zenkaku dash), and '<span lang="ja" xml:lang="ja">－</span>' (Zenkaku minus) are resemble each other.  As all these characters are converted from the same character '-' with a Japanese input method, these characters are often misused in Japanese.  A Japanese word "<span lang="ja" xml:lang="ja">リード</span>" is a correct word that means "lead" in English, while "<span lang="ja" xml:lang="ja">リ―ド</span>" makes no sense. Sighted users even do not notice this mistake, while users who use a screen reader cannot understand that word.


(5) Guideline 1.5 may be [level 3 guideline] not [level 2 guideline].



III. We found the following points in WCAG 2.0 WD implicitly assume English and European languages and therefore cannot apply to Asian and other languages.

(1) Guideline 2.4, L2 SC 1
"In documents greater than 50,000 words or sites larger than 50 perceived pages, ..."

A sentence of Japanese and some other languages, however, does not consist of words. Therefore, this SC cannot apply to all languages.


(2) Guideline 2.5, L3 SC 2
"correct spellings are suggested" 
is difficult in some languages such as Japanese.


(3) Guideline 3.1, L3 SC 3. has a long list of instruction about easy-to-read document.  This list, however, is oriented mainly to English.  We suggest that this list should not be put in normative section, SC, but written as informative information.  Or more modification is needed to make this document more language independent.


(4) Guideline 3.1, L3 SC 3 Vocabulary
"using a checklist like the ones produced by US and Canadian government agencies." 
is difficult to accomplish in some languages.



IV. Does WCAG 2.0 cope with the fact that capabilities of assistive technologies in various countries are different?

(1) Guideline 4.1 Example 3
"Java accessible APIs."  
But not all AT have an ability to treat these functions.


(2) We think all L1 SCs should be able to be used to all user agents and ATs over the world.  
Guideline 3.1 L1 SC 2. 
"The meaning of abbreviations and acronyms can be programmatically located.", 
however, may not be achieved in some languages.



V. Proposal of Techniques

(1) "CSS Techniques: 8.1 Specifying fallback fonts" has an Editorial Note on the JIS issue of readable fonts (Issue 892).  We think this should be another CSS technique.

<Technology>CSS Techniques
<Technology Category>CSS/Fonts
<Short Name>Use readable fonts
<Guideline Reference>G 1.3??, G 1.4??
<Task>Font which is easy-to-read considering size and typeface should be specified.
<Description of technique>
<Example Description>
Some characters of Japanese and some other languages consist of many strokes. Han ideograph, used in Japanese writing, of "<span lang="ja" xml:lang="ja">聾</span>", which means "deaf" in English, is one example. Characters consisting of large number of strokes may require larger size to be recognized by a user with low-vision.  This problem can be compensated by selecting an appropriate font design.
<Example Code>
<User Agent Issues>
<Resources>
<Additional Notes>


(2) The following is needed as X(HTML) Techniques with some appropriate coding examples.  

<Technology>(X)HTML Tech
<Technology Category>HTML/Text Markup
<Short Name>pronunciations
<Guideline Reference>G 3.1
<Task>Give pronunciations if it is difficult to read.
<Description of technique>
<Example Description>
Some words, especially proper nouns, have various pronunciations.  For example in Japanese, a proper noun "<span lang="ja" xml:lang="ja">三田</span>" can be read as "<span lang="ja" xml:lang="ja">みた</span>" (Mita) or "<span lang="ja" xml:lang="ja">さんだ</span>" (Sanda).  In these cases users cannot imagine the correct pronunciation if it is not presented by a content creator.  English also has similar examples because screen readers do not know the pronunciation of every words.  A sighted user suffers little problem even if he cannot identify the correct pronunciation.  A user with visual disability, however, may have difficulty in understanding content because pronunciation is an only clue for him.  
<Example Code>
In case of XHTML 1.1, Ruby module (http://www.w3.org/TR/ruby/) seems an appropriate solution.
(Should we use class="reading" attribute?)

<ruby>
  <rb lang="ja" xml:lang="ja">三田</rb>
  <rp>(</rp><rt lang="ja" xml:lang="ja">みた</rt><rp>)</rp>
</ruby>

<User Agent Issues>
<Resources>
<Additional Notes>
(1) A good example is needed for HTML 4.01.
(2) Ruby module seems not to be the correct method to specify a pronunciation.  XHTML should have a mechanism to specify a pronunciation.


(3) The following techniques should be added in addition to "CSS Techniques: 9.3 Spacing letters and words."

<Technology>CSS Techniques
<Technology Category>Text
<Short Name>Vertical writing
<Guideline Reference>G 1.3 (content-structure separation)?
<Task>Linebreak character must not be inserted in the middle of a word for presentation purpose.
<Description of technique>
<Example Description>
Some languages such as Japanese have vertical writing mode.  Some books are written totally in vertical and Japanese newspapers and magazines often use both horizontal and vertical writing in the same page. The writing-mode of CSS3 enables vertical writing from top to bottom.  It is prohibited to write vertically by inserting a line-break element between every character because a user agent cannot recognize these characters as one word.  Only a sighted user can recognize these characters as one word.
<Example Code>
Bad example: "V&lt;br&gt;E&lt;br&gt;R&lt;br&gt;T&lt;br&gt;I&lt;br&gt;C&lt;br&gt;A&lt;br&gt;L"
<User Agent Issues>which UA support writing-mode of CSS3?
<Resources>
<Additional Notes>
We need a good example.



VI. In translating WCAG 2.0 into Japanese, we find the following text is difficult to understand for non-native readers.

(1) Definition of L2 SC in Conformance section is difficult.
It is too abstract and vague to understand and translate into Japanese.
We are afraid English people also feel this difficulty.

We think some examples that clearly show the difference between three SCs help to understand what matter belongs to Level2 SC and what matter does not.


(2) A word "robust", 4th principle of WCAG, is a difficult word to translate into Japanese.
Could you please explain this principle to us in other words?


(3) Guideline 2.2 "Who benefits .." section. 
"People with physical disabilities can access content that is updated often in cases where content might not be processed and read before being refreshed or when read out of order an assistive technology or voice browser."
is difficult sentence to understand.

Is it 
"People with physical disabilities can access content that is updated often in cases where content might not be processed and read before being refreshed or when read out of order by an assistive technology or voice browser. "
?
 
Does it mean
"People with physical disabilities can access content that is updated often in case the content displayed before refreshed is not accessed by an assistive technology."
?


(4) Guideline 2.3 L3 SC
"the combined area of flashes occurring concurrently (but not necessarily contiguously)"
is a difficult sentence to understand.
Could you explain a meaning of "combined"?


(5) General Flash Threshold says
"1. the combined area of flashes occurring concurrently (but not necessarily contiguously) occupies more than one quarter of any 355 x 268 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 by 768 pixels."
Is this definition valid when a low-vision user uses screen magnifier?


(6) "perceived pages" is a difficult expression to understand.


(7) Guideline 2.4 L2 SC
"8 or more links". 
Reference is needed because a reason of 8 is unclear.


(8) Guideline 2.4 L3 SC 5 is difficult to understand.
We need an example in Examples section.


(9) Guideline 2.5 L3 SC 1
"Where the input options are known, there are less than 75 of them,"
needs a reference to show why 75.


(10) Guideline 3.2 Who benefits from Guideline
"Individuals who are unable to detect extreme changes in context or may not realize that the context has changed are less likely to become disoriented while navigating a site."

We think "context" is not an appropriate word because we think it talks about something displayed to a user and has no relationship to a meaning (context).


(11) Guideline 4.2 L1 SC1
"If inaccessible plug-ins are available, then a method for obtaining an accessible plug-in is provided from the content."

"is provided from the content" is difficult to understand.