Page content

Listen to this section

 

Meeting the OSU Web Accessibility Policy and Standards

According to the OSU Web Accessibility Policy (PDF), all content interfaces to be used by Ohio State University faculty/staff, program participants, or other university constituencies are required to be compliant with the Americans with Disabilities Act (ADA), as amended. This page provides elaboration and guidelines to help OSU developers and purchasing agents meet the Web Accessibility Policy.

To be compliant with the ADA and our Web Accessibility Policy and Standards a person with a disability must be able to acquire the same information, engage in the same interactions, and enjoy the same services as a person without a disability, and be able to do so in an equally effective manner, with substantially equivalent ease of use. Information and services must be made available at the same time to a person with a disability as to a person without a disability.

Table of Contents:

Considerations for Functional Accessibility

To help satisfy the requirement to comply with the ADA and meet Web Accessibility Policy and Standards, your resource (page, site, media, or application) should be functionally accessible, rather than merely technically accessible. While technical accessibility determines whether a resource is coded to an accepted accessibility standard, to be functionally accessible means that any person can use the resource effectively to perform an available task. Coding to an accepted standard is often a means of approaching functional accessibility, but achieving functional accessibility means that your resource is easy to use and your content clear and unambiguous for all users, regardless of ability.

To be functionally accessible your web resource must consider:

  • use by people who may have severe or moderate visual impairment
  • use by people who may be colorblind
  • use by people who may be deaf or hard of hearing
  • use by people who may have motor disabilities
  • use by people who may have cognitive disabilities

Users with severe visual impairments typically use screen readers, programs that navigate the web browser's rendering of the code of a web page and read aloud the content. Screen readers identify not only text, but alternate text for images. They facilitate full interaction with web page content and objects. And they allow users to skip between chunks of content by link, heading, form element, and content block, among other means. Invalid or lax coding practices, minimal logical structure and semantics, and inappropriate or missing textual descriptions for images or links make navigation and understanding of web content difficult or impossible for screen reader reliant users. Some usages of JavaScript and plug-ins can be inaccessible to screen readers, as well.

The screen reader used most on campus is Freedom Scientific JAWS. We are also seeing significant use of VoiceOver, the screen reader on Mac and iOS devices. Because of the variety of screen readers in use on campus, we strongly recommend testing on more than one platform, including a mobile platform. NVDA is a free screen reader for Windows which tends to be in the vanguard in its handling of modern web page/application implementations. We recommend it for testing, along with VoiceOver on Mac and iOS.

Users with moderate to severe visual impairments (“low-vision”) typically enlarge the screen fonts, either by using the browser's zoom or text scaling facilities or by using screen magnification programs. These users may also set their operating system to a “high-contrast” mode or use custom style sheets to increase the contrast between foreground and background.

The Minimum Web Accessibility Standards implementation guidelines in the table below have some recommendations for ensuring access for low-vision users, including testing with Windows high-contrast mode enabled. We also recommend testing with a screen magnification program. Many campus lab computers have ZoomText installed. ZoomText is a high-quality, widely used screen magnifier for Windows. It has modes of operation for documents and applications that simplify web pages and web applications. In certain cases, these modes may interact with web pages, forms, and applications in unexpected ways. So testing not only with screen magnification enabled but also with ZoomText in application and document reading modes is recommended.

Users with color blindness have problems distinguishing between certain colors. We recommend avoiding instances where functionality or meaning is conveyed solely by color differences and further recommend evaluating web resources with special programs that emulate various types of color-blindness. (See the implementation guidelines in the compliance table below for resources.)

Users who are deaf or hard of hearing may rely on transcripts of audio content, captioned video, and alternatives to auditory cuing.

According to best practices and our Minimum Web Accessibility Standards, all video content must have a synchronized text track (caption), providing transcription of spoken text, speaker identification, and text equivalents of non-verbal audio (a.k.a., sound effects), as appropriate. Audio podcasts and other spoken audio should be accompanied by a full text transcription. Web pages or applications that use audio cues also should provide a visual, preferably text-based, cue.

