A A A A A

(Inactive) Best Practices for Designing Course Content (BPDCC) Documentation

Announcements

This group is no longer active.

BPDCC RESEARCH MATERIALS

Web Best Practices Materials

1. Navigation & Orientation

1.1 Titling & heading

1.1.1 – Provide meaningful and unique page titles.

What:

Page titles appear in the title bar at the very top of the web
browser window. In HTML, the page title is specified using the title
tag.


Why:

Screen readers announce the page title whenever a new page is
loaded. Screen readers use also the title tag information to announce
the intended page when switching from one browser session or tab to
another.


How:

Every web page should have a title. The title should indicate
both the name of the site and the topic of the page and should be
unique within the site whenever possible. Note that Titles should
usually be 60 or fewer characters in length.


1.1.2 – Use heading elements H1-H6 to structure your page
logically and hierarchically.


What:

Headings are used to introduce sections and sub-sections
within a page. HTML includes six levels of headings
(<h1>, <h2>, <h3>,
<h4>, <h5>, and <h6>,
representing
the different levels in an “outline” of the page. Web browsers normally
display headings in large, bold font.


Why:

Screen readers and some browsers like Opera use these
structure to skip from one heading to another which eases navigation
and orientation for blind and keyboard users.


How:

Start the main content area of each page with an <h1>
heading that indicates the topic of the page as identified in the page
title. If the page is long
enough to be divided into sections, group each section in a
<div> and begin each <div>with a heading of
the appropriate level:

Use Cascading Style Sheets (CSS) to control the size and appearance of
headings.
Note: Headings (and other elements) may be hidden visually but revealed
to assistive technologies using a style such as:
.invisible { position: absolute; left: -10000px; width: 1px; height:
1px; overflow: hidden; }

1.1.3 Choose a meaningful and descriptive text for the main
heading that is a subset from the title of your page and make it an h1
element.


What:

The main heading of each page should be always an h1 element.


Why:

Assistive technology software like screen readers provide a
very easy navigation to headings including h1 headings. This will allow
screen readers to quickly find the main heading of the page regardless
of their location on the page.


How:

Choose a meaningful text for the main heading and make sure that the
text is a subset from the title. Note that unique title are helpful
when blind users are switching from one browser session/tab to another
and the meaningful text for the main heading is useful for navigation
and orientation within the same page. The fact that the main heading is
a subset from the title would help blind users to match the main
heading with the title of the same page.

1.2 Navigation Bars & Menus


1.2.1 Group menu items logically and use unordered list to
organize them.


What:

??
Why:

??
How:

??

1.2.2 provide meaningful headings to each navigation bar/menu.


What:

??


Why:

HTML markup language does not have any mean to identify
navigation bars/menus. Until the ROLE attribute is supported widely by
browsers and assistive technologies, use a consistent heading level
(preferably h2) to identify each navigation bar/menu.


How:

Headings can be set off-screen if it is preferred that they
not be displayed.


1.2.3 Provide full keyboard support for dynamic menus.


What:

??


Why:

??


How:

??


1.2.4 Provide means to identify selected tab in multi-tab
style interfaces.


What:

??


Why:

??


How:

??


1.2.5 Provide a means of skipping past repetitive navigation
links.


What:

Navigation links are the lists or “menus” of links to all the
sections of a site that are often repeated on every page.


Why:

Because navigation links are typically placed at the beginning
(top left) of pages, screen reader users must read through all the
navigation links before reaching the main area of the page. Individuals
who use a keyboard instead of a mouse similarly must tab through all
the navigation links before reaching the main area of the page.
Providing a means of skipping these links can significantly improve
efficiency and usability for screen reader and keyboard users.


How:

Provide a link at the beginning of navigation lists that
points to a target at the beginning of the main content area of the
page. This link must be visible to screen reader and keyboard users,
but can be hidden from other users. It is also acceptable to design a
page so that navigation links come at the end of the document.



2. Content


2.1 Document structure & Markup


2.1.1 Use appropriate markup to convey document structure.


What:

HTML includes “markup” (programming code) to identify the
structural elements of a document. For example, <p>
identifies a paragraph, <h1> identifies a heading, and
<ul> identifies an unordered list.


Why:

Screen readers use structural information to move within a
page. For example, most screen readers can skip from heading to
heading, announce the number of items in a list, and identify the
current row and column in a data table.


How:

Identify headings, paragraphs, lists, quotations, etc., using
the appropriate markup instead of relying solely on formatting. For
example, use <h1> tags to identify the top-level heading
rather than simply making its text large and bold. Do not misuse
structural markup for formatting effects, such as using
<blockquote> to indent a paragraph. Use Cascading Style
Sheets (CSS) for formatting.


2.2 Text


2.2.1 – Use text to display text, unless formatting that
cannot be achieved with CSS is required.


What:

Web developers often use images of text to achieve a specific
style, size, or special effect.


Why:

Users with limited vision rely on the ability to enlarge text
or choose enhanced color combinations. However, most web browsers
cannot change the size and color of images.


How:

Whenever possible, use actual text instead of images of text.
Cascading Style Sheets (CSS) can be used to achieve specific sizes,
colors, or effects. Text that requires exact formatting, such as logos
and/or other branding elements, are appropriate exceptions.


2.2.2 – Use relative sizes for fonts.


What:

Font sizes can be set using “absolute” or “relative” units of
measurement. Absolute units, notably pixels (px), points (pt), and
inches (in), are based on fixed physical measurements; “relative”
units, such as percentages (%) or keywords (e.g., small, medium, or
large) are based on the user’s default font size.


Why:

Users with limited vision often rely on the ability to enlarge
text. Most web browsers allow users to easily change the size of text
that has been set with relative units (or not set at all). Using
absolute font sizes generally makes it more difficult for users to
change text size to meet their needs.


How:

Set font sizes using relative measurements or avoid setting
font sizes altogether.


2.2.3 – Identify the language of text.


What:

HTML uses the lang attribute to specify language in a web
page. It can be set for any HTML element.


Why:

Words written in foreign languages can be unintelligible when
spoken by a screen reader. Most screen readers are able to pronounce
words in their appropriate language if it is specified.


How:

Use the lang attribute on the <html> element to
identify the primary language of each document, for example,
<html lang=“en”>, for English. Use the lang attribute on
<span> or other elements to identify words or phrases in
other languages. For example, a Spanish phrase within an English
document could be coded as: <span lang=“es”>se habla
espanol</span>.


2.2.4 – Use images instead of “ASCII art.”


What:

ASCII art is images created using special arrangements of text characters and symbols. For example,)” is often used to create
a smiley face, and “-> is often used as an arrow.

