Re: Proposed modification to checkpoint 2.7 (identification of language)

Sort of. We are actually warning the user that this is not junk, but that we
can't deal with it. The rules applied to braille displays as well as screen
readers.

The problem is that in many cases there is no particularly good answer to
"who has to do then implementation" - if I use emacs with a braille display
then there is no good reason for the braille display to expect to have to go
through the DOM - it is just providing an output device for a character
stream. (Effectively, I am using emacs in a mode where there is a one-line
window - the same as I can do in a normal X-window environment.)

So the anser that "it is there through the DOM" may not be good enough for
all assistive technologies - it is only relevant to some. And braille
translators change for different languages - if they are being told that they
are getting english when  they are really getting german, who should make the
repair? As a practical question, the user should manually set to german, but
to do that they need to know what is going on...

Charles McCN

On Wed, 19 Jul 2000, Ian Jacobs wrote:

  Hello,
  
  In the 7 July UA Guidelines, checkpoint 2.7 reads:
  
    2.7 For author-identified but unsupported natural 
        languages, allow the user to configure the user 
        agent to identify those language changes in content.
  
  At the 13 July teleconference [2], I expressed a concern about
  proposing the minimal requirement be to render the information
  "in content" and got an action item to propose a change.
  Please consider the following proposals:
  
  1) Delete checkpoint 2.7. This checkpoint was initially 
     included in the UA Guidelines in support of the WCAG 1.0 
     checkpoint 4.1:
  
         Clearly identify changes in the natural language of a 
         document's text and any text equivalents (e.g., captions).
  
     As I recall, this checkpoint was included as a P1 requirement
     to that screen readers capable of handling several languages might
     switch dictionaries. However, checkpoint 2.7 is not about making
     the markup provided by the author available to assistive
  technologies;
     it's abount rendering through the native UI. In my opinion,
     our requirements to implement the DOM are the appropriate 
     reflection of the WCAG 1.0 requirement. And therefore, if the
     checkpoint is not about the UI, I think we should delete it.
  
  2) Don't delete checkpoint 2.7 because rendering content written in
     an unsupported natural language with incomprehensible glyphs or
     sounds may cause accessibility problems. I don't think we should
  argue
     that the problems are for assistive technologies (since they should
  get
     the information through the DOM). But we could argue for that many
     users, including users with some disabilities, viewing content
  through
     a native viewport when that content is rendered as garbage may be
     disorienting. We should either require the UA not to render garbage,
     or to identify it as such. 
  
     I would note that the HTML specification, section 5.4 [5] discusses
     the handling of undisplayable characters. It recommends the following
     to user agents:
  
        Adopt a clearly visible, but unobtrusive mechanism to 
        alert the user of missing resources. 
  
    Please consider the following wording for a revised P3 checkpoint:
  
    <NEW>
      2.7 For content in a recognized but unsupported natural 
          language, allow configuration so that when rendered,
          this content does not disorient the user. The user 
          agent may choose to not render this content, but must
          indicate the absence through the user interface.
        Note: For example, if the user agent does not support
        Japanese, render "[Japanese text]" instead of the content,
        or use an accessible icon that indicates an unsupported language.
     </NEW>
  
  Other techniques:
  
   - Render the name of the language and use a colored background
     to indicate that content is garbage.
  
  Notes:
  
   - I have removed the part about the text being marked-up
     by the author. I think the requirement should apply for
     any text content recognized by the user agent as being
     in an unsupported natural language. The techniques document
     talks about ways to identify natural language.
  
   - The requirement used to only be about changes in natural language.
     However, I think the accessibility issue raised above applies
     for all unsupported natural languages, even if the entire document
     is in that language.
  
     IMPORTANT: We decided (refer ot issue 174) to remove a requirement
     to render content according to natural language specifications
  because
     we said that not doing so was not an accessibility issue. I'm arguing
     here that rendering junk without warning the user that it's junk
     may be an accessibility issue.
  
   - Ian
  
  [1] http://www.w3.org/WAI/UA/WD-UAAG10-20000707/
  [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0056.html
  [3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html
  [4] http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
  [5] http://www.w3.org/TR/1999/REC-html401-19991224/charset.html#h-5.4
  [6] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#174
  -- 
  Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
  Tel:                         +1 831 457-2842
  Cell:                        +1 917 450-8783
  
  

--
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
Postal: GPO Box 2476V, Melbourne 3001,  Australia

Received on Thursday, 20 July 2000 00:59:58 UTC