Users with various motor disabilities may have difficulty using the mouse as a pointing device, due to nerve conditions, disease, or injury. Limited motor acuity may affect response times and accuracy in selecting navigation or options within forms and other controls. Repetitive stress and other less severe motor disabilities may make over-reliance on the keyboard difficult — for example, excessive tabbing to move through controls. Users with limited upper-body mobility may use speech recognition for input or other input devices which mimic keyboard input, or they may rely solely on the keyboard for all input.

Developers should test to make sure all navigation, form, and other control elements in web pages are accessible and operable via the keyboard alone and look to see that if timed responses are necessary there is the ability to extend the time and that that functionality is easy to understand and locate in the page or application. Also try to judge the impact on usability afforded by the quantity and complexity of input required for navigation, form, or other input. (Note that providing a means for skipping over repetitive navigation is a requirement of our Minimum Web Accessibility Standards.) We also recommend testing the usability of web forms and applications with speech recognition software, such as Dragon or Windows 7 Speech Recognition.

Cognitive disability is the most broad and varied category of disability. Most users with disabilities registered through our Office for Disability Services have some form of cognitive disability. Thus, attention to usability problems that may be encountered by users with cognitive disability will have proportionally the greatest positive impact on visitors to your site. Cognitive disabilities include conditions affecting reading and verbal comprehension, learning disabilities, attention and distractibility disorders, conditions affecting memory and processing of large amounts of information, and problems comprehending information presented mathematically or graphically.

In general, try to assess the general usability and comprehensibility — clarity in presentation and logical and spacial organization — of web resources. Ensuring correct grammar and spelling and reducing verbal complexity will have a positive impact for users with certain cognitive disabilities, as well. There also exist services that can analyze the complexity of your text content, for example the Readability Test.

Minimum Web Accessibility Standards and Compliance Table

The Ohio State University Minimum Web Accessibility Standards (MWAS) provide implementation guidelines for its Web Accessibility Policy. The Standards were adopted in 2004 and are maintained by the ADA Coordinator's Office, with the assistance of the Web Accessibility Center. They are based on Section 508 §1194.22 of the Federal Rehabilitation Act, the current standard of legal compliance for U.S. government institutions. The goal of MWAS is to ensure web resources are functionally accessible to people with disabilities, as described above and in Section 508 §1194.31 of the Rehab Act, “Functional Performance Criteria.”

We understand that the 508 criteria are being revisited and will likely come to harmonize with W3C WCAG 2.0. The "Reference Standards" sections in the middle column of the table below elaborate MWAS in an attempt to align it with current and emerging standards.

The table below quotes the OSU MWAS in the left-hand column. The middle column lists general web content categories for each Standard and gives links to similar or relevant web accessibility standards. The web content categories refer to HTML structures, content provided via external resources, and aspects of web resources having to do with visual presentation and behavior:

  • HTML Structures: Document Organization and Semantics, Forms, Graphics, Links, and Tables
  • Content from External Resources: Audio, Multimedia, Plug-ins, Video
  • Presentation and Behavior: Dynamic Content, Keyboard Accessibility and Focus, Use of Color, Use of JavaScript

The right column of the table elaborates on and provides guidelines for meeting MWAS. “Required” guidelines must be implmented to meet the Standard, but all guidelines should be considered.

The middle column can serve as reference lookup to allow you to research other key web accessibility standards, specifically:

  • Section 508 §1194.22 of the Federal Rehabilitation Act (508), the standard of legal compliance for U.S. government institutions.
  • The World Wide Web Consortium's Web Content Accessibility Guidelines version 2.0 (WCAG 2.0), the primary international guidelines.
  • The implementation guidelines for the Illinois Information Technology Accessibility Act (IITAA), a model state law, authored in collaboration with a Big Ten institution.

The MWAS Compliance Table was last updated May 22, 2013. See below the table for list of changes between updates.

OSU Minimum Web Accessibility Standards (MWAS) Compliance Table
MWASContent Categories & Standards ReferencesImplementation Guidelines

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

