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
Some legacy accordion content is not operable by keyboard or screen reader.	Newer accordions are built with keyboard and screen-reader controls as standard. Remediation of remaining legacy instances is ongoing.
Some modals do not trap focus. Content can be accessed, but focus is not retained within the modal.	We are reviewing instances of this exception and putting steps in place to remedy.
Some navigational elements do not indicate active/selected item status.	We are reviewing instances of this exception and putting steps in place to remedy.
Some legacy content does not follow correct focus order and heading structure.	New features use the correct heading structure. We are aware that incorrect heading structure persists in some legacy areas.
Some buttons and content elements are not labelled with their associated information.	A standardised button component has been built and is being rolled out across the learner portal. Some areas are not yet covered by the new component.
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.
The platform is optimised for portrait orientation on mobile devices and is not optimised for landscape.	Content is not locked to portrait and remains operable in landscape, but some screens may not display as intended. This relates to WCAG 2.2 success criterion 1.3.4 (Orientation).

Document Information

Information	Value
Version	5.2
Date of version	24.06.2026
Owner	Charlotte Murray (Senior 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.
24.06.2026	5.2	Charlotte Murray	Reworded the exceptions list so each entry describes the current limitation rather than remediation progress. Removed the mouse-dependent signatures exception, as this work is fully remediated across the platform. Added a note on mobile landscape orientation support (WCAG 2.2 SC 1.3.4).

Document Future Review Periods

Period	Document review start date
2026 Quarter 3	11.08.2026