Old Interim Technical Guidelines

Use equivalent descriptive alt attributes on all images and animations. One special case: use a null alt attribute for decorative images, or in better practice, specify the decorative image as a background image using Cascading Style Sheets (CSS).

• Michigan State Logo example: alt="logo Michigan State University"
• Beaumont Tower example: alt="MSU Beaumont Tower in the spring"
• Decorative Image example: alt="" (null alt text)

Graphs and charts should use longdesc as a text alternative or provide a summary in text format. The longdesc attribute is a fuller explanation of an image, graph, etc., that is too long to be provided in the context of an alt attribute.

Source: Section 508 (a), WCAG 1.1

Ensure that all information conveyed with color is also available without color, for example, from context or markup.

Source: Section 508(c), WCAG 2.1

Some users will turn off stylesheets or use their own because of specific visual requirements. It is essential to develop an HTML page that is readable and allows for easy navigation when stylesheets are turned off.

Source: Section 508(d), WCAG 6.1

Design pages to avoid causing the screen to flicker with a frequency greater than twice per second. A flickering or flashing screen can be extremely confusing and distracting for those with developmental disabilities or head trauma, and can cause seizures in some users, such as those with photosensitive epilepsy.

Source: Section 508(j), WCAG 7.1

A text-only page is a “last resort” option, and not the first choice for providing accessible content. Many people with disabilities do not find text-only pages desirable because content is often not kept current or equivalent to the graphic site.

Source: Section 508(k)

Provide a way for users to skip over groups of links, such as links in the navigation bar. Assistive technology, such as a screen reader, will unnecessarily read links in repetitive groups on every page unless the user is given the option to skip link groupings and go directly to content.

Example:
<a href=”#content”>Skip navigation</a>
[ Some list of repetitive navigation ]

Source: Section 508(o), WCAG 13.6

When a timed response is required, alert the user and give sufficient time for the user to indicate that more time is required.

Source: Section 508(p)

When mixing languages in a sentence or paragraph, notate the change within the markup.

Example: My Spanish friend then said,<span lang=”sp”>“¡Te Extraño Mucho!”</span>

Source: WCAG 4.1

Developers must ensure that alternative or static content is updated when dynamic content changes so that persons using assistive technology have access to current information.

Source: WCAG 6.2

Simple and clear writing benefits users with cognitive disabilities and will enhance both the accessibility and usability of your website.

Note: This guideline is not intended to affect the intellectual content or quality of University Web pages used to conduct core University business or academic activities. It is expected that a research university will use language in academic content (such as course materials, research and personal scholarship) which requires a higher level of reading comprehension. Use of such language in these contexts will not be interpreted as noncompliance with the Policy's accessibility requirements.

Source: WCAG 14.1

When data needs to be presented in a tabular format, use the table element and its supporting elements and attributes.

Example:
<table>
<thead><tr>
<th>Date</th>
<th>Name</th>
<th>Age</th>
</tr></thead>
[ Tabular data in appropriate markup ]

Source: Section 508(g), WCAG 5.1

For "complex" tables, i.e., where tables have structural divisions beyond those implicit in the rows and columns, use appropriate markup to identify those divisions.

Source: Section 508(h), WCAG 5.2

It is recommended that you avoid using frames whenever possible, since frames can complicate navigation and presentation. If you choose to use frames, however, all frames should have a meaningful frame title and title attribute (not just frame1/frame2). Explain what the frame is doing or contains so the visitor has some concept of what they will find in the frame.

Example:
<frameset cols="10%, 90%"
title="Our library of electronic documents">
<framesrc="nav.html" title="Navigation bar">
<framesrc="doc.html" title="Documents">
</frameset>


Source: Section 508(i), WCAG 12.1

Every input field in a form should have an informative label, but not all labels have to be visible (such as a label for a submit button).

Learn more: WAI - Input label coding examples

Source: Section 508 (n), WCAG 10.2 and 12.4

All scripts, plug-ins, and applets must work properly with assistive technology. If a technical means of supplying the information or service online is not possible, provide contact information so the visitor can get the information off-line.

Source: WCAG 6.3 (modified to reflect pending changes in WCAG 2.0)

When a Web page requires 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 accessible plug-in or applet.

Source: Section 508(m)

All image map hot spots should have an alt attribute. Like other links, this allows the visitor know where they will go when they click on the link. There should also be a text-alternative for any image map links that are used.

Example:
<map name="top-bar">
<area shape="rect" coords="91,30 186,98" href="http://www.msu.edu" alt="MSU Home Page" />
</map>

Source: WCAG 1.1

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

Source: Section 508(c), WCAG 1.2)

Image maps present large accessibility obstacles, but their use is necessary in some cases. Instead of using server-side image maps, use a client-side image map. If this is not possible, provide a textual alternative.

Source: Section 508(f), WCAG 9.1

