Everybody wants their website to be accessible. Information and Communication Technologies (ICT) is key for any modern organization. In the Government of Canada, it is a clear part of the Liberal Party's mandate. Setting a strong policy direction is critical, but then what?

Most departments still see accessibility as a one-liner that can be added to an ICT contract. Then the responsibility for any shortfalls lies on the vendor.

Sadly, this doesn't work. Accessibility is a journey, not a destination.

Web accessibility is complicated, the ecosystem and use cases change over time. So what can procurement do to fix this? I've collected a series of examples good accessibility procurement practices. I am hoping to add to this with some good Canadian examples.

Start Off Right

The first thing that government RFPs & contracts can do is set a good example.

So often these documents are overly complicated and are very difficult to understand. Make sure that these documents are written in plain English so they are easy to understand. In writing this blog post I've used the HemingwayApp.com to check that my ideas are easy to understand.

PDFs have well-known accessibility problems with them. You can make them quite accessible with considerable effort, but it isn't a best practice. Use PDFs only where a signature is required. Otherwise, it would be more accessible to send EPUB or OpenDocument files. Vendors should not be asked to produce more PDFs as part of the contract.

Focus on the Process

Don't obsess on the end result. As with security, there are going to be things that are missed. Of course, everyone wants a site that is as accessible as it can be, but ultimately there are other goals as well.

The earlier accessibility efforts are brought into project planning, the better the results will be. So, vendors should be asked about the process that they use to build in accessibility. You need to know that they have a team onboard who has experience addressing this complex issue. It is also important that there is a clear and open feedback channel for people who face barriers. People with disabilities need to be part of the process.

It would be good to ask for a description of how the vendor overcame a difficult accessibility challenge. Sometimes you need to make compromises that may balance design or usability requirements. Often there are multiple ways of doing things and no clear best practice.

Open

I'm big into open source software (OSS). As Drupal 8 Core Accessibility Maintainer, I'm also not sure how we can make progress without OSS.

Starting with an existing OSS application means that you are able to begin a project with one that has had some testing already. It will have a list of bugs that are known, and hopefully a longer list of bugs which have been fixed.

Many people choose Drupal as it is the most accessible platforms in the world. Unfortunately, most do not contribute to improving its accessibility. If a vendor is proposing an open source solution, ask how they are working to improve its accessibility. Contributing back is key to the success of any effective community project. Furthermore, clarify the process when the vendor finds accessibility errors. Vendors should be submitting bug reports and patching the code when errors are found.

Testing

The vendor and the client both have a responsibility to do testing as the product is developing. Both should be doing regular spot checks with tools WebAim's WAVE Toolbar. It also takes very little time to learn how to do keyboard only testing. There is no reason why even non-technical people can't use these approaches to catch basic errors.

Screen reader testing requires considerable experience to be effective. Having a developer run a site through VoiceOver or NVDA just isn't good enough. Contracts should have a component in them to ensure that a 3rd party is engaged to provide an evaluation. It should be considered no different than hiring an editor to review the work of an author. If possible, this evaluation should engage people with disabilities.

Sales vs Delivery

The focus needs to be on the process of the vendor and how that will ensure a more accessible delivery. Things like the Voluntary Product Accessibility Template (VPAT) are still essentially sales documents. For some more detailed approaches, see:

• Partnership on Employment & Accessible Technology (PEAT)
• Ireland's National Disability Authority

OECD Playbook

Canada is a member of the Organisation for Economic Co-operation and Development. I was happy to be part of a meeting called by Treasury Board to discuss reforming the OECD Playbook for ICT Procurement. It is clear that there is a deep interest in government in doing procurement differently to get more accessible results. A big part of this goes back to learning to embrace open source and to collaborate outside of government silos. It is great to see many instances of people working together to learn how to implement technology better. We need much more of this!