Re: Important: Issues relating to checkpoint 2.1 raised during 30 March teleconference.

I proposed an alternative solution to the problem - to add a note to the
checkpoint:

Note: For information intended to be human-readable, (for example equivalent
alternatives) a source view alone is insufficient, and access must be
provided as part of the normal user browsing interface.

This avoids changing the checkpoint scope, or meaning, and still requires
that it is possible somehow to find out what is in the source (for example a
javascript: usi that can be interpreted by a human independently of whether
their browser understands it can solve an otherwise complete access block)
but doesn't require a source view (although that is the obvious way to
provide access to all content, with additional features required for
alternative content rendering, etc.

Cheers

Charles McCN

On Fri, 31 Mar 2000, Ian Jacobs wrote:

  Hello,
  
  Several issues were raised during the 30 March 
  teleconference [1] and I'd like to try to summarize
  them here. Please let me know if you think this
  is an inaccurate or incomplete summary. The issues
  are listed in no particular order.
  
  Note: The proposals I make below I make in a vacuum.
        The UA Guidelines are in Proposed Rec review
        and any changes we make might require another
        round of reviews. I'll ignore that fact for the
        purposes of the discussion below. However, without
        committing myself, I think that resolving Issues
        2 and 3 could be considered clarifications rather
        than substantial changes to the document.
        
  
  Issue 1: What is the scope of checkpoint 2.1?
  
     In the proposed rec [2], checkpoint 2.1 reads:
  
       2.1 Ensure that the user has access to all content,       
           including equivalent alternatives for content.
  
     This checkpoint does not specify which content must
     be made available through the user interface. While
     people will rightly assume that some content will be
     made available through the user interface, there is no
     requirement that all content be made available through
     the user interface. At the 2 March teleconference,
     we discussed the option of modifying 2.1 to talk only
     about making content available through the user 
     interface (to complement, rather than overlap with,
     the requirement to make content available through 
     an API), but there was consensus not to change the 
     checkpoint.
  
     Yesterday we also talked about reducing the scope of
     2.1 to making "renderable" content available through
     the user interface. 
  
     The document [2] does not include a requirement that
     all alternative equivalents be available through
     the user interface. Based on the resolution at the
     2 March teleconference, Checkpoint 2.1 intentionally
     does not make that requirement.
  
     Proposal: Change checkpoint 2.1 to read: "Ensure that
     the user has access to all alternative equivalents
     through the user interface."
  
     Problems with this proposal:
  
       1) What will be lose by narrowing the scope from
          "all content" to "alternative equivalents"? Are
          there other parts of content that the user would
          want that cannot be classified as equivalents?
          (More on content generated by scripts below.)
  
       2) How are equivalent alternatives specified in 
          a markup language? In HTML, there are many
          elements that may be used to supply alternative
          equivalents (alt, longdesc, summary, abbr,
          MAP content that is not AREA, OBJECT content).
  
          The case of NOFRAMES is a stubborn one because
          the HTML 4 specification explicitly says not
          to render NOFRAMES content when frames are
          supported [4]:
  
              "User agents that support frames must only display
               the contents of a NOFRAMES declaration
  when                       configured not to display frames."
  
          You can argue that the HTML spec is wrong (or
          needs clarification). We do not have a requirement
          that user agents allow users to turn off frames.
          We used to, but since it was argued that turning
          off frames didn't really make sense, that 
          frames aren't inherently inaccessible, and that
          access to NOFRAMES was possible through an API,
          the requirement to be able to turn off frames was
          dropped.  So the question is: is requiring a
          user agent to render NOFRAMES even when it supports
          frames a violation of checkpoint 6.2 (conform to
          specifications)?
   
  Issue 2: Does a source view satisfy checkpoint 2.1?
  
     Phill Jenkins asked [5] whether a source view would
     satisfy checkpoint 2.1. 
  
     I think it is difficult to conclude from the document
     that a source view is not part of the user interface
     (and in my opinion, a source view is part of the user 
     interface).
  
     However, there seems to be consensus that a
     source view does not satisfy 2.1
     (whatever the outcome of Issue 1) because it does not
     present content in a form that most people can actually
     use. It is entirely unacceptable to expect a user to
     read the binary format of a GIF image. It is less
     unacceptable to expect a user to read the text that's 
     available in the middle of an HTML file, but that still
     requires knowledge of the markup language that we
     should not expect of users (whether or not they
     have a disability).
  
     Thus, there seems to be consensus that:
  
     a) We are not requiring that user agents provide
        a source view.
  
     b) A source view would not satisfy 2.1
  
     c) A source view is useful to some users.
       
     
  Issue 3: What does "content" mean?
  
    There seemed to be disagreement about the definition
    of "content" in the Proposed Recommendation:
  
        "In this document, content means the document source,  
        including its elements, attributes, comments, and other
        features defined by a markup language specification such as
        HTML 4.01 or an XML application. Refer also
        to the definitions of rendered content and equivalent
        alternatives for content."
  
    This is distinguished from rendered content, whose
    definition begins:
  
  
        "Rendered content is the part of content that is 
        rendered after the application of style sheets,   
        transformations, user agent settings, etc."
  
    In fact, the situation is even more complicated than
    that. There seem to be more than two "layers":
  
     - There is document source, which includes associated
       style sheets, external content such as images,
       and probably information communicated in HTTP headers.
  
     - There is the document tree, which may include
       content generated by scripts and transformations.
       What about content generated or suppressed due
       to user preferences (e.g., use "abbr" for table
       cell headers instead of TH content)?
  
     - There is the rendered content, which is what actually
       gets presented to the user. In CSS, content generated
       by style sheets is considered part of rendered content.
       However, will DOM 3 include this as part of the DOM
       tree? (I don't know enough about DOM 3 plans to 
       know this.)
  
       I think "rendered content" is supposed to be "what the
       user gets", which is how I heard some people using
       "content" yesterday.
  
    Hans refers to these three levels in his email of 31
    March [6].
  
    I invite people to suggest ideas for clarifying the various
    states of content from source to DOM to viewport.
  
  Thank you,
  
   - Ian
  
  [1]
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0549.html
  
  [2] http://www.w3.org/TR/2000/PR-UAAG10-20000310/
  [3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0426.html
  [4]
  http://www.w3.org/TR/1999/REC-html401-19991224/present/frames.html#h-16.4.1
  [5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0517.html
  [6] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0547.html
  -- 
  Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
  Tel:                         +1 831 429-8586
  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 Monday, 3 April 2000 06:14:42 UTC