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

hi Ian

see comments at MN: below.

At 1:34 PM 3/31/00, 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."


MN:  "Ensure that the user has access to all renderable content
available through  the user interface  -or - Ensure that
the user has access to all alternative equivalents
through the user interface."   either of which seem to me
like a sub-set of the current 2.1.  I'd rather leave 2.1 as
is, and if people see the need, make one or both of these special
cases of 2.1, like we've done with other checkpoints?





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

MN:  agree with a, b, and c.



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

MN:  I think you have the definitions in order, source->DOM tree->
rendered 'view', and i'm ok with "rendered content" as supposed to
be "what the user gets".




>  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 18:27:37 UTC