Why:

Screen readers read most ASCII art literally, which can be extremely confusing. For example,)” reads as “colon dash right
parenthesis” and “->” as “dash greater than.”


How:

Use images with appropriate alternate text instead of ASCII
art.


2.2.5 – Use separate accessible versions only as a last
resort.


What:

Separate accessible or “text-only” versions are often offered
instead of providing a single accessible site.


Why:

In practice, “text-only” versions are rarely kept complete or
up-to-date. Given advances in accessibility techniques and assistive
technologies, “text-only” sites are simply not necessary in most cases.


How:

Follow these standards to develop a single site that is
universally accessible and efficient to maintain.


2.3 Colors


2.3.1 – Do not convey information with color alone.


What:

Color is often used to indicate special functions or status.
For example, required form fields are frequently indicated with red
labels.


Why:

Users with blindness, limited vision, or color-blindness may
miss information presented with color.


How:

Whenever color is used as an indicator, use a non-color-based
indicator as well. For example, required form fields could be
identified with an icon (an image with appropriate alternate text) in
the label, as well as with color.


2.3.2 – Use contrasting foreground and background colors.


What:

Web authors can set specific colors to be used for foregrounds
(text) and backgrounds. Sometimes images are used as backgrounds.


Why:

Users with limited vision or color-blindness may have
difficulty reading text that is similar in color to its background.


How:

For text, use dark colors on light backgrounds, or vice versa.
Avoid combinations of red and green as well as busy background images.
Text must have a contrast ratio of at least 3:1.


2.4 Images


2.4.1 – Provide appropriate “alternate text” for all images.


What:

The HTML image element <img> includes an
“alternate text” attribute (alt) that is used to provide text that can
be substituted when the image itself cannot be displayed. Alternate
text is meant to be a concise replacement for an image and should serve
the same purpose and convey the same meaning.


Why:

Individuals who are blind cannot perceive information
presented in images; screen reading software reads alternate text
instead.


How:

ALL images must have appropriate alternate text. As a rule of
thumb, consider what you might say if you were reading the web page to
someone over the telephone. You do not need to include the words “image
of” or “graphic of.” Specifically:



2.4.2 – Provide full descriptions for graphs, diagrams, and
other meaningful images.


What:

“Meaningful” images are images that convey more information
than can appropriately be expressed as alternate text.


Why:

A full description allows a user who cannot see or understand
a meaningful image to receive the same information as a sighted
individual.


How:

Present a full description of a meaningful image either on the
page on which the image appears or through a link immediately preceding
or following the image. Use alternate text to provide a concise name
for the image. For example, the alternate text of a graph should state
its title and the full description should summarize its trends and/or
present a table of its data.
Note: The longdesc attribute of the <img> element can
also be used to provide a link to a full description. Because longdesc
it is not yet supported by most web browsers, it should not be used as
the only method of providing a full description.


2.5 Image Maps


2.5.1 – Provide alternate text for each area in client-side
image maps.


What:

Image maps are images divided into multiple “areas,” with each
area having its own hypertext link.


Why:

Just as images must have alternate text, each area of an image
map must also have appropriate alternate text for use when the image is
not displayed.


How:

Use alternate text that indicates the function or destination
of the link for each area of a client-side image map. The image itself
should have alternate text that indicates the overall function of the
image map.


2.5.2 – Use client-side image maps instead of server-side
image maps unless areas cannot be defined with available shapes.


What:

While client-side image maps and server-side image maps look
and operate similarly, they are technically very different. Because of
the way server-side image maps work, all information about the image
and links is stored at the web server and is not available to the
user’s web browser or assistive technology.


Why:

Screen readers cannot identify or read the separate areas or
links within server-side image maps.


How:

Whenever possible, use client-side image maps instead of
server-side image maps. If server-side image maps must be used, provide
an accessible alternative that includes the same content and
functionality. In cases where it is impossible to create an equivalent
accessible version, such as with some geographical imaging and mapping
systems, exceptions may be necessary.


2.6 Multimedia


2.6.1 – Do not convey information with sound alone.


What:

It is possible to use sound for a variety of purposes,
including presenting warning signals, cues, or verbal instructions.


Why:

Users who are deaf or hard of hearing may miss information
provided only through sound.


How:

Whenever significant information is provided by sound, include
a visual indicator that provides the same information as well.


2.6.2 – Do not automatically play audio.


What:

It is possible for a web page to automatically play sound or
music when it loads.


Why:

Background sounds or music can make it difficult or impossible
for screen readers user to hear their screen readers.


How:

Do not automatically play audio for more than 3 seconds.
Provide a means for users to start audio playback when they desire
(e.g., a “play” button).


2.6.3 – Provide text transcripts for informational audio
contents.


What:

“Audio containing speech” includes audio recordings or live
broadcasts of speeches, seminars, conferences, etc. A text transcript
is a word-for-word written record of the spoken content of such an
event.


Why:

Individuals who are deaf or hard of hearing may require text
transcripts to access audio information.


How:

Provide a link to an HTML or text transcript of any audio
presented on a web site. Transcripts should be posted at the same time
the audio is made available. Communication Access Realtime Translation
(CART) providers can transcribe live events.


2.6.4 – Provide synchronized captions for all multimedia that
contains essential auditory information.


What:

Multimedia generally refers to recorded or live media
containing both video and audio tracks. Captions are essentially a text
transcript of the audio synchronized with the audio/video tracks of the
presentation.


Why:

Individuals who are deaf or hard of hearing may require
captions to access the audio information in multimedia.


How:

Whenever possible, captions should be implemented using
Synchronized Multimedia Integration Language (SMIL) If multimedia
contains essential audio but no essential video, a text transcript may
be provided instead of captions.


2.6.5 – Provide audio descriptions for all multimedia that
contains essential visual information.


What:

Audio descriptions are verbal descriptions of the actions and
images displayed in a video that are inserted during pauses in the
regular dialogue or audio track. Audio descriptions are only necessary
if significant information that is presented visually is not
discernable from the dialogue or audio track.


Why:

Individuals who are blind or low-vision may require audio
descriptions to access the visual information in multimedia.


How:

Carefully consider whether audio descriptions are necessary to
present the significant information of a multimedia recording. Many
speech-intensive events, such as speeches, lectures, or conferences, do
not contain essential video and, therefore, do not need audio
description. When necessary, audio descriptions are usually best
implemented by a professional “audio describer.”


2.7 Links


2.7.1 – Ensure that links are understandable out of context.


What:

A link is understandable out of context when it clearly
indicates its destination or function without requiring additional
information.


Why:

Screen reader users often “tab” through links (skip from link
to link by pressing the Tab key) in order to “scan” a page. Most screen
readers also offer a “links list” feature to help speed the process of
navigating to specific links. Links that are not understandable out of
context, such as “click here” or “more,” make these techniques much
less efficient. Some screen readers can be configured to read link
title attributes instead of link text, however most currently read only
link text by default.


How:

Use link text that is clear and unambiguous. Link text should
usually match the title of the page to which the link points. Ensure
that links that point to the same URL use the same link text, and that
links that point to different URLs use different link text. If title
attributes are used, repeat the text of the link as the beginning of
the title, followed by the additional information.
Note: Portions of links may be hidden visually but revealed to
assistive technologies using a style such as:


.invisible { position: absolute; left: -10000px; width: 1px; height: 1px; overflow: hidden; }<br />

2.7.2 – Avoid using small links.


What:

The size of the “clickable” area of a link is limited to the
size of the image or text that makes up the link.


Why:

Mouse-users with limited fine motor control may have
difficulty pointing to and clicking on links that are small, especially
if the links are close together.


How:

Make sure that images used for links are reasonably large,
preferably 16 pixels by 16 pixels or larger. Use standard or enlarged
font sizes for text links, and avoid using text links that are shorter
than 4 characters in length. Avoid placing small links close together.


2.7.3 – Ensure that same-page links move keyboard focus as
well as screen focus.


What:

Same-page links are links that target another location on the
same page. The target is usually indicated with a “named anchor” (e.g.,
). When a same-page link is
clicked, the screen should scroll and keyboard focus should move to the
target location on the page.


Why:

Users with physical or visual impairments may not be able to
use a mouse. Same-page links can enable these users to more quickly and
efficiently move about a page. Unfortunately, Internet Explorer 5, 6
& 7 do not reliably move keyboard focus to the target of same
page links.


How:

To ensure that same-page links work correctly in Internet
Explorer 5, 6 & 7, set tabindex=”-1” on same-page link targets.


2.8 Forms


2.8.1 – Provide labels or titles for all form fields.


What:

HTML forms include “fields” such as text boxes (<input
type=“text”>), check boxes (<input
type=“checkbox”>), radio buttons (<input
type=“radio”>), and drop-down lists (<select>).
Each field is typically identified by a text label positioned above,
before, or below the field. In HTML, labels are identified using the
<label> tag.


Why:

Screen readers cannot always determine which label belongs to
which field based on positioning alone. Proper use of the HTML
<label> element and/or title attribute makes this
association clear.


How:

Use a <label> element whenever possible to
identify each form field’s label. Set the label element’s for attribute
to match the corresponding field’s id. Add a title attribute to any
form field that cannot be associated with a <label>.
Because screen readers typically recognize either the
<label> or the title (not both), the title must provide
the full label, and a <label> should not be associated
with the field.
Note: In most web browsers, label associations can be checked by
clicking the label with the mouse. If the label is properly associated,
focus will move to the corresponding field.


2.8.2 – Provide legends for groups of form fields.


What:

In some cases, several form fields may need to be grouped
together. For example, a set of radio buttons may provide different
answers to a single question.


Why:

Screen readers need to be able to read the group name or
“question” in addition to each field’s individual label.


How:

