Skip header information, go directly to content

OSU Minimum Web Accessibility Standards

Index
  1. Alternate Text.
  2. Synchronization.
  3. Color.
  4. Contrast.
  1. Style Sheets.
  2. Image Maps.
  3. Server-side Maps.
  4. Tables.
  1. Table Headers.
  2. Frames.
  3. Screen Flicker.
  4. Scripting.
  1. Applications and Plug-ins.
  2. Forms.
  3. Skip Navigation.
  4. Timed Response.
  1. Pop-up Windows.
  2. Link Targets.
  3. Alternate Versions.
  4. Best Practices.

 

mwas standard Standard 1-- Alternative Text.
A text equivalent for every non-text element shall be provided (e.g., via alt tags, "longdesc, or in element content).

Examples:
1.1 -- Non-text elements (images, java applets, flash files, video files, audio files, plug-ins, etc.) have alt tag descriptions that convey the purpose or intended meaning of the object (e.g. Alt Tags for images used as links describe the link destination).
1.2 -- Complex graphics that summarize information (graphs, charts, tables, etc.) are accompanied by text conveying the information providing a meaningful narrative of the information.
1.3 -- Decorative graphics with no other function have empty alt descriptions (alt= "") not missing alt descriptions.
1.4 -- When descriptions are lengthy or refer to other resources or sites, a longer description will be made available using a link or supported "longdesc".

ALT Tags -- Dos and Don'ts

Do Don't

Insure every image has an ALT tag.

Use generic ALT tags such as "image" or "graphic."

Why: ALT tags offer the only method for screen readers to render images. They also act as descriptive place-holders when users turn-off images in their browsers (as users of slow internet connections frequently do).

How: Most web authoring tools (e.g. Dreamweaver, FrontPage) allow you to set the accessibility options so the program automatically asks you to enter an ALT tag when an image is inserted. If your editor does not have this option, you must add the alt="description" attribute to the <IMG> element in your HTML code.

Do Don't

Use empty ALT tags (alt="") for decorative or spacer images.

Use descriptive ALT tags for dividers and borders (e.g. alt="yellow line" or alt="blank space"

Why: Images used for spacing or aesthetics are not needed to understand the content of the page. By including a descriptive ALT tag for these images, you are adding unnecessary clutter to your pages. However, an empty ALT tag signals to the screen reader to "skip" the image and not identify it. If there is NO ALT tag, the screen reader will still say "graphic" or "image."

How: Some web editors only allow you to either create a descriptive ALT tag or no ALT tag. Since inserting an empty alt tag (ALT="") is different from having no ALT tag, you may have to directly edit the <IMG> element in your HTML code to create an empty ALT tag.

Do Don't

Be descriptive. Describe the function of the image, if any, rather than the shape (e.g. alt="send us email" instead of "picture of letter opening")

Be verbose. Example: alt="This animated gif shows a letter opening and closing with a mailbox in the background. Enable this mail to-link to send us your comments, questions, or concerns about this site."

Why: What an image looks like or how it is arranged is frequently less important that the function that the image has on the page: a link, an example, a highlight. When you are unable to describe the function of the image in less than 150 characters, use the LONGDESC attribute to give users more time to review your description.

How: Keep it <150 characters when possible. Use the LONGDESC attribute for longer descriptions. Focus on the purpose of the image rather than the characteristics of the image. If you find yourself saying "this image is just fun" or "this image is just pretty", consider using an empty ALT tag for that image.

Get more help with ALT tags for Images, visit All Things Web: "The Art of ALT".

Return to index.

Long Descriptions (LONGDESC) -- Dos and Don'ts

Do Don't

Use a long description for graphs, charts, and other complex images that convey information.

Use a long description for all images.

Why: Using the LONGDESC attribute requires you to put the full and detailed description on a separate HTML page, where users will have time to review it and can easily come back to the description. The long description should be used when detailed explanations, transcripts, or other lengthy descriptions are needed to fully comprehend the graphic or image.

How: Create a separate page containing the long description. Include both the ALT and LONGDESC attribute in your <IMG>, and include the URL to the long description page as the value of the LONGDESC attribute. For example: <IMG src="cartoon.gif" alt="a Calvin and Hobbes cartoon" longdesc=/images/calvin-writing.htm>

Do Don't

Use the "D-link" as well as the long description.

Rely on "LONGDESC" attribute only; some assistive technology still does not support LONGDESC.

Why: Browser support for the LONGDESC attribute is not yet extensive. Therefore, designers must also use the older solution of the D-link.

How: Immediately following (to the right) of the image, include a link to the long description page. Make the link text a "D." Example: <IMG src="cartoon.gif" alt="a Calvin and Hobbes cartoon" longdesc=/images/calvin-writing.htm><A href="/images/calvin-writing.htm>D</a>. You may make this D-link invisible or transparent using style sheets or other methods.

See this method in action: WAC Best Practices Tutorial: Images.

Do Don't

Consider including a caption or summary within the text of the page, as well as using the long description.

Assume only vision-impaired/screen reader users can benefit from long descriptions or summaries.

Why: Linking to a page containing the long description interrupts the flow of the current page content and may become tedious if several graphs or charts requiring long descriptions are on a single page. Using an in page caption helps not only visually impaired users, but all users who may otherwise have difficulty interpreting the image, graph, or chart.

How: Whenever possible, place the caption or description before (above or to the left) of the image it describes. This insures that screen readers read the description before reaching the image. Captions may be identified by formatting or may be included in-line with the other text on the page.

Get more help with Long Descriptions , visit W3C's "7.2 Long descriptions of images."

Return to index.

Alternative Text for Multimedia

See also: Standard 2 -- Synchronization.

Do Don't

Provide a transcript as well as captioned video.

Provide a transcript instead of captions or only offer captions and no transcript.

Why: A transcript represents a true "alternate format" of video that does not require special software (video viewer) to access. Captions help make video more accessible, but still depend on the accessibility of the player.

How: Use the same text used in captioning to create a transcript. The transcript may also include more thick description than the captions would (e.g. descriptions of the scene, graphics displayed, and other visual elements important to comprehension).

Return to index.

mwas standard Standard 2 -- Synchronization.
Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

Note: 2.1) Limited access password protected pages with a controlled user group may identify, in writing, a process for providing access to multimedia presentations. The process must address how the information will be made accessible within a comparable time frame and with comparable effort by the user

Examples:
2.1 -- Multimedia files posted to a department page has synchronized captions.
2.2 -- A web page supporting an on campus course presents multimedia files and provides a separate statement about requesting captioning and the instructor/department has a letter from the Office For Disability Services outlining the time frame and various responsibilities for providing captioning.

Synchronization -- Dos and Don'ts

See also: Standard 1 -- Alternative Text.

Do Don't

Caption video so that captions appear at the same time the words are spoken in the video.

Frontload or backload captions, so that captions appear in large chucks before or after words are spoken in the video.

Why: Captions that appear in-synch with the audio of a video track helps users associate the words with the images and also helps associate the speaker with the words.

How: Divide your captions into "chunks" and associate the smaller sections with the correct frame of video. Make captions no longer than three lines per screen.

Get more help with captioning and synchronization , visit NCAM's Rich Media Accessibility .

Return to index.

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

Examples:
3.1 -- If color is used to convey information alternative indicators, such as an asterisk (*), are used in conjunction. .

Color -- Dos and Don'ts

See also: Standard 4 -- Contrast.

Do Don't

Use color to emphasize and draw attention to certain content.

Use color to convey information (e.g., all the blue text is required reading).

Why: Using color alone to identify links, buttons, navigation paths, or other content means those who cannot distinguish the colors or those with colors turned off or using monochrome monitors (such as on PDAs or cell phones) are unable to use your page.

How: Along with color, use graphic symbols such as underlining, asterisks, or borders to identify special content (including links). Label buttons and navigation bars with text. Test your page by printing on a black and white printer.

Do Don't

Use color to highlight links; use underline and/or bold as well.

Use only color to distinguish links.

Why: Style sheets allow you to turn-off the default underlining of links. While these may be advantageous for menu items (which are usually distinguished by location, background color, and border as well) links in the body of the page need to be clearly differentiated from other text. A good way to frustrate and alienate users is to make them "hunt" for the links on your page.

How: Do not turn off underlining for links in the body of your page or use other non-color distinction such as bold, asterisk, or other character or symbol.

Get more help with information and color, read the iGeek article "Color to convey information".

Return to index.

mwas standard Standard 4 -- Contrast.
Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on black and white screen.

Examples:
4.1 -- Blue on Blue, using different saturations of the same color for background and foreground.

Contrast -- Dos and Don'ts

See also: Standard 3 -- Color.

Do Don't

Use high contrast colors.

Use similar text and background colors (e.g. light grey on dark grey; light blue on dark blue).

Why: Two colors that contrast sharply to someone with normal vision may be far less distinguishable to someone with a visual disorder. It is the contrast of colors one against another that makes them more or less discernible rather than the individual colors themselves.

How: 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 the light colors and darken the dark colors in your design, you will increase the visual accessibility.

Get more help with contrast color, visit Lighthouse International.

Return to index.

mwas standard Standard 5 -- Style Sheets.
Documents shall be organized so they are readable without requiring an associated style sheet.

Note: WCAG Recommends using style sheets to control layout and presentation.  This method is strongly preferred over the use of tables due to wider compatibility with end user devices

Examples:
5.1 -- When a document is rendered without associated style sheet, it must still be possible to read the document.
5.2 -- 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).

