Draft Accessible Authoring Interface Requirement for ATAG 2.0

GUIDELINE 1: Make the authoring interface accessible

The design of all aspects of the authoring tool, including the authoring interface, installation procedure, documentation, and help files, must be accessible.

Conformance note for authoring tools with Web-based functionality: For the purposes of Guideline 1, Web-based functionality will be evaluated in the the context of the user agent(s) in which it is rendered, allowing user agent functionality to play a role, along with accessible Web page design, in satisfying the following checkpoints (NEW.2, From_UAAG.1, From_UAAG.2, NEW.1, EXISTING(1.5), From_UAAG.4, From_UAAG.5, From_UAAG.6, From_UAAG.7, EXISTING(1.3), From_UAAG.8, From_UAAG.9, From_UAAG.10, From_UAAG.11, From_UAAG.12, From_UAAG.14, From_UAAG.15, From_UAAG.16, From_UAAG.17, From_UAAG.18, and From_UAAG.21, From_UAAG.25). In order to cite user agent functionality in a conformance evaluation, the user agent must be identified in the conformance profile.@@adaptation of JR's proposal - http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0016.html moved here@@

@@marked terms need ATAG defintions@@

NEW.1 Ensure that Web-based functionality conforms to WCAG [Priority RP]

Rationale:

Techniques:

Success Criteria:

  1. Any component of an authoring tool that is Web-based must conform to WCAG.
NEW.2 Ensure that fully rendered views conform to UAAG 1.0. [Priority 1]

Rationale: ???

Techniques:

Success Criteria:

  1. If an authoring tool provides a view that is intended to mimic the way the content will be rendered by a user agent, then that view is considered to be a user agent and must conform to UAAG 1.0 or the author must be able to specify a different user agent to perform the preview.
FROM_UAAG.1. Ensure full keyboard access [Priority 1] [Adapted from UAAG 1.1, 9.7, 11.4, 11.5]

Rationale: Since people use a variety of devices for input and output, authoring tool developers need to ensure redundancy in the authoring interface. The author may be operating the authoring interface with a variety of input devices (e.g., keyboard, pointing device, and voice input) and output modalities (e.g., graphical, speech, or braille rendering).

Techniques:

Success Criteria:

  1. The author must be able, through keyboard input alone, to perform any authoring task (e.g. navigating, selecting, and editing content, operating the authoring interface, installing and configuring the authoring tool, and accessing documentation) that is available through the authoring interface.
  2. Single-key access must be provided to the following functionalities:
    • move @@content focus to the next enabled control in authoring interface, and move @@content focus to the previous enabled control in the authoring interface.
    • for graphical viewports: navigate forward and backward through content by approximately the height of the viewport
    • open help system
  3. Key-plus-modifier-key access must be provided to the following functionalities (if present):
    • open new content
    • open existing content
    • save content
    • close content
    • cut/copy/paste
    • undo
    • find/replace
    • for graphical viewports: navigate to the start and end of the content
EXISTING(1.4) Ensure that the authoring interface enables the author to Provide navigation of content structure and ability to perform structure-based edits. [Priority 2]

Rationale: It is often more efficient to navigate and edit via the structure in Web content.

Techniques: Implementation Techniques for Checkpoint 1.4

Success Criteria:

  1. In any element hierarchy, the author must always be able, with a device-independent action, to move the editing focus from any element to any of the following elements, if they exist: the element immediately above (i.e. parent), the first element immediately below (i.e. child), the element immediately preceding at the same level (i.e. previous sibling), and the element immediately following at the same level (i.e. next sibling).
  2. In any element hierarchy, the author must always be able, with a device-independent action, to select content and perform editing functions on any element along with any content, including subelements.
FROM_UAAG.2 Ensure that equivalent alternatives are available. [Priority 1] [Adapted from UAAG 1.3, 2.5]

Rationale: ???

Techniques:

Success Criteria:

  1. All non-text objects in the authoring interface that have information value (e.g., toolbar icon, placeholder image, sound effect, etc.) must have an equivalent alternative.
  2. All editing views must always include an option to display any available equivalent alternatives.
 
FROM_UAAG.3 Allow time-independent interaction. [Priority 1] [Adapted from UAAG 2.4]

Rationale: ???

Techniques:

Success Criteria:

  1. All authoring time limits must be configurable by the author unless they are controlled by time-sensitive external processes (e.g. collaborative authoring to a real-time audience).
NEW.3 Provide an undo function. [Priority 1]

