Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References
Copyright © 1994-2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
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, this 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).
Rationale: Following language specifications is the most basic
requirement for accessible content production. When content is valid, it is
easier to check and correct accessibility errors and user agents are better able
to render the content properly and personalize the content to the needs of individual
content consumer's users' devices.
Technique 2.1.1: Ensure that the markup produced by the tool, in any of its supported languages, is valid. | |
Technique 2.1.2: Publish proprietary language specifications or DTD's on the Web, to allow documents to be validated. | |
Technique 2.1.3: Use namespaces and schemas to make documents that can be automatically transformed to a known markup language. | |
Technique 2.1.4: If markup produced by the tool does not conform to W3C specifications, inform the author. (e.g. statement on the saving dialog, an alert that is displayed following a save or inline highlighting through the use of style sheets, etc.). @@New technique made from ATAG1 2.3@@ | |
Technique 2.1.5: If the tool produces inaccessible markup, whether it is valid or not, see the checking Techniques for ATAG checkpoint 5.1. @@New technique made from ATAG1 2.3@ |
Rationale: Some formats are WCAG-capable, enabling the creation of web content that conforms to WCAG, while other formats may intrinsically preclude this possibility.
Technique 2.2.1: When creating documents or markup languages, make full use of W3C Recommendations. For example, use MathML for mathematical Web content and XHTML, MathML, and DOM scripting to implement dynamic-interactive spreadsheets. | |
Technique 2.2.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.2.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 or 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.2.4: Although markup languages and formats that become W3C Recommendations after an authoring tool's development cycle permit input are not considered "available" in time, modular design of tools provides for new markup languages and formats to be supported late in the development cycle or even after deployment. | |
Technique 2.2.5: Consult the following references: | |
|
Rationale: The ability to produce accessible Web content is the most basic requirement of this document.
Technique 2.3.1: Ensure the tool supports all the structural features of the supported languages. | |
Technique 2.3.2: Allow the author to directly edit the source markup (so knowledgeable authors can ensure accessible content). | |
Technique 2.3.3: When an extended (superset) or simplified (subset) markup language is supported, ensure that the accessibility features in the base language are still available. | |
Technique 2.3.4: Allow the addition of equivalent alternatives for all supported image formats that allow text content, including PNG, SVG, WebCGM, JPEG, and GIF. | |
Technique 2.3.5: Enable the author to produce metadata that can be used to construct an accessible version of the output. For example, when producing image formats that do not allow the inclusion of alternative information within them, use Dublin Core metadata to incorporate description, title information, or "foaf" metadata to identify people depicted in images. @@new category and T####@@ @@CMN Proposal@@ [@@I think this should be more like - add metadata to the object providing Dublin Core type, format, title and description metadata - Liddy@@@ ] | |
Technique 2.3.6: Notify the author,@@@no comma here, I think@@@if a given output format is not accessible (so they can decide to use a different format). [T0401] @@new category and T####@@ @@CMN Proposal@@ | |
Technique 2.3.7: Consult the following references: | |
Rationale: Unrecognized markup may include recent technologies that have been added to enhance accessibility and should be preserved during conversions (i.e. taking content encoded in one markup language and re-encoding it in another) or transformations (i.e. modifying the encoding of content without changing the markup language). Accessibility information should also be preserved.
Technique 2.4.1: This checkpoint covers systems that digest ingest?@@documents and reconstitute them in standardized formats. @@new category and T####@@ @@F2F Proposal@@ | |
Technique 2.4.2: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 publishing view [@@what does 'view' mean here?@@] or preview mode. | |
Technique 2.4.3: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.4.4:Some examples of conversion best practices include: @@Use of "conversion best practice"@@ | |
|
Technique 2.4.5: 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@@ | |
Technique 2.4.7: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.4.8:Do not change the DTD without notifying the author. @@from ATAG1 4.3@@ | |
Technique 2.4.9: Consider providing the author with explanations of automatic changes made by the tool[@@]. @@new category and T####@@ @@F2F Proposal@@ | |
Technique 2.4.10: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. |
From old 2.7 (removed)
Technique 2.7.1: If possible, preserve all unrecognized markup, since it might be related to accessibility (See Techniques for ATAG Checkpoint 3.2). | |
Technique 2.7.2: 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.7.3: Provide options for the author to confirm or override removal of markup on a change-by-change basis or as a batch process. | |
Technique 2.7.4: Do not change the DTD without notifying the author. |
Rationale: Authoring tools that automatically generate content that does not conform to WCAG are an obvious source of accessibility problems.
Technique 2.5.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 : |
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
user 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, and show authors the importance of description writing.
Technique 2.6.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. [T0080] | |
Technique 2.6.2: Provide pre-authored content in formats that allow for accessible annotation to be included in the files, such as SMIL, PNG, and SVG. @@new category and T####@@ | |
Technique 2.6.3: Ensure that all pre-authored content provided by the tool conforms [@@] to the relevant WCAG checkpoints : | |
Technique 2.6.4: Make use of accessible templates. | |
|
Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References