- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 31 Mar 2000 13:34:10 -0500
- To: w3c-wai-ua@w3.org
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