3. Section 508 Guidelines

Main Points

• Section 508 Guidelines The Section 508 Guidelines with examples.
• Section 508 Commentary Discussion of Section 508.
• ^{Skip to Main Points} links return to the Main Points menu.

Section 508 Guidelines

The Section 508 website is unforgivably difficult to navigate, and when you finally locate the really meaningful pages, some explanations are quite good while others leave you stuck with a lot of questions. This is my limited attempt to collect in one webpage, everything you need to do for Section 508 compliance.

1. A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content).

   This reiterates what we've already discussed, that non-text content should reiterate text which appears on your webpage. Best practices dictate that this information should be first and foremost written into the webpage content. However, each non-text XHTML tag typically has method for specifying it's content or purpose within the markup itself, e.g. the alt attribute for the <img> tag, the summary attribute of the <table> tag, etc. Look up the available attributes of any tag that inserts non-text content and use the available accessibility features.

2. Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

   This can be very difficult to accomplish, as the Section 508 guidelines make it clear they expect you to include either open or closed captioning for all multimedia. Closed captioning requires technology that supports it, and I know of no web technology that does, so we're really talking about open captioning (captions that are visible to everyone whether they want them or not). So if you have audio in Flash animations or video with sound, that's multimedia and you're supposed to caption the audio portion of the presentation in sync with the video. Is this hard? Well, the Section 508 website can't even provide a web accessible example. (Which is amusing when you think about it.) Their "solution" involves something called a .ram file which would not play in any browser or program available on any of my computers... so much for accessibility. According to the W3C, you can use SMIL to meet this criteria, but I've never used this language and can't speak to either it's effectiveness or browser support.

   So let's talk about what you can do. Hopefully, you have a "good" video editing program that will let you include text in the video. That's all you need to add open captions, however time consuming. Insert text and synchronize it to your content. If you can't add open captions in your video editor, then realistically your website will violate this guideline until you upgrade to a better editor.

   Remember that you also need to provide a text-based version (ie a transcript) to comply with guideline a. For speed, I recommend completing the transcript first, then you can copy and post sections from the transcript into your video editor and synchronize the text with the video. That's the best way to kill two birds - this guideline and the transcript - with the same stone.

3. Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

   A fairly straightforward guideline, if someone viewed your webpage in a text browser without the ability to see the colors you've specified would they still understand your page. Color is an important communication tool, but it should support, not replace text.

4. Documents shall be organized so they are readable without requiring an associated style sheet.

   This is a more generalized version of guideline (c). Your webpage should make sense in a text browser or with a different stylesheet. The color as well as any other styling should support the text of the document, not replace it. If it doesn't, when you restyle your website, you'll have to rewrite content and that is an insidious kind of error which you're likely to miss. It also means that you need to apply your CSS intelligently; i.e. use an external stylesheet. (.css file) This is good advice all the way around as external stylesheets are the key to accessibility, flexibility, modular websites, and creating a design that is easily maintainable. It's a critical part of accessibility because some users will have custom style sheets defined, large fonts are quite common, for example. If you define any CSS in the webpage, it can override your visitor's settings which destroys their ability to use your webpage.

5. Redundant text links shall be provided for each active region of a server-side image map.

   A server-side image map simply returns the coordinates of the mouse click to the server; the server then determines what link the user has clicked. This means the user cannot tell where the links go in a server-side image map, because they aren't present as text on the page. Therefore, if you unwisely use this technique (it has many other downsides as well), you need to provide duplicate links in the text of the webpage.

6. 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.

   This guideline is being kind. In many cases, an image map is neither warranted nor wise. Using a client-side image map is generally hard to write, and hard to maintain and update. Usually a CSS styled list is best practices for presenting links in this way, consider a client-side image map as a fall back position. Using a server-side image map is close to ridiculous.

   If you are going to use an image, make sure it's done as a client-side map so users can access the links. Make sure to mark everything up as correctly as possible. Provide a summary using the alt attribute of the image. Also include the usemap attribute and specify the map to use. Then add the related map element immediately after the image. Nest each area element which defines a hotspot inside the map element. But it's much better to use text in the first place, and style it along with associated images in the external stylesheet.

7. Row and column headers shall be identified for data tables.
8. 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.

   These two guidelines speak to accessible table design, which in the first place means using tables according to web standards; tables are for marking up tabular data, e.g. spreadsheets. Here's how to write an accessible table.

   Accessible Table

   Technology	Resource Folder	Resource Type
   CSS	ECBeta / CSS	Stylesheet
   ASP.NET	ECBeta / Master	Master Pages

   <table summary="Demo of an accessible table.">
   

   <caption>
   

   Accessible Table
   

   </caption>
   

   <tr>
   

   <th scope="col">
   

   Technology
   

   </th>
   

   <th scope="col">
   

   Resource Folder
   

   </th>
   

   <th scope="col">
   

   Resource Type
   

   </th>
   

   </tr>
   

   <tr>
   

   <th scope="row">
   

   CSS
   

   </th>
   

   <td>
   

   ECBeta / CSS
   

   </td>
   

   <td>
   

   Stylesheet
   

   </td>
   

   </tr>
   

   <tr>
   

   <th scope="row">
   

   ASP.NET
   

   </th>
   

   <td>
   

   ECBeta / Master
   

   </td>
   

   <td>
   

   Master Pages
   

   </td>
   

   </tr>
   

   </table>
   

   A table should have a summary attribute which provides a quick description of the entire table, much like the alt attribute of the <img> tag. Like the <legend> tag nested inside a <fieldset>, the <caption> tag should be nested inside the <table> tag. This is the table title. Most importantly however are the scope attributes of the <th> tags. Each cell in the first table row should be a <th>, table heading which describes the information of the column and includes the scope="col" attribute. Similarly, the first cell of each subsequent row should be a <th>, table heading which describes the information of the row and includes the scope="row" attribute. This allows screen readers, braille displays, and other accessibility devices to correctly understand the table structure.

