Integrate accessibility solutions into the overall "look and feel"

ATAG Checkpoint 4.1: Ensure that the functionalities for checkpoints 3.1, 3.2 and 4.1 are always clearly available to the user [Priority 1]

• @@No techniques yet.@@

ATAG Checkpoint 4.2: Ensure that accessible authoring practices supporting the minimum level requirements for all WCAG 2.0 [WCAG20] checkpoints are among the most obvious and easily initiated by the author. [Priority 2]

• 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. [T0228]
• Highlight the most accessible authoring solutions or templates when presenting choices for the author. [T0229]

ATAG Checkpoint 4.3: Ensure that all functionality (prompts, checkers, information icons, etc.) related to accessible authoring practices is naturally integrated into the overall look and feel of the tool. [Priority 2]

• Provide a consistent look and feel, but not to the point that product differentiation and improved accessibility functionality are compromised:
  • Provide a common toolkit to design tool functionality modules (so that third party developers can add accessibility features with the same look and feel). [T0425]
  • Ensure that author can utilize the tool's accessible authoring features by the same interaction styles used for other features in the program. For example, if the tool makes use of onscreen symbols such as underlines or coloration change rather than dialogs for conveying information, then the same interface techniques should be used to convey accessibility information. [T0223]
  • The same fonts, text sizes, colors, symbols, etc. that characterize other program features should also characterize those dealing with accessibility. [T0224]
• There should be seamless integration of the accessibility functions into the workflow model of the base tool:
  • The accessibility features should be designed as integral components of the authoring tool application, not components that need to be separately executed. [T0222]
  • Include 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. [T0225]
  • The default settings of the authoring tool should include all accessible content production features enabled (as opposed to accessibility features for the author). The author may have the option to disable these features later on. [T0226]
  • Allow efficient and fast access to accessibility-related settings with as few steps as possible needed to make any changes that will generate accessible content. [T0227]

ATAG Checkpoint 4.4: Ensure that creating accessible content is a naturally integrated part of the documentation, including examples. [Priority 2]

Techniques:

• Ensure all examples conform with WCAG10 (at least to the level that the tool conforms to ATAG), regardless of what the example is meant to show (this will help authors familiarize with the requirements of accessibility). [T0236]
• Provide examples of all WCAG10 accessibility requirements (including priority 2 and 3). [T0235]
• When the help files of a base tool do not meet this checkpoint, accessibility plugins could include updated files and modify the base tool's help index to point to the new files. [T0426]
• When encouraging the author to use accessibility features, take a broad view. For example, do not refer to text equivalents as being "for blind authors" or label them with a "disability" icon. Instead, refer to them as being for "authors who are not viewing images". In addition, emphasize the auxiliary benefits of accessibility features. [T0238]
• When explaining the accessibility issues related to non-deprecated elements, emphasize the solutions rather than explicitly discouraging the use of the element. [T0240]
• For tools that include context sensitive help, implement context-sensitive help for accessibility terms as well as tasks related to accessibility. [T0242]
• For tools that include tutorials, provide a tutorial on checking for and correcting Web accessibility problems. [T0246]
• Include pointers to more information on accessible Web authoring, such as WCAG10 and other accessibility-related resources,
• Include current versions of, or links to relevant language specifications in the documentation. This is particularly relevant for languages that are easily hand edited, such as most XML languages [XML]. [T0245]
• Document the tool's conformance to ATAG 1.0 [ATAG10] and include a link to its ATAG conformance evaluation [T0244]

Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | Appendix A: Prompting | Glossary | References