Understanding and Applying Section 508 Standards

OSU requires web developers to meet or exceed the OSU Web Accessibility Policies and Standards, which are based on Section 508 of the Rehabilitation Act of 1973. Section 508 requires that certain guidelines or priorities are met to insure those with visual, auditory, physical, mental, or learning disabilities are able to access electronic information.

Note: Many of the requirements defined by Section 508 are covered by Priority One and, to a lesser extent, Priority Two issues established by the World Wide Web Consortium’s Web Accessibility Initiative (WAI). While the WAC primarily uses the OSU Web Accessibility Policies and Standards as the guideline for identifying and evaluating an accessible site, in most cases, web designers meeting the WAI’s Priority One guidelines also will have met the minimum OSU standards.

Section 508, Subpart 1194.22: Web-based intranet and internet information and applications.

Contents:

• (a) Alternate Descriptions for Non-Text Elements
• (b) Synchronization with Multimedia
• (c) Use Color for Design, not Context
• (d) Using Style Sheets
• (e) Server-Side Image Maps
• (f) Client-side Image Maps
• (g & h) Data Table Headers
• (i) Using Frames
• (j) Flashing or Flickering Elements
• (k) Updating Text-Only Versions
• (l) Using Scripts to Create Dynamic Pages
• (m) Using Applets and Plug-Ins
• (n) Using Online Forms
• (o) Skip Navigation Link
• (p) Using Time Out Scripts

Alternate Descriptions for Non-Text Elements:

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

Non-text elements include: images, graphical representations of text (including symbols), image map regions, animations, applets, and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds, stand alone audio files, audio tracks of view, and video.

Sample Code:

Image without alternate description:


< img src="../images/wacapp.gif" width="61" height="34">

Image with alternate description:


< img src="../images/wacapp.gif" alt="WAC Approved icon" width="61" height="34">

Put your mouse over each image to see the difference. Alternate descriptions are read by screen-readers and appear when an image is unavailable from the server or when the user chooses to "turn-off" or "hide" images in his/her browser.

return to top.

Synchronization with Multimedia:

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

Captioning for the audio portion and audio description of visual information of multimedia presentations are considered equivalent alternatives. This provision requires that when an audio portion of a multimedia production is captioned, as required in provision (a), the captioning must be synchronized with the audio. Synchronized captioning would be required so someone reading the captions could also watch the speaker and associate relevant body language with the speech.

return to top.

Use Color for Design, not Context:

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

Good web design may use color and other visual markers to help users navigate the site. For example, visited links may be a different color, font, or size to help users remember where they have been in the site.

However, color and other visual elements should not be used as the only guide. A web site that asks students to use the RED links and faculty to use the BLUE links would be a poor example of color use. To fix the problem, the designer might put all the RED links in the left column and the BLUE links in the right column of a layout table and indicate the difference between the columns in the column headers and table summary. Here is a sample table:

And here is the code that created this table:

<table width="60%" border="2" summary="This table contains navigation links for faculty and students. The faculty links are in the left column and the student links are in the right column.">
<tr>
<th class="xtextred" scope="col">Links for Faculty</th>
<th class="xtxtblue" scope="col">Links for Students</th>
</tr>
<tr>
<td class="xtextred">Grade Reports</td>
<td class="xtxtblue">Course Descriptions</td>
</tr>
<tr>
<td class="xtextred">Internal Procedures</td>
<td class="xtxtblue">Faculty Contact Information</td>
</tr>
<tr>
<td class="xtextred">Scheduling</td>
<td class="xtxtblue">Events and Workshops</td>
</tr>
</table>

Note: there is still a problem with this table. A screen-reader will read tables from left to right then down. So, this table, read by JAWS, sounds like this:

"Links for faculty, links for students, grade reports, course descriptions, internal procedures, faculty contact information, scheduling, events and workshops."

In this arrangement, the information for faculty and students is read alternately, rather than in a group. A better way to organize this table would be:

