Introduction to Guideline 2:

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 create valid, standards-based Web content, that can be rendered reliably by more user agents, including assistive technologies (Checkpoint 2.1). The next responsibility is to support formats that enable accessible content (Checkpoint 2.2).

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 support this include ensuring that it is possible to author accessible content (Checkpoint 2.3), preserving accessible or unknown content (Checkpoint 2.4), automatically generating accessible content (Checkpoint 2.5), and including accessible pre-authored content (Checkpoint 2.6).

Checkpoints in Guideline 2 :

• Techniques for checkpoint 2.1: Support formats that enable the creation of Web content that conforms to WCAG. [Priority 1]
• Techniques for checkpoint 2.2: Ensure that the tool preserves all unrecognized markup and accessibility information during transformations and conversions. [Priority 2]
• Techniques for checkpoint 2.3: Ensure that when the tool automatically generates content it conforms to WCAG. [Web Content Checkpoints Relative to WCAG]
• Techniques for checkpoint 2.4: Ensure that all pre-authored content for the tool conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

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 a imperative voice. Nevertheless, the techniques remain informative (non-normative).

ATAG Checkpoint 2.1: Support formats that enable the creation of Web content that conforms to WCAG. [Priority 1].

Rationale: Some formats are WCAG-capable, enabling the creation of web content that conforms to WCAG, while other formats may intrinsically preclude this possibility.

Techniques for Success Criteria 1: Any authoring tool that chooses the format of content for the author (i.e. a default format) must always choose formats for which there are published WCAG techniques documents for meeting each WCAG checkpoint.

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 format of content must support at least one format for which there is a published WCAG techniques documents for meeting each WCAG checkpoint and always give prominence to those formats.

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.

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.

Technique 2.1.5: Consult the following references:

• W3C maintains a Technical Reports and Publications page of the W3C.
• Language specific accessibility notes: CSS [CSS-ACCESS], SMIL [SMIL-ACCESS], HTML4 [HTML4-ACCESS], SVG [SVG-ACCESS], XML languages [XML-ACCESS].

ATAG checkpoint 2.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. (Conversion is defined as taking content encoded in one markup language and re-encoding it in another, and transformation is defined as modifying the encoding of content without changing the markup language.) 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.

(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

(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.

• (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.

Technique 2.2.5: Best practices for conversion include the following examples:

• 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 use of the new language.

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

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.

Technique 2.2.9:Do not change the DTD without notifying the author.

Technique 2.2.10: Provide the author with explanations of automatic changes made by the tool.

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 2.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.

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 (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]

ATAG Checkpoint 2.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.

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.

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.

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

Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References