WAI Accessibility Guidelines:
Authoring Tools
W3C Working Draft 13-October-1998
Abstract
Note. This document provides guidance on the
development of Web authoring tools which produce accessible Web pages, consistent with the
'WAI Page Authoring Guidelines.
Status of this document
This is [not yet] a W3C Working Draft for review by W3C members and other
interested parties. It is a draft document and may be updated, replaced or obsoleted 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, or the consensus of, either W3C or members of
the WAI User Agent (AU) working group.
This document has been produced as part of the W3C WAI
Activity, and is intended as a draft of a Proposed Recommendation for how to improve
authoring tool accessibility. The goals of the WAI-AU
Working Group are discussed in the WAI-AU charter.
A list of the current AU working group members is available.
Available formats
Comments
Table of Contents
1 Ratings and Classification
2 Terms and Definitions
3 Guidelines for Accessible Document Production
4 Guidelines for Ensuring an Accessible Authoring Environment
5 Appendices
- 5.1 Appendix A: HTML4.0 "Alt"-Text Module
- 5.1.1 Sample Support Strategies
- 5.1.2 Images (IMG)
- 5.1.3 Applets
- 5.1.4 Image Maps (Client-Side and Server-Side)
- 5.1.5 Image Map Links (AREA)
- 5.1.6 Sample Automated Tools
- 5.1.6.1 "Alt"-Text Registry
- 5.1.6.2 Server-Side to Client-Side Image Map Converter
- 5.1.6.3 Description Text Editor
- 5.2 Appendix B: HTML4.0 Tables Module
- 5.2.1 Sample Support Strategies
- 5.2.2 Tables
- 5.2.3 Sample Automated Tools
- 5.3 Appendix C: HTML4.0 Forms Module
- 5.3.1 Sample Support Strategies
- 5.3.2 Forms
- 5.3.3 Automated Tools
- 5.3.3.1 FIELDSET Grouper
- 5.3.3.2 LABEL Maker
- 5.3.3.3 TABINDEX Assignment Mode
- 5.4 Appendix D: HTML4.0 File Conversion Module
- 5.4.1 Sample Support Strategies
- 5.4.2 Automated Tools
6 Acknowledgments
7 References
1 Ratings and Classification
Some of the guidelines are classified according to the following rating system.
- [Priority 1]
- This guideline must be implemented by an authoring tool, or one or more groups of users
will find it impossible to access either the tool or some of the information in documents
produced by the tool. Implementing this guideline will significantly improve access to Web
documents.
- [Priority 2]
- This guideline should be implemented by an authoring tool, or one or more groups of users
will find it difficult to access either the tool or some of the information in documents
produced by the tool. Implementing this guideline will improve access to Web documents.
- [Priority 3]
- This guideline should be implemented by an authoring tool to make it
easier for one or more
groups of users to access either the tool or some of the information in documents
produced by the tool. Implementing this guideline is not critical to accessibility,
however.
2 Terms and Definitions
2.1 Markup Authoring, Conversion and Generation Tools
- Authoring Tool
- An Authoring Tool is any application that is specifically designed to aid
users in the editing of markup language documents. The editing processes covered by this
definition may range from direct hand coding (with automated syntax support or other
markup specific features) to WYSIWYG editors that allow markup to be produced from a
browsing perspective. This definition does not include text editors and word
processors that also allow HTML to be hand produced.
- 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 dedicated Web publishers as well as "save
as HTML"(or other markup format) features in non-markup applications.
- Generation Tool
- A Generation Tool is a program or script that produces automatic markup
"on the fly" following a template or set of rules.
2.2 Inaccessible Markup
- 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 WAI Accessibility Guidelines: Page Authoring.
- Document
- A document is a series of elements that are defined by a language (e.g., HTML
4.0 or an XML application).
- Element
- Each element consists of a name that identifies the type of element, optional
attributes that take values, and (possibly empty) content.
- Attributes
- 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.
- Properties
- Properties describe the presentation of a document (e.g., font face, font
sizes for different headers, paragraph justification, text color, etc.).
- Current Value
- Each property has a current value at any moment (e.g., "Helvetica"
for font face, "12 point" for font size, "black" for text color, etc.)
The current value comes from one of the following sources: browser, document, or user.
- Default Value
- The value given to a property when the browser is first "turned on" is called
the default value. Browsers may allow users to change default values through a
variety of mechanisms (e.g., the user interface, style sheets, initialization files,
etc.). Setting the current value of a property does not change the default value.
- Author Styles
- A property may receive its current value when the user agent reads a document: through
style sheets within the document or linked externally, through the presentation attributes
of an element, via a server, etc. These values are called author styles.
- User Styles
- The user may set the current value through user style sheets or the user interface;
these are called user styles.
Authoring tools allow users to interact with document through several mechanisms.
- 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.
- Viewport
- A user accesses the information in a view through a window, frame, or other viewport.
The size of the viewport may prevent the user from accessing all of the information in the
view at once; viewports may offer scrolling mechanisms to give access to all of the view's
information.
- 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 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). [Note: highlighted text is often used by third-party
assistive technologies to indicate through speech or Braille output what the user wants
read. Most screen readers are sensitive to highlight colors. Third-party
assistive technologies may provide alternative presentation of the selection through
speech, enlargement, or dynamic Braille display.]
- Focus
- The focus designates the element (link, form control, element with associated
scripts) in a view that will react when the user next interacts
with the document.
- Activate
- The user is said to activate the element with the focus. For instance, a user
may activate a link (which usually causes the user agent to follow the link), a form
control (which usually causes a change of state in the form control), or an element with
associated scripts. A view has only one focus.
- Current Focus
- When several views co-exist, each may have a focus, but only one is active, called the current
focus.
- Current View
- Both the current focus and the current user selection must be in the same view, called
the current view.
- Alternate Textual Representations
- Certain types of content may not be accessible to all users (e.g., images), so authoring
toold must ensure that alternate textual representations
("Alt-text") of information be available to the user. Alternate text can come
from element content (e.g., the OBJECT element) or attributes (e.g., "alt" or
"title").
- 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.). The "WAI Accessibility Guidelines: Page
Authoring" document (see [WAI-PAGEAUTH]) describes
when and how to insert description links in a document. D-links should be identified in
the document source by giving the "rel" attribute the value "dlink".
2.7 Inserting and Editing
- 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 UI
manipulation.
-
2.8 Miscellaneous
- Emphasis
- Emphasis refers to the practice of drawing attention to an option or
component within a user interface. This may be acheived with techniques including, but not
limited to, placement, coloration, font, special icons, or layout.
- Prompting
- Prompting refers to requesting or encouraging the author to follow a given
set of steps. In the context of this document, prompting will usually refer to requests
for small amounts of descriptive information or organizational structure.
- Automated authoring aids
- Automated authoring aids are the features of an authoring tool that allow the user to
produce markup without directly typing it. This defines 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.
3 Guidelines for
Development of Web Authoring Tools that Support Accessibility
3.A.1 [Priority 1] Support all accessiblity features of relevant
languages (HTML, CSS, SMIL, XML, etc.)
Implementation Priorities:
Accessibility Features
3.A.2 [Priority 1] Emphasize accessible authoring practices
All recommended page author solutions (and their priorities) must be taken into account
during the design of relevant user interface components and program functionality. In
particular:
- When more than one means of performing a particular authoring task is available, the
most accessible means of performing that task should also be the most visible and easily
initiated.
- When ambiguous situations arise, authoring tools should always assume that authors
intend to create accessible pages
- Authors must not be permitted to neglect accessibility solutions that are required
by a particular language (e.g. "alt"-text in HTML4.0).
3.A.3 [Priority 1] Expose all inaccessible markup
Whenever the authoring tool processes markup text, it must check for and expose all inaccessible markup. This includes continuously
checking documents during editing as well as checking previously existing documents
(created by any means) if they are opened for further editing. Any problems should be
advertised to the author immediately, even if the option of delaying the correction is
left open. Suggested methods for alerting the user include:
- presenting a warning
- placing emphasis in the form of icons, underlining, outlining
(etc.) at the point in the document at which the problem was located.
- activating an accessibility correction system
3.A.4 [Priority 2] Promote accessibility awareness in tool
suites
Language markup authoring tools often form part of integrated web publishing suites
that also include peripheral tools for handling non-coding tasks. Examples of these tools
and recommended roles they may play in an integrated accessibility approach appear below:
- Site Management Tools: These tools already routinely perform checks for site
issues such as broken links. The ability to check for and correct (at least) Priority 1
accessibility problems should be added to these tools. Documents missing required
accessibility solutions (such as "alt"-text for HTML4.0) should be prevented
from web publishing until the problems is corrected.
- Image Editors: Image editors should be modified to encourage the writing of
short "alt"-text and long description text for any images produced. This will
allow easy cataloging and future searching of images as well as pre-written default text
that can be used if the image is placed in a web page.
- Video Editors: Video (as well as animated gif) editors should be modified to
encourage the writing of long description text as well as transcripts. This will
allow easy cataloging and future searching of videos as well as pre-written descriptive
text that can be used if the video is placed in a web page.
3.A.5 [Priority 2] Integrate accessibility features
naturally
When a new feature is added to an established software tool without proper integration,
color schemes, fonts, and interaction styles may differ and interface bugs may be more
frequent.
In order to gain user acceptance of accessible authoring, it is imperative that the any
new functionality associated with accessibility be properly integrated into the overall
"look and feel" of the authoring tool. By making small modificications to all
the pre-existing interface components that are relevant to accessibility awareness , the
need for dedicated components will be reduced, keeping the footprint of the accessibility
changes to a minimum..
3.A.6 [Priority 3] Allow users to configure levels of
accessibility awareness
Authoring tools should be designed so that accessibility awareness is at least
partially user configurable. The author should be given the freedom to customize the
system within the constraints of the priority levels defined by the WAI Accessibility Guidelines: Page Authoring. In particular:
- Authors should NOT have the option of disabling checking for Priority 1
problems (e.g. "alt"-text in HTML4.0).
- Authors should be able to customize the alert list for Priority 2 and Priority 3
problems.
- Authors should be able to decide between interuptive warnings, or some other less
intrusive alert system
- Authors should have the option of disabling tooltips, predictors and other active
accessibility system features
3.B.1 [Priority 1] Provide context-sensitive accessibility
help to authors
The issue of web accessibility is often unknown to Web authors. The provision of
convenient links to clear and concisely written help files will contribute to author
acceptance of and education about markup accessibility.
The focus or edit position within the authoring environment when the Help system is
activated should be used to provide the context for the help response. It is especially
important to implement context sensitive help for any special accessibility icons,
outlining or other emphasis within the user interface, since these may appear foreign.
The help files themselves, should explain the accessibility problem or accessibility
feature quickly, with emphasis placed on the solutions available rather than the
incorrectness of using a certain markup element. The help files should include frequent
examples as well as links to any automated correction utilities (See
Section 3.C.5).
The WAI Accessibility Guidelines: Page Authoring and WAI Accessibility Guidelines: Page Authoring Techniques
have now been structured in a way that simplifies the task of writing help files, since
the problem, rationale and solution techniques are all stated explictly.
3.B.2 [Priority 1] Provide rationales that stress Universal
Design
Since most users probably have little knowledge of accessibility issues, it is
understandable that they will question the justification for certain requests. The author
attitude that accessibility means devoting time and effort to things they believe will
never use is a major acceptance barrier. Therefore, justification should comprise an
important part of the accessibility Help system. Within the justification area it will be
important to emphasize the wider benefits of providing Universal Design. The major
argument of these justifications should be that most authoring decisions that support
access for users with disabilities also have benefits for users with other needs or
abilities. The principles of supporting flexible display and control choices has 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 (not everyone has a fiber connection)
- web users who prefer text-only browsing to avoid "image clutter"
The justifications should also address:
- 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.
For more information on Universal Design, see the WAI
Justifications Document
3.B.3 [Priority 2] Ensure that all Help examples are
accessible (Weak? - I. Jacobs)
In addition to the dedicated accessibility help section (see 3.B.1, 3.B.2),
accessiblity principles should be followed for all applicable markup examples in
the rest of the help system. In particular:
- All markup practices that require accessible solutions should appear without those
solutions (ex. no IMG elements without "alt"-text)
- Lower priority accessibility solutions should also be included to increase their
visibility
This will increase integration and help show authors that accessibility is a normal
part of authoring, rather than a separate concern.
3.B.4 [Priority 2] Package multimedia files with pre-written
descriptions
Textual descriptions, 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 authors.
Authoring tool developers should include professionally written descriptions for all
multimedia files shipped with their tools in order to satisfy the following important
objectives:
- users will be saved time and effort
- a significant number of professionally written descriptions will begin to circulate
- users will be provided with convenient models to emulate when they write their own
descriptions
- users will see evidence of the importance of description writing
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.
The inclusion of descriptions has the additional benefit of allowing authors to make
time-saving searches of the multimedia database.
The key to increasing the accessibility of the web is to take advantage of the
power of automation to free authors to concentrate on the higher-level aspects of web
authoring.
3.C.1 [Priority 1] Allow the user to check for and correct
accessibility problems automatically
Many authoring tools allow their users to create markup documents with little or no
knowledge about the underlying structure of the language. Accessibility problems must be
corrected in an analgous fashion. Every authoring tool must include some kind of automated
tool for automatically traversing a document to identify and help correct accessibility
problems as they are defined by the WAI Accessibility
Guidelines: Page Authoring. The tool must be designed to allow authors the option of
making corrections without necessarily understanding either the details of markup
accessibility.
3.C.2 [Priority 1] Ensure that all markup inserted through
the user interface is accessible
When markup is automatically generated, the author has, by definition, lost the ability
to precisely specify the nature of the produced markup.If the automation results int
inaccessible markup, authors who are aware of access issues will have to expend extra
effort to make the appropriate corrections by hand. However, most authors will continue,
unaware of the problem.
Automated authoring aids should always make
use of appropriate accessible solutions, even if this means presenting the author with
extra prompts for necessary information or structure. Under no
circumstances should these tools make use of algorithms that automatically produce inaccessible markup.
3.C.3 [Priority 1] Ensure that conversion tools produce
accessible markup
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. This process
is often hidden from the user's view and creates inaccessible documents. Just as it is
recommended that authoring aids not produce inaccessible
markup (See Section 3.C.2), conversion utilities should also
avoid generating documents that contravene the WAI
Accessibility Guidelines: Page Authoring. Ensuring that accessible solutions are
produced will most likely involve both prompting the author to supply alternative
information as well as minor changes to the aesthetic appearance of the document.
3.C.4 [Priority 1] Avoid removing or modifying any of the
existing structure or descriptive content of documents
When a document is opened by an authoring tool that did not create it, changes often
need to be made to the markup to allow efficient functionning of the tool.
Unfortunately these modifications often have the effect of removing markup required for
accessibility. Therefore:
- Authoring tools should never remove or modify structure or content that is necessary for
accessibility
- Authoring tools are allowed to change a document to make it more accessible.
- Authoring tools must allow users to know when any changes are made.
Section Editors: Treviranus
Closely related to UA group because editing is very similar to browsing. This
group also does a good job of pointing to resources.
Some original stuff about an authoring UI - accessible dialogs, alternatives to icons
etc.
Also needs links to resources for making software accessible.
The following appendices are examples of how authoring tools might be modified to take
accessibility into account. Each module deals with a serious accessible authoring issue:
"alt"-text, tables, forms and format conversion. Each module outlines possible
strategies for supporting the production of documents that are accessible with respect to
these issues. In addition, sample warning and help text is included.
Section Editors: Richards, Treviranus
"Alt"-text is generally considered the most important aid to
accessibility. For this reason, the "alt"-text Section of the WAI Accessibility Guidelines: Page Authoring should receive
special emphasis both within the user interface and within the Help system.
A.1 Sample Support Strategies
The following strategy deals exclusively with images. However, the strategy could
just as easily apply to the other elements that require "alt"-text.
- The user interface of the Sample Accessibility Aware Authoring Tool (SAAAT) is designed
so that "alt"-text is required.
- Immediately after choosing an image to insert the SAAAT searches its
"alt"-text registry for an existing description. If a description is found, it
is entered as default text in the font and color emphasized "alt" text entry
field. If no description exists an Image Property dialog is presented with focus on the
font and color emphasized "alt" text entry field. A one line tooltip guideline
activates immediately, requesting the user write a short description. Links are available
to extended help and rationale files.
- If the user disregards this prompt attempt, they may return to editing, but the SAAAT
places a small visual marker next to the image in the document.
- If the user attempts opens the Image Property Dialog to edit another attribute, the font
and color emphasized "alt" text entry field is given initial focus.
- The missing "alt"-text error is given special emphasis when the user runs an
accessibility check on the document.
- Finally, the SAAAT presents a missing "alt"-text warning notice whenever a
save is performed.
- When an "alt"-description is entered, the image-description association is
immediately saved in the "alt"-text registry.
- All images that are bundled with the SAAAT are accompanied by professionally written
"alt"-text registry entries and pre-written long description files.
A.2 Images (IMG)
- Sample Warning Text:
- "The IMG element that has just been inserted requires "alt"-text."
- Important Points for Help File Text:
- Images are the most common inaccessible elements on the web.
- Screen readers, used by people with visual disabilities, cannot access the image content
(including any graphically presented text).
- Users of text only browsers or slow connections often navigate with Image Loading turned
off.
- Images can be made more accessible using the "alt" (alternate text) attribute
of the IMG element to add a short textual description, which can be displayed in place of
the image by text-based browsers and graphical browsers whose image loading has been
disabled.
- Refer to WAI Accessibility Guidelines: Page Authoring
Techniques Document for ""alt""-text help file authoring tips:
A.3 Applets
- Sample Warning Text
- "The APPLET element that has just been inserted requires "alt"-text"
- Important Points for Help File Text
- The APPLET element is deprecated, so it should be avoided.
- If it is used, the APPLET element should include an "alt"-text that describes
its function and content.
- Alternate textual presentations of the content should also be made available.
A.4 Image Maps (Client-Side and Server-Side)
- Sample Warning Text
- "The image map that has just been inserted requires "alt"-text"
- Important Points for Help File Text
- Image maps are a very popular and effective way of conveying information.
- To access an image map, a user requires a graphical browser, a fast connection as well
as the physical ability to see the screen and move a mouse pointer.
- Client-side image maps (that use the AREA element to define their links) can be accessed
by keyboard control within several browsers. If "alt"-text is provided for
each link then these image maps become accessible to people with visual impairments.
Therefore, it is recommended that you convert any server-side image maps into
client-side image maps.
- It is always recommended that a textual listing of the links within all server-side and
client-side image maps for users with older browsers or slow connections be provided..
A.5 Image Map Links (AREA)
- Sample Warning Text
- "The image map link (AREA) that has just been inserted requires
"alt"-text"
- Important Points for Help File Text
- The AREA element defines the individual link hotspots within a client-side image map.
- Some browsers have a keyboard function that allows users to TAB through all the links on
a page, including each AREA. This feature is important for users with visual or mobility
disabilities, who have difficulty controlling a mouse effectively.
- In order for a client-side image map to be accessible, each AREA element must have an
"alt"-text description that describes the function of the link.
- "Alt"-text for the full image map is still required to tell the user that the
image is an image map. This text should also emphasize whether there are alternative text
links or if the reader should rely on the alt-text for the AREAs.
- A descriptive text file may also be used to give users the full flavour of the image
map's design and purpose.
A.6 Sample Automated Tools
A.6.1 ALT Text Registry
This tool does not have a visual window presence as far as the user is concerned. It
works by saving an association between every "alt"-text label that a user writes
with the name of the image, applet, image map, or image map link. Then, whenever one
of these elements is inserted, the file name information of the object is checked against
the registry association file. If a match is found, then the pre-written "alt"
text is displayed as a default choice, allowing users to avoid the repetition of writing
multiple descriptions for the same image. The ability to store several descriptions in
different languages might also be supported. In more sophisticated implementations, the
tool may include a prediction algorithm that takes into account the recency of the
"alt"-text, name similarity, and target similarity when searching for matches.
This tool has the curb-cut advantage that the descriptions (especially the
professionally written ones that come with bundled images) will allow users to search
images using keyword searches, thereby simplifying the task of finding appropriate images.
A.6.2 Server-Side to Client-Side Image Map Converter
This tool takes the page containing the Server-Side image map as well as the map file
as input. It converts the information in the map file into AREA elements within a MAP
element placed in the document. The author will be prompted for alt-text for the
full image (if it is absent) and for each link. If the map file contains link
comments, these will be used as default "alt"-text.
A.6.3 Description Text Editor
This tool is a dialog based utility that allows users to include descriptive text
without necessarily knowing how to format it properly. The editor will prompt the
author for a description, while displaying the image for easy reference. Then the author's
description can be used (adter spell checking) to create a new HTML file which is linked
from the image by way of the LONGDESC attribute of IMG. Legacy implementations may also
choose to support d-links.
Section Editors: Bingham, ???
[Priority 2] Authors should be aided in providing proper structure for tables.
B.1 Sample Support Strategies
B.2 Tables
B.3 Sample Automated Tools
Section Editors: Richards, Treviranus
Improvements in access and user agent technologyhave meant that forms are not as
inaccessible as they once were (for those users with the newest technology). However, the
practice of good organization and labelling is always necessary because it helps all
users.
C.1 Sample Support Strategies
- The user interface of the Sample Accessibility Aware Authoring Tool (SAAAT) is designed
so that authors are guided towards the production of organized, easy-to-use forms.
- The SAAAT includes a LABEL-maker feature that automatically creates associated LABEL
elements for each non-labelled form control..
- The SAAAT also includes a FIELDSET grouping feature that helps the user organize their
form using the FIELDSET and CAPTION elements to group and label functionally associated
controls.
- The SAAAT warns users that images or image maps used as graphical "submit"
buttons should be replaced with either BUTTON (of type "submit") or INPUT
(of type "image") elements. If the author chooses the second case, they are
prompted to provide "alt"-text.
- When the length of a SELECT list grows beyond a certain threshold, the SAAAT suggests
that the author make use of the OPTGROUP element to organize the list into subgroups..
- Once the number of links and form controls in a document reaches a certain threshold,
authors are advised that a TABINDEX and ACCESSKEY assignment mode exists, that allows a
TABINDEX order or ACCESSKEY hotkey combination to be easily defined.
- Sample Warning Text
- "The form control element that has just been inserted requires an associated LABEL
element."
- Important Points for Help File Text
- Forms are becoming more universally accessible as browsing technology advances.
- However, forms with many controls that rely on visual layout for their organization can
be exteremly difficult to navigate without a screen.
- For example, the association between an edit box and the text label, that identifies the
type of information the reader should enter, is often purely visual.
- The new LABEL element in HTML4.0 allows labels to be logically associated with form
controls.
- The FIELDSET element allows controls to be grouped within dialog type organizational
boxes.
- HTML4.0 includes the TABINDEX and ACCESSKEY elements. TABINDEX allows
authors to define a keyboard navigation order for links and form controls and ACCESSKEY
allows quick keys to be defined for frequently used links and form controls.
- In order to ensure full accessibility, alternative contact information should always be
provided (e.g. email, phone numbers, fax numbers and postal addresses).
C.3 Sample Automated Tools
C.3.1 LABEL Maker
Whenever a form control without an implict label (e.g. edit box, pull down menu, etc.)
is inserted, this tool automatically defines a default ID for the form control and uses
this to link an associated LABEL element (using the "for" attribute). The tool
immediately places the LABEL to the right of the form control with focus. Tooltip text
informs the user that a label text should be entered and that the position of the label
can be changed. If the user changes the form controls ID, the tool will ask the user if
they wish to update the LABEL's "for" attribute as well. After a LABEL has been
created, selection of the LABEL or FORM control will cause a visual emphasis of both
elements in the associated pair.element.
C.3.2 FIELDSET Grouper
This tool will suggest the creation of a FIELDSET group box whenever an ungrouped set
of five or more form controls is inserted by the author. If the author agrees, a FIELDSET
element will be inserted to enclose the controls. The LEGEND element that defines a
heading of the group box will receive focus at the end of the operation and a tool tip
will instruct the author to enter a heading for the controls.
C.3.3 TABINDEX and ACCESSKEY Assignment Mode
This tool is a mode that allows the user to define either tab order or a hotkey. Once
the mode is activated (by menu item or toolbar button), the present tab order and any
existing hot keys are displayed. The author can the change the tab order by selecting the
links or form controls in the preffered order, with the mouse or keyboard. Holding a key
while selecting a link or form contol will create an ACCESSKEY shortcut.
Section Editors: Richards, Treviranus, ???
[Priority 1] Avoid removing or modifying existing structure (especially
"alt"-text) without user notification.
[Priority 1] Avoid automated use of any inaccessible markup.
D.1 Sample Support Strategies
D.2 Sample Automated Tools
- [HTML40]
- "HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds. The
HTML 4.0 Recommendation is available at:
http://www.w3.org/TR/REC-html40/.
- [CSS1]
- "CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds. The CSS1
Recommendation is available at:
http://www.w3.org/TR/REC-CSS1-961217/.
- [CSS2]
- "CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs,
eds. The CSS2 Recommendation is available at:
http://www.w3.org/TR/REC-CSS2/.
- [WAI-PAGEAUTH]
- "WAI Accessibility Guidelines: Page Authoring", G. Vanderheiden, W. Chisholm,
and I. Jacobs, eds. These guidelines for designing accessible documents are available at:
http://www.w3.org/TR/WD-WAI-PAGEAUTH.
- [Page Authoring
Techniques]
- "WAI Accessibility Guidelines: Page Authoring Techniques", G. Vanderheiden, W.
Chisholm, and I. Jacobs, eds. These guidelines for designing accessible documents are
available at:
http://www.w3.org/WAI/wai-gl-techniques.
- [CSS2-ACCESS]
- "WAI Resources: CSS2 Accessibility Improvements", I. Jacobs and J. Brewer,
eds. This document, which describes accessibility features in CSS2, is available at:
http://www.w3.org/WAI/References/CSS2-access.
- [HTML4-ACCESS]
- "WAI Resources: HTML 4.0 Accessibility Improvements", I. Jacobs, J. Brewer,
and D. Dardailler, eds. This document, which describes accessibility features in HTML 4.0,
is available at:
http://www.w3.org/WAI/References/HTML4-access.
- [Access Aware Authoring Tools]
- "The Three -tions of Accessibility-Aware HTML Authoring Tools", J. Richards.
Available at:
http://www.utoronto.ca/atrc/rd/hm/3tions.htm.