The code for this version of the table is:

<table width="60%" border="2" summary="This table contains navigation links for faculty and students. The faculty links are in the left column and the student links are in the right column.">
<tr>
<th class="xtextred" scope="col">Links for Faculty</th>
<th class="xtxtblue" scope="col">Links for Students</th>
</tr>
<tr>
<td class="xtextred"><ul>
<li>Grade Reports</li>
<li>Internal Procedures</li>
<li>Scheduling</li>
</ul></td>
<td class="xtxtblue"><ul>
<li>Course Descriptions</li>
<li>Faculty Contact Information</li>
<li>Events and Workshops</li>
</ul></td>
</tr>
</table>

In this version, JAWS would read all the faculty-related links before reading the student links. In addition, the links have been put into an unordered (bulleted) list, and JAWS would announce how many items are in each list before reading each item. This makes it even easier to follow the table information.

For more on organizing data tables, see the Data Table Headers section of this guide.

Tip for testing -- There are two simple ways of testing a web page to determine if this requirement is being met: by either viewing the page on a black and white monitor, or by printing it out on a black and white printer. Both methods will quickly show if the removal of color affects the usability of the page.

return to top.

Using Style Sheets:

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

Style sheets can enable users to define specific viewing preferences to accommodate their disability. For instance, users with low vision may create their own style sheet so that, regardless of what web pages they visit, all text is displayed in an extra large font with white characters on a
black background. If designers set up their pages to override user-defined style sheets, people with disabilities may not be able to use those pages. For good access, therefore, it is critical that designers ensure that their web pages do not interfere with user-defined style sheets.

Style sheets can also help designers insure a consistent look across the site by establishing site-wide fonts, colors, and positioning.

In general, the "safest" and most useful form of style sheets are "external" style sheets, in which the style rules are set up in a separate file. An example of an external style sheet is:

<link rel=stylesheet type="text / css" href="/wac/styles/Styles.css">

There are many online tutorials to help you learn to build and manage your own style sheet. We recommend Mulder's Stylesheet's Tutorial from WebMonkey.

return to top.

Server-Side Image Maps:

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

An "image map" is a picture (often an actual map) on a web page that provides different "links" to other web pages, depending on where a user clicks on the image. There are two basic types of image maps: "client-side image maps" and "server-side image maps." With client-side image
maps, each "active region" in a picture can be assigned its own "link" (called a URL or "Uniform Resource Locator") that specifies what web page to retrieve when a portion of the picture is selected. HTML allows each active region to have its own alternative text, just like a picture can
have alternative text.

By contrast, clicking on a location of a server-side image map only specifies the coordinates within the image when the mouse was depressed. The ultimate selection of the link or URL must be deciphered by the computer serving the web page.

Most novice designers and webmasters of non-dynamic sites use only client-side image maps. Creation and use of server-side image maps requires advanced programming experience.

return to top.

Client-side Image Maps:

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

Because of the potential accessibility problems with server-side image maps (see Server-Side Image Maps above), client-side image maps should be used in a majority of cases.

Here is an example of a client-side image map:

Here is the code that inserts the image and creates the image map:

<img src="../images/disabilitystudiestopbar3.jpg" alt="Disability Studies at OSU" name="disabilitystudies" width="400" height="55" border="0" usemap="#Map" id="disabilitystudies">
<map name="Map">
<area shape="rect" coords="4,5,59,45" href="http://www.osu.edu" alt="OSU Home Page">
<area shape="rect" coords="77,3,396,50" href="http://ada.osu.edu/disabilitystudies" alt="Return to Disability Studies Home Page">
</map>

return to top.

Data Table Headers:

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

Large tables of data can be difficult to interpret if a person is using a non-visual means of accessing the web. Users of screen readers can easily get "lost" inside a table because it may be impossible to associate a particular cell that a screen reader is reading with the corresponding column headings and row names.

