This document contains techniques and further examples, as an informative
aid to developers seeking to implement the Authoring Tool Accessibility
Guidelines. 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 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 22 September 1999. Proposed changes to the Last Call
draft of the Guidelines [WAI-AUTOOLS-LC] are
identified with the HTML elements del or ins, which have a class determined by
the date the suggested changes were resolved. For further information consult
the minutes of Working Group Meetings. This document
has not been systematically updated to reflect changes in the Guidelines
document which occurred after September 22. A revised techniques document will
be published around 14 October.
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, or in a hypothetical image editor -
MyTool or a hypothetical multimedia editor - SMILey. 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
([##Cnotify-on-schedule]) has relative priority. This means that it is
priority 1 for a tool to check for accessibility errors that are [Web-Content-Priority-1], but
priority 2 to check for accessibility errors that are [Web-Content-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]
-
- [#C+Rgenerate-access-markup] Ensure that the tool
generates markup that conforms to the W3C's Web Content Accessibility Guidelines
[WAI-WEBCONTENT].
- 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.
- [#C+Ruse-accessible-templates] Ensure that templates
provided by the tool conform to the Web
Content Accessibility Guidelines [WAI-WEBCONTENT].
- 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..
- 1.2 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.
- 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.
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].
- 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.
- 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.
-
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:
- [#C+Rprovide-missing-alt] Assist the author in
providing alternative information (e.g., captions, long descriptions of
graphics).
- 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.
- Amaya prompts the author to provide alt text
for IMG and AREA, and CAPTION for TABLE.
- See also checkpoint 3.2
- [#C+Rhelp-provide-structure] Help the author create
structured content and separate information from its presentation.
- 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, prompt the author for kana text that can be used as a
ruby for unusual or complex kanji.
- 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.
- [#C+Rinclude-pro-descs] Ensure that prepackaged
content conforms to Web Content Accessibility
Guidelines [WAI-WEBCONTENT].
- For example include synchronised text and audio equivalents with
movies. (Refer also to [##C-no-default-alt]).
- Use formats that allow for accessible annotation, such as
PNG.
- 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
- See also 3.2
- 3.1 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 that human-authored content may be available for an object whose
function is known with certainty (See also 3.2,
[##Cinclude-pro-descs]
- 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 (see also
[###Cnotify-on-schedule])
- Amaya does not provide default alt text
except when copying and pasting images, in which case it copies all
attributes with the image.
- 3.2 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.
- 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 [##Cprovide-missing-alt]). 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 3.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
[##Cinclude-pro-descs]. 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..
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 may 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 (see also 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 that 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:
- [#C+Rnotify-on-schedule] Check for and alert the
author to accessibility problems.
- Include alerts for [Web-Content-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.
- Where there is a change in the character set (or subset) 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-test].
- 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.
- [#C+Rdont-require-knowledge] Assist authors in
correcting accessibility problems.
- Do this in a way that is consistent with the look and feel of the
authoring tool.
- Provide context sensitive-help for accessibility errors. See also
6 Promote accessibility in help and documentation
- 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..
- 4.1 Allow the author to preserve markup not recognized by the tool. [Priority 2]
- Notes:
- 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
- 4.2 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
- 4.3 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.2
- Amaya provides a language for specifying
structure transformations, along with a large number of
transformations being included.
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 will influence their view of
the tool and their opinion of accessible authoring. See also
5 Integrate accessibility solutions into the overall "look and feel"
.
- 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.
- 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..
- 5.2 Ensure that the [Web-Content-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.2), 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.
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.
- 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 [HTML4],
CSS [CSS1],[CSS2])
- 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.
- 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 accesibility section will be provided in the next
release version.
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" [MS-ACCESS] 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] (See also
1 Support accessible authoring practices
)
- 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].
- 7.2 Allow the author to change the editing view 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..
- 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 that 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.
- 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.
- 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
- 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.
- 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. See also 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.
[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 that Amaya is developed as a proof
of concept for a number of specifications, not a product for market.
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.
MyTool (SauVaGe) - a hypothetical image editor, that is triple-A
conformant to the Authoring Tool Accessibility Guidelines:
checkpoint 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]
: MyTool follows the accessibility guidelines
provided for the language the user interface is written in, and implements the
accessibility features and APIs that are described in the reference literature
for the platforms on which it is available.
checkpoint 7.2 Allow the author to change the editing view without affecting the document markup. [Priority 1]
: MyTool provides remapping of colors via a style
sheet so you don't need to see a color to use it - you can address it by any
of 3 schemes.
[###Ctext-elements]: With MyTool the author can display the filename, can
read all metadata for each image or layer, and can navigate an image by pixel
or vector through a text-based interface, as well as a standard image
manipulation user interface
checkpoint 7.3 Allow the author to edit all properties of each element and object in an accessible fashion. [Priority 1]
: With MyTool the author can edit all metadata for each
image or layer, and can edit a pixel or vector's properties through a
text-based interface, as well as through a standard image manipulation user
interface.
checkpoint 7.4 Ensure the editing view allows navigation via the structure of the document in an accessible fashion. [Priority 1]
: MyTool allows the author to build an image of
component parts, placed in layers. These layers can be named and
navigated.
checkpoint 7.5 Enable editing of the structure of the document in an accessible fashion. [Priority 2]
: With MyTool, while the image is layered, it is
possible to make changes at the layer level. For animated GIFs, the author can
directly edit the control structure, or use a simple graphical interface.
checkpoint 2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task. [Priority 2]
: MyTool supports PNG and WebCGM as well as GIF, JPEG,
TIFF, XPM, BMP, EPS, etc. The next version will implement full SVG support.
checkpoint 2.2 Ensure that the tool generates valid markup. [Priority 1]
: MyTool implements standards exactly as
written.
[###Censure-accessible-DTD]: MyTool currently uses PNG as its default
format to provide accessibility features available in that format. One of the
reasons for the transition to SVG is the expected increase in available
accessibility features..
checkpoint 1.1 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1]
: MyTool attempts to include as much
information as possible with each image. For formats that allow it, text
entered into an image is also included as annotation or title information.
[###Cgenerate-access-markup]: MyTool produces images that have as much
equivalent information available as possible, and where the format allows, it
enables colour and size control (e.g., SVG)
[###Cuse-accessible-templates]: MyTool provides some standard clip-art,
that has associated names and descriptions for use in layered image
construction (Refer also to checkpoints [##Ctext-elements] and
3.1)
checkpoint 1.2 Ensure that the tool preserves all accessibility information during authoring, transformations and conversions. [Priority 1]
: MyTool tracks all metadata included in an
image, and where it cannot be included as part of the image format supplies it
with the image (Refer also to checkpoints [##Cprovide-missing-alt],
[##Cinclude-pro-descs], and 3.2)
[###Cprovide-missing-alt]: MyTool prompts the author to give a name and
description for each image or layer when it is saved. It also prompts the
author for a brief description of the role of each image or layer at save
time, or when layers are merged. These actions are available to the author at
any time.
[###Cinclude-pro-descs]: MyTool provides pre-written alternative
information for all multimedia packaged with the software
checkpoint 3.2 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]
: MyTool provides a database system for managing
images and layers and associating metadata that is saved for future use.
checkpoint 3.1 Do not insert automatically generated or place-holder equivalent alternatives. [Priority 1]
: MyTool offers default text where it exists, as an
editable option. If it has not been used before, MyTool prompts the author to
confirm the use of this default text.
checkpoint 5.1 Ensure that functionalities related to accessible Authoring practices are integrated into the tool. [Priority 2]
: With MyTool, accessibility features are always
available in relevant dialogs. The user interface includes a metadata menu at
the top level, and on the button bar, for easy addition of metadata at any
time.
checkpoint 5.2 Ensure that the [Web-Content-Priority-1] accessible authoring practices are among the most obvious and easily initiated by the author. [Priority 2]
: MyTool always prompts the author for accessibility
features. Turning this off is possible via an "advanced" options menu
[###Cnotify-on-schedule]: MyTool checks for missing information at save
time, or when layers are about to be merged (Refer also
1.1 and [##Cgenerate-access-markup])
[###Cdont-require-knowledge]: MyTool has an easy prompt-driven interface
for adding metadata, as well as fast keyboard-control and buttons for the
power user. Context-sensitive help is always available.
checkpoint 4.1 Allow the author to preserve markup not recognized by the tool. [Priority 2]
: MyTool provides an alert if it opens an invalid
document, and the author can cancel attempted repair or undo it afterwards.
MyTool also alerts the author when saving to a format that results in a loss
of built-in accessible information.
checkpoint 4.2 Provide the author with a summary of the document accessibility status. [Priority 3]
: MyTool highlights layers or images that do not
have names, descriptions or structural role information through the use of
icons that have textual equivalents available
checkpoint 4.3 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]
: MyTool allows the transformation of layers, by
combining or splitting, with prompting for which metadata goes with which part
of a split layer
checkpoint 6.2 Ensure that creating accessible content is a naturally integrated part of the documentation, including examples. [Priority 2]
: MyTool Help pages have naming and
describing images as part of the process of creating them. The discussion of
layers (which is promoted as a good way to do images) includes discussion of
giving structural role information, and what kind of information is required.
All help contains numerous examples of how to do the process.
checkpoint 6.1 Document all features that promote the production of accessible content. [Priority 1]
: In addition to having the relevant accessibility
practices as part of the normal help, MyTool has a help topic called
accessibility of images. All relevant topics are available in both places
[###Cdont-use-bad-markup]: The help section for MyTool has many examples,
all of which use standard markup and conform to the Web Content Accessibility
Guidelines [WAI-WEBCONTENT].
checkpoint 6.3 In a dedicated section, document all features of the tool that promote the production of accessible content. [Priority 3]
: The help section for MyTool explains
that structured images are easier to re-use, and can be easily optimized for a
variety of situations - low bandwidth/high bandwidth, text-only editing,
etc.
SMILey - a hypothetical video and audio editor, that is triple-A conformant
to the Authoring Tool Accessibility Guidelines:
checkpoint 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]
: SMILey follows the accessibility guidelines
provided for the language the user interface is written in, and implements the
accessibility features and APIs that are described in the reference literature
for the platforms on which it is available.
checkpoint 7.2 Allow the author to change the editing view without affecting the document markup. [Priority 1]
: SMILey uses SMIL to separate audio, video,
descriptive signing and text tracks.
[###Ctext-elements]: With SMILey the author can display the filename, and
can read all metadata for each multimedia segment.
checkpoint 7.3 Allow the author to edit all properties of each element and object in an accessible fashion. [Priority 1]
: Using SMILey the author can edit all metadata for each
component, and can edit a video frame by frame by using SMILey as a plug-in
through a text-based interface, as well as through a standard image
manipulation user interface.
checkpoint 7.4 Ensure the editing view allows navigation via the structure of the document in an accessible fashion. [Priority 1]
: SMILey allows navigation of the SMIL
structure.
checkpoint 7.5 Enable editing of the structure of the document in an accessible fashion. [Priority 2]
: In SMILey, while the image is layered, it is possible
to make changes at the layer level. For animated GIFs, the author can directly
edit the control structure, or use a simple graphical interface.
checkpoint 2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task. [Priority 2]
: SMILey is primarily a SMIL editor. It imports various
formats for images, audio, video, and text.
checkpoint 2.2 Ensure that the tool generates valid markup. [Priority 1]
: SMILey implements SMIL exactly as published,
with its additional metadata implemented according to the Resource Description
Framework (RDF) syntax [RDF-SYNTAX].
[###Censure-accessible-DTD]: SMILey implements SMIL to allow multiple
parallel tracks, providing support for medium-independent rendering.
checkpoint 1.1 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1]
: SMILey supports all access features in SMIL,
and includes an RDF parser and generator to provide additional functions such
as searching and more complex multiple tracks.
[###Cgenerate-access-markup]: SMILey splits audio, video, and text layers
into separate tracks, with appropriate system-variables, to allow them to be
rendered separately.
[###Cuse-accessible-templates]: SMILey provides a sample presentation made
available by a third party to demonstrate accessible design of multimedia.
checkpoint 1.2 Ensure that the tool preserves all accessibility information during authoring, transformations and conversions. [Priority 1]
: SMILey keeps all the elements of imported
presentations.
[###Cprovide-missing-alt]: SMILey prompts the author to provide text
captions, audio descriptions for video, and text descriptions of video to
allow searching. The SMILey team are investigating the ability to provide
music markup as a separate track to facilitate re-presentation of soundtrack
music.
checkpoint 3.1 Do not insert automatically generated or place-holder equivalent alternatives. [Priority 1]
: SMILey interrogates its RDF database when a new track
is added to suggest tracks that could be associated. The author must confirm
these tracks before they are included.
[###Cinclude-pro-descs]: The example document supplied with SMILey includes
multiple content types - text captions, audio description, etc.
checkpoint 3.2 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]
: SMILey uses RDF metadata to associate multiple
tracks. It can interrogate the RDF store.
checkpoint 5.1 Ensure that functionalities related to accessible Authoring practices are integrated into the tool. [Priority 2]
: Accessibility features are always available in
relevant dialogs. The user interface includes a metadata menu at the top
level, and on the button bar, for easy addition of metadata at any time.
checkpoint 5.2 Ensure that the [Web-Content-Priority-1] accessible authoring practices are among the most obvious and easily initiated by the author. [Priority 2]
: SMILey always prompts the author for accessibility
features. Turning this off is possible via an "advanced" options menu
[###Cnotify-on-schedule]: SMILey checks for missing information each time
changes are made to the document, and at save time.
[###Cdont-require-knowledge]: SMILey has an easy prompt-driven interface
for adding metadata, as well as fast keyboard-control and buttons for the
power user. Context-sensitive help is always available.
checkpoint 4.1 Allow the author to preserve markup not recognized by the tool. [Priority 2]
: SMILey provides an alert if it opens an invalid
document, and the author can cancel attempted repair or undo it afterwards.
SMILey also alerts the author when saving to a format that results in a loss
of built-in accessible information.
checkpoint 4.2 Provide the author with a summary of the document accessibility status. [Priority 3]
: SMILey highlights tracks that do not appear to
have full alternative versions through properties defined in the user style
sheet, which can also be applied to the source mode.
checkpoint 4.3 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]
: SMILey allows conversion between switch and par
elements, enabling the author to specify whether tracks should be played all
together or only as alternatives to each other.
checkpoint 6.2 Ensure that creating accessible content is a naturally integrated part of the documentation, including examples. [Priority 2]
: SMILey provides extensive documentation on
how to generate multiple tracks for accessibility, including examples of what
they should contain and how they should be included.
checkpoint 6.1 Document all features that promote the production of accessible content. [Priority 1]
: In addition to having the relevant accessibility
practices as part of the normal help, SMILey has a help topic called
accessibility of images. All relevant topics are available in both places
[###Cdont-use-bad-markup]: SMILey help has many examples, all of which use
standard markup and conform to the Web Content Accessibility Guidelines [WAI-WEBCONTENT].
checkpoint 6.3 In a dedicated section, document all features of the tool that promote the production of accessible content. [Priority 3]
: SMILey help explains how multiple tracks
allow for searching and indexing of timed presentations, as well as providing
access to people with one or more disabilities to the full content of the
presentation.
[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 1]
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.
[Editors' note: This section will be updated to reflect comments received
during last call. In particualr, it will be in alphabetical order]
- 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.
- 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.
- 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.
- Authoring Tool
- As used in this document, an Authoring Tool is any software
that is used to generate content for publishing on the Web. See also
section 1.3 Scope of the
guidelines.
- 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.
- 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.
- 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.
- 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.
- Image Editor
- A graphics program that provides a variety of
options for altering images of different formats.
- 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.
- 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.
- 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.
- 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. .
- Document
- A document is a series of elements that are defined by a
language (e.g., HTML 4.0 or an XML application).
- 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 has no closing tag or content.
- 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.
- 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
- 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.
- 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.
- 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 Information
- Accessibility information is content, including information and
markup, which is used to improve the accessibility of a document.
- Inaccessible
Markup, Inaccessible Element, Inaccessible Attribute, Inaccessible
Authoring Practice and Access Barrier
- All these terms are used in the context of
inaccessibility as defined by the Web
Content Accessibility Guidelines [WAI-WEBCONTENT].
- Accessibility Solution,
Accessible Authoring Practice
- These terms refer to Authoring practices that improve the
accessibility of content generated by the tool.
- 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.
- 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.).
- Transcripts
- A transcript is a line by line record of all dialog
and action within a video or audio clip.
- 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.
- 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.
- 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.
- 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.
- Editing view
- What is displayed by the authoring tool to the author during the
editing process.
- 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.
- 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).
- 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.
- 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, Kynn Bartlett, Harvey Bingham, Judy Brewer,
Carl Brown, Dick Brown, Kelly Ford, Wendy Chisholm, Rob Cumming, Daniel
Dardailler, Mark Day, BK Delong, Jamie Fox, Edna French, Sylvain Galineau, Al
Gilman, Eric Hansen, Phill Jenkins, Len Kasday, Brian Kelly, Marja-Riitta
Koivunen, Jaap van Lelieveld, William Loughborough, Karen McCall, Charles
Oppermann, Dave Pawson, Dave Poehlman, Bruce Roberts, Chris Ridpath, Gregory
Rosmaita, Jim Thatcher, Irène Vatton, Gregg Vanderheiden, Pawan Vora,
Jason White, and Lauren Wood.
If you have contributed to the AU guidelines and your name does not appear
please contact the editors to add your name to the list.
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-sample]
- "Amaya - Authoring Tool
Accessibility Guidelines example" Describes how Amaya, W3C's WYSIWYG
browser/authoring tool, implements the guidelines.
- [AMAYA-help-img]
- "Images and
Client-side Image Maps" Amaya's Help page for images and image
maps..
- [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-tools]
- "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.
- [EITAAC]
- "EITACC
Desktop Software standards", Electronic Information Technology
Access Advisory (EITACC) Committee.
- [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.
- [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.
- [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-ACCESS]
- "Information for
Developers About Microsoft Active Accessibility", Microsoft
Corporation.
- [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.
- [NOTES-ACCESS]
- "Lotus Notes
Accessibility Guidelines", IBM Special Needs Systems.
- [RDF-SYNTAX]
- "Resource
Description Framework (RDF) Model and Syntax Specification", O.
Lassila, R. Swick, eds., 22 February 1999. This RDF Recommendation is
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. The latest version of RDF
1.0 is available at http://www.w3.org/TR/REC-rdf-syntax.
- [SEARCHABLE]
- "A
Comparison of Schemas for Dublin Core-based Video Metadata
Representation", J Hunter.
- [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/
- [TRACE-REF]
- "Application
Software Design Guidelines", compiled by G. Vanderheiden. A thorough
reference work.
- [WAI-AUTOOLS]
- "Authoring Tool
Accessibility Guidelines (Working Draft)", J. Treviranus, J.
Richards, I. Jacobs, and C. McCathieNevile eds. The latest draft of the
Authoring Tool Accessibility Guidelines is available at
http://www.w3.org/WAI/AU/WAI-AUTOOLS.
- [WAI-AUTOOLS-LC]
- "Authoring Tool
Accessibility Guidelines (Working Draft), 3 September 1999 Last Call
draft", J. Treviranus, J. Richards, I. Jacobs, and C. McCathieNevile
eds. The Last Call draft of 3 September is available at
http://www.w3.org/TR/1999/AU/WAI-AUTOOLS-19990903.
- [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.