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 :
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:
Ensure that markup which the tool automatically generates is valid for the language
the tool is generating.[Priority 1]
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 devices.
Techniques for Success Criteria 1: All markup strings written automatically
by the tool (i.e. not authored
"by hand") must conform to the applicable markup language specification.
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@@@@unnecessary@@
ATAG Checkpoint 2.2: Support
formats that enable the creation of WCAG-conformant content. [Priority 2].
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: In order to
give priority to a format, that format must have a published techniques
document for meeting each WCAG checkpoint.
Technique 2.2.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.
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. @@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.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, 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: 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.2.5: Consult the following references:
Rationale: The ability to produce accessible Web content is
the most basic requirement of this document.
Techniques for Success Criteria 1: Tools must always meet
at least one of the following: (1) generate accessible content automatically,
(2) provide a method for authoring
"by hand", or (3) provide the author with accessible options for every authoring
task.
Technique 2.3.1: Ensure the tool supports all the structural
features of the supported languages.
Technique 2.3.2: Allow the author to edit the source markup
directly (so knowledgeable authors can ensure accessible content).
Technique 2.3.3: When only a simplified
(subset) of a markup language is supported, ensure that the subset includes
accessibility features in the base language.
Technique 2.3.4: Allow the addition of equivalent alternatives
for all supported image formats that allow text content (e.g. 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 [DUBLIN-CORE]
to incorporate description, title information, or "foaf" metadata
to identify people depicted in images. @@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 when
a given output format is not accessible and provide the option to use a different
format. @@CMN Proposal@@ @@KM sounds like a Techs 3 duplicate, but the "provide
the option" part makes it different and perhaps valid to include here.
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 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. @@reworded by KM@@
Techniques for Success Criteria 1: During all transformations and
conversions, any accessibility information must be preserved, unless
prevented by limitations of the target format.
Technique 2.4.1: If possible, preserve
all unrecognized markup, since it might be related to accessibility (See
Techniques for ATAG Checkpoint 3.2).
Technique 2.4.2: This checkpoint covers
systems that reconstitute documents into standardized formats. @@KM rewording@@
Technique 2.4.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@@
Technique 2.4.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.4.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.4.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.4.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.4.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.4.9:Do not change the DTD
without notifying the author. @@from ATAG1 4.3@@
Technique 2.4.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 2.5:
Ensure that when the tool automatically generates content it conforms
to WCAG.[WCAG Relative Priority (Web Content)]
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
strings written automatically by the tool (i.e. not authored
"by hand") must be accessible (i.e. meet the Web
content checkpoints requirements to Level 1, 2, or 3).
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. [STRONGLY SUGGESTED] @@KM should
we provide the actual hyperlinks here?@@
ATAG Checkpoint 2.6
: Ensure that all pre-authored content for the tool conforms to WCAG. [WCAG Relative Priority (Web Content)]
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 Web content
(e.g. templates, clip art, multimedia objects, scripts, applets, example pages,
etc.) preferentially licensed (i.e. better terms of use for users of tool than
for others) for users of the tool, must be accessible (i.e. meet the
Web content checkpoints requirements to
Level 1, 2, or 3).
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.@@KM perhaps make cross-ref to appropriate checkpoint in guideline
3, maybe 4 (about checking, etc.)? @@
Technique 2.6.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.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. 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.6.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@@
Contents | Guideline 1 |
Guideline 2 | Guideline 3 | Guideline
4 | References