Skip to main content
Michigan State University

Web Accessibility Interim Technical Guidelines

Purpose

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.

Section I. Required Checkpoints

Basic Principles

MSU Web pages must do the following to provide equal access to information, materials, programs, and services for all users regardless of ability:

  1. Establish eligibility criteria for technology and Web-based services or participation in programs and activities that will not screen out or tend to screen out qualified individuals with disabilities, unless such limitations are necessary to meet the essential objectives of the program.
  2. Supply the same or equally effective benefits, services, and programs for all users of the Web-based environment.
  3. Use electronic and information technologies that allow all Web users to have comparable access to and use of information and data.
  4. Provide all members of the public seeking information or services the same access to and use of information and data.
  5. Provide alternative programs and services of the World Wide Web for qualified individuals with disabilities only where the alternatives are necessary to make the programs and services equally as effective as those provided to other users.

Validation and Conformance

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.

General

Images containing content are described by meaningful alt and longdesc (as needed) attributes

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

Content is understandable without the use of color

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

Page content is read in the correct order without style sheets

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

There are no flickering images in the site

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

An alternative text-only page is provided if the Web page cannot be made accessible

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)

A "Skip to Main Content" link is provided at the top of each Web page

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

Users are notified of and can delay an impending timeout

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)

Changes in content language are indicated by HTML code

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

Alternative (static) content is updated when dynamic content changes

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

Clear and simple language is used throughout the site

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

Tables

Row and column headers are identified in data tables

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

Data tables with two or more levels of headers contain markup to associate data cells and header cells

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

Frames

Frames have meaningful titles

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

Forms

Forms work properly and can be completed successfully using assistive technology

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

Applets, Plug-ins, and Scripts

Java, JavaScript and other active features work with assistive technology

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)

Links are provided to download plug-ins or applets if they are required to use the site

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)

Image Maps

Client-side image maps have alt attributes

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

Text links are provided if a server-side image map is necessary

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

Source: Section 508(c), WCAG 1.2)

Client-side image maps are used instead of server-side image maps

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

Multimedia

Supplementary audio information is provided for video and multimedia presentations

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

Synchronized captioning is provided for video and audio presentations

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

Section II. Recommended Checkpoints

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.

General

Documents contained in Web site are formatted to be accessible

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

Testing has been done to ensure cross-browser/cross-platform compatibility

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

Site validates to XHTML 1.0 Transitional and CSS 2 protocols

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

!DOCTYPE is included on all Web pages

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"

Web content does not blink

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

Web pages either do not refresh automatically or can be controlled by user

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

Web pages do not redirect automatically or can be controlled by user

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

Current W3C specifications and methodologies are followed

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

Meta-data includes page description and keywords

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

Navigation

User is informed when his/her action will cause a new page or popup window to appear

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

User is notified when link connects to a PDF file

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

Frames include information about their purpose and relationships (as needed)

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 makes sense out of context.

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

Text is not repeated for different links

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 are differentiated from non-visited links

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

Web site has a site map

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

Presentation and Content

There is sufficient contrast between foreground (text) and background colors

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

Blockquote attribute is used for quotations and not indentation

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

CSS is used to format text

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

Relative units are used for sizing and positioning Web site content

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

Header elements are used to convey document structure

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

Related items and sub-navigation links are contained in lists

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

Abbr and acronym elements are used

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

Large chunks of information are divided into more manageable groups

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

Navigation, page structure, presentation and coding are consistent throughout site

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

Source: WCAG 13.4

Style of Writing

Pages are organized to enhance comprehension and navigation

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

Sentences are short, to the point and consistently structured

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

Tables

CSS is used for page layout and presentation

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

Tables make sense with style sheets turned off

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

Tables are not formatted using structural markup

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 contain summary and caption attributes

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

Forms

Labels precede input fields; labels follow checkboxes and radio buttons

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

Labels are explicitly associated with form controls

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

Important information is not contained between input fields

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

Source: Theofanos and Redish

Applets & Scripts

Web site is fully functional using only the keyboard

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 accessible or provided in an alternative, accessible format

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 is not animated on site or can be controlled by user

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

Event handlers are coded to be device-independent

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

Section III. Recommendation on Documenting Web Page Accessibility on a Site

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.

Do not make a site-wide claim of accessibility or standards compliance

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.

Accessibility page

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.

About This Site page

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.

Compliance Links and Logos

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.

References

  • "Accessible Web Sites: Why They're Important and Where to Begin" by Charmane K. Corcoran and Shawn D. Corcoran, About Campus Journal of the American College Personnel Association (ACPA). March-April 2002/Vol 7, No. 1.
  • An Accessibility Frontier: Cognitive disabilities and learning difficulties; By Roger Hudson, Russ Weakley and Peter Firminger. Most recent version of article: 30 January 2005 Originally presented at OZeWAI 2004 Conference, La Trobe University, Melbourne, Australia - 2 December 2004.
  • MSU Web Accessibility Guidelines
  • MSU Web Style Guide
  • accessIT, National Disability Authority (NDA)
  • Section 508 Standards for Web
  • W3C Web Content Accessibility Guidelines 1.0

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.