|
Information Menu
Information Menu
|
THE ACCESSIBILITY OF UAA'S WEB PRESENCE
Accessibility—in the context of content
presentation on the Web—refers to the
ability of an individual to utilize online
content even when functioning under limited
conditions (e.g., use of a screen reader to
aid an individual with limited or no sight).
The aim of making a Web site accessible is
to enable more users to access the Web site
effectively in more situations.
The University of Alaska has undertaken a systematic
approach to revamping its Web presence to
ensure that it complies with and exceeds the
parameters set forth in recent federal
accessibility legislation.
This overview seeks to provide a summary of
the pertinent legislation, what that means
in terms of Web site components that need
revision, and how an Institute Web
author/developer might go about making his
or her site(s) compliant.
Pertinent Legislation
The Americans with Disabilities Act (ADA) of
1990 requires state and local governments to
provide auxiliary aids and services where
necessary to ensure effective communication
with individuals with disabilities, unless
doing so would result in a fundamental
alteration to the program or service or in
an undue burden. Section 508 of the
Rehabilitation Act Amendments (RAA) of 1998
complements the ADA by specifically
requiring public agencies to make online
content accessible to users with special
needs.
The Architectural and Transportation
Barriers Compliance Board (Access Board) has
issued final accessibility standards for
electronic and information technology
covered by section 508 of the RAA. Section
508 requires the Access Board to publish
standards setting forth a definition of
electronic and information technology and
the technical and functional performance
criteria necessary for such technology to
comply with section 508. The final document
draws heavily from, but does not directly
mirror, the Web Content Accessibility
Guidelines 1.0 (WCAG), published by the
World Wide Web Consortium (W3C).
Enforcement and Effective Date
The enforcement provisions of section 508
took effect on June 21, 2001.
By statute, the enforcement provisions of
section 508 apply only to electronic and
information technology procured on or after
the effective date. As a result, section 508
does not authorize complaints or lawsuits to
retrofit technology procured before this
date to meet the Board's standards. However,
even though section 508's enforcement
mechanisms apply only to procurement, the
law does require access to technology
developed, used, or maintained by a
government agency.
An agency does not have to comply with the
technology accessibility standards if it
would impose an “undue burden” to do so.
This is consistent with language used in the
ADA and other civil rights legislation,
where the term "undue burden" has been
defined as "significant difficulty or
expense." However, the agency must explain
why meeting the standards would pose an
undue burden for a given procurement action,
and must still provide people with
disabilities access to the information or
data that is affected.
Compliance Criteria
A Web site required to be accessible by
section 508 would be in complete compliance
if it met paragraphs (a) through (p) of
these standards. It could also comply if it
fully met the WCAG 1.0 (as detailed in
http://www.w3.org/TR/WCAG10/ ), priority one
checkpoints and paragraphs (l), (m), (n),
(o), and (p) of these standards. A federal
Web site that was in compliance with these
standards and that wished to meet all of the
WCAG 1.0 priority one checkpoints would also
have to address issues regarding using the
clearest and simplest language appropriate
for a site's content, alerting a user when
there is a change in the natural language of
the page, audio descriptions, and the
provision that Web pages reliably update
both dynamic and equivalent sites
simultaneously, should they be maintained
separately.
Accessibility Parameters
a) Paragraph (a) requires that a text
equivalent for every non-text element shall
be provided. As the Internet has developed,
the use of photographs, images, and other
multimedia has increased greatly. Most Web
pages are created using HTML, or "HyperText
Markup Language." A "page" in HTML is
actually a computer file that includes the
actual text of the Web page and a series of
"tags" that control layout, display images
(which are actually separate computer
files), and essentially provide all content
other than text. The tags are merely signals
to the browser that tell it how to display
information, and many tags allow Web
designers to include a textual description
of the non-textual content arranged by the
tag. The provision is necessary because
assistive technology cannot describe
pictures, but can convey the text
information to the user.
Currently, most Web page authoring programs
already provide a method for Web designers
to associate words with an image, and
associating text with non-textual content is
easy for anyone familiar with HTML. This
provision requires that when an image
indicates a navigational action such as
"move to the next screen" or "go back to the
top of the page," the image must be
accompanied by actual text that states the
purpose of the image, or what the image is
telling you to do. This provision also
requires that when an image is used to
represent page content, the image must have
a text description accompanying it that
explains the meaning of the image.
Associating text with these images makes it
possible for someone who cannot see the
screen to understand the content and
navigate a Web page.
The types of non-text elements requiring
identification are limited to those images
that provide information required for
comprehension of content or to facilitate
navigation. Web page authors often utilize
transparent graphics for spacing. Adding
text to identify these elements would
produce unnecessary clutter for users of
screen readers.
The Board also interprets this provision to
require that when audio presentations are
available on a Web page (because audio is a
non-textual element), text in the form of
captioning must accompany the audio to allow
people who are deaf or hard of hearing to
comprehend the content.
b) Paragraph (b) provides that equivalent
alternatives for any multimedia presentation
shall be synchronized with the presentation.
This would require, for example, that if an
audio portion of a multimedia production was
captioned as required in paragraph (a), the
captioning must be synchronized with the
audio. There are new techniques for
providing realtime captioning that are
supported by new versions of programs such
as RealAudio. Providing captioning does not
preclude posting a transcript of the speech
for people to search or download.
c) Paragraph (c) prohibits the use of color
as the single method for indicating
important information on a Web page. When
colors are used as the sole method for
identifying screen elements or controls,
persons who are color blind as well as those
people who are blind or have low vision may
find the Web page unusable. This provision
does not prohibit the use of color to
enhance identification of important
features. It does, however, require that
some other method of identification, such as
text labels, must be combined with the use
of color. For example, a Web page that
directs a user to "press the green button to
start" should also identify the green button
in some other fashion than simply by color.
d) Paragraph (d) provides that documents
must be organized so they are readable
without requiring browser support for style
sheets. Style sheets are a relatively new
technology that lets Web site designers make
visually consistent Web pages that can be
easily updated. For instance, without style
sheets, making headings appear in large font
while not affecting the surrounding text
requires separate tags hidden in the
document to control font size and boldface.
Each heading would require a separate set of
tags.
Using style sheets, however, the Web site
designer can specify in a single tag that
all headings in the document should be in
large font and boldface. Because style
sheets can be used to easily affect the
entire appearance of a page, they are often
used to enhance accessibility, and this
provision does not prohibit the use of style
sheets. This provision requires that Web
pages using style sheets be able to be read
accurately by browsers that do not support
style sheets and by browsers that have
disabled the support for style sheets. This
requirement is based on the fact that style
sheets are a relatively new technology, and
many users with disabilities may either not
have computer software that can properly
render style sheets or because they may have
set their own style sheet for all Web pages
that they view.
e) Paragraph (e) requires Web page designers
to include redundant text links for each
active region of a server-side image map on
their Web pages. An "image map" is a picture
on a Web page that provides different
"links" to other Web pages, depending on
where a user clicks on the image. There are
two basic types of image maps: "client-side
image maps" and "server-side image maps."
With client-side image maps, each "active
region" in a picture can be assigned its own
"link" that specifies what Web page to
retrieve when a portion of the picture is
selected. HTML allows each active region to
have its own alternative text, just like a
picture can have alternative text.
By contrast, clicking on a location of a
server-side image map only specifies the
coordinates within the image when the mouse
was depressed - which link or URL is
ultimately selected must be deciphered by
the computer serving the Web page. When a
Web page uses a server-side image map to
present the user with a selection of
options, browsers cannot indicate to the
user the URL that will be followed when a
region of the map is activated. Therefore,
the redundant text link is necessary to
provide access to the page for anyone not
able to see or accurately click on the map.
f) Paragraph (f) provides that client-side
image maps shall be provided instead of
server-side image maps except where the
regions cannot be defined with an available
geometric shape. As discussed above, there
are two general categories of image maps:
client-side image maps and server-side image
maps. When a Web browser retrieves a
specific set of instructions from a
client-side image map, it also receives all
the information about what action will
happen when a region of the map is pressed.
For this reason, client-side image maps,
even though graphical in nature, can display
the links related to the map in a text
format that can be read with the use of
assistive technology.
g) and h) Paragraphs (g) and (h) permit the
use of tables, but require that the tables
be coded according to the rules for
developing tables of the markup language
used. When tables are coded inaccurately or
table codes are used for non-tabular
material, some assistive technology cannot
accurately read the content. Many assistive
technology applications can interpret the
HTML codes for tables and will most likely
be updated to read the table coding of new
markup languages.
The Board understands that there are
currently few alternatives to the use of
tables when trying to place items in
predefined positions on Web pages. These
provisions do not prohibit the use of table
codes to format non-tabular content. They
require that when a table is created,
appropriate coding should be used.
i) Paragraph (i) addresses the use of frames
and requires that they be titled with text
to identify the frame and assist in
navigating the frames. "Frames" are a
technique used by Web designers to create
different "portions" or "frames" of their
screen that serve different functions. When
a Web site uses frames, often only a single
frame will update with information while the
other frames remain intact. Frames can be an
asset to users of screen readers and other
assistive technology if the labels on the
frames are explicit. Labels such as top,
bottom, or left provide few clues as to what
is contained in the frame. However, labels
such as "navigation bar" or "main content"
are more meaningful and facilitate frame
identification and navigation.
j) Paragraph (j) sets limits on the blink or
flicker rate of screen elements. The W3C’s
Web Content Accessibility Guidelines 1.0
provide that "[u]ntil user agents allow
users to control flickering, avoid causing
the screen to flicker." Several technologies
can cause a flashing effect, but it is the
recommendation of the Board to minimize or
avoid technology that will cause that to
happen.
k) Paragraph (k) requires that a text-only
Web page shall only be provided as a last
resort method for bringing a Web site into
compliance with the other accessibility
requirements. Text-only pages must contain
information or functionality that is
equivalent to the primary pages. Also, the
text-only page shall be updated whenever the
primary page changes.
l) Paragraph (l) requires that when Web
pages rely on special programming
instructions called "scripts" to affect
information displayed or to process user
input, functional text shall be provided. It
also requires that the text be readable by
assistive technology such as screen reading
software. Scripts are widely used by Web
sites as an efficient method to create
faster or more secure Web communications. A
script is a programmatic set of instructions
that is downloaded with a Web page and
permits the user's computer to share the
processing of information with the Web
server. Without scripts, a user performs
some action while viewing a Web page such as
selecting a link or submitting a form, a
message is sent back to the "Web server,"
and a new Web page is sent back to the
user's computer. The more frequently an
individual computer has to send and receive
information from a Web server, the greater
chance there is for errors in the data, loss
of speed, and possible violations of
security.
Also, when many users are simultaneously
viewing the same Web page, the demands on
the Web server may be huge. Scripts allow
more work to be performed on the
individual's computer instead of on the Web
server, and the individual computer does not
have to contact the Web server as often.
Scripts can perform very complex tasks such
as those necessary to complete, verify, and
submit a form and verify credit information.
The advantage for the user is that many
actions take place almost instantly, because
processing takes place on the user's
computer and because communication with the
Web server is often not necessary. This
improves the apparent speed of a Web page
and makes it appear more dynamic.
JavaScript—a standardized object-oriented
programming language—is a good example of a
scripting language, and certain plug-ins
support slightly different scripting
languages. This provision requires Web page
authors to ensure that all the information
placed on a screen by a script shall be
available in a text form to accommodate
assistive technology.
Web page authors have a responsibility to
provide script information in a fashion that
can be read by assistive technology. When
authors do not put functional text with a
script, a screen reader will often read the
content of the script itself in a
meaningless jumble of numbers and letters.
Although this jumble is text, it cannot be
interpreted or used. For this reason, the
provision requires that functional text—text
that when read conveys an accurate message
as to what is being displayed by the
script—be provided. For instance, if a Web
page uses a script only to fill the contents
of an HTML form with basic default values,
the Web page will likely comply with this
requirement, as the text inserted into the
form by the script may be readable by a
screen reader.
By contrast, if a Web page uses a script to
create a graphic map of menu choices when
the user moves the pointer over an icon, the
Web site designer may be required to
incorporate "redundant text links" that
match the menu choices because functional
text for each menu choice cannot be rendered
to the assistive technology. Determining
whether a Web page meets this requirement
may require careful testing by Web site
designers, particularly as both assistive
technology and the JavaScript standard
continue to evolve.
m) While most Web browsers can easily read
HTML and display it to the user, several
private companies have developed proprietary
file formats for transmitting and displaying
special content, such as multimedia or very
precisely defined documents. Because these
file formats are proprietary, they cannot
ordinarily be displayed by Web browsers. To
make it possible for these files to be
viewed by Web browsers, add-on programs or
"plug-ins" can be downloaded and installed
on the user's computer that will make it
possible for their Web browsers to display
or play the content of the files.
Paragraph (m) requires that Web pages that
provide content such as Real Audio or PDF
files also provide a link to a plug-in that
will meet the software provisions. It is
very common for a Web page to provide links
to needed plug-ins. For example, Web pages
containing Real Audio almost always have a
link to a source for the necessary player.
This provision places a responsibility on
the Web page author to know that a compliant
application exists before requiring a
plug-in.
n) Paragraph (n) requires that people with
disabilities have access to interactive
electronic forms. Electronic forms are a
popular method used by many agencies to
gather information or permit a person to
apply for services, benefits, or employment.
The 1998 Government Paperwork Elimination
Act requires that federal agencies make
electronic versions of their forms available
online when practicable and allows
individuals and businesses to use electronic
signatures to file these forms
electronically. At present, the interaction
between form controls and screen readers can
be unpredictable, depending upon the design
of the page containing these controls. Some
developers place control labels and controls
in different table cells; others place
control labels in various locations in
various distances from the controls
themselves, making the response from a
screen reader less than accurate many times.
This provision does not forbid the use of
scripts or plug-ins, and many of the
existing products support these features. If
a browser does not support these features,
however, paragraphs (l) and (m) require that
some other method of working with the Web
page must be provided.
o) Paragraph (o) provides that a method be
used to facilitate the easy tracking of page
content that provides users of assistive
technology the option to skip repetitive
navigation links.
p) Paragraph (p) addresses the accessibility
problems that can occur if a Web page
times-out while a user is completing a form.
Web pages can be designed with scripts so
that the Web page disappears or "expires" if
a response is not received within a
specified amount of time. Sometimes, this
technique is used for security reasons or to
reduce the demands on the computer serving
the Web pages. A disability can have a
direct impact on the speed with which a
person can read, move around, or fill in a
Web form. For this reason, when a timed
response is required, the user shall be
alerted and given sufficient time to
indicate that additional time is necessary.
The final rule requires only that a user be
notified if a process is about to time-out
and be given an opportunity to answer a
prompt asking whether additional time is
needed.
Summary of Requirements
All Web sites maintained by public
institutions must adhere to the following
parameters, in accordance with Section 508:
1. provide a text equivalent for every
meaningful non-text element
2. synchronize equivalent alternatives for
multimedia presentations
3. do not use color as the single method for
indicating important information
4. organize content so that it is readable
without requiring browser support for style
sheets
5. include redundant text links for each
active region of a server-side image map
6. use client-side image maps except when
hotlinks can’t be defined by geometric
shapes
7. make sure tables are correctly coded
according to standards
8. title all frames with text to identify
each frame and assist in navigating the
frames
9. limit or eliminate the blink or flicker
rate of screen elements
10. avoid use of text-only sites; if
unavoidable, it must receive equally
frequent updates
11. provide functional text when using
scripts to display information—make it all
readable
12. provide links to appropriate, compliant
plug-ins for “non-standard” media
13. interactive electronic forms must be
usable by individuals with special needs
14. users must be able to skip repetitive
navigation links
15. notify user if a process is about to
time-out; give user opportunity to answer a
prompt
Validation
The WCAG 1.0 provides several
recommendations for validation that will
help to ensure that Web communications meet
the aforementioned accessibility guidelines.
The W3C recommends the use of automatic
tools for accessibility validation, coupled
with subsequent human review. “Automated
methods are generally rapid and convenient,
but cannot identify all accessibility
issues. Human review can help ensure clarity
of language and ease of navigation.”
The following are some validation methods
that should be employed to make pages
accessible to all audiences:
1) Use an automated accessibility tool and
browser validation tool. Please note that
software tools do not address all
accessibility issues, such as the
meaningfulness of link text, the
applicability of a text equivalent, etc.
- e.g. CAST’s Bobby online accessibility
analysis tool — www.cast.org/bobby
- e.g. Bobby application — bobby.cast.org/html/en/pricing.jsp
2) Validate syntax (e.g., HTML, XML, etc.).
- e.g. W3C HTML Validation Service —
validator.w3.org
3) Validate style sheets (e.g., CSS).
- e.g. W3C CSS Validation Service —
jigsaw.w3.org/css-validator
4) Use a text-only browser or emulator.
- e.g. Opera — www.opera.com
- e.g. Lynx — lynx.browser.org
5) Use multiple graphic browsers with:
• sounds and graphics loaded,
• graphics not loaded,
• sounds not loaded,
• no mouse,
• frames, scripts, style sheets, and applets
not loaded
- e.g. Opera (see above) does an excellent
job of facilitating this
6) Use several browsers, old and new.
While support of non-standards-compliant
browsers is not essential, it is important
to know precisely how pages will display in
the older generation of browser. Pages do
not have to parse perfectly, but do need to
have readable, navigable content. A more
exhaustive discussion of standards
compliance and browser upgrades can be found
at the Web Standards Project's Browser
Upgrade Campaign site.
7) Use a self-voicing browser, a screen
reader, magnification software, a small
display, etc.
- e.g. JAWS for Windows
http://www.freedomscientific.com/fs_products/software_jaws.asp
- e.g. IBM Home Page Reader
http://www-3.ibm.com/able/hpr.html
8) Use spell and grammar checkers. A person
reading a page with a speech synthesizer may
not be able to decipher the synthesizer's
best guess for a word with a spelling error.
Eliminating grammar problems increases
comprehension.
9) Review the document for clarity and
simplicity. Readability statistics, such as
those generated by some word processors, may
be useful indicators of clarity and
simplicity. Better still, ask an experienced
(human) editor to review written content for
clarity. Editors can also improve the
usability of documents by identifying
potentially sensitive cultural issues that
might arise due to language or icon usage.
10) Invite people with disabilities to
review documents. Expert and novice users
with disabilities will provide valuable
feedback about accessibility or usability
problems and their severity.
Should a Web site pass all of the checks
that accompany the aforementioned
practices—especially Priority 1 and 2
validation from CAST’s Bobby system, and W3C
HTML (and CSS, if applicable) Validation—one
should assume that the site complies with
Section 508 of the RAA.
References
Special note should be made that a
significant portion of the contents
presented in this document were direct
excerpts from the following resource:
“Section 1194.22 Web-based Intranet and
Internet Information and Applications”
Electronic and Information Technology
Accessibility Standards
Architectural and Transportation Barriers
Compliance Board
[Published in the Federal Register on
December 21, 2000]
36 CFR Part 1194
[Docket No. 2000-01]
RIN 3014-AA25
http://www.access-board.gov/sec508/508standards.htm
Additional information about this resource
and the specifics contained therein may be
obtained by contacting Doug Wakefield,
Office of Technical and Information
Services, Architectural and Transportation
Barriers Compliance Board, 1331 F Street,
NW., suite 1000, Washington, DC 20004-1111.
Phone: (202) 272-5434 extension 139 (voice);
(202) 272-5449 (TTY). E-mail: wakefield@access-board.gov.
Additional
accessibility information can be found by
visiting the web development site:
www.bluediamondwebs.com |
|
|
Anchorage, Alaska
99508-4614