For instance, assume that a salary table includes the salaries for federal employees by grade and step. Each row in the table may represent a grade scale and each column may represent a step. Thus, finding the salary corresponding to a grade 9, step 5 may involve finding the cell in the ninth row and the fifth column. For a salary chart of 15 grade scales and 10 steps, the table will have at least 150 cells. Without a method to associate the headings with each cell, it is easy to imagine the difficulty a user of assistive technology may encounter with the table.

Here is a table with both row and column headers:

Here is the code used to define this table, including headers:

<table width="90%" border="2" id="datatable" summary="This table contains information on student programs. Each row lists the student name, academic level completed to date, and current program enrolled.">
<tr>
<th scope="col"><p>Student</p></th>
<th scope="col"><p>Academic Level</p></th>
<th scope="col"><p>Current Program</p></th>
</tr>
<tr class="smallertxt">
<th scope="row"><p>Lori Badia</p></th>
<td><p>M.A. completed</p></td>
<td><p>Ph.D. English</p></td>
</tr>
<tr class="smallertxt">
<th scope="row"><p>Susan Bailey</p></th>
<td><p>B.S. completed</p></td>
<td><p>M.B.A.</p></td>
</tr>
<tr class="smallertxt">
<th scope="row"><p>Alicia Baker</p></th>
<td><p>B.A., in progress</p></td>
<td><p>Dept. of Education</p></td>
</tr>
</table>

As a screen-reader, like JAWS, reads this table, each data cell can be identified by either row or column header. For instance, when reading across row two, JAWS reads the row header:

"Student Lori Bailey, academic level, M.A. completed; current program, Ph.D. English."

When reading down, JAWS reads the row header for each cell. For instance, when reading column three:

"Lori Bailey, Ph.D. English; Susan Bailey, M.B.A., Alicia Baker, Dept. of English."

Row and column headers help insure that data tables can be understood.

return to top.

Using Frames:

(i) Frames shall be titled with text that facilitates frame identification and navigation.

Frames provide a means of visually dividing the computer screen into distinct areas that can be separately rewritten. Unfortunately, frames can also present difficulties for users with disabilities when those frames are not easily identifiable to assistive technology. For instance, a popular use of frames is to create "navigational bars" in a fixed position on the screen and have the content of the web site retrievable by activating one of those navigational buttons. The new content is displayed another area of the screen. Because the navigational bar doesn't change, it provides a stable "frame-of-reference" for users and makes navigation much easier. However, users with disabilities may become lost if the differences between the two frames are not clearly established.

