This accessibility in procurement guidance has been created in collaboration with RNIB (Royal National Institute of Blind People) to ensure consistent world leading accessibility standards are embedded within all products or services to benefit everyone involved in its delivery. This is part of an ongoing relationship to make the UK Higher Education sector more inclusive and accessible to all.

We hope that the template will be of use to others, but as with any procurement exercise, these clauses may be adjusted to your organisation needs, and we suggest that you still seek your own advice before use.

Public Sector Bodies 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 they procure are accessible. 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.

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'.

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.

The intent of this guide is for you to be able to use the following example digital accessibility requirements in tender and technical or functional requirements documentation when procuring Software as a Service (SaaS) products.

SaaS can cover a wide variety of digital purchases (and range of included content) such as commissioning a new website, the production of digital documents for marketing campaigns, 3rd party applications, mobile apps, or systems, and other digital content.

Coverage

The requirement to be accessible applies to both for front-end (customer, students, members of the public) and back-end (staff) aspects of systems and services. This means that we need to ensure that the entirety of the service is accessible, including the following:

• external facing screens;
• internal facing screens;
• administration facing screens;
• password verification systems;
• authentication processes; and
• all communications, including emails, generated document formats, confirmation user action, receipt of acknowledgment, requests, additional correspondence, requests for further information, and use of third-party plugins.

Relevant Regulations and Standards

When receiving responses from suppliers, they may reference different standards depending on where they are based. It is good to understand the following relevant regulations and standards to accessibility in procurement and the information different compliance documentation may contain. The list below is a quick reference of some of the key requirements:

• PSBAR – Public Sector Bodies (Websites and Mobile Applications) (No.2) Accessibility Regulations 2018 (PSBAR) which requires evidence of compliance with WCAG 2.2 and an accessibility statement.
• EU Web Accessibility Directive – The EU equivalent of PSBAR. Differs between EU members states but all require evidence of compliance with WCAG (under the banner of the EN 301 549 harmonised standard) and an accessibility statement.
• EU Accessibility Act 2019 – Will require evidence of compliance with WCAG 2.1 or better and other standards for physical accessibility for electrical hardware as well.
• Section 508 – The American standards which require evidence of WCAG compliance for 2.0 or better. Is evidenced through a VPAT.
• WCAG – The Web Content Accessibility Guidelines. The underlying technical standards that all others refer back to.
• ATAG – The Authoring Tools Accessibility Guidelines. A subset of WCAG requirements and additional points focussed on accessible authoring tools.
• EN 301 549 – The European harmonised standard which aligns WCAG requirements with a wider range of formats including documents.
• VPAT – A type of WCAG checklist used to evidence levels of compliance under Section 508. Originally an American thing but have become more of a common widespread document.

General guidance

We recommend where possible, you involve your organisations digital accessibility officers in the review of any supplier responses received during a procurement exercise. It is important to get the feedback of accessibility professionals to be able to correctly judge the quality of documentation provided by suppliers.

For example, if a supplier provides an accessibility roadmap it should be reviewed by an appropriate accessibility professional outside the project. They weigh up the potential user impact, proposed mitigations, and consider the availability of alternative products. They may approve or not; approval may be subject to specific mitigations being implemented as a prerequisite to purchase.

If you do not have accessibility specialists to review your supplier responses, please refer to our Reviewing procurement responses guide which give some suggestions on what you should be looking for in different response and documentation types.

Contracts

When you have chosen your supplier, use the Make Things Accessible SaaS contracts accessibility clauses to embed your accessibility requirements into the final delivery.

When you are putting together your requirements, you should make sure to include accessibility in what you ask the suppliers to agree to. Depending on what kind of SaaS product you are procuring, you may have a different selection of requirements or be expecting different evidence from suppliers. In the sections below we describe requirements for the following types of SaaS procurement:

1. Supplier is offering to create a system to your specification (bespoke product).
2. Supplier is offering their own product that will be “customised” to your requirements.
3. Supplier is offering a Commercial Off the Shelf (COtS) Product.

The 8 requirements listed below should be applicable in all cases. For further clarification on what responses are appropriate to each requirement for different system requirements, we have put together further guidance on scoring and maturity in procurement.

Option 1: Bespoke system to your specification

If a supplier is offering to create a system to your specification, they will not necessarily be able to provide you with documentation for a system’s compliance at the tender stage but should instead provide clear detail about how they plan to develop your system to accessibility standards and how they plan to test and evidence this compliance.

Option 2: Supplier product that will be “customised” to your requirements

If a supplier is offering their own product that will be “customised” to your requirements, they should be able to provide compliance documentation for a “default” version of the platform and be able to clarify how much customisation they offer to customers, and what impacts that may have on accessibility compliance and how they support mitigating those risks during the implementation process.

Option 3: Commercial Off the Shelf (COtS) Product

If a supplier is offering their own product with no customisations, they should be able to provide compliance documentation for the platform, including their testing processes, tools they use, and how they fix known issues and maintain high accessibility standards.

The requirements list

Download the requirements template

1. Describe how the supplier will ensure the proposed solution (customer and staff facing) shall meet and maintain compliance with the latest published version of WCAG (Web Content Accessibility Guidelines) (currently 2.2) A and AA success criteria, in line with regulation requirements and international best practice. Supplier to provide test reports to evidence how they meet / don't meet WCAG compliance including listing test tooling used, their audit process or the audit process of the subcontractor they may involve for external testing. For example, a detailed WCAG audit report, VPAT, evidence of assistive technology testing or user testing with disabled user groups. Supplier to also provide their development roadmap for accessibility if their product partially complies, and how they plan to test and maintain compliance in future.
2. Describe levels of customisations available to the customer in terms of themes, GUI, and functionality. Supplier should explain what impacts customisations may have on accessibility compliance and how the supplier supports customers to check for and mitigating accessibility risks being introduced during the implementation process. For example, does the supplier maintain guidance on how to implement GUI or theme changes to maintain colour or magnification requirements, or components list and their known accessibility issues so that customers can choose only accessible components before implementation.
3. Describe how the solution supports accessible web content creation and upload compliance with WCAG where relevant. For example, what restrictions, options, or guidance the solution includes to help content creators upload or write accessible content, such as internal checks for appropriate heading structure or the presence of alternative text on uploaded images.
4. Describe how the solution supports disabled staff in using authoring tools to create content in compliance with the ATAG (Authoring Tools Accessibility Guidelines 2.0). For example, how do internal screens function with keyboard controls and assistive technologies like screen readers or dictation software to ensure staff can navigate and interact with internal functions.
5. The supplier will indicate if in the delivery of the solution they are using or plan to use any products provided by companies listed in the Overlay Fact Sheet, or any other products that fit the description below. Overlay and Underlay products/plugins/add-ons which offer to remediate accessibility issues represent a false approach to accessibility compliance and can present legal and reputational risks to both the supplier and customer. It is important to be clear on where and what the supplier is using overlay products for because overlay products cannot be used for regulation compliance.
6. 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 agrees to works with the customer to produce an accessibility statement for the proposed solution which meets customer legislative obligation as a public sector body under PSBAR (2018) and is acceptable to the customer. The prerequisite (REQ1) being that the supplier has sufficient evidence of WCAG compliance testing from which to draw details required for the accessibility statement.
7. The supplier provides / works with the customer to provide guidance for assistive technology users. Guidance material required in all cases; additional guidance required to navigate areas of non-compliance with WCAG if present.
8. Describe how the supplier will ensure that any related non-web content generated by the system shall meet accessibility compliance. This should cover any non-web content generated by the system, or related to the promotion, use, or management of the system, including all communications, emails, generated document formats, PDFs, confirmation user action, receipt of acknowledgment, additional correspondence, requests for further information, and use of third-party plugins. Compliance will be assessed against the EN 301 549 content relevant WCAG success criteria in line with regulation requirements and international best practice.