Section 508 compliance has received a great deal of attention in Federal webmaster circles in the last year. Slowly, other webmasters have started to hear of it and something called “accessibility.” It appears to be the latest, greatest idea in website design.

Yet, accessibility isn’t all that new. The Web Accessibility Initiative started in 1997 as part of the World Wide Web Consortium (W3C). The Center for Applied Special Technology (CAST) is even older, going back to the pre-Web days of 1984. However, the codification of accessibility guidelines has prompted many webmasters to retrofit their sites, whether or not they are required to do so by 508.

Why build accessible?

Because you have to.

If you work for a Federal agency, then you are covered by section 508 of the Rehabilitation Act of 1973, as amended. “Section 508” (or just “508” if you want to sound very in-the-know) has 16 guidelines that specifically cover website development. Waivers are available, but few agencies outside of the Department of Defense, and not many there, are expected to qualify for a waiver.

Because you want to.

• Accessibility opens a website to a wider user population.
• People with disabilities control $175 million discretionary dollars [1].
• People with disabilities are more likely than others to spend money online. Shopping online is more attractive to customers for whom travel is difficult or inconvenient.
• 54 million Americans have a disability, although not all of the disabilities affect web access [2].
• An accessible website reaches more than the disabled. Some people are bandwidth-challenged and surf with the images turned off in their browser. Others, particularly those in Europe, pay a per-minute charge for Internet access and prefer low-bandwidth surfing. On the bleeding edge of technology, many are surfing with a relatively low-resolution PDA or cell phone, which can more easily interpret an accessible website.

What does accessible mean?

Accessibility means that anyone can access your site. In the brick-and-mortar world, accessibility means having ramps instead of stairs, or in addition to them. And just as in the physical world, other people will use the ramp built for wheelchairs. Parents with strollers and travelers with luggage are more likely to access a ramp than stairs.

It’s not just about visual impairment. Accessibility also means building for people with little or no fine motor skills. Many people have difficulty using a mouse and must rely on keyboard shortcuts. Others may be using voice-input devices.

How to build accessible?

You must first decide on an accessibility strategy. The strategies listed below are not mutually exclusive.

• The Two-Site strategy—build one high-speed, low-drag site with Flash, animation, tons of audio, video, JavaScript pull-down menus, etc., and then build another “text-only” site.
  
  
• The New Build-Only strategy—focusing only on being compliant with Section 508, this strategy ignores old pages and deals only with pages that are built after the compliance deadline. Retrofitting of previously created pages is not accomplished under this strategy. [This strategy is not an option for some Federal webmasters. See more below.]
  
  
• The Removal strategy—If content cannot be made accessible within budget, it is removed from the site.
  
  
• The Head-in-the-Sand strategy—Do nothing and hope you don’t get caught or lose too much business.
  
  
• The Full-Compliance strategy—Retrofit existing pages and build a process by which new content is tested for compliance prior to posting.
  
  
• A Mix—Mixing the above strategies, retrofitting some content, removing other outdated content, and ensuring new content is accessible.
  
  

Which Strategy is Best for You? (Pros and Cons of each strategy)

Two-Site Strategy:

PROs: You can go full-bore, with no consideration for accessibility, on your bells-and-whistles site. Nothing is off-limits. If your site is database-driven, a second text-only site need not be a burden.

CONs: Maintaining two sites, keeping both up-to-date and error-free, is a complicated task for all but the smallest of websites. Even on your B&W site, you will still need to consider usability, so you won’t be free ignore interface considerations. Finally, your text-based-only site will probably be fairly boring and not visually appealing.

New Build-Only Strategy:

PROs: For larger websites, this strategy will be cheaper than retrofitting all your pages immediately.

CONs: Consistency of look-and-feel may suffer while the pages are waiting to turn over. Some pages may never be retrofitted. Department of Defense guidelines do not permit this strategy.

Removal Strategy:

PROs: Removing inaccessible content is very inexpensive, requires no redesign, and is quick.

CONs: You’re missing the point with this strategy. The idea is to make more content available to more people. By removing content, you are making less content available. The organization had reasons for wanting to make the content available in the first place. Chances are those reasons are still valid.

Head-in-the-Sand Strategy:

PROs: Simple and easy, this strategy is often appealing.

CONs: You can be held personally liable for violation of Federal law. Not a recommended course of action.

Full-Compliance Strategy:

PROs: Following both the spirit and the letter of the law, full compliance will expand your audience and improve your organization’s service. You can use this opportunity to complete that long-overdue site redesign.

CONs: This strategy is no simple task. Good accessibility, in addition to following the 508 guidelines, is tough. This strategy typically requires a redesign, and can be expensive and time-consuming.

A Mix:

Obviously, this is last since it is the one that I recommend. Take the pros from each strategy (except for the Head-in-the-Sand) and create a custom strategy that best serves your organizational needs.

For example, you’ll probably want to evaluate some of the content that is more difficult to make accessible. Is the two-year old PowerPoint brief that has been superceded 10 times still a valid piece of content? Is it needed for archival purposes, or has the information become obsolete? Perhaps it can be removed rather than retrofitted. Do you still need the audio “Welcome to our Website” speech from the past director?

As another example, you can still include a Flash introduction (most of these are content-light/free) as long as you provide another way to enter the site.

On to the Implementation

Some content, primarily text, will already be accessible. Other content may be fairly simple to fix. Adding alt and longdesc tags to navigational graphics won’t take long. Javascript pull-down menus and mouseovers will require more work, as will PowerPoint, which still doesn’t have an accessible free viewer.

Once the retrofitting is done, you’ll need to constantly evaluate new content. To best do this, your content providers must be educated. We now have a good, legal reason to discourage content mavens from taking perfectly good text and making it into a graphic. Or for another example, when video taping a presentation, you may also wish to make an audio recording to ease transcription efforts.