9. Frames shall be titled with text that facilitates frame identification and navigation.

   I admit I find this guideline a little strange; like closing the barn door after the cow is gone. If you're using frames you can't even see an accessible design from where you are, much less build one. Frames are a user interface nightmare. The first thing you need to do is meet the needs of the 90+% of non-disabled users and drop the frames. Then you can start worrying about improving your accessibility for the blind, deaf, etc. Until then you have bigger fish to fry. Virtually every server-side technology has a way to duplicate frame functionality by placing each frame's content into a separate file. It then builds the page when it's requested. .NET user controls and master pages are the best technique, but even a simple server side include is infinitely preferable to using frames.

10. Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

    The concern here is that violating this guideline could trigger seizures in some people with epilepsy. The flip side is that while you can indentify the <img> and <applet> tags that include content which "might" cause potential problems, I know of no final test to determine flicker rate for these technologies. It's also problematic that Every Flash animation / movie on the internet animates in this range, but does animation frame rate equate to "screen flicker rate"? I've been unable to track down answers to these questions, making this guideline an unsolvable riddle.

11. 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.

    The final sentence really gets to the heart of why this is not the best idea, you now have two places to update information which is bad practice. Keep the text on the same page. The only realistic time when you should create a separate page for text information is when you do something silly and the page can't be downloaded or functionally accessed. In that case you'll need to provide a page that is downloadable, and you'll be saddled with some arduous website maintenance.

12. 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.

    Like guideline (d) on stylesheets, this is really about implementing your Javascript correctly. The Section 508 website gives a lot of information on scripts, but all those problems vanish if you follow best practices and apply your scripts from an external .js file. Code separation provides the best accessibility, maintainability, and modularity in programming design; it's true for CSS, it's true for Javascript.

13. 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)

    This is not just about accessibility for the disabled, it's just polite for all visitors. If you require a plug-in, provide a link to the page where your visitors can download it. Make it as easy as possible for them to meet the criteria you've set for accessing your website content.

14. 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.

    This is about accessible form design. While there are a lot of ins and outs to creating an attractive form, making sure it's accessible is an easy two-step process.

    1. Each form element needs to have an id attribute. While there are times when ids are not necessary for an XHTML element, forms are not one of them. Every form element which requires user input needs an id.
    2. Every form element needs a <label> tag which specifies the input you want the user to enter. The label is what tells the user what you want them to do. The label tag takes the for attribute; the for attribute should be set to the value of the id of the form element you are labeling. This is what ties the two elements together and allows braille displays and software to associate the form element with the label that describes it.
15. A method shall be provided that permits users to skip repetitive navigation links.

    This means that each "separate" group of navigation links on your page should begin with a skip link that neatly avoids the navigation entirely. In practice, this is not as big a problem if your content comes first on the page. On Earth Chronicle, we have several different navigation components but they are all grouped at the end of the page. We can use one skip link to avoid them all, however, if you have navigation components in different spots on the page use a separate skip link for each.

16. When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

    Like screen flicker, this is only a problem for Javascript programmers and Flash designers, the only exception being the highly problematic meta refresh tag which you shouldn't be using anyway. It's involved in some black hat SEO, and Google may ban you. If you're doing a game, that's a different issue as you are not levraging content. However, if you are providing content what is the point of denying it to people after a limited amount of time. Especially since this guideline requires you to provide the functionality to allow the user to self-select additional time. Talk about pointless, just don't do it.

Section 508 Commentary

There are some notable trouble spots in testing for Section 508 compliance. The captioning requirement in section b is a royal pain in the ass. It's difficult to implement, and the 90% of users who don't want captions are screwed. The screen flicker requirement for section j is a huge mystery. I've found little discussion and no procedure for designing or testing your page for compliance. However, by and large it is not what Section 508 requires but what it leaves out that is surprising.

Every accessibility and SEO guru I've ever read or talked to has stressed the importance of using descriptive link text. People should know exactly where a link will take them, what format the page/document/etc. is in, and generally enough information so that a visitor can decide whether they want to click the link or not. Also, descriptive headings come up just as high as links on every list I've ever seen. Use your <h1> tag to display the title of the page and use subheadings to clearly group your text on the page. Finally both these XHTML elements take the title attribute which is an excellent tool. The title attribute can include synonyms for your keywords especially if they're terms you don't like (e.g. masterpage instead of master page), or at the very least you can reiterate your descriptive text. Don't forget these critical XHTML guidelines; your accessibility and your SEO will suffer if you don't.

1. Use descriptive link text. Clearly explain where it goes with accurate keywords.
2. Descriptive heading text. Lay out your headings logically to describe the webpage's structure.
3. Use the title attribute to restate information, or better, include any important synonyms or alternate keywords you could not find room for in the document text.

• Beta Home
• Beta Reader's Guide
• Beta Projects
• Beta FAQ