[contents]
_________________________________________________________________
W3C
Techniques for Authoring Tool Accessibility (working draft)
W3C Working Draft 14 October 1999
This version:
http://www.w3.org/WAI/AU/WAI-AUTOOLS-TECHS-19991014
(plain text, HTML gzip tar archive, HTML zip archive,
PostScript, PDF)
Latest version:
http://www.w3.org/WAI/AU/WAI-AUTOOLS-TECHS
Previous version:
http://www.w3.org/WAI/AU/WAI-AUTOOLS-TECHS-19991009
Editors:
Jutta Treviranus <jutta.treviranus@utoronto.ca>
Jan Richards <jan.richards@utoronto.ca>
Ian Jacobs <ij@w3.org>
Charles McCathieNevile <charles@w3.org>
Copyright © 1999 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C
liability, trademark, document use and software licensing rules
apply.
_________________________________________________________________
Abstract
This document contains techniques and further examples, as an
informative aid to developers seeking to implement the Authoring Tool
Accessibility Guidelines [WAI-AUTOOLS]. The guidelines and checkpoints
for that document are included for convenience.
This document is part of a series of accessibility documents published
by the W3C Web Accessibility Initiative.
Status of this document
This is a Working Draft of the Techniques for Authoring Tool
Accessibility. This draft is to demonstrate a possible format for the
sample implementations section. This draft follows the working group
meeting on 13 October 1999. For further information consult the
minutes of Working Group Meetings.
This is a draft document and may be updated, replaced or rendered
obsolete by other documents at any time. It is inappropriate to use
W3C Working Drafts as reference material or to cite them as other than
"work in progress". This is work in progress and does not imply
endorsement by either W3C or its member organizations.
The goals of the WAI AU Working Group are discussed in the WAI AU
charter.
Please send comments about this document to the public mailing list:
w3c-wai-au@w3.org, archived at
http://lists.w3.org/Archives/Public/w3c-wai-au
A list of the current AU Working Group members is available.
Table of Contents
* Abstract
* Status of this document
* 1 Introduction
+ 1.1 How the Techniques are organized.
+ 1.2 Checkpoint priorities
* 2 Guidelines
+ 1. Support accessible authoring practices
+ 2. Generate standard markup
+ 3. Support the creation of accessible content
+ 4. Provide methods of checking and correcting inaccessible
content
+ 5. Integrate accessibility solutions into the overall "look
and feel"
+ 6. Promote accessibility in help and documentation
+ 7. Ensure that the Authoring Tool is Accessible to Authors
with Disabilities
* 3 Appendix - Sample Implementations
+ 3.1 Amaya
+ 3.2 Sketch
+ 3.3 The A-prompt Tool
+ 3.4 Alt-Text for the HTML 4.0 IMG Element
* 4 Terms and Definitions
* 5 Acknowledgments
* 6 References
_________________________________________________________________
1 Introduction
This document complements the Authoring Tool Accessibility Guidelines
[WAI-AUTOOLS]. Although it reproduces the guidelines and checkpoints
from that document it is not a normative reference; the techniques
introduced here are not required for conformance to the Guidelines.
The document contains suggested implementation techniques, examples,
and references to other sources of information as an aid to developers
seeking to implement the Authoring Tool Accessibility Guidelines.
These techniques are not necessarily the only way of fulfilling the
checkpoint, nor are they necessarily a definitive set of requirements
for fulfilling a checkpoint.. It is expected to be updated in response
to queries raised by implementors of the Guidelines, for example to
cover new technologies. Suggestions for additional techniques are
welcome and should be sent to the working group mailing list at
w3c-wai-au@w3.org. The archive of that list at
http://lists.w3.org/Archives/Public/w3c-wai-au is also available.
To understand the accessibility issues relevant to authoring tool
design, consider that many users may be creating documents in contexts
very different from your own:
* They may not be able to see, hear, move, or may not be able to
process some types of information easily or at all;
* They may have difficulty reading or comprehending text;
* They may not have or be able to use a keyboard or mouse;
* They may have a text-only display, or a small screen.
In addition, accessible design will benefit many people who do not
have a physical disability but with similar needs. For example they
may be working in a noisy environment and unable to hear, or need to
use their eyes for another task, and be unable to view a screen. They
may be using a small mobile device, with a small screen, no keyboard
and no mouse.
1.1 How the Techniques are organized.
This document has the same structure as the Authoring Tool
Accessibility Guidelines ([WAI-AUTOOLS]). Each Guideline and
checkpoint from that Document is listed, in the same order, with
techniques for implementing them, further references, and other
information that the working group considers useful for implementing
the guidelines but not a normative (required) part of the guidelines
themselves. For some guidelines there are techniques or information
which are relevant to the entire guideline. These are provided at the
end of the section for the relevant guideline.
In addition, there are "sample implementations". These list the
checkpoints from the Authoring Tool Accessibility Guidelines
[WAI-AUTOOLS], that will be in the same order, and that describe how
a real or hypothetical tool of a particular type implements them.
Some of the techniques describe the implementation of a checkpoint in
a real HTML editing tool - W3C's Amaya, the image editor Sketch
([SKETCH]), and Microsoft's Word 2000. The Amaya techniques are also
available as single "sample implementation" documents [AMAYA-SAMPLE],
and it is anticipated that the other sample implementations will be
handled in the same way.
Each checkpoint is intended to be specific enough that it can be
verified, while being sufficiently general to allow developers the
freedom to use the most appropriate strategies to meet the checkpoint.
The Techniques provided in this document are suggestions for how
implementation might be done, or where further information can be
found. They are informative only, and other strategies may be used to
meet the checkpoint as well as, or in place of, those discussed.
1.2 Checkpoint priorities
Each checkpoint has a priority level. The priority level reflects the
impact of the checkpoint in meeting the goals of this document. These
goals are:
* That the authoring tool be accessible
* That the authoring tool generate accessible content by default
* That the authoring tool encourage the creation of accessible
content
The three priority levels are assigned as follows:
[Priority 1]
If the checkpoint is essential to meeting those goals
[Priority 2]
If the checkpoint is important to meeting those goals
[Priority 3]
If the checkpoint is beneficial to meeting those goals
[Relative Priority]
Some checkpoints talk about production, generation, checking
etc of various content that have different priorities in WCAG.
The priority for these checkpoints in ATAG varies according to
the priority of the checkpoints in WCAG.
Relative Priority is used for ATAG checkpoints which relate to
different types of content, to ensure that the priority of each
feature matches the priority given to the feature in WCAG, as
follows:
+ It is priority 1 to implement the checkpoint for content
features which are a priority 1 requirement in WCAG.
+ It is priority 2 to implement the checkpoint for content
features which are a priority 2 requirement in WCAG.
+ It is priority 3 to implement the checkpoint for content
features which are a priority 3 requirement in WCAG.
For example, checking for accessibility errors (4.1) has
relative priority. This means that it is priority 1 for a tool
to check for accessibility errors that are
[WEB-CONTENT-PRIORITY] Priority 1, but priority 2 to check for
accessibility errors that are [WEB-CONTENT-PRIORITY] Priority
2.
2 Guidelines
Guideline 1. Support accessible authoring practices
Methods for ensuring accessible markup vary with different markup
languages. If markup is automatically generated, many authors will be
unaware of the accessibility status of the final product unless they
expend extra effort to make appropriate corrections by hand. Since
many authors are unfamiliar with accessibility, the onus is on the
authoring tool to generate accessible markup, and where appropriate,
to guide the author in producing accessible content.
Many applications feature the ability to convert documents from other
formats (e.g., Rich Text Format) into a markup format, such as HTML.
Markup changes may also be made to facilitate efficient editing and
manipulation. These processes are usually hidden from the user's view
and may create inaccessible markup or cause inaccessible markup to be
produced.
Checkpoints:
1.1 Ensure that the author can produce accessible content in the
markup language(s) supported by the tool. [Priority 1]
+ Provide options for accessibility information such as
equivalent alternatives to be included whenever an object is
added to a document. Refer also to checkpoint 3.1.
+ Allow direct source editing (but note also the requirements
in 1.4 and 5.1)
+ Most image formats, including PNG, SVG, WebCGM, and GIF allow
the inclusion of text content. Where it is available in the
format this feature should be used by authoring tools.
+ Many formats for audio or video allow for the use of
alternative content.
+ General: Web Content Accessibility Guidelines 1.0
[WAI-WEBCONTENT]
+ Techniques for Web Content Accessibility Guidelines 1.0
[WAI-WEBCONTENT-TECHS]
+ The Web Accessibility Initiative publishes a series of notes
on the accessibility features of different W3C
specifications. Notes are currently available for
1. CSS2 [CSS2-ACCESS]
2. HTML 4.0 [HTML4-ACCESS]
3. SMIL [SMIL-ACCESS]
Working drafts are available for
1. SVG [SVG-ACCESS]
In each case the specifications themselves also provide
information.
+ Amaya implements all of the accessibility features of HTML.
The CSS cascade order, an accessibility feature of CSS2, is
yet to be completely implemented.
+ An audio/video editing suite can use SMIL to separate audio,
video, descriptive signing and text tracks.An audio/video
editing suite can use SMIL to separate audio, video,
descriptive signing and text tracks.
+ Sketch allows the author to group, or change the groups of
graphic elements, use plain text rather than images of text,
and other accessibility features (in its own language - this
does not work in SVG yet). But it does not provide a
mechanism for associating alternative content with an image.
+ Word allows alternative text to be provided for images, and
alternative images to be provided for videos (sound has not
been checked). The Author can create structured content
easily using style sheets, provides language information
(grammar checking, readability checking, etc.)
1.2 Ensure that the tool generates markup that conforms to the W3C's
Web Content Accessibility Guidelines [WAI-WEBCONTENT].
[Relative Priority]
+ Use consistent document structures. For a tool which does
site-wide management provide consistent navigation systems
and document structures.
+ Include markup which supports alternatives for
media-dependent elements or content.
+ Do not use structural markup for presentational effects, or
presentation markup for known structures. For example, use
list markup of an appropriate type rather than creating
multiple line paragraphs and beginning each line with an
image of a bullet, and do not use list markup for an
indentation effect.
+ Do not publish Web content in markup languages which do not
allow for alternative information to be included for
media-specific presentations (such as images or video, sound,
etc).
+ The Web Accessibility Initiative's Protocols and Formats
group have a draft set of notes about creating accessible
document types [XMLGL].
+ Amaya implements each supported recommendation according to
the specifications.
+ New document types are constantly being developed, and in
many cases offer improvements to the structure and utility of
Web content. In implementing a new or extended document type
it is important to ensure that a tool does not remove access
to information that had been inherent in the base document
type.
The same can apply to a reduced DTD. For example, producing a
DTD that did not include the "alt" attribute for IMG, or
effectively working to such a DTD by not implementing a means
to include the attribute, compromises the accessibility of
any included IMG elements.
+ Amaya generates markup that conforms to level-A, and allows
the author to generate markup that is triple-A through the
user interface.
+ Sketch does not conform to this checkpoint because it does
not provide a mechanism for associating alternative content
with images, although it does provide for the separation of
style, and the production of structured documents.
+ Word uses styles, can produce structured documents (but for
some reason does not always), can keep alternatives for
images or videos.
1.3 Ensure that templates provided by the tool conform to the Web
Content Accessibility Guidelines [WAI-WEBCONTENT].
[Relative Priority]
+ Produce accessible representations for site maps generated by
the authoring tool.
+ Provide equivalent alternatives for all non-text content
(images, audio, etc)
+ Use consistent navigation schemata
+ Ensure that event-handlers for scripts are device-independent
+ Ensure that color schemes provide sufficient contrast for
people or technology with poor color separation
+ Ensure that the natural language of the template is
identified
+ Provide navigation bars
+ Provide keyboard shortcuts for important links, etc.
+ Amaya has just introduced templates, which will be checked
for conformance to Web Content Accessibility Guidelines.
+ Sketch does not provide templates.
+ Word provides templates for blank pages. Templates such as
brochures are well-structured, but lack alternative content
for images.
1.4 Ensure that the tool preserves all accessibility information
during authoring, transformations and conversions. [Priority 1]
+ When transforming a table to a list or list of lists, ensure
that table headings are transformed into headings, and
summary or caption information is retained as rendered
content. (This transformation is not necessarily cleanly
reversible)
+ When importing images with associated descriptions to an HTML
document make the descriptions available for use as longdesc,
alt, or title
+ When converting from a word-processor format to HTML ensure
that headings and list items are transformed into appropriate
headings of the appropriate level, and list items in the
appropriate type of list (rather than as plain text with font
formatting)
+ Do not transform text into images - use style sheets for
presentation control, or an XML application such as Scalable
Vector Graphics that keeps the text as text. If this is not
possible, ensure that the text that is converted is available
as "alt-text" for the image.
+ Ensure that the tool recognizes and preserves elements that
are defined in the relevant specification(s) even if it is
unable to render them in a publishing view or preview mode.
This is relevant for WYSIWYG page authoring tools, tools that
handle image formats which allow the incorporation of titles,
descriptions, etc.
+ When converting linked elements such as footnotes or endnotes
either provide them as inline content or or maintain two-way
linking. In HTML this should be hypertext links rather than
plain-text references.
+ 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.
+ Sketch uses its own internal representation, and loses
information converting it to SVG. When the SVG implementation
is complete this should occur naturally, since it is possible
to convert the information between different formats.
+ Word keeps some information, such as alt attributes for img
elements, but loses some information, such as certain heading
levels, list structure, longdesc attributes, etc. in
converting from one format to another.
Guideline 2. Generate standard markup
Conformance with standards promotes interoperability and
accessibility. Where applicable use W3C Recommendations, which have
been reviewed to ensure accessibility and interoperability. If there
are no applicable W3C Recommendations, use a published standard that
enables accessibility.
Checkpoints:
2.1 Use the latest versions of W3C Recommendations when they are
available and appropriate for a task. [Priority 2]
These specifications have undergone review specifically to
ensure that they do not compromise, and where possible they
enhance, accessibility.
+ When creating documents or document types, make full use of
W3C Recommendations (Specifications that have been approved
by the W3C. These specifications have undergone review
specifically to ensure that they do not compromise, and where
possible they enhance, accessibility). For example when
creating mathematical content for the Web use MathML rather
than another markup language. Use applicable HTML structures.
+ Ensure that the tool recognizes and preserves elements which
are defined in the relevant specification(s) even if it is
unable to render them. This is particularly important for
WYSIWYG editing tools.
+ Amaya supports HTML 4.0 [HTML40]], 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].
+ Sketch has a very basic experimental implementation of
Scalable Vector Graphics [SVG].
+ Word uses XML namespaces. However the markup generated is not
always well-formed XML.
2.2 Ensure that the tool generates valid markup. [Priority 1]
This is necessary for user agents to be able to transform Web
content to a presentation appropriate to a particular user's
needs.
+ Produce valid HTML/XML
+ Publish proprietary DTDs on the Web, to allow documents to be
validated.
+ Use namespaces and schemas to make documents which can be
automatically transformed to a known document type.
+ Amaya implements each language according to the published
specifications.
+ Sketch seems to do this.
+ Word generates content for its own namespaces (presumably it
does this correctly).
2.3 If markup generated by the tool differs from W3C specifications,
inform the author. [Priority 3]
This allows the author to choose to conform.
+ Amaya markup conforms to W3C specifications (except for some
bugs)
+ Sketch does not conform to this checkpoint. It could note in
documentation which formats are W3C specifications, and the
differences between them.
+ Word does not do this.
Guideline 3. Support the creation of accessible content
Generating equivalent information, such as textual alternatives for
images and audio descriptions of video, can be one of the most
challenging aspects of Web design. Along with the necessity for
structural information it is a cornerstone of accessible design,
allowing information to be presented in a way most appropriate for the
needs of the user without constraining the creativity of the author.
Automating the mechanics of this process, by prompting authors to
include the relevant information at appropriate times, can greatly
ease the burden for authors. Where such information can be
mechanically determined (e.g., the function of icons in an
automatically-generated navigation bar, or expansion of acronyms from
a dictionary) and offered as a choice for the author the tool will
assist the author, at the same time as it reinforces the need for such
information and the author's role in ensuring that it is used
appropriately in each instance.
Checkpoints:
3.1 Assist the author in providing alternative information (e.g.,
captions, long descriptions of graphics). [Relative Priority]
+ When a multimedia object is inserted, prompt the author for
relevant alternatives: functional replacement and long
description for images, text captions (as text or as a URI),
video of signed translations for audio, audio descriptions
for video (as well as alternatives for its audio components).
+ Provide an author with the option of specifying alternative
information, or electing to insert null alternative
information for images, audio, video. Default to an
accessibility error such as no "alt" attribute for images.
+ When video is inserted, prompt the author for a still image
as part of the alternative content.
+ Amaya prompts the author to provide alt text for IMG and
AREA, and CAPTION for TABLE.
+ Sketch does not seem to do this. It is possible to extend the
user interface (the documentation describes how to do this)
and adding the facility to provide title and descriptions to
images or graphic components would be a possible strategy to
satisfy the component.
+ Meeting 3.5 would provide much of the required functionality
Refer also to checkpoint 4.1..
+ Word does not seem to do this.
+ Refer also to checkpoint 3.5., Refer also to checkpoint 6.2.
3.2 Help the author create structured content and separate information
from its presentation. [Relative Priority]
+ Recognize collections of upper-case letters (in languages
that have case) and prompt the author for an expansion, to be
provided in markup.
+ In Japanese, Chinese, and other appropriate languages, prompt
the author for kana text that can be used as a ruby for
unusual kanji or kanji groups.
+ Prompt the author for header information for tabular data.
+ Prompt the author (and allow them to specify a default
suggestion) for the language of a document.
+ Amaya will prompt the author for title for ABBR, ACRONYM,
OBJECT, longdesc for IMG 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.
+ Sketch's user interface guides the author to create
structured graphics, and its own language supports this.
+ Word's outline view guides the author to create structured
content. Some structure transformations are done right and
others are converted to presentation markup.Word help in some
cases guides the author to provide structure, while in other
cases focuses completely on presentation at the expense of
structure.
3.3 Ensure that prepackaged content conforms to Web Content
Accessibility Guidelines [WAI-WEBCONTENT]. [Relative Priority]
For example include synchronized text and audio equivalents
with movies. Refer also to checkpoint 3.4.
+ Use formats that allow for accessible annotation to be
included in the files, such as SMIL, PNG and SVG.
+ Provide long descriptions, and associated text files with
appropriate "alt-text" in clip-art collections.
+ Provide video description files with prepackaged video.
+ Provide text caption files for prepackaged audio, or video
with audio track(s).
+ Including pre-written descriptions for all multimedia files
(e.g., clip-art) packaged with the tool would save users time
and effort, cause a significant number of professionally
written descriptions to circulate on the Web, provide users
with convenient models to emulate when they write their own
descriptions and show authors the importance of description
writing.
+ Amaya does not provide any clip art
+ Sketch examples do not yet conform.
+ Word clip art does not have alternative information.
+ Refer also to checkpoint 3.5.
3.4 Do not insert automatically generated or place-holder equivalent
alternatives. [Priority 1]
For example, in an automatically generated navigation bar,
"search" may be appropriate alternative information for a
button linked to a search function, but the filename of an
image should not be inserted as a default.
Note. Human-authored content may be available for an object
whose function is known with certainty. Refer also to
checkpoint 3.5 Provide a mechanism to manage alternative
information for multimedia objects, that retains and offers for
editing pre-written or previously linked alternative
information. [Priority 3] and checkpoint 3.3 Ensure that
prepackaged content conforms to Web Content Accessibility
Guidelines [WAI-WEBCONTENT]. [Relative Priority] .
+ Items used throughout a Website, such as graphical navigation
bars, should have standard alternative information. However
the author should be prompted to edit or approve this the
first time it is used in a site, and when the destination of
the links is changed by the author.
+ If the author has not specified alternative text for an IMG,
or specified that none is required, default to having no alt
attribute, so that an accessibility problem will be noted.
Refer also to checkpoint 4.1.
+ Amaya does not provide default alt text except when copying
and pasting images, in which case it copies all attributes
with the image.
+ Sketch conforms to this checkpoint.
+ Word conforms to this checkpoint
3.5 Provide a mechanism to manage alternative information for
multimedia objects, that retains and offers for editing
pre-written or previously linked alternative information.
[Priority 3]
+ Maintain a database registry that associates object identity
information with alternative information. Whenever an object
is used and alternative information is provided, ask the
author whether they want to add the object (or identifying
information) and the alternative information to the database.
In the case of alt-text the alternate information might be
stored directly while a longer descriptions such as video
captions would be entered as pointers to external files.
Allow different alternative information to be associated with
a single object.
+ 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]).
+ Suggest pre-written descriptions as default text whenever one
of the associated files is inserted into the author's
document.
+ The use of RDF, or formats like SVG can enable a tool to
maintain and use libraries of information within the tool and
on the Web.
+ This checkpoint is prioritized as a level 3, meaning that in
itself, it does not have a critical effect on an authoring
tool's likelihood of producing accessible mark-up. However,
several limited extensions to this alternative information
management mechanism (AIMM) have the potential to
simultaneously meet several higher priority checkpoints and
dramatically improve the usability of an access aware
authoring tool. In particular:
1. The AIMM should maintain a list of associations between
object file names and authored responses to prompts for
alternative information (as per 3.1). The alternative
information may take the form of short strings (i.e.
"alt"-text) or pointers to descriptive files (i.e.,
"longdesc", transcripts, etc.). Multiple associations
for the same object for different languages or contexts
should also be handled.
2. The AIMM would offer the associated alternative
information as a default whenever the appropriate
associated object is selected for insertion. If no
previous association is found, the field should be left
empty (i.e., no purely rule-generated alternative
information should be used). Note. The term "default"
implies that the alternative information is offered for
the author's approval. The term does not imply that the
default alternative information is automatically placed
without the author's approval. Such automatic placement
may only occur when in situations where the function of
the object is known with certainty, as per checkpoint
3.4 Do not insert automatically generated or
place-holder equivalent alternatives. [Priority 1] .
Such a situation might arise in the case of a
"navigation bar builder" that places a navigation bar at
the bottom of every page on a site. In this case, it
would be appropriate to use the same "alt"-text
automatically for every instance of a particular image
(with the same target) on every page.
3. The alternative information mechanism should be closely
integrated with the pre-written alternative information
provided for all packaged multimedia files, as per 3.3.
This would allow the alternative information to be
automatically retrieved whenever the author selected one
of the packaged objects for insertion. An important
benefit of the system would be the ease of adding a
keyword search capability that would allow efficient
location of multimedia based on its alternative
information.
+ 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.
+ Sketch does not do this directly, but implementing SVG means
that the alternative content is automatically available as
part of each graphic component or image, so using any library
of SVG (for example the collection of available files) which
conforms to 3.3 will achieve this.
+ Word does not do this
Techniques for this guideline:
* Extensive examples that cover a number of these checkpoints are
provided in the "Sample implementations" section of the Techniques
document.
Guideline 4. Provide methods of checking and correcting inaccessible content
Many authoring tools allow authors to create documents with little or
no knowledge about the underlying markup. To ensure accessibility,
authoring tools must be designed so that they can automatically
identify inaccessible markup, and enable its correction even when the
markup itself is hidden from the author.
In supporting the creation of accessible Web content, authoring tools
should take into account the differing authoring styles of their
users. In general, authors will prefer to be able to configure their
tools to support their working style. Tools that allow such
configuration can help authors to feel that accessible authoring is a
natural practice (refer also to the previous guideline) rather than an
intrusion on their normal work pattern. For example some users may
prefer to be alerted to problems when they occur, whereas others may
prefer to perform a check after the document is completed. This is
analogous to programming environments that allow users to decide
whether to check for correct code during editing or at compile time.
Note. Many assistive technologies used with browsers and multimedia
players are only able to provide access to Web documents that use
valid mark-up. Therefore validation of mark-up is an essential aspect
of authoring tool accessibility.
Checkpoints:
4.1 Check for and alert the author to accessibility problems.
[Relative Priority]
Some accessibility problems cannot be detected automatically,
and will require the user to make decisions.
+ Include alerts for [WEB-CONTENT-PRIORITY] Priority 1
checkpoints in the default configuration.
+ Highlight problems detected when documents are opened, when
an editing or insertion action is completed, or while an
author is editing. Using CSS classes to indicate
accessibility problems will enable the author to easily
configure the presentation of errors.
+ Where there is a change in the writing script used, prompt
the author to identify whether there has been a change in
language
+ Alert authors to accessibility problems when saving.
+ Access concerns can be highlighted using strategies similar
to spell checking within a word processor. Access alerts
within the document can be linked to context sensitive help.
+ Allow users to choose different alert levels based on the
priority of authoring accessibility recommendations.
+ If interruptive warnings are used, provide a means for the
author to quickly set the warning to non-obtrusive to avoid
frustration.
+ A view that renders the document as it might appear without
technologies such as style sheets and images enabled, or the
ability to turn those features off and on in the editing
view, will give an author some idea of whether a document's
logical order has been correctly preserved, whether
alternative text is appropriate, etc.
+ The WAI Evaluation and Repair group [WAI-ER] is developing a
document that discusses which aspects of the Web Content
Accessibility Guidelines can be automatically tested. A draft
of that document is available [AUTO-TOOL].
+ There are online tools whose output can be integrated with
the user interface. Other tools are available for
incorporation in existing software, either as licensed
products or in some cases as "open source" solutions. The WAI
Evaluation and Repair group maintains information about
available tools [WAI-ER].
+ Amaya currently checks for validity, but the author can only
find warning of invalid markup in the structure view. The
team is investigating automating an accessibility check and
author notification. Where Amaya detects an error it
identifies and highlights the offending code in the structure
view, allowing the author to delete it.
+ Sketch does not conform to this checkpoint. It could identify
image components that did not have associated alternative
content (Priority 1 requirement).
+ Word has spell and grammar check, but no validity or
accessibility
4.2 Assist authors in correcting accessibility problems.
[Relative Priority]
At a minimum, provide context-sensitive help with the
accessibility checking required by 4.1
+ Do this in a way that is consistent with the look and feel of
the authoring tool.
+ Provide context sensitive-help for accessibility errors.
Refer also to 6.
+ Where there are site-wide errors, to make correction more
efficient the author can be given the choice to make
site-wide changes or corrections. For example this may be
appropriate for a common error in markup, but may not be
appropriate in providing alt text that is appropriate for one
use of na image but completely inappropriate for the other
uses of the image on the same site (or even the same page).
+ Allow authors to control both the nature and timing of the
correction process.
+ Amaya currently does not implement this checkpoint. Amaya
uses its own internal representation for the document markup
that is translated 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.
+ Sketch does not conform to this checkpoint. It could provide
help or explanation when it noted each accessibility problem
+ Word assists correcting spelling or grammar.
4.3 Allow the author to preserve markup not recognized by the tool.
[Priority 2]
Note. The author may have included or imported markup that is
not recognized by the tool, but which enhances accessibility.
+ Provide a summary of all automated structural changes that
may affect accessibility.
+ Provide options for the author to confirm or override removal
of markup on a change-by-change basis or as a batch process.
+ Do not change the DTD without notifying the author.
+ Amaya currently does not implement this checkpoint.
+ Sketch does not conform to this checkpoint. It could conform
by providing an option to preserve markup on loading a
document (although editing may cause
+ Word sometimes warns that information will be lost (allowing
the author to cancel the transformation), and sometimes it
doesn't.
4.4 Provide the author with a summary of the document accessibility
status. [Priority 3]
+ Provide a summary of accessibility problems remaining by type
and/or by number.
+ Amaya currently does not implement this checkpoint.
+ Word does not conform to 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 that is stylistic into style sheet markup.
[Priority 3]
+ Some examples of transformations include: HTML table-based
layout into CSS, HTML br to p, HTML (deprecated) FONT into
heuristically or author-determined structure, Word processor
styles to Web styles, HTML deprecated presentational markup
into CSS, SPAN into RUBY, MathML presentational markup to
semantic markup.
+ Allow the user to define transformations for imported
documents that have presentation, rather than structural,
markup.
+ Allow the user to create style rules based on the formatting
properties of an element, and then apply the rule to other
elements in the document, to assist conversion of documents
to the use of style sheets
+ Include pre-written transformations to rationalize multiple
tables, and to transform (deprecated) presentation HTML into
style sheets.
+ Remember that accessibility information, including attributes
or properties of the elements being transformed, must be
preserved - see 1.4
+ Amaya provides a language for specifying structure
transformations, along with a large number of transformations
being included.
+ Sketch would do this by allowing fonts and style sheets (as
opposed to simply inline styles) to be generated. I am not
sure if this is implemented, although the theory is explained
in documentation. For more information on how this is done
see the relevant section of the SVG specification [SVG] or
"Accessibility features of SVG" [SVG-ACCESS].
+ Word allows the author to do this directly through prominent
user interface features, as well as through the search and
replace mechanism, and through macro scripting.
Techniques for this guideline:
* Prompts can be used to encourage authors to provide information
needed to make the content accessible (such as alternative textual
representations). Prompts are simple requests for information
before a markup structure has been finalized. For example, an
"alt-text" entry field prominently displayed in an image insertion
dialog would constitute a prompt. Prompts are relatively
unintrusive and address a problem before it has been committed.
However, once the user has ignored the prompt, its message is
unavailable.
Alerts warn the author that there are problems that need to be
addressed. The art of attracting users' attention is a tricky
issue. The way users are alerted, prompted, or warned can
influence their view of the tool and even their opinion of
accessible authoring. Refer also to 5.
User Configurable Schedule
A user configurable schedule allows the user to determine
the type of prompts and alerts that are used, including
when they are presented. For example, a user may wish to
include multiple images without being prompted for
alternative information, and then provide the alternative
information in a batch process, or may wish to be
reminded each time they add an image. If the prompting is
done on a user configurable schedule they will be able to
make that decision themselves. This technique allows a
tool to suit the needs a wide range of authors.
Interruptive Alerts
Interruptive alerts are informative messages that
interrupt the edit process for the user. For example,
interruptive alerts are often presented when a user's
action could cause a loss of data. Interruptive alerts
allow problems to be brought to the user's attention
immediately. However, users may resent the constant
delays and forced actions. Many people prefer to finish
expressing an idea before returning to edit its format.
Unintrusive Alerts
Unintrusive alerts are alerts such as icons, underlines,
and gentle sounds that can be presented to the user
without necessitating immediate action. for example, in
some word processors misspelled text is highlighted
without forcing the user to make immediate corrections.
These alerts allow users to continue editing with the
knowledge that problems will be easy to identify at a
later time. However, users may become annoyed at the
extra formatting or may choose to ignore the alerts
altogether.
Guideline 5. Integrate accessibility solutions into the overall "look and
feel"
When a new feature is added to an existing software tool without
proper integration, the result is often an obvious discontinuity.
Differing color schemes, fonts, interaction styles and even
application stability can be factors affecting user acceptance of the
new feature.
Checkpoints:
5.1 Ensure that functionalities related to accessible Authoring
practices are integrated into the tool. [Priority 2]
+ Ensure that author can utilize the tool's accessible
authoring features by the same interaction styles used for
other features in the program. For example, if the tool makes
use of onscreen symbols such as underlines or coloration
change rather than dialogs for conveying information, then
the same interface techniques should be used to convey
accessibility information.
+ The same fonts, text sizes, colors, symbols, etc. that
characterize other program features should also characterize
those dealing with accessibility.
+ Include considerations for accessibility - such as the "alt"
and "longdesc" attributes of the IMG element - right below
the "src" attribute in a dialogue box, not buried behind an
"Advanced..." button.
+ Allow efficient and fast access to accessibility-related
settings with as few steps as possible needed to make any
changes that will generate accessible content.
+ The accessibility features should be designed as integral
components of the authoring tool application, not plug-ins or
other peripheral components that need to be separately
obtained, installed, configured or executed
+ The default installation of the authoring tool should include
all accessibility features enabled. The author may have the
option to disable these features later on.
+ A help page that describes how to make an image map should
include adding alternative information for each AREA in the
MAP as part of the process. Any examples of code should give
either block content with text links, or AREA elements that
all have relevant ALT attribute values.
+ When a user creates a frameset, suggest the main content page
and a navigation bar as the content for NOFRAMES.
+ 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.
+ Sketch conforms to this checkpoint to the extent that it
provides accessibility features.
+ Word integrates most of the accessibility features it has:
style/structure, alt text, etc. Source editing is passed to
another application.
5.2 Ensure that the [WEB-CONTENT-PRIORITY] Priority 1 accessible
authoring practices are among the most obvious and easily
initiated by the author. [Priority 2]
+ When the user has selected text to format, the use of CSS
should be emphasized rather than FONT.
+ Highlight the most accessible solutions when presenting
choices for the author.
+ If there is more than one option for the author, and one
option is more accessible than another, place the more
accessible option first and make it the default. For example,
when requesting alternative information for an image, offer
an unchecked option for empty alternative (i.e., alt="",
implying the image has no real function) with the cursor
positioned in the text entry for an "alt" value (and if
available provide the appropriate value from the "alt text
registry" - see 3.5), rather than offering the filename as a
default suggestion, or selecting the null "alt" value as a
default.
+ Amaya's user interface guides the author to produce
structured content, with presentation elements separated into
style sheets.
+ Sketch conforms to this checkpoint to the extent that it
provides accessibility features - grouping controls are part
of the standard toolbar, and style operations are available
from the standard menus.
+ Word does this with some features such as style, and to a
lesser extent outlining. Adding alternative content requires
knowing about it.
Guideline 6. Promote accessibility in help and documentation
The issues surrounding Web accessibility are often unknown to Web
authors. Help and documentation should explain accessibility problems
and solutions, with examples.
Checkpoints:
6.1 Document all features that promote the production of accessible
content. [Priority 1]
+ Ensure that accessibility solutions are present in all help
text descriptions of markup practices (e.g., IMG elements
should appear with "alt-text" and a "longdesc" attribute
wherever appropriate).
+ Ensure that electronic documentation complies with the Web
Content Accessibility Guidelines [WAI-WEBCONTENT]
+ Link from help text to any automated correction utilities.
+ Provide examples of accessible design practices in online
tutorials.
+ Include help documentation for all accessible authoring
practices supported by the tool.
+ Link those mechanisms used to identify accessibility problems
(e.g., icons, outlining or other emphasis within the user
interface) to help files.
+ 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. Some pages need to
be updated.
+ Sketch conforms to this checkpoint to the extent that it
provides accessibility features.
+ Word attempts to document all accessibility features. A
thorough review will make it clear whether this has been
done.
6.2 Ensure that creating accessible content is a naturally integrated
part of the documentation, including examples. [Priority 2]
+ In help text, when explaining the accessibility barriers of
non-deprecated elements, emphasize appropriate solutions
rather than explicitly discouraging the use of the element.
+ Explain the importance of utilizing accessibility features
generally and for specific instances.
+ Take a broad view of accessibility-related practices; for
example, do not refer to ALT text as being "for blind users"
but rather as "for users who are not viewing images".
+ Avoid labelling accessibility features of the tool with a
"handicapped" icon, as this can give the impression that
accessible design practices only benefit disabled users.
+ In help text, emphasize accessibility features that benefit
multiple groups. In particular the principles of supporting
flexible display and control choices have obvious advantages
for the emergence of hands free, eyes-free, voice-activated
browsing devices such as Web phone, the large number of slow
Web connections, and Web users who prefer text-only browsing
to avoid "image clutter".
+ Provide examples of all accessibility solutions in help text,
including those of lower [WEB-CONTENT-PRIORITY].
+ Implement context-sensitive help for all special
accessibility terms as well as tasks related to
accessibility.
+ Document the tool's conformance to the Authoring Tool
Accessibility Guidelines [WAI-AUTOOLS].
+ Include current versions of, or links to relevant
specifications in the documentation (e.g. HTML 4.0 [HTML40],
CSS [CSS2].) This is particularly relevant for markup
languages which are easily hand edited, such as most XML
languages.
+ Include a tutorial specifically on checking for and
correcting Web accessibility problems.
+ Link to or provide URIs for more information on accessible
Web authoring, such as Web Content Accessibility Guidelines
[WAI-WEBCONTENT], and other accessibility-related resources.
+ Accessible authoring features are added to the documentation
as they are incorporated into Amaya, as part of the normal
documentation of the relevant feature.
+ Ensure that documentation examples conform to the Web Content
Accessibility Guidelines [WAI-WEBCONTENT].
+ Clearly label any examples that display practices that reduce
accessibility.
+ Sketch conforms to this checkpoint to the extent that it
provides accessibility features.
+ Word documentation includes integrated accessibility
requirements in some areas, but some areas need further work.
6.3 In a dedicated section, document all features of the tool that
promote the production of accessible content. [Priority 3]
+ Amaya does not currently implement this checkpoint. An
accessibility section will be provided in the next release
version.
+ Sketch does not conform to this checkpoint.
+ Word documentation has a dedicated accessibility section.
Guideline 7. Ensure that the Authoring Tool is Accessible to Authors with
Disabilities
The authoring tool is a software program with standard user interface
elements and as such should follow relevant user interface
accessibility guidelines. In addition to applicable general interface
accessibility guidelines there are interface design considerations
that are specific to Web authoring tools.
One such consideration is that the author may need a different
presentation to edit the Web content than the one they wish ultimately
to be displayed. This implies display preferences that do not manifest
themselves in the ultimate markup or style declarations.
Another consideration relates to the process of navigating and
manipulating the document while authoring. Authoring Web content
requires editing a potentially large and complex document. In order to
edit a document the author must be able to locate and select specific
elements, efficiently traverse the document, and quickly find and mark
insertion points. Authors who use screen readers, refreshable braille
displays, or screen magnifiers can make limited use (if at all) of
visual artifacts that communicate the structure of the document and
act as sign posts when traversing the document. Authors who use
keyboard and mouse alternatives must make tiring repetitions of
movement commands to navigate the document. There are strategies that
make it easier to navigate and manipulate a marked-up document. Using
the structure of a Web document, the author can be given a view of the
document which allows the author to both get a good sense of the
overall document and to navigate that document more easily.
Checkpoints:
7.1 Use all applicable operating system and accessibility standards
and conventions (Priority 1 for standards and conventions which
are essential to accessibility, Priority 2 for those that are
important to accessibility, Priority 3 for those that are
beneficial to accessibility). [Priority 1]
+ Guidelines for specific platforms include
1. "IBM Guidelines for Writing Accessible Applications
Using 100% Pure Java" [JAVA-ACCESS] R. Schwerdtfeger,
IBM Special Needs Systems.
2. "An ICE Rendezvous Mechanism for X Window System
Clients" [ICE-RAP], W. Walker. A description of how to
use the ICE and RAP protocols for X Window clients.
3. "Information for Developers About Microsoft Active
Accessibility" [MSAA] Microsoft Corporation.
4. "The Inter-Client communication conventions manual"
[ICCCM]. A protocol for communication between clients
in the X Window system.
5. "Lotus Notes accessibility guidelines" [NOTES-ACCESS]
IBM Special Needs Systems.
6. "Java accessibility guidelines and checklist"
[JAVA-CHECKLIST] IBM Special Needs Systems.
7. "The Java Tutorial. Trail: Creating a GUI with
JFC/Swing" [JAVA-TUT]. An online tutorial that describes
how to use the Swing Java Foundation Class to build an
accessible User Interface.
8. "Macintosh Human Interface Guidelines" [APPLE-HI] Apple
Computer Inc.
9. "The Microsoft Windows Guidelines for Accessible
Software Design" [MS-SOFTWARE]. Warning! This is a
"self-extracting archive", an application that will
probably only run on MS-Windows systems.
+ Guidelines for specific software types include
1. "The Three-tions of Accessibility-Aware HTML Authoring
Tools" [ACCESS-AWARE], J. Richards.
2. "User Agent Accessibility Guidelines (Working Draft)" J.
Gunderson, I. Jacobs eds. (This is a work in progress)
[WAI-USERAGENT]
+ General guidelines for producing accessible software include:
1. "Accessibility for applications designers" [MS-ENABLE]
Microsoft Corporation.
2. "Application Software Design Guidelines" [TRACE-REF]
compiled by G. Vanderheiden. A thorough reference work.
3. "Designing for Accessibility" [SUN-DESIGN] Eric Bergman
and Earl Johnson. This paper discusses specific
disabilities including those related to hearing, vision,
and cognitive function.
4. "EITAAC Desktop Software standards" [EITAAC]] Electronic
Information Technology Access Advisory (EITACC)
Committee.
5. "Requirements for Accessible Software Design" [ED-DEPT]
US Department of Education, version 1.1 March 6, 1997.
6. "Software Accessibility"> [IBM-ACCESS] IBM Special Needs
Systems
7. "Towards Accessible Human-Computer Interaction"
[SUN-HCI] Eric Bergman, Earl Johnson, Sun Microsytems
1995. A substantial paper, with a valuable print
bibliography.
8. "What is Accessible Software" [WHAT-IS] James W.
Thatcher, Ph.D., IBM, 1997. This paper gives a short
example-based introduction to the difference between
software that is accessible, and software that can be
used by some assistive technologies.
+ User Interfaces are sometimes built as Web content, and as
such should follow the Web Content Accessibility Guidelines
[WAI-WEBCONTENT]. Refer also to 1.
+ The following are common requirements for producing
accessible software. This list does not necessarily cover all
requirements for all platforms, and items may not be
applicable to some software.:
Following Standards
o Draw text and objects using system conventions
o Make mouse, keyboard, and API activation of events
consistent
o Provide a User Interface that is "familiar" (to system
standards, or across platform)
o Use system standard indirections and APIs wherever
possible
o Ensure all dialogs, subwindows, etc meet these
requirements
o Avoid blocking assistive technology functions
(sticky/mouse keys, screenreader controls, etc) where
possible
Configurability
o Allow users to create profiles
o Allow control of timing, colors, sizes, input/output
devices and media
o Allow users to reshape the user interface - customize
toolbars, keyboard commands, etc
Input Device Independence
o Provide Keyboard access to all functions
o Document all keyboard bindings
o Provide customizable keyboard shortcuts for common
functions
o Provide logical navigation order for the keyboard
interface.
o Avoid repetitive keying wherever possible
o Provide mouse access to functions where possible
Icons, Graphics, Sounds
o Provide visual (text) equivalents for sound warnings
o Allow sounds to be turned off
o Provide text equivalents for images/icons
o Use customizable (or removable) colors/patterns
o Ensure high contrast is available (as default setting)
o Provide text equivalents for all audio
o Use icons that are resizeable or available in multiple
sizes
Layout
o Do not rely on color alone for meaning. Use color for
differentiation, in combination with accessible cues
(text equivalents, natural language, etc)
o Position related text labels and objects consistently,
and in an obvious manner (labels before objects is
recommended)
o Group related controls
o Ensure default window sizes fit in screen
o Allow for window resizing (very small to very large)
User Focus
o Clearly identify the user focus (and expose it via API)
o Unexpected events should not be caused by viewing
content (for example by moving the focus to a new point)
o Allow user control of timing - delays, time-dependent
response, etc
o Allow for navigation between as well as within windows
2.7.1 Documentation
o Provide documentation for all features of the tool
o Ensure that help functions are accessible
+ Amaya is currently available for two platforms: Unix and
Windows. There is some work required on both platforms to
bring it into line with conventions, in particular to provide
conformance with the User Agent Guidelines [WAI-USERAGENT],
and to implement Microsoft Active Accessibility [MSAA]. It is
being re-written to take advantage of the improved
accessibility support possible in Gnome (it currently uses
Motif) in the Unix version. The Documentation is all
available online and has been reviewed to ensure it conforms
to Web Content Accessibility Guidelines [WAI-WEBCONTENT].
+ Sketch uses standard APIs, provides help documentation which
is (for the most part, but not completely) accessible, but
fails to provide full accessibility to some functions.
+ Word seems to conform to this checkpoint well.
7.2 Allow the author to change the presentation within editing views
without affecting the document markup. [Priority 1]
This allows the author to edit the document according to their
personal requirements, without changing the way the document
looks or is rendered when published.
+ In representing the source structure of a document mark
elements with textual brackets rather than purely graphic
representations. For example "</>" is regarded as a textual
bracket, since it is made of character elements.
+ Allow the user to create audio style sheets using a visual
representation rather than an audio one (with accessible
representation, of course).
+ An authoring tool that offers a "rendered view" of a
document, such as a browser preview mode, may provide an
editing view whose presentation can be controlled
independently of the rendered view.
+ A "WYSIWYG" editor may allow an author to specify a local
style sheet, that will override the "published" style of the
document in the editing view.
+ Amaya allows the user to create local style sheets, and to
enable or disable each style sheet that is linked to a
document.
+ Sketch does not conform to this checkpoint except for
allowing magnification. The required functionality could be
achieved by implementing SVG with user style sheets.
+ Word makes use of a development application for source
editing which provides various types of control. Word itself
allows magnification, use of white text on blue background
for high-contrast, and it allows Operating System settings to
control the presentation.
7.3 Allow the author to edit all properties of each element and object
in an accessible fashion. [Priority 1]
+ An authoring tool may offer several editing views of the same
document, such as a source mode which allows direct editing
of all properties.
+ Allow the author to individually edit each attribute of the
elements in an HTML or XML document, for example through a
menu. Note. This must include the ability to add values for
attributes which are not present, as well as changing current
values of attributes.
+ Amaya allows each attribute to be edited through the menu or
through the structure view. Element types can be assigned
through the menu system.
+ For a site management tool, allow the author to display a
site map in text form (e.g., as a structured tree file).
+ Allow the author to specify that filenames or alternative
information are rendered in place of images or other
multimedia content while editing.
+ Include attributes / properties of elements in a view of the
structure.
+ Provide access to a list of properties via a "context menu"
for each element.
+ Graphically represented elements cannot be identified by
assistive technologies that translate text to braille,
speech, or large print, unless there is appropriate
information available as text. For example, some HTML
authoring tools display start and end tags as graphics.
+ Sketch does not conform to this checkpoint. Currently some
properties can be edited in an accessible fashion, while
others require the use of a graphic interface.
+ Word enables editing of most properties through dialogs or
wizards. It also enables editing of the source (through
another application).
7.4 Ensure the editing view allows navigation via the structure of the
document in an accessible fashion. [Priority 1]
+ Allow the author to navigate via an "outline" or "structure"
of the document being edited. This is particularly important
for people who are using a slow interface such as a small
braille device, or speech output, or a single switch input
device. It is equivalent to the ability provided by a mouse
interface to move rapidly around the document.
+ To minimally satisfy this checkpoint, allow navigation from
element to element.
+ In a hypertext document allow the author to navigate among
links and active elements of a document.
+ For SMIL and other time-based presentations allow the author
to navigate through the presentation in time.
+ Allow the author to navigate regions of an image, or the
document tree for an image expressed in a structured language
such as Scalable Vector Graphics [SVG]
+ Amaya provides a structure view, that can be navigated
element by element, a Table of Contents view, that allows
navigation via the headings, and a links view, that allows
sequential navigation via the links in the document. It also
provides configurable keyboard navigation of the HTML
structure - parent, child, next and previous sibling
elements.
+ Sketch allows navigation of the image structure through
mouse-based selection and by the keyboard.
+ Word provides an outline view which allows user-configurable
navigation and viewing of the document structure. It also
provides a project view to manage multiple pages at once.
7.5 Enable editing of the structure of the document in an accessible
fashion. [Priority 2]
+ An authoring tool may offer a structured tree view of the
document, allowing the author to move among, select and cut,
copy or paste elements of the document.
+ A WYSIWYG tool may allow elements to be selected, and copied
or moved while retaining their structure.
+ A tool may allow transformation from one element type to
another, such as
1. HTML paragraphs to lists and back
2. HTML br to p
3. SMIL transformations between switch, excl and par
4. HTML (deprecated) FONT into heuristically determined
structure
5. Lists of lists to tables and back
6. MathML transformations between semantic and presentation
markup
7. Transforming SVG g elements to symbol
8. Giving a structural role to a part of an element, such
as an SVG g or an HTML p
+ Amaya allows the author to select elements (including
containers) and cut, copy and paste them with their
attributes and properties in any of the formatted, structure
and alternate views.
+ Sketch allows navigation of the image structure either
through mouse-based selection and by the keyboard, but
editing its properties is not always possible in an
accessible format.
+ Word's outline view is an editing view.
7.6 Allow the author to search within editing views. [Priority 2]
+ Search functions are already present in almost every text and
hypertext editing tools. The simplest allow searching for a
sequence of characters, while more powerful searches can
include the ability to perform searches which are case
sensitive or case-insensitive, the ability to replace a
search string, the ability to repeat a previous search to
find the next or previous occurrence, or to select multiple
occurrences with a single search.
+ The ability to search for a particular type of structure is
useful in a structured document, structured image such as a
complex SVG image, etc.
+ In an image editor the ability to select an area by
properties (such as colour, or closeness of colour) is
useful. This is common in middle range and high end image
processing software.
+ The ability to search a database for particular content, or
to search a collection of files at once (a simple
implementation of the latter is the Unix function "grep") is
an important tool in managing large collections, especially
those which are dynamically converted into Web content.
+ The use of metadata (as per the Web Content Accessibility
Guidelines [WAI-WEBCONTENT]) can allow for very complex
searching of large collections, or of timed presentations.
Refer also to the paper "A Comparison of Schemas for Dublin
Core-based Video Metadata Representation" [SEARCHABLE] for
discussion specifically addressing timed multimedia
presentations.
+ Amaya provides a search function. Because all document views
are synchronized, any search text found will be selected in
each of the available views.
+ Sketch does not conform to this checkpoint. An implementation
for SVG could allow the user to search for and select a text
in a text, title or desc element as well as style or graphic
properties.
+ Word has a search function which allow search of textual
content as well as various style properties or structure
types..
3 Appendix - Sample Implementations
[Editors' Note: These will be incorporated into the main body of the
techniques, and available as single documents - so far that has only
been done for the Amaya sample implementation.]
The Sample Implementations are collections of the above techniques for
a specific type of tool. They have been developed to illustrate how
the design principles embodied in the guidelines sections can be
applied in various types of authoring tool.
3.1 Amaya
Amaya [AMAYA] is the W3C's testbed Web authoring/browsing platform.
Its default editing view is WYSIWYG-style. The sample implementation
[AMAYA-SAMPLE] outlines how Amaya Release version 2.1 conforms to the
3 September 1999 draft of the guidelines, and plans for improving
conformance. Note. Amaya is developed as a proof of concept for a
number of specifications, not a product for market.
3.2 Sketch
Sketch is an open-source image editor, which is in alpha. The version
tested is 0.6.2, which provides an experimental SVG import/export
functionality, although it only implements a few SVG elements as a
proof of concept. It is written in python to enable easy user
extension (and how to do this is well-documented).
3.3 The A-prompt Tool
The A-prompt tool [APROMPT] is an example tool that allows for
checking of many accessibility features in HTML pages, and
incorporates an "alt text registry" to manage alternative information
for known resources. The tool is built in such a way that the
functions can be incorporated into an authoring tool.
3.4 Alt-Text for the HTML 4.0 IMG Element
[Editors' note: This section has not kept pace with the development of
the guidelines. It will be updated in future drafts.]
"Alt-text" is generally considered the most important aid to HTML
accessibility. For this reason, the issue of "alt-text" has been
chosen as the subject for an extended technique based on a
hypothetical implementation.
7 Ensure that the Authoring Tool is Accessible to Authors with
Disabilities
Implementation: The author can edit the document using the
alternative information of the image in its place, and can
access all the properties of the image (height, width, etc)
2 Generate standard markup
Implementation: In any markup produced, the IMG element is
always properly formed as defined in the HTML4 specification.
This means that the element contains both a "src" attribute and
an "alt" attribute.
1 Support accessible authoring practices
Implementation: Due to the [WEB-CONTENT-PRIORITY]
recommendation status of "alt-text" in the Web Content
Accessibility Guidelines, special attention will be devoted to
prompting and guiding the user toward full "alt" coverage. The
authoring tool has the capability of opening and converting
word processor documents into HTML. If an image is encountered
during this process, the user will be prompted for "alt-text".
The authoring tool sometimes makes changes to the HTML it works
with to allow more efficient manipulation. These changes never
result in the removal or modification of "alt-text" entries.
3 Support the creation of accessible content
Implementation: The authoring tool is shipped with many
ready-to-use clip art and other images. For each of these
images a short "alt-text" string and a longer description have
been pre-written and stored in an "alt-text" registry. When the
user selects one of these images for insertion, the alternative
text and long description are offered for editing and approval.
Whenever the user includes another image, the tool keeps the
reference to that image and the associated "alt-text" and long
description in the "alt-text registry". When a text alternative
offered by the tool is edited, the tool adds the new text to
the registry, and offers both entries when the image is used
again. There is an option to mark any entry as the default.
5 Integrate accessibility solutions into the overall "look and feel"
Implementation: At no point do "alt-text" requests appear on
their own or in a non-standard manner. Instead "alt-text"
notices and emphasis appear as integrated and necessary as the
"src" attribute.
4 Provide methods of checking and correcting inaccessible content
Implementation: If the user opens content or pastes in markup
containing an IMG element that lacks "alt-text", the author is
prompted to add them. The tool can be configured to prompt as
soon as an error is detected, or to provide a highlight mark
where these errors occur and to prompt when the author is
saving or publishing a document. The default prompt includes
prompting for a long description of each image.
6 Promote accessibility in help and documentation
Implementation: Whenever missing "alt-text" is flagged
(anywhere in the tool suite) the same quick explanation,
extended help, and examples are offered. The help documentation
for inserting images and image maps includes providing
alternative text as part of the necessary steps, and describes
how to determine appropriate alternative text in the same
section. Examples of images and image-maps all have alternative
text included, and images have long descriptions.
4 Terms and Definitions
Accessible, Accessibility
Within these guidelines, Accessible and Accessibility are used
in the sense of being accessible to people regardless of
disability.
To understand the accessibility issues relevant to authoring
tool design, consider that many users may be creating documents
in contexts very different from your own:
+ They may not be able to see, hear, move, or may not be able
to process some types of information easily or at all;
+ They may have difficulty reading or comprehending text;
+ They may not have or be able to use a keyboard or mouse;
+ They may have a text-only display, or a small screen.
In addition, accessible design will benefit many people who do
not have a physical disability but with similar needs. For
example they may be working in a noisy environment and unable
to hear, or need to use their eyes for another task, and be
unable to view a screen. They may be using a small mobile
device, with a small screen, no keyboard and no mouse.
Accessibility Awareness
The term accessibility awareness is used to describe an
application that has been designed to maximize the ease of use
of the interface and its products for people with differing
needs, abilities and technologies. In the case of authoring
tools, this means that (1) care has been taken to ensure that
the content produced by user-authors is accessible and (2) that
the user interface has been designed to be usable with a
variety of display and control technologies.
Accessibility Information
Accessibility information is content, including information and
markup, which is used to improve the accessibility of a
document.
Accessibility Solution, Accessible Authoring Practice
These terms refer to Authoring practices that improve the
accessibility of content generated by the tool.
Alerts
Alerts notify the author of something, or mark something for
the author's attention. They may or may not require author
response. Alerts warn the author that there are problems that
need to be addressed. The art of attracting users' attention is
a tricky issue. The way in which users are alerted, prompted,
or warned will influence their view of the tool as well as
their opinion of accessible authoring.
Alternative Presentations and Alternative Information
Certain types of content may not be accessible to all users
(e.g., images or audio presentations), so alternative
representations are used, such as transcripts for audio, or
short functionally equivalent text (e.g., "site map link")
and/or descriptive text equivalents (e.g., "Graph 2.5 shows
that the population has doubled approximately every ten years
for the last fifty years, increasing from about 10 million to
330 million in that time"). An object may have several
alternative representations, for example a video, captions of
the audio, audio description of the video, a series of still
images, and textual representations of each of these.
Attributes
in XML and HTML, an element may have any number of attributes.
In the following example, the attributes of the beverage
element are flavor, which has the value "lots", and colour,
which has the value "red": <beverage flavor="lots"
colour="red">my favorite</beverage> Some attributes are
integral to document accessibility (e.g., the "alt", "title",
and "longdesc" attributes in HTML
Authoring Tool
As used in this document, an Authoring Tool is any software
that is used to generate content for publishing on the Web.
Refer also to section 1.3 Scope of the guidelines.
Automated Markup Insertion Function
Automated markup insertion functions are the features of an
authoring tool that allow the user to produce markup without
directly typing it. This includes a wide range of tools from
simple markup insertion aids (such as a bold button on a
toolbar) to markup managers (such as table makers that include
powerful tools such as "split cells" that can make multiple
changes) to high level site building wizards that produce
almost complete documents on the basis of a series of user
preferences.
Conversion Tool
A Conversion Tool is any application or application feature
that allows content in some other format (proprietary or not)
to be converted automatically into a particular markup
language. This includes software whose primary function is to
convert documents to a particular markup language as well as
"save as HTML" (or other markup language) features in
non-markup applications.
Current User Selection
When several views co-exist, each may have a user selection,
but only one is active, called the current user selection. The
selections may be rendered specially (e.g., visually
highlighted).
Description Link (D-link)
A description link, or D-Link, is an author-supplied link to
additional information about a piece of content that might
otherwise be difficult to access (image, applet, video, etc.).
Document
A document is a series of elements that are defined by a
language (e.g., HTML 4.0 or an XML application).
Editing an element
Editing an element involves making changes to one or more of an
element's attributes or properties. This applies to all
editing, including, but not limited to, direct coding in a text
editing mode, making changes to a property dialog or direct
User Interface manipulation.
Editing View
What is displayed by the authoring tool to the author during
the editing process.
Element
An element is any identifiable object within a document, for
example a character, word, image, paragraph or spreadsheet
cell. In HTML and XML an element refers to a pair of tags and
their content, or an "empty" tag - one that requires no closing
tag or content.
Focus
The focus designates the active element (e.g., link, form
control, element with associated scripts, etc.) in a view that
will react when the user next interacts with the document.
Generation Tool
A Generation Tool is a program or script that produces
automatic markup "on the fly" by following a template or set of
rules. The generation may be performed on either the server or
client side.
Image Editor
A graphics program that provides a variety of options for
altering images of different formats.
Inaccessible Markup, Inaccessible Element, Inaccessible Attribute,
Inaccessible Authoring Practice and Access Barrier
These terms are used to mean markup or practices which do not
meet (or produce content which does not meet) checkpoints of
the Web Content Accessibility Guidelines [WAI-WEBCONTENT].
Inserting an element
Inserting an element involves placing that element's markup
within the markup of the file. This applies to all insertions,
including, but not limited to, direct coding in a text editing
mode, choosing an automated insertion from a pull-down menu or
tool bar button, "drag-and-drop" style insertions, or "paste"
operations.
Interruptive Alerts
Interruptive alerts are informative messages that interrupt the
edit process for the user. For example, interruptive alerts are
often presented when a user's action could cause a loss of
data. Interruptive alerts allow problems to be brought to the
user's attention immediately. However, users may resent the
constant delays and forced actions. Many people prefer to
finish expressing an idea before returning to edit its format.
Markup Language
The term markup language is used in this document to refer to
the encoding language of a document, such as HTML, SVG, or
MathML.
Multi-media Authoring Tool
Software that facilitates integration of diverse media elements
into an comprehensive presentation format. May incorporate
video, audio, images, animations, simulations, and other
interactive components.
Prompts
Prompts are requests for user input, either information or a
decision. Prompts require author response. Prompts can be used
to encourage authors to provide information needed to make the
information accessible (such as alternative textual
representations). Prompts are simple requests for information
before a markup structure has been finalized. For example, an
"alt-text" entry field prominently displayed in an image
insertion dialog would constitute a prompt. Prompts are
relatively unintrusive and address a problem before it has been
committed. However, once the user has ignored the prompt, its
message is unavailable.
Property
A property is a piece of information about an element, for
example structural information (e.g., it is item number 7 in a
list, or plain text) or presentation information (e.g., that it
is marked as bold, its font size is 14). In XML and HTML
properties of an element include the name of the element (e.g.,
IMG or DL), the values of its attributes, and information
associated by means of a style sheet. In a database, properties
of a particular element may include values of the entry, and
acceptable data types for that element.
Publishing Tool
A tool that allows content to be uploaded in an integrated
fashion. Sometimes these tools makes changes such as local
hyper-reference modifications. Although these tools sometimes
stand alone, they may also be integrated into site management
tools.
Rendered Content
The rendered content is that which an element actually causes
to be rendered by the user agent. This may differ from the
element's structural content. For example, some elements cause
external data to be rendered (e.g., the IMG element in HTML),
and in some cases, browsers may render the value of an
attribute (e.g., "alt", "title") in place of the element's
content.
Rendered View
What is displayed by the authoring tool to the author as a
means of simulating how a user of the document being edited
will interact with the document currently being edited as a
published document.
Selection
A selection is a set of elements identified for a particular
operation. The user selection identifies a set of elements for
certain types of user interaction (e.g., cut, copy, and paste
operations). The user selection may be established by the user
(e.g., by a pointing device or the keyboard) or via an
accessibility Application Programmatic Interface (API). A view
may have several selections, but only one user selection.
Site Management Tool
A tool that provides an overview of an entire Web site
indicating hierarchical structure. It will facilitate
management through functions that may include automatic index
creation, automatic link updating, and broken link checking.
Transcripts
A transcript is a line by line record of all dialog and action
within a video or audio clip.
Transformation
A process whereby one object is changed, according to a
discrete set of rules, into another, equivalent, object. This
includes any application or application feature that allows
content that is marked up in a particular markup language to be
transformed into another markup language, such as software that
allows the author to change the DTD defined for the original
document to another DTD. .
Unintrusive Alerts
Unintrusive alerts are alerts such as icons, underlines, and
gentle sounds that can be presented to the user without
necessitating immediate action. for example, in some word
processors misspelled text is highlighted without forcing the
user to make immediate corrections. These alerts allow users to
continue editing with the knowledge that problems will be easy
to identify at a later time. However, users may become annoyed
at the extra formatting or may choose to ignore the alerts
altogether.
User Agent
The term User Agent in this document refers to an application
which is used to read web content, such as a browser, a plug-in
for a particular media type, or a piece of assistive
technology.
User Configurable Schedule
A user configurable schedule allows the user to determine the
type of prompts and alerts that are used, including when they
are presented. For example, a user may wish to include multiple
images without being prompted for alternative information, and
then provide the alternative information in a batch process, or
may wish to be reminded each time they add an image. If the
prompting is done on a user configurable schedule they will be
able to make that decision themselves. This technique allows a
tool to suit the needs a wide range of authors.
Video Captions
A video caption is a textual message that is stored in the text
track of a video file. The video caption describes the action
and dialog for the scene in which it is displayed.
Video Editor
A tool that facilitates the process of manipulating video
images. Video editing includes cutting segments (trimming),
re-sequencing clips, and adding transitions and other special
effects.
Views
An authoring tool may offer several views of the same document.
For instance, one view may show raw markup, a second may show a
structured tree view, a third may show markup with rendered
objects while a final view shows an example of how the document
may appear if it were to be rendered by a particular browser.
Markup Language
The term markup language is used in this document to refer to
the encoding language of a document, such as HTML, SVG, or
MathML.
5 Acknowledgments
Many thanks to the following people who have contributed through
review and comment: Jim Allan, Denis Anson, Kitch Barnicle, Kynn
Bartlett, Harvey Bingham, Judy Brewer, Carl Brown, Dick Brown, Wendy
Chisholm, Rob Cumming, Daniel Dardailler, Mark Day, BK Delong, Martin
Dürst, Kelly Ford, Jamie Fox, Edna French, Sylvain Galineau, Al
Gilman, Eric Hansen, Phill Jenkins, Len Kasday, Brian Kelly,
Marja-Riitta Koivunen, Sho Kuwamoto, Jaap van Lelieveld, William
Loughborough, Karen McCall, Charles Oppermann, Dave Pawson, Dave
Poehlman, Bruce Roberts, Chris Ridpath, Gregory Rosmaita, Janina
Sajka, Jim Thatcher, Irène Vatton, Gregg Vanderheiden, Pawan Vora,
Jason White, and Lauren Wood.
6 References
For the latest version of any W3C specification please consult the
list of W3C Technical Reports.
[ACCESS-AWARE]
"The Three-tions of Accessibility-Aware HTML Authoring Tools,"
J. Richards.
[AMAYA]
Amaya W3C's own browser/authoring tool, used to demonstrate and
test many of the new developments in Web protocols and data
formats. Amaya has a WYSIWYG style of interface. Source code,
binaries, and further information are all available at
http://www.w3.org/Amaya/.
[AMAYA-HELP-IMG]
"Images and Client-side Image Maps" Amaya's Help page for
images and image maps.
[AMAYA-SAMPLE]
Amaya - Authoring Tool Accessibility Guidelines example"
Describes how Amaya, W3C's WYSIWYG browser/authoring tool,
implements the guidelines.
[APPLE-HI]
"Macintosh Human Interface Guidelines," Apple Computer Inc.
[APROMPT]
A-prompt tool is a freely available example tool developed by
the Adaptive Technology Resource Center at the University of
Toronto, and the TRACE center at the University of Wisconsin.
The source code for the tool is also available at
http://aprompt.snow.utoronto.ca
[AUTO-TOOL]
"Techniques For Evaluation And Implementation Of Web Content
Accessibility Guidelines," C. Ridpath.
[CSS1]
"CSS, level 1 Recommendation," B. Bos, 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.
[CSS2]
"CSS, level 2 Recommendation," B. Bos, H. Wium Lie, C. Lilley,
and I. Jacobs, eds., 12 May 1998. This CSS2 Recommendation is
http://www.w3.org/TR/1998/REC-CSS2-19980512. The latest version
of CSS2 is available at http://www.w3.org/TR/REC-CSS2.
[CSS2-ACCESS]
"Accessibility Features of CSS," I. Jacobs and J. Brewer, eds.,
4 August 1999. This version is
http://www.w3.org/1999/08/NOTE-CSS-access-19990804. The latest
version of Accessibility Features of CSS is available at
http://www.w3.org/TR/CSS-access.
[ED-DEPT]
"Requirements for Accessible Software Design," US Department of
Education, version 1.1 March 6, 1997.
[HTML4-ACCESS]
""WAI Resources: HTML 4.0 Accessibility Improvements," I.
Jacobs, J. Brewer, and D. Dardailler, eds. This document
describes accessibility features in HTML 4.0.
[HTML40]
"HTML 4.0 Recommendation," D. Raggett, A. Le Hors, and I.
Jacobs, eds., 17 December 1997, revised 24 April 1998. This
HTML 4.0 Recommendation is
http://www.w3.org/TR/1998/REC-html40-19980424. The latest
version of HTML 4.0 is available at
http://www.w3.org/TR/REC-html40.
[IBM-ACCESS]
"Software Accessibility," IBM Special Needs Systems.
[ICCCM]
"The Inter-Client communication conventions manual." A protocol
for communication between clients in the X Window system.
[ICE-RAP]
"An ICE Rendezvous Mechanism for X Window System Clients," W.
Walker. A description of how to use the ICE and RAP protocols
for X Window clients.
[JAVA-ACCESS]
"IBM Guidelines for Writing Accessible Applications Using 100%
Pure Java," R. Schwerdtfeger, IBM Special Needs Systems.
[JAVA-CHECKLIST]
"Java Accessibility Guidelines and Checklist," IBM Special
Needs Systems.
[JAVA-TUT]
"The Java Tutorial. Trail: Creating a GUI with JFC/Swing." An
online tutorial that describes how to use the Swing Java
Foundation Class to build an accessible User Interface.
[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.
[MS-ENABLE]
"Accessibility for Applications Designers," Microsoft
Corporation.
[MS-SOFTWARE]
"The Microsoft Windows Guidelines for Accessible Software
Design." Warning! This is a "self-extracting archive", an
application that will probably only run on MS-Windows systems.
[MSAA]
"Information for Developers About Microsoft Active
Accessibility," Microsoft Corporation.
[NOTES-ACCESS]
"Lotus Notes Accessibility Guidelines," IBM Special Needs
Systems.
[SEARCHABLE]
"A Comparison of Schemas for Dublin Core-based Video Metadata
Representation," J Hunter.
[SKETCH]
The Sketch open source image editor home page.
[SMIL-ACCESS]
"Accessibility of SMIL", M.-R. Koivunen, I. Jacobs eds. The
latest version is available at http://www.w3.org/TR/SMIL-access
[SUN-DESIGN]
"Designing for Accessibility," Eric Bergman and Earl Johnson.
This paper discusses specific disabilities including those
related to hearing, vision, and cognitive function.
[SUN-HCI]
"Towards Accessible Human-Computer Interaction," Eric Bergman,
Earl Johnson, Sun Microsytems 1995. A substantial paper, with a
valuable print bibliography.
[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
[SVG-ACCESS]
"Accessibility of Scalable Vector Graphics" (Working Draft), C.
McCathieNevile, M.-R. Koivunen eds. The latest version is
available at http://www.w3.org/1999/09/SVG-access
[TRACE-REF]
"Application Software Design Guidelines," compiled by G.
Vanderheiden. A thorough reference work.
[WAI-AUTOOLS]
"Authoring Tool Accessibility Guidelines 1.0 (working draft),"
J. Treviranus, J. Richards, I. Jacobs, and C. McCathieNevile
eds. The latest version is available at
http://www.w3.org/WAI/AU/WAI-AUTOOLS.
[WAI-ER]
The Web Accessibility Initiative Evaluation and Repair Tools
Working Group tracks and develops tools that can help repair
accessibility errors.
[WAI-USERAGENT]
"User Agent Accessibility Guidelines," J. Gunderson and I.
Jacobs, eds. The latest version of the User Agent Accessibility
Guidelines is available at
http://www.w3.org/WAI/UA/WAI-USERAGENT.
[WAI-WEBCONTENT]
"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/WAI-WEBCONTENT/.
[WAI-WEBCONTENT-TECHS]
"Techniques for Web Content Accessibility Guidelines 1.0," W.
Chisholm, G. Vanderheiden, and I. Jacobs, eds. The latest
version of Techniques for Web Content Accessibility Guidelines
1.0 is available at http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/.
[WEB-CONTENT-PRIORITY]
Priorities defined by [WAI-WEBCONTENT].
[WHAT-IS]
"What is Accessible Software," James W. Thatcher, Ph.D., IBM,
1997. This paper gives a short example-based introduction to
the difference between software that is accessible, and
software that can be used by some assistive technologies.
[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.
[XMLGL]
"XML Accessibility Guidelines (Draft Note)," D. Dardailler ed.
Draft notes for producing accessible XML document types. The
latest version of the XML Accessibility Guidelines is
available at http://www.w3.org/WAI/PF/xmlgl.
_________________________________________________________________
[contents]