Categories
Graphics
Links
Reference Standards
508 1194.22: 508 a
WCAG 2.0: WCAG 1.1.1
IITAA: IITAA 4.1, IITAA 4.2
Required: Informational graphics have text equivalents (via the alt attribute). Links to long descriptions, in-page or external, are provided when alt attribute descriptions are insufficient, for example, in the case of descriptions of charts or graphic tables.
Required: Decorative/non-informative inline graphics have alt="" (empty alt).
Required: Graphics used as links (without accompanying text description) have alt indicating link target.
Strongly Recommended: When graphic icons accompany link text, for example in a graphical menu, the graphics should get empty alt. Example:
<a href="foo.html"><img src="foo-icon.png" alt=""> Foo</a>
Recommended: Use CSS to render decorative graphics.
Resource: Find some helpful guides to writing effective alternative text in the ACT Wiki, under Media Accessibility > Describing Graphics.

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

Categories
Multimedia
Audio
Video
Reference Standards
508 1194.22: 508 a, 508 b
WCAG 2.0: WCAG 1.1.1, WCAG 1.2.1, WCAG 1.2.2, WCAG 1.2.3
IITAA: IITAA 6.3, IITAA 7.1, IITAA 7.2

Required: Synchronized full text captions are provided for publicly available video.

  • Note: For moving-picture video content, a synchronized verbatim caption is required.
  • Note: For voice-over narrated automated slide shows and similar, a static transcript, cued to update upon slide change is required.
  • Note: Captions should include speaker identifications and “sound effects”/audio cues, where appropriate.

Required: Full text transcripts are provided for publicly available audio-only presentations.

Note: Transcripts should include speaker identifications and “sound effects”/audio cues, where appropriate.

Required: Video or audio does not begin playing on page load.

Strongly Recommended: Video has secondary audio description, when appropriate to content.

Note: A descriptive transcript — one that provides all necessary text equivalents of crucial auditory content (sounds, speaker changes, etc.) and video content (scene and character descriptions, etc.) — is an acceptable alternative to synchronized audio-only audio description.

Note on when captions/transcripts are required: For non-public video (or audio) with a known and controlled audience, captions (or transcripts) are not required but must be provided within a reasonable time if need for accommodation arises. See the “Requirements” section of the OSU Web Accessibility Policy (PDF) for more information.
3. “Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.”
Categories
Graphics
Use of Color
Reference Standards
508 1194.22: 508 c
WCAG 2.0: WCAG 1.4.1
IITAA: IITAA 3.1
Required: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Recommended: Author has tested to ensure colors are distinguishable to users with common forms of colorblindness.

Resource: Contrast Analyser.

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.”
Categories
Graphics
Use of Color
Reference Standards
508 1194.22: N/A
WCAG 2.0: WCAG 1.4.1
IITAA: IITAA 3.2

Required: There is sufficient foreground/background contrast when viewed by someone with low-vision or a color deficit.

Required: When Windows OS high-contrast mode is enabled, all content and controls remain visible. Informational images rendered via stylesheets, such as those commonly used in buttons and navigation links, are replaced by text equivalents, in order to maintain usability and/or indicate functionality.

Recommended: Author has tested with a color contrast analysis tool or equivalent to ensure W3C standards for foreground/background contrast are achieved.

Resource: Contrast Analyser.

5. “Documents shall be organized so they are readable without requiring an associated style sheet.”
Categories
Document Organization and Semantics
Reference Standards
508 1194.22: 508 d
WCAG 2.0: WCAG 1.3.1 , WCAG 1.3.2, WCAG 1.4.8, WCAG 4.1.2
IITAA: IITAA 1.2, IITAA 1.3, IITAA 17.3

Required: Turning off stylesheets does not negatively impact content order or make the meaning of previously styled elements ambiguous.

Negative example: CSS positions the content for visual reading but the HTML source does not have a logical reading order.

Negative example: Stylesheets provided an important visual cue that is not also present in text in the HTML source or rendered DOM.

Required: Properly nested headings organize the content sections of web pages, including using visually-hidden (“off-left”) headings where appropriate to create page semantics.