Style Sheets -- Dos and Don'ts

Do Don't

Use style sheets whenever possible.

Make content style sheet dependent. (Insure when style sheets are disabled, the page still works.)

Why: Style sheets are the win-win situation for designers and users. Designers can specify exact formatting parameters (size, colors, weight, position) in one easily changed document and apply it to the whole site. Users can simply "turn off" styles to view the content in its simplest form or create their own custom style sheets to change formatting to suit their preferences.

How: Do not create content using a style sheet or scripting. Test your site both with and without style sheets and scripting enabled in your browser.

Do Don't

Mark up content instead of using images.

Use images to represent text or as a means of stylizing text.

Why: Designers who want to control the exact look of text often create text-as-images, which allow them to "freeze" the font, size, color, and position. However, text-images do not scale well, cannot be easily resized, are invisible to screen-readers without an ALT tag, and cannot be copied/pasted into editors and other assistive technology.

How: Style text using a style sheet rather than creating an image of styled text.

Get more help with style sheets , visit the Web Design Group's "Cascading Style Sheets".

Content Organization -- Dos and Don'ts

Do Don't

Use header tags (H1, H2, H3) to organize and indicate content hierarchy.

Use header tags for styling text. (Use a style sheet instead.)

Why: When used correctly, header tags can indicate the structure of the page and help writers of web text better organize content. When used for formatting, headers become meaningless and pages may look cluttered and disorganized when styles are turned off.

How: Organize content using headers to indicate an outline of topics and subtopics. H1=the top level, H2=second level, and so on.

Do Don't

Use lists to group items.

Use lists for indenting or spacing.

