Audio captioning

When multimedia presentations (such as video with audio) are available on a web page, the audio portion must be captioned and the captions must be synchronized with the presentation.

Audio Information

Core Techniques (W3C Source)

Auditory presentations must be accompanied by text transcripts of auditory events. When these transcripts are presented synchronously with a video presentation they are called "captions" and are used by people who cannot hear the audio track of the video material.

Some media formats (e.g., QuickTime and SMIL) allow captions and video descriptions (audio description of visual content) to be added to a multimedia clip. Microsoft's SAMI allows captions to be added. The following example demonstrates that captions should include speech as well as any other sounds in the environment that help viewers understand what is going on.

Example: Captions for a scene from "E.T." The phone rings three times, then is answered.
[phone rings]
[ring]
[ring]
"Hello?"
End example.

Until the format you are using supports alternative tracks, two versions of a movie could be made available, one with captions and video descriptions, and one without. Some technologies, such as SMIL and SAMI, allow audio/visual files to be combined with separate text files via a synchronization file to create captioned audio and movies.

Some technologies also allow users to choose from multiple sets of captions to match their reading skills. For more information see the SMIL specification.

Equivalents for sounds can be provided in the form of a text phrase on the page that links to a text transcript or description of the sound file. The link to the transcript should appear in a highly visible location such as at the top of the page. However, if a script is automatically loading a sound, it should also be able to automatically load a visual indication that the sound is currently being played and provide a description or transcript of the sound.

Note: Some controversy surrounds this last technique because ideally the browser should simply load the visual form of the information instead of the auditory form if the user preferences are set to do so. However, strategies must also work with today's browsers.

For more information, please refer to NCAM.

Text Equivalents for Multimedia

HTML Techniques (W3C source)

If necessary, a text equivalent should be provided for visual information necessary for an understanding of a webpage. For example, consider a repeating animation that shows cloud cover and precipitation as part of a weather status report. Since the animation is supplementing the rest of the weather report (which is presented in text), a less verbose description of the animation is necessary. However, if the animation appears in a pedagogical setting where students are learning about cloud formations in relation to land mass, then the animation ought to be described for those who cannot view the animation but want to learn the lesson.

Note: Following is a related concern, not included on the section 508 guidelines:

WAI Guideline 1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. [Priority 1]

For core techniques, see Visual information and motion .

Creating ALT text

A text equivalent for every non-text element (audio tracks, images, etc.) should be provided.

• Every image, Java applet, Flash file, video file, audio file, plug-in, etc. should have an alt description.
• Complex graphics (graphs, charts, etc.) should be accompanied by detailed text descriptions.
• Alt descriptions for images used as links should note the link destination.
• Decorative graphics with no other function should have empty alt descriptions (alt= ""), but should not be missing alt descriptions.

When creating "alternative text" aim for a functional label based on the context in which the component being described (most often an image) is used rather than a visual description. Imagine reading the document aloud over the telephone. What would you say upon encountering this image to make the page comprehensible to the listener?

Most authoring tools provide a space for you to enter this information, or you can add alternative text with the "alt" attribute of the IMG element. For example, use a tag like the following:

<img src="jjoyce.jpg" alt="James Joyce as a young man">

