Web Accessibility at
Michigan State University
Web Accessibility at
Michigan State University
As you navigate the Michigan State University campus, you may notice ways that the university assists people with disabilities. You’ll encounter ramps and automated doors to make it easier for people who use wheelchairs to move about. At major crosswalks you’ll hear automated voices announcing when it is safe to cross in order to assist people who have visual impairments.
Just as these accommodations help people with disabilities navigate the physical world, similar assistive (or adaptive) technologies help people navigate the world of computers and the Web. These technologies assist people who have visual, hearing, mobility, and/or cognitive impairments.
A number of assistive tools have been developed. For blind or visually impaired people, there is software that reads text out loud (screen readers) and there is software that acts as a magnifying glass on the screen. For people with mobility issues, there are alternatives to the mouse and standard keyboards.
People and institutions have come to rely on the Web as an indispensible part of daily life. Just as our Web sites need to work well with popular Web browsers such as Internet Explorer or Firefox, they also should work well with assistive technologies so that all of our users can access the content, regardless of ability.
Since the dawn of the Web era in 1993, awareness of the need for Web sites to be accessible has grown. States and nations have passed laws requiring Web accessibility, and the global Web community has defined standards.
The World Wide Web Consortium (W3C) is the leading international organization dedicated to promoting the development of the Web. The W3C’s Web Accessibility Initiative (WAI) publishes a standard known as Web Content Accessibility Guidelines (WCAG). The currently approved version of the standard is WCAG 1.0.
The WCAG defines a set of “checkpoints” you should examine to ensure that your site is accessible. Priority 1 is a basic requirement that must be satisfied for some groups to be able to use the Web. Priority 2 should be satisfied to remove significant barriers to access and reduce difficulty of one or more groups in accessing information. Priority 3 may have checkpoint elements satisfied to improve access to Web documents and remove additional barriers not addressed by other checkpoints. If your Web site does not meet Priority 1 checks, it may be unusable to some users.
MSU considers it good practice to follow the standards described in Section 508 of the Rehabilitation Act of America. Section 508 applies specifically to federal agencies and entities receiving federal monies. Section 508 standards are often used to resolve court cases brought based on the Americans with Disabilities Act (ADA) and Section 504. For more information, see: http://section508.gov.
Many institutions, including universities, develop policies that may require compliance with WCAG and/or Section 508.
See the MSU Web Accessibility Policy for its statement on conformance with accessibility standards.
There are three basic approaches for evaluating and validating the accessibility of new or existing Web sites:
In many cases a combination of these approaches will be employed. For instance, expert evaluators often use automated tools to flag areas that merit manual inspection and interpretation.
A good way to understand accessibility validation tools is to test your own Web site using a tool called Wave. Developed by an accessibility consultancy called WebAIM, the Web Accessibility Evaluation tool flags potential accessibility issues graphically in the context of each page it tests. For instance, following is a WAVE report on MSU’s main home page, www.msu.edu:
WAVE report on www.msu.edu. Although the page is not rendered perfectly, you can see items flagged for manual inspection in context.
Even if you are not trained in Web accessibility, you can gain an understanding of the issues involved by trying WAVE on your own Web site. Simply visit http://wave.webaim.org and enter the URL of a page you want to test.
It is preferable to design and build sites to be accessible from the start, rather than waiting until the end of a project and trying to achieve accessibility. Developers can check accessibility during the development process using tools built into software like Adobe Dreamweaver, or by using other tools.
The process of remediating accessibility issues found in existing sites may take time, training, and money.
Once your site is accessible, you may wish to prepare a statement on the accessibility standards your site follows and the steps you took to validate. Section 3 of the Technical Guidelines provides advice on documenting accessibility of your site.