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

ATAG 2.0 In-group checkpoint review: A.1.1

From: Jan Richards <jan.richards@utoronto.ca>
Date: Tue, 25 Apr 2006 16:48:01 -0400
Message-ID: <444E8B01.8090306@utoronto.ca>
To: "List (WAI-AUWG)" <w3c-wai-au@w3.org>

[1] Checkpoint Text: A reviewer noted that the text should be changed to
match WCAG. A possibility (as stated in
http://lists.w3.org/Archives/Public/w3c-wai-au/2006AprJun/att-0016/12_2005_comment_responses.html) 

is to amend the text - but actually I don't mind keeping it the way it 
is to clarify its applicability - here are the two possibilities:

A.1.1 Provide text alternatives for all non-text content in the user
interface. [Priority 1]

A.1.1 Provide text alternatives for all non-text content. [Priority 1]


[2] Rationale: propose changing the example to match our usual style

Rationale: People who have difficulty perceiving non-text content can
often access the same information if it is conveyed using a text
alternative (by assistive technology or braille, for example).

to:

Rationale: People who have difficulty perceiving non-text content are 
often able to access text alternatives of the same information, since 
text is more easily transformed between various display methods (e.g. 
magnification and enhancement, text-to-speech, Braille output).


[3] Success Criteria 1: Wording better match WCAG (TO DISCUSS: Only one 
of WCAG SC used), add new definitions (from WCAG) for "non-text content" 
"convey information" "functional"; make singular.

1. All user interface non-text objects that are used to convey
information (e.g., toolbar icon, graphical depiction of a tag, sound
effect, etc.) must have a text alternative (e.g. alternative text label,
long text description).

to:

1. All *non-text content* in the *user interface* that presents 
information (e.g. graphical depiction of a tag, screen capture in 
documentation, sound effect) or responds to author input (e.g. graphical 
toolbar button) must have *text alternatives* that serve the same 
purpose and present the same information as the non-text content.


[4] Success Criteria 2: Reworded for clarity; example added; renumbered

2. All editing views must always include an option to display any
available text alternatives for non-text objects in the content.

to:

2. All *editing views* must include an option to display text
alternatives for non-text in content being edited.


[5] Reference to A.0.1: Reworded to be specific to SC1:

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve
to meet this checkpoint.

to:

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve
to success criteria 1 of this checkpoint.


[6] Techniques - reworked for new SC wording; applicability statements 
made positive:

Techniques for SC1:

Applicability: This success criteria is only applicable if non-text 
content that presents information (e.g. graphical depiction of a tag, 
screen capture in documentation, sound effect) or responds to user input 
(e.g. graphical toolbar button) appear within the user interface 
(non-text content in the content being edited is not within the scope of 
this success criterion).

Technique A.1.1-1.1 [Sufficient]: Ensuring that non-text content in the 
user interface that presents information or responds to author input has 
text alternatives (e.g. short text label, long text description) that 
are available both on screen (e.g. by tool tip) and programmatically to 
assistive technologies.

Example A.1.1-1.1(a): A given tool makes use of graphical toolbar 
buttons that respond to author input. The buttons are
accompanied by alternative text labels that describe the function of the 
buttons.

Example A.1.1-1.1(b): A given tool makes use of informative images (e.g. 
screen captures within on-line documentation). The screen captures are
accompanied by both alternative text labels and long text descriptions.

Technique A.1.1-1.2 [Advisory]: Providing a text rendering option 
whenever text is rendered as non-text content.

Example A.1.1-1.2: A given tool has an editing view that includes 
graphic renderings of tags to show the author where elements begin and 
end. In the author preferences of the tool, there is a option to "Show 
tags as text", which replaces these graphical tags with the text of the 
tags (e.g. <img> and </img>).

Technique A.1.1-1.3 [Advisory]: For tools that display collections of
content using graphic representations of the objects, links, etc.,
providing the author with the option of displaying the information as
text. (e.g. as a structured tree).


Techniques for SC2:

Applicability: This success criteria is only applicable if an editing 
view allows non-text content to be authored.

Technique A.1.1-2.1 [Sufficient]: In editing views that render non-text
content, displaying, in an editable fashion, any text alternatives 
(short text labels, long text descriptions) associated with the non-text 
content (e.g. within a properties dialog).

Technique A.1.1-2.2 [Sufficient]: When appropriate for a content type,
providing a code-level editing view that allows direct viewing and 
editing of text alternatives.

EXAMPLE A.1.1-2.2: Text editors provide access to all markup and 
content, including text alternatives.

Technique A.1.1-2.3 [Advisory]: Providing an option to toggle between
rendered non-text content and the text alternatives for that content.

Example A.1.1-2.3: This illustration shows an authoring interface that
allows the author to toggle between a fully rendered image and the text 
alternative of the image (with a small preview rendering of the image 
for context). (Source: mockup by AUWG)

IMAGES: ok



Cheers,
Jan
Received on Tuesday, 25 April 2006 20:48:35 GMT

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