ICT Procurement Language

We know that drafting Requests for Proposals (RFPs) and Scope of Work documents for RFPs can be a daunting task. For persons and companies that are new to writing accessibility-conscious RFPs for Information and Communications Technology (ICT) related products and services, we have prepared some language that may be appropriate to include in your requirements. 

Compliance with Standards

It perhaps isn’t uncommon for RFPs to include criteria like the following (the portions that are in bold brackets would change based on your company):

Solutions must comply with all applicable laws and regulations commonly found in a [corporate/higher education/etc.] environment as well as timely implementation of compliance with future changes to laws and regulations. Current laws and regulations include, but are not limited to:  [FERPA, CleryAct, COPPA, HIPAA,] ADA and Section [504 and 508] compliance, etc.

This is a great place to start as it introduces the laws and regulations that your company wants to comply with. However, when you expect a vendor to give a simple yes or no kind of response to a list of laws and regulations like this, it is easy for the vendor to answer this question based on the regulations it is more familiar with and assume compliance with the regulations it is less familiar with. This is why, at the minimum, we suggest that you also include criteria like the following:

Describe how your solution and its digital support interfaces meet the accessibility requirements outlined in [your company’s accessibility policy–if you have one–and in] the revised Section 508 standards or the level A and AA criteria of [WCAG 2.0 or WCAG 2.1].

This description should be in the form of one or more Accessibility Conformance Reports (ACR) that are based on version [2.0 or later] VPATs. The ACR should clearly note the compliance level (Supported, Supported with Exceptions, Not Supported, and Not Applicable) for each area of your solution and include an estimated date for completed remediation of all areas that are considered Not Supported. Detailed remarks that describe the testing methods and identify the features that are non-compliant are preferred.

Also in your proposal, please provide the following information about your ACR(s):

  • What improvements, if any, have been made since the evaluation’s completion?
  • Was the evaluation conducted by a 3rd party (someone outside the vendor’s company) or internally by the vendor?
  • Have the ACR(s) been reviewed by a 3rd party?
  • (If applicable and possible) What is the job title of the auditor and the name of the organization that they represent?

This requirement doesn’t guarantee that the solution provided by the vendor is compliant with accessibility standards. Still, it does give you evidence as to whether or not the vendor has put some thought into the accessibility of their product. If the vendor does not have an ACR, it may mean that they haven’t put a lot of thought into their solution’s accessibility. If the vendor can provide the ACR, then some thought has been given but the quality and depth of thought isn’t always exposed until the vendor provides the added information in the bulleted list. For example, an ACR from before 2018 (which would not align with the revised Section 508 standards) might suggest that the vendor was interested in accessibility at one time but may not be focused on it now. Additionally, if the audit was conducted internally or by a questionable 3rd party, it could suggest that the vendor knew that companies are looking for these kinds of reports but may not be quite as concerned with accessibility for accessibility’s sake.

As the reports requested above will not always be reliable, we also recommend that you require additional evidence through either or both the technical proposal and demonstration. By doing this, you allow the vendor to provide information that may be more up-to-date than what is in the report and allow them to provide details that could increase your confidence in the vendor. As an added bonus, you will communicate to the vendor that your company takes accessibility seriously and will be less likely to adopt an inaccessible product or service. Here is some language that we suggest:

Provide details on how your solution(s) and digital support interface(s) meet the following requirements:

  • Your solution and support interfaces can be fully controlled using only keyboard commands, as outlined in WCAG 2.1.1.
  • A focus ring is visible, as outlined by WCAG 2.4.7.
  • The tab and reading order progress through your systems in a logical order, as outlined by WCAG 1.3.1, WCAG 1.3.2, and WCAG 2.4.3.
  • Appropriately strong color contrast between foreground information (text, interface control symbols, and focus ring) and their background is used, as outlined by WCAG 1.4.3.
  • All statuses and other forms of information are conveyed by more than color, as outlined in WCAG 1.4.1.
  • All important information is available to two or more senses, as outlined in WCAG 1.4.1 and WCAG 1.3.3. Color, size, shape, and location information is not typically conveyed by screen reader technology to visually impaired individuals. Information conveyed only through sound is not accessible to persons with hearing impairments.
  • (Preferred) The text in your solution and support interfaces is not justify-aligned and has appropriate line and paragraph spacing, as outlined in WCAG 1.4.8.
  • The text in your interfaces can be magnified by at least 200% without loss of usability, as outlined by WCAG 1.4.4.
  • All non-decorative images have text alternatives (usually alt text), as outlined in WCAG 1.1.1.
  • All audio-only content is transcribed, as outlined by WCAG 1.2.1.
  • All video content containing audible speech is captioned, as outlined by WCAG 1.2.2.
  • All videos that contain important, purely visual information have audio descriptions, as outlined by WCAG 1.2.5. If audio descriptions are not available, then descriptive transcripts are provided, as outlined by WCAG 1.2.1 and WCAG 1.1.1.
  • (Preferred) All video and audio content use appropriate contrast between foreground and background audio, as outlined by WCAG 1.4.7.
  • All moving, blinking, scrolling, and auto-updating animations can be stopped, paused, or hidden, as outlined by WCAG 2.2.2.
  • All blinking or flashing content adheres to the flashing threshold outlined in WCAG 2.3.1.
  • All form fields, controls, and other inputs are appropriately labeled, as outlined in WCAG 1.3.1, WCAG 3.3.2, and WCAG 4.1.2.

