Section 508 of the Rehabilitation Act of 1973, is a U.S. law
requiring electronic technology used by the government to be
accessible. The CSU has passed a mandate that all CSU systems
must also adhere to these standards. Below is a more detailed
listing of these standards, while the menu at left contains
links to solutions on how best to meet them.
The following requirements must be satisfied to comply with
the Web Page Accessibility Policy.
Note
to §1194.22: The Board interprets paragraphs
(a) through (k) of this section as consistent with the
following priority 1 Checkpoints of the Web Content Accessibility
Guidelines 1.0 (WCAG 1.0) (May 5, 1999) published by the
Web Accessibility Initiative of the World Wide Web Consortium:
Checkpoint A, text equivalents
A text equivalent for every non-text element shall be provided (e.g.,
via "alt", "longdesc", or in element content).
Why this is important: Assistive technologies such as screen readers
can't read images; neither can search engines. Some sighted visitors might
have images disabled for various reasons, or images might fail to load
over a network. If alt-text is not given for images used as links, screen
readers will read the whole URL instead, which is horribly confusing for
listeners! The title= attribute (best practice) is used in Firefox for
mouseover (alt= is used in IE); many low-vision users benefit from having
this available.
Checkpoint B, multimedia equivalents
Equivalent alternatives for any multimedia presentation shall be synchronized
with the presentation.
Why this is important: All of the problems addressed in checkpoint A
are compounded by multimedia presentation, where a visual equivalent of
audio content is needed as well as an audio equivalent of visual content.
In addition, most assistive technologies are unlikely to have plugins that
can deal with multimedia formats.
Checkpoint C, color
Web pages shall be designed so that all information conveyed with color
is also available without color, for example from context or markup.
Why this is important: Visitors both with full vision and with various
forms of color blindness require sufficient contrast to read text easily.
If images are used as background, contrast may change when they are unavailable.
Color-blind users may be unable to distinguish information conveyed by
color without alternate coding of that information; blind users obviously
cannot use color information at all.
Checkpoint D, styles
Documents shall be organized so they are readable without requiring an
associated style sheet.
Why this is important: Many low vision visitors will disable the page
author's styles, and may substitute a custom style sheet of their own.
If styles are used to substitute for semantic markup, low-vision and text-only
readers will be unable to understand the structure of the page. (Example:
large bold text used instead of a heading.) Elements that are hidden from
sighted users will also be hidden from low-vision users who may need to
see them; badly hidden element may be inaccessible to all users.
Checkpoint F, client-side image maps
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.
Why this is important: Image maps are designed for fully-sighted readers
who can also use a mouse. Each clickable area must be identified with its
link target, and must be reachable via its tab order, just like all other
links. Frequently, an alternate means of selection may prove easiest to
use for all visitors. (Example: a drop-down list of states in addition
to an image map of the country.)
Checkpoint G, simple
tables
Row and column headers shall be identified for data tables.
Why this is important: Simple data tables are those consisting of only
one column header, and possibly one row header, for each data cell. Unless
the HTML code explicitly associates each data cell with its column (and
row, if applicable) header, visitors using text readers will hear only
a string of unintelligible data values. Technically, this is done with
the <th scope= ...> element. Text-only visitors also might need assistance
in understanding the purpose of the table, which may be provided to them
with the summary attribute of the <table> element. On the other hand,
text-only visitors should never have to hear summaries such as "this
table is for layout only."
Checkpoint H, complex tables
Markup shall be used to associate data cells and header cells for data
tables that have two or more logical levels of row or column headers
Why this is important: Complex data tables are those in which there is
more than one level of header for any column or row. All of the simple
table information also applies to these. For text readers to work properly
on multiple levels of headings, id= attributes must be added to the <th> elements,
and matching headers= attributes to each data cell. Additional markup such
as the <thead> element can be used to further clarify the table structure.
Checkpoint I, frames
Frames shall be titled with text that facilitates frame identification
and navigation.
Why this is important: Untitled frames cannot be navigated by assistive
technology, leaving some visitors unable to reach major portions of the
page content. Some assistive technologies might not support frames at all,
and it is almost impossible to provide truly equivalent content with the <noframes> element.
For these reasons and many others, the use of frames is deprecated by the
W3C in favor of element positioning with style sheets.
Checkpoint J, flicker
Pages shall be designed to avoid causing the screen to flicker with a
frequency greater than 2 Hz and lower than 55 Hz.
Why this is important: At worst, flickering and flashing page elements
can cause epileptic seizures in some viewers. They are also disruptive
to many readers with cognitive disabilities or low vision. At best, they
have become an irritant to nearly everyone.
Checkpoint K, text only
A text-only page, with equivalent information or functionality, shall
be provided to make a web site comply with the provisions of this part,
when compliance cannot be accomplished in any other way. The content of
the text-only page shall be updated whenever the primary page changes.
Why this is important: The limitations of text-only pages were well known
even at that time, though: they include the difficulty and cost of maintenance
and the difficulty of insuring that content is truly equal in different
versions of the page. Modern development standards have rendered the text-only
page obsolete.
Checkpoint L, scripts
When pages utilize scripting languages to display content, or to create
interface elements, the information provided by the script shall be identified
with functional text that can be read by assistive technology.
Why this is important: Many users of assistive technology will not have
scripting available; even users of standard browsers may have scripting
disabled for security or other reasons. Keyboard-only users will not be
able to access functionality that is provided only with mouse-triggered
events. The now obsolete "<noscript>" alternative is almost
never able to provide truly equivalent content and functionality.
Checkpoint M, applets and plug-ins
When a web page requires that an applet, plug-in or other application
be present on the client system to interpret page content, the page must
provide a link to a plug-in or applet that complies with §1194.21 (a)
through (l).
Why this is important: This checkpoint has become substantially more
complicated to evaluate since it was written. There are two problems here.
The first, "applets," can be thought of as true computer applications
running within a browser; for example, Java or ActiveX controls—these
will have to meet the separate Section 508 standards for all computer software.
The second, "plug-ins," could mean anything from Flash to Quick-time
to PDF or even Word. Most browsers now provide built-in rendering for many
of these formats, but many assistive technologies probably won't. Equivalent
content will have to be provided for a large range of disabilities; for
example, closed captioning of video and transcripts of audio—and
formats such as PDF will have to be coded with current accessibility techniques.
Checkpoint N, forms
When electronic forms are designed to be completed on-line, the form
shall allow people using assistive technology to access the information,
field elements, and functionality required for completion and submission
of the form, including all directions and cues.
Why this is important: Visitors using assistive technology need to access
form controls independently of how they are presented on the screen. They
also need to receive all of the cues that normal browsers provide—for
example, which fields are mandatory and what, if any, errors have been
made in completing the form. Proper semantic markup (XHTML) helps assistive
technology to present form information and controls accessibly.
Checkpoint O, skip links
A method shall be provided that permits users to skip repetitive navigation
links.
Why this is important: Pages that contain repetitive links or multiple
groups of repetitive links, which a user might want to "skip" in
whole or only in part, should contain a method for users to jump over such
links to get straight to the content of the page. Though it has been the
practice in the past to provide what is commonly referred to as a “skip
navigation” link, assistive technologies now support navigation by
headings and lists. These constructs can be used instead of, or in addition
to “skip navigation” to organize links beneficially for all
users. New site construction should include headings, and provide an additional
method for skipping navigation if appropriate. Access keys that may override
screen reader settings should be avoided.
Checkpoint P, timed response
When a timed response is required, the user shall be alerted and given
sufficient time to indicate more time is required.
Why this is important: Users may have a variety of difficulties when
a timed response is required from a Web form. In education, one possible
reason requiring such a response would be in an examination, where it would
be impractical to allow all students to request more time, as called for
in the checkpoint. Other accommodations, such as a customized version of
the test or a special testing center, may have to be provided in this case.
For more information contact:
Rosa Padilla – Web Accessibility Coordinator
rosap@csusb.edu (909) 537-5075
Evans Kahuthu - Webmaster
ekahuthu@csusb.edu (909) 537-7629
Michael Casadonte – Web Development
Coordinator
mcasadon@csusb.edu (909) 537-5086
Leon McNaught - ACRC Coordinator
mcnaught@csusb.edu (909) 537-5079
|