Rationale: Some authors may experience a higher number of unintended actions than others.

Techniques:

Success Criteria:

  1. All actions must be either reversible with an undo function or include a warning to the author that the action is irreversible.
EXISTING(1.5) Ensure that the authoring interface allows the author to Provide searching within the editing views. [Priority 2]

Rationale: Search functions within the editing views facilitate author navigation of content as it is being authored by allowing the author to move focus quickly to arbitrary points in the content. Including the capability to search within text equivalents of rendered non-text content increases the efficiency of the search function.

Techniques: Implementation Techniques for Checkpoint 1.5

Success Criteria:

  1. At least one comprehensive editing view must always include a search function that meets the three conditions below.
    • (a) Provides search within any rendered Web content
    • (b) Provides the option to search markup when the tool allows direct editing of markup (e.g. when authored "by hand").
    • (c) Provides the option to search for text within all text equivalents of any non-text content
FROM_UAAG.4 Ensure that potential distractions can be turned off. [Priority 1] [Adapted from UAAG 3.1, 3.2, 3.3, 3.6]

Rationale: Some displays may distract authors or obscure information. For instance, flashing content may trigger seizures in people with photosensitive epilepsy, or may make an authoring interface too distracting to be usable by someone with a cognitive disability. Blinking text can affect screen reader users, since screen readers (in conjunction with speech synthesizers or braille displays) may re-render the text every time it blinks. Distracting background images, colors, or sounds may make it impossible for authors to see or hear other information.

Techniques:

Success Criteria:

  1. If the authoring tool includes within the authoring interface or renders within any editing views any of the following, there must be a configuration setting to turn this off:
    • images (including background images)
    • audio
    • animation (including video)
    • animated or blinking text
FROM_UAAG.5 Ensure that visual displays are configurable. [Priority 1] [Adapted from UAAG 4.1, 4.2, 4.3]

Rationale: Authors with low vision may require that text be rendered at a size larger than the size specified by the authoring tool's defaults. authors with color blindness may need to impose or prevent certain color combinations.

Techniques:

Success Criteria:

  1. The author must be able to configure all text (size, font family, and foreground/background color) and the non-text objects (size, color):
    • (a) for the entire authoring interface (including content within editing views),
    • (b) using either the authoring tool or via the operating enviornment settings,
    • (c) in a range that is the same as that available in the operating environment settings.
From_UAAG.6 Ensure that audio displays are configurable. [Priority 1] [Adapted from UAAG 4.7] @@needs work@@

Rationale: Authors with hearing impairments may require that audio be increased in volume, substituted by different sounds or by visual indicators.

Techniques:

Success Criteria:

  1. The author must be able to configure audio (volume, sounds used, visual indicators of):
    • (a) or the entire authoring interface (including editing views),
    • (b) using either the authoring tool or via the operating enviornment settings,
    • (c) in a range that is the same as that avaialble in the operating environment settings
From_UAAG.7 Ensure enhanced access to multimedia. [Priority 1] [Adapted from UAAG 4.4, 4.5]

Rationale: ???

Techniques:

Success Criteria:

  1. For any rendered audio or animation in the authoring interface (including editing views for such content), the author must be able to
    • (a) stop, pause, and resume
    • (b) slow the presentation rate of rendered audio to 80% of its original speed and animation to at least 50% of its original speed.
EXISTING.1.3 Ensure editing views display preferences can be configured independently of the content. [Priority 1] @@wording change@@

Rationale: Authors may require a set of display preferences to view and control the document that is different from the display styles that they want to define for the published document (e.g. a particular text-background combination that differs from the published version).

Techniques: Implementation Techniques for Checkpoint 1.3

Success Criteria:

  1. All editing views must always include an option to display any available equivalent alternatives. [@@moved to UAAG.2@@]
  2. The author must be able to configure the display settings of all editing views without affecting the Web content being edited.@@wording change@@
From_UAAG.8 Provide a focus within each editing view. [Priority 1] [Adapted from UAAG 9.1]

Rationale: ???

Techniques:

Success Criteria:

  1. Each editing view @@viewport must have at least one @@content focus.
  2. The author must be able to make the @@content focus of any editing view @@viewport the @@current focus.
From_UAAG.9 Provide an authoring interface focus. [Priority 1] [Adapted from UAAG 9.2]

Rationale: ???

Techniques:

Success Criteria:

  1. Provide an @@authoring interface focus.
From_UAAG.10 Ensure predictability of viewport behavior. [Priority 2] [Adapted from UAAG 5.1, 5.2, 5.4, 9.5]

Rationale: Control of viewport behavior is important to accessibility. Unexpected changes to the point of regard — what the author is presumed to be viewing — may cause authors to lose track of how many viewports are open, or which viewport has the current focus. If carried out automatically, these changes might go unnoticed (e.g., by some authors with blindness) or be disorienting (e.g., to some authors with a cognitive disability).

Techniques:

Success Criteria:

  1. There must be an option that ensures that moving the content focus to or from any control does not automatically activate any explicitly associated event handlers of any event type.
  2. There must be an option that requires that if a @@viewport opens without @@explicit user request, neither its @@content focus nor its @@user interface focus automatically becomes the @@current focus.
  3. For graphical user interfaces, there must be a configuration option that keeps the viewport with the @@current focus "on top" of all other viewports with which it overlaps.
  4. When a viewport's @@selection or @@content focus changes, the new selection or content focus must be at least partially in the @@viewport after the change.
From_UAAG.11 Ensure programmatic operation of authoring tool user interface. [Priority 1] [Adapted from UAAG 6.5] @@needs work@@

Rationale: ???

Techniques:

Success Criteria:

  1. Programmatic read access to @@authoring tool user interface controls, @@selection, @@content focus, and @@user interface focus must be provided via an API (see API note).
  2. If the author can modify the state or value of a authoring tool user interface control (e.g., by checking a box or editing a text area), allow programmatic read access(see API note) to the current state or value, and allow the same degree of write access programmatically as is available through the authoring interface.

API Note: APIs used to satisfy the API requirement may vary. For instance, an they may be independent of a particular operating environment (e.g., the W3C DOM), or the conventional APIs for a particular operating environment, or the conventional APIs for programming languages, plug-ins, or virtual machine environments. Authoring tool developers are encouraged to implement APIs that allow assistive technologies to interoperate with multiple types of software in a given operating environment (e.g., user agents, word processors, and spreadsheet programs), as this reuse will benefit authors and assistive technology developers. Authoring tools should always follow operating environment conventions for the use of input and output APIs.

From_UAAG.12 Ensure programmatic notification of changes. [Priority 1] [Adapted from UAAG 6.6] @@needs work@@

Rationale: ???

Techniques:

Success Criteria:

  1. Provide programmatic notification of changes (see API note) to content, states and values of content, authoring tool user interface controls, selection, content focus, and user interface focus.
Ensure programmatic access to underlying Web content being authored . [Priority 1] [Adapted from UAAG 6.1, 6.3]
@@needs work - this checkpoint is a combination of a couple of UAAG checkpoints, but perhaps it does not really makes sense here. One concern is that some authoring tools won't even have the underlying Web content (e.g. indirect authoring tools), since it doesn't get generated until publishing. Others take the content apart to accomplish the editing process. Perhaps "From_UAAG.11 is enough?@@

Rationale: ???

Techniques:

Success Criteria:

  1. Provide programmatic read access to XML content by making available all of the information items defined by the W3C XML Infoset [INFOSET].
  2. Provide programmatic read access to HTML content by making available all of the following information items defined by the W3C XML Infoset [INFOSET]:
    • Document Information item: children, document element, base URI, charset
    • Element Information items: element-type name, children, attributes, parent
    • Attribute Information items: attribute-type name, normalized value, specified, attribute type, references, owner element
    • Character Information items: character code, parent element
    • Comment Information items: content, parent
  3. For content other than HTML and XML, provide structured programmatic read access to content.
  4. If the user can modify the state or value of a piece of non-HTML/XML content through the user interface (e.g., by checking a box or editing a text area), allow programmatic read access to the current state or value, and allow the same degree of write access programmatically as is available through the user interface.
From_UAAG.14 Ensure programmatic access to information about rendered content. [Priority 1] [Adapted from UAAG 6.4] @@needs work@@

Rationale: ???

Techniques:

Success Criteria:

  1. For graphical user interface editing views, implement at least one API (see API note) in order to:
    • make available bounding dimensions and coordinates of rendered graphical objects. Coordinates must be relative to the point of origin in the graphical environment (e.g., with respect to the desktop), not the viewport.
    • provide access to the following information about each piece of rendered text: font family, font size, and foreground and background colors.
 
 
 
From_UAAG.15 Support conventional keyboard APIs. [Priority 1] [Adapted from UAAG 6.7] @@needs work@@

Rationale: ???

Techniques:

Success Criteria:

  1. Implement APIs for the keyboard as follows:
    • Follow operating environment conventions. Note: An operating environment may define more than one conventional API for the keyboard. For instance, for Japanese and Chinese, input may be processed in two stages, with an API for each stage.)
    • If no conventions exist, implement publicly documented APIs
 
 
From_UAAG.16 Respect focus and selection conventions. [Priority 1] [Adapted from UAAG 7.1]

Rationale: Following @@operating environment conventions increases predictability for authors and for developers of assistive technologies. These guidelines explain what authors will expect from the look and feel of the authoring interface, keyboard conventions, and documentation. These guidelines also include information about accessibility features that the authoring tool should adopt rather than reimplement.

Techniques:

Success Criteria:

  1. @@Operating environment conventions that benefit accessibility must be followed when implementing the @@selection, @@content focus, and @@user interface focus.
From_UAAG.17 Respect input configuration conventions. [Priority 1] [Adapted from UAAG 7.2]

Rationale: ???

Techniques:

Success Criteria:

  1. The default @@input configurations of the authoring tool must not interfere with @@operating environment accessibility conventions (e.g., for keyboard accessibility).
From_UAAG.18 Respect operating environment conventions. [Priority 2] [Adapted from UAAG 7.3]

Rationale: ???

Techniques:

Success Criteria:

  1. @@Operating environment conventions related to user interface design, keyboard configuration, product installation, and documentation that benefit accessibility must be followed.
From_UAAG.19 Display current input configuration. [Priority 1] [Adapted from UAAG 7.4, 11.1]

Rationale: ???

Techniques:

Success Criteria:

  1. The current author preferences for @@input configurations must be displayed in either a centralized fashion (e.g., a list of bindings) or a distributed fashion (e.g., by listing keyboard shortcuts in user interface menus)
From_UAAG.20 Allow the author to override bindings. [Priority 2] [Adapted from UAAG 11.3]

Rationale: Authors have a wide range of capabilities and need to be able to configure the authoring tool according to their preferences for styles, graphical user interface configuration, and keyboard configuration

Techniques:

Success Criteria:

  1. The author must be able to override any binding that is part of the default @@input configuration. (Note: This only applies to bindings for the same input modality (e.g., the author must be able to override a keyboard binding with another keyboard binding) and excludes conventional bindings for the operating environment (e.g., for access to help)).
From_UAAG.21 Provide author profile functionality. [Priority 2] [Adapted from UAAG 11.6] @@P3?@@

Rationale: ???

Techniques:

Success Criteria:

  1. The authormust be able to save and restore profiles that contain the configuration settings required by checkpoints Y.3, Y.4, Y.5, Y.6, Y.7, Y.22, and Y.24.@@
  2. The author must be able to restore the default configuration settings profile.
From_UAAG.22 Ensure that toolbars are configurable. [Priority 3] [Adapted from UAAG 11.7]

Rationale: ???

Techniques:

Success Criteria:

  1. For authoring tools with tool bars:
    • (a) the author must be able to configure the position of controls on those tool bars.
    • (b) a predefined set of controls that may be added to or removed from tool bars must be offered.
    • (c) the author must be able to restore the default tool bar configuration.
From_UAAG.23 Ensure that documentation is accessible. [Priority RP] [Adapted from UAAG 12.1]

Rationale: While intuitive user interface design is valuable to many authors, some authors may still not be able to understand or be able to operate the authoring interface without thorough documentation. For instance, an author with blindness may not find a graphical user interface intuitive without supporting documentation.

Techniques:

Success Criteria:

  1. The authoring tool help system must conform to WCAG.
From_UAAG.24 Document all authoring interface accessibility features. [Priority 1] [adapted from UAAG 12.2, 12.3]

Rationale: Without documentation of the features that make the authoring interface accessible (e.g. keyboard bindings, configuration options, etc.) authors may not find or use them.

Techniques:

Success Criteria:

  1. All features that benefit the accessibility of the authoring interface must be documented in the help system.
  2. Default keyboard bindings must be documented in the help system.
From_UAAG.25 Associate table cells and headers. [Priority 1] [adapted from UAAG 10.1]

Rationale: Without documentation of the features that make the authoring interface accessible (e.g. keyboard bindings, configuration options, etc.) authors may not find or use them.

Techniques:

Success Criteria:

  1. All tables in the authoring interface must be implemented such that, when focus is within any cell in the table, the author is able access associated header information for that cell.