If possible, group related fields within a
<fieldset> element and provide the group name or
“question” in the fieldset’s <legend>. If a fieldset
cannot be used, apply a title attribute to each field in the group
including the group name and the field’s label. Because screen readers
typically recognize either the <label> or the title (not
both), the <label> elements should not be associated with
their fields when using this technique. Also note that groups of radio
buttons (and sometimes checkboxes) can usually be replaced by a single
drop-down list (<select>) or list box
(<option>) elements.


2.8.3 – Ensure that form fields are in a logical tab order.


What:

Screen reader and keyboard users move between form fields (and
links) using the Tab key. The order in which form fields receive focus
is called the “tab order.” By default, the tab order follows the order
in which elements appear in a page’s HTML code.


Why:

Depending on the design and layout of a page, the tab order
may not match the visual (or logical) order of fields on a form.
Reading fields out of their intended order can be disorienting for a
screen reader or keyboard user.


How:

Make sure that fields appear in logical order in the HTML code
or use the tabindex attribute on each field to set the appropriate
order.
Note: Any element with a positive tabindex will come before all
elements without tabindex in the tab order. As a result, tabindex must
usually be applied to all or none of the focusable elements on a page.


2.8.4 – Avoid placing non-focusable text between form fields.


What:

Special instructions for completing form fields may be listed
after or between the fields to which they apply. Usually, this text is
non-focusable, that is, it does not receive focus when a user tabs
through the form fields.


Why:

When filling out a form, screen readers typically use a
special “forms mode” in which they interact only with focusable
elements, including form fields, associated labels, buttons, and links.
In “forms mode,” screen readers do not read non-focusable text.


How:

Instructions should be given within field labels if possible.
If instructions are too long to fit within labels, they should be
provided in an instructions section before the beginning of the form.
If neither of these approaches works, consider using a technique to
make the text elements focusable, such as by using script to set
tabindex=“0”.
Note that disabled form fields (disabled=“disabled”) are non-focusable;
fields may be made read-only (readonly=“readonly”) to keep them
focusable.


2.8.5 – Ensure that text in form fields can be enlarged.


What:

Most web browsers allow users to easily adjust the size of
text on a page.


Why:

Users with limited vision often rely on the ability to enlarge
text. However, Internet Explorer 5, 6 & 7 do not change the
size of text within form fields to match settings selected from the
View, Text Size menu.


How:

To ensure that text in form fields can be easily resized in
Internet Explorer 5, 6 & 7, include a style rule such as the
following:
input, select, textarea, button { font-size: 100%; }


2.9 Embedded objects


2.9.1 – Use accessible embedded objects whenever possible.


What:

“Objects” include a variety of non-HTML technologies, such as
Java and Flash, that can be embedded within web pages. These
technologies require additional software to be downloaded, installed,
and run before the content can be viewed or used. Embedded objects
operate with their own user interfaces, which are separate and
different from that of standard web pages.


Why:

Because embedded objects have their own interfaces, they must
be accessible in and of themselves. If essential content or
functionality is presented using an object that is not accessible, it
will not be usable by individuals with disabilities.


How:

Follow the accessibility information and Best Practices for
some of the document types at Best
Practices
. If the desired object or document type is not
listed there, check with the manufacturer and/or developer to determine
if and how the technology can be made accessible.


2.9.2 – If an inaccessible embedded object must be used,
provide an accessible alternative that includes the same content and
functionality.


What:

If an embedded object cannot be made accessible, it may be
possible to provide both the original object and an equivalent
accessible alternative.


Why:

The same features that make an embedded object inaccessible to
some users may actually improve accessibility or usability for others.
By providing both the original and accessible versions, the same
content and functionality can be available to all users.


How:

Wherever an inaccessible object is embedded, also provide or
link to an accessible version. Make sure that the information and
functionality is completely equivalent and up-to-date. Be sure to
consider whether the inaccessible version is actually necessary. In
cases where it is impossible to create an equivalent accessible
version, such as with some geographical imaging and mapping systems,
exceptions may be necessary.



3. Layout & Styling


3.1 Layout


3.1.1 Use CSS for layout and positioning and avoid tables.


What:

???


Why:

???


How:

???


3.1.2 – When using style sheets for layout, ensure that
reading order is logical.


What:

The positioning features of Cascading Style Sheets can be used
to position elements visually almost anywhere on a web page.


Why:

Screen readers read through the elements on a web page in the
order in which they appear in the page code, regardless of how they are
positioned using style sheets. It is essential that the reading order
match the logical flow of the document so that a screen reader user
would hear the document in the same order that a visual reader would
read it.


How:

Check the reading order by following the order in which
elements appear in the HTML code. Adjust the reading order by
rearranging the order in which elements are defined in the code.
you can also disable CSS in your browser and make sure that the reading
orders make sense.


3.1.3 Avoid horizontal scrolling.


What:

If a web page is wider than the window or screen in which it
is viewed, most browsers will display a horizontal scroll bar and
require the user to manually scroll to see the entire page.


Why:

When a screen magnifier enlarges a web page, it also reduces
the field of view so that the user must pan (scroll) to see the entire
page. When the web page being viewed also requires horizontal
scrolling, the combination can be awkward or unusable. Keyboard users
may also find repetitive scrolling fatiguing and inefficient.


How:

Design pages so that they can resize to fit the width of the
user’s browser. Use relative widths and check for horizontal scrolling
using a screen resolution of 800 by 600 pixels. If scrolling cannot be
avoided, place the least important content in the rightmost part of the
page.


3.2 Styling