Why: Lists offer a useful way to associate like items (as in "All the best restaurants in my town." or "Places to bike ride."). However, lists have specific functionality when rendered by screen-readers and other assistive technology. Therefore, you should not use lists for formatting.

How: Use style sheets to indent or change the spacing between lines of text.

Get more help with organizing content,
visit the W.A.I.'s "The Global Structure of an HTML Document".

Return to index.

mwas standard Standard 6 -- 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.

Examples:
6.1 -- Use standard HTML client-side image maps with appropriate alt tags for the image and hot spots .

Image Maps -- Dos and Don'ts

see also: Standard 7 -- Server-side Maps.

Do Don't

Use client-side image maps whenever possible. Use server-side image maps only when map areas cannot be defined as a geometric shape.

Use server-side image maps regardless of the map shape.

Why: Client-side image maps store map information within the HTML document. Server-side image maps require server processing to define the hotspot area and action (or link location). Thus, links in server-side maps do not show up on link lists and other assistive technology tools. Plus they require more server resources and more delay time for users.

How: Insert an IMG as usual. Create a MAP and link it to your IMG using the "id" attribute. Create an AREA for each map hotspot.

Sample HTML Code:

<img src="../images/mwas.gif" alt="mwas standard" width="70" height="40" border="0" usemap="#mwasmap" />
<map name="mwasmap" id="mwasmap">
<area shape="rect" coords="4,7,35,22" href="home.htm" alt="return to home page" />
</map>

End Code.

Do Don't

Include a separate ALT tag for each map AREA (hotspot).

Only give an ALT tag to the IMG or to the MAP as a whole and not to the individual defined AREAS.

Why: Unlike server-side image maps, the client-side image map allows an author to assign text to each image map “hot spots.” which helps assistive technology users to more easily identify and activate regions of the map. Also, region ALT tags will appear, even if the image does not download or images are turned off.

How: For each "area" element in the map, include an ALT tag that defines the function of the area.

Get more help with image maps, visit W3C's "13.6 Image Maps".

Return to index.

mwas standard Standard 7 -- Server-Side Maps.
Redundant text links shall be provided for each active region of a server-side image map .

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

Server-side Image Maps -- Dos and Don'ts

See also: Standard 6 -- Image Maps.

Do Don't

Provide text-equivalent links for each active region of a server-side map.

Only provide a server-side map with no text links.

Why: 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. Thus, navigation is tied to specific screen location and not accessible to keyboard users.

Note: Server-side maps may require the use of specialized applications or "plug-ins." If so, web authors are required to select an application accessible to assistive technology and provide a link to the download page where the accessible version may be acquired. (See Standard 13 -- Accessible Plug-ins.)

How: Make sure links tied to a server-side image map also appear as text links somewhere else on the page.

Get more help with server-side image maps, visit Webmonkey's "Piecing Together Server-side Image Maps".

Return to index.

mwas standard Standard 8 -- Tables.
Row and column headers shall be identified for data tables .

Examples:
8.1 -- Tables used only for layout do not have header rows or columns.
8.2 -- In data tables, column and row headers are identified using the <th> tag.

Table Markup -- Dos and Don'ts

See also: Standard 9 -- Table Headers

Do Don't

Create layout tables with no summary, no caption, and no column or row headers.

Markup layout tables in the same way as data tables.

Why: Layout tables are a special kind of table used to control aesthetics rather than convey information. Adding information, such as a summary or caption, to a layout table only confuses users. If layout tables do not have data table markup, they are typically ignored by screen readers, which instead read the content rather than the structure of the table.

How: For layout tables, do not include the "summary" attribute and do not use the <th> element.

Do Don't

Create row and column headers for data tables.

Use data tables that do not clearly identify the contents of each column and row.

Why: When data tables do not have row and column headers, 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. When coded properly, a screen reader will help orient the user by identifying the appropriate row or column header before reading the data within a particular cell.

How: The first row of each table should include column headings. Typically, these column headings are inserted in <TH> tags, although <TD> tags can also be used, along with the scope="col" attribute. Similarly, the each cell in the first column of every data table should include uniquely identifying information about the content of each row in the table. Each of the cells in that first column are created by either <TH> or <TD>. Include the following attribute in these cells: scope="row".

Get more help with tables, visit the Access Board's Section 508 information on tables.

Return to index.

mwas standard Standard 9 -- Table Headers.
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 .

Examples:
9.1 -- Table cells are associated with the appropriate headers (e.g. id, headers, scope and/or axis HTML attributes).

Standard 9 -- Table Headers.

See also: Standard 8 -- Tables.

Do Don't

Consider using ID to associate each cell of a data table with its header.

Create a sub-table (table within a table) without associating each cell with its appropriate header.

Why: Unlike using the "scope" attribute, using the "id" and "headers" attributes requires that every data cell in a table include special attributes for association. It can be useful when tables include sub-tables or subsets of data, as it helps insure each cell is associated with the appropriate descriptive header.

How: Define the header using the "id" attribute in the <th> element. Then specify the correct header using the "headers" attribute in the <td> element of each data cell.

Sample HTML table code:

<table>
<tr>
<th>&nbsp;</th>
<th colspan="2" id="winter" >Winter</th>
<th colspan="2" id="summer" >Summer</th>
</tr>
<tr>
<th>&nbsp;</th>
<th id="am1" >Morning</th>
<th id="pm1" >Afternoon</th>
<th id="am2" >Morning</th>
<th id="pm2" >Afternoon</th>
</tr>
<tr>
<td id="wilma" >Wilma</td>
<td headers="wilma am1 winter" >9-11</td>
<td headers="wilma pm1 winter" >12-6</td>
<td headers="wilma am2 summer" >7-11</td>
<td headers="wilma pm2 summer" >12-3</td>
</tr>
<tr>
<td id="fred" >Fred</td>
<td headers="fred am1 winter" >10-11</td>
<td headers="fred pm1 winter" >12-6</td>
<td headers="fred am2 summer" >9-11</td>
<td headers="fred pm2 summer" >12-5</td>
</tr>
</table>