Some information in video and multimedia is not available from the main soundtrack. Such content should be provided in an open or closed audio description.

Source: WCAG 1.3

Captions should be available at approximately the same time as associated audio and should be equivalent to the spoken word. Transcripts differ from captions in that they do not need to be verbatim—they can and should include additional information that makes them more beneficial. It is also important for the visitor to be able to easily resize the text of transcripts and captions.

Source: Section 508(b), WCAG 1.4

Documents are formatted so they include paragraph headings, meaningful link phrases, alternative text for images, charts and graphs, and table headers.

Source: MSU Web Style Guide

Web pages should be designed to look and function consistently on various hardware, software, and browsers commonly used to view the site.

For current browser standards, see http://www.msu.edu/webstyle/browser-standards.html

Documents that are created using published formal grammars will be supported by more browsers and assistive technologies.

Many accessibility features of assistive technology, accessible Web technology, and Web browsers rely on published formal grammars. Failing to work to a formal published grammar may make a Web page directly inaccessible or inaccessible to assistive technologies like screen readers, Braille devices, etc. Writing code which validates to formal grammars also facilitates indexing tools, search engines, programs that extract tables to databases, navigation tools that use header elements and automatic text translation software.

Source: WCAG 3.2, NDA

A ‘!DOCTYPE’ statement (document type declaration) should be at the beginning of all HTML pages. This statement can be used by automated validators to know which version of HTML/XHTML to validate to.

Source: WCAG 3.2, "A List Apart - Fix your site with the right !DOCTYPE"

Items that change or move on a page can cause distractions and often annoyance for most people. For some people, the distraction of animation can completely prevent them from concentrating on the important information. Strobing, blinking, flashing and flickering can cause seizures in sensitive people (e.g. people with photo-sensitive epilepsy).

Source: WCAG 7.2, NDA

An automatic refresh is disorienting to some users. If using meta-refresh to redirect users to another page, substitute it with server redirects. If server redirects are not possible, a meta-refresh with zero seconds is permissible.

Source: WCAG 7.4

Automatically redirecting to a new page can be very confusing and frustrating for users who may not be overly familiar with computers and using the Web. Many people find auto-direct pages highly confusing because they take control of navigation away from users, who can quickly become disoriented and fail to grasp the structure of a site.

Source: WCAG 7.5, NDA

If non-W3C technologies are used, the user may be required to download or use plug-ins or stand-alone applications which are not always accessible. Also, W3C technologies are continually reviewed for accessibility. By using a W3C technology, you are more likely to embed accessibility in your Website.

Source: WCAG 11.1, 11.2, NDA

Good quality metadata improves usability of search facilities by providing useful and accurate keywords and descriptions of content and media types. The descriptions and summaries of page contents displayed in search results are often drawn from metadata which is inserted in Web pages.

Source: WCAG 13.2, NDA

Failure to provide a warning to visitors can cause confusion or disorientation. If you must use a pop-up window, announce that the link will open a new window and ensure that the pop-up has a close-window option.

Source: WCAG 10.1

When linking to a PDF file, announce to visitors beforehand that the link is pointing to a PDF document. This can be done with text or by using freely-available PDF icons.

Source: Best Practices

Each frame should have a title, even though this is not displayed visually. If the titles of frames used to present a Web page do not clearly explain the structural order or relationship between them and the nature of their contents, this information should be provided elsewhere. When these users open a page with frames, they are presented with a list of the frames that make up the page. The list shows the frame titles. The user must then navigate each frame individually, a frustrating task if the frame titles are confusing.

Source: WCAG 12.2, NDA

Link text should make it obvious where the link will take a user. Do not use "click here" as the text for a link. "Click here" does not tell a visitor where "here" is.

Example:
“Conference registration” instead of “To register, click here”

Source: WCAG 13.1

The first word or phrase in a link should not be repeated in other links. Multiple links that point to the same page are an exception, in which case they should use the same link text. This guideline will help to facilitate the quick scanning of links.

Source: Theofanos and Redish

Visited links should have a noticeably different color than non-visited links. This enhanced navigation will give users a clear picture of where they have and have not been on your site. Consider using the default visited link color.

Source: Theofanos and Redish

Not all users seek information the same way. Providing alternative means of displaying site content, like a site map, will alleviate some navigation problems.

Source: WCAG 13.3

There should be sufficient contrast between foreground and background colors on a page. Individuals with visual disabilities may have difficulty distinguishing text when the background and foreground colors are too much alike.

Source: WCAG 2.2

Only use the blockquote element to denote a quotation and not as an indent. The blockquote element will be spoken differently by a screen reader. Instead, use CSS classes to style an indent.

Source: WCAG 2.7

Conveying textual information via images is problematic for visitors who want to change their default text size. Images do not expand when browser text size is increased, and a visitor with visual disabilities may not be able to read any text contained within images.

Source: WCAG 3.1