3.2.1 To facilitate liquid design, use proportional font size
and width instead of fixed sizes.


What:

???


Why:

???


How:

???


3.2.2 Avoid inline formatting whenever possible and use
external style sheet instead.


What:

???


Why:

???


How:

???


3.2.3 For decorative images use CSS background images instead
of inline images.


What:

???


Why:

???


How:

???


3.2.4 Use CSS for spacing, instead of spacer.gif.


What:

???


Why:

???


How:

???


3.2.5 Use CSS for borders and separators, instead of inline
images.


What:

???


Why:

???


How:

???


3.2.6 Use CSS to style links, instead of inline images.


What:

???


Why:

???


How:

???


3.3 Frames


3.3.1 – Provide concise, unique, and understandable titles
for frames.


What:

HTML frames and iframes are used to divide web pages into
separate areas, each displaying a separate web page. Each frame is
identified by its title attribute and each page contained within a
frame is identified by its <title> element.


Why:

To navigate pages with frames, users who are blind must be
able to identify the different frames and understand the purpose of
each frame. Most screen readers identify frames by speaking the title
of each frame.


How:

Give each frame and iframe a concise, unique, understandable
title attribute that indicates the frame’s function and is unique
within the frameset. Do not include the word “frame.” Set the
<title> element of each page contained within a frame to
match its title attribute or to identify the current content of that
frame.


3.3.2 – Avoid using hidden, empty, or non-essential frames.


What:

Frames or iframes are sometimes used for formatting, layout,
or other technical purposes. For example, hidden frames may be used to
hold information to be transmitted between pages.


Why:

Screen readers cannot judge whether the content of a frame is
significant and identify every frame for the user. Having to read this
extraneous information can be time consuming and confusing.


How:

Use frames sparingly. If a frame is not necessary for page
content, eliminate it. Minimize the nesting of frames. Recognize that
information in hidden frames may be read by screen readers.



4. Scripting


4.1 compatibility and testing


4.1.1 – Ensure that scripted functions are usable with
assistive technologies.


What:

Scripting languages such as JavaScript are simple programming
languages that can be used within a web browser to automate tasks and
enable pages to respond to user input. Scripts are often used to
dynamically show or hide the content that appears on a web page or to
perform important functions, such as checking that entries in form
fields are valid.


Why:

Assistive technologies may interact with scripts in unexpected
ways. For example, some assistive technologies may not be able to
trigger some script events, and other assistive technologies may not
recognize changes to content made using scripts. However, assistive
technology users need to be able to access the same essential content
and functionality whether scripts are fully, partially, or not
supported. It is not safe to assume that users with disabilities will
have scripting support turned off.


How:

Whenever scripts are used, it is the responsibility of the
page developer to thoroughly test using assistive technologies to
ensure that all information and functionality is accessible. Testing
should confirm that content is usable with system large fonts and high
contrast display settings, that interface elements are focusable and
operable using the keyboard, that tab and reading order are
appropriate, and that all content can be identified and operated with
leading assistive technology tools. If there is any doubt, err on the
safe side by ensuring that the essential elements of the page do not
rely on scripts.
Scripting features that are purely decorative and do not present any
significant information or functionality do not need to be made
accessible.


4.2 Keyboard support


4.1.1 – Ensure that significant interactions can be performed
with both keyboard and mouse.


What:

Scripts can trigger changes when the user performs specific
actions. For example, an image can change color when the mouse pointer
hovers over it (i.e., the onmouseover event). Different events are
triggered by either mouse or keyboard actions.


Why:

Users with physical impairments may be able to use the
keyboard but not the mouse. Individuals who cannot see the mouse
pointer on the screen must use the keyboard for all interactions.
Scripts that can only be triggered by the mouse are not accessible to
these individuals.


How:

Whenever using a mouse-only event (e.g., onmouseover,
onmouseout) to trigger a significant script action, use the
corresponding keyboard event (e.g., onfocus, onblur). Ensure that
scripts are attached to elements that can receive keyboard focus, such
as links and form fields. If necessary, use a technique to make
elements focusable, such as by using script to set tabindex=“0”. Also,
make sure that keyboard events do not unintentionally trigger script
actions. For example, when a keyboard user arrows through the options
in a drop-down list (<select>), the onchange event fires
once for each option; if a script attached to this event reloads the
page (or causes some other significant change), it may be impossible
for a keyboard user to operate the control.


4.2.2 Use CSS to indicate keyboard focus.


What:

??


Why:

??


How:

??


4.3 Dynamic focus and content changes


4.3.1 – Avoid changing focus unexpectedly.


What:

Scripting can be used to move focus from one element to
another, load a new page, or open a new window.


Why:

Users may be disoriented by changes that they do not expect.


How:

In most cases, changes to focus, location, or the current
window should be initiated by a user activating (clicking) a link or
button. If changes are initiated by other actions, make sure that there
is an obvious cause-and-effect relationship between the action and the
change. If changes are not likely to be expected, it may be necessary
to provide explicit instructions to users before the changes occur.


4.3.2 – Avoid changing content unexpectedly.


What:

Scripting can be used to add or change content on a web page.


Why:

Users, especially those using screen readers and screen
magnifiers, may not notice that content has changed on a different part
of the page. If changes occur in parts of the page that have already
been read, the user is not likely to “back up” to find the new content.


How:

In most cases, content should only be changed or added after
the current point of focus in the tab/reading order. For example, if
entering a value in a field causes text to appear, the text should
appear after that field in the tab/reading order. It is also important
to ensure that changes happen quickly enough that they are complete
before the user reaches the changed element. For example, if selecting
an item from a list box changes the value in a subsequent field, the
change must be complete before the focus moves to the subsequent field.
If content is changed above the user’s focus, or if changes occur
slowly enough that a user may move past the changed element before the
change is complete, it may be necessary to provide an alert box or
other instruction to direct the user to the changed element.


4.4 Timing


4.4.1 – Notify users of time limits and provide a means to
extend time if possible.


What:

Some web pages, frequently those that require a user to log
in, time-out after a certain period of inactivity and require the user
to start over.


Why:

Users with visual, physical, or cognitive disabilities may
require more time than average to read and interact with a web page.


How:

Provide a clear explanation of any time limits. If possible,
offer the user a way to extend or remove the limits. Avoid using time
limits unnecessarily.


4.4.2 – Do not automatically refresh the current page.


What:

It is possible to cause web pages to automatically re-load
their content on a certain interval. For example, a page containing
news headlines might refresh every few minutes to present the most
current items.


Why:

When a page automatically refreshes, it can cause a screen
reader to re-start reading from the beginning of the page.


How:

Do not use http-equiv=“refresh”. If necessary, provide a link
or control to allow the user to refresh a page at his or her discretion.



5. Standards


5.1 HTML & CSS validations


5.1.1 Use validators to validate your code.


What:

The World Wide Web Consortium (W3C) sets and publishes
standards for web programming languages including HyperText Markup
Language (HTML/XHTML), and Cascading
Style Sheets (CSS). Programming code is considered “valid” when it
follows the rules and conventions specified in the published standards.


Why:

Valid code is the foundation for accessibility. Screen readers
and other assistive technologies most reliably interpret and interact
with web pages that are built using valid, standard code. A valid HTML
page increases the possibility of having consistent views between
browser’s and the assistive technology’s view.


How:

For web pages, indicate the programming language you are using
by starting your code with a standard document type declaration, such
as:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>


