W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 2006

ATAG 2.0 In-group checkpoint review: A.1.5

From: Jan Richards <jan.richards@utoronto.ca>
Date: Mon, 01 May 2006 13:48:12 -0400
Message-ID: <445649DC.2090607@utoronto.ca>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:06 GMT