Distinguish two interfaces -- comments on WCAG 2.0 Last Call Draft

Commenter:

Email:

Affiliation:

Date:

Directions

Column 1: Enter the abbreviation for the Document you are commenting on:
- W2 for WCAG 2.0.
- UW(or HTM) for Understanding WCAG document (and for the How To Meet sections of this doc).
- TD for Techniques document.
Column 2: Enter the major section name or Item number of the guideline, success criterion, technique etc that you are commenting on.
- For example "Intro" for introduction "1.1" for a guideline 1.1, "3.2.1" for success criterion 3.2.1, "H-56" for HTML technique number H-56
Column 3: Enter the heading for the section you are commenting on.
- E.g. "Intent", or "Description", or "Examples", etc.
Column 4: Enter the type of comment you are making
- G = General (i.e., applies to whole document)
- T = Technical (i.e., deals with substance)
- E = Editorial (i.e., concerns grammar, wording, formatting, etc.)
- Q = Question (i.e. not requesting any change).
All : are required.
Filling out column 6 greatly increases our ability to understand and address your concern.

Please ensure that the comments submitted are as complete and "resolvable" as possible. Thank you.

1. Document Abbv. (W2/UW/TD)	2. Item Number (e.g. 1.1)	3. Part of Item (Heading)	4. Comment Type (G/T/E/Q)	5. Comment (Including rationale for any proposed change)	6. Proposed Change (Be specific)
W2	throughout		G/T	Distinguish requirements that apply at the User Interface, i.e. in the Rendered Content, from requirements that apply at the network interface, i.e. in the Communicated Content. The latter is defined by how the content is represented as it passes from the author and server's automation to the user's automation. We may be able to resurrect the notion of a [generic] document object model as a slightly stronger statement of the 4.1 'clean parse' language and tie "programmatically determined" clauses there.	Distinguish requirements that apply at the User Interface, i.e. in the Rendered Content, from requirements that apply at the network interface, i.e. in the Communicated Content. 1.3.2 is an example of the former. 1.3.2 is an example of the latter.
W2	Intro	Role of User Agents	G/T	The role of User Agents is underdeveloped in this document, and the effectiveness of the document suffers. There is a whole missing principle of "different strokes for different folks." It is not enough to say "people have to perceive the presentation of information." The encoding or representation of the information in that rendered view must be recognizable. The success criterion is in terms of cognition, not perception. Further, there is no "one size fits all" presentation that affords a functional user experience for all people. So the fundamental requirement is one of personalization: that the same information can be presented and accepted in diversified look-and-feel variants to reach all the people. The User Agent doesn't just render the display and process user input events. It also affords the user view-management funtions such as navigation within the document and presentation property profiling. These are managed between the user and the user agent. Sometimes it is not easy to make the rendering transform plastic enough to enable use by all users, and the server has to offer content choices to achieve the full range of under which the web content and/or service is available.	Clearly represent that the guidelines set out in this document apply to the data passing through the network interface, not the signals passing through the user interface. Explain the requirements here (in this document, not a companion note) starting with User Interface requirement, but transformed by the capabilities and needs of User Agents.
W2	1	statement of principle	G/T	"content is perceivable" is an oxymoron. The two are not comparable. The rendering is perceivable. In the rendering, the content must be recognizable.
W2	1.3	statement of guideline	G/T	It doesn't work until the content is re-united with an adapted presentation.	change to: Ensure that presentation can be adapted while preserving content. Alternate language: Enable personalization of presentation.
W2	1.3.2	SC itself	G/T	Requiring that the other way of showing the color-signaled information is visual is a UI requirement. It is not a content requirement. This requirement is inappropriate for a claim that includes SALT in its baseline such that the default presentation would speak the information as well as show it with color. Compare with UAAG 2.3. Sometimes you should not try to replicate the richness of the color coding in other, more limited property spaces, but rather signal that there is further information and expand on the further information on user interactive request. Compare also to the 'minimized' treatment of notes in a DAISY player. Here the presence of a note is evident, the content of the note is available but on an 'ask for' basis. 24 bits per pixel of color-coded information is just too much information to assume that other visual effects can capture it all.	User Interface requirement: strike the word 'visually' to leave "is also evident, or is available and the availability of more information is evident" Content requirement: The default prsentation afforded without user intervention satisfies the above requirement. [alternate language: .. is visually evident ... in the author-designed visual presentation of the content] Content requirement: The connotations of color and other presentation-properties constitute non-text information and must (per 1.1.1) be afforded text explanations that are associated with the items bearing these presentation effects (and connotations), associated by an association that can be programmatically determined.