Required: Pages have a title element in the head of the document. The title should provide the name of the page and contextual information to help orient the user within the web site. The title should be unique within the site whenever possible.
Strongly Recommended: Major navigation elements (menus) are implemented as HTML unordered lists.
Strongly Recommended: Pages declare a base document language using the lang attribute on the body (e.g., lang="en"). Any non-default language text is identified using the lang attribute on the parent element.
Strongly Recommended: HTML is used “semantically” to organize and help provide meaning to content (e.g., lists are implemented with list elements, block quotes are implemented with blockquote elements, etc.)
Strongly Recommended: Major content sections are identified by using WAI-ARIA landmark roles.
Strongly Recommended: Document source and tab order aligns with visual display order. This guideline should extend to pages that reorient content sections (columns, etc.) when displayed at narrower widths, for example in the case of responsive web design accommodating mobile browsers.
Recommended: It is possible to enlarge page text to twice the default size without loss of functionality or content (clipping) or making it necessary to scroll horizontally to read the content.
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.”
Categories
Graphics
Links
Reference Standards
508 1194.22: 508 a , 508 f
WCAG 2.0: WCAG 1.1.1
IITAA: IITAA 5.1
Required: Clickable regions of client-side image maps are properly identified with alt attributes.
7. “Redundant text links shall be provided for each active region of a server-side image map.”
Categories
Graphics
Links
Reference Standards
508 1194.22: 508 e, 508 f
WCAG 2.0: WCAG 1.1.1
IITAA: IITAA 5.2
Required: Server-side image maps are used only when non-geometric/solely positional input is required and an alternative accessible input method is provided in such cases.
8. “Row and column headers shall be identified for data tables.”
Categories
Tables
Document Organization and Semantics
Reference Standards
508 1194.22: 508 g
WCAG 2.0: WCAG 1.3.1, WCAG 1.3.2
IITAA: IITAA 11.1, IITAA 17.1

Required: Data tables identify row and column headers using th tag.

Required: If tables are used for layout, a logical reading order is maintained.
Strongly Recommended: Summary attribute is used to explain the purpose and structure of the table.
Strongly Recommended: Caption element is used to provide a descriptive title for the table.
Recommended: HTML tables are used for organization of tabular data, primarily, with CSS used for layout.
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.”
Categories
Tables
Document Organization and Semantics
Reference Standards
508 1194.22: 508 h
WCAG 2.0: WCAG 1.3.1
IITAA: IITAA 11.2
Required: Simple HTML data tables (that, is, not layout tables) have scope (row or col) set on table header cells.
Strongly Recommended: Complex HTML tables (i.e., those with more than a single column or row header and those with complex row or column spans) use headers and id attributes to associate data cells with header cells
10. “Frames shall be titled with text that facilitates frame identification and navigation.”
Categories
Document Organization and Semantics
Reference Standards
508 1194.22: 508 i
WCAG 2.0: WCAG 4.1.2
IITAA : IITAA 12.1, IITAA 12.2
Required: Frames and iframes have title attributes identifying their purpose and/or briefly describing their content.
Recommended: Use of hidden frames or iframes is avoided.
Recommended: iframes or CSS alternatives are used in preference to frames.
11. “Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.”
Categories
Graphics
Dynamic Content
Multimedia
Reference Standards
508 1194.22: 508 j
WCAG 2.0: WCAG 2.3.1
IITAA: IITAA 8.2
Required: No page content or graphic flashes faster than three times per second.
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.”
Categories
Keyboard Accessibility and Focus
Use of JavaScript
Dynamic Content
Reference Standards
508 1194.22: 508 l
WCAG 2.0: WCAG 1.3.1, WCAG 4.1.2
IITAA: IITAA 13.1, IITAA 13.2

Required: Scripted elements and/or “widgets” are accessible to the keyboard, with all focusable elements being able to be activated/utilized solely via the keyboard.

Required: Scripted elements and/or “widgets” are coded so that they work effectively with screen readers.

Strongly Recommended: W3C WAI ARIA Authoring Practices are followed for scripted elements and widgets.

Resource: Model examples are at OpenAjax Accessibility Example. Dojo A11y Requirements provides general guidelines and testing procedures.

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.”
Categories
Plug-ins
Keyboard Accessibilty and Focus
Multimedia
Reference Standards
508 1194.22: 508 k
WCAG 2.0: WCAG 1.1.1, WCAG 2.1.2
IITAA: IITAA 14.2
Required: Plug-in based widgets (Flash, Silverlight, Java, etc.), menus, or other controls embedded in the web site have functionality that complies with standards 1 through 9 of MWAS or a functionally equivalent form of access is provided (e.g., Widgets provide HTML-based, keyboard accessible primary or alternative controls).
Required: Plug-in based widgets do not “trap” the keyboard/prevent keyboard navigation from moving out of or away from the widget.
Strongly Recommended: PDF, EPUB, PowerPoint, and other document types linked to within the hosted web site meet appropriate accessibility standards (e.g., PDF is “tagged,” PowerPoint is mostly text-based with graphics adequately described, EPUB has a proper document structure with videos captioned and images described, etc.).