The above image shows a web site that used to be based on frames The top navigation area, including the program logo and navigation bar remain static while the information changes below. (Note: this site was later updated to remove frames. Visit the new, improved site at: http://english.ohio-state.edu/programs/dmp).

While Section 508 guidelines require that frames be titled and labeled to identify the changing areas of information, the WAC recommends that web developers avoid using frames in most cases. Instead, templates can be developed to manage repeating information (such as background color, logos, and navigation menus) across the site.

Before deciding to use frames in your site, we recommend you read more about the problems with frames:

Jacob Nielsen: "Why Frames Suck (most of the time)."

ALT.HTML: "Why are Frames so Evil?"

Web Design Group: "Guide to Frame Usage."

If you do decide to use frames, be sure to read the Access Board's guidelines for creating accessible frames.

return to top.

Flashing or Flickering Elements:

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

Causing a page or elements on a page to flash or flicker can have serious effects on users with epilepsy and light sensitivity. Flashing and moving graphics can also be extremely distracting and just plain annoying to other users.

Here is an example of a page with too many flickering elements: North Royalton Police Department (archive) . [Note: this page is an archive from February 2003. Visit the updated and much improved site and note the difference: North Royalton Police Department (current)].

Flashing or flickering elements are usually added through technologies such as animated gif's, Java applets, or third-party plug-ins or applications. Java applets and third party plug-ins can be identified by the presence of <APPLET> or <OBJECT> tags. Animated gif's are images that download in a single file (like ordinary image files), but have content that changes over short periods of time. Like other images, however, they are usually incorporated through the use of the <IMG> tag.

return to top.

Updating Text-Only Versions:

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

Text-only pages mimic the content of the original pages but are structured so that they resolve most major accessibility issues. Thus, web sites that use inaccessible elements, such as flash navigation and complex pages, often offer a text-only version of the site with simpler presentation. If you choose to offer a text-only version of your site, you must have a system in place that insures the text-only version is as up-to-date as the primary version. Emerging technology, such as LIFT's Text Transcoder, helps designers insure that text-only sites remain current.

return to top.

Using Scripts:

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

Javascript is one of the most popular scripting languages for web development. In addition to libraries of javascript code available online, two of the most popular web development tools, FrontPage and Dreamweaver, include easy-to-access code snippets that add little "extras" to web pages. Developers should use caution when deciding to include Javascript or other scripting elements on their pages. Here are a few of the most popular uses for Javascript and some of the accessibility issues to consider:

• onClick – The onClick event handler is triggered when the user clicks once on a particular item. It is commonly used on links and button elements and, used in connection with these elements, it works well with screen readers. If clicking on the element associated with the onClick event handler triggers a function or performs some other action, developers should ensure that the context makes that fact clear to all users. Do not use the onClick event handlers for form elements that include several options (e.g. select lists, radio buttons, checkboxes) unless absolutely necessary.
• onMouseOver and onMouseOut – These two event handlers are very popular on many web sites. For instance, so-called rollover gif's, which swap images on a web page when the mouse passes over an image, typically use both of these event handlers. These event handlers neither can be accessed by the mouse nor interfere with accessibility – a screen reader simply bypasses them entirely. Accordingly, web designers who use these event handlers should be careful to duplicate the information (if any) provided by these event handlers through other means.
• onChange – This event handler is very commonly used for triggering JavaScript functions based on a selection from within a <select> tag. Surprisingly, it presents tremendous accessibility problems for many commonly used screen readers and should be avoided. Instead, web developers should use the onClick event handler (associated with a link or button that is adjacent to a <select> tag) to accomplish the same functions.

For more information on accessibility issues when using Javascript, see:

• University of Wisconsin-Madison, Trace Center's Javascript Accessibility Issues.
• Web Accessibility In Mind (WEBAIM), "Creating Accessible Javascript."
• World Wide Web Consortium (W3C), "Script Techniques for Web Content Accessibility Guidelines 2.0"

return to top.

Using Applets and Plug-Ins:

(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 most web browsers can easily read HTML and display it to the user, several private companies have developed proprietary file formats for transmitting and displaying special content, such as multimedia or very precisely defined documents. Because these file formats are proprietary, web browsers cannot ordinarily display them. To make it possible for these files to be viewed by web browsers, add-on programs or "plug-ins" can be downloaded and installed on the user's computer that will make it possible for their web browsers to display or play the content of the files. This provision requires that web pages that provide content such as Real Audio or PDF (Adobe Acrobat's Portable Document Format) files also provide a link to a plug-in that will meet the software provisions. It is very common for a web page to provide links to needed plug-ins. For example, web pages containing Real Audio almost always have a link to a source for the necessary player. This provision places a responsibility on the web page author to know that a compliant application exists, before requiring a plug-in.

Here is an example from the WAC's links page:

Training Video on PDF Accessibility from AccessIT (requires Windows Media Player): “PDF Accessibility” a presentation by Terry Thompson, Technology Specialist with AccessIT, offers detailed help with evaluating PDF files for accessibility and creating accessible PDF using MS Word and Adobe Acrobat plug-ins.

WAC provides a link to the streaming video file, and a link to the Windows Media Player download page, to allow users who don't have the WMP plug-in installed to access video. WAC also provides a link to the home page of AccessIT, in case the video file moves or is offered in other formats on the host site.

return to top.

Using Online Forms:

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

Simple steps to good form design include:

• Associate a label with each form input element.
  For example, a text box --
  Enter Your Name:
  Code: <label for="name">Enter Your Name:</label>
<input type="text" name="username" id="name">
The "for" attribute identifies which element the label describes. A corresponding "id" attribute should be in the element tag and the label should appear as close to the form element as possible.
• Order the form using the "tabindex" attribute. The tabindex determines the order that fields will be activated when using the TAB button to move through the form. For each element in the form, include a tabindex.
  Example:
  Email Address:
  Name:
  Code:
  <label for="label">Email Address:</label>
<input type="text" name="textfield2" tabindex="2" id="label">
<br>
<label for="label2">Name:</label>
<input type="text" name="textfield3" tabindex="1" id="label2">
  Notice that even though the email address input appears above the name input, we can reorder the form by using the tabindex. Thus, users who scroll through the form using their TAB button will first arrive at the Name box then the Email Address box. However, in most cases, users will expect that the form order will be top-down, and you should set your tabindex in that order.
  Be sure to add a tabindex to all form elements, including the SUBMIT and CLEAR buttons.
• Setup alternate keystroke commands for form processing.
  Using the "accesskey" attribute allows you to set keystroke commands for most elements on a web page, including links and form elements. Keyboard commands help insure that users do not have trouble finding an alternate to the mouse "click" to select an option or submit a form.
  Example: Submit
  Code: <label for="Submit">Submit</label>
<input type="submit" name="Submit" value="Send this form" accesskey="s" tabindex="3" id="Submit">

return to top.

Skip Navigation Link:

(o) A method shall be provided that permits users to skip repetitive navigation links.

Consider this page from OSU's Department of Microbiology:

Before a screen-reader begins reading the main content, beginning with "What's New" title and "We welcome new faculty . . .", it must read all the "header" information, including 14 separate links. If a nondisabled user returns to the web page and knows that he or she wants to view the contents of that particular page instead of selecting a navigation link to go to another page, he or she may simply look past the links and begin reading wherever the desired text is located. For those who use screen readers or other types of assistive technologies, however, it can be a tedious and time-consuming chore to wait for the assistive technology to work through and announce each of the standard navigational links before getting to the intended location.

To avoid this problem, developers can include a simple "skip navigation" link somewhere near the top of the page (preferably before any other content). This in-page link then directs the screen-reader to the first word of "content" on the page.

Here is an example from the OSU ADA Coordinator's Office web site:

Because the "skip navigation" link is designed to be used primarily by screen-readers, it does not need to be located in a prominent or even visible part of the page. The barely visible link at the top of the ADA Coordinator's Office pages directs screen-readers to the first word of the main body of text in the center of the page.

Here is how the link appears in HTML code:

• Skip navigation link: <a href="#content">skip navigation</a>
• Anchor is placed before the start of the main body of text: <a name="content"></a>Welcome to the ADA Coordinator's Office . . .

return to top.

Using Time Out Scripts:

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

Web pages can be designed with scripts so that the web page disappears or "expires" if a response is not received within a specified amount of time. Sometimes, this technique is used for security reasons or to reduce the demands on the computer serving the web pages. Someone's disability can have a direct impact on the speed with which he or she can read, move around, or fill in a web form. For instance, someone with extremely low vision may be a slower-than-average reader. A page may "time out" before he is able to finish reading it. Many forms, when they "time out" automatically, also delete whatever data has been entered. The result is that someone with a disability who is slow to enter data cannot complete the form. For this reason, when a timed response is required, the user shall be alerted via a prompt and given sufficient time to indicate whether additional time is needed.

return to top.

Information presented here adapted from the Section 508 web site: http://www.section508.gov and the Access Board's Guide to the Section 508 Standards for Electronic and Information Technology.