Procuring Accessible Content

Organizing the Procurement

• Form a diverse working group including stakeholders from procurement, IT, disability/accessibility, students, teachers/professors, and administrators.
• Involve the working group throughout the procurement process, from specifications development to vendor meetings.
• Prior to procurement, collect information about existing digital accessibility barriers within the organization.
• Accessibility Services Offices and adaptive technologists are valuable sources of information regarding barriers faced by students with disabilities.
• Reference policies or documentation outlining commitments to accessibility in existing processes.
• Incorporate accessibility criteria, as required by the AODA, into procurement processes for large purchases or critical digital tools.
• Many American universities have policies for digital accessibility procurement due to Section 508; use them as a framework, adapting details to the Ontario context.

Determining Specifications

• Identify specific AODA requirements applicable to your organization (see Legal Requirements). Keep in mind that there may be changes to these legal requirements in the future.
• Consider incorporating accessibility specifications into your procurements by establishing a policy defining the desired level of accessibility.
• Avoid vague statements in solicitations; instead, specifically reference the accessibility requirements the product should meet.
• Acknowledge that a general reference to "comply with AODA standards" may be meaningless due to the absence of specific AODA standards on procurement.
• Tailor specifications based on the type of procurement (hardware, software, tablet, phone) and intended functionality/purpose (voice communication, video transmission).
• Include seemingly irrelevant specifications (e.g., for video and audio) to ensure full accessibility, especially if the product documentation includes embedded multimedia.
• There are two main tools to help you define specifications in procurement documents: one from the Canadian government and one from the US government. They are based on very similar, but slightly different, standards. The Canadian tool is more applicable to Ontario institutions as it does not refer to specific American legislation, however, currently it is not based on the most current version of the ETSI.

Incorporating Specifications into Solicitations

• Federal accessibility requirements in the U.S. and Europe have significantly increased the availability of globally accessible products.
• Market research is essential to inform procurement strategies and identify accessible products.
• Vendors often provide Accessibility Conformance Reports (ACRs) or Voluntary Product Accessibility Templates (VPATs) to outline their accessibility status.
• Engage vendors in conversations about accessibility during the procurement process.
• G3ICT's Discussion Guide recommends meetings with selected vendors, seeking clarification on accessibility specifications, inquiring about their accessibility experience, and requesting product demonstrations.
• Solicitations and Specifications should:
  • Include explicit references to the organization's accessibility commitment and standards, aligning with AODA obligations.
  • Provide precise details in solicitations, outlining product or service requirements, including accessibility criteria.
  • Specify that tenders for new products must include accessibility considerations in the design and development process.
  • Guide vendors on demonstrating accessibility conformance, specifying documentation expectations, testing, user scenarios, and plans to address known gaps (See Section508.gov for a template of instructions to vendors).
  • Request VPATs from vendors, emphasizing the importance of accessibility.
  • Seek references specifically addressing the accessibility of the product.
  • Clearly articulate when specifications are minimum acceptance criteria and how they will be evaluated alongside other factors.

Download a checklist of Accessibility Questions to Ask Vendors

Interpreting Vendor Claims

VPATs and ACRs:

• Accessibility Compliance Reports (ACRs) or Voluntary Product Accessibility Templates (VPATs) validate vendor claims of accessibility.
• VPATs, based on Section 508 or EN 201 549 standards, are generic templates used by companies to report on a product's accessibility.
• For commercial off-the-shelf products, VPATs are usually available online, providing insights into a product's accessibility.
• VPATs are not audit reports but are based on audits performed by vendors. Caution is advised, as they may exaggerate accessibility.

Red Flags:

• Old versions of VPATs (VPAT 1.X) or those dated over 12 months indicate potential lack of updates.
• Incomplete VPATs, non-standard language use, or one VPAT covering multiple products can raise concerns.
• Unstated evaluation methods, consistent use of the term "Supports" for all criteria, or minimal content in the "Remarks" column may indicate issues.
• Authors marking many criteria as "Not Applicable" without explanations can be suspect.
• Vendors are using an accessibility overlay on their website. Accessibility overlay tools are automated software solutions that claim to detect and fix web accessibility issues. This is a quick fix and an indication that an organization does not consider accessibility in their approach and they lack the resources or knowledge to properly address accessibility issues.

If Red Flags Are Encountered:

• Quick tests, like keyboard accessibility checks or form submissions, can validate some VPAT claims.
• If results don't align with the VPAT, it may be unreliable, necessitating independent testing for accuracy.
• Questions to the vendor can address concerns, such as outdated VPATs or criteria marked as "Not Applicable" without explanation.

Signs of a Reliable VPAT:

• Third-party-authored VPATs demonstrate greater expertise and objectivity in assessing accessibility criteria.
• Detailed content on the VPAT cover page, including testing specifics and assistive technology used, indicates rigorous testing.
• Examples demonstrating how the product meets specific success criteria showcase an understanding of accessibility.
• Publicly available VPATs indicate the vendor's confidence in the report's accuracy.

Download a checklist for Evaluating Vendor Claims

Evaluation and Non-Conformance

• Government of Canada’s ICT Accessibility Requirements Wizard offers evaluation templates matching specifications.
• Determine minimum accessibility requirements and criteria to be evaluated, considering legal requirements and product quality.
• Prioritize accessible products when both accessible and inaccessible options meet needs.
• Consider higher accessibility expectations for critical or widely used products.
• If procuring a product not fully meeting accessibility specifications, document the decision and provide an explanation upon request.
• Develop an equally effective alternative action plan when a fully accessible product is impractical.
• Proactively create an action plan for known issues or reactively respond to individual requests.
• UDL (Universal Design for Learning in Higher Education) on Campus provides resources for developing equally effective alternative action plans, mainly based on American standards.

Contract Language

Once a product and vendor have been selected, the contract will incorporate the various accessibility specifications, including how delivery will be tested and confirmed, and how non-conformance will be addressed. The following is a checklist of things to consider when finalizing contract details:

• Include accessibility specifications in the contract, specifying the applicable standard (e.g., WCAG 2.1 Level AA).
• Define procedures for handling exceptions to standards and specifications.
• Agree on deployment and support procedures, ensuring the vendor's dedicated support team covers accessibility.
• Provide comprehensive information on testing and delivery.
• Make the vendor responsible for remediation if the product is inaccessible, including delivering a new product or returning money.
• Include provisions for soliciting feedback from vendors and users.
• Specify the vendor's responsibility to remediate identified barriers.
• G3ICT offers a resource on "9 Steps to Procuring Accessible ICTs for Inclusive Education".
• Section508.gov provides sample contract language for various ICT services, adaptable to specific accessibility standards. This language will need to be adapted to refer to the specific accessibility standards of your college or university, instead of the Section 508 requirements.