Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0:

Guideline 4: Integrate accessibility content related features.

Working Group Draft 24 March 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 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, templates) must integrate prompting, checking, repair functions and documentation."

Breakdown by tool type?

	Technique 4.1.1:

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 markup implementations (e.g. changing the color of text with presentation markup or style sheets), 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: Removing less accessible options can simplify the task of meeting this checkpoint.

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

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:
	Screenshot of properties 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:
	Screenshot of dialog informing the user of the consequences of this action..

Techniques for "Success Criteria 3: The accessibility-related prompting must have at least the same prominence as prompting for other mandatory information in the tool (e.g. file name for saving)."

Technique 4.4.5: Considerations for accessibility, such as short text label and long description attributes, on the same dialog as the source attribute, rather than buried behind an "Advanced..." button. (Applies to [b])

Technique 4.4.6: Efficient and fast access to accessibility-related settings with as few steps as possible needed to make any changes that will generate accessible content. (Applies to [b])

"Prominence" should be called out into its own section.

	Technique 4.3.a: Modified Input Field Order: ATAG 2.0 contains ATAG Checkpoint 5.2 does not require that accessibility related controls either obscure or hinder other controls. Instead, the checkpoint emphasizes that these controls should be allotted a screen presence that is appropriate for their importance. For example, some tools have floating properties bars that display input fields appropriate to the currently selected element (see Figure 3.1.2). The relative importance of a property can be communicated to the author in several ways. (Applies to [b]) [@@changed slightly@@] Reading Order: Without any other forms of organization, most people will read interface items in a "localized" reading order (i.e. in English, French, etc. this is left to right and top to bottom). The higher visibility of items that occur early in the reading order confers higher apparent importance. Grouping: Grouping input fields can change the reading order and the related judgments of importance. For example, the "H" field in the figure below, rises in the reading order due to a strong grouping with the "W" field. Advanced Options: When the properties are explicitly or implicitly grouped into sets of basic and advanced properties, the basic properties will gain apparent importance. For example, in the figure, below, the fact that the "alt" field appears in the default properties, rather than the collapsible portion of the properties bar confers visibility and apparent importance.
	Figure 4.1.2: Example of a floating properties bar (top: maximized, bottom: minimized). [d] (Source: Macromedia Dreamweaver 2.0)
	Technique 4.3.b: Input Field Highlighting: Visibility of input fields related to accessibility may be further enhanced by visual highlighting. For example, the fields may be distinguished from others using icons (see Figure A-3), color (see Figure A-4), underlining, 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 (as per ATAG Checkpoint 5.1). For example, if an authoring tool uses an icon in the shape of a black dot to denote the required field, this convention might be extended so that a red dot is used to denote the accessibility-related fields. An additional consideration is that in order to meet ATAG Checkpoint 7.1, the highlighting must be implemented so that it is available through APIs, allowing an author with disabilities to access the highlighting through assistive devices (MSAA, Java Accessibility API, GNOME accessibility).
	Figure 4.1.3(a): Input field highlighting with colored input field. [d] (Source: mockup by AUWG) Figure 4.1.3(b): Input field highlighting with an iconic reference to a note. [d] (Source: mockup by AUWG)
	Technique 4.3.c: Grouping Related Input Fields: 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.
	Figure 4.2.4: Accessibility tab on the `input` element properties dialog. [d] (Source:mockup by AUWG)
	Technique 4.3.d: If there is more than one option for the author, and one option is more accessible than another, place the more accessible option first and make it the default. For example, when the author has selected text to format, the use of CSS should be emphasized rather than deprecated `FONT` element.
	Technique 4.3.e: Highlight the most accessible authoring solutions or templates when presenting choices for the author.

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)."

	Technique 4.3.4: 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 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)."

	Technique 4.3.5:

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

	Technique 4.3.6:

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)."

3 AXES

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

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

ALL	Technique 4.4.1(a): Accessibility prompting can be made similar to prompting for other types of information.
	Screenshot of image properties dialog with missing SRC	Screenshot of image properties dialog with missing ALT-pass:	Screenshot of image properties dialog with missing ALT -fail
Code-level	Technique 4.4.1(b):
	Screenshot of code editor anticipating data type		Screenshot of code editor anticipating ALT attribute
WYSIWYG	Technique 4.4.1(c):
	Screenshot of DW aloowing user to associate a Link with an existing anchor link.	Screenshot of UI to associate a label with an existing form control
Object Oriented	Technique 4.4.1(d):
	Screenshot of object that includes a syntax error	Screenshot of object that includes an accessibility error
Indirect	Technique 4.4.1(e):
	Screenshot of screen asking for some high priority information (eg. the name of a course lecturer)	Screenshot of screen asking for some high priority information (eg. a label for a picture)

ALL	Technique 4.4.2(a): Accessibility checking functions can be made similar to that of spelling or syntax checking.
	Screenshot of spell checker finding a problem	Screenshot of accessibility checker finding a problem - pass	Screenshot of accessibility checker finding a problem - fail
Code-level	Technique 4.4.2(b):
	Screenshot of code editor highlighting syntax error		Screenshot of code editor highlighting access error
WYSIWYG	Technique 4.4.2(c):
	Screenshot of WYSIWYG with red underline for spelling	Screenshot of WYSIWYG with blue underline for accessibility
Object Oriented	Technique 4.4.2(d):

Indirect	Technique 4.4.2(e):

ALL	Technique 4.4.3(a): Accessibility repair functions can be made similar to that of spelling or syntax repair.

Code-level	Technique 4.4.3(b):

WYSIWYG	Technique 4.4.3(c):

Object Oriented	Technique 4.4.3(d):

Indirect	Technique 4.4.3(e):

ALL	Technique 4.4.3: Accessibility documentation functions can be made similar to that of other documentation.

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.

Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0: