Section 508 guidelines
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?
- (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.
· (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.