Recommended: Plug-ins required for display or functionality of content are readily available (via link on page or (verified) automatic functionality of web browser).

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.”
Categories
Forms
Use of JavaScript
Reference Standards
508 1194.22: 508 n
WCAG 2.0: WCAG 1.3.1, WCAG 2.1.1, WCAG 2.4.6, WCAG 3.3.2
IITAA: IITAA 4.1, IITAA 10.1, IITAA 10.2, IITAA 10.3
Required: All form elements are able to be utilized fully via keyboard.
Required: Input fields are associated with labels via “for-id” syntax (title attribute used alternatively, when necessary/by visual requirement) and buttons or button inputs are properly labeled (via encapsulated text or value attribute, respectively).

Required: If a traditional visual challenge CAPTCHA is used (not advised), an audio challenge alternative is provided and/or a method requiring only text-to-speech output is provided.

Strongly Recommended: Fieldsets with short descriptive legends group associated radio buttons or check boxes.

Strongly Recommended: Order of form elements flows logically and associated elements are proximate and in a logical order.
Strongly Recommended: Form errors are indicated by focusing the errors list on page submit or by focusing first error field and ensuring error message is accessible to a screen reader user by using aria-labelledby or other associative labeling method
Strongly Recommended: Form required fields are identified textually (via alt on an image of an asterisk, for example) and/or through both aria-required and required attributes.
Strongly Recommended: Help prompts in forms are accessible to a screen reader and properly associated with the relevant field, using aria-labelledby or other associative labeling method.
Strongly Recommended: Dynamic, scripted elements within a form (contextual reveals, etc.) do not disrupt form fill out and are tested to be screen reader accessible.
Recommended: Users are able to confirm and edit long/multi-page form changes before submitting.
Recommended: Form submission errors are indicated with text proximate to the field and associated with aria-labelledby or other associative labeling method
Recommended: Forms do not use links for buttons.
15. “A method shall be provided that permits users to skip repetitive navigation links.”
Categories
Document Organization and Semantics
Keyboard Accessibility and Focus
Reference Standards
508 1194.22: 508 o
WCAG 2.0: WCAG 2.4.1
IITAA: IITAA 9.2
Required: A method to skip long lists of links, such as navigation, is provided (e.g., “skip to main content” link is first focusable page element)

Note: MWAS 5 recommends a heading structure and use of ARIA landmark roles. These may provide certain assistive technologies adequate means for skipping repetitive navigation. Nevertheless, for some users, for example, those with motor impairments, it is very helpful to provide visible skip navigation to allow for a convenient means to bypass top level navigation and move straight to content.

Note: For a model implementation of skip links, see Back to Basics: Skip to Main Content Links.
16. “When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.”
Categories
Forms
Dynamic Content
Reference Standards
508 1194.22: 508 p
WCAG 2.0: WCAG 2.2.1
IITAA: IITAA 8.1, IITAA 16.1, IITAA 16.2
Required: The user is given an accessible method to extend time when a timed response is required.
Strongly Recommended: The user is given an accessible method to extend the browser “session.”
Strongly Recommended: The user is given an accessible means to pause automatically moving, rotating, updating, or scrolling content.
Strongly Recommended: Do not automatically refresh the page.
17. “Do not change the current window without informing the user.”
Categories
Keyboard Accessibility and Focus
Use of JavaScript
Reference Standards
508 1194.22: 508 l
WCAG 2.0: WCAG 3.2.2, WCAG 3.2.5
IITAA: IITAA 9.4, IITAA 13.3, IITAA 13.4

Required: The user expects all changes of cursor focus on a page because the user initiated the change purposefully. (e.g., an in-page anchor link is clicked, the screen scrolls and caret focus moves to the anchor.)

Strongly Recommended: The user is aware of significant changes to page content. (e.g., a new section of content dynamically populates; this change is readily discoverable by the user, regardless of technology being used to access the page (screen reader, etc.).)