End code.

This table would be displayed as follows:

  Winter Summer
  Morning Afternoon Morning Afternoon
Wilma 9-11 12-6 7-11 12-3
Fred 10-11 12-6 9-11 12-5

 

Get more help with data tables, visit WebAIM's "Creating Accessible Tables."

Return to index.

mwas standard Standard 10 -- Frames.
Frames shall be titled with text that facilitates frame identification and navigation. .

Examples:
10.1 -- Each frame has a title that describes its purpose or the type of information contained within the frame.

Frames -- Dos and Don'ts

Do Don't

Avoid frames whenever possible.

Use frames for all navigation.

Why: Frames have gone out of fashion and for good reason. Frames render the user's "BACK" button and "HISTORY" list useless and cause serious barriers to keyboard users who need to move between frames -- e.g., the outer "navigation" frame and the inner "content" frame.

How: Instead of frames, use repeating navigation elements placed in a consistent location with consistent markup on each page.

Do Don't

Label each frame with a unique title identifying the content and/or functionality.

Use no title or the same repeating title (e.g. "frame") for each frame.

Why: Users of assistive technology rely on frame titles to identify which frame currently has the focus and to move between frames.

How: For each <FRAME> element include an identifying "title" attribute.

Get more help with frames, visit WebAIM's "Creating Accessible Frames."

Return to index.

mwas standard Standard 11 -- Screen Flicker.
Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz .

Screen Flicker -- Dos and Don'ts

Do Don't

Screen items which flicker (blink) must do so either at a rate of less than twice a second or more than 55 times a second. A Hertz (Hz) is a cycle per second.

Cause images to move too quickly or too slowly. Create images that flicker with intense contrast (e.g. black/white).

Why: Moving images can cause serious injury to those with epilepsy, migraines, or other vision-triggered conditions. And they are distracting and quickly become annoying for the rest of us. Use moving images only when necessary to interpreting content.

How: 2Hz = 2 flashes per second. 55Hz=55 flashes per second. Most image software divides a second into 100 units. 2Hz would equal 50/100 (2 flashes x 50units per sec = 100 units) and 55 Hz would equal 1.8/100 (55 flashes x 1.8 units per sec = 100 units). Animation should not be set between 2 and 55 Hz.

Do Don't

Allow users to turn-off moving elements or cause movement to stop after a certain time frame or number of cycles.

Use too many flickering/moving elements on a page. Cause constant motion on a page.

Why: Besides being dangerous to some users, flashing and flickering elements distract from other content on the page.

How: There is no good method for turning off animated gif's. Therefore, designers should program gif's to stop after so-many cycles of the animation loop. Other objects, such as music clips, movies, or flash should include a javascript stop button to stop motion or sound.

Get more help with flicker and moving images, visit NCAM's examples of flicker rate.

Return to index.

mwas standard Standard 12 -- Scripting.
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 .

Examples:
12.1 -- Within scripts information is text-based or a text alternative is provided.
12.2 -- All scripts (Javascript, pop-up menus, etc.) work with keyboard-accessible alternatives (either within or outside of the script) that provide equivalent functionality.

Scripting -- Dos and Don'ts

Do Don't

Use scripts that create usable elements and/or readable text in the page.

Use scripts that generate server-side objects or content that cannot be read when scripts are turned off.

Why: When authors do not put functional text with a script, a screen reader will often read the content of the script itself in a meaningless jumble of numbers and letters. Although this jumble is text, it cannot be interpreted or used.

How: Test pages with browser scripting turned off. Test page functionality using only the keyboard. Avoid mouseover events and script embedded images.

Get more help with scripts, visit Jim Thatcher's "Scripts and Applets."

Return to index.

mwas standard Standard 13 -- Applications and Plug-ins.
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 standards 1-9 of this document. .

Examples:
13.1 -- When applets, plug-ins or applications (Java applets, Java scripts, Acrobat PDF files or PowerPoint files) are not accessible to assistive technologies you must provide an alternative means of accessing the content within the applications (e.g., a mirror HTML file for a PDF file).
13.2 -- When an applet, plug-in or application is utilized you must provide a link to a an accessible page where the plug-in can be downloaded.

Plug-ins -- Dos and Don'ts

Do Don't

Only require the use of accessible plug-in or external applications to access content.

Offer content only in a format requiring a non-compliant application or in a non-compliant format.

Why: Web authors frequently rely on other applications beyond those available in a browser to display specialized content. It is the responsibility of the web author to insure that these applications are compliant with MWAS and available to assistive technology users.

How: Do not assume that popular technology like video and presentation viewers are accessible to users of assistive technology. Investigate the accessibility policies of the companies responsible for any auxiliary application you require and, if possible, test those applications using assistive technology.

Do Don't

Provide a link to accessible versions of required plug-ins.

Assume users will have the necessary plug-ins installed or require the use of plug-ins that are not compatible with assistive technology.

Why: To make it possible for specially formatted files (e.g. PDF or video) to be viewed by web browsers, add-on programs or "plug-ins" need to be downloaded and installed on the user's computer. Web designers should not assume users already have these plug-ins installed.

How: Provide a link to the download page of any necessary plug-in on each page it is required to view information or perform tasks.

Do Don't

If a plug-in compatible with assistive technology is not available, offer the content in an alternate format.