Ems, percentage, and other relative-size units will allow for the most flexibility for resizing by the visitor, particularly those with low vision.

Source: WCAG 3.4

Screen readers apply a different tone of voice when reading heading elements than with regular text. Heading elements also give a sense of structure to a page and should be ordered by importance (with h1 the most important).

Example:
<h1>Page Title</h1>
<h2>Section 1 Title</h2>
<h3>Section 1.1 Title</h3>
<h2>Section 2 Title</h2>
[ Additional markup ]

Source: WCAG 3.5

Bulleted and numbered lists help readability. Solid text can be broken up into smaller and more manageable pieces by bulleted or numbered lists. This also creates white space that "frames" smaller pieces of text.

Source: WCAG 3.6

Use abbr and acronym elements to expand abbreviations and acronyms when they first occur. This may explain abbreviations and acronyms that a visitor is not familiar with, or clarify an acronym that has multiple meanings.

Example:
<abbr title=”Anonymous”>Anon.</abbr>
<acronym title=”Hewlett Packard”>HP</acronym>


Source: WCAG 4.2

People are generally uncomfortable with reading large tracts of text on screen and tend to skim through content by scanning headings, subheadings, lists, etc. This is easier to do if the content has been broken down in to easily digestible chunks.

Source: WCAG 12.3, NDA

Use consistent markup and structure throughout the site. Coding inconsistencies can confuse both technology and site visitors.

Source: WCAG 13.4

If the page is long, either break it into multiple pages or use anchor links to easily navigate to different sections within the page. Ensure fluid navigation for your visitors between anchor links and pages.

Source: MSU Web Accessibility

Long strings of text can be hard to read. Keep lines of text to around 70 or 80 characters long (10-15 words).

MSU Web Accessibility

The screen reader will read the table columns and rows aloud. This is very distracting to a visitor with visual disabilities, because the browser has to read unnecessary code, thus slowing down response time. Instead, using a div-based layout in combination with CSS.

Source: WCAG 3.3

Ensure that tables will be sensible when read in a linear fashion, e.g. when style sheets are turned off. It is not recommended that tables be used for layout purposes (use div instead), but if used, the summary attribute for the table should be set to null.

Source: WCAG 5.3

Do not define information contained in table cells as structural elements purely to achieve a visual effect if the table is used to control the layout a page. Defining the text content of a table cell as a column heading so it displays as bold text is an example of misusing structural mark-up to achieve a visual effect. If content items are incorrectly identified as structural elements in the underlying HTML, the page structure will not make sense when it is presented by a text only browser or screen reader.

Source: WCAG 5.4, NDA

Data tables should include summary and caption attributes. Table summary attributes are analogous to image alt attributes - they describe a table's content. Screen readers make this information available to visitors with visual disabilities.

Source: WCAG 5.5

It is good practice to position labels so the visual relationship with corresponding form controls is clear. However, some assistive technologies, like screen readers, can only read left to right and unless form labels are positioned carefully, they will fail to read the form in a meaningful way.

Source: WCAG 10.2, NDA

It is good practice to position labels so the visual relationship with corresponding form controls is clear. However, if the relationship between labels and form controls is not explicitly defined in the underlying HTML, older browsers or assistive technologies may fail to accurately present the form.

Source: WCAG 12.4, NDA

A screen reader will skip from input field to input field and users could miss important content.

Source: Theofanos and Redish

If an applet (created with either OBJECT or APPLET) requires user interaction (e.g., the ability to manipulate a physics experiment) that cannot be duplicated in an alternative format, make the applet directly accessible.

The accessibility of objects with their own interface is independent of the accessibility of the user agent. Accessibility must therefore be built into the objects or an alternative must be provided. Programmers should be aware of the resources available to help ensure that programs are accessible.

Source: WCAG 6.4, 8.1, 9.2

Dynamic content is information on the page which is updated in real time. For example, breaking news which is uploaded "live" from a dynamic database in real time. If a Web page contains dynamic information, then the dynamic content should be delivered in a way that makes it accessible. Failing that, users should be provided with a means to navigate to another page where the same information is presented in an accessible format.

Source: WCAG 6.5

Content that moves continuously is distracting and annoying for most users. Users who read visually often hide animations or moving text from view by covering it with their hands, a piece of paper or by scrolling the page so it can't be seen. Screen reader users find moving content difficult or impossible to use because screen readers do not cope with content that changes continually within the browser window.

Source: WCAG 7.3, NDA

An event handler is a script that is invoked when a certain event occurs (e.g, the mouse moves, a key is pressed, the document is loaded, etc.). Interfaces which do not provide flexibility in the type of device which the user relies on to input information are inherently inaccessible. Screen reader users rely entirely on the keyboard for interacting with Websites. Failing to support the keyboard as an input device will make the site unusable to them. Other users may use voice input for hands-free operation in a busy office, or if they have dexterity limitations.

Source: WCAG 9.3, NDA