Notes:

• These techniques are informative (non-normative). There are no claims made, implicit or explicit, that by following any of the techniques in this document any conformance requirements of the ATAG2.0 WD will be satisfied. Rather, these techniques represent an illustrative sampling of approaches that might be useful in considering the subject of authoring tool accessibility. There may be many other ways a tool might be designed and still meet the normative criteria contained in the success criteria. It should be noted that some techniques are so important to meeting their respective success criteria, that for all practical purposes, the techniques are required. These techniques have been marked with the term "STRONGLY SUGGESTED".
• For purposes of clarity, the techniques are phrased using an imperative voice. Nevertheless, the techniques remain informative (non-normative).

Guideline B.1: Enable the production of accessible content

The creation of accessible content is dependent on the actions of the tool and the author. This guideline delineates the responsibilities that rest exclusively with the tool.

The first responsibility is to support formats that enable accessible content (Checkpoint B.1.1). Web content produced by an authoring tool is most likely to be accessible, if the content is created in accordance with the requirements of WCAG and preserved in that state throughout the authoring process. The checkpoint requirements that accessible or unknown content be preserved (Checkpoint B.1.2), automatically generating accessible content (Checkpoint B.1.3), and including accessible pre-authored content (Checkpoint B.1.4).

• Techniques for checkpoint B.1.1: Support technologies that enable the creation of Web content that conforms toWCAG. [Priority 1]
• Techniques for checkpoint B.1.2: Ensure that the tool preserves all unrecognized markup and accessibility information during transformations and conversions. [Priority 2]
• Techniques for checkpoint B.1.3: Ensure that when the tool automatically generates content it conforms to WCAG. [Web Content Checkpoints Relative to WCAG]
• Techniques for checkpoint B.1.4: Ensure that all pre-authored content for the tool conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

ATAG Checkpoint B.1.1: Support technologies that enable the creation of Web content that conforms to WCAG. [Priority 1].

Rationale: Technologies with published technology-specific WCAG benchmark documents facilitate the creation of Web content that can be assessed for accessibility with WCAG.

Techniques for Success Criteria 1: Any authoring tool that chooses the Web content technology for the author (i.e. a default document markup language) must always choose technologies for which a published technology-specific WCAG benchmark exists.

Technique 2.1.1: When creating documents or markup languages, make full use of W3C Recommendations. For example, use MathML [MathML] for mathematical Web content and XHTML [XHTML], MathML [MathML], and DOM [DOM] scripting to implement dynamic-interactive spreadsheets.

Techniques for Success Criteria 2: Any authoring tool that allows authors to choose the Web content technology must always support at least one technology for which a published technology-specific WCAG benchmark exists and always give prominence to those technologies.

Technique 2.1.2: In some cases a W3C Recommendation formatted version may be offered in addition to a proprietary format. Tools that dynamically generate Web content may use HTTP content negotiation to facilitate this. @@KM should we provide explanation of HTTP content negotiation here? e.g. link to http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html?? Just a thought. Would our audience know this?@@

Technique 2.1.3: Do not publish Web content in markup languages that do not allow for equivalent alternative information to be included for media-specific presentations (such as images, video, sound, etc.). Where this cannot be avoided, make the information directly available from the content generated. For example, convert the text equivalent of an image to a caption for the image, or provide a "base" page that includes links to alternative versions of content.

Technique 2.1.4: Markup languages and formats that become W3C Recommendations after an authoring tool's development cycle permit input are not considered "available" in time. Tool design that is modular can, however, provide for new markup languages and formats to be supported late in the development cycle or even after deployment.@@reworded by KM@@

Technique 2.1.5: Consult the following references:

• W3C maintains a Technical Reports and Publications page of the W3C. @@Is this preferable to annotated list of recs. that we must keep updated? - KM agrees@@
• Language specific accessibility notes: CSS [CSS-ACCESS], SMIL [SMIL-ACCESS], HTML4 [HTML4-ACCESS], SVG [SVG-ACCESS], XML languages [XML-ACCESS].

ATAG checkpoint B.1.2: Ensure that the tool preserves all unrecognized markup and accessibility information during transformations and conversions. [Priority 2]

Rationale: Unrecognized markup may include recent technologies that have been added to enhance accessibility and should be preserved during conversions or transformations. Accessibility information should also be preserved.

Techniques for Success Criteria 1: All transformations and conversions supported by the authoring tool must always meet both of the following conditions:

Technique 2.2.2: This checkpoint covers systems that reconstitute documents into standardized formats. @@KM rewording@@

(a) the author is notified before any unrecognized markup is permanently removed.

Technique 2.2.1: If possible, preserve all unrecognized markup, since it might be related to accessibility (See Techniques for ATAG Checkpoint 3.2).

(b) all accessibility information is handled according to at least one of the following:

Technique 2.2.3: Ensure that the tool preserves all the elements and attributes defined in the relevant specification(s) even if it is unable to render them in a preview mode. @@KM rewording@@

(i) be preserved in the target format such that the information can be "round-tripped" (i.e. converted or transformed back into its original form) by the same authoring tool.

(ii) be preserved in some other way in the target format.

(iii) be removed only after the author has been notified and the content has been preserved in its original format.

Technique 2.2.4: Allow authors to edit document conversion templates to specify the way presentation conventions should be converted into structural markup. @@from ATAG1 4.3@@

Technique 2.2.5: Best practices for conversion include the following examples: @@KM rewording@@

• Avoid transforming text into images. Use style sheets for presentation control, or use an XML application such as Scalable Vector Graphics [SVG] that keeps the text as text. If this is not possible, ensure that the text is available as equivalent text for the image.
• When importing images with associated descriptions into a markup document, make the descriptions available through appropriate markup.
• When transforming a table to a list or list of lists, ensure that table headings are transformed into headings and that summary or caption information is retained as rendered content.
• When converting linked elements (i.e. footnotes, endnotes, call-outs, annotations, references, etc.) provide them as inline content or maintain two-way linking.
• When converting from an unstructured word-processor format to markup, ensure that headings and list items are transformed into appropriate structural markup (appropriate level of heading or type of list, etc.).
• When generating a natural language translation of text, produce the simplest and clearest possible @@version of the text-Liddy@@ use of the new language. @@CMN Proposal-LN believes this needs more clarification@@ @@KM agree that clarification is needed.

Techniques for Success Criteria 2: When accessibility information cannot be preserved during a conversion or transformation, the author must notified beforehand.

@@These can be collapsed into just a few techs@@

Technique 2.2.6: Inform the author if [@@] changes to markup that is not recognized by the tool are necessary for the tool to further process the document (for example, a tool that requires valid markup when a document is opened).

Technique 2.2.7: Allow the author to decide whether or not to preserve unrecognized markup (since it might be related to accessibility). @@from ATAG1 4.3@@

Technique 2.4.6:If markup that is not recognized by the tool needs changing (for example, a tool that requires valid markup when a document is opened), inform the author of the changes[@@]. @@from ATAG1 4.3@@KM

Technique 2.2.8:Provide options for the author to confirm or override removal of markup either [@@]on a change-by-change basis or as a batch process. @@from ATAG1 4.3@@

Technique 2.2.9:Do not change the DTD without notifying the author. @@from ATAG1 4.3@@

Technique 2.2.10: Provide the author with explanations of automatic changes made by the tool[@@]. @@F2F Proposal@@

Technique 2.4.11:Ensure that changes to a document's graphical layout do not reduce readability when the document is [@@] rendered serially. For example, confirm the linearized reading order with the author.

ATAG Checkpoint B.1.3: Ensure that when the tool automatically generates content it conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

Rationale: Authoring tools that automatically generate content that does not conform to WCAG are an obvious source of accessibility problems.

@@Term "authored Unit" from WCAG could help here.@@

Techniques for Success Criteria 1: All markup and content that is automatically generated (in formats for which there is a published WCAG techniques documents for meeting each WCAG checkpoint) by the authoring tool (i.e. not authored "by hand") must always conform to WCAG.

