Accessibility Statement

Introduction

At Bud, we’re dedicated to building a platform that’s inclusive and accessible to everyone—regardless of ability, technology, or environment.

We follow the WCAG 2.2 Level AA guidelines, as defined by the W3C Web Accessibility Initiative, and use these standards to shape our approach to accessibility across the product. These principles guide our teams in integrating accessibility from the earliest stages of design and help us proactively identify and resolve issues.

Our Accessibility Champions

Accessibility is a shared responsibility across Bud, supported by two key teams:

  • Accessibility Working Group: A cross-functional team of experts from UX, Development, and QA. This group meets regularly to audit our platform, deepen accessibility knowledge, and implement effective remediation strategies.
  • Enablement Team: Specializing in front-end design and engineering, this team ensures accessibility is embedded into the core of our UI. They are currently leading a major redesign of our design system components and patterns to make accessibility a foundational element.

How We Test

To maintain an inclusive experience, we combine manual and automated testing using a range of tools, including:

  • Accessibility Insights for Web (Microsoft)
  • SonarQube
  • Storybook Accessibility Plugin
  • Native device assistive technologies
  • AXE integration in automated testing
  • NVDA screen reader

Exceptions

While we strive to meet WCAG 2.2 Level AA compliance across our platform, there are certain areas that fall outside our direct control.

This includes third-party applications integrated into our platform, as well as content uploaded by users. While we encourage all users to follow accessibility best practices when adding content, we cannot guarantee that such content will meet accessibility standards.

We also recognise that some areas of our platform—particularly legacy features or components built prior to our current accessibility standards—may not yet meet these criteria. Below is a list of all known limitations.

Exception Comment
Mouse-dependent signatures on digital documents and reviews.

We have implemented a keyboard alternative signature for our Other Skills & Training (OST) Application Summary Document and Reviews. The signature mechanism used in OST has been standardised as a component.

We have now also rolled out this component in the following areas: Application Agreements, Application Summary, Training Plan, Additional Learner Support, and the Funding Document.

Some content in accordion containers is not available to keyboard users

We have begun to implement new accordions into the platform which are built with keyboard and screen-reader controls as standard. 

Some modals do not have active focus – whilst content can be accessed, the focus is not trapped within the modal. We are reviewing instances of this exception and putting steps in place to remedy.
Some navigational elements do not provide activated item status We are reviewing instances of this exception and putting steps in place to remedy.
Some content does not have focus order and correct heading structure.

New features use the correct heading structure, but we are aware that there are some areas where incorrect heading structure persists in legacy content.

Some buttons and content elements are not labelled with their associated information.

The production of a new component, which standardises buttons across the platform, has been completed and is now being rolled out across the learner portal.

Some functionality within our business reports is not optimised for screen-readers

We have investigated the accessibility of our business reports, which are built using Microsoft's Power BI embedded functionality. While Power BI includes built-in accessibility features, it has also certain limitations that we would typically address in our standard web application. More information can on Power BI’s accessibility standards can be found in their official documentation here.

 Document Information

Information Value
Version 5.1
Date of version 23.03.2026
Owner Charlotte Murray (Lead Product Designer)
Contact Information charlotte.murray@bud.co.uk
Approved by Brad Tombling (Chief Operating Officer)
Confidentiality level Public

Document Change History  

Date Version Created by Description of change
20.02.2020 0.1 Nathan Meek Initial Draft
25.02.2020 1.0 Ben Garfitt Reviewed draft and added minor amends.
18.06.2020 1.1 Nathan Meek

Amended wording within New Development

Features
21.01.2021 2.0 Nathan Meek Re-titled document and updated Bud testing approaches and tools used, including automation testing. Added points about training within the tech team.
24.03.2023 3.0 Stuart Janicki

Updates to:

  • Introduction
  • WCAG principles
  • Quality Assurance & Testing
  • Existing Functionality Testing
  • New Feature Development

Added:

  • Exceptions
04.05.2023 3.1 Stuart Janicki Updated content within Exceptions
26.07.2023 4.0

Stuart Janicki,

Tia Jacob,

Dave Wainwright,

Sophia Kahlenberg

Updates to:

  • Introduction
  • Guidelines
  • WCAG Principles
  • New Developments and Features
  • Exceptions

Page changes:

  • Added Accessibility Working Group overview.
  • Combined Quality Assurance and Testing with Existing Functionality Testing

Verification:

  • Reviewed by QA and updated
25.10.2023 4.1 Stuart Janicki Updates to exceptions to reflect current remediation and component work.
08.02.2024 4.2

Stuart Janicki,

Stacey Shlapachenko

Updates to include the following component updates in our exceptions list:

  • Typography
  • Buttons
  • Icons / Images Alt Text

Inclusion of Figma and Storybook as named elements in our new feature development section. 
Updated QA and Testing to reflect Storybook as a testing tool, and the use of Product Backlog Items as our method of reporting accessibility requirements.
 
15.05.24 4.3 Stuart Janicki,
Tracey Penberthy

Reference to WCAG 2.2 standards

Updates to include improvements and investigations in our exceptions list:

  • Accordions
  • Focus and Heading Structure
  • Buttons
  • Reports
01.11.2024 4.4

Dora Czerna,

Stacey Shlapachenko

Updates made to the exceptions list to highlight recent actions and progress on remedying the following points:

  • buttons and content elements not labelled with their associated information,
  • non-text content and icons not labelled with correct alt-tags or presentation-only labels.
10.02.2025 4.5 Dora Czerna

Updates made to the exceptions list:

We have improved the accessibility of our business reports by adding alternative text and adjusting the tab order to enhance screen-reader navigation.
06.05.2025 4.6 Dora Czerna

Updates made to the exceptions list.

Our keyboard alternative signature component has now also been implemented in the following areas: Application Agreements, Application Summary, Training Plan, Additional Learner Support, and the Funding Document.
30.10.2025 5.0 Charlotte Murray
  • Main content rewritten and restructured.
  • Updates made to the exceptions list:
    • Removed: Mouse-dependent signatures on digital documents and reviews. These have been remedied across the platform.
    • Removed: Some non-text content and icons are not labelled with correct alt-tags or presentation-only labels. All work on this is now complete.
    • Added: Warning messages across the platform do not meet minimum colour contrast requirements. 
23.03.2026 5.1 Charlotte Murray

We identified several instances where text within banner components did not meet the required colour contrast ratio under WCAG 2.2 AA. This affected banners shown in parts of the enrolment journey, application overview pages, programme activities pages, and platform‑wide release notifications.

We have updated the colour palette and banner styles so that text now meets the minimum 4.5:1 contrast ratio (or 3:1 for large text), ensuring banners are legible for all users.

Document Future Review Periods

Period Document review start date
2026 Quarter 2 11.05.2026