Building Accessibility Best Practices into Contracting
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
Accessibility-Procurement-Pilot-Modified.md
Accessibility-Procurement-Pilot.md
Australian-Procurement-Rules.md spacing Mar 30, 2017
BalancedContract.md
City-University-NY.md
EU-Functional-Accessibility-Requirements.md
EU-Solicitation-language-Web-based-internet-system.md
Government-of-Ontario-Outsourcing-Web-Development.md
Irish-Dept-Defence-procurement-requirements.md
Massachusetts-IT-Acquisition.md mark down Mar 28, 2017
Massachusetts-Mandatory-Contract-Language.md
NCDAE-Procurement-in-Accessibility-Policy.md
NY-State-IT.md
README.md
University-of-California-Guidelines.md
University-of-Montana.md
_config.yml
audit-scotland-procurement-requirements.md

README.md

Accessibility Contracting Best Practices

Building Accessibility Best Practices into Contracting

Most RFPs that talk about accessibility include something like:

We require that all purchases be accessible according to the Web Accessibility Initiative 
(WAI) Web Content Accessibility Guidelines 2.0 AA. 

or

All content, interfaces, and navigation elements to be used for this project must be 
compliant with Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines 2.0 AA. 
Compliance means that a person with a disability can percieve, operate and understand the 
interface the same as a person without a disability.

Concerns

  • Don't ask that a vendor commit to making a site meet a set accessibility target if there isn't a clearly defined set of deliverables or a flexible budget.
  • Ensure that whoever is driving the design & functionality requirements for the site have a good grounding in accessibility. Decisions made by the client often meet other organizational needs. If the person deciding on behalf of the client isn't aware of accessibility implications of their decisions then it may affect the delivery of the end product.

Don't include in RFP

  • Any specific requirements to use Web Accessibility Initiatives – Accessible Rich Internet Applications (“WAI-ARIA”) to further enhance accessibility. If used properly it will, but it doesn't add anything beyond WCAG 2.0 AA above and can destract from accessibility if it is implemented poorly.

Ten Steps for Accessible IT Procurement

Based roughly on Smart Practices for Addressing Accessibility in Vendor Contracts

  1. Set up an internal Accessibility Policy
  2. List goals (like WCAG 2.1 AA), your internal policy as well as any government regulations you must comply with
  3. Ask for details on how the vendor will meet accessibility goals. Make sure these do not rely exclusively on automated tests
  4. Make sure that your RFP is accessible and that the proposals are also created in an accessible format
  5. Clients should have people knowledgable about accessibility as part of the procurement process and should be asking questions about the process to demonstrate that this is important
  6. Not all products have a VPAT. Most VPATs are mostly marketing. If a VPAT is produced by a recognized 3rd party, it can provide some useful insights. It is the client's responsibility to ensure that they underestand it, so ask questions
  7. Make sure that you have understanding about the contract. There are other examples here of what you might want to consider
  8. Do an independent evaluation. If you are hiring a firm to build a customized solution, make sure you test it before it is launched. The vendor should know this will happen.
  9. See that you have processes in place to escalate accessibility problems when they come up. There will be new barriers identified as people start using the technology, make sure there are processes in place to deal with them quickly.
  10. Set up a monitoring agreement with a 3rd party to see that you get informed of new issues when they come up

Questions for the Procurer (Client):

  • Is there an established accessibility procurement policy or a procurement policy where accessibility is explicitly mentioned?
  • The procurement contract should include language that specifically documents how satisfactory progress on accessibility will be measured.
  • If the product is currently accessible, the contract should include language that assures continued accessibility as the product is updated.
  • Is there a 3rd party audit built into procurment?
  • Do your boiler-plate contracts state that your organization owns the IP generated? If you are using open-source software, do you explicitly support fixing problems (or even reporting) problems in the source libraries?
  • Do you use a "work for hire" policy which traps all intellectual property done with institution money/time? Is it possible to explicitly exempt open-source contributions or encourage contributions?
  • How are you planning to use the product?
  • How are Voluntary Product Accessibility Template (VPAT)s seen & evaluated within your institution?
  • Do they have an [Accessibility Statement(https://github.com/accessibility/Accessibility-Statement/) or Accessibility Policy - if so it should be included.

Internal expertise

  • Is there a Accessible Technology Initiative (ATI) person in your organization who can help ensure consistent implementation of Accessible ICT procurement procedures?
  • Who on the organization's side is responsible for evaluating accessibility of the product delivered?
  • Who oversees the review of ICT accessibility compliance documentation?
  • Who coordinates with ICT vendors to resolve issues with accessibility support or documentation?
  • Who is the primary contact for questions regarding Accessible ICT procurement?
  • Does someone coordinate the delivery of Accessible ICT procurement training programs in your institution?
  • Has Vendor inability to provide accessible products has affected purchasing decisions? Who maintains a success/failure record in your institution?
  • Will someone be able and willing to submit problems to the product's issue tracking system?
  • When a product has a fix for a problem that you have identified, who will be able to verify the fix?
  • Who is maintaining the list of what assistive technology is supported?
  • Who is the primary accessibility lead within our organization?

In section listing the various questions that Vendors need to respond to, include:

Product

  • Are all interfaces (both for administrators and end-users) that are part of your product compliant with WCAG 2.0 AA?
  • Does this product meet any targets for ATAG 2.0 AA, Part B?
  • Who will pay to remediate any necessary fixes after purchase?
  • If your product is not WCAG 2.0 AA compliant, do you have a roadmap to make your product fully compliant? If so, include your roadmap.
  • 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?
  • If you have created a VPAT, is it prepared by a 3rd party?
  • What standards are you using to evaluate accessibility?
  • How are accessibility features documented? Are they discoverable by the user?
  • Is this product being used by accessibility focused organizations and are there any reviews by them.
  • WCAG related accessibility barriers are categorized as bugs; not feature requests

Process

  • Describe your accessibility conformance testing process.
  • Describe measures you've taken to ensoure your IT products or services are accessible.
  • Is there an open issue queue of known accessibility issues for the IT product?
  • If there are known barriers for users, vendors should be asked to make a commitment to improving accessibility over a specified timeline.
  • Has your team ever worked with Accessibility as a functional requirement?
  • What are your company's internal standards for developing with accessibility in mind?
  • Does your company have a road map for accessibility going forward? If so, can you give us a general outline (goals / milestones)?
  • Have you tested and/or developed your mobile apps (especially iOS) with accessibility in mind?
  • What automated tools do developers & designers use to evaluate their work?
  • Describe the steps you take for manual testing of your interface.
  • How are you keeping pace with the changes in Assistive Technology?
  • What training do you give to your staff to see that inclusion is understood?

Experience

  • Do you have clients who require web accessibility? If so, in outline, how are they ensuring your product meets their requirement?
  • 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?
  • What experience do developers on your team have coding for accessibility?
  • Have your developers contributed to any open-source accessibility work you could link to?
  • How do your developers and designers stay up-to-date with best practices with web accessibility?
  • What resources do you refer to for information about addressing accessibility?
  • Have you adopted a Policy-driven Adoption for Accessibility (PDAA) framework to demonstrate the extent to which your organization has implemented accessibility best practices?
  • Does your website & proposal reflect knowledge of accessibility? How well does the vendor site score with automated tests like http://wave.webaim.org/ or https://tenon.io/

Useful Links