Proposed change to: A.1.1

PROPOSED:

[1]

A.1.1 Provide text alternatives for all non-text content in the 
authoring tool user interface

[2]

Glossary Def’ns:

Authoring Interface:
An authoring interface is the display and control mechanism available to 
an author to communicate with and operate the authoring tool software. 
ATAG 2.0 divides authoring tool interfaces into two categories: 
Web-Based (i.e. tools that are implemented using Web content and run 
within a user agent) and non-Web-Based (i.e. tools that run directly on 
a operating system such as Windows or Mac OS). The authoring interface 
is made up of the authoring tool user interface, the editing view user 
interface(s) and, possibly, preview user interface(s).

Authoring Interface, Full-Featured:
A full-featured authoring interface is one that includes editing methods 
for all of the properties that are editable by an authoring tool.

User Interface, Authoring Tool:
The authoring tool user interface is only those parts of the authoring 
interface that operate on the content that is being authored (e.g. menu 
bars, tool bars, pop-up menus, status bar, etc.). This is sometimes 
referred to as the tool’s “chrome”. This does not include the user 
interface for editing views or previews.

User Interface, Editing View:
The editing view user interface is only those parts of the authoring 
interface that convey, in a way that is not editable, the actual content 
that is being authored (e.g. a text editing control in a code-level 
authoring function, a rendered content image in a WYSIWYG authoring 
function).

User Interface, Preview:
The preview user interface is only those parts of the authoring 
interface that exist within a *preview* (e.g. text and images in a 
browser emulator).

Preview: A non-editable, rendered view that is intended to emulate a 
browser or class of browsers



---

CURRENT

A.1.1 Provide text alternatives for all non-text content in the user 
interface @@JR@@ensure preview rendered view out clause is in the defn 
of user interface@@ . [Priority ?]

Rationale: People who have difficulty perceiving non-text content in the 
authoring interface can have text in text alternatives for such non-text 
content made available to them (by assistive technology or braille, for 
example).

Note: ???.

Techniques: ???

Success Criteria:

1. All non-text objects in the authoring tool user interface that have 
information value (e.g., toolbar icon, placeholder image, sound effect, 
etc.) must have a text alternative.
2. All editing views must always include an option to display any 
available text alternatives for non-text objects in the content.



-------------------------
Cheers,
Jan

Received on Monday, 11 July 2005 18:39:50 UTC