Exclude users who cannot obtain or use a required plug-in from access to site content.

Why: Web authors should, whenever possible, only require the use of external applications if those applications meet accessibility guidelines. However, if no such accessible plug-in exists, content requiring the plug-in must be offered in a different format.

How: Offer the content both using the plug-in application and in an accessible format. For example, if you are posting a PowerPoint presentation that requires the PowerPoint viewer (which is not an accessible technology), you may also display the content of the presentation in HTML format.

Do Don't

Include a link to the Acrobat Reader plug-in.

Expect users to have Acrobat Reader already installed.

Why: Because assistive technology can be very system intensive, many users avoid extraneous software. Users with slow connections may not have wanted to take the time to download additional software or keep up with updates.

How: Include a link to the download page for the latest version of Adobe Reader on every page in which a link to a PDF file occurs.

Get more help with plug-ins, visit Usability.gov.

Return to index.

mwas standard Standard 14 -- Forms.
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.

Examples:
14.1 -- Form controls have text labels adjacent to them and keyboard access to control functionality.
14.2 -- Form elements have explicitly associated labels in the markup (i.e. the id and for, HTML elements).
14.3 -- Dynamic HTML scripting of the form does not interfere with assistive technologies.

Forms -- Dos and Don'ts

Do Don't

Include a label for each form element.

Make long labels with detailed instructions.

Why: Well-meaning designers often error on the other side of accessibility: adding too much information. Be aware that users with disabilities want to use the web in the same way as other users: they want to access information and perform necessary tasks quickly and easily. Adding verbose directions only adds to the clutter of a site. If the directions are important, put them in the main body of the form, where everyone can see them and benefit from them.

How: Create a label that describes the function of the element or the required information and is as short as possible.

Good label: <label for="textbox1">First Name:</label>

Too much information label: <label for="textbox1">Begin this form by entering your First Name:</label>

Do Don't

Place label as close to the form element as possible.

Separate labels and elements with dividers or by putting them in separate cells.

Why: Older versions of assistive technology software may still be unable to associate form controls with their labels requiring users to first read the label, then find the form control.

How: Place labels immediately adjacent to form elements. If you use tables to layout the form, put both the form label and element in the same cell.

Do Don't

Explicitly associate form labels with form elements.

Put label information next to or near the form element without connecting them using code.

Why: Form elements without explicitly associated labels will be read as "blank." Finding out which information belongs in which "blank" box is difficult, at best.

How: Use the "for" attribute in the label and the "id" attribute in the element.

Example HTML code: <label for="textbox1">First Name:</label><INPUT type="text" id="textbox1">

Do Don't

Create a logical tab order for navigating the form.

Assume users will "click" in the boxes and form elements they want to change.

Why: Users of assistive technology frequently fill-out forms out-of-order (that is, not top-down, left-to-right). Specifying a tab order helps insure that all form elements can be accessed with a keyboard and that keyboard users can navigate the form in a logical way.

How: Use the "tabindex" attribute in the element. You must specify a tabindex for each element in your form.

Example HTML code: <INPUT type="text" tabindex="1">.

Do Don't

Assign access keys for form elements, particularly buttons, to insure form is accessible to keyboard users.

Use elements that require a mouse to activate.

Why: JavaScript events, such as the "OnClick" don't always work for keyboard users. Access keys establish keyboard shortcuts for frequently used or important functions of the form or page.

How: Use the "accesskey" attribute in the element.

Example HTML code: <INPUT tabindex="2" type="submit" name="submit" accesskey="S">

Get more help with forms, visit WebAIM's "Creating Accessible Forms."

Return to index.

mwas standard Standard 15 -- Skip Navigation.
A method shall be provided that permits users to skip repetitive navigation links. .

Examples:
15.1 -- A link is provided to skip over lengthy lists of links (e.g. navigational menus).

Navigation -- Dos and Don'ts

Do Don't

Allow users to skip navigation.

Bury content far down the page or after a lengthy links-list.

Why: Web sites are often top-heavy with menu items and screen readers must read all these items each time a page is loaded before the main content is read. Even a repeating menu of just five links can quickly become annoying. Further, more recent screen reader updates include an auto-detect feature that automatically positions the cursor at the "content" anchor rather than reading the full menus.

How: This in-page link may be either visible or invisible. You can make it invisible by using a style sheet to color the text the same color as the page background or by using a transparent image link (no less than 2 pixels by 2 pixels). Place an anchor/bookmark in the page immediately before the start of the content. Link the skip navigation text or image to that anchor. The link text or image ALT tag should be either "skip navigation" or "skip nav."

More Navigation Hints and Tips for Accessible Design.

Do Don't

Use clear navigation that is focused on user tasks.

Include repeated navigation links on every page to infrequently visited sections of the site or areas meant for only a small portion of your users (e.g., internal pages).

Why: More choices do not always mean better choices. Users need help narrowing choices in making fast decisions. While the form of navigation -- navigation bar, breadcrumb navigation, text navigation -- should be consistent throughout the site, it is preferable to change the navigation options to fit the particular function of the site page. A page directed at students may not need to include links to pages directed at faculty or staff.

How: Don't put a link to every page in your site on every page in your site. Help users navigate your site by creating navigation paths for different users -- students follow one path, instructors another, and administrators yet another. Then you need only include links to the start of each major "path" on each page.

Do Don't

Give users an indication of where they have been and where they can go in the site.

Override visited and unvisited link colors, so users are unsure which areas of the site they visited last, want to return to, or still need to view.

Why: As a site grows, it is important to help users find what they are looking for quickly. By differentiating between visited and unvisited links, you help the user quickly return to a desired section or narrow-down choices when looking for specific information.