Technique 2.3.1: Ensure that when the tool automatically generates content and markup @@Does this cover content other than tagging?-Liddy@@ (e.g. the author has not specifically specified the markup to be used), that markup conforms to the relevant WCAG checkpoints. These include checkpoints that involve the inclusion of equivalent alternative information. See restrictions on automatically generating equivalent alternatives and the techniques for prompting guidance. [STRONGLY SUGGESTED] @@KM should we provide the actual hyperlinks here?@@

ATAG Checkpoint B.1.4 : Ensure that all pre-authored content for the tool conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

Rationale: Pre-authored content (e.g. templates, images, videos) is often included with authoring tools for the convenience of the author. When this content is WCAG-conformant, it is more convenient for authors and more easily reused.

Note: Pre-authored content refers to markup content, images, multimedia, applets, scripts, etc. Including pre-written descriptions for all multimedia files (e.g., clip-art) packaged with the tool will save authors time and effort, cause a significant number of professionally written descriptions to circulate on the Web, provide authors with convenient models to emulate when they write their own descriptions, show authors the importance of description writing, and encourage good authoring practices.@@KM rewording@@

Techniques for Success Criteria 1: Any authoring tool that provides Web content (e.g. templates, clip art, example pages, etc.) that is bundled with the authoring tool or preferentially licensed (i.e. provided for free or sold at a discount) to the users of the authoring tool (as compared to non-users of that tool), then all of that Web content must always conform to WCAG.

Technique 2.4.1: For tools that allow authors to create their own templates, advise the author that templates should be held to a high accessibility standard, since they will be repeatedly reused. Help the author reach this goal by making an accessibility check mandatory before saving as a template.@@KM perhaps make cross-ref to appropriate checkpoint in guideline 3, maybe 4 (about checking, etc.)? @@

Technique 2.4.2: Provide pre-authored content in formats that allow for accessible annotation to be included in the files, such as SMIL [SMIL], PNG [PNG], and SVG [SVG].

Technique 2.4.3: Ensure that all pre-authored content provided by the tool conforms to the relevant WCAG checkpoints.

Technique 2.4.4: Make use of accessible templates. Examples: Template 1: Home page, Template 2: News and events page, Template 3: About page, Stylesheet: Used by sample templates. @@KM I understand the first sentence, but not the examples.@@

Technique 2.4.5: Ensure equivalent alternatives provided for pre-authored content are inter-operable with functionality for managing, editing, and reusing equivalent alternatives (see checkpoint 3.5). @@NEW@@

Guideline B.2: Support the author in the production of accessible content

Actions may be taken at the author's initiative that may result in accessibility problems. The authoring tool should include features that provide support and guidance to the author in these situations, so that accessible authoring practices can be followed and accessible web content can be produced.

This support includes prompting and assisting the author to create accessible web content (Checkpoint 3.1), especially for information that cannot be generated automatically, checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3). In performing these functions, the authoring tool must avoid including automatically generated equivalent alternatives or previously authored equivalent alternatives without author consent (Checkpoint 3.4). The authoring tool may also provide automated means for managing equivalent alternatives (Checkpoint 3.5) and provide accessibility status summaries (Checkpoint 3.6).

Accessibility-related documentation provides support and guidance to the author. The documentation must accommodate the various levels of author familiarity with web content accessibility issues. The checkpoint requirements include documenting accessible content promoting features (Checkpoint 3.7), and ensuring that documentation demonstrates authoring practices (Checkpoint 3.8) and workflow processes that result in accessible content (Checkpoint 3.9).

• Techniques for checkpoint B.2.1: Prompt and assist the author to create content that conforms to WCAG. [Web Content Checkpoints Relative to WCAG]
• Techniques for checkpoint B.2.2: Check for and inform the author of accessibility problems. [Web Content Checkpoints Relative to WCAG]
• Techniques for checkpoint B.2.3: Assist authors in repairing accessibility problems. [Web Content Checkpoints Relative to WCAG]
• Techniques for checkpoint B.2.4: Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]
• Techniques for checkpoint B.2.5: Provide functionality for managing, editing, and reusing alternative equivalents. [Priority 3]
• Techniques for checkpoint B.2.6: Provide the author with a summary of accessibility status. [Priority 3]
• Techniques for checkpoint B.2.7: Document all features of the tool that support the production of accessible content. [Priority 2]
• Techniques for checkpoint B.2.8: Ensure that accessibility is modeled in all documentation and help, including examples. [Priority 3]
• Techniques for checkpoint B.2.9: Provide a tutorial on the process of accessible authoring. [Priority 3]

@@BF: prompting for accessibility localization@@

@@we must ensure accessibility of examples (i.e. that they meet GL1)@@

@@more help designing well - e.g. alternatives to image maps@@

ATAG Checkpoint B.2.1: Prompt and assist the author to create content that conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

Rationale: Appropriate assistance should increase the likelihood that typical authors will create WCAG-conformant content. Different tool developers will accomplish this goal in ways that are appropriate to their products, processes, and authors.

Executive Summary of Techniques:

In some authoring situations it may be necessary to prompt (see clarification) or assist (e.g. task automation, entry storage, etc.) authors to follow accessible authoring practices. This is especially true of accessibility problems that require human judgment to remedy, such as adding descriptions to images. In general, it is preferable to begin guiding the author towards the production of accessible content before accessibility problems have actually been introduced. Postponing checking (checkpoint 3.2) and correcting (checkpoint 3.3) may leave the author uninformed of accessibility problems for so long that when the author is finally informed, the full weight of the accumulated problems may be overwhelming.

When information is required of the author, it is crucial that that information be correct and complete. This is most likely to occur if the author has been convinced to provide the information voluntarily. Therefore, overly restrictive mechanisms are not recommended for meeting this checkpoint.

Techniques for Success Criteria 1: When the actions of the author risk creating Web content that is not accessible (i.e. fails to meet the Web content checkpoints requirements to Level 1, 2, or 3) (e.g. image inserted, author typing invalid element into a code view, author initiating a page creation wizard, etc.), the tool must introduce the appropriate accessible authoring practice.

Technique 3.1.1: Use an appropriate prompting and assisting mechanism

3.1.1(1): Prompting and assisting for short text labels (e.g. alternate text, titles, short text metadata fields, rubies for ideograms):

• (a) Prompts for short text strings may be afforded relatively little screen real estate because they are usually intended to elicit entries of ten words or less. @@rewording@@
• (b) Provide a rendered view of the object for the author to examine while composing the label.@@rewording@@
• (c) Implement automated routines to detect and offer labels for objects serving special functions (e.g. "decorative", "button", "spacer", "horizontal rule", etc.).@@rewording@@
• (d) Use editable text entry boxes with drop-down lists to accommodate new text entry as well as the option to select from reusable or special function label text (see Example 3.1.1(1a)). @@rewording@@
• (e) In code-based tools, prompt the author with short text labels combined with the appropriate markup (see Example 3.1.1(1b)).

Example 3.1.1(1a): This illustration shows an authoring interface for description reuse. It is comprised of a drop-down list that is shown with several short labels for the same image. Notice that one of the labels in the list is in a different language (i.e. French). The author must be able to create a new label, if the stored strings are not appropriate. (Source: mockup by AUWG)
[longdesc missing]

