Procurement accessibility guidance

Tagged with:

If you are currently procuring any website, system, mobile app or other content or hiring a 3rd party to develop digital content or systems for you, then you must ensure that you are tying the 3rd party / supplier / provider to meeting your legal obligations when it comes to accessibility, for example helping you to meet the requirements of the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.

Public sector responsibilities

Public sector bodies are in scope of accessibility regulations and as such all legal responsibility falls on the public sector body, developers and contractors cannot be held accountable unless you specifically tie them to meeting the legal obligations within contract documentation and make sure to get evidence during procurement.

There are many complexities when it comes to regulation responsibilities and 3rd parties. We have more information on these complexities in our 3rd party content responsibilities guide.

Going to tender

When you are putting together your requirements, you should make sure to include accessibility in what you ask the developers to agree to. Include the following in the tender requirements.

If the developer is bidding to create a system to your specification:

If the developer is offering their own product that will be “customised” to your requirements we set out the following expectations:

Reviewing tender responses

Assuming you have used the previous questions to get information from suppliers on how their systems will meet your requirements, you should have received some information back that broadly fits into the following categories:

The below sections provide further information on what these responses might look link and how best to respond to or interpret different responses and evidence.

No information or other negative response

The range of poor responses you might receive from suppliers can be quite broad. You may receive anything including

If a tender response cannot provide any information to show that they are aware of the legal accessibility requirements for their customer base and know how to deal with requests and have appropriate evidence, then they are significantly higher risk.

Remember that we all first learn about accessibility at some point. For many suppliers, this might be the first time they are being made aware of the requirements. The important thing is how the supplier responde to these requirements. If they approach it proactively and try to make fixes and are operating in good faith then that is one thing, but conversely they may dismiss the need because it has been "unimportant" up till now. The supplier's direction from this point is important.

Remember, you as the public sector body hold all the legal responsibility. If a supplier that does not know what they are doing delivers you an illegal product, you are responsible if something goes wrong.

“Our product fully complies”

Many suppliers will claim that the product they are trying to sell you fully complies with all WCAG A and AA success criteria. In our experience this is in almost every case, incorrect.

If a supplier says this in the tender response, you should be immediately sceptical. Any large or complex product will almost never be fully compliant just on the size alone.

Most times we have seen this response provided; the supplier will answer following questions explaining that there are a limited number of areas where the product has current issues against WCAG. This might be in a written response to one of the tender questions or can be identified through documentation such as a VPAT or audit report as mentioned below.

If you receive a response from a supplier which says “fully compliant” and then receive documentation which does not say they are 100% perfect, you should immediately raise this inconsistency and be sceptical of their documentation. Consider:

If you receive documentation which shows a clean slate for accessibility, also be sceptical and ask to be able to do your own testing. As has been said, most of the time, any suitably large system will not be perfect, and sometimes that has to be accepted but you are looking for an accurate state of the system not clean documentation just to get past the check.

Using an overlay to maintain compliance

More and more we are seeing suppliers state that they are using an "overlay" product to deliver accessibility for their service. Overlay products are touted as additional plugins which you add onto your website or service which will then adjust pages to make them WCAG compliant without you having to test and remediate issues. These are false claims.

If you want to find out more about overlays, why we do not support their use, and how to respond to suppliers who use overlays read our overlay guide.


VPATs are a type of document which provides a very basic level of information on the accessibility of a digital product. This will normally be in the form of a table listing each of the WCAG success criteria an identification of their compliance, and some notes. VPAT's are part of the American Section 508 requirements, but have become an internationally used piece of accessibility documentation.

The problem with VPATs is that they are normally not detailed enough to give useful information on the true level of impact for a service.

For example, a VPAT may say for a digital system that it partially complies with 2.1.1 Keyboard (A). The notes read “Some areas of the product are not accessible to all keyboard controls”.

The question you should be asking is what does “some” mean? Is it the main navigation for the platform? Is it all main content? Or is it a logo in the footer?

If the navigation is not accessible or the main content is not accessible but other content is, then that still counts as some but would mean that a wide range of users would not be able to interact with the product at all.

If you receive a VPAT that includes vague statements such as the above, which could mean a potential massive risk, or you are not sure, ask the supplier for more detailed information on the exact areas of the product that the issue covers, and refuse to sign any contract until you see a more detailed list. A VPAT can only have been produced correctly following in-depth testing. They are summary documents and so the detailed test results must exist.

You should also be asking for a detailed remediation roadmap. If they are already aware of several issues as detailed in their VPAT, ask them for evidence of how they are planning to fix those identified issues. If they have no answer, refuse to sign a contract until they do.

Other detailed auditing documentation

If the supplier responds with detailed testing documentation for the product you should look through the documents carefully.

You will want to look at:

If there are any issues present in the detailed documentation you should ask for a detailed remediation roadmap. If they are already aware of several issues as detailed in their detailed documentation, ask them for evidence of how they are planning to fix those identified issues. If they have no answer, refuse to sign a contract until they do.

Accessibility Statement

The accessibility statement is the end of the documentation journey. If the supplier can provide you with an accessibility statement, this is an insight into their testing process. If the statement is good, and has useful information on issues and even suggested workarounds already this could be a positive sign.

If the statement is poor and does not include specific information about technical issues and their affects on users, but instead includes vapid statements about "commitments to support all users" this could be a sign that they do not have meaningful practical documentation to back this up and show what actions they are taking to deliver on those commitments.

In either case, if an accessibility statement is provided as the main piece of evidence you should respond asking for other detailed auditing documentation which must have been used to create a good accessibility statement, or is what is required in the event a poor statement is provided, which is not enough to proceed by itself.

Remediation roadmaps

In the event that you receive detailed documentation from a supplier that includes identifying issues as well as remediation roadmaps which go into detail about when each issue is planned to be fixed, this is an excellent response and should show that the supplier is aware of issues with their product, are working to fix them and can provide you as the customer with significant evidence to support due diligence.

Plans for testing

Sometimes, particularly with new products that are either being designed bespoke for you or are a new launch from the supplier, thorough testing and road mapping may not yet have taken place. In this case you would expect to see information from the supplier about how they plan to test the product and what they will do about issues found during that testing.

Ideally you will be looking for suppliers to commit to testing against the latest WCAG A & AA success criteria as a minimum. This can be done either in house if they have the skills, or by a subcontractor such as professional accessibility auditing companies. In any case the testing should include:

Post procurement and contracts

Once you have completed your tendering process and have decided to enter into an agreement with a supplier, it is important to keep accessibility compliance in the requirements.

The best way to do this is to include accessibility into contracts with suppliers. For more information, read our guide on accessibility in supplier contracts which includes example contract clauses.

Share on: