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 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. Find out whether you may hold responsibility for 3rd party content.
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:
- Describe how the supplier will ensure the proposed solution (customer and staff facing) shall meet WCAG 2.1 AA compliance in line with the government requirements. This should include a description of how the supplier plans to test the final product against WCAG 2.1, their audit process or the audit process of the subcontractor they may involve for external testing. This should also include any information regarding how they would roadmap fixes if the final product is not compliant.
- Describe how the solution will support content upload compliance with WCAG where relevant. For example, what restrictions, options or guidance the solution will implement to help content creators upload or write accessible content.
If the developer is offering their own product that will be “customised” to your requirements:
- The proposed solution (customer and staff facing) shall meet WCAG 2.1 AA compliance in line with the government accessibility requirements - Public Sector Bodies Accessibility Regulations (2018). Supplier to provide test reports and relevant certification to evidence how they meet / don't meet WCAG 2.1 AA compliance. For example, a WCAG audit report, VPAT, evidence of assistive technology testing or user testing with disabled user groups. Supplier to provide their development roadmap for accessibility if their product partially complies.
- Describe how the solution will support content upload compliance with WCAG where relevant. For example, what restrictions, options, or guidance the solution will implement to help content creators upload or write accessible content.
- Supplier to provide a copy of the accessibility statement for their product covering core technical sections as required by the Public Sector Bodies Accessibility Regulations (2018). Or the supplier works with us to produce an accessibility statement for the proposed solution which meets our legislative obligation as a public sector body under PSBAR (2018) and is acceptable to us. Supplier provides / works with us to provide guidance for assistive technology users on using the solution. Guidance material required in all cases; additional guidance required to navigate areas of non-compliance with WCAG if present.
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:
- No information or other negative response
- “Our product fully complies”
- We use an overlay to maintain compliance
- VPATs
- Other detailed auditing documentation
- An accessibility statement
- Remediation roadmap
- Plans for testing
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
- no answers at all
- accessibility is not on their roadmap
- They have not done any testing to check compliance
- No one has ever asked about this before (including “you are the first Council/Uni/College/etc. to ask for this”)
- We are on X framework (such as Crown Commercial Services frameworks) so we must be fine, no further evidence supplied.
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 high risk and should not be dealt with.
“Our product fully complies”
Many suppliers will claim that the product they are trying to sell you fully complies with all WCAG 2.1 A and AA success criteria. In our experience this is in almost every case, incorrect.
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 call them out on this inconsistency and be very sceptical of doing business with that organisation.
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 and why we do not support their use, read our overlay guide.
If a supplier does respond that they are using an overlay we would suggest responding with the following:
We would like to clarify that we do not condone the use of overlays and are not willing to accept the legal risk associated with their use. The government department that monitors the regulations we must meet do not recognise overlays as an accepted solution, and overlays do not contribute to our legal compliance. Overlay products make many claims about making website meet WCAG 2.1, EN301549, Section 508 etc. All of these are false.
You can find more information on the Overlay Fact Sheet. The fact sheet is supported by a vast number of the best accessibility professionals in the field, and the industry overwhelmingly agrees to avoid the use of these snake oil products.
Many organisations in the US are being sued for staking their compliance claims on these overlay products, and recently a representative from the US Department of Justice referred to overlay use as "committing legal suicide". Beyond accessibility there are also other GDPR related concerns with overlay usage and their data collection.
We are not willing to sign off on the use of [X overlay product] and do not accept it as evidence of [Y website or system] complying with technical standards WCAG 2.1, or meeting our legal obligations under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018. If you proceed with the use of [X overlay product] on [Y website or system] which we plan to utilise as part of our digital estate, we will be forced to escalate this incompatibility as we cannot accept the legal risks associated and may not be able to proceed to contract.
We welcome your thoughts on this issue and what alternative arrangements you will put in place to evidence accessibility compliance.
VPAT
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.
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.
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. Read our guide for reviewing testing documentation.
You will want to look at:
- How they have tested the product
- What tools they have used
- Is there a mix between manual, automated and assistive technology testing
- How large was the scope of testing
- How serious the issues are or if the descriptions are vague
- What priority ratings they have given for issues
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 WCAG 2.1 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:
A significant scope which covers the majority of components across a platform through a representative sample
A mix of manual, automated and assistive technology testing.
- Manual testing is required to confirm several WCAG criteria that can only be done with human judgement such as whether things are correct in context.
- Automated testing tools can be used to deal with repeat issues that are easier to check with a computer such as comparing colour values for contrast, rather than trying to guess by eye.
- Assistive technology testing is vital to check that the platform works with common assistive technology and operating system pairings. This would include checking with common screen readers, dictation software, magnification techniques and non-pointer input devices such as keyboard controls.
A prioritisation of issues based on impact to users
Recommendations on how to fix issues. This may be more present in common easy to fix issues, rather than more complex issues for significant components which may require replacement.
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.