- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Mon, 01 May 2006 13:48:12 -0400
- To: "List (WAI-AUWG)" <w3c-wai-au@w3.org>
[1] Checkpoint text: ok A.1.5: Ensure that information, functionality, and structure can be separated from presentation. [Priority 1] [2] Rationale: OK; just added "the" between "allows" and "user" Rationale: Separating content and structure from presentation allows the user interfaces of authoring tools to be presented differently to meet the needs and constraints of different authors, without losing any of the information or structure. For example, information can be presented via speech or braille (text) that was originally intended to be presented visually. It can also facilitate automatic emphasis of structure or more efficient navigation. All of these can benefit authors with cognitive, physical, hearing, and visual disabilities. [3] Success Criteria: some REWORDING - main change is to allow an alternate version for presentation in the editing view that has some informational significance (SC2). SC1: WHEN CONTENT IS RENDERED IN A *content display* (E.G. WYSIWYG VIEW), all characteristics of the presentation (e.g. color, boldness, positioning, etc.) must be *available programmatically*. SC2: WHEN PRESENTATION IS ADDED TO A *content display* (e.g. coloring misspelled words, identifying tag text in a code view) TO PROVIDE INFORMATION, the semantic description of the presentation must EITHER be *available programmatically* OR BE PROVIDED BY AN ALTERNATIVE VERSION THAT MEETS *PART A*. SC3: WHEN the presentation of controls within the *editing interface* of the authoring tool user interface (e.g. dialog boxes, menus, user interface elements in the editing view) CONVEYS INFORMATION, the semantic description of the presentation must be *available programmatically*. SC4: WHEN information is conveyed by color (e.g. red underlining for spelling error vs. green underlining for grammar error) IT MUST either BE visually evident when color is not available (e.g. by the shape of the underlining) or BE provided by an alternative version that meets *Part A* (e.g. spell and grammar checking utilities). For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint. OK [4] TECHNIQUES: Missing applicability statements for each; several commas removed Techniques for SC1: APPLICABILITY: This success criteria is applicable to any presentation changes that are a result of rendering content (e.g. WYSIWYG views). Technique A.1.5-1.1 [Sufficient]: Providing information on the size, font, foreground and background color, font weight, and position of any text that is under the control of the author, via an accessibility platform architecture or another published interoperability mechanism. ADDED: Technique A.1.5-1.2 [Advisory]: Providing information on the size, foreground and background color, and position of any non-text content that is under the control of the author, via an accessibility platform architecture or another published interoperability mechanism. Techniques for SC2: APPLICABILITY: This success criteria is applicable to any presentation changes are not the result of rendering content and are not applied uniformly to the view (e.g. highlighting a misspelled word in red is applicable, allowing the author to set the display color text of a text editor to red is not) SEMANTIC misspelled: Technique A.1.5-2.1 [Sufficient]: Providing semantic labels and descriptions for any presentation that is added to the editing view by the authoring tool, via an accessibility platform architecture or another published interoperability mechanism. Techniques for SC3: APPLICABILITY: This success criteria is applicable to any instances in which the presentation of controls in the authoring tool user interface is important to an author's understanding and use of the controls. (e.g. a positioning control that involves text entry boxes placed at the points of a compass graphic is applicable, but a text box prompting for name probably is not) SEMANTIC misspelled: Technique A.1.5-3.1 [Sufficient]: Providing semantic labels and descriptions for any presentation that is that is part of the editing interface, via an accessibility platform architecture or another published interoperability mechanism. Techniques for SC4: APPLICABILITY: This success criteria is applicable to any instances in which the understanding or use of controls in the authoring tool user interface would be prevented without color. "ELEMENT" CHANGED TO "PART": Technique A.1.5-4.1 [Sufficient]: Ensuring (by design, testing on monochrome displays, including color blind individuals in testing, etc.) that color alone is not required to identify any part of the editing interface of the tool. "ELEMENT" CHANGED TO "PART": Technique A.1.5-4.2 [Sufficient]: Providing an alternative route to the information or functionality that is accessed via a part of the editing interface of the tool that requires color discrimination to understand or access.
Received on Monday, 1 May 2006 17:49:14 UTC