To do this in HTML (and in the code view of Dreamweaver), set your cursor down after the source name of your image (for example "joyce1.gif”), type alt=””. Within the quotation marks, type the text as you would like it to be spoken by the user's screenreader application.

When using Dreamweaver, you can also designate alternative text in the Image Properties Panel (usually at the bottom of the screen)—simply type the text into the alt field. See below:

Dreamweaver also features accessibility dialog boxes. Just click Edit>Preferences>Accessibility and check the "Images" checkbox. Then, whenever you insert an image, the following dialog box will pop up:

You can add your alternative text here instead of in the properties panel. Additionally, you can choose to use the "longdesc," or long description, attribute (see the second text box in the dialog box above). Because screenreaders typically read only 150 characters or less of alternate text (the example above is 26 characters, including spaces), you may need to describe an image in more detail in another file (e.g., jjoyce.html):

<HTML>
<HEAD>
<TITLE>James Joyce as a Young Man (Long Description)</TITLE>
</HEAD>
<BODY>
A black and white photo of a young James Joyce standing outside, and in front of, an open windowpane.
He wears a vest over his shirt and tie as well as a crumpled sport-jacket. His hands are in the pockets of his 
wool trousers and his head, which tilts to his right, is topped with a sailor's cap. His face is expressionless.
</BODY>
</HTML>

The tag in the calling document (the one with the IMG element) would now look like the following:

<IMG src="jjoyce.jpg" alt="James Joyce as 
a young man" width="234" height="373" longdesc="jjoyce.html">

Presumably, a user can now click on the image and go to the "jjoyce.html" file. Unfortunately, most browsers (including Internet Explorer) do not support this attribute. So it is better to make a caption for each of your images and use this caption as a link to the long description file (when necessary).

Even sighted users may benefit from having access to a long description. It is debatable as to whether this particular long description is necessary, accurate, or at all interesting. However, if you use an image of a chart in your document, a long description may be the best way for you to insure equitable access to information for visually impaired users.

To specify an "alt" attribute with Microsoft FrontPage, right-click on the picture, choose Picture Properties, and then find the text box for Alternative Representation in the Picture Properties dialog box.

For client-side image maps, either use the "alt" attribute with the AREA element, or link-text with A elements (see Image Map Guidelines). For the former method, Dreamweaver provides a Hotspot Properties Panel that includes a text box for entering alt text. This panel will appear when you use any of the hotspot tools from the Image Properties Panel:

The <APPLET> tag for Java applets also accepts an "alt" attribute, but it only works for browsers that provide support for Java. Often, users with slower internet connections will turn support for Java applets off. A better alternative for providing textual descriptions is to simply include the alternative text between the opening and closing <APPLET> or <OBJECT> tags. For instance, if a web designer wanted to include an applet called MyCoolApplet in a web page, and also include a description reporting that the applet shows a stock ticker displaying the current price of various stocks, the designer would use the following HTML coding:

<APPLET code="MyCoolApplet.class" width="200", 	
height="100">This applet displays current stock prices 
for many popular stocks.</APPLET>

Finally, yet another way of providing a textual description is to include it in the surrounding context:

<p>..it seems strange to be back. 
Below is a picture of me during my great vacation!</p>
<IMG src="pictureofme.jpg">

Alt descriptions for images used as links should note the link destination.

Link text should be identical or closely related to the title of the destination page or object. When an image is used as a link, however, the image is often used in the place of the link text, so the alt attribute of the IMG element should be used to indicate the destination, whether or not the image itself is also described. For example:

<a href="jjoyce.html"><img src="jjoyce.jpg" 
alt="James Joyce as a young man, link to long description" 
width="234" height="373" longdesc="jjoyce.html"></A>

Decorative graphics with no other function should have empty alt descriptions (alt= ""), but should not be missing alt descriptions.

If descriptive text is already provided above or below the image, an empty description, alt="", may be used in the IMG tag. In other situations where alternative text is unnecessary or distracting, such as images used as spacers, bullets in lists, and links that also contain text, alt="" should still be included so that non-graphical browsers know to ignore the image. Do not use this technique if the image is a link or is important for understanding the page.

For more information, see the World Wide Web Consortium's Core Techniques for Text Equivalents.

Using color

Web pages should be designed so that all information conveyed with color is also available without color, either from context or tags. Contrast between foreground and background should be distinct.

To make your sites accessible to the visually impaired, make sure that information is not conveyed through color alone. For example, do not ask users to "Please select an item from those listed in green." Instead, ensure that information is available through other style effects (e.g., a font effect), context (e.g., comprehensive text links), or an alternative indicator, such as an asterisk (*) or other symbol.

Color deficiencies associated with partial sight and congenital deficiencies make it difficult to discriminate between colors of similar hue. Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone with color deficits or when viewed on a black and white screen--will text and background still be distinguishable? Will your user still be able to navigate your links, images, etc.?

Don't assume that the lightness you perceive will be the same as the lightness perceived by people with color deficits. You can generally assume that they will see less contrast between colors than you will. If you lighten your light colors and darken your dark colors, you will increase the visual accessibility of your design.

To test whether your document still works without colors, examine it with a monochrome monitor or with browser colors turned off. Also, try setting up a color scheme in your browser that only uses black, white, and the four browser-safe shades of gray and see how your page holds up. You can also use WAVE to perform more sophisticated tests.

To test whether color contrast is sufficient to be read by people with color deficiencies or by those with low resolution monitors, print pages on a black and white printer (with backgrounds and colors appearing in grayscale). Also try taking the printout and copying it for two or three generations to see how it degrades. This will show you where you need to add redundant cues (example: hyperlinks are usually underlined on Web pages), or whether the cues are too small or indistinct to hold up well.

For more information you can go to Lighthouse International's tutorial for Effective Color Contrast.

Using stylesheets

Documents should be organized so they are readable without a style sheet.

Organize documents so they may be read without style sheets. When content is organized logically, it will be rendered in a meaningful order even when style sheets are turned off or not supported.

Style sheets may be used for color, indentation and other presentation effects, but the document should still be understandable (even if less visually appealing) when the style sheet is turned off.

If you use a style sheet, ensure that the important content appears in the documents that use the style sheet. Text generated by style sheets is not part of the document source and will not be available to assistive technologies that access content through the Document Object Model Level 1 (DOM1). Provide a text equivalent for any important image or text generated by style sheets (e.g., via the 'background-image', 'list-style', or 'content' properties).

If designers set up their pages to override user-defined style sheets, people with disabilities may not be able to use those pages. Therefore, designers must ensure that their web pages do not interfere with user-defined style sheets.

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. Example of source code:

You may also want to create an alternate external style sheet for your page that allows the user to view the page in larger text. This style sheet will be used as an alternate to the default style sheet, and can be coded in the following way:

For information on creating alternate styles sheets, please see the following articles by Paul Sowden. This article informed the style sheets on the CWRL site.

For information on CSS2 techniques for generating content from style sheets, you can go to the World Wide Web Consortium's Guidelines for Generated Content.

For information on using CSS properties to specify border styles, see the World Wide Web Consortium's Guidelines for Rules and Borders.

Using image maps

Image Map Guidelines (from W3C HTML Techniques)

An image map is an image that has "active regions." When the user selects one of the regions, some action takes place -- a link may be followed, information may be sent to a server, etc. To make an image map accessible, content developers must ensure that each action associated with a visual region may be activated without a pointing device (such as a mouse).

Image maps are created with the MAP element. HTML allows two types of image maps: client-side (the user's browser processes a URI) and server-side (the server processes click coordinates). For all image maps, content developers must supply a text equivalent.

Ths page contains guidelines for:

* using serve-side image maps
* writing redundant text in image maps

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.

Content developers should create client-side image maps (with the "usemap" attribute ) rather than server-side image maps (with the "ismap" attribute) because server-side image maps require a specific input device. If server-side image maps must be used (e.g., because the geometry of a region cannot be represented with values of the shape attribute), authors must provide the same functionality or information in an alternative accessible format. One way to achieve this is to provide a textual link for each active region so that each link is navigable with the keyboard. If you must use a server-side image map, please consult the section on server-side image maps.

Standard HTML client-side image maps are used, and appropriate alt tags are provided for the image as well as the hot spots.

Provide text equivalents for image maps since they convey visual information. As with other links, the link text should make sense when read out of context. Refer to the section on Link Text for information on writing good link text. Users may also want keyboard shortcuts to access frequently followed links. Refer to the section on Keyboard access to links.

If AREA is used to create the map, use the "alt" attribute:

<img src="welcome.gif"alt="Image map of areas in the library" usemap="#map1">
<MAP name="map1">
<AREA shape="rect" coords="0,0,30,30" href="reference.html" alt="Reference">
<AREA shape="rect" coords="34,34,100,100" href="media.html" alt="Audio visual lab">
</MAP>

The following example illustrates the same idea, but uses OBJECT instead of IMG to insert the image to provide more information about the image:

<OBJECT data="welcome.gif" type="image/gif" usemap="#map1">
There are several areas in the library including the 
<a href="reference.html">Reference</A> section and the
<a href="media.html">Audio Visual Lab</A>
</OBJECT>
<MAP name="map1">
<AREA shape="rect" coords="0,0,30,30" 
href="reference.html" alt="Reference">
<AREA shape="rect" coords="34,34,100,100"
href="media.html" alt="Audio visual lab">
</MAP>

In addition to providing a text equivalent, provide redundant textual links. If the A element is used instead of AREA, the content developer may describe the active regions and provide redundant links at the same time:

<OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
<MAP name="map1">
<P>Navigate the site.
[<A href="guide.html" shape="rect" coords="0,0,118,28">Access Guide</A>]
[<A href="shortcut.html" shape="rect" coords="118,0,184,28">Go</A>]
[<A href="search.html" shape="circle" coords="184.200,60">Search</A>]
[<A href="top10.html" shape="poly" coords="276,0,276,28,100,200,50,50,276,0">Top Ten</A>]
</MAP>
</OBJECT>

Note that in the previous example, the MAP element is the content of the OBJECT element so that the alternative links will only be displayed if the image map (navbar1.gif) is not.

Note also that links have been separated by brackets ([]). This is to prevent older screen readers from reading several adjacent links as a single link as well as to help sighted users distinguish between links visually.

Content developers should make sure they include printable characters (such as brackets or a vertical bar (|)) surrounded by spaces between adjacent text links. The problem does not occur if images have been used as links; The alt-text will not be read as a single link because of the place-holding images that graphical browsers use when images are not loaded. Refer to the section Grouping and bypassing links for more information.

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

Separate text links are provided outside of the server-side image map to access the same content that the image map hot spots access.

When a server-side image map must be used, content developers should provide an alternative list of image map choices. There are three techniques:

Include the alternative links within the body of an OBJECT element (refer to the previous example illustrating links in the OBJECT element).

If IMG is used to insert the image, provide an alternative list of links after it and indicate the existence and location of the alternative list (e.g., via that "alt" attribute).

<A href="http://www.example.com/cgi-bin/imagemap/my-map">
<IMG src="welcome.gif" alt="Welcome! (Text links follow)" ismap>
</A>
<P>
[<A href="reference.html">Reference</A>]
[<A href="media.html">Audio Visual Lab</A>]

If other approaches don't make the image map accessible, create an alternative page that is accessible.

Creating accessible tables

Row and column headers

Row and column headers should be identified for data tables.

Tables used strictly for layout purposes should not have header rows or columns. Data tables should have column and row headers appropriately identified (using the <TH> tag)

Tables allow us to arrange data -- text, images, links, other tables, etc. -- into rows and columns of cells. Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets, not tables, to control layout.

Table cells may either contain "header" information (use the TH element) or "data" (see the TD element). Cells may span multiple rows and columns. Individual cells can be labeled to communicate heading information about the cell (see markup for cells in data tables below). This information greatly assists users with visual disabilities, and allows multi-modal wireless /preowsers with limited display capabilities (e.g., Web-enabled pagers and phones) to handle tables.

Each table may have an associated caption that provides a short description of the table's purpose: e.g., <CAPTION>text</CAPTION>. For a longer description, use the summary attribute of the Table Element: e.g.,<TABLE summary="text">

When using Dreamweaver, you can select Edit>Preferences>Accessibility and then choose the tables checkbox. When you create a table, the following dialog box will appear:

This dialog box includes caption and summary text input fields. It also allows you to automatically create header tags for all your rows and/or columns. The align attribute of the caption element, meanwhile, like all style related attributes, can be more efficiently set in a style sheet.

For more information, see the World Wide Web Consortium's table page, from which this explanation has been adapted. For a /preief example, see the table below:

<TABLE border="1" summary="This table charts the number of
cups of coffee consumed by each senator, the type of coffee
(decaf or regular), and whether taken with sugar.">
    <caption>Cups of coffee consumed by each senator</caption>
    <tr> 
        <th>Name</th>
        <th>Cups</th>
        <th>Type of Coffee</th>
        <th>Sugar?</th>
    </tr>
    <tr> 
        <th>T. Sexton</th>
        <td>10</td>
        <td>Espresso</td>
        <td>No</td>
    </tr>
    <tr>
        <th>J. Dinnen</th>
        <td>5</td>
        <td>Decaf</td>
        <td>Yes</td>
    </tr>
</table>

Markup for cells in data tables

Markup (html tags) should be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers

Table cells should be associated with the appropriate headers (i.e. with the id, headers, scope and/or axis HTML attributes

• Headers (THEAD, TFOOT, and TBODY)
• Scope
• Axis

Headers
Use headers to identify relationships among table cells. Headers allow screen readers to interpret the information in tables. If there is more than one row or column of headers, a more extensive description of the relationship between cells helps the user understand the table's structure better.

Table rows may be grouped into head, foot, and body sections, with the THEAD, TFOOT and TBODY elements, respectively. These row groups convey additional structural information and may be rendered in ways that emphasize this structure. The head/body/foot division can help users scroll sections independently of the head and foot. When long tables are printed, the head and foot information may be repeated on each page that contains table data.

The table head and table foot should contain information about the table's columns. The table body should contain rows of table data. The following example illustrates the order and structure of table heads, feet, and bodies.

<TABLE>
  		<THEAD>
  		<TR> ...header information...
  		</THEAD>

  		<TFOOT>
  		<TR> ...footer information...
  		</TFOOT>
  		<TBODY>
  		<TR> ...first row of block one data...

  		<TR> ...second row of block one data...
  		</TBODY>
  		<TBODY>
  		<TR> ...first row of block two data...
  		<TR> ...second row of block two data...

  		<TR> ...third row of block two data...
  		</TBODY>
  		</TABLE> 

TFOOT must appear before TBODY within a TABLE definition.

Column groups can also provide additional structural information. Use the COLGROUP and COL elements to declare column properties at the start of a table definition. Users can then read the table incrementally rather than having to wait for all the table data to arrive.

Scope
The following example associates header and data information with the "scope" attribute rather than headers. Scope must have one of the following values: "row", "col", "rowgroup", or "colgroup." Scope specifies the set of data cells to be associated with the current header cell. This method is particularly useful for simple tables like the following:

Here is the HTML for the above table. Note the <TH> tags defining each column.

<TABLE border="border" summary="This table charts the number
  		of cups of coffee consumed by each senator, the type of coffee 
  		(decaf or regular), and whether taken with sugar.">
  		<CAPTION>Cups of coffee consumed by each senator</CAPTION>
  		<TR>
  		<TH scope="col">Name</TH>
  		<TH scope="col">Cups</TH>
  		<TH scope="col" ab/pre="Type">Type
  		of Coffee</TH>
  		<TH scope="col">Sugar?</TH>
  		</TR>
  		<TR>
		<TH scope="row">T. Sexton</TH>
  		<TD>10</TD>
  		<TD>Espresso</TD>
  		<TD>No</TD>
  		</TR>
  		<TR>
		<TH scope="row">J. Dinnen</TH>
  		<TD>5</TD>
  		<TD>Decaf</TD>
  		<TD>Yes</TD>
  		</TR>
  		</TABLE>

The axis tag can be used to create categories in more complex tables. Use it to group similar elements.

A speech synthesizer might render the example above by speaking the following:

San Jose
  		25-Aug-97: Meals: 37.74, Hotels: 112.00, Transport: 45.00
  		26-Aug-97: Meals: 27.28, Hotels: 112.00, Transport: 45.00
  		subtotals: Meals: 65.02, Hotels: 224.00, Transport: 90.00, subtotals: 379.02
  		etc.

Alternatively, the user may be interested only in a particular column, and with the appropriate markup can instruct the speech synthesizer to read it as follows:

Meals
  		San Jose
  		25-Aug-97: 37.74
  		26-Aug-97: 27.28
  		subtotals: 65.02

  		Seattle
  		27-Aug-97: 96.25
  		28-Aug-97: 35.00
  		subtotals: 131.25
  		Totals: 196.24

The HTML source for this example follows. Notice how "axis", "headers", and "id" attributes are used in some of the TH and/or TD tags. The axis attribute creates categories of headers uniquely identified by the id attribute, and the headers attribute refers to all of the headers associated with a particular cell.

<TABLE border="border" summary="this complex table example summarizes travel
		  expenses incurred during August trips to San Jose and Seattle">
		  <CAPTION> Travel Expense Report </CAPTION>

		  <TR>
		  <TH></TH>
		  <TH id="e1" axis="expenses">Meals</TH>
		  <TH id="e2" axis="expenses">Hotels</TH>

		  <TH id="e3" axis="expenses">Transport</TH>
		  <TH id="s1" axis="subtotals">subtotals</TH>

		  </TR>
		  <TR>
		  <TH id="l1" axis="location">San Jose</TH>
		  </TR>

		  <TR>
		  <TD id="d1" axis="date">25-Aug-97</TD>
		  <TD headers="l1 d1 e1">37.74</TD>

		  <TD headers="l1 d1 e2">112.00</TD>
		  <TD headers="l1 d1 e3">45.00</TD>
		  <TD></TD>
		  </TR>

		  <TR>
		  <TD headers="l1" id="d2" axis="date">26-Aug-97</TD>
		  <TD headers="l1 d2 e1">27.28</TD>

		  <TD headers="l1 d2 e2">112.00</TD>
		  <TD headers="l1 d2 e3">45.00</TD>
		  <TD></TD>
		  </TR>

		  <TR>
		  <TH headers="l1"id="s2"axis="subtotals">subtotals</TH>
		  <TD headers="l1 s2 e1">65.02</TD>

		  <TD headers="l1 s2 e2">224.00</TD>
		  <TD headers="l1 s2 e3">90.00</TD>
		  <TD headers="l1 s2 s1">379.02</TD>

		  </TR>
		  <TR>
		  <TH id="l2" axis="location">Seattle</TH>
		  </TR>

		  <TR>
		  <TD headers="l2"id="d3" axis="date">27-Aug-97</TD>
		  <TD headers="l2 d3 e1">96.25</TD>

		  <TD headers="l2 d3 e2">109.00</TD>
		  <TD headers="l2 d3 e3">36.00</TD>
		  <TD></TD>
		  </TR>

		  <TR>
		  <TD headers="l2"id="d4" axis="date">28-Aug-97</TD>
		  <TD headers="l2 d4 e1">35.00</TD>

		  <TD headers="l2 d4 e2">109.00</TD>
		  <TD headers="l2 d4 e3">36.00</TD>
		  <TD></TD>
		  </TR>

		  <TR>
		  <TD headers="l2"id="s3" axis="subtotals">subtotals</TD>
		  <TD headers="l2 s3 e1">131.25</TD>

		  <TD headers="l2 s3 e2">218.00 
		  </TD>
		  <TD headers="l2 s3 e3">72.00</TD>
		  <TD headers="l2 s3 s1">421.25</TD>

		  </TR>
		  <TR>
		  <TH id="t1" axis="totals">Totals</TH>
		  <TD headers="t1 e1">196.27</TD>

		  <TD headers="t1 e2">442.00</TD>
		  <TD headers="t1 e3">162.00</TD>
		  <TD headers="t1 s1">800.27</TD>

		  </TR>
		  </TABLE> 

For more information, see the World Wide Web Consortium's table page, from which this explanation has been adapted.

Using frames

Frames titles should indicate frame content and navigation.

Each frame should have a title that helps the user understand the frame's purpose.

A frameset combines at least two other separate Web pages in the same window of a browser. Although recent screen readers can interpret frames, frames can still be disorienting to the user. Over the last several years, the use of frames has become less common, since the effect can often be simulated by the reduplication of banners and navigation structures on each page. If you do choose to employ frames, use the "title" attribute of the <FRAME> element to describe each frame's purpose, as in the following example:

<FRAMESET cols="15%, 85%">

<FRAME src="menu.html" title="Navigation menu"name="menu">

<FRAME src="content1.html" title="Main content" name="content">

The "name" attribute of the <FRAME> element can be used for targeting and should not be regarded as a functional replacement for the title attribute. The <FRAME> element also implements the "longdesc" attribute (see Creating Alternative Text), which should be used to supplement the short description provided by the title attribute.

Alternative <NOFRAMES> content should always be available if the user cannot or chooses not to view frame content. The <NOFRAMES> content should indicate what the contents of the frames are and provide links to individual frame pages if appropriate, as in this example.

<NOFRAMES>
<P>This frameset document contains:
<UL>
	<LI><a href="menu.html">Page navigation</A>
	<LI><a href="content1.html">Main content</A>
</UL>
</NOFRAMES>
</FRAMESET>

These two pieces of sample code could be joined to form a complete frameset.

If you are using Dreamweaver MX, you can activate the Frame Tag Accessibility Attributes Dialog Box by selecting Edit>Preferences>Accessibility and choosing the Frames Checkbox. Then whenever you insert a frame in the Design window, the following dialog box will appear:

The dialog box includes a text field for entering the title as well as a dropdown list of name attribute values for the current frame and all pre-existing frames. In Dreamweaver, frames automatically use a naming convention based on positioning (e.g. "leftFrame" or "mainFrame"). You can only change these frame names in the code view.

This description has been adapted from the frames page at www.webaim.org.

Flickering content

Avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

Unacceptable levels of screen flicker can trigger seizures in users with photosensitive epilepsy. Many other users find it annoying. Flashing or flickering elements are usually added through technologies such as animated gif's, Java applets, or third-party plug-ins or applications.

In general, avoid animation unless you have a compelling reason to use it. Do not use scrolling text, which is inaccessible to screen readers and impossible for some people to read.

The following link demonstrates unacceptable screen flicker. Do not follow this link if you have photosensitive epilepsy:
http://ncam.wgbh.org/richmedia/media/flicker_demo.html

Using applets

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 an appropriately accessible applet, plug-in, or other application.

The bulleted items below are guidelines for appropriately accessible applets, plug-ins, and applications.

• When software is designed to run on a system that has a keyboard, product functions should be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
• Applications should not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also should not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.
• A well-defined on-screen indication of the current focus should be provided that moves among interactive interface elements as the input focus changes. The focus should be programmatically exposed so that assistive technology can track focus and focus changes.
• Sufficient information about a user interface element including the identity, operation and state of the element should be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.
• When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images should be consistent throughout an application's performance.
• Textual information should be provided through operating system functions for displaying text. The minimum information that should be made available is text content, text input caret location, and text attributes.
• Applications should not override user selected contrast and color selections and other individual display attributes.
• When animation is displayed, the information should be displayable in at least one non-animated presentation mode at the option of the user.
• Color coding should not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
• When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels should be provided.
• Software should not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
• When electronic forms are used, the form should 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.
• When embedded into web pages, few plug-ins are currently directly accessible. Some of them (e.g. RealPlayer) are more accessible as standalone products. It may be better to invoke the whole program rather than embed movies into pages at this point, although this may change in the future.
• Acrobat Reader 5.0 allows screen readers to access PDF documents. However, not all users have this version installed, and not all PDF documents are text-based (some are scanned in as graphics), which renders them useless to many assistive technologies. It is recommended that an accessible HTML version be made available as an alternative to PDF.
• PowerPoint files are currently not directly accessible unless the user has a full version of the PowerPoint program on the client computer (and not just the PowerPoint viewer). It is recommended that an accessible HTML version be provided as well.

Creating forms

When electronic forms are designed to be completed on-line, the form should 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.

All form controls must have text labels adjacent to them.

Form controls, or form objects, are special elements by which users interact with forms. Examples include buttons, checkboxes, menus, and text inputs.

Until user agents support explicit associations between labels and form controls for all form controls with implicitly associated labels, ensure that the label is properly positioned. The label must immediately precede its control on the same line (allowing more than one control/label per line) or be in the line preceding the control (with only one label and one control per line).

Form elements should have labels associated with them in the markup.

Whenever you use a form control / object, use the <LABEL> tag to implicitly associate a label with the control. You should also use the “id”and “for” HTML attributes to explicitly associate labels with form controls:

                <LABEL for="firstname">First Name:
		<INPUT type="text" id="firstname">
                </LABEL>

The preceding example wraps the <LABEL> tag around the <INPUT> tag, so the inclusion of the explicit association provided by the "for" and "id" attributes may not be necessary. In fact, Dreamweaver's "Input Tag Accessibility Attributes" dialog box makes you choose between these two methods. You can activate this dialog box by selecting Edit>Preferences>Accessibility and choosing the "Form Elements" checkbox. The following dialog box will then appear whenever you insert a form object:

For reasons stated earlier, the radio buttons labeled "Style: No Label Tag" and "Position: After Form Item" should never or rarely be selected. The "Access Key" text field assigns a value to the "accesskey" attribute, which enables the user to directly access the form control. The "Tab Index" text field assigns a value to the "tabindex" attribute, which determines the control's position in the tab order. Since many users prefer to tab through forms rather than using a mouse, ensuring a logical tab order is important.

It is also a good idea to provide a default value for each form control using the "value" attribute:

<LABEL accesskey="n">First Name: 
<INPUT type="text"value="firstname" tabindex="1">
</LABEL>

When form controls can be grouped into logical units, use the <FIELDSET> element and label those units with the <LEGEND> element:

                  <FORM action="http://example.com/adduser" method="post">
		  <FIELDSET>
		  <LEGEND>Personal information</LEGEND>
		  <LABEL for="firstname">First name: </LABEL>
		  <INPUT type="text"
		  id="firstname" tabindex="1">
		  <LABEL for="lastname">Last name: </LABEL>
		  <INPUT type="text"id="lastname" tabindex="2">
		  ...more personal information...
		  </FIELDSET>
		  <FIELDSET>
		  <LEGEND>Medical History</LEGEND>
		  ...medical history information...
		  </FIELDSET>
		  </FORM>

Make sure that the Dynamic HTML scripting of the form does not interfere with assistive technologies.

Test out your form with Bobby, at http://bobby.watchfire.com, or with WAVE, at http://wave.webaim.org, especially if you use dynamic HTML. If the dynamic HTML interferes with assistive technology, such as screen readers, provide a form alternative that does not use the dynamic HTML. You should also provide alternative means of submitting form information, such as a phone number and/or a mail or email address.

For further information, see the World Wide Web Consortium’s Guidelines for Forms.

Shortcuts and skip to content links

Bypassing Repetitive Content

A method should be provided that permits users to skip repetitive navigation links.

Many sites include a series of navigation links at the top, or down the side of the page, sometimes repeating on every subsequent or embedded page. These navigation links can be frustratingly repetitive for users of screen-readers since screen readers read from beginning to end and users do not always have the ability to ignore content unless a means is provided to bypass it.

You can create bypass links to reduce this unnecessary reading. One of the most common strategies is to include an "invisible" (transparent or matching the background color) 1pixel x 1pixel gif immediately before the content to be skipped and to anchor this image further down the page, past the unnecessary material. Although this image/link will probably go unnoticed by users deploying pointing devices and visual user-agents, users of screen readers will take note of this image and link. Like all images, the tag for this invisible gif should include alt text with something to the effect of "bypass navigation links" or "skip to main content."

The following example provides code for skipping over repetitive navigation:

<P><A href="#skipover"><IMG src="skipover.gif"
width="1" height="1" alt="skip to main content"> 
<a href="http://wwwnt.cwrl.utexas.edu/web/accessibility/guidelines/index.html">
</A></P>
<P><A href="http://www.lib.utexas.edu">Visit the Library</A></P>
<P><A href="http://www.utexas.edu">Home</A></P>

Using Keyboard Shortcuts

When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.

Unless you are developing your own software application, this requirement is probably not relevant for you. If you are developing software, make sure that there are keyboard shortcuts available for all the functions of your application and that these shortcuts are easy to find. The application should also be tab-navigable or implement some other keyboard navigation scheme. In other words, the user should be able to use and manipulate the software without using a mouse. The user should also be informed textually of the result of performing a function. For example, if he or she executes a "save changes" command with the keyboard, the resulting screen should include a textual message reading something like "document saved." This way, blind and visually impaired students using a voice application will be able to quickly verify that a given function has been performed. Other users will also benefit from such feedback.

If you are an instructor with keyboard-dependent students, make sure that the software used in your course is in compliance with this guideline.

For more info, search the NCAM (National Center for Accessible Media) website.