Old Interim Technical Guidelines
* This page contains the original Interim Technical Guidelines (in force from 2008 through 2014), which have been superseded by the current Technical Guidelines. This content is provided for historical reference only. *
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:
- Section I. Required Checkpoints
- Section II. Recommended Checkpoints
- Section III. Recommendations on Documenting Web Page Accessibility on a Site
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:
- 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.
- Supply the same or equally effective benefits, services, and programs for all users of the Web-based environment.
- Use electronic and information technologies that allow all Web users to have comparable access to and use of information and data.
- Provide all members of the public seeking information or services the same access to and use of information and data.
- 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.