This is part two of a two-part post. Part one covers the basics of web standards and progressive enhancement and Section 508 standards §1194.22 (a)-(f). Part two covers Section 508 standards §1194.22 (g)-(p).
Good news! Despite the excessive amount of time it took me to finish this post, Section 508 compliance is STILL easier than you think. Compliance does not preclude you from having an amazing web site. By following modern web standards, it is possible to create a site that is inherently accessible. Let’s continue where we left off with (g)!
Section 508 Guidelines
(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.
Why on earth would you want to make the screen flicker?
The lesson: You should be fired 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.
(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.
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.
One of the frequent complaints about Section 508 compliance is that it is nearly impossible to implement a good web site and still follow the guidelines. Trust me, a good web site can be implemented without using applets, image maps and frames. Your web site’s success will not come from a Java applet showing animated amber waves of grain. Using semantic markup and separating the markup, presentation, and behavior will get you most of the way to having a compliant web site. Yes, complex web applications are much more difficult to make compliant, but there is no reason to blame the average, substandard government web site on Section 508.