Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0:

Guideline 4: Promote and integrate accessibility solutions

Working Group Draft DD MMM 2004

This version:: http://www.w3.org/WAI/AU/2004/WD-ATAG20-20040120/tier4
Latest version:: http://www.w3.org/TR/ATAG20/tier4
ATAG 1.0 Recommendation:: http://www.w3.org/TR/ATAG10

Editors of this chapter:: Jutta Treviranus - ATRC, University of Toronto; Jan Richards - ATRC, University of Toronto; Matt May - W3C

Integrate accessibility solutions into the overall "look and feel":

Techniques for checkpoint 4.1: Ensure that accessibility prompting, checking, repair functions and documentation are integrated into the workflow of Web Content development. [Priority 2]
Techniques for checkpoint 4.2: Ensure that the most accessible option for an authoring task is given priority. [Priority 2]
Techniques for checkpoint 4.3: Ensure that accessibility prompting, checking, repair functions and documentation are always clearly available to the author [Priority 1]
Techniques for checkpoint 4.4: Ensure that accessibility prompting, checking, repair functions and documentation are naturally integrated into the appearance and interactive style of the tool. [Priority 3]

Integrate accessibility solutions into the overall "look and feel"

ATAG Checkpoint 4.1: Ensure @@accessible authoring practices @@ @@DELETE THIS that accessibility prompting, checking, repair functions and documentation@@ are integrated into the workflow of Web Content development. [Priority 2]

Techniques for "Success Criteria 1: Any mechanism that guides the author in sequencing authoring actions (e.g. design aids, wizards, documentation @@GP suggestion@@, templates) must integrate @@accessibility - ADDED@@ prompting, checking, repair functions and documentation."

Indirect

Technique 4.1.1: Content generation wizards can include accessibility-related functionality.

Screenshots from a sample accessible wizard showing integration of prompting, checking, repair functions and documentation.

Take something very sequential - e.g. creation of a table - showing prompting as user goes along.

Ex. F1 link to accessiblity help...

Another example, in documentation on creating a form, etc..

@@???@@ Anything general?

We could offer sample wording for persuading authors?

ATAG Checkpoint 4.2: Ensure that the most accessible option for an authoring task is given priority. [Priority 2]

Techniques for "Success Criteria 1: When an authoring action has several @@more than one@@ markup implementations @@(e.g. the color of text can be changed with presentation markup or style sheets) @@ changed by JR@@, those markup implementation(s) that meet the requirements of WCAG must have equal or higher prominence than those markup implementations that do not meet the @@WCAG@@ requirements."

	Technique 4.2.1: If there is more than one option for the author, and one option is more accessible (@@meets WCAG@@) than another, the more accessible option can be given prominence and made the default. Style sheets vs. deprecated `FONT` element for text styling. @@???@@
	~~Technique 4.3.e:~~ ~~Highlight the most accessible authoring solutions or templates when presenting choices for the author.~~
	Technique 4.2.2: Removing less accessible options altogether can simplify the task of meeting this checkpoint.
	@@???@@Different modes?

ATAG Checkpoint 4.3: Ensure that accessibility prompting, checking, repair functions and documentation are always clearly available to the author [Priority 2]

In some cases, several input fields are required to be completed in order to make a single element accessible. Instead of dispersing these prompts over multiple dialog boxes, it may be more effective to draw them together into one group of controls with a visible tab or other method for accessing the group (see Figure A-5). This can have the additional benefit of allowing accessibility-related help information to be provided without confusion (see "Quick Tips" in the figure, below). The downside of placing all the accessibility related input fields in the same area is that all of them will be neglected if the author does not see the grouping.

Techniques for "Success Criteria 1: Continuously active processes (e.g. a checker that underlines errors as they occur, a checker that runs at each save, a checker that runs every 10 minutes, etc.) that implement functions required by checkpoints 3.1, 3.2, 3.3 and 3.7 must be enabled by default."

	Technique 4.3.1: A scheduling interface can be provided.
	Screenshot of scheduling window with options checked.

Techniques for "Success Criteria 2: If the author chooses to disable these continuously active processes, then the tool must inform the author of the consequences of their choice."

	Technique 4.3.2: The tool can inform the user that disabling any continuously active process may cause problems to develop that might not otherwise.
	Screenshot of dialog informing the user of the consequences of this action.

Techniques for "Success Criteria 3: The accessibility-related @@accessibility prompting, checking, repair and documentation@@ must have at least the same prominence as@@ prompting, checking, repair and documentation@@ for other mandatory information in the tool @@(e.g. prompting for file names during saves or checking for and repairing spelling or syntax errors)."@@

	Technique 4.3.3: Considerations for accessibility, such as short text label and long description attributes, can appear on the same dialog as the source attribute, rather than buried behind an "Advanced..." button.
	Technique 4.3.4: Efficient and fast access to accessibility-related settings with as few steps as possible needed to make any changes that will generate accessible content.
	Technique 4.3.5: If a single checker tool is implemented to detect spelling errors and accessibility problems, the design can ensure equal visibility for the accessibility checking component:
	@@???@@

Techniques for "Success Criteria 4: The accessibility-related checking must have at least the same prominence as checking for other high priority information in the tool (e.g. spelling or syntax errors)."

Techniques for "Success Criteria 5: The accessibility-related repairing must have at least the same prominence as repairing for other high priority information in the tool (e.g. spelling or syntax errors)."

Techniques for "Success Criteria 6: The accessibility-related documentation must have at least the same prominence as the other documentation in the tool."

ATAG Checkpoint 4.4: Ensure that accessibility prompting, checking, repair functions and documentation are naturally integrated into the appearance and interactive style of the tool. [Priority 3]

Techniques for "Success Criteria 1: The user interface for accessibility prompting, checking, repair and documentation must be similar to the user interface for comparable functions in terms of the following characteristics: [1] visual design (measured by design metaphors, artistic sophistication, sizes, fonts, colors), [2] operation (measured by degree of automation, number of actions for activation), [3] configurability (measured by number and types of features), and [4] comprehensiveness (measured by breadth and depth of functionality coverage)."

Note: use term "equivalent"

All	Technique 4.4.1: Accessibility-related documentation must be similar to other documentation in the tool.
All	Screenshot of other documentaion; screenshot of accessibility doc Work this up with classifications.
Code	Technique 4.4.2(a): For code-based authoring functions an accessibility prompting mechanism might be comparable to a code syntax prompting mechanism.
Code	Screenshot of syntax prompter; Screenshot of accessibility prompter
WYSIWYG	Technique 4.4.2(b): For WYSIWYG authoring functions, an accessibility checking mechanism might be comparable to a spell checking mechanism.
WYSIWYG	Screenshot of spell checker; Screenshot of accessibility checker
OO	Technique 4.4.2(c): For object oriented authoring functions an accessibility repair mechanism might be comparable to a object manipulation operation.
OO	Screenshot of user grouping controls; Screenshot of user setting label for a form.
Indirect	Technique 4.4.2(d): For indirect authoring functions, an accessibility prompting mechanism might be comparable to a high priority information prompting mechanism.
Indirect	Screenshot of prompter (eg. the name of a course lecturer); Screenshot of accessibility prompter (eg. a label for a picture)
ALL	Technique 4.4.5: A common toolkit can be implemented to help design additional tool functionality modules. This might be used internally or by third party developers to develop accessibility plug-ins with the same look and feel as other parts of the tool.
ALL	Technique 4.4.6: The accessibility features can be designed as integral components of the authoring tool application, not components that need to be separately installed or executed.

3 AXES

4 types of functionality in question (prompting, checking, repairing, documentation)
4 categories of integration
4 types of tool functionality (Code-Level, WYSIWYG, Object Oriented, Indirect)

PLUS what is meant by comparable functions needs to be made clear.

Defined Term: "Prominence" [ed. maybe should be moved to ATAG Glossary]

The "prominence" of a control in the user interface is a heuristic measure of the degree to which users take notice of the control when operating the system. In these guidelines, "prominence" refers to visual as wll as keyboard-dreiven navigation. The factors that contribut to "prominence" include:

Control Size: Larger controls or controls surrounded by more whitespace may appear to be confered higher importance.
Control Order: Without any other forms of organization, most people will read interface items in a "localized" reading order (i.e. left to right and top to bottom; right to left and top to bottom, etc.). The higher visibility of items that occur early in the reading order confers higher apparent importance.
Control Grouping: Grouping input fields (eg. in a vertical list, etc.) can change the reading order and the related judgments of importance.
Advanced Options: When the properties are explicitly or implicitly grouped into sets of basic and advanced properties, the basic properties may gain apparent importance.
Highlighting: Controls may be distinguished from others using icons, color, styling, etc. When these methods are used, it is important to ensure that that they are consistent with the overall look and feel of the authoring tool interface (see Checkpoint 4.4). An additional consideration is that in order to meet ATAG Checkpoint 7.1, the highlighting must be implemented so that it is available through the appropriate API (MSAA, Java Accessibility API, GNOME accessibility, etc.), allowing an author with disabilities to access the highlighting through assistive devices .

Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0: