1. Help
2. Campus map
3. Find people
4. Search OSU

• Disability Studies
• ASL
• Disability Services

Accessibility Policy (6/30/04) Accessibility Standards (6/30/04)

Web Accessibility Center Resources for Design

Accessibility Policy (12/07/01) Accessibility Standards (1/29/02)

The Ohio State University Web Accessibility Policy
(Revised 2/25/2004 -- Implementation Date 6/30/04)

Purpose

The creation and dissemination of knowledge is a defining characteristic of universities and is fundamental to Ohio State University's mission.   The use of state of the art digital and web based information delivery of information is increasingly central in carrying out our mission. Acknowledging this, The Ohio State University is committed to ensuring equal access to information for all its constituencies. This policy establishes minimum standards for the accessibility of web based information and services considered necessary to meet this goal and ensure compliance with applicable state and federal regulations.

Scope

Official Web Pages and associated web based services developed by or for a college, department, program or unit of the University.  Individual web pages published by students, employees or non-university organizations that are hosted by the University and do not conduct University related business are encouraged to adopt the University's policy and standards but fall outside the jurisdiction of this policy.

Policy

All new and redesigned Web pages published by any university college, department, program, or unit after 06/30/04 must be in compliance with the University's 2004 Minimum Web Accessibility Standards (MWAS).  Web pages published prior to 06/30/04 are considered Legacy Pages. Legacy pages are subject to the standards in place at the time of their development and to the guidelines for legacy pages provided for in this policy.

As of 06/30/04 each University web site, including Legacy Pages, must indicate, in plain text, a method of contact for users having trouble accessing content within the site. Suggested language:

"If you have trouble accessing this page and need to request an alternate format, contact _____________ at _________.";

The contact information would usually be an e-mail and/or phone number that puts the user in touch with someone responsible for the content and function of the page who can respond within one business day.

Upon a specific request for access by an individual with a disability, legacy pages must be updated to be in compliance with the University's 2004 MWAS or the content of must otherwise be made available to any individual requesting access in a timely manner (Timeliness should be considered in the context of the type of information or service a page provides and generally considered to be within 10 business days.)

Upon specific request for access, Web sites and pages in archive status (e.g. no longer in use but subject to records retention plans) containing core administrative or academic information, official records, and similar information be made available/accessible to any individual eligible for and needing access to such Web content, by revision or otherwise.

Priority must be given to creating accessible Web pages for core institutional information such as course work, registration, advising, admission, catalogs, and student services information. Units with large Web sites must establish priorities for ensuring access to these pages based on time sensitivity of function and frequency of use.

Implementation Priorities

1. All new and redesigned Web pages published by any university college, department, program, or unit after, 06/30/04.
2. Pages that individuals must access in a limited time frame in order to effectively participate in a program, to utilize a service or benefit from information offered by any unit of the University.
3. Annually convert the top 15% percent of the pages (based on frequency of hits among pages managed by any unit) to meet the current (6/30/04) standards.
4. Remaining Legacy Pages.

Exceptions

1. Web pages, including those in legacy or archive status, that are specifically requested to be made accessible as an accommodation for an individual with a disability shall be made accessible or an equally effective alternative shall be provided within 10 business days. For information based pages equally effective means that it communicates the same information with a comparable level of accuracy.  For interactive or service pages equally effective means that the end results (e.g. registration) is accomplished in a comparable time and with comparable effort on the part of the requestor.
2. Web sites and pages that are no longer actively linked to but are subject to records retention plans are considered to be in archive status and do not have to be converted to the 6/30/04 standard unless specifically requested by an individual.
3. Where compliance is not technically possible or may require extraordinary measures due to the nature of the information and the intent of the web page, exceptions to this policy may be granted by the ADA Coordinator's Office.  Request for such exceptions must be made in writing and must be based on issues other than cost alone.

Reporting

A status report summarizing the progress towards fully accessible web space (as defined by the 6/30/04 standard) over the past year and targets for the upcoming year shall be included in the annual reports to the Provost submitted by the Colleges and Vice Presidential areas.

Review

The ADA Coordinator's Office will initiate a review and necessary revisions of this policy the associated standards at least once every three years.  The review group will include designees from the University's Chief Information Officer, The Web Accessibility Center, and the office currently responsible for managing the University's "front page" (www.osu.edu )

Minimum Web Accessibility Standards

(Revised 2/25/2004 - Implementation Date 6/30/04

The following University standards 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 information and services.  Resources to assist designers in understanding and meeting these standards can be found at the University's Web Accessibility Center http://www.wac.ohio-state.edu/, (including a detailed guide to the standards http://www.wac.ohio-state.edu/standards); the Section 508 standards and links to tools and resources can be found at http://www.section508.gov/ and the WCAG Guidelines and associated resources are available at: http://www.w3.org/TR/WAI-WEBCONTENT/

Equivalent facilitation

Nothing in these standards are intended to prevent the use of designs or technologies as alternatives to those prescribed in these standards provided they result in substantially equivalent or greater access to and use of a web site for people with disabilities

1) A text equivalent for every non-text element shall be provided (e.g., via alt tags, "longdesc, or in element content).

Examples:

• Non-text elements (images, java applets, flash files, video files, audio files, plug-ins, etc.) have alt tag descriptions that convey the purpose or intended meaning of the object (e.g. Alt Tags for images used as links describe the link destination).
• Complex graphics that summarize information (graphs, charts, tables, etc.) are accompanied by text conveying the information providing a meaningful narrative of the information.
• Decorative graphics with no other function have empty alt descriptions (alt= "") not missing alt descriptions.
• When descriptions are lengthy or refer to other resources or sites, a longer description will be made available using a link or supported "longdesc".

2) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

2.1) Limited access password protected pages with a controlled user group may identify, in writing, a process for providing access to multimedia presentations.  The process must address how the information will be made accessible within a comparable time frame and with comparable effort by the user

Examples:

• Multimedia files on a department posted to a department page has synchronized captions.
• A web page supporting an on campus course presents multimedia files and provides a separate statement about requesting captioning and the instructor/department has a letter from the Office For Disability Services outlining the time frame and various responsibilities for providing captioning.

3) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup

Example:

• If color is used to convey information alternative indicators, such as an asterisk (*), are used in conjunction.

4) Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on black and white screen. 

Example:

• Blue on Blue, using different saturations of the same color for background and foreground

5) Documents shall be organized so they are readable without requiring an associated style sheet.

Examples:

• When a document is rendered without associated style sheet, it must still be possible to read the document. 
• Provide a text equivalent for any important image or text generated by style sheets (e.g., via the 'background-image', 'list-style', or 'content' properties).

Note: WCAG 3.3 Recommends using style sheets to control layout and presentation.  This method is strongly preferred over the use of tables due to wider compatibility with end user devices

6) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

Example:

• Use standard HTML client-side image maps with appropriate alt tags for the image and hot spots.

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

Example:

• Separate text links are provided outside of the server-side image map that provide the same to the content that image map hot spots access.

8) Row and column headers shall be identified for data tables.

Examples:

• Tables used only for layout do not have header rows or columns.
• In data tables, column and row headers are identified using the <th> tag.

9) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

Example:

• Table cells are associated with the appropriate headers (e.g. id, headers, scope and/or axis HTML attributes).

10) Frames shall be titled with text that facilitates frame identification and navigation.

Example:

• Each frame has a title that describes its purpose or the type of information contained within the frame.

11) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

12) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

Examples:

• Within scripts information is text-based or a text alternative is provided.
• All scripts (Javascript, pop-up menus, etc.) work with keyboard-accessible alternatives (either within or outside of the script) that provide equivalent functionality.

13) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with standards 1-9 of this document.

Examples:

• When applets, plug-ins or applications (Java applets, Java scripts, Acrobat PDF files or PowerPoint files) are not accessible to assistive technologies you must provide an alternative means of accessing the content within the applications (e.g., a mirror HTML file for a PDF file).
• When an applet, plug-in or application is utilized you must provide a link to a an accessible page where the plug-in can be downloaded

14) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

Examples:

• Form controls have text labels adjacent to them and keyboard access to control functionality.
• Form elements have explicitly associated labels in the markup (i.e. the id and for, HTML elements).
• Dynamic HTML scripting of the form does not interfere with assistive technologies.

15) A method shall be provided that permits users to skip repetitive navigation links.

Example:

• A link is provided to skip over lengthy lists of links (e.g. navigational menus).

16) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Example:

• Do not automatically forward, refresh, or otherwise alter pages, unless you provide the user with a method to adjust the timing of these content changes.

17) Do not change the current window without informing the user. 

Example:

• Do not cause pop-ups or other windows to appear (until typical user agents allow users to turn off spawned windows)

18) Clearly identify the target of each link. 

Example:

• Multiple links called the same thing (e.g., "more info . . . ", "results", or "click here") are problematic.

19) An accessible mirror page (e.g. text-only or non-flash) with equivalent information or functionality, can be provided to make a web site comply with this policy, when compliance cannot be accomplished in any other way. The content of mirror pages must be updated whenever the primary page changes.

Examples:

• A mirror page is acceptable when there is no other way to make the content accessible, or when it offers significant advantages for ease of navigation.
• The content for primary and mirror pages should be updated simultaneously.  For example, using a common database to generate content for multiple versions of the site.
• Instead of static alternative pages, set up server-side scripts that generate accessible versions of a page on demand.
• Mirror pages must be the functionality equivalent to primary pages (e.g. provides alternatives for applets, scripts, plug-ns and similar applications that are not directly accessible).
• "Text-only" and "accessible" are not synonymous; designers must incorporate all of the above standards when designing mirror pages.

Software Applications and Operating Systems.

Web based systems do not exist in a vacuum. When licensing or purchasing operating systems and software consider their impact your choices will have on the resources and effort necessary to provide accessible web based services and information in accordance with OSU policy and applicable state and federal regulations. The following standards from Section 508 provide guidance in considering these purchases. Software applications and operating systems that meet or exceed these standards provide the most efficient platforms for implementing and designing accessible web based services and applications.

1. When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
2. Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.
3. A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.
4. Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.
5. When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.
6. Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.
7. Applications shall not override user selected contrast and color selections and other individual display attributes.
8. When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.
9. Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
10. When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.
11. Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
12. When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

The Ohio State University Web Accessibility Policy (Revised 12/07/01)

Purpose

The creation and dissemination of knowledge is a defining characteristic of universities and is fundamental to Ohio State University's mission. The use of state of the art digital and web based information delivery of information is increasingly central in carrying out our mission. Acknowledging this, The Ohio State University is committed to ensuring equal access to information for all its constituencies, this policy establishes minimum standards for the accessibility of web based information.

Policy

All new or revised Web pages published or hosted by the University after 06/30/02, (the effective date of this policy) must be in compliance with the University's Minimum Web Accessibility Standards *(MWAS). Web pages published or hosted by the University prior to 06/30/02 are considered Legacy Pages, and are subject to additional guidelines. Legacy Pages will ultimately have to be removed or revised to be in compliance with the University's MWAS.

As of the effective date of this policy (06/30/02) each University web site, including Legacy Pages, must indicate, in plain text, a person to contact if users have trouble accessing content within the site. Suggested language:

"If you have trouble accessing this page, contact _____________ at _________." This would usually be the web page developer. Note: The addition of a contact person is not sufficient, in and of itself, in meeting accessibility guidelines.

Legacy Pages must be updated to be in compliance with the University's MWAS no later than 06/30/04 (two years after the effective date of this policy).

Upon a specific request for access, any page, including Legacy Pages must be revised to comply with the University's MWAS or the content therein must otherwise be made available to any individual needing access to such Web content in a timely manner.

Upon specific request for access, Web sites and pages in archive status (e.g. no longer in use but subject to records retention plans) containing core administrative or academic information, official records, and similar information be made available/accessible to any individual needing access to such Web content, by revision or otherwise.

Priority should be given to creating accessible Web pages for core institutional information such as course work, registration, advising, admission, catalogs, and student services information. Units with large Web sites containing core institutional information should establish priorities for ensuring access to these pages according to the pages being used or requested most often.

Priorities

For setting priorities to make Legacy Pages accessible, the following guidance is suggested:

First Year: Tier 1 pages.

Tier 1 Pages are:

1. The top 20 percent of the pages (based on frequency of hits among pages managed by any unit.)
2. Pages that individuals must access to effectively participate in a program to utilize a service offered by any unit of the University.
3. Web pages specifically requested to be made accessible as part of a formal accommodation request shall be made accessible as soon as possible, or an equally effective alternative shall be provided. Equally effective means that it communicates the same information in as timely a fashion as does the web page.

Second Year: remaining Legacy Pages

University entities developing Web pages for a federal or state agency may use the University's Web accessibility policy standards. Exception: Where a federal agency requires a Web page to be developed to a higher standard of accessibility than does the University, the higher standard shall be used.

Where compliance is not technically possible or may require extraordinary measures due to the nature of the information and the intent of the web page, exceptions to this policy may be granted by the ADA Coordinator's Office. Request for such exceptions must be made in writing and must be based on issues other than cost.

The ADA Coordinator's Office will initiate a review and necessary revisions of this policy at least once every three years. The review group will include designees from the University's Chief Information Officer, The Web Accessibility Center, and the Office currently responsible for managing the University's "front page" (www.osu.edu)

The Ohio State University Web Accessibility Standards (Revised 1/29/02)

Table of Contents

Introduction

Section 1: Alternative Accessible Elements and Pages

Section 2: Layout and Presentation

Section 3: Writing Style and Language

Section 4: Image Maps

Section 5: Tables

Section 6: Frames

Section 7: Forms

Section 8: Applets and Scripts

Section 9: Multimedia

 

Introduction