How: Don't use style sheets to make all links look the same. Whenever possible, use the universally recognized colors: blue = unvisited link; violet/red = visited link.

Do Don't

Provide multiple entry and exit points into each page, so users can navigate the entire site without using the browser's navigation.

Break the BACK or HISTORY lists so users cannot return or jump back to a previously visited page. This includes using pop-up windows.

Why: Forcing users to use your own navigation system including a script created back button or frame navigation, reduces the functionality of the site and can be extremely disorienting. Users cannot bookmark pages to "jump" back to specific information and cannot "back out" of navigation when they have taken the wrong path.

How: Avoid frames whenever possible. Do not turn off browser navigation, such as the back button. Do not open pages in new windows.

Do Don't

Create custom Error 404 pages that direct users to helpful pages (e.g., site search or site map) when an incorrect or missing URL is entered.

Cause pages to refresh or redirect automatically.

Why: Generic Error 404 pages offer no help when users are looking for a specific page in your site. Automatic redirects break the history list and can cause continual loops when using the back button to return to the previously viewed page.

How: Create an Error 404 page with a link to your home page and site map and, if possible, include a search option on the page. Do not automatically direct users to moved pages: provide the new URL on the old page and ask users to use the new link.

Do Don't

Include a site map or table of contents for the site.

Stylize the site map or organize it using embedded tables and lists which may be difficult to navigate using assistive technology.

Why: Different users rely on different browsing strategies: some like to use the site search, others use the navigation menus, and others prefer a well-organized site map that conveys the "lay of the land" and offers both a text-based and visual interpretation of the sites organization.

How: Organize your site map using headers and lists. Avoid tables. Users who choose to navigate the site using the site map do not need/want the other elements on the site map page -- remove duplicate navigation menus and search boxes and make the site map page as clean and simple as possible.

Get more help with navigation, visit WAI's "13. Provide clear navigation mechanisms".

Return to index.

mwas standard Standard 16 -- Timed Response.
When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Examples:
16.1 -- Do not automatically forward, refresh, or otherwise alter pages, unless you provide the user with a method to adjust the timing of these content changes .

Timed Response -- Dos and Don'ts

Do Don't

Place a redirect message on pages that have moved or been deleted.

Automatically redirect users to the new URL of outdated pages.

Why: Automatically forwarding pages can be disorienting to users who do not have enough time to read the redirect message or who are trying to use their BACK or HISTORY buttons to return to a particular page.

How: Do not use the meta "refresh" or "redirect" element. Instead, put a link to the new location in the body of the page and direct users to activate the link.

Do Don't

If a script "expires" after so long due to inactivity or no response, give users an option to request more time.

Cause data to disappear or be deleted or cause pages to reload or refresh if a certain response is not given within a certain time frame.

Why: 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 she 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.

How: Sometimes, this technique is used for security reasons or to reduce the demands on the computer serving the web pages. 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.

Get more help with time responses, visit PENN State's "Redirects and Other Time Responses".

Return to index.

mwas standard Standard 17 -- Pop-up Windows.
Do not change the current window without informing the user .

Examples:
17.1 -- Do not cause pop-ups or other windows to appear (until typical user agents allow users to turn off spawned windows) .

Pop-up Windows -- Dos and Don'ts

See also: Standard 18 -- Links.

Do Don't

Use pop-up windows sparingly, if at all. Clearly identify links that open in a new window.

All links open in a new window.

Why: Links that open in new windows can be extremely disorienting to users of assistive technology. These links break the "BACK" and "HISTORY" list. Screen readers may or may not indicate a new window has opened, causing links to appear "dead" -- e.g., nothing appears to happen when the link is activated because new window opens without notice.

How: Carefully consider when to use links that open in new windows. Generally, there is little advantage to forcing users to keep your site in an open window unless you are certain they will need to return to your site after viewing other pages (e.g. when leaving a form to get more information on required inputs, users may then be expected to return to the form page without the form being reloaded and entered data being cleared). Identify any links that open in a new window using a referenced symbol or plain text.

Example:

Find out more information about this topic*.
Find out more information about this topic (opens in new window).
Note: Links with an asterisk open in a new window.

Get more help with pop-up windows (including a useful work-around), visit Sitepoint's "New-Window Links in a Standards-Compliant World" by Kevin Yank.

Return to index.

mwas standard Standard 18 -- Link Targets.
Clearly identify the target of each link. 

Examples:
18.1 -- Multiple links called the same thing (e.g., "more info . . . ", "results", or "click here") are problematic. .

Link Targets -- Dos and Don'ts

See also: Standard 17 -- Pop-up windows.

Do Don't

Create link text that makes sense out of context (e.g. "more information on topic A")

Use general or vague link text (e.g., "more," "click here," "next").

Why: Link text is frequently read out of context by users of assistive technology. So a link that reads "Click here for information on this exciting opportunity" in the body of the page, appears as only "Click here" in a link list. Multiple "Click here" phrases on a page makes the process even more confusing.

How: Choose link text that makes sense out of context and describes where the link leads.

Instead of: "Click here for more information,"

Try using "Get more information about us."

Or "Get more information about us."

Do Don't

Identify links with underlining.

Use underline on non-link text.

Why: For whatever reason, underlining has become the de facto symbol to identify a link among other text. When you override the automatic underlining of linked text, you force users to relearn how to surf the web: a process they won't appreciate.

How: For non-link text, use emphasis <em> [italics] or bold <strong> instead of underlining.

Do Don't

Distinguish between visited and unvisited links.

Make all links look alike.

