- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 03 Apr 2000 10:37:00 -0400
- To: Charles McCathieNevile <charles@w3.org>
- CC: w3c-wai-ua@w3.org
Charles McCathieNevile wrote:
>
> 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,
I believe that saying the following would not change the scope
of 1.2:
1) All content must be available (through the UI or an API).
2) When rendered through the UI, human-viewable content must
be rendered for human consumption (and a source view does not
suffice since markup is not meant for ordinary users).
3) Not all content that is human-viewable
must be made available through the user interface.
I haven't heard agreement on point three, even though I believe
there was consensus on 2 March 2000 to leave checkpoint 1.2 ambiguous
about what had to be rendered through the user interface.
I believe that if we change three to be "All content that is meant
to be viewed by the user must be available through the UI", then
we are not only reversing a decision made on 2 March, but we are
changing
the scope of checkpoint 1.2.
I think we need to make 1.2 clearer, and changing point 3 is probably
a good idea since it will reduce the ambiguity about what needs to
be available through the UI (we already know that everything must
be available through an API).
- Ian
> 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
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 429-8586
Cell: +1 917 450-8783
Received on Monday, 3 April 2000 10:37:04 UTC