Procurement accessibility guidance

Tagged with:

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.


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:

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:

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.

This publication is issued as guidance only. It is not intended to provide legal or professional advice. All collaborators on this content accept no liability for any errors, omissions or any consequences, losses or damages arising from any use of, or reliance placed on, this publication. You should seek advice from a suitably qualified professional.


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

Going to tender

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.

Share on:


Site preferences

Please feel free to display our site, your way by finding the preferences that work best for you. We do not track any data or preferences at all, should you select any options in the groups below, we store a small non-identifiable token to your browser's Local Storage, this is required for your preferencesto persist across pages accordion be present on repeat visits. You can remove those tokens if you wish, by simply selecting Unset, from each preference group.


Code block theme

Code theme help

Code block themes can be changed independent of the site theme.

  • Default: (Unset) Code blocks will have the same theme as the site theme.
  • Light 1: will be default for users viewing the light theme, this maintains the minimum 7:1 (WCAG Level AAA) contrast ratio we have used throughout the site, it can be quite difficult to identify the differences in colour between various syntax types, due to the similarities in colour at that contrast ratio
  • Light 2: drops the contrast for syntax highlighting down to WCAG Level AA standards (greater than 4.5:1)
  • Dark: Syntax highlighting has a minimum contrast of 7:1 and due to the dark background differences in colour may appear much more perceivable


Motion & animation

Motion & animation help

  • Default (Unset): Obeys device settings, if present. If no preference is set, there are subtle animations on this site which will be shown. If you have opted for reduce motion, smooth scrolling as well as expanding and collapsing animations will no longer be present, fading transtitions and micro animations will still be still present.
  • None: All animations and transitions are completely removed, including fade transitions.


Underline all links

Underline all links help

  • Default (Unset): Most links are underlined, with a few exceptions such as: the top level links in the main navigation (on large screens), cards, tags and icon links.
  • Yes: Will add underlines to the exceptions outlined above, resulting in every link being underlined

Text and paragraphs

Font size (main content)

Font size help

This setting does not apply to the site's header or footer regions

  • Default (Unset): Font sizes are set to site defaults
  • Selecting Large or Largest will increase the font size of the main content, the size of the increase depends on various factors such as your display size and/or zoom level. The easiest way to determine which option suits you best would be to view this text after clicking either size's button
Letter spacing

Letter spacing help

  • Default (Unset): Default letter spacing applies
  • Increased: Multiplies the font size by 0.12 and adds the sum as spacing between each character
Line height

Line height help

  • Default (Unset): all text has a minimum line height of 1.5 times the size of the text
  • Increased: all text has a line height of twice the size of the text
Paragraph spacing

Paragraph spacing help

  • Default (Unset): The space between paragraphs is equivalent to 1.5 times the height of the paragraph's text
  • Increased: The space between paragraphs is equivalent to 2.25 times the height of the paragraph's text
Word spacing preference

Word spacing help

  • Default (Unset): No modifications to word spacing are present
  • Increased: Spaces between words are equivalent to 0.16 times the font size