Example 3.1.1(1b): This illustration shows a code-based authoring interface for short text label prompting. The drop-down menu was triggered when the author typed quotation marks (") to close the href attribute. (Source: mockup by AUWG)
[longdesc missing]

3.1.1(2): Prompting and assisting for multiple text labels (e.g. image map area labels):

• (a) Prompts for image map text labels may be similar to those for short text labels with allowance made for rapidly adding several labels for one image map. (see Example 3.1.1(2))
• (b) Provide a preview of the image map areas.@@rewording@@
• (c) Provide the URI of image map areas.@@rewording@@
• (d) Offer to automatically generate a set of plain text links from the labels. @@rewording@@

Example 3.1.1(2): This illustration shows an authoring interface for image map area text label prompting. It is comprised of a list with two columns. In the right-hand column is the URL for each image map area. This can be used as a hint by the author as they fill in the text labels (left-hand column). A checkbox at the bottom provides the option of using the text labels to create a set of text links below the image map. (Source: mockup by AUWG)
[longdesc missing]

3.1.1(3): Prompting and assisting for long text descriptions (e.g. longdesc text, table summaries, site information, long text metadata fields):

• (a) Begin by prompting the author about whether the inserted object is adequately described with an existing short text label. Providing a "no images" view of the page may help the author decide. (see Example 3.1.1(3))@@rewording@@
• (b) If the short description is inadequate, prompt the author for the location of a pre-existing description.@@rewording@@
• (c) If the author needs to create a description, provide a special writing utility that includes a rendered view of the object and description writing advice.@@rewording@@
• (d) Implement automated routines that detect and ignore some objects that do not require long text descriptions (e.g. bullets, spacers, horizontal rules).@@rewording@@

Example 3.1.1(3): This illustration shows an authoring interface for long text description prompting. A "description required" checkbox controls whether the rest of the interface is available. If a description is required, the author then has the choice of opening an existing description file or writing (and saving) a new one. (Source: mockup by AUWG)
[longdesc missing]

3.1.1(4): Prompting and assisting for form field labels:

• (a) Present the form fields and ask the author to select text that is serving as a label or to enter a new label. (see Example 3.1.1(4))
• (b) Alert authors to form fields that are missing labels.

Example 3.1.1(4): This illustration shows a form properties list that allows the author to simultaneously decide the field labels, tab order, form field place holders, and accesskeys. In this example, two form field labels are missing, causing prompts to be displayed. (Source: mockup by AUWG)
[longdesc missing]

3.1.1(5): Prompting and assisting for form field place-holders:

• (a) Prompts for form field place-holders may be similar to those for short text labels.
• (b) Provide authors with the option of directly selecting nearby text strings that are serving implicitly as labels.

3.1.1(6): Prompting and assisting for TAB order sequence:

• (a) Provide the author with a numbering tool that they can use to select controls to create a TAB preferred sequence. (See Example 3.1.1(6))@@rewording@@
• (b) Where there are only a few links that change in each page of a collection, ask the author to confirm whether these links receive focus first. If so, then the tool can appropriately update the tabindex order.@@rewording@@
• (c) Provide a list of links and controls to check the TAB order.

Example 3.1.1(6): This illustration two views of a "Set TAB Order" utility that lets the author visualize and adjust the TAB order of a document: as a mouse-driven graphical overlay on the screen and as a keyboard accessible list.@@new after Copenhagen F2F@@
[longdesc missing]

3.1.1(7): Prompting and assisting for navigational shortcuts (e.g. keyboard shortcuts, skip links, voice commands, etc.):

• (a) Prompt authors to add skip over navigation links for sets of common navigation links. (see Example 3.1.1(7a))@@new@@
• (b) Prompt authors with a list of links that are candidates for accesskeys because they are common to a number of pages in a site.@@rewording@@
• (c) Manage accesskey lists to ensure consistency across sites and to prevent conflicts within pages.(See Example 3.1.1(7b))@@rewording@@

Example 3.1.1(7a): This illustration shows a mechanism that detects repeating navigation elements and asks the author whether they want to add a skip navigation link (Source: mockup by AUWG)@@new after Copenhagen F2F@@

Example 3.1.1(7b): This illustration shows a code-based authoring interface suggesting accesskey values. Notice that the system suggests "m" because it is the first letter of the link text ("moon"). The letter "c" does not appear in the list because it is already used as an accesskey later in the document (for the link "camera"). (Source: mockup by AUWG)
[longdesc missing]

3.1.1(8): Prompting and assisting for contrasting colors:

• (a) Assemble color palettes with insufficiently contrasting colors excluded (see Example 3.1.1(8)) or identified.
• (b) Provide gray scale and black and white views or suggest the author activate the system operating system high contrast mode.
• (c) Emphasize Web-safe colors. @@???@@

Example 3.1.1(8): This illustration shows an authoring interface for choosing a text color. The palette has been pre-screened so that sufficient contrast between the text and the current background color is assured. Color codes entered manually are also screened. (Source: mockup by AUWG)
[longdesc missing]

3.1.1(9): Prompting and assisting for alternative resources for multimedia (transcripts, captions, video transcripts, audio descriptions, signed translations, still images, etc.):

• (a) Prompt the author for the location of a pre-existing alternative resources for multimedia (see Example 3.1.1(9)).@@rewording@@
• (b) Although producing alternative resource for multimedia can be a complex process for long media files, production suites do exist or authoring tools can include simple utilities, with built-in media players, for producing simple alternative resources.
• (c) The tool should be able to access alternative resources for multimedia, which may be incorporated into existing media or exist separately.

Example 3.1.1(9): This illustration shows an authoring interface for embedding a video. The tool automatically detects whether captions, video transcript, audio descriptions, signed translations and a still image are available for the video. When an item is not found, the author has the option to locate the material or launch an authoring utility. (Source: mockup by AUWG)
[longdesc missing]

3.1.1(10): Prompting and assisting for Metadata: @@open work item assigned to JT/JR,LN@@

• (a) For metadata information fields requiring information similar to that discussed in the other sections of this technique, see the relevant section. For example: short text labels (3.1.1(1)), long text descriptions (3.1.1(3)), and alternative resources for multimedia(3.1.1(9)). @@jr added@@
• (b) When prompting for terms in a controlled vocabulary, allow the author to choose from lists to prevent spelling errors.
• (c) Provide the option of automating the insertion of information that easily stored and reused (e.g. author name, author organization, date, etc.).
• (d) Automate metadata discovery where possible.
• (e) Provide the option of storing licensing conditions within metadata. (See, for example, the Creative Commons licenses [CREATIVE-COMMONS], or the GPL [GPL], LGPL [LGPL], BSD [BSD], and other software licenses)
• (f) Publish accessibility status of content as EARL [EARL] to facilitate correction by third party repair tools.
• (g) Consider characterizing accessibility of content using IMS AccessForAll Meta-data Specification [IMS-ACCMD]<http://www.imsproject.org/accessibility/index.cfm#version1pd> to facilitate personalized content delivery.
• (h) Consult the following references: ???

3.1.1(11): Prompting and assisting for document structure:

• Alert the author to the occurrence of unstructured content in a way that is appropriate to the workflow of the tool. (see Checkpoint 4.3).
• Provide the author with options for creating new content that is structured, such as:
  • templates (with pre-defined structure),
  • wizards (that introduce structure to content through a series of system-generated queries), or
  • real time validators (that may be set by the author to prevent the creation of improperly structured content)
• Provide the author with options for imposing structure on existing unstructured content.
  • For tools that support explicit structural mechanisms offer authors the opportunity to use those mechanisms. For example, for DTD or schema based structures, provide validation in accordance to the applicable DTD or schema.
  • For tools that do not support explicit structural mechanisms, offer authors the option of deriving structure from format styles. For example, provide authors a mechanism to map presentation markup that follows formatting conventions into structural elements. For example, patterns of text formatting may be interpreted as headings (see Example 3.1.1(11)) and multiple lines of text beginning items with certain typographical symbols, such as "*" or "-", may be interpreted as list items.
• Provide structure-based editing features, such as:
  • hide/show content blocks according to structure,
  • shift content blocks up, down, and sideways through the document structure, or
  • hierarchical representation or network diagram view of the document structure, as appropriate.
• Provide fully automated checking (validation) for structure.
• Provide fully automated or semi-automated repair for structure.
• It is not necessary to prohibit editing in an unstructured mode. However, the tool should alert authors to the fact that they are working in an unstructured mode.

Example 3.1.1(11): This illustration shows a tool that detects opportunities for enhancing structure and alerts the author. (Source: mockup by AUWG)
[longdesc missing]

3.1.1(12): Prompting and assisting for tabular structure:

• (a) Prompt the author to identify tables as used for layout or data or implement automated detection mechanisms. @@rewording@@
• (b) Differentiate utilities for table structure from utilities for document layout - use this when tables are identified as being for layout. [STRONGLY SUGGESTED]
• (c) Prompt the author to provide header information.(see Example 3.1.1(12))@@rewording@@
• (d) Prompt the author to group and split columns, rows, or blocks of cells that are related.@@rewording@@
• (e) Provide the author with a linearized view of tables (as tablin does).@@rewording@@

Example 3.1.1(12): This illustration shows a tool that prompts the author about whether the top row of a table is a row of table headers. (Source: mockup by AUWG)
[longdesc missing]

3.1.1(13): Prompting and assisting for style sheets:

• (a) Use style sheets, according to specification, as the default mechanism for presentation formatting and layout.
• (b) If content is created with a style sheet format, along with a content format, the use of that style format must also meet the requirements of WCAG. [STRONGLY SUGGESTED]
• (c) Conceal the technical details of style sheet usage to a similar degree as for usage of other markup formats supported by the tool.
• (d) Assist the author by detecting structural markup (e.g. header tags, etc.) that has been misused to achieve presentation formatting and, with author permission, transforming it to use style sheets. See also 3.1.1(11) for information on transforming misused style sheets into structural markup. (see Example 3.1.1(13a))
• (e) Prompt the author to create style classes and rules within and across document, rather than using more limited in-line styling.
• (f) Assist the author by recognizing patterns in style sheet use and converting them into style classes and rules.
• (g) Provide the option of editing text content independently of style sheet layout and presentation formatting. (See example 3.1.1(13b))
• (h) Assist the author with the issue of style sheet browser compatibility by guiding them towards standard practices and detecting the existence of non-standard practices.
• (i) Assist the author by providing a style sheet validation function.
• (j) Maintain a registry of styles for ease of re-use.
• (k) For prompting and assisting with specific types of information required by style sheets, see the other sections in this technique. For example: font/background colors (3.1.1(8)) and document structure (3.1.1(12)).
• (l) Consult the following references: Accessibility Features of CSS [CSS Access], CSS2.1 specification [CSS21], and XML Accessibility Guidelines [XML Access].

Example 3.1.1(13a): This illustration shows a prompt that indicates that a heading has been misused to indicate emphasis. Use of style sheets is suggested instead and a list of styles already used in the document is provided. (Source: mockup by AUWG)

Example 3.1.1(13b): This illustration shows a control panel that lets the author decide what style sheet formating will be displaced in the WYSIWYG view of the content. (Source: mockup by AUWG)

3.1.1(14): Prompting and assisting for clearly written text:

• (a) Prompt the author to specify a default language of a document. @@rewording@@
• (b) Provide a thesaurus function.@@rewording@@
• (c) Provide a dictionary lookup system that can recognize changes of language, terms outside a controlled vocabulary as well as known abbreviation or acronym expansions.@@rewording@@
• (d) Provide an automated reading level status. (see Example 3.1.1(14a))@@rewording@@
• (e) Prompt the author for expansions of unknown acronyms, recognizable in some languages as collections of uppercase letters. (see Example 3.1.1(14b))@@rewording@@

Example 3.1.1(14a): This illustration shows an authoring interface that indicates the reading level of a page and whether it exceeds a limit determined by the author's preference settings. (Source: mockup by AUWG)
[longdesc missing]

Example 3.1.1(14b): This illustration shows an authoring interface that prompts the author to enter an acronym expansion. (Source: mockup by AUWG)
[longdesc missing]

3.1.1(15): Prompting and assisting for device independent handlers:

• (a) During code development, prompt the author to include device-independent means of activation.
• (b) Prompt authors to use device-independent events (e.g., DOM 2 onactivate [DOM]) instead of device-specific events (e.g., onclick), or route multiple events (onclick and onkeypress) through the same functions.
• (c) Prompt authors to add a DOM onfocus event to elements that are targeted with the onmouseover event.
• (d) Prompt authors about using events for which no common device-independent analogue exists (e.g. ondblclick) and avoid these events as default options.

3.1.1(16): Prompting and assisting for non-text supplements to text:

• (a) Prompt the author to provide icons for buttons, illustrations for text, graphs for numeric comparisons, etc. (see Example 3.1.1(16)) @@rewording@@
• (b) Where subject metadata is available, look up appropriate illustrations.@@rewording@@
• (c) If the author has identified content as instructions then provide templates or automated utilities for extracting flow charts, etc.@@rewording@@

Example 3.1.1(16): This illustration shows an authoring interface for prompting the author about whether a paragraph that contains many numbers might be made more clear with the addition of a chart or graph. (Source: mockup by AUWG)
[longdesc missing]

3.1.1(17): Prompting and assisting the author to make use of up to date formats:

• (a) Default to the most up to date formats available whenever the author has not specified a format.
• (b) Give up to date formats a higher prominence during format selection.
• (c) Provide tools that convert content in older formats into more up to date formats.
• (d) Fully or partially automate some of the more complex aspects of more up to date formats, including document structure (see 3.1.1(11)) and use of style sheets (see 3.1.1(13)).

Note: The preceding list is meant to cover techniques of prompting and assisting for many, but not all, of the most common accessible authoring practices.

• (a) Form-based alternatives to irregular image map shapes (e.g. for a geographic map the input might be used to look up latitude and longitude of a point). @@rewording@@
• (b) Server-side alternatives for essential client-side scripts and applets. @@rewording@@
• (c) Links that skip over objects that may permanently capture the tab focus in some user agents. @@rewording@@
• (d) Noframes sections for framesets. @@rewording@@
• (e) When frames are used for a mosaic of images, allow inclusion of markup files (with images embedded) rather than images directly.
• (f) Warn the author about adjacent links.

Technique 3.1.2: Check all textual entries for spelling, grammar, and reading level (where applicable). @@NEW@@

Technique 3.1.3: Share non-text equivalents between authors (where applicable).@@NEW -could this be added to checkpoint 3.5?@@

Technique 3.1.4:

Technique 3.1.3: Provide multiple preview modes and a warning to authors that there are many other less predictable ways in which a page may be presented (aurally, text-only, text with pictures separately, on a small screen, on a large screen, etc.). Some possible document views include: @@rewording@@

• an alternative content view (with images and other multimedia replace by any alternative content)
• a monochrome view (to test contrast)
• a collapsible structure-only view
• no scripts view
• no frames view
• no style sheet view

Example 3.1.2: This illustration shows a WYSIWYG authoring interface with a list of rendering options displayed. The options include "All" (i.e. render as in a generic browser), "text-only" (i.e. non-text items replaced by textual equivalents), "no styles", "no frames", and "grayscale" (used to check for sufficient contrast). (Source: mockup by AUWG)
[longdesc missing]

ATAG Checkpoint B.2.2: Check for and inform the author of accessibility problems. [Web Content Checkpoints Relative to WCAG]

Executive Summary:

Despite prompting assistance from the tool (see Checkpoint 3.1), accessibility problems may still be introduced. For example, the author may cause accessibility problems by hand coding or by opening content with existing accessibility problems for editing. In these cases, the prompting and assistance mechanisms that operate when markup is added or edited (i.e. insertion dialogs and property windows) must be backed up by a more general checking system that can detect and alert the author to problems anywhere within the content (e.g. attribute, element, programmatic object, etc.). It is preferable that this checking mechanisms be well integrated with correction mechanisms (see Checkpoint 3.3), so that when the checking system detects a problem and informs the author, the tool immediately offer assistance to the author.

Techniques for Success Criteria 1: The authoring tool must always provide a check (automated check, semi-automated check or manual check) for each applicable requirement to conform to WCAG.

Technique 3.2.1: Automate as much checking as possible. Where necessary provide semi-automated checking. Where neither of these options is reliable, provide manual checking.

(a) Automated: In automated checking, the tool is able to check for accessibility problems automatically, with no human intervention required. This type of check is usually appropriate for checks of a syntactic nature, such as the use of deprecated elements or a missing attribute, in which the meaning of text or images does not play a role.

Example 3.2.1(a): This illustration shows a summary interface for a code-based authoring tool that displays the results of an automated check. (Source: mockup by AUWG)
[longdesc missing]

Example 3.2.1(b): This illustration shows an interface that displays the results of an automated check in a WYSIWYG authoring view using blue squiggly highlighting around or under rendered elements, identifying accessibility problems for the author to correct. (Source: mockup by AUWG)
[longdesc missing]

Example 3.2.1(c): This illustration shows an authoring interface of an automated check in a code-level authoring view. In this view, the text of elements with accessibility problems is shown in a blue font, instead of the default black font. (Source: mockup by AUWG)
[longdesc missing]

(b) Semi-Automated: In semi-automated checking, the tool is able to identify potential problems, but still requires human judgment by the author to make a final decision on whether an actual problem exists. Semi-automated checks are usually most appropriate for problems that are semantic in nature, such as descriptions of non-text objects, as opposed to purely syntactic problems, such as missing attributes, that lend themselves more readily to full automation.

Example 3.2.1(d): This illustration shows a dialog box that appears once the tool has detected an image without a description attribute. However, since not all images require description, the author is prompted to make the final decision. The author can confirm the at this is indeed an accessibility problem and move on to the repair stage by choosing "Yes". (Source: mockup by AUWG)
[longdesc missing]

(c) Manual: In manual checking, the tool provides the author with instructions for detecting a problem, but does not automate the task of detecting the problem in any meaningful way. As a result, the author must decide on their own whether or not a problem exists. Manual checks are discouraged because they are prone to human error, especially when the type of problem in question may be easily detected by a more automated utility, such as an element missing a particular attribute.

Example 3.2.1(e): This illustration shows a dialog box that reminds the author to check if there are any words in other languages in the document. The author can move on to the repair stage by pressing "Yes". (Source: mockup by AUWG)
[longdesc missing]

Technique 3.2.2: Consult the Techniques For Accessibility Evaluation and Repair Tools [WAI-ER @@change to AERT@@] Public Working Draft for evaluation and repair algorithms related to WCAG 1.0. @@rewording@@

Techniques for Success Criteria 2: The authoring tool must inform the author to any failed check results prior to completion of authoring.

@@???@@

ATAG Checkpoint B.2.3: Assist authors in repairing accessibility problems. [Web Content Checkpoints Relative to WCAG]

Executive Summary:

Once a problem has been detected by the author or, preferably by the tool (see Checkpoint 3.2), the tool may assist the author to correct the problem. As with accessibility checking, the extent to which accessibility correction can be automated depends on the nature of the particular problems. Some repairs are easily automated, whereas others that require human judgment may be semi-automated at best.

Techniques for Success Criteria 1: The authoring tool must always provide a repair (automated repair, semi-automated repair or manual repair) for each applicable requirement to conform to WCAG.

Technique 3.3.1: Automate as much repairing as possible. Where necessary provide semi-automated repairing. Where neither of these options is reliable, provide manual repairing.

(a) Automated: In automated tools, the tool is able to make repairs automatically, with no author input required. For example, a tool may be capable of automatically adding a document type to the header of a file that lacks this information. In these cases, very little, if any, author notification is required. This type of repair is usually appropriate for corrections of a syntactic or repetitive nature.

Example 3.3.1(a): This illustration shows a sample of an announcement that an automated repair has been completed. An "undo " button is provided in case the author wishes to reverse the operation. In some cases, automated repairs might be completed with no author notification at all. (Source: mockup by AUWG)
[longdesc missing]

(b) Semi-Automated: In semi-automated repairing, the tool can provide some automated assistance to the author in performing corrections, but the author's input is still required before the repair can be complete. For example, the tool may prompt the author for a plain text string, but then be capable of handling all the markup required to add the text string to the content. In other cases, the tool may be able to narrow the choice of repair options, but still rely on the author to make the final selection. This type of repair is usually appropriate for corrections of a semantic nature.

Example 3.3.1(b): This illustration shows a sample of a semi-automated repair in a WYSIWYG editor. The author has right-clicked on an image highlighted by the automated checker system. The author must then decide whether the label text that the tool suggests is appropriate. Whichever option the author chooses, the tool will handle the details of updating the content. (Source: mockup by AUWG)
[longdesc missing]

3. Manual: In manual repairing, the tool provides the author with instructions for making the necessary correction, but does not automate the task in any substantial way. For example, the tool may move the cursor to start of the problem, but since this is not a substantial automation, the repair would still be considered "manual". Manual correction tools leave it up to the author to follow the instructions and make the repair by themselves. This is the most time consuming option for authors and allows the most opportunity for human error.

Example 3.3.1(c): This illustration shows a sample manual repair. The problems have already been detected in the checking step and the selected offending elements in a code view have been highlighted. However, when it comes to repairing the problem, the only assistance that the tool provides is a context sensitive hint. The author is left to make sense of the hint and perform the repair without any automated assistance. (Source: mockup by AUWG)
[longdesc missing]

Technique 3.3.2: Implement a special-purpose correcting interface where appropriate. When problems require some human judgment, the simplest solution is often to display the property editing mechanism for the offending element. This has the advantage that the author is already somewhat familiar with the interface. However, this practice suffers from the drawback that it does not necessarily focus the author's attention on the dialog control(s) that are relevant to the required correction. Another option is to display a special-purpose correction utility that includes only the input field(s) for the information currently required. A further advantage of this approach is that additional information and tips that the author may require in order to properly provide the requested information can be easily added. Notice that in the figure, a drop-down edit box has been used for the short text label field. This technique might be used to allow the author to select from text strings used previously for the alt-text of this image (see ATAG Checkpoint 3.5 for more).

Example 3.3.2: This illustration shows a sample of a special-purpose correction interface. The tool supports the author's repair task by providing a description of the problem, a preview (in this case of the image missing a label), tips for performing the repair, possible repair options (archived from previous repairs), and other information (in this case the name of the image file). (Source: mockup by AUWG)
[longdesc missing]

Technique 3.3.3: Checks can be automatically sequenced. In cases where there are likely to be many accessibility problems, it may be useful to implement a checking utility that presents accessibility problems and repair options in a sequential manner. This may take a form similar to a configuration wizard or a spell checker (see Figure 3.3.5). In the case of a wizard, a complex interaction is broken down into a series of simple sequential steps that the author can complete one at a time. The later steps can then be updated "on-the-fly" to take into account the information provided by the author in earlier steps. A checker is a special case of a wizard in which the number of detected errors determines the number of steps. For example, word processors have checkers that display all the spelling problems one at a time in a standard template with places for the misspelled word, a list of suggested words, and "change to" word. The author also has correcting options, some of which can store responses to affect how the same situation can be handled later. In an accessibility problem checker, sequential prompting is an efficient way of correcting problems. However, because of the wide range of problems the checker needs to handle (i.e. missing text, missing structural information, improper use of color, etc.), the interface template will need to be even more flexible than that of a spell checker. Nevertheless, the template is still likely to include areas for identifying the problem (WYSIWYG or code-based according to the tool), suggesting multiple solutions, and choosing between or creating new solutions. In addition, the dialog may include context-sensitive instructive text to help the author with the current correction.

@@TB: Author should know what is the sequencing criteria@@

Example 3.3.3: This illustration shows an example of a sequential accessibility checker, the special-purpose correction interface from Example 3.3.2 is supplemented with navigational controls for moving backwards and forwards through the list of repair tasks. (Source: mockup by AUWG)
[longdesc missing]

Technique 3.3.5: Where a tool is able to detect site-wide errors, allow the author to make site-wide corrections. This should not be used for equivalent alternatives when the function is not known with certainty (see ATAG Checkpoint 3.4).

Technique 3.3.6: Provide a mechanism for authors to navigate sequentially among uncorrected accessibility errors. This allows the author to quickly scan accessibility problems in context.

Technique 3.3.7: Consult the Techniques For Accessibility Evaluation and Repair Tools [WAI-ER @@change to AERT@@] Public Working Draft document for evaluation and repair algorithms related to WCAG 1.0.@@rewording@@

Techniques for Success Criteria 2: For accessibility problems for which an authoring tool provides only manual repairs, the repair instructions must be directly linked from the corresponding check.

@@???@@

ATAG Checkpoint B.2.4: Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]

