All web content providers want to make their sites as user-friendly and accessible as possible, but the terminology and techniques can be daunting. This article aims to clear up one of the most common points of confusion – how to comply with Section 508 using the WCAG 1.0 checkpoints.
What is Section 508?
Section 508 is part of the Rehabilitation Act of 1973. It applies to all federal agencies, and is encouraged or required at the state and local level as well. Section 508 requires that electronic information be equally accessible to federal employees with or without disabilities. This equality is often extended to the public.
The goals of section 508 are clear, but unfortunately the Act does not provide any practical means to evaluate the accessibility of web-based content. Luckily WCAG provides some help.
What is WCAG?
The Web Content Accessibility Guidelines (WCAG) were released by the World Wide Web Consortium to make it easier to judge the accessibility of content. It aims to make online content accessible to a wide range of people with disabilities, including blindness/low vision, hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity, and others.
Two version of the WCAG are currently available. This document applies the better-established 1.0 version to Section 508 compliance.
Using WCAG 1.0 to Meet Section 508 Requirements
You can make sure that your web site is compliant with section 508 by following a subset of the WCAG 1.0 recommendations and checkpoints:
Provide a text equivalent for every non-text element (checkpoint 1.1)
This checkpoint ensures that your content does not rely on purely visual or auditory content to express its meaning. Non-sighted visitors cannot view text presented as an image. Hearing-impaired visitors cannot hear spoken content or feedback sounds. Make sure that all images, videos, and audio content contain “alt” or “longdesc” attributes describing them.
Provide synchronized alternatives for any time-based media (checkpoint 1.4)
Video and audio content are often inaccessible to visually- and auditory-impaired visitors. Providing equivalent textual captions allows screen-readers to render the content in a format that is more accessible.
Note that this requirement is extremely difficult to meet in practice. Consider carefully if audio/video is necessary or appropriate for your site.
Make sure that all meaning conveyed by color is also clear without it (checkpoint 2.1)
Up to 10% of the population have some form of colorblindness, and about 2.6% have some other form of visual impairment. Error messages and other content that are only set apart with color are difficult or impossible for these visitors to find.
Organize documents so they can be read without stylesheets (checkpoint 6.1)
Many screen readers and other accessibility tools cannot process stylesheets. This can be particularly problematic if you rely on CSS positioning to organize content. Make sure that the logical flow of text on the page still makes sense without the CSS-forced placement.
Provide text links for all links within image maps or other media (checkpoint 1.2)
Image maps and links within media (Flash, etc.) can be difficult or impossible for visitors to access. You should provide a separate set of links, or (preferably) avoid the maps/media entirely.
Provide client-side image maps rather than server-side maps (checkpoint 9.1)
Server-side image maps are now rare, but modern AJAX applications suffer many of the same problems. Many screen readers and other access technologies cannot provide the user with a clear view of their navigation options if links/clicks are being processed by the server or a Javascript application. Consider more traditional navigation methods.
Identify row/column headers in tables (checkpoint 5.1, 5.2)
Proper use of table markup (TH, TD) allows screen readers and other access technologies to render tabular data for their users. Avoid the use of style-only (non-semantic) markup within tables.
Make sure that you use tags like TBODY, THEAD, COL, and COLGROUP to associate each set of headers with its matching data set. Consider simplifying your table to be single axis.
Title each frame (checkpoint 12.1)
Frames and iframes are difficult for many users (disabled or otherwise) to navigate. Consider omitting them if possible, and carefully label each frame with its content if they cannot be avoided.
Avoid causing screen flicker (checkpoint 7.1)
Rapid flashes, movement, and color changes can trigger seizures in photo-sensitive users. Do not create content that blinks, vibrates, or flashes.
Make all active content usable without client-side support (checkpoints 6.3, 6.4, 6.5, 8.1)
Client-side dynamic technologies like AJAX and Flash are often inaccessible from alternative user agents like screen readers. Make sure that your dynamic content will still work with javascript and plugins turned off. (This often requires providing a server-side alternative for client-side programs.)
Make all forms usable by alternative user agents (checkpoints 9.4, 9.5, 10.2, 10.4)
Use standards-based markup like LABEL to clarify which form labels are attached to each control. Make sure that the logical flow of the form (including tab order) is clear without visual clues. Be cautious with CAPTCHA technologies.
Allow users to skip repetitive navigation links (checkpoint 13.6)
Screen readers generally start at the top of the page and work down. Having to read the same list of 15 navigation items on each page can render the site unusable. Offer an anchor that jumps over long navigation elements.
Avoid time-sensitive entry or allow for extensions (checkpoints 7.4, 8.1)
Assistive technologies often take longer to work through a page’s content than regular browsers and visitors. Don’t rush users. This includes automatic page refreshes that can force a visitor to start again at the top of a page.
Provide an alternative page if the main page cannot be made accessible (checkpoint 11.4)
Some content cannot be made accessible without substantially damaging the user experience for non-disabled users. (Video, complex in-page applications, etc.) As a last resort, you can provide a separate page with equivalent information and capabilities. You are almost always better off finding a way to make the main page accessible instead.
Summary
Accessibility is good practice whether you are legally required to meet Section 508 or not. Starting with the WCAG 1.0 Priority 1 checkpoints and the other items above is a simple way to make your site as broadly usable as possible.
Resources & References
The latest version of the WCAG document is available at:
http://www.w3.org/TR/WAI-WEBCONTENT/
The federal government has a Section 508 resource site available at:
FRII Creative offers Section 508 compliance consulting and construction:
