This document lists all of the techniques employed by Amaya
[AMAYA] that are listed in Techniques for Authoring Tool Accessibility Guidelines 1.0 [ATAG10-TECHS]. The
guidelines and checkpoints are included as well for convenience.
Status of this document
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The latest status of
this document series is maintained at the W3C.
This document is a W3C Note, published as an informative appendix
to "Techniques for Authoring Tool Accessibility Guidelines 1.0". This document has been approved by the Authoring Tool Accessibility
Guidelines Working Group (AUWG). The Working Group expects
to update this document in response to queries raised by implementors
of the Guidelines, for example, to cover new technologies. Suggestions
for additional techniques are welcome.
Publication of a W3C Note does not imply endorsement by the W3C Membership.
This document has been produced by the Authoring Tool Accessibility
Guidelines Working Group (AUWG) as part of the Web Accessibility Initiative (WAI). The goals of the
Working Group are discussed in the AUWG charter.
Please send general comments about this document to the public
mailing list: w3c-wai-au@w3.org
(public
archives).
This document lists the techniques used by Amaya (or in development
for Amaya) to satisfy the Authoring Tool Accessibility Guidelines 1.0
[ATAG10]. It is intended to assist developers seeking to implement
the Authoring Tool Accessibility Guidelines 1.0.
Note: The techniques in this document are merely
suggestions; they are not required for conformance to the Authoring
Tool Accessibility Guidelines 1.0. These techniques are not
necessarily the only way of satisfying the checkpoint, nor are they
necessarily a definitive set of requirements for satisfying a
checkpoint.
This document has the same structure as the Authoring Tool
Guidelines 1.0 [ATAG10]. Each guideline and checkpoint from that
document is listed, in the same order, with an explanation of Amaya's
techniques for implementing them, or techniques that the development
team plans to implement.
Guideline 1. Support accessible authoring
practices.
Checkpoints:
- 1.1 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1]
-
- Amaya implements all of the accessibility
features of HTML. The CSS cascade order, an accessibility feature of
CSS2, has not yet been completely implemented in Amaya.
- 1.2 Ensure that the tool preserves all accessibility information during authoring, transformations, and conversions. [Priority 1]
-
- The predefined transformations shipped with
Amaya preserve all element content. The transformation language
allows the preservation of attribute values, but this is not done by
all the supplied transformations.
- 1.3 Ensure that when the tool automatically generates markup it conforms to the W3C's Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]
-
- Amaya generates markup that conforms to
level-A, and allows the author to generate markup that is triple-A
through the user interface.
- 1.4 Ensure that templates provided by the tool conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]
-
- Amaya has templates, which have
not yet been checked for conformance to WCAG 1.0 [WCAG10].
Guideline 2. Generate standard markup.
Checkpoints:
- 2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task. [Priority 2]
-
- Amaya supports HTML 4 [HTML4], XHTML 1.0
[XHTML10], and most of CSS1 [CSS1]. It provides partial support
for MathML [MATHML] and some experimental support for Scalable
Vector Graphics [SVG].
- 2.2 Ensure that the tool automatically generates valid markup. [Priority 1]
-
- Amaya implements each language according to
the published specifications.
- 2.3 If markup produced by the tool does not conform to W3C specifications, inform the author. [Priority 3]
-
- If Amaya imports or generates markup that does not conform to W3C
specifications it is highlighted in the structure view. This occurs
when Amaya tries to repair invalid markup and cannot successfully do
so.
Guideline 3. Support the creation of accessible
content.
Checkpoints:
- 3.1 Prompt the author to provide equivalent alternative information (e.g., captions, auditory descriptions, and collated text transcripts for video). [Relative Priority]
-
- Amaya prompts the author to provide
equivalent text for
IMG
and AREA
elements,
and CAPTION
for the TABLE
element.
- 3.2 Help the author create structured content and separate information from its presentation. [Relative Priority]
-
- In future releases Amaya is expected to
prompt the author for
"title"
for ABBR
,
ACRONYM
, OBJECT
, and IMG
elements, and LABEL
for FORM
controls. The
user interface of Amaya was developed to guide authors to produce
structured documents. Style in Amaya is created as a
stylesheet.
- 3.3 Ensure that prepackaged content conforms to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]
-
- Amaya does not provide any clip art
or other prepackaged content.
- 3.4 Do not automatically generate equivalent alternatives. Do not reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]
-
- Amaya does not provide default
"alt"
text
except when copying and pasting images, in which case it copies all
attributes with the image.
- 3.5 Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects. [Priority 3]
-
- Amaya has no registry of alternate text
associated with images, although when an image is copied and pasted
its alt and other attributes are copied too.
Guideline 4. Provide ways of checking and
correcting inaccessible content.
Checkpoints:
- 4.1 Check for and inform the author of accessibility problems. [Relative Priority]
-
- Amaya currently checks for validity, but the
only warning of invalid markup appears in the structure
view. The Amaya developers are investigating automating an accessibility check
and author notification. Where Amaya detects an error, it identifies
and highlights the incorrect code in the structure view, allowing
the author to delete it.
- 4.2 Assist authors in correcting accessibility problems. [Relative Priority]
-
- Amaya currently does not satisfy this
checkpoint. Amaya uses its own internal representation for the
document markup that is transformed on output. Possible
implementation strategy: Where there are errors in a document Amaya
could alert the author and warn that the document must be changed,
and present the structure view highlighting areas where it has
changed the markup, allowing the author to abort the editing session
or save the changed version under a new name.
- 4.3 Allow the author to preserve markup not recognized by the tool. [Priority 2]
-
- Amaya currently does not satisfy this
checkpoint.
- 4.4 Provide the author with a summary of the document's accessibility status. [Priority 3]
-
- Amaya currently does not satisfy this
checkpoint.
- 4.5 Allow the author to transform presentation markup that is misused to convey structure into structural markup, and to transform presentation markup used for style into style sheets. [Priority 3]
-
- Amaya provides a language for specifying
structure transformations, and a large number of
predefined transformations are included.
Guideline 5. Integrate accessibility
solutions into the overall "look and feel".
Checkpoints:
- 5.1 Ensure that functionality related to accessible authoring practices is naturally integrated into the overall look and feel of the tool. [Priority 2]
-
- In Amaya some accessibility features are part
of relevant dialogs. Others, such as longdesc and title attributes
must be separately generated by the author. The development team
will integrate these into the relevant dialogues in future
releases.
- 5.2 Ensure that accessible authoring practices supporting Web Content Accessibility Guidelines 1.0 [WCAG10] Priority 1 checkpoints are among the most obvious and easily initiated by the author. [Priority 2]
-
- Amaya's user interface guides the author to
produce structured content, with presentation elements separated
into style sheets. Providing an equivalent alternative is mandatory
at the time of inserting some elements.
Guideline 6. Promote accessibility in help and
documentation.
Checkpoints:
- 6.1 Document all features that promote the production of accessible content. [Priority 1]
-
- Amaya help pages for images and image maps
[AMAYA-HELP-IMG] include providing text alternatives as part of
the process. There is a help page on configuring Amaya, that
documents how to change the default keyboard bindings.
- 6.2 Ensure that creating accessible content is a naturally integrated part of the documentation, including examples. [Priority 2]
-
- Accessible authoring features are added to
the documentation as they are incorporated into Amaya, as part of
the normal documentation of the relevant feature.
- 6.3 In a dedicated section, document all features of the tool that promote the production of accessible content. [Priority 3]
-
- Amaya documentation has a basic accessibility
section.
For the latest version of any W3C specification please consult the list of
W3C Technical Reports.
- [AMAYA]
- Amaya, developed at W3C, is both an authoring tool and
browser with a
WYSIWYG-style user interface.
Amaya serves as a testbed for W3C specifications.
Source code, binaries, and further
information are available at http://www.w3.org/Amaya/. The
techniques in this document are based on Amaya version 2.4.
- [AMAYA-HELP-IMG]
- "Images and
Client-side Image Maps," Amaya's Help page for images and image
maps.
- [ATAG10]
- "Amaya - Authoring Tool Accessibility Guidelines 1.0 sample implementation," J.
Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds. The latest version is available at
http://www.w3.org/TR/ATAG10-TECHS/sample-amaya.
- [ATAG10-TECHS]
- "Techniques for Authoring Tool Accessibility Guidelines 1.0," J.
Treviranus, J. Richards, I. Jacobs, and C. McCathieNevile eds. The
latest version is available at http://www.w3.org/TR/ATAG10-TECHS/sample-amaya.
- [CSS1]
- "CSS, level 1
Recommendation," B. Bos and H. Wium Lie, eds., 17 December 1996,
revised 11 January 1999. This CSS1 Recommendation is
http://www.w3.org/TR/1999/REC-CSS1-19990111. The latest version of CSS1 is
available at http://www.w3.org/TR/REC-CSS1. Note:
CSS1 has been superseded by CSS2. Tools should implement
the CSS2 cascade.
- [HTML4]
- "HTML 4.01
Recommendation," D. Raggett, A. Le Hors, and I. Jacobs, eds., 24
December 1999. This HTML 4.01 Recommendation is
http://www.w3.org/TR/1999/REC-html401-19991224. The latest version of HTML 4 is
available at http://www.w3.org/TR/html4.
- [MATHML]
- "Mathematical
Markup Language," P. Ion and R. Miner, eds., 7 April 1998, revised 7
July 1999. This MathML 1.0 Recommendation is
http://www.w3.org/TR/1998/REC-MathML-19990707. The latest version of MathML 1.0
is available at http://www.w3.org/TR/REC-MathML.
- [SVG]
- "Scalable Vector Graphics (SVG) 1.0
Specification (Working Draft)," J. Ferraiolo, ed. The latest version
of the SVG specification is available at
http://www.w3.org/TR/SVG.
- [WCAG10]
- "Web
Content Accessibility Guidelines 1.0," W. Chisholm, G. Vanderheiden,
and I. Jacobs, eds., 5 May 1999. This Recommendation is
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. The latest version of
the Web Content
Accessibility Guidelines 1.0" is available at
http://www.w3.org/TR/WCAG10/.
- [XHTML10]
- "XHTML(TM) 1.0: The
Extensible HyperText Markup Language (Working Draft)," S. Pemberton
et al. The latest version of XHTML
1.0 is available at http://www.w3.org/TR/xhtml1.