See the full list of W3C Recommended Document Type Declarations
(http://www.w3.org/QA/2002/04/valid-dtd-list.html). Use the W3C HTML
Validation Service
(http://validator.w3.org) to check your code.


5.1.2 Use XHTML instead of HTMl??


What:

??


Why:

??


How:

??



MS Word Best Practices Materials



1.
Backgrounds


1.1 – Patterned backgrounds on pages or
tables. 


What:
Do not use patterned background images and texture fill.
Why:
Background texture fill in may crash a screen reader
because the reader sees the
pattern as a series of repeated images.  The screen reader
will
read each instance of the image in the pattern and thereby prevent or
delay access
to other important page content.
How:
Use a solid color instead, provided you observe contrast
and color guidelines (see below).
Ref:
IBM, Creating Accessible MS Word Documents
IBM, Creating Accessible MS Word Documents” target=”_blank”>http://www-03.ibm.com/able/guidelines/documentation/docmsword.html
See:
Cross-reference listings for this recommendation in this
document.


1.2 – Decorative backgrounds and watermarks may be used,
provided they meet contrast and color considerations (see below).


What:
You can use a background image, color, or gradient, but
exercise caution with color choice and contrast.
Why:
  • Background images (or watermarks) do not appear on the
    filtered output page, but colors, gradients, and texture fills do
    appear on the filtered output page.
  • Background images will not change color if a user goes
    into high contrast viewing mode. If the bg image is white, it will be
    rendered as white on white and will thus be unreadable.
How:
To add a background color or texture to a Word document:
  • On the Format menu, point to Background.
  • Do one of the following:
  • Click the color you want.
  • Click More Colors to see additional color choices.
To add a watermark (or background image) to a Word
document:
  • On the Format menu, point to Background, and then click
    Printed Watermark.
  • Do one of the following:
  • To insert a picture as a watermark, click Picture
    Watermark, and then click Select Picture.
  • To insert a text watermark, click Text Watermark, and
    then select or enter the desired text.
Ref:
Links to additional references.
See:
Cross-reference listings for this recommendation in this
document.


1.3 – Provide sufficient contrast between text and the page
background.


What:
Provide sufficient contrast between text and page
background. For example, black text on a white background or yellow
text on a black background.
Why:
High contrast can increase legibility for users with a
variety of vision impairments.
How:
There is no built in MS Word function for testing high
contrast. Word will use the Operating System’s display settings. You
can turn on High Contrast before starting your application. The
shortcut to switch to OS high contrast is ALT+Left Shift+Print Screen.
To make multiple access/high contrast documents in Word, you can create
a Word template that uses a high contrast foreground/background.
Ref:
MS Word Help site
http://office.microsoft.com/en-us/word/default.aspx
 
See:
Cross-reference listings for this recommendation in this
document.


1.4 -Use color as an enhancement, not as the only way to
convey information.


What:
Use color as an enhancement, not as the only way to convey
information.
Why:
When color is the only way to differentiate information,
some users will not be able to understand the information. For example,
if completed items in a table are green and open items are red, they
will look the same to someone who is color blind and sound the same to
someone using a screen reader.
How:
Provide another way of distinguishing the items. For
example, add an “x” by completed items in green and an exclamation
point by open items in red. If images of checkmarks are used, provide
appropriate alternative text so they can be read by a screen reader. If
a document uses color, you can test the use of color for informational
purposes by printing a copy of the document in black and white to
verify that all information is still conveyed.
Ref:
IBM, Creating Accessible MS Word Documents
IBM, Creating Accessible MS Word Documents” target=”_blank”>http://www-03.ibm.com/able/guidelines/documentation/docmsword.html
See:
Cross-reference listings for this recommendation in this
document.


2. Multi-language
Contents


2.1 – Topic.


What:
Text describing what best practice is recommended..
Why:
Text describing why this best practice is recommended.
How:
Text explaining how this recommendation can be done.
Ref:
Links to additional references.
See:
Cross-reference listings for this recommendation in this
document.


4.
Frames


4.1 – Topic.


What:
Text describing what best practice is recommended..
Why:
Text describing why this best practice is recommended.
How:
Text explaining how this recommendation can be done.
Ref:
Links to additional references.
See:
Cross-reference listings for this recommendation in this
document.


5.
Forms


5.1 – Topic.


What:
Text describing what best practice is recommended..
Why:
Text describing why this best practice is recommended.
How:
Text explaining how this recommendation can be done.
Ref:
Links to additional references.
See:
Text describing what best practice is recommended..


6.
Objects


6.1 – Topic.


What:
Text describing what best practice is recommended..
Why:
Text explaining why this best practice is recommended.
How:
Text explaining how this recommendation can be done.
Ref:
Links to additional references.
See:
Cross-reference listings for this recommendation in this
document.


7.
Text boxes


7.1 – Topic.


What:
Text describing what best practice is recommended..
Why:
Text explaining why this best practice is recommended.
How:
Text explaining how this recommendation can be done.
Ref:
Links to additional references.
See:
Cross-reference listings for this recommendation in this
document.


8.
Diagrams and Organizational Charts


8.1 – Topic.


What:
Text describing what best practice is recommended..
Why:
Text explaining why this best practice is recommended.
How:
Text explaining how this recommendation can be done.
Ref:
Links to additional references.
See:
Cross-reference listings for this recommendation in this
document.


9.
Templates


9.1 – Topic.


What:
Text describing what best practice is recommended..
Why:
Text explaining why this best practice is recommended.
How:
Text explaining how this recommendation can be done.
Ref:
Links to additional references.
See:
Cross-reference listings for this recommendation in this
document.


10.
Images


10.1 – ALT Text with Images

What:
Use ALT text with informational graphics. By contrast, decorative images that contain no meaningful content should not use ALT text.
Why:
Users of assistive devices such as screen readers or refreshable Braille use text equivalents to obtain information about images and other non-text items, such as charts, graphs, [and symbols.]
How:
A text equivalent is a phrase, sentence, or combination of the two that you write and associate with a particular image. The ALT text should describe the image and its purpose. For example, an image of the solar system in a lecture on astonomy might offer ALT text as follows: "Drawing of solar system depicting the orbits and relative distances of the planets from one another." [Add another example, perhaps of a photograph.]


To set ALT text in Word:

Word 2003
  1. Select the picture or shape.
  2. On the Format menu, choose [Format Picture.]
  3. Move to the Web tab.
  4. In the Alternative text box, type the text you want.
Word 2007
  1. Select the picture or shape.
  2. Choose Size.
  3. Move to the Alt Text tab.
  4. In the Alternative text box, type the text you want.
Ref:
Some tips for writing text equivalents are located at http://www.provost.uiuc.edu/cai/training/fivesteps/five-texteq-writing.html
See:
 


10.2 – Charts and Graphs


What:
Provide descriptive ALT text for charts or graphs. When charts or graphs represent data, they should also include the corresponding data tables.
Why:
Charts and graphs are often more complex than other images and thus require more detailed text equivalents to effectively convey the purpose of the chart or graph. For example, a more detailed text equivalent for a bar graph might include a data table of the information in that graph, along with a description of the graph’s purpose. [Do we need to be clearer here about the distinction between data tables that are placed in the actual document text, and descriptive text placed in the ALT text of the graph or chart?]
How:
[In addition to the instructions below for ALT text, we need to add directions for copying the data tables from graphs in Word 2003 and 2007.]

To add ALT text to graphs and charts:

Word 2003
Text Equivalents are inserted in the Web Tab found in the [Format Picture] dialog box:
Select the non-text item
Select [FORMAT PICTURE] from the Format menu or press ALT + O > I Select the Web tab.
Enter the appropriate Text Equivalent in the alternative text area

Word 2007
Text Equivalents are inserted in the Alt Text Tab found in the Size Options window:
Select the non-text item
Open the Size Options window (ALT + 4)
Select the Alt Text tab.
Enter the appropriate Text Equivalent in the alternative text area

To Insert the Data Table for a Graph or Chart

Word 2003 [Add keyboard commands]

In the Edit Table view select the table cells that contain the corresponding chart or graph information.

Copy the data table cells.

Exit editing mode by clicking or selecting an area outside the chart or graph.

Paste the data cells in the document.

Select the pasted data cells and select "Convert" then "Text to Table" from "Table" on the main menu.

Check column and row numbers to make sure they correspond to those in the data table.

Select OK to convert the data to a table.

Move the converted data table to a position below or adjacent to the chart or graph.

Word 2007
[Add Word 2007 instructions here.]

Ref:
text goes here
See:
text goes here


10.3 – Image grouping


What:

When you have one or more images that are representing the same thing (the text equivalents would be the same for all items), then grouping is the best thing to do. Take the example of an organizational chart, for instance. With boxes, lines, and arrows that may be all separate image items (and thus require all separate text equivalents), they are all part of one meaning. So grouping these items together would create one image with one text equivalent.

Why:
By grouping multiple images or objects that make up a larger image or object, you can move or resize them as a single entity rather than manipulating their individual components. This allows placement between objects to be maintained when resized or moved.
How:
text goes here
Ref:
text goes here
See:
text goes here


10.4 – Background images and watermarks


What:
You can use a background image, color, or gradient, but exercise caution with color choice and contrast (see contrast and color considerations below).
Why:
  • Background images (or watermarks) do not appear on the filtered output page, but colors, gradients, and texture fills do appear on the filtered output page.
  • Background images will not change color if a user goes into high contrast viewing mode. If the bg image is white, it will be rendered as white on white and will thus be unreadable.
How:
To add a background color or texture to a Word document:
  • On the Format menu, point to Background.
  • Do one of the following:
  • Click the color you want.
  • Click More Colors to see additional color choices.
To add a watermark (or background image) to a Word document:
  • On the Format menu, point to Background, and then click Printed Watermark.
  • Do one of the following:
  • To insert a picture as a watermark, click Picture Watermark, and then click Select Picture.
  • To insert a text watermark, click Text Watermark, and then select or enter the desired text.
Ref:
Links to additional references.
See:
Cross-reference listings for this recommendation in this document.


10.5 – Patterned backgrounds


What:
Avoid using patterned background images and texture fill on pages, tables [and charts?]. [Does the texture fill screen reader warning apply to charts where texture may be used to supplement color coding—e.g., solid vs. dashed lines, different cross-hatch patterns to distinguish bars on a bar graph, etc.?]
Why:
Background texture fill in may crash a screen reader because the reader sees the pattern as a series of repeated images.  The screen reader will read each instance of the image in the pattern and thereby prevent or delay access to other important page content.
How:
Use a solid color instead, provided you observe contrast and color guidelines (see below).
Ref:
IBM, Creating Accessible MS Word Documents
http://www-03.ibm.com/able/guidelines/documentation/docmsword.html
See:
Cross-reference listings for this recommendation in this document.


10.6 – Contrast considerations


What:
Provide sufficient contrast between text and page background. For example, black text on a white background or yellow text on a black background.
Why:
High contrast can increase legibility for users with a variety of vision impairments.
How:
There is no built in MS Word function for testing high contrast. Word will use the Operating System’s display settings. You can turn on High Contrast before starting your application. The shortcut to switch to OS high contrast is ALT+Left Shift+Print Screen. To make multiple access/high contrast documents in Word, you can create a Word template that uses a high contrast foreground/background.
Ref:
MS Word Help site
http://office.microsoft.com/en-us/word/default.aspx
See:
Cross-reference listings for this recommendation in this document.


10.7 – Color considerations


What:
Use color as an enhancement, not as the only way to convey information.
Why:
When color is the only way to differentiate information, some users will not be able to understand the information. For example, if completed items in a table are green and open items are red, they will look the same to someone who is color blind and sound the same to someone using a screen reader.
How:
Provide another way of distinguishing the items. For example, add an "x" by completed items in green and an exclamation point by open items in red. If images of checkmarks are used, provide appropriate alternative text so they can be read by a screen reader. If a document uses color, you can test the use of color for informational purposes by printing a copy of the document in black and white to verify that all information is still conveyed.
Ref:
IBM, Creating Accessible MS Word Documents
http://www-03.ibm.com/able/guidelines/documentation/docmsword.html
See:
Cross-reference listings for this recommendation in this document.


10.8 – Positioning images


What:
Avoid using tables to position images on the page when it is desireable to convey a visual relationship between images and text (e.g., a set of illustrated step-by-step instructions); instead, use
Why:
Since you can control the location of an image in a document through the format picture dialog box (the layout tab in 2003 and the text layout on the arrange ribbon in 2007), there really is no reason to put an image in a table to position it. [We need one or two specifics here on why images positioned with tables are disruptive to screen readers and other perhaps other assistive technologies.]

How:

Word 2003
1. Select the picture or object.
2. On the Format menu, click Picture, and then click the Layout tab.
3. Click the Advanced button.
4. On the Text Wrapping tab, click the top and bottom wrapping style or another style of your choice.
5. If you want to specify the picture’s distance from text, specify the distance in the Top, Bottom, Left, and Right boxes. Some elements on the tab may be dimmed, depending on the selections you make.
6. Click the Picture Position tab to select the picture’s horizontal and vertical placement, as well as other options. Some elements on the tab may be dimmed, depending on the selections you make.

Word 2007
1. Select the picture or object.

2. On the Format tab, in the Arrange group, click Position. If you don’t see Position, click Arrange, and then click Position.

3. Click the wrapping position you want to apply.

Ref:
MS Office Online: Positioning Pictures in Office 2003
http://office.microsoft.com/en-us/word/HA010547971033.aspx
Wrapping Text in Office 2007
http://office.microsoft.com/en-us/word/HA100997401033.aspx?pid=CH100970231033
See:
Cross-reference listings for this recommendation in this document.

12. Charts

11.1 – Topic.

What:
Text describing what best practice is recommended..
Why:
Text explaining why this best practice is recommended.
How:
Text explaining how this recommendation can be done.
Ref:
Links to additional references.
See:
Cross-reference listings for this recommendation in this document.

13. Misc.

11.1 – Topic.

What:
Text describing what best practice is recommended..
Why:
Text explaining why this best practice is recommended.
How:
Text explaining how this recommendation can be done.
Ref:
Links to additional references.
See:
Cross-reference listings for this recommendation in this document.

PowerPoint Best Practices Materials

PDF Best Practices Materials

Flash Best Practices Materials

Captivate Best Practices Materials