Why: Designers often like to use style sheets or other methods to override the default colors of links. As long as you choose good contrast colors, this shouldn't be a problem. But be sure to keep the distinction between visited and unvisited links clear. Users rely on these color codes to help them return to previously visited pages and as a guide to exploring new sections of your site.

How: Make sure your style sheet designates distinct colors for any a:link or a:visited definition you use. If possible, follow the standard blue/violet configuration for unvisited/visited links. If using a different scheme, make sure it is clear to the user which is which. Some designers choose a more faded or muted color for visited links. Be sure whatever color/s you choose, they provide good contrast with the background color of your pages.

Do Don't

Clearly label links that lead to PDFs.

Have links that open PDF files without warning the user.

Why: Opening a PDF in a browser window requires the Adobe Reader plug-in. Users with low processor speed, slow internet connections, and older versions of Reader may not want to wait for your documents to download and open. Additionally, users of assistive technology need to know if another program will be opening and that the navigation will be changing.

How: Two common solutions: 1) add "PDF" to the link text: "Download booklet (pdf)." or 2) add a symbol to the link text to indicate PDF: "Download booklet+" Be sure to include a statement that explains the symbol means PDF and a link to the download page of the latest version of Adobe Reader: "Links with a plus symbol (+) open a PDF file and require Adobe Acrobat Reader to view."

Get more help with links, visit the WAI's techniques for WCAG 1.0 "6. Links".

Return to index.

mwas standard Standard 19 -- Alternate Versions.
An accessible mirror page (e.g. text-only or non-flash) with equivalent information or functionality, can be provided to make a web site comply with this policy, when compliance cannot be accomplished in any other way. The content of mirror pages must be updated whenever the primary page changes .

Examples:
19.1 -- A mirror page is acceptable when there is no other way to make the content accessible, or when it offers significant advantages for ease of navigation.
19.2 -- The content for primary and mirror pages should be updated simultaneously.  For example, using a common database to generate content for multiple versions of the site.
19.3 -- Instead of static alternative pages, set up server-side scripts that generate accessible versions of a page on demand.
19.4 -- Mirror pages must be the functionality equivalent to primary pages (e.g. provides alternatives for applets, scripts, plug-ns and similar applications that are not directly accessible).
19.5 -- "Text-only" and "accessible" are not synonymous; designers must incorporate all of the above standards when designing mirror pages.

Alternate Versions -- Dos and Don'ts

Do Don't

Offer alternate versions of particular pages that cannot otherwise be made accessible.

Assume that if one page can't be made accessible, the entire site must be offered as "text-only."

Why: Making as few pages as possible in duplicate formats (accessible and not accessible) increases the likelihood that all versions will remain up-to-date and helps insure all users have access to the same content.

How: When you have two versions (e.g. HTML and PDF) of a document, default to display the most accessible version first (HTML) and offer a link to the non-accessible version (PDF) from that page.

Do Don't

Offer an alternate version of the entire site ONLY when the site cannot otherwise be made accessible.

Plan on ignoring accessibility issues in the "real" version of the site and create an alternate "text-only" version to take care of all those "pesky" accessibility issues.

Why: In reality, very few sites cannot be made accessible with careful planning and knowledgeable designers. While certain aspects of the site may require alternate versions (e.g. text-based navigation or transcripts of animation or video content), the majority of a site can usually be made available to all users without redirecting a certain segment of users to what is often a sub-par version of the site.

How: Focus on making particular elements or segments of content accessible, rather than assuming you need to make an alternate version of the entire site.

Do Don't

Use databases or other programming methods to insure the alternative, accessible pages are updated concurrently with primary pages.

Update primary pages first then update alternative, accessible pages "as time allows" or "as soon as we can."

Why: Unless content from the primary page is directly tied to content of the alternative version, it is highly likely that the alternative version will become quickly outdated.

How: Web authors who decide to use an alternative version for accessibility must establish a method for insuring both versions are updated simultaneously. This is usually done by tying content to a database, where it can be updated once and updated information appears on both versions of the site.

Do Don't

Clearly identify the availability of an alternative version and make the alternate version easy to access.

Use scripting, Flash, or other non-accessible elements to identify and link to alternative versions of the site.

Why: Some well-intentioned web authors create an alternative version of the site, but then make the link to this "text-only" site using Flash or other methods that essentially make the alternate version inaccessible.

How: The alternate version should be clearly marked and easy to get to. Use a plain-text link and put it as close to the top of the page as possible.

Do Don't

Avoid PDFs if possible or provide both PDF and other accessible format.

Require PDF capabilities to reach the majority of your site content.

Why: While generally simple to make in its non-accessible version, creating accessible PDFs requires a lot of forethought and careful planning. Most PDFs offer only limited access to the text in the file; often including inaccessible tables, graphs, and images. If your site is going to rely on PDF for information, you must use highly-skilled designers who create the original documents with accessibility in mind BEFORE converting to PDF.

How: If you want to use PDF to control formatting for printing, offer the document in an alternate accessible format and link to the PDF version. Be sure to warn users of any links that open a PDF document.

Get more help with alternate versions, read WebAIM's article "Do Accessible Web Sites Have to be Boring?"

Return to index.

Best Practice icon Best Practices
Although not required by the OSU Minimum Web Accessibility Standards, following these guidelines will add additional functionality and usability for all users, including users of assistive technology.

Best Practices -- Page Header Information.

Do Don't

Give every page a descriptive title that indicates the page contents.

Use cryptic or general page titles (e.g. "cr751s1Ap4" or "home page")

Why: Titles are used in window title bars, bookmark lists, and results from searches. The title appears in the window of the browser and is also used in tracking the HISTORY (BACK button) of where the user has been. It can be particularly helpful when a user has multiple windows open, if it uniquely identifies each page.

How: The title should ideally be less than 64 characters in length. That is, many applications will display document titles in window titles, menus, etc where there is only limited room. Whilst there is no limit on the length of a title (as it may be automatically generated from other data), it may be truncated if long.

Do Don't

Identify the language of the document and any changes in that language.

Assume your users' language is English.

Why: The language declaration may: assist search engines, assist speech synthesizers, help a browser choose special characters, help a browser make decisions about hyphenation and spacing, and assist spelling and grammar checkers.

How: The LANG attribute is part of the HTML element and uses the two-letter primary language-code. Example: <html lang="en"> Some other codes include: FR (French), de (German), it (Italian), e's (Spanish), hz (Chinese), and jab (Japanese). You can specify a change in language using the DIV element: <div lang="far">Bon Jour!</div>

Do Don't

Include meta data (keywords and summary) for better searching.

Use the same keywords and summary for every page in your site.

Why: Meta-data helps search engines find related pages faster and insures better, more accurate searching. The OSU search engine uses meta keywords and descriptions to prioritize hits in search results.

For more on the uses of META tags, visit the META Tag Tutorial from webdeveloper.com

How: Place META tags between the HEAD tags in your HTML documents.

For page summary/descriptions: <meta name="description" content="description of page goes here.">

For keywords: <meta name="keywords" content="searchterm1, searchterm2, searchterm3">

Get more help with page header information, visit WAI's "The Global Structure of an HTML Document".

Return to index.

Best Practices -- Relative Sizing.

Do Don't

Use relatively size font definitions (e.g., font-size="medium" or font-size="1em").

Use definite font sizes (e.g., font-size = "14 point").

Why: Relatively sized fonts transform gracefully regardless of the default font size the user sets the browser to display. Thus, a user who sets the default size to 24 points still sees your headers as larger than the body of the page. If you set a specific font size, your selections may override the user definitions making your page unreadable to those with visual impairments.

How: Create a style sheet that defines font sizes using a relative definition. Recommended: use the "M" (written as "em"); a typesetter value based on the largest letter in the alphabet (along with "W"). The WAC site sets our paragraph text to 1em and our largest header to 2ems with a range of sizes in between to denote "levels" of organization.

Do Don't

Use relatively sized tables (e.g. width="85%").

Format layout tables to a fit a specific resolution (e.g., width="800").

Why: Setting tables to fit lower resolutions means wasted space on user screens. Setting tables to fit higher resolutions causes users to scroll left-right as well as up-down. Using relatively sized tables allows the table to transform gracefully regardless of screen resolution or window size.

How: Express all table widths as a percentage rather than a pixel size. Avoid specifying a table height -- allow content to determine height.

Get more help with relative sizing, visit "CSS Design: Size Matters," by Todd Fahrner.

Return to index.

Best Practices -- Code.

Do Don't

Include a DOCTYPE statement on every page and validate your code to the specified code grammar.

Include the wrong DOCTYPE or use elements and attributes not supported by the grammar you specify.

Why: Writing the "cleanest" code possible should ensure your pages will look best across the widest range of web display technology. Adhering to a specific grammar helps insure browsers will interpret your code correctly.

How: Choose a code standard (HTML 4.01 strict, HTML 4.01 transitional, XHTML 1.0 transitional, etc.) and stick to it. Define your preferences in your web editor to follow the rules of that standard. Identify that standard on each page using the correct DOCTYPE statement. Validate your code to insure you are following the rules of standard you have chosen.

Do Don't

Use ABBR and ACRONYM to identify abbreviated text.

Rely on ABBR and ACRONYM to describe abbreviations (also include the description the first time you use the abbreviation or acronym).

Why: The ABBR and ACRONYM elements help screen-readers interpret abbreviations and acronyms. They may also provide browser users with additional information. However, they should not be relied upon to convey the explanation of the shortened term.

How: ABBR is used for standard abbreviations that are intended to be spoken as abbreviations (e.g., I.R.S.) or as the full term (e.g., Univ., spoken as "university"). ACRONYM is used when the abbreviation is spoken as a word (e.g. PETA, spoken as "Peetah" rather than as individual letters: P, E, T, A.).

Do Don't

Use style sheets for formatting.

Use deprecated code elements, including FONT, CENTER, B, I, and U.

Why: Using style sheets for formatting helps insure that users can override your style choices when necessary and customize colors, font size, and resolution as desired. Deprecated code elements, like the FONT tag, are more likely to block users from overriding your formatting selections.

How: Rather than using the FONT tag, redefine how HTML elements like P, H1, UL and others appear on your pages using Cascading Style Sheets. Then, turn-off style sheets in your browser and test your pages. Can you still understand all the content on the page? If so, you are using style sheets correctly. You might also consider offering your users a selection of style sheets to render your pages in larger text, higher contrast, or with reduced graphics.

Do Don't

Use BLOCKQUOTE to identify quoted text.

Use BLOCKQUOTE for indenting.

Why: The BLOCKQUOTE element has special functionality in screen readers and text surrounded by BLOCKQUOTE is often read in a different voice or set-off with "quote" and "end quote." Using BLOCKQUOTE incorrectly can be confusing.

How: Identify quoted text by enclosing it in the BLOCKQUOTE tag. Do not use the tag for indenting. Instead, create an "indent" style in your style sheet.

Get more help with using code correctly, review the Web Design Group's "HTML 4.o Deprecated Features".

backBack Nextnext

Top of Page || Return to Index
view this document in PDF. View/Print in PDF format. (Acrobat Reader required.)
Ohio State University