Web Accessibility at
Michigan State University
Web Accessibility at
Michigan State University
Michigan State University is committed to providing accessible, usable, and aesthetically pleasing design of its Web pages1. The University strives to employ principles of Universal Design2 and use these Interim Web Accessibility Technical Guidelines (Guidelines) in the design, implementation, enhancement, and replacement of Web pages. In doing so, MSU aims to improve access to current and emerging technologies.
These Guidelines are meant to help developers reach everyone in the intended audiences regardless of ability or use of assistive technology. Visitors may have a variety of disabilities such as low vision, cognitive disabilities, or motor disabilities, and may use assistive technologies to augment their use of the Web. Satisfying the Guidelines in this document will improve access to Web documents for everyone, and, for some, remove significant barriers to Web documents more readily accessed by others.
Guidelines are broken into three groups:
The MSU policy on Web accessibility applies to all University Web pages used to conduct core University business or academic activities. This policy does not apply to Web pages published by students, employees, or non-university organizations that are hosted by the University but are not used to conduct core University business or academic activities3. All new and redesigned University Web pages published after May 15, 2009 must be in compliance with Section I of these Guidelines, unless granted an exception under Article IV of the policy. University Web pages published before May 15, 2009 must assess compliance with Section I of these Guidelines and submit a Web Accessibility Review Form to the Office for Inclusion and Intercultural Initiatives by May 15, 2009. Voluntary adoption of Section I of these Guidelines is encouraged for all other Web pages not covered by the policy.
Beyond the minimum requirements outlined in Section I, the University recommends adoption of the recommendations listed in Section II for all University Web pages, to maximize access for a broader audience and facilitate a wider range of user needs.
Documenting compliance with the MSU policy on Web accessibility is one of the final steps taken by Web developers and content producers as they implement the policy’s requirements. However, it is a voluntary action - indicating that a Web page is compliant is not required. If Web developers and content producers choose to denote compliance to external standards, they should consider following the recommendation contained in Section III.
MSU Web pages must do the following to provide equal access to information, materials, programs, and services for all users regardless of ability:
The University’s Technical Guidelines were developed using the U.S. Access Board’s Section 508 standards supplemented by the Web Content Accessibility Guidelines, developed by World Wide Web Consortium (W3C), as a benchmark for access to Web-based content and services.
Evaluation and validation tools check the source code of a document for required elements and the correct structure of the HTML. Use of validators to evaluate page accessibility requires the selection of a standard or guideline to generate a review. Developers should select WCAG 1.0 Level A and Section 508 as the standards which most closely conform to the technical requirements contained in Section I of the Guidelines. Developers should select WCAG 1.0 Level AA and Section 508 as the standards which most closely conform to the technical recommendations contained in Section II of the Guidelines. While automated tools are quick and convenient, they cannot identify all issues. Human review is often necessary to ensure complete clarity and ease of navigation.
While automated tools are quick and convenient, they cannot identify all issues. Human review is also necessary to ensure site comprehension and ease of navigation. The Usability & Accessibility Center (UAC) has created a protocol to guide you through the process, which can be found at http://webaccess.msu.edu. The following criteria mirror the checklist found on the Web Accessibility Review Form.
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).
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
Beyond the minimum requirements outlined in Section I, the University recommends adoption of the following recommendations for all University Web pages, to maximize access for a broader audience and facilitate a wider range of user needs.
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
Documenting compliance with the MSU policy on Web accessibility is one of the final steps taken by Web developers and content producers as they implement the policy’s requirements. However, it is a voluntary action - indicating that a Web page is compliant is not required. If Web developers and content producers choose to denote compliance to external standards, they should consider following this recommendation.
When developing to industry standards defined by the World Wide Web Consortium (W3C), such as XHTML 1.1 Transitional and WCAG 1.0, compliance will ideally be denoted on each page. That is, a particular page should only claim that it meets a Web standard if it actually does. However, this is not always practical as modern Web sites tend to be developed using templates that lock content common to multiple pages, like a footer. If developers indicate compliance in a footer common to all pages, they may be claiming compliance for pages that, for whatever reason, are not compliant. Additionally, continuing maintenance of these links will be an annoying task that developers may come to resent.
Therefore, rather than indicating compliance in the footer, it is recommended that Web developers and content producers include compliance information in a common location on the site, using language that does not promise site-wide compliance. Two possible locations for this information include: (1) a site accessibility page, and (2) an “About This Site” page. The MSU Web Team uses both pages to denote compliance with the MSU policy on Web accessibility on www.msu.edu.
An accessibility page should be designed for users with disabilities, to identify accessibility features used throughout the site that will aid them in navigation. Though the target audience for this kind of page is the visitor with disabilities, others will find the information helpful as well.
For an example of how to construct such a page, see “Accessibility of This Site” at http://www.msu.edu/accessibility.html. The www.msu.edu accessibility page demonstrates how to document contact information, general accessibility information and use of accessibility standards and guidelines.
An accessibility page can include a list of the standards and guidelines employed during site development. For instance, a site can state that it was developed to conform to the XHTML 1.0 Strict, Cascading Style Sheets (Level 2), Web Content Accessibility Guidelines (WCAG 1.0 Level AA) and Section 508 of the U.S. Rehabilitation Act. This informs the user that these standards were taken into account throughout the site. However, this method should not be used to verify that all pages in the site are accessible. Claims of accessibility can only be made on a page-by-page basis.
Sample text
We have endeavored to make this Web site accessible to a broad range of users, compliant with the Section I of the Interim Technical Guidelines associated with the MSU policy on Web Accessibility, and compatible with screen readers as well as other assistive technologies. However, this is an ongoing process and it is possible that some users may encounter problems. If you have trouble accessing or using a page, please contact us by e-mail at contact@msu.edu or by calling (517) 432-6200.
An “About This Site” page provides another opportunity for Web developers to state Web standards used in the development process.
Again, this page should not be used to verify that all pages in a site meet particular standards or are accessible.
Sample text
This Web site was developed using industry standards defined by the World Wide Web Consortium and Section 508.
- XHTML 1.0 Transitional
- CSS 2.0
- Section 508
- WCAG 1.0 Level A
In addition, by developing the site to meet the accessibility requirements described by WCAG 1.0 Level AA, this site follows the recommendations in the the MSU policy on Web Accessibility to exceed the minimum requirements for making a site accessible.
We have endeavored to make this Web site accessible to a broad range of users, compliant with the the MSU policy on Web accessibility, and compatible with screen readers as well as other assistive technologies. However, this is an ongoing process and it is possible that some users may encounter problems. If you have trouble accessing or using a page, please contact us by e-mail at contact@msu.edu or by calling (517) 432-6200.
If for some reason it is important that the site denote accessibility by using industry standards links or logos, those links or logos should denote compliance on a page-by-page basis.
1 - Reference to “Web pages” in this policy covers both Web pages and Web sites, including their design and any Web-delivered content or service.
2 - "Universal Design" refers to the design of products in such a way that they are useable by all regardless of ability. Universal Design supports the use of emerging technologies, use in different environments, use by people with different learning styles or literacy levels, and multi-lingual usage.
3 - Web pages that conduct core University business and academic activities include those Web pages that students, employees, or visitors must access in order to effectively participate in a program, service, or activity offered by the University. Examples of core academic activities include admissions, registration, advising, and academic course work. Examples of core business activities include business services or personnel activities of Human Resources, Controllers Office, Department of Intercollegiate Athletics, Wharton Center, or other University services frequently used by employees or visitors.