Techniques for Success Criteria 1: When the author inserts an unrecognized non-text object (the recognition criteria is left unspecified), the tool must not insert an automatically generated text equivalent (e.g. label generated from the file name).

Technique 3.4.1: If the author has not specified an alternative equivalent, default to leaving out the relevant content (e.g. attribute, element, etc.), rather than including the attribute with no value or with automatically-generated content. Leaving out the attribute will increase the probability that the problem will be detected by checking algorithms. [STRONGLY SUGGESTED]

Techniques for Success Criteria 2: When the author inserts a non-text object for which the tool has a previously authored equivalent alternatives (i.e. created by the author, tool designer, pre-authored content developer, etc.), but the function of the object is not known with certainty, the tool must prompt the author to confirm insertion of the equivalent. However, where the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.), the tool may automatically insert the equivalent.

Technique 3.4.2: If human-authored equivalent alternatives are available for an object (for example, through management functionality (ATAG checkpoint 3.5) and/or equivalent alternatives bundled with pre-authored content (ATAG checkpoint 2.6), then the equivalent alternatives can be used in both semi-automated repair processes and automated repair processes as long as the function of the object is known with certainty. The function of an instance of an object can be considered to be known with certainty when:

• the tool totally controls its use (i.e. a generated tool bar), or
• the author has linked the current object instance to the same URI(s) as the object was linked to when the equivalent alternative was stored, or
• there is semantic role information stored for the object.

Technique 3.4.3: Allow the author to store semantic role information for instances of objects.@@non-empty values???@@

Technique 3.4.4: If human-authored equivalent alternatives are available for an object and that object is used for a function that is not known with certainty, tools may offer the equivalent alternatives to the author as defaults in a semi-automated repair processes, but not not in fully automated repair processes.

Technique 3.4.5: Where an object has already been used in a document, the tool may offer the alternative information that was supplied for the first or most recent use as a default.

Technique 3.4.6: If the author changes the alternative content, the tool may ask the author whether all instances of the object with the same known function should have their alternative content updated with the new value.

ATAG Checkpoint B.2.5: Provide functionality for managing, editing, and reusing alternative equivalents. [Priority 3]

Note: This checkpoint is priority 3 and is, therefore, not required to be implemented in order for a tool to conform to ATAG 2.0 at the single-A and double-AA levels. However, implementing this checkpoint has the potential to simplify the satisfaction of several higher priority checkpoints (ATAG checkpoint 3.1, ATAG checkpoint 3.2, and ATAG checkpoint 3.3) and improve the usability of the tool.

Techniques for Success Criteria 1: The authoring tool must always keep a record of alternative equivalents that the author inserts for particular non-text objects in a way that allows the text equivalent to be offered back to the author for modification and re-use if the same non-text object is reused.

Technique 3.5.1: Maintain a registry that associates object identity information with alternative information (this could be done with the Resource Description Framework (RDF) [RDF10]). Whenever an object is used and an equivalent alternative is collected (see ATAG Checkpoint 3.1) the object (or identifying information) and the alternative information can be added to the registry. In the case of a text equivalent, the alternate information can be stored in the document source. For more substantial information (such as video captions or audio descriptions), the information can be stored externally and linked from the document source. Several different versions of alternative information can be associated with a single object. @@rewording@@

Example 3.5.1: This illustration shows a text equivalents registry viewer that a tool can include to allow the author to query and edit the various text equivalents stored in the registry. For maximum flexibility, the design takes into account multiple non-text objects of the same name, multiple types of text equivalents for each non-text object, and multiple versions of each text equivalent type. (Source: mockup by AUWG)
[longdesc missing]

Technique 3.5.2: Present stored alternative information to the author as default text in the appropriate field, whenever one of the associated files is inserted into the author's document. This satisfies ATAG Checkpoint 3.4 because the equivalent alternatives are not automatically generated and they are only reused with author confirmation.@@rewording@@

Technique 3.5.3: If no stored association is found in the registry, leave the field empty.@@rewording@@

Technique 3.5.4: The stored alternative information required for pre-authored content (see ATAG Checkpoint 2.6) may be part of the management system, allowing the alternative equivalents to be retrieved whenever the pre-authored content is inserted.

Technique 3.5.5: Tools may allow authors to make keyword searches of a description database (to simplify the task of finding relevant images, sound files, etc.). A paper describing a method to create searchable databases for video and audio files is available (refer to [SEARCHABLE]).

ATAG Checkpoint B.2.6: Provide the author with a summary of accessibility status. [Priority 3]

Techniques for Success Criteria 1: The authoring tool must provide an option to view a list of all known accessibility problems (i.e. detected by automated check or identified by the author as part of a semi-automated or manual check) prior to completion of authoring.

Technique 3.6.1: Provide a list of all accessibility errors found in the content (e.g. selection, document, site, etc.).@@rewording of can@@

Technique 3.6.2: Provide a summary of accessibility problems remaining by type and/or by number. @@rewording of can@@

Technique 3.6.3: Store accessibility status information in an interoperable form using Evaluation and Repair Language [EARL].@@rewording@@

ATAG Checkpoint B.2.7: Document all features of the tool that support the production of accessible content. [Priority 2]

Techniques for Success Criteria 1: All features that play a role in creating accessible content must be documented in the help system.

Technique 3.7.1: Ensure that the help system can answer the following questions: "What features of the tool encourage the production of accessible content?" and "How are these features operated?".

Technique 3.7.2: Provide direct links to context sensitive help on how to operate the features.

ATAG Checkpoint B.2.8: Ensure that accessibility is modeled in all documentation and help, including examples. [Priority 3]

Techniques for Success Criteria 1: All examples of markup and screenshots of the authoring interface that appear in the documentation and help must model accessible Web content.

Technique 3.8.1: Include relevant accessible authoring practices in examples. [STRONGLY SUGGESTED]

Example 3.8.1: This illustration shows documentation for the input element in this code-level authoring tool makes use of the label element in order to reinforce the routine nature of the pairing. (Source: mockup by AUWG)
[longdesc missing]

Technique 3.8.2: In the documentation, ensure that all code examples pass the tool's own accessibility checking mechanism (see Checkpoint 3.1).

Technique 3.8.3: In the documentation, provide at least one model of each accessibility practice in the relevant WCAG techniques document for each language supported by the tool. Include all levels of accessibility practices.

Technique 3.8.4: Plug-ins that update accessibility features of a tool, should also update the documentation examples.

Technique 3.8.5: Implement context-sensitive help for accessibility terms as well as tasks related to accessibility.

Technique 3.8.6: Provide a tutorial on checking for and correcting accessibility problems.

Technique 3.8.7: Include pointers to more information on accessible Web authoring, such as WCAG and other accessibility-related resources.

Technique 3.8.8: 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.

Technique 3.8.9: Provide links from within the accessibility related documentation to launch the relevant accessibility features.

ATAG Checkpoint B.2.9: Provide a tutorial on the process of accessible authoring. [Priority 3]

Techniques for Success Criteria 1: A tutorial on accessible authoring for that authoring tool must be provided.

Technique 3.9.1: Document the sequence of steps that the author should take, using the tool, in order to increase the likelihood of producing accessible content. This should take account of any idiosyncrasies of the tool.

Technique 3.9.2: Explain the importance of accessibility for a wide range of content consumers, from those with disabilities to those with alternative viewers. Consider emphasizing points in "Auxiliary Benefits of Accessibility Features", a W3C-WAI resource.

Technique 3.9.3: Avoid referring to accessibility features as being exclusively for particular groups (e.g. "for blind authors").

Technique 3.9.4: In addition to including accessibility information throughout the documentation, provide a dedicated accessibility section.

Techniques for Success Criteria 2: For tools that lack a particular accessibility-related feature, the workflow description must include a workaround for the missing feature.

Note: Meeting this success criteria will not suffice to meet the checkpoints related to the missing accessibility-related feature.

Technique 3.9.5: Tools that lack an accessibility checking and/or repair feature may point to the relevant WCAG Techniques document

Guideline B.3: Promote and integrate accessibility solutions

This guideline requires that authoring tools must promote accessible authoring practices within the tool as well as smoothly integrate any functions added to meet the other requirements in this document. The checkpoint requirements for this section include ensuring that accessibility practices and features are given authoring interface priority (Checkpoint 4.1), clear availability (Checkpoint 4.2), workflow integration (Checkpoint 4.3), natural integration with the appearance and interactive style of the tool (Checkpoint 4.4), and sufficient configurability (Checkpoint 4.5)

• Techniques for checkpoint B.3.1 Ensure that the most accessible option for an authoring task is given priority. [Priority 2]
• Techniques for checkpoint B.3.2 Ensure that accessibility prompting, checking, repair functions, and documentation are always clearly available to the author [Priority 2]
• Techniques for checkpoint B.3.3 Ensure that sequential authoring processes integrate accessible authoring practices. [Priority 2]
• Techniques for checkpoint B.3.4 Ensure that accessibility prompting, checking, repair functions and documentation are configurable [Priority 3]

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

Rationale: Authors are most likely to use the first and easiest options.

Techniques for Success Criteria 1: When the author has more than one markup implementation to choose from (e.g. the color of text can be changed with presentation markup or style sheets), those markup implementations that conform to WCAG must have equal or higher prominence than those markup implementations that do not meet the WCAG requirements.

Technique 4.1.1: If there are two or more authoring options for performing the same authoring task (e.g. setting color, inserting multimedia, etc.), and one option results in content that meets WCAG and the other does not, the more accessible option should be given authoring interface prominence. (See Example 4.1.1) See the definition of the term "prominence" for more information. [STRONGLY SUGGESTED]

Example 4.1.1: This illustration shows an authoring tool that supports two methods for setting text color: using CSS and using font. Since using CSS is the more accessible option, it is given a higher prominence within the authoring interface by: (1) the "CSS Styling" option appearing above the "FONT Styling" option in the drop down Text menu, and (2) the CSS styling option being used to implement the one-click text color formatting button in the tool bar. (Source: mockup by AUWG)
[longdesc missing]

Technique 4.1.2: Completely removing less accessible options simplifies the task of meeting this success criteria.

Techniques for Success Criteria 2: @@New from Nov 1 call@@When the author is presented with a list of choices, that includes choices of formats or authoring practices that do not support content that conforms to WCAG, these should be *marked* to indicate that the choice may produce content that is inaccessible.

@@???@@

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

Rationale: If the features that support accessible authoring are difficult to find and activate, they are less likely to be used. Ideally, these features should be turned on by default.

Techniques for Success Criteria 1: All accessibility prompting, checking, repair functions and documentation must meet the following conditions:

(a) if they are continuously active, then it must always be enabled by default and if the author disables it (e.g. from a preferences screen), then the tool must always inform the author that this may allow accessibility problems to be introduced.

(b) they must have at least the same prominence as the same type of function (i.e. prompting, checking, repair and documentation) related to other kinds of information (e.g. markup validity, program code syntax, etc.).

Technique 4.2.1: Make any continuously active processes related to accessibility that can be turned on or off (e.g. "as you type"-style checkers), active by default.@@rewording@@

Example 4.2.1: This illustration shows the preference setting area of an authoring tool, open to an "Accessibility" section. Settings that control processes that are continuously active (i.e. not triggered by the author at each instance) are circled in red. (Source: mockup by AUWG)
[longdesc missing]

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.2.2: Inform the author that disabling any continuously active process may cause accessibility problems that might not occur otherwise. @@rewording@@

Example 4.2.2: If the author unchecks a "highlighting accessibility related fields" feature, as shown in figure 4.2.1, the tool might display a warning that reads "You have just turned off the highlighting accessibility related fields feature. This feature is designed to inform you when information must be provided in order for your documents to comply with your target accessibility setting. Turning this feature off could cause your documents to be less accessible to many users. In some jurisdictions accessibility is a legal requirement. Are you sure you want to proceed?

Techniques for Success Criteria 3: The 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 critical to content correctness(e.g. prompting for file names during saves or checking for and repairing spelling or syntax errors).

Technique 4.2.3: Prompting for accessibility information has the same prominence as prompting for information critical to content correctness. For example, a tool that prompts the author for file name attributes required to reference a multimedia object will have prompts with the same prominence for short text labels and long descriptions for that object

Example 4.2.3: This illustration shows a dialog box in which the input fields of for a text label, long description, and src attribute all have very similar prominence. (Source: mockup by AUWG )
[longdesc missing]

Technique 4.2.4: Checking and repairing accessibility problems has the same prominence as checking for information critical to content correctness. For example, a tool that checks for spelling, grammar, or code syntax will have checks with the same prominence for accessibility problems.

Example 4.2.4: This illustration shows an authoring interface that checks for and displays spelling and accessibility errors with the same prominence. In this case, the author has activated a right-click pop-up menu that includes spelling and accessibility repair options. (Source: mockup by AUWG)

Technique 4.2.5: Documentation for accessibility has the same prominence as documentation for information critical to content correctness. For example, a tool that documents any aspect of its operation will have documentation with the same prominence for accessibility.

Example 4.2.5: This illustration shows how the accessibility documentation has been added directly to the main documentation, with very similar prominence to that of the spelling-related features. (Source: mockup by AUWG)
[longdesc missing]

General Techniques for Checkpoint 4.2:

Technique 4.2.6: Sometimes several input fields must be filled in order to make a single element accessible. Instead of dispersing these prompts over multiple dialog boxes, it can be more effective to draw them together into one group of controls with a visible tab or other method for accessing the group.@@new-from intro text@

Technique 4.2.7: When determining prominence, control grouping rules usually takes precedence. (e.g. including a fields for adding a label and a description to an image insertion dialog). @@from BAF comment@@

ATAG Checkpoint 4.3: Ensure that sequential authoring processes integrate accessible authoring practices.[Priority 2]

Rationale: Accessible design as an afterthought or separate process is much more onerous and therefore costly than when accessibility is considered from the start. If the authoring tool supports a workflow in which the author considers accessibility before and/or during the authoring process it is more likely that accessible authoring practices will become a common practice. This is analogous to internationalization, which is much easier when it is considered from the beginning rather than handled last.

Techniques for Success Criteria 1: Accessibility prompting must be integrated into all features that assist with author decision-making (e.g. templates, wizards, and instruction text). Accessibility checking, repair, and documentation functions must be made available before completion of any authoring workflow.

Technique 4.3.1: Optimize the timing of prompting, checking, and repair functions. Authoring accessible documents should be as efficient as possible. Prompting, should be timed so that accessibility problems are prevented whenever possible and, when not possible, checking, and repair should occur when the accessibility problem is easily reversible. Integrated guidance in creating accessible content from the beginning of the workflow will avert the need for more disruptive checking and repair later in the workflow. Timing options include: Negotiated Interruption, Scheduled Interruption, and Immediate Interruption.

(a) Negotiated Interruption: A negotiated interruption is caused by interface mechanisms (e.g. icons or highlighting of the element, audio feedback) that alert the author to a problem, but remain flexible enough to allow the author to decide whether to take immediate action or address the issue at a later time. Since negotiated interruptions are less intrusive than immediate or scheduled interruptions, they can often be better integrated into the design workflow and have the added benefit of informing the author about the distribution of problems within the document. Although some authors may choose to ignore the alerts completely, it is not recommended that authors be forced to fix problems as they occur. Instead, it is recommended that negotiated interruption be supplemented by scheduled interruptions at major editing events (e.g., when publishing), when the tool should alert the author to the outstanding accessibility problems.

Example 4.3.1(a): This illustration shows an example of a negotiated interruption. The author is made aware of problems detected automatically by means of a blue squiggly line around or under rendered elements with accessibility problems. The author can decide to address the problems at a later time. (Source: mockup by AUWG)
[longdesc missing]

(b) Scheduled Interruption: A scheduled interruption is one in which the author has set the tool to alert them of accessibility issues on a configurable schedule. One option for the schedule might be to have prompts associated with the interface mechanisms for significant authoring events, such as opening, saving, closing, committing, or publishing files. At the significant authoring event, the author would be informed of the problem, while at the same time they would not be prevented from saving (see Figure 4.3.1(b)), publishing, printing, etc.. A potential downside of postponing corrective actions is that by the time the prompt is displayed, the author may not have sufficient time or inclination to make the required changes, especially if they are extensive.

Example 4.3.1(b): This illustration shows a "Publish" dialog box that is an example of a scheduled interruption. The author is alerted to the existence of content that does not meet a "standard of publishing" before being allowed to publish. This standard might include spelling and grammar standards as well as accessibility issues. (Source: mockup by AUWG)
[longdesc missing]

(c) Immediate Interruption: An immediate interruption is the most intrusive timing option because the attention of the author is actively diverted from the current editing task by the notification of some issue. This might be achieved, for instance, by an alert dialog. This type of alert presents multiple usability problems and should be used sparingly because it interferes with the normal design workflow. Intrusive warnings are probably only appropriate when the window of opportunity for correcting a serious accessibility problem is about to close, such as when an author decides to publish the content in question. In general, negotiated and scheduled interruptions are preferred.

Example 4.3.1(c): This illustration shows an example of an immediate interruption of the author's workflow. The author must press the "OK" button on the dialog box to continue. (Source: mockup by AUWG)
[longdesc missing]

Technique 4.3.2: When authoring tools produce content in real time, it is usually no longer possible to delay addressing accessibility problems until an arbitrary point in the future. At the same time, due to the time pressure, authors in real-time environments tend to be less receptive to intrusive prompts. Nevertheless, tools that allow this kind of authoring (see Figure 3.3.6) should still take accessibility issues into account by supporting the following:

(a) Determination of Participant Requirements: If real-time authoring is consumed by individuals with no special communicative needs, there may be no need for real-time prompting. However, as with any other Web content it is often impossible for the author to know all of the needs of the actual or potential participants. Therefore, the best practice is to create real-time content that conforms with WCAG to the greatest extent possible. However, when this is not possible, a real-time authoring tool might be able to facilitate graceful degradation of accessibility by polling the participants (see "Request whiteboard descriptions" checkbox in the figure) or in some cases checking the profiles of participants (e.g. using CCPP, ACCLIP) to determine which types of accessibility practices would offer the greatest advantage in the short time available. Once this information is compiled, the tool can prompt the author (or see Assistant/Peer Author) to correct problems appropriately (preferably during Preparation Time). When it is not possible to know, with certainty, the needs of all participants, the tool should still assume that accessible content is required. This is especially true if the results of the session will be archived.

(b) Assistant/Peer Author: In some cases, it may be possible to designate one or more secondary authors in the live community, who can receive and respond to prompts for supplemental information generated as the primary author proceeds uninterrupted. The secondary author might be an unrelated specialist, analogous to Sign language interpreter, a co-author (helpful for describing technical drawings, etc.), or in some situations any member of the session audience (i.e. a peer).

(c) Preparation Time: If the authoring tool allows the author time to pre-assemble materials for a live presentation (e.g. a professor preparing for an online class), this authoring is not considered real-time authoring. The authoring tool has the opportunity and the obligation to support accessible authoring as described elsewhere in this document.

(d) Archiving: If the session will be archived, there may be other opportunities to increase the accessibility of the content of the archive by guiding the author through a process to check for and repair accessibility problems after the real-time session has ended, but prior to archiving.

If it has been determined that the author must provide real-time supplements, but no preparation time or assistant author are available, then in addition to allowing the author control of the nature and timing of prompting, the authoring tool can facilitate the inclusion of supplements by:

• Implementing the management functionality for equivalent alternatives (see Checkpoint 3.5). This way, if the author uses an object that has been used before, the tool can suggest the previously stored alternative, which the author can quickly accept or decline without substantial workflow disruption.
• Providing a voice recognition capability so that the author's real-time speech input can be converted into captioning.

Example 4.3.2: This illustration shows an a real-time presentation in a whiteboard/chat environment. Notice the functionality by which the presenter or an assistant/peer author can describe the events on the whiteboard even as the dialog continues. (Source: mockup by AUWG).
[longdesc missing]

Technique 4.3.3: Detect and immediately highlight accessibility problems when documents are opened, when an editing or insertion action is completed, or while an author is editing.

Technique 4.3.4: If intrusive warnings are used, provide a means for the author to select a less obtrusive method of alerting.

Techniques for Success Criteria 2: Any mechanism that guides the author in sequencing authoring actions (e.g. design aids, wizards, templates, etc.) must integrate accessibility prompting, checking, repair functions, and documentation.

@@ BAF: Wizards are the way to go: . Repair tools can address pre-existing content or content edits after use of a wizard (assuming you cannot reenter the wizard). @@ @@BAF: wizards etc should be a major prompting mechanism. Many samples should be shown such as the table example.@@ @@GP would like to de-emphasize wizards a bit.@@

@@JT: Maybe have an example showing a template....?NTS?@@

@@JT: We need to have new techniques for tools that could try to get author to put down structure first and separately than presentation - swappable styles@@

Technique 4.3.5: Integrate prompting into sequencing mechanisms (e.g. design aids, wizards, templates) at a point early enough in the authoring process that there is less chance that it will be bypassed.

Example 4.3.5: This illustration shows three screens of a page building wizard (indirect authoring). The wizard prompts the author for a few key pieces of information that are used to tailor the process, in this case to create a gallery page. Since the accessibility-related prompts ("label" and "description") occur on the third step of the wizard, the "Finish" button is unavailable until then to prevent the author from bypassing this step. (Source: mockup by AUWG)
[longdesc missing]

Technique 4.3.6: Integrate checking and repairing into sequencing mechanisms (e.g. design aids, wizards, templates).

Example 4.3.6: This illustration shows the wizard screen that immediately follows the sequence in Example 4.3.6. Since no text was entered in the description field, checking, and repairing occurs immediately in the sequence of the wizard interface. (Source: mockup by AUWG)

Technique 4.3.7: Provide the author with immediate access to some basic accessibility documentation and one-step access to more comprehensive documentation.

Example 4.3.7: This illustration shows an accessibility checker with some limited short label authoring tips listed beneath the text entry area as well as a button linking to the full documentation. (Source: mockup by AUWG)
[longdesc missing]

Technique 4.3.8: A tight coupling between all of the accessibility-related functions leads to a more seamless authoring experience.

Example 4.3.8(a,b,c): This illustration shows a sequence of steps through a WYSIWYG interface in which prompting, checking, repair, and documentation of accessibility issues are all integrated into the process of creating a table. In the first step (Figure 4.3.8(a)), the author has requested that a table be inserted. The tool prompts the author for accessibility information (i.e. caption and summary) at the same time as it prompts for the number of rows and columns, etc. The tool assists the author by filling both fields with known information (i.e. that this is the 3rd table in the document). In the second step (Figure 4.3.8(b)), as the author finishes filling in the top row of cells, the tool has checked the structure of the table and found that no header cells have been defined. To address this problem, the tool highlights the top row of the table. When the author selects the highlighted area a drop-down is displayed that lets the user choose whether to let the tool make the repair or ignore the problem. In the third step (Figure 4.3.9(c)), the author has added a new row to the top of the table and merged two cells in this new top row. The tool again checks the table and facilitates the repair. In all three steps, help documentation is within easy reach. (Source: mockup by AUWG)
[longdesc missing]

ATAG Checkpoint B.3.4: Ensure that accessibility prompting, checking, repair, and documentation functions are configurable. [Priority 3]

Rationale: A configurable tool is more likely to be adaptable to the work habits of more authors.

Techniques for Success Criteria 1: All functions related to accessibility prompting, checking, repair, and documentation must match the other prompting, checking, repair, and documentation functions of the tool (respectively), in terms of the number of options controllable by the author and the degree to which each option can be controlled.

Technique 4.5.1: Provide author configurability. Author acceptance of the accessibility features of an authoring tool can depend on the degree to which these features are integrated into the existing workflows of authors. Author configurability can help naturally incorporate accessibility-related authoring tasks into the regular workflow of the author. Useful configuration options include (see Figure 4.5.1):

• the nature of the accessibility guidance they wish to receive,
• the degree to which the prompts are highlighted in the interface,
• the nature and timing of any automated accessibility features (e.g. accessibility checking or repairing utilities), and
• which accessibility standards they wish to follow, and where applicable, to which level.

  Example 4.5.1: This illustration shows an accessibility preferences dialog that allows the author to customize the nature of accessibility checking, highlighting and help as well as set the accessibility standards the tool will check against. (Source: mockup by AUWG)
  [longdesc missing] @@other mockup removed@@

Technique 4.5.2: Include alerts for high priority WCAG checkpoints in the default configuration.

Technique 4.5.3: Allow authors to choose different alert mechanisms based on the priority of accessibility problems.

Technique 4.5.4: CSS classes can be used to indicate accessibility problems enabling the author to easily configure the presentation of errors.@@more detailed than usual@@

Contents | Part A | Part B | References