Strongly Recommended: Pop-open dialogs are indicated by moving focus to the dialog and escaping/closing the dialog returns focus to original location on the page.
18. “Clearly identify the target of each link.”
Categories
Keyboard Accessibility and Focus
Links
Multimedia
Reference Standards
508 1194.22: N/A
WCAG 2.0: WCAG 2.4.4
IITAA: IITAA 9.1
Required: Link text is understandable out of context on the page (no use of “click here,” “more…”, or links that are URLs (except when identifying resources for purposes of printing)).
Required: Keyboard focus is clearly visually indicated (e.g., when tabbing through a page).
Required: All focusable links and controls are able to be utilized fully via the keyboard.
Strongly Recommended: A link that loads an external application, PDF, or other media has that application identified with accessible text (e.g., “my file (PDF)”).
Strongly Recommended: When creating links, the title attribute should only be used when there is a compelling need for extra information to be conveyed, not merely to duplicate link text. The tooltip created by title values is not accessible to keyboard alone, and when hovered with the mouse can obscure adjacent content. If title on links is used, the link text must be repeated, first, with the extra information coming afterward.
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.”
Reference Standards
508 1194.22: 508 k
WCAG 2.0: Conforming Alternate Version definition
IITAA: IITAA 18.1

Required: Separate, up-to-date, accessible “mirror pages” are used only as a last resort.

See the section on "Exceptions" in the OSU Web Accessibility Policy (PDF) for more information.

MWAS Change Log:

  • 22 May 2013: Changes to MWAS 5: added Strongly Recommended guideline on document order following visual order; changed title and headings guidelines from Strongly Recommended to Required; changed landmarks guideline from Recommended to Strongly Recommended.

Suggested Purchasing Procedures and Contract Language to Help Meet MWAS

When evaluating third-party products we sometimes find accessibility has not been fully addressed. In making a selection, it is advisable to choose the most accessible product in the space. However, not always will there be accessible choices, or the most accessible choice may not align with other dominant selection criteria.

In cases where a product with limited accessibility has been purchased, demonstrating that OSU is working with the vendor and that a time frame for improving accessibility has been established in partnership with the vendor may help minimize legal risk. The OSU Web Accessibility Center (wac@osu.edu) may be able to help determine and monitor progress on appropriate short and longer term accessibility improvements.

Additionally, interim, equivalent accommodations documented in an approved ADA Exception should be in place until the service can be made accessible. The ADA Exception is a mechanism through which we hold ourselves accountable for the fact that we are rolling out software that (temporarily) violates our own policy. Within the Exception, processes for arriving at accessible solutions and documentation of temporary accommodations should be as open and transparent as feasible, given OSU business concerns. Request for an ADA Exception must be made to the ADA Coordinator's Office (ada@osu.edu).

“Enterprise” purchases go through a formal procedure that includes a Request for Proposal (RFP). Below we suggest language to include within RFPs, which requires vendors to benchmark their products against our MWAS implementation guidelines. Vendor responses can help determine both a product's compliance and a vendor's awareness and knowledge of accessibility. Responses also may help in ranking products for ultimate selection.

It should be noted that often vendor representatives have limited knowledge of the accessibility of their products and will make accessibility statements that might later prove to be false. Vendor responses should be verified by OSU staff with demonstrated ability in accessibility evaluation. This verification process should be accomplished through hands-on evaluation of the product, prior to purchase. It is best to involve both OSU experts and users with disabilities in such evaluation.

After selection has been made a contract will be negotiated. The contract provides an opportunity to factor in changes to the product within an agreed time frame.

The RFP and contract amendment language presented below are merely suggested phrasings. Purchasing agents are invited to edit as appropriate to specific business needs.

Suggested RFP Language

[begin suggested RFP language]

All content, interfaces, and navigation elements to be used by University faculty/staff, program participants, or other University constituencies must be compliant with the Americans with Disabilities Act, as amended. Compliance means that a person with a disability can acquire the same information, engage in the same interactions, and enjoy the same services as a person without a disability, in an equally effective and integrated manner, with substantially equivalent ease of use.

There are multiple approaches to providing equally effective and substantially equivalent ease of use. A product will be considered to have met this standard based on a review by the University or when the vendor demonstrates that the work clearly meets the applicable current portions of the Ohio State University's Minimum Web Accessibility Standards through documented accessibility testing.