If this list is included in the technical proposal, it may be appropriate to make each list item separate criteria in order to make the organization of the proposals you receive a little easier to read.

Practical Use Criteria

In addition to RFP criteria that help you assess the vendor’s compliance with accessibility standards, we recommend adding criteria related to actual use. For example, a 155 inch, touchscreen TV for lecture presentations may meet the criteria listed above. Still, if it is mounted at a height that the touchscreen cannot be fully utilized by a person in a wheelchair, then the product is still inaccessible unless an alternate input device can be used. 

Criteria about an ICT related product or service’s use will vary, but we were able to come up with some criteria related to software and input device compatibility. Some of these criteria may be best assessed through demonstrations, but we’ve written them as if they would be included in the technical proposal’s requirements. We’ve also gone a step further with some of these criteria and asked for support documentation. Our reason behind this is to make sure that you have a copy or know how to access these critical pieces of information before a person with disabilities requests them.

  • If your solution prevents other programs from running at the same time as your program, describe your solution’s ability to whitelist assistive technology like screen reader programs, text-to-speech programs, eye tracking software, and dictation software. If these programs cannot be whitelisted, describe what built-in alternatives your solution has and provide documentation on how to activate and use these features.
  • If your solution has built-in assistive technology (text-to-speech application, dictation tools, text resizing application, high contrast mode, etc.), provide documentation on how to activate and use these features. Also, provide information regarding these features’ compatibility with assistive technology that users may already be using when accessing your solution.
  • If your solution is available on a mobile device and/or through a mobile app, provide information about your solution’s use of responsive layout and about your solution’s ability to be compatible with the mobile device’s accessibility features.
  • Describe how your solution can be fully controlled using only keyboard commands and provide documentation, like Adobe’s Keyboard shortcuts in Adobe Connect and Deque’s guide to NVDA’s keyboard shortcuts, for any specialized keyboard commands your solution uses.
  • Describe how your solution can be fully controlled from a touchscreen device and provide documentation, like Apple’s VoiceOver gesture guide for iPhone, for any specialized gesture commands your solution uses.
  • If your solution uses touchscreen input, describe how your solution able to be used by a person who is blind and/or has mobility impairments. Also, provide documentation, like  Apple’s VoiceOver gesture guide for iPhone, for any special touch gestures your solution uses.
  • Describe how your solution can be fully controlled using speech recognition technology and provide documentation, like Windows Speech Recognition Commands, for any specialized voice commands your solution uses. 
  • Describe your solution’s compatibility with other alternate input devices such as switches, sip-and-puff pipes, and eye tracking technology.
  • If your solution is programmed to time-out, the time-out feature follows the requirements of WCAG 2.2.1.
  • If contacts for support are provided in or on the solution, indicate if the contact options include a phone number, a TTY phone number, a chat option, and/or email address. If only a phone number is provided, someone who cannot speak cannot seek help. If someone is unable to quickly and easily use a chat or email option, a phone number may be preferable.

Specific to Physical Solutions

If the solution you are looking for is a physical device, you will likely want to include the following criteria as well.

  • Indicate if your product requires more than 5lbs of pressure to operate and/or provide routine maintenance.
  • Indicate if your solution has input controls that are normally located at heights greater than 36-38 inches.
  • If your solution has text printed on it, indicate if there is braille signage and/or raised lettering that conveys the same information then describe where it is located.
  • If your solution requires touchscreen input, describe how your solution is able to be used by a person who is blind and/or has mobility impairments. Also, provide documentation, like  Apple’s VoiceOver gesture guide for iPhone, for any special touch gestures your solution uses.
  • If your solution requires touchscreen input that cannot be made accessible to persons with visual and/or mobility impairments, does your product have a mobile app alternative? Describe the accessibility of that mobile app, if a description has not been provided in responses to earlier criteria.
  • Describe how your solution meets other applicable ADAAG standards.