- From: Jutta Treviranus <jutta.treviranus@utoronto.ca>
- Date: Tue, 12 Jan 1999 15:09:56 -0500
- To: w3c-wai-au@w3.org, Ian Jacobs <ij@w3.org>
The new organization and merging proposed would result in a document core
that looks like this:
2 Ensure that content produced by the authoring tool is accessible
Guiding Principle: The authoring tool user interface can be used to guide
and encourage the author to create accessible web content.
Guiding Principle: The power of automation should be utilized so that
authors may concentrate on description writing and other higher-level
aspects of Web accessibility.
2.1 Generate standard markup [PRIORITY 1]
The first step towards accessibility is interoperability. Authoring tools
must ensure that content is created in accordance with W3C specifications
(or other standards when applicable).
2.2 Support all accessible content recommendations [PRIORITY 1]
Methods for ensuring accessible content vary with different markup
languages. An authoring tool must support all accessibility features that
have
been defined for the markup language(s) supported by the tool. Listing the
accessibility features of specific languages lies beyond the scope of this
document. However, an informative list of documents that address accessible
Web authoring practices follows.
Page Author Accessibility Features: (The actual accessible markup solutions)
General: WAI Page Authoring Guidelines: Techniques
HTML4: HTML4 Accessibility Improvements
CSS2: CSS2 Accessibility Improvements
SMIL, MathML
Page Author Implementation Priorities: (The priorities placed on the
accessibility markup solutions)
General: WAI Page Author Guidelines
Mechanisms that can be employed by authoring tools to support accessible
authoring practices are discussed in Section 5.
2.3 Identify all inaccessible markup [PRIORITY 1]
Many authoring tools allow their users 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 content, even when the markup itself is hidden from the
author.
Checkpoints:
[Checkpoint: 2.3.1] [PRIORITY 1]
Existing documents are checked when they are opened for editing.
[Checkpoint: 2.3.2] [PRIORITY 1]
Documents are checked during all types of editing, including
hand-coding, paste operations, and code insertions.
[Checkpoint: 2.3.3] [PRIORITY 1]
When problems are detected, the author should be alerted according
to a user-configurable schedule. See the section on ensuring that users
may configure accessibility mechanisms and Alert Techniques.
[Checkpoint: 2.3.4] [PRIORITY 1]
Correcting tools are designed so that authors can correct
accessibility problems without necessarily understanding the underlying
structure
of the language or the details of markup accessibility.
2.4 Ensure that all markup inserted by the authoring tool is accessible
[PRIORITY 1]
If markup is automatically generated, the author will be unaware of the
accessibility status of the final product unless they expend extra effort to
make appropriate corrections by hand. Since most authors are unfamiliar
with accessibility, these problems are likely to remain.
Checkpoints:
[Checkpoint: 2.4.1] [PRIORITY 1]
Automated markup insertion functions make use of appropriate
accessible solutions, even if this means presenting the author with
extra prompts for necessary information or structure during
or following the process.
2.5 Integrate accessibility solutions into relevant automated tools and
wizards [PRIORITY 1]
Accessibility issues often arise in complex markup tasks. Many authoring
tools provide automated tools or wizards to guide authors in creating the
relatively complex syntax needed to insert items such as objects, tables,
or frames.
Checkpoints:
[Checkpoint: 2.6.1] [PRIORITY 1]
All automated tasks for which there are page author accessibility
guidelines include the required relevant accessibility solutions.
2.6 Provide mechanisms for managing alternative content [PRIORITY 1]
Alternative content, including "alt"-text, long descriptions, video
captions, and transcripts are absolutely necessary for the accessibility of
all
images, applets, video, and audio files. However, the task of writing these
descriptions is probably the most time-consuming accessibility
recommendation made to the author. This is especially true in the case of
conversion tools that can quickly produce large amounts of content that is
lacking alternative representation. To reduce the demands on authors,
automated tools for managing alternatice content should be included.
Checkpoints:
[Checkpoint: 2.7.1a] [PRIORITY 1]
The author is prompted, on a configurable schedule, to provide
"alt"-text for images, image maps, and image map links.
[Checkpoint: 2.7.1b] [PRIORITY 1]
The author is prompted, on a configurable schedule, to provide
captioning or transcriptions for any video segments.
[Checkpoint: 2.7.1c] [PRIORITY 1]
The author is prompted, on a configurable schedule, to provider
transcriptions for any audio segments.
[Checkpoint: 2.7.1d] [PRIORITY 3]
The author is given the option of providing a long description for
any graphic element.
[Checkpoint: 2.7.2a] [PRIORITY 1]
The authoring tool never inserts rule-generated description text
into the document (default "alt"-text) or a properties field (place-holder
"alt"-text).
[Checkpoint: 2.7.2b] [PRIORITY 1]
Automated processes store and suggest pre-authored text that has
previously been associated with an object by the author or content
developer. This may only occur when the meaning or function of the
described object is known with certainty.
Techniques:
[Technique: 2.7.1]
Professionally written descriptions should be included for
all multimedia files packaged with the authoring tool (e.g. clip art) so
that:
1.users will be saved time and effort
2.a significant number of professionally written
descriptions will begin to circulate
3.users will be provided with convenient models to
emulate when they write their own descriptions
4.users will see evidence of the importance of
description writing
[Technique: 2.7.2]
The authoring tool should make use of the pre-written
descriptions by suggesting them as default text whenever one of the
associated files is inserted into the author's document.
[Technique: 2.7.3]
Increase user acceptance of pre-written descriptions by
allowing authors to make keyword searches of the description database,
thus simplifying the task of finding relevant images.
2.7 Ensure that conversion tools produce and retain accessible markup and
content [PRIORITY 1]
Many applications feature the ability to convert documents from other
formats (e.g., Rich Text Format) or proprietary formats 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 content or cause inaccessible
content to be produced.
Checkpoints:
[Checkpoint: 2.8.1] [PRIORITY 1]
Conversion utilities generate documents that respect the WAI Page
Author Guidelines.
[Checkpoint: 2.8.2] [PRIORITY 1]
Authoring tools never remove or modify structure or content that is
necessary for continued accessibility.
[Checkpoint: 2.8.3] [PRIORITY 1]
The authors is provided with the option of a receiving a summary of
all automated structural changes that may affect accessibility.
3 Encourage Authors to Create Accessible Documents
Guiding Principle: Help files, justifications and examples are critical if
authors are to become more aware of and implement Web accessibility
principles.
Guiding Principle: Once accessibility is integrated into authoring tools,
authors will be much more likely to produce accessible documents.
3.1 Emphasize accessible authoring practices [PRIORITY 1]
Recommended accessible authoring practices (and their priorities) must be
taken into account during the design of relevant user interface
components and program functionality.
Checkpoints:
[Checkpoint: 3.1.1] [PRIORITY 1]
All authoring practices discouraged by [Page-Author-Priority 1] are
not recommended or otherwise encouraged by the authoring tool.
[Checkpoint: 3.1.2] [PRIORITY 1]
The most accessible authoring practices are the most visible and
easily initiated by the author.
[Checkpoint: 3.1.3] [PRIORITY 1]
When predicting author behaviour, the goal of maintaining content
accessibility is assumed.
3.2 Provide comprehensive accessibility help to authors [PRIORITY 1]
The issues surrounding Web accessibility are often unknown to Web authors.
Providing convenient links to clear and concisely written help files
will contribute to author acceptance of, and education about, markup
accessibility.
Checkpoints:
[Checkpoint: 2.5.1] [PRIORITY 1]
Context sensitive help is implemented for all special
accessibility terms, as well as tasks related to accessibility.
Techniques:
[Technique: 2.5.1] [PRIORITY 1]
Mechanisms used to identify accessibility problems such as
icons, outlining or other emphasis within the user interface should be
linked to help files.
[Technique: 2.5.2] [PRIORITY 1]
The accessibility help files should explain the accessibility
problem or accessibility feature quickly, with emphasis placed on the
solutions available rather than placing emphasis on elements
that have been incorrectly marked up.
[Technique: 2.5.3] [PRIORITY 1]
The help files include many examples.
[Technique: 2.5.4] [PRIORITY 1]
The help files include links to any automated correction
utilities.
3.2 Provide rationales that stress Universal Design [PRIORITY 1]
Most users are unfamiliar with accessibility issues on the Web. By
incorporating explanations of Universal Design benefits into authoring
tools,
authors will better understand the value of accessible page design. The
Universal Design principle of flexible display and control choices are
critical
for:
hands free, eyes-free, voice-activated browsing devices such as Web
phones
the large number of slow Web connections (not everyone has a fiber
connection)
Web users who prefer text-only browsing to avoid "image clutter"
the aging population (with the accompanying decrease in visual,
hearing, motor, and cognitive abilities)
the relatively high Web presence of people with sensory and motor
disabilities.
Checkpoints:
[Checkpoint: 3.2.1] [PRIORITY 1]
The help system explains the importance of utilizing
accessibility features generally and for specific instances.
[Checkpoint: 3.2.2] [PRIORITY 1]
Explanations emphasize accessibility benefits for multiple
groups.
Techniques:
For more information on Universal Design, visit the Trace Center.
3.3 Promote accessibility in all Help examples [PRIORITY 3]
In addition to a help section dedicated to accessibility, accessibility
principles should be followed for all applicable markup examples in the
rest of
the help system. This will increase integration and help show authors that
accessibility is a normal part of authoring, rather than a separate concern.
Checkpoints:
[Checkpoint: 3.3.1] [PRIORITY 3]
Help files for markup practices that require accessible
solutions appear with those solutions. (ex. IMG elements should appear
with "alt"-text)
[Checkpoint: 3.3.2] [PRIORITY 3]
Help files include lower priority accessibility solutions.
3.4 Ensure that users may configure accessibility mechanisms [PRIORITY 1]
In supporting the creation of accessible Web content, authoring tools must
take into account the differing authoring styles of their users. 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.
Checkpoints:
[Checkpoint: 3.4.1] [PRIORITY 1]
The tools is designed so that users can indicate their preferences
regarding both the nature and timing of accessibility alerts.
[Checkpoint: 3.4.2] [PRIORITY 1]
The priority level given to accessibility recommendations for a
given language is taken into account when determining the level of user
control. Specifically, the user has the option of determining the
extent of alerts for [Page-Author-Priority 2] and [Page-Author-Priority 3]
recommendation items.
[Checkpoint: 3.4.3] [PRIORITY 1]
Users are prevented from disabling the lowest-level of non-intrusive
alerts for [Page-Author-Priority 1] items.
3.5 Integrate accessibility solutions naturally [PRIORITY 2]
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:
[Checkpoint: 3.5.1] [PRIORITY 2]
All functionality associated with accessibility is properly
integrated into the overall "look and feel" of the authoring tool.
[Checkpoint: 3.5.2] [PRIORITY 2]
Accessibility features never interfere with any of the expected
operations of an author's editing environment. For example, fundamental
operations such as saving, closing, and pasting should not be
canceled or postponed due to the existence of accessibility problems.
3.6 Provide the author with progress feedback [PRIORITY 3]
Achieving accessibility requires some extra effort and cooperation from the
author. In order to maintain user goodwill and acceptance of accessible
authoring practices, the user should receive progress feedback regarding
satisfied accessibility objectives.
Checkpoints:
[Checkpoint: 3.6.1] [PRIORITY 3]
The user is provided with progress feedback as accessibility goals
are accomplished.
4 Ensure the Authoring Tool is Accessible to Authors with Disabilities
Principles to consider in making the authoring tool accessible to authors
with disabilities relate to 3 classes of functionality:
1) The authoring tool is a software program with standard user interface
elements and as such should follow relevant user interface accessibility
guidelines (links to TRACE guidelines, Microsoft, SUN, DACX, Apple, IBM
guidelines)
2) The authoring tool frequently encompasses the functionality of a user
agent or browser and as such should follow the user agent guidelines.
3) The authoring tool has unique functionality as a Web content editor.
Access to this unique functionality will be addressed in these guidelines.
4.1 Provide optional views of the edited document
When creating or editing a Web page the desired ultimate rendering of the
page may not be optimal for creating and editing.
Checkpoints:
[Checkpoint: 4.1.1] [PRIORITY 1]
The authoring tools supports at least two views:
1.an authoring/editing view
2.a publishing or browser view, (similar to the normal and page
view or print preview of popular word processors).
Techniques:
[Technique: 4.1.1]
In the authoring/editing view, the font size, letter and line
spacing, and text and background color should be independent of the final
format
of the document.
4.2 Provide text representations of tags
Graphically represented elements cannot be identified by third-party
assistive technologies that translate text to Braille, speech, or large
print. Some
authoring tools display the start and end tags as graphics.
Checkpoints:
[Checkpoint: 4.2.1] [PRIORITY 1]
Allow the author to display tags in a text format.
[Checkpoint: 4.2.2] [PRIORITY 1]
Surround tags with text brackets to help distinguish the start or
end tag from the remainder of the document.
4.3 Provide text representations of site maps
Graphic representation of Web pages or Web site elements in site management
tools cannot be identified by third-party assistive technologies that
translate text to Braille, speech, or large print.
Techniques:
[Technique: 2.8.1] [PRIORITY 1]
Allow the author to display the site map in text form (e.g., as a
structured tree file).
Received on Tuesday, 12 January 1999 15:08:45 UTC