5. Procurement and Accessibility Policy
Contract for Accessibility
Assuming you have received proposals from vendors, tested their understanding of web accessibility, and are ready to move into a contractual arrangement to license or purchase the software or web application from one of them, it is important to lay out web accessibility requirements in the issued contract.
The following are two approaches to defining accessibility requirements: the first is a more general approach, relying on a specific standard to which vendors can refer, and the second is a more detailed approach, which relies on a standard but also supplies specific requirements that must be met.
Section 508 Wording
The National Center on Disability and Access to Education (NCDAE) provides some standard text for contracts that makes accessibility a requirement of the agreement. This text will be relevant for those procuring under the Section 508 regulations:
Vendors must ensure that the course management system contained in the proposal fully conforms with Section 508 of the Rehabilitation Act of 1973, as amended in 2017. (For information on Section 508, see www.section508.gov.) This includes both the student and instructor views and also includes all interaction tools (e.g., chats, discussion forums), and add-ons (e.g., grade functions). Vendors must declare if any portion of the version under consideration does not fully conform to Section 508, and the ways in which the proposed product is out of compliance.
Source: The National Center on Disability and Access to Education
While this approach may be sufficient in some cases, where it has been confirmed that the vendor understands the requirements of Section 508, there will be cases when vendors don’t know if their product conforms or not. To reduce that likelihood, details of the Section 508 requirements could be specified, something like the requirements outlined in the “WCAG 2.0 Wording” section below.
WCAG 2.0 Wording
Like the wording for RFPs introduced earlier in this unit, it is important for contracts to provide specific details in order to avoid potential confusion for vendors who may not be fully aware of WCAG 2.0 requirements. The following is an adapted version of the Section 508 wording above, with suggested wording that specifies an agreed upon course of action should accessibility issues be discovered after the contract is implemented, along with the procuring organization’s specific accessibility requirements. Though WCAG 2.0 is specified, this language would be appropriate for those drafting AODA-related web accessibility requirements.
Sample 2: Purchasing contracts of specific productsVendors must ensure that the course management system contained in the proposal fully conforms with the Web Content Accessibility Guidelines (WCAG 2.0), Level AA, as published by the Web Accessibility Initiative (WAI) of the W3C, summarized in the list below (see WCAG 2.0 for more information). This includes both the student and instructor views and also includes all interaction tools (e.g., chats, discussion forums), and add-ons (e.g., grade functions). Vendors must declare if any portion of the version under consideration does not fully conform to WCAG 2.0 Level AA, and describe the ways in which the proposed product is out of compliance.Vendors agree that their product will continue to conform with these requirements, and in the event potential violations are discovered, will arrange to have such issues resolved unless otherwise agreed upon exceptions are stated in writing.
G1.1.1 (Level A)
All meaningful images in the User Interface (UI) include a text alternative, in the form of alt text, that accurately describes the meaning or function associated with the image.
G1.2.2 (Level A)
Where video is provided, either in the product itself, or in the associated documentation, meaningful spoken dialog in the video includes closed captions produced by a person rather than an automated service.
G 1.3.1 (Level A)
Content is structured using proper HTML section headings (e.g., h1, h2) and proper lists (i.e., ol, ul, li) rather than formatting that just creates the appearance of a heading or list.
G 1.3.2 (Level A)
When navigating through elements of the UI and content using only the Tab key, the cursor takes a logical path, from left to right and from top to bottom.
G 1.4.1 (Level A)
When colour is used in a meaningful way, some method other than colour is used to represent that same meaning.
G 1.4.3 (Level AA)
When text is presented over a coloured background, a minimum contrast between the two of 4.5:1 for standard sized text, and 3:1 for larger text, is provided.
G 2.1.1 (Level A)
All elements in the UI or content that function with a mouse click, also function using only a keyboard.
G 2.4.1 (Level A)
Means are provided that allow assistive technology users, or keyboard only users, to skip past repetitive elements such as menus and navigation bars, using either bypass links, or WAI-ARIA landmarks.
G 2.4.4 (Level A)
All link text is meaningful either on its own, or within the context of other adjacent links, accurately describing the destination or function of the link.
G 3.3.1 (Level A)
Error messages are presented in a way that can be consumed by assistive technology without requiring the user to search through the content to find them, either presented consistently in one place on the page or using an ARIA alert role.
G 3.3.2 (Level A)
Forms are formatted in a way that explicitly associates labels with input fields, and sufficient instructions are provided to describe the expected input in each field.
G 2.4.7 (Level AA)
When navigating through the UI using the tab key only, the focus position is easily followed visually through elements on the screen.
G 4.1.1 (Level A)
(Exception: Meets this requirement to the extent that markup violations do not introduce barriers that affect access for assistive technologies.)
The markup of the UI complies with HTML5 specifications.
