Section
508 Guidelines
- (a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).
If we
properly separate our three layers, we remove most of the situations in which
we would have to provide text equivalents. Markup should only include img
tags when the image is actually part of the content of the page (i.e. Flickr or Boston.com's The Big Picture).
The
lesson: Logos, navigation, buttons and
other content elements are not proper uses of img tags. When non-text
content is necessary, use title and alt attributes.
- (b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
That fancy
Java slideshow applet that adds ripple effects to the slides probably isn't
necessary. Simplify your life and make basic HTML pages styled with CSS
instead.
The
lesson: If you do need multimedia
capabilities, use technologies that have accessibility options.
- (c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
Users with
colorblindness or screen readers can't tell a red icon from a green icon. If
all you have in your HTML is an img tag, you are hiding content from
people that are unable to see the page. Be sure to have meaningful text content
in your HTML whenever you are conveying information with color.
The
lesson: Color is presentation, not content.
Convey all information as text in HTML and use styles heets to make it pretty
and colorful.
- (d) Documents shall be organized so they are readable without requiring an associated style sheet.
Remember
our three layers of separation?
The
lesson: If you have created a page that
needs CSS or JavaScript to be readable, you have violated our "HTML is
content" principle. Semantic markup without styles creates HTML that is
meaningful even if it is boring to look at.
- (e) Redundant text links shall be provided for each active region of a server-side image map.
Don't use
image maps as they are almost always unnecessary. As simple as that.
The
lesson: Provide basic text interactions
with plain old HTML. If rich interactions are necessary, enable them by using
progressive enhancement techniques.
- (f) 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.
The
lesson: Plan/ discuss it before
implementing.
(g)
Row and column headers shall be identified for data tables.
Since we only use tables for the markup of tabular
data and not for layout, this requirement can be satisfied by adding th,
and optionally thead tags, to the table. Complicated tables
can be simplified by being split into multiple tables, or by using multiple
levels of headings and using the scope attribute on th
tags.
The lesson: All tables should use th
instead of td to markup row and column headers.
·
(h) 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.
As mentioned above, the tables elements have
various attributes that allow complex associations between headers and content.
The lesson: Check out the id,
headers, axis, and scope
tags. Read up on techniques
for table accessibility from WCAG.
·
(i) Frames shall be titled with text
that facilitates frame identification and navigation.
Frames are generally a bad idea, but when you
absolutely must use a frame, be sure to add appropriate title
attributes to the frame element. This element allows a user
using a screen reader to know what is content contained in the frame.
The lesson: Do not use frames. If
you must, add a title attribute to all frames.
·
(j) Pages shall be designed to avoid
causing the screen to flicker with a frequency greater than 2 Hz and lower than
55 Hz.
As the site is going to be for people with
disabilities should take care.
The lesson: You might be in trouble
if you want anything on your page to blink or flicker.
·
(k) 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.
If constructed properly, your site will have no
need for text-only pages. When a text-only page is absolutely necessary, use
your CMS to display the same content on both the text-only and the rich pages.
When the content is updated, it will be applied to both pages.
The lesson: Dynamically generated
pages can ensure that the text-only pages are updated when the rest of the site
content is. Build your site well and you won't have to worry about this.
·
(l) 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.
As we learned in part one of this article,
scripting languages (behavior) should never be used in place of content or
interface (markup). Properly written, the behavior should complement and extend
a functional markup-only application. This development strategy is called progressive
enhancement.
The lesson: Do not rely on
JavaScript to render markup or content. It is a violation of the separation of
content and behavior.
·
(m) 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).
While rich content is nice, it should only come
after developing a site with comprehensive access to content through
traditional means. A zooming map with color overlays can enhance a users's
experience, but the underlying data or analysis should also be available
through accessible text-based pages. When rich content is necessary, provide
links to plug-ins that have accessibility features built-in and make sure that
the content rendered by those plugins takes advantage of the accessibility
features.
The lesson: Only use plug-ins that
have accessibility features.
·
(n) 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.
Accessible and attractive forms can be quite
intimidating at first. Fortunately HTML provides you with all the tools
necessary to create forms that are easily read with assistive technologies: fieldset, legend, label, and others. Each
form element should have a label associated with it. The for attribute
of the label contains the id of the form field to which it is related.
The label element also provides a convenient styling hook that removes the need
to use a table for layout. Each label/element combination can be written as an
item (li) within a list.
JavaScript is often used for client-side form
validation, but it should only be used as a convenience to the user. The server
should always validate forms as well. When there are errors in server-side
validation, they should be displayed grouped together at the top of the form.
This allows the user to know what the problems were without having to go
through each form element. Complex forms should show the errors on individual
fieldsets or at the field level.
A List Apart
has a fantastic
article about how to create accessible, good looking forms.
The lesson: HTML provides all the
tools necessary to create accessible forms. Keep them simple and use CSS to do
the layout.
·
(o) A method shall be provided that
permits users to skip repetitive navigation links.
This is usually accomplished by adding an anchor to
the top of the page content that takes the user to an element right past the
navigation elements. The link is typically styled using CSS as to make it
invisible to users that are not using assistive technologies. Once HTML 5 is
widely support, the new nav
element will allow users to skip past navigation without having to add a link
specifically for that purpose.
The lesson: A simple anchor will
get the job done.
·
(p) When a timed response is required,
the user shall be alerted and given sufficient time to indicate more time is
required.
On the off chance your application requires timed
responses (timed sessions?), provide users with a warning that their time is
about to expire. Give them the opportunity to extend their time. Mint and many banks do a beautiful job of this by
letting you know when your session is about to expire and giving you the
opportunity to save it.
The lesson: Never make assumptions
about how long it will take your users to complete actions. Be polite and give
them the option to extend their time if it is about to expire.
No comments:
Post a Comment