All University constituents are encouraged to use the full version of the current Section 508 standards, the access standards governing Federal web sites, as a guide in developing web sites (http://www.access-board.gov/508.htm).

The University's Minimum Web Accessibility Standards are derived from the Section 508 standards of the Rehabilitation Act and have been established to ensure that web pages are designed and maintained as accessible to people with disabilities. These standards are congruent with the principles of good design, recognize rapidly changing technology, and will enhance the effectiveness and usability of web-based communications for all users. Additional details, techniques, tutorials, and examples will be integrated into future versions of this document. Currently design support can be found at the University's Web Accessibility Center (http://www.wac.ohio-state.edu/)

Back to Table of Contents

Section 1: Alternative Accessible Elements and Pages

• Graphic elements and dynamic content must be accessible. Provide a text equivalent for all graphic elements and inaccessible dynamic content. Text is considered accessible to most users. Text can be interpreted by screen readers, non-visual browsers, and Braille readers.
• Whenever possible, avoid using images to represent text by using the appropriate markup languages.
• We recommend creating web pages that are universally designed and can be accessed by everyone, but if a page must be designed in a way that is not fully accessible to all, then an alternative accessible web page must be created. This may take the form of a text only version.
• Ensure that all text only versions and text equivalents are maintained and updated whenever non-text and dynamic content changes.

Back to Table of Contents

Section 2: Layout and Presentation

• If color is used to convey information, make sure that the information is also available without color.
• Background colors and foreground colors should provide sufficient color contrast.
• Link text should be clear and meaningful. Avoid using "click here".
• Provide a site map or table of contents.
• Navigation features and style of presentation should be consistent throughout the site.
• Style sheets should be used to create layout and presentation instead of tables.
• Use relative units rather than absolute units in markup language attribute values and style sheet property values.
• Use Header (H1, H2 etc.) to indicate headers and sub-headers, and use them in the correct order. Do not use headers to embellish fonts.
• Use lists and list items properly and do not use them for layout or formatting purposes.
• Use quotation markup for quotations and not for formatting purposes such as indentations.
• Avoid the use of screen flicker and blinking at rates faster than 3 per second. Flashing, flickering, and blinking of a document or document element can cause seizures in people with photosensitive epilepsy.
• Automatic refresh, and auto-redirect of pages can be confusing and disorienting to some user. Instead, configure the server to perform redirects, and create a static page that provides the new URL to direct the user to the new web location.
• Avoid using pop-up windows and inform the user if the current window changes to a new window. Some users may not realize that a pop-up window or a new window has been implemented, causing confusion and loss of important information.
• Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.
• Outdated elements of W3C technologies (http://www.w3.org/) should be avoided and be replaced with newer technologies. The FONT tag is an example of an outdated element that has been replaced through the use of style sheets. Refer to the W3C References for more information.

Back to Table of Contents

Section 3: Writing Style and Language

• Try to break up large blocks of information into smaller sections to aid in navigation and readability.
• Define the meaning of acronyms and abbreviations where they first occur in a document.
• Identify the primary natural language of a document. Any changes in the primary natural language of a document must be identified. For example, if the natural language of a document is English and a section of the document changes to French, the French text must be clearly identified as being French.
• Create documents that validate to published formal grammars.

Back to Table of Contents

Section 4: Image Maps

• Use client-side image maps instead of server-side image maps whenever possible. If a region can't be defined with an available geometric shape, then a server-side image map may be used.
• If a server-side image map must be used, provide redundant text links for each active region.

Section 5: Tables

• Style sheets are preferable for page layout instead of tables.
• If a table must be used for layout, be sure that the table makes sense when linearized, if not, be sure to provide an alternative equivalent. Table row and column headers should not be used when a table is used for layout purposes.
• Data may be organized with the use of tables. Identify table row and column headers for data tables.
• Provide table summaries explaining the structure of the table and the purpose of the data. Non-visual readers will be especially aided through the use of a table summary.
• Avoid nested tables.

Back to Table of Contents

Section 6: Frames

• If frames must be used, be sure to title each frame to aid in navigation and to identify the content of each frame.
• If the frame titles are too vague, provide a description that explains how each frame relates to each other and the purpose of each frame.

Section 7: Forms

• For all form controls with implicitly associated labels, ensure that the label is properly positioned. Associate labels explicitly with their controls.
• Provide place holding words or characters in edit boxes and text areas to help provide meaning and understanding.

Back to Table of Contents

Section 8: Applets and Scripts

• When scripts, applets, or other programmatic objects are turned off, be sure that pages are still readable. Otherwise an alternative accessible page must be provided with equivalent information.
• For scripts and applets, ensure that event handlers are input device-independent.
• Provide alternatives to or avoid movement in pages.
• Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.
• Ensure that any element that has its own interface can be operated in a device-independent manner.
• For scripts, specify logical event handlers rather than device-dependent event handlers.

Section 9: Multimedia

• An audio track explaining important visual information must be provided for visual multimedia presentations.
• Time-based multimedia presentations such as movies must have equivalent alternatives synchronized with the presentation. This would include captions or auditory descriptions of the visual presentation.

Back to Table of Contents | Back to ADA Resources