Accessible procurement

Getting accessibility right during the tendering and procurement process is vital as it helps us fulfil our legal requirements from the very start and prevents 'buying into problems'.

Introduction

As a public sector organisation we have a responsibility under the Public Sector Bodies (Websites and Mobile Applications) (No.2) Accessibility Regulations 2018 (PSBAR), the Equality Act 2010 and the Public Sector Equality Duty to ensure that the digital systems/products we procure are accessible. 

This applies to both internal and external facing services. We have an equal duty to not discriminate against members of the public or our staff because of disability.

We do this by making sure all the products we buy meet the required standards, with clear evidence to support compliance with our legal responsibilities.

Questions for suppliers

As part of any tender response, ask suppliers to answer the following questions and provide the following details.

Describe in detail your accessibility testing process

Including the following details for both internal and external facing aspects of your products or services:

  • Frequency of accessibility testing
  • Standards you test against
  • What (if any) automated accessibility testing tools you use
  • Assistive Technologies and Browser pairings you use
  • Any user research completed with people who have additional access needs
  • What you do about identified issues

How compliant is your product/service with Web Content Accessibility Guidelines (WCAG) 2.1 AA?

Show how your solution/product meets the 50 success criteria covering all level A and AA of WCAG 2.1 or the equivalent within the EN 301 549 harmonized standard.

Suggested evidence for this:

  • Voluntary Product Accessibility Template (VPAT)
  • Accessibility audit report detailing areas of non-compliance
  • Any other evidence of testing for accessibility requirements carried out

You need to share compliance results for both front-facing and internal aspects of your products.

If not fully compliant with WCAG 2.1 AA, please provide as many of the following as possible

  • Remediation plan including timescales
  • A full list of non-compliances
  • Workaround guidance for users

Provide a compliant accessibility statement

This should ideally be in a format that matches the Central Digital and Data Office (CDDO) sample accessibility statement or provide as much required information as possible that it can be easily transposed to match the CDDO sample.

Provide a release schedule for future accessibility features

If your products are going to incorporate increased accessibility features in the future please tell us about these features and when we might expect to see them. Please also specify how you will maintain existing features.

What to look for in responses from suppliers

Supplier responses should include evidence to support supplier claims when it comes to accessibility compliance. Below is what to look out for.

Details of their accessibility testing process

Described in as much detail as possible, including:

  • Frequency of accessibility testing
  • Standards they test against
  • What (if any) automated accessibility testing tools they use
  • Assistive Technologies and Browser pairings they use
  • Any user research completed with people who have additional access needs
  • What they do about identified issues

Their response should cover both front-facing and internal aspects of their products.

Be wary if the supplier only uses automated tools for accessibility testing: automated tools don't catch all issues and in no way guarantee WCAG 2.1 AA compliance.

As a minimum, they should show evidence of everything in the list above, with the exception of user research which is a less common practice. 

  • They should tell you the tools they conduct testing with, how often, and what they are testing against (they should test against WCAG 2.1 or EN 301 549).
  • They should list assistive the technologies such as screen readers, speech-to-text software, magnification and OS/browser settings that they use for testing.
  • They should explain what they do about issues when they are found.

If they can't, these are red flags.

Level of compliance against Web Content Accessibility Guidelines (WCAG) 2.1 AA

We suggest evidence for this is:

  • Voluntary Product Accessibility Template (VPAT)
  • Accessibility audit report detailing areas of non-compliance
  • Any other evidence of testing for accessibility requirements carried out

Their response should cover both front-facing and internal aspects of their products.

At minimum you should expect either a VPAT or other accessibility audit report. This should clearly work through WCAG success criteria listing where issues occur, what the issues are and what WCAG success criteria they fail against.

If a supplier cannot produce one of these documents while claiming WCAG 2.1 AA compliance, this is a red flag.

If they cannot produce the document and say they pass on automated testing then you should not proceed with that supplier.

If anything is not fully compliant with WCAG 2.1 AA standards

They must provide as many of these as possible:

  • Remediation plan including timescales
  • A full list of non-compliances
  • Workaround guidance for users

Each of these requested pieces of evidence will be vital for you if an accessibility challenge is raised against any non-compliant solution/products you chose to proceed with. Without this evidence you open yourself up to additional risk under the regulations.

If you proceed knowingly with a product that does not meet your legal obligations, you must be able to show sufficient evidence that would lead you to believe that the supplier had:

  • thoroughly identified the severity of the issues;
  • had detailed plans in place to fix them,  and 
  • had worked with you to produce useful guidance for users to work around existing issues until fixes are deployed.

Ask them for a compliant accessibility statement

This should ideally be in a format that matches the Central Digital and Data Office (CDDO) sample accessibility statement or provide as much required information as possible that it can be easily transposed to match the CDDO sample.

Accessibility statements are straightforward to create with the results of proper accessibility testing. If a supplier does not have a current accessibility statement but is willing to provide one (or work with you to complete a statement to your satisfaction as part of the go-live process), this is acceptable.

Collaboration with the suppliers is the best strategy for producing an accessibility statement. Accessibility statements are created at the University so that we can make the content relevant to our institution, such as the people to contact if users need support or want to report an issue.

It's the responsibility of the developer to provide us with the information where a service/platform doesn't meet WCAG. Sometimes an accessibility issue may be caused by a customisation applied at the University, such as applying our colour scheme.

An accessibility statement must be published at the point any service goes live.

Release schedule for future accessibility features

If their products are going to incorporate increased accessibility features in the future, they need to tell us about these features and when we might expect to see them.

This helps you get a better idea of how seriously the supplier takes accessibility. If they can provide you with information on upcoming releases that includes how they are incorporating improved accessibility, it's good evidence that the supplier understands the topic and is likely to be able to deliver a compliant product / be open to supporting our legal requirements.

Review responses

The university Procurement Team can advise on overall compliance with technical standards for any new digital systems/products . 

For accessibility related procurement queries please contact opera@kent.ac.uk 

Last updated