The Ohio State University Minimum Web Accessibility Standards are implementation guidelines for its Web Accessibility Policy, adopted in 2004. They are based on Section 508 §1194.22 of the Federal Rehabilitation Act, the standard of legal compliance for U.S. government institutions. The goal of MWAS is to ensure websites and web-based applications are functionally accessible to people with disabilities, as described in Section 508 §1194.31, Functional Performance Criteria. We understand that the 508 criteria are being revisited, and will likely come to harmonize with W3C WCAG 2.0 AA compliance. The criteria in the middle column of the table elaborate MWAS in an attempt to align it with current and emerging standards.

The accessibility testing process must be described in the proposal along with the completed chart (included below), and may include but is not limited to code reviews by internal or external experts, evaluations with accessibility checking software, vendor test bedding with assistive technologies, testing by users with disabilities, or testing by a third party organization.

Please answer the following questions:

  1. Do you have clients who require accessibility (Federal govt., international, local company policies)? If so, in outline, how are they ensuring your product meets their requirement?
  2. What standards are followed for coding of interfaces (if 508, what parts, if WCAG 2.0, which level)?
  3. Do you do testing with users with disabilities? If so, can you explain the process and identify, roughly, the range of disabilities and access technologies used?
  4. What experience do developers on your team have coding for accessibility?
  5. What are your company's internal standards for developing with accessibility in mind? (Note: may have been answered by question 2.)
  6. Does your company have a road map for accessibility going forward? If so, can you give us a general outline (goals, milestones)?
  7. Have you tested and/or developed your mobile apps (especially iOS) with accessibility in mind?
  8. If we find that there are changes that need to be made to web/mobile interfaces/apps, what guarantee can we have that these will be implemented to our satisfaction prior to go-live/going forward?
  9. Would your company indemnify OSU against legal action related to accessibility?

Please complete the following chart to indicate your organization’s ability to support Ohio State’s ADA compliance guidelines.

[include the entire MWAS implementation guidelines from above, adding a column with “meets/partially meets/does not meet” and a column for vendor comments]

[end suggested RFP language]

Suggested Contract Amendment Language

The second paragraph and subsequent suggested contract language below assumes that the prospective vendor's current product has accessibility issues that make it non-compliant with our policy. It recommends the vendor enter into a collaborative partnership with OSU to help address access issues. Obviously, not always will a vendor be non-compliant and, though the model is recommended, not always will a collaboration be feasible. Incorporate those parts of the language that suit your business case.

[begin suggested contract language]

[Vendor] shall be complaint with all federal and state laws and requirements in the provision of services under this Agreement, including but not limited to the provision for equally effective and substantially equivalent ease of use for persons with disabilities, as required by the Americans with Disabilities Act (ADA). OSU's Minimum Web Accessibility Standards (MWAS (http://go.osu.edu/mwas)) shall be used to evaluate minimum compliance with the ADA. [Vendor] shall indemnify, defend, and hold OSU, [other OSU entities named], and their respective Trustees, Employees, agents, and servants harmless for any fines, penalties, expenses, or awards related to any claims, including requests for accommodations, concerning administration of [OSU's name for to-be-established service], including but not limited to ADA compliance.

In addition, [vendor] agrees to collaborate with OSU’s ADA Coordinator, Web Accessibility Center (WAC), and/or other designees to design and implement necessary minimum initial and medium enhancements surrounding ADA compliance, as described below, within [given time frame] from the effective date of this Agreement.

In cooperation with OSU WAC [and/or other designated entities], [vendor] will establish an accessibility evaluation, remediation, and development process for all vendor-supplied web-based and mobile components/interfaces. This process will establish regular teleconferences between the WAC [and/or other designated entities] and appropriate product staff and/or developers at [vendor], and may involve interface code reviews and accessibility testing with experts and users with disabilities, in order to determine current and evolving accessibility of interfaces and components and to recommend improvements, where necessary, in order to satisfy, minimally, all germane, agreed upon “Required,” “Strongly Recommended,” and “Recommended” Implementation Guidelines of the MWAS.

Minimum and medium enhancements will include the following:

[bullet list of features/enhancements required to be implemented, with staged completion dates, where appropriate]

[end suggested contract language]