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

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

Received on Friday, 31 March 2000 13:34:14 UTC