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.
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.
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.
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.
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.
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]
-
- 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.
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.
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:
- 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.
- 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.
- 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:
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.
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.
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.
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
- "IBM Guidelines for Writing Accessible Applications Using 100%
Pure Java" [JAVA-ACCESS] R. Schwerdtfeger, IBM Special Needs
Systems.
- "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.
- "Information for Developers About Microsoft Active
Accessibility" [MSAA] Microsoft Corporation.
- "The Inter-Client communication conventions manual" [ICCCM].
A protocol for communication between clients in the X Window
system.
- "Lotus Notes accessibility guidelines" [NOTES-ACCESS] IBM
Special Needs Systems.
- "Java accessibility guidelines and checklist"
[JAVA-CHECKLIST] IBM Special Needs Systems.
- "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.
- "Macintosh Human Interface Guidelines" [APPLE-HI] Apple
Computer Inc.
- "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
- "The Three-tions of Accessibility-Aware HTML Authoring Tools"
[ACCESS-AWARE], J. Richards.
- "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:
- "Accessibility for applications designers" [MS-ENABLE]
Microsoft Corporation.
- "Application Software Design Guidelines" [TRACE-REF]
compiled by G. Vanderheiden. A thorough reference work.
- "Designing for Accessibility" [SUN-DESIGN] Eric Bergman and
Earl Johnson. This paper discusses specific disabilities
including those related to hearing, vision, and cognitive
function.
- "EITAAC Desktop Software standards" [EITAAC]] Electronic
Information Technology Access Advisory (EITACC) Committee.
- "Requirements for Accessible Software Design" [ED-DEPT] US
Department of Education, version 1.1 March 6, 1997.
- "Software Accessibility"> [IBM-ACCESS] IBM Special Needs
Systems
- "Towards Accessible Human-Computer Interaction" [SUN-HCI]
Eric Bergman, Earl Johnson, Sun Microsytems 1995. A substantial
paper, with a valuable print bibliography.
- "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.:
- Draw text and objects using system conventions
- Make mouse, keyboard, and API activation of events
consistent
- Provide a User Interface that is "familiar" (to system
standards, or across platform)
- Use system standard indirections and APIs
wherever possible
- Ensure all dialogs, subwindows, etc meet these
requirements
- Avoid blocking assistive technology functions (sticky/mouse
keys, screenreader controls, etc) where possible
- Allow users to create profiles
- Allow control of timing, colors, sizes, input/output devices
and media
- Allow users to reshape the user interface - customize
toolbars, keyboard commands, etc
- Provide Keyboard access to all functions
- Document all keyboard bindings
- Provide customizable keyboard shortcuts for common
functions
- Provide logical navigation order for the keyboard
interface.
- Avoid repetitive keying wherever possible
- Provide mouse access to functions where possible
- Provide visual (text) equivalents for sound warnings
- Allow sounds to be turned off
- Provide text equivalents for images/icons
- Use customizable (or removable) colors/patterns
- Ensure high contrast is available (as default setting)
- Provide text equivalents for all audio
- Use icons that are resizeable or available in multiple
sizes
- Do not rely on color alone for meaning. Use color for
differentiation, in combination with accessible cues (text
equivalents, natural language, etc)
- Position related text labels and objects consistently, and in
an obvious manner (labels before objects is recommended)
- Group related controls
- Ensure default window sizes fit in screen
- Allow for window resizing (very small to very large)
- Clearly identify the user focus (and expose it via API)
- Unexpected events should not be caused by viewing content (for
example by moving the focus to a new point)
- Allow user control of timing - delays, time-dependent
response, etc
- Allow for navigation between as well as within windows
- Provide documentation for all features of the tool
- 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
- HTML paragraphs to lists and back
- HTML
br
to p
- SMIL transformations between
switch
,
excl
and par
- HTML (deprecated)
FONT
into heuristically
determined structure
- Lists of lists to tables and back
- MathML transformations between semantic and presentation
markup
- Transforming SVG
g
elements to symbol
- 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..
[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.
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.
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).
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.
[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.
- 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.
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.
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.