As you’ll see below, some guidelines are fairly simple to implement, while others may require a substantial investment.

If you have to follow Section 508, these are them. No choices, except to expand:

If you are choosing accessibility, you’ll need to establish which guidelines your organization will follow. Section 508 is a great place to start. You can also check the W3C Guidelines at http://www.w3.org/TR/WCAG10/. Canada has some Federal guidelines as well at http://www.canada.gc.ca/programs/guide/3_1_4e.html#.

The Guidelines and Technical Solutions

The guidelines are verbatim from the standards. Technical Solutions are one way of allowing access. No one solution will work for every organization. You’ll want to do some additional research on your own, but these will get you started.

Guideline (a): A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).
Technical Solution: <img src=”myfile.jpg” alt=”Person looking at a computer”>
<img src=”chart.jpg” longdesc=”The flow of information starts at the user level. This person should then submit a file.”>

While no set rule exists for when to use “longdesc” instead of “alt,” generally at 50 characters “longdesc” should be used. For very long descriptions, a link to another page may be provided.

The convention has evolved to use the letter “d” near the graphic to be the link text. So,
<a href=”desc.htm”>d</a>
would link to your page that describes the graphic. Users of accessible technology are generally familiar with this convention. If you don’t wish to clutter the pretty, clean lines of your site with a bunch of “d-links,” then employ style sheets to hide them.
In the header:
<style type="text/css">
<!--
.hide {visibility: hidden)
-->
</style>
And then the link would be:
<a href=”desc.htm” class=”hide”>d</a>

Guideline (b): Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
Technical Solution: A text transcript of an audio presentation must be provided. A text description of a video presentation must be provided. If the presentation is fairly long, a transcription agency can perform the transcription.

Guideline (c): Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
Technical Solution: Add asterisks or other marking text to indicate when form fields are required, rather than relying on color (i.e., “Red fields are required” becomes “* marks a required field”). You can still use the red to denote required fields; just be sure that the color is not the sole way of identifying them. Vischeck is a great way to see what your graphics will look like to your colorblind audience.

Guideline (d): Documents shall be organized so they are readable without requiring an associated style sheet.
Technical Solution: Use an external style sheet: <link rel=stylesheet type="text / css" href="style.css> and then test your pages with the style sheets removed.

Guideline (e): Redundant text links shall be provided for each active region of a server-side image map.
Technical Solution: Again, you can use the “hide” class of your external style sheet to keep sighted visitors from seeing the text links. Consider leaving them visible, however, as many sighted visitors prefer using text as well. Better yet, just use a client-side image map, which leads us to:

Guideline (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.
Technical Solution: Use a client-side image map. Any image can be used as an image map. You can use rectangles, “rect,” circles, “circle” and polygons “poly”. Since image maps require knowing where the pixels are that you’re interested in using as a “hot spot” or link area, many graphics programs will build the image map for you. Be sure to provide “alt” tags for the hot spots. <img src="../images/about/org.gif” usemap="#org" alt="Organization structure. Links below.">
<map name=org> <area shape="rect" coords="290,10,525,104" href="front/index.htm" alt="Front Office Staff"> <area shape="rect" coords="552,142,804,234" href="fac/index.htm" alt="Facilities"> <area shape="rect" coords="276,140,532,235" href="Plans/index.htm" alt="Plans"> </map>

Guideline (g): Row and column headers shall be identified for data tables.

Guideline (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.
Technical Solution: The “scope” attribute of the <td> and <th> tags is the best solution for these two related guidelines. Use “col” for column headings and “row” for row headings.

<table> <tr> <th scope= ”col”>January</th> <th scope= “col”>February</th> <th scope= “col”>March</th> </tr> <tr> <td scope=”row”>Meetings</td> <td>Wednesdays</td> <td>Thursdays</td> <td>Mondays</td> </tr> <tr> <td scope=”row”>Workshops</td> <td>Tuesdays</td> <td>Fridays</td> <td>Sundays</td> </tr> </table>

Guideline (i): Frames shall be titled with text that facilitates frame identification and navigation.
Technical Solution: Give each of your frames meaningful titles, such as “Main Content,” “Banner,” or “Navigational Links”. <frameset cols="25%, 75%"> <frame src="nav.htm" name="navlinks" title="Navigational Links Frame"> <frame src="home.htm" name="content" title="Main Content Frame"> </frame>
Additionally, you can put a header in each frame to tell your visitor what is in the frame.

Guideline (j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
Technical Solution: Evaluate any animated graphics by opening the file in a good graphics editing tool. The change rate will be available. Be sure to evaluate your applets and other plug-ins for flicker. This guideline is a good example of where the Removal Strategy may prove useful.

Guideline (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.
Technical Solution: A hidden “d” link as outlined under Guideline (a) can be used for purely visual content. Other content should have a link to the text content clearly available.
<a href=”text.htm”>Text Only</a>

Guideline (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.
Technical Solution: When using JavaScript URLs to launch functions, you can use an image for your link and then provide an “alt” tag.
<a href="javascript:fooBar();"><img src="foobar.gif" alt="Link for launching FooBar."></a>
JavaScript changes to the status line are difficult to detect, so if information is provided that way, be sure to have it elsewhere on the page. Event handlers (e.g., onMouseOver) need to be device-independent or content-free (e.g., highlighting a link).

Guideline (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).
Technical Solution: Link to a compliant viewer. Unfortunately, MicroSoft does not offer a free PowerPoint viewer that is compliant with the software portion of Section 508. Get Adobe Reader for PDFs

Guideline (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.
Technical Solution: You have two choices. First, don’t put your form in a table.