Accessibility Statement

Introduction

Estimates indicate that 14.6 million people in the UK had a disability, representing 22% of the total population (Source: UK disability statistics: Prevalence and life experiences - House of Commons Library).

Bud is committed to providing a platform that is accessible to the widest possible audience, regardless of technology or ability. We are actively working to increase the accessibility of our platform, implementing accessibility best practices to improve the usability of the platform for all users.

We aim to follow the web standards established by W3C’s (World Wide Web Consortium) Web Accessibility Initiative, aligning to Web Content Accessibility Guidelines (WCAG) 2.1 AA minimum standards. 

These standards help the Bud team to work with and identify any potential accessibility issues within our Product Design, Development and Quality Assurance teams and address them in a timely manner.

Web Content Accessibility Guidelines

The Web Content Accessibility Guidelines are an internationally recognised set of recommendations and principles for improving web accessibility.

They explain how to make digital services, platforms and apps accessible to everyone, including users with the following impairments:

  • Vision – those who are severely sight impaired (blind), sight impaired (partially sighted) or who suffer from colour blindness.
  • Hearing – those who are deaf or hard of hearing.
  • Mobility – those who find it difficult to use a mouse or keyboard.
  • Thinking and Understanding – those with dyslexia, autism or learning difficulties.

By following these guidelines, we consider potential user impairments and where possible assist them by applying accessibility design principles: 

  • Using a keyboard instead of a mouse.
  • Change browser settings to make content easier to read.
  • Using a screen reader to ‘read’ (speak) content aloud.
  • Using a screen magnifier to enlarge all of part of a screen.
  • Using voice commands to navigate a platform. 

These principles apply to all aspects of our product development strategy.

WCAG Design Principles 

There are four design principles that WCAG 2.1 states should be followed to align to their standards - Perceivable, Operable, Understandable and Robust.

Each principle is further broken down into specific guidelines and success criteria. Below is a breakdown of the four principles and what they include:

Perceivable

The perceivable principle covers recognition and use of the product’s interface by senses available to the user. Examples include:

  • provide text alternatives (alt text) for non-text content where appropriate, and indicate that content is for presentation-only elsewhere
  • provide captions for multimedia
  • make sure content is structured logically and can be navigated and read by a screen reader
  • ensure colour is not the only way to explain or distinguish something
  • use text colours that display clearly against a background colour
  • the interface is responsive on the user’s chosen device, page orientation and font size they like to use

Operable

The operable principle ensures how users find and use content, regardless of how they choose to access it. Examples include:

  • make sure everything works for keyboard-only users
  • let people play, pause and stop any moving content
  • not use blinking or flashing content - or let the user disable animations
  • provide a ‘skip to content’ link
  • use descriptive titles for pages and frames
  • make sure users can move through content in a way that makes sense
  • use descriptive links so users know where a link will take them, or what content will be downloaded
  • use meaningful headings and labels, making sure that any accessible labels match or closely resemble the label in the interface
  • make it easy for keyboard users to see the item their keyboard or assistive technology is currently focused on - this is known as ‘active focus’ 

Understandable

This principle is to make sure users can understand content easily and how the platform works. Examples include:

  • use plain English
  • keep sentences short
  • not use words and phrases that people won’t recognise - or provide an explanation
  • explain all abbreviations and acronyms, unless they are well known and in common use
  • make sure features look consistent and behave in predictable ways
  • make sure all form fields have visible and meaningful labels - and that they’re marked up properly
  • make it easy for people to identify and correct errors in forms

Robust

The robust principle is to make sure content can be interpreted reliably by a wide variety of user agents (including reasonably outdated, current and anticipated browsers) and assistive technologies. Examples include:

  • use valid HTML so user agents, including assistive technologies, can accurately interpret and parse content
  • make sure the code lets assistive technologies know what every user interface component is for, what state it’s currently in and if it changes
  • make sure important status messages or modal dialogs are marked up in a way that informs the user of their presence and purpose, and lets them interact with them using their assistive technology
  • let the user return to what they were doing after they’ve interacted with a status message or modal input

Accessibility Working Group

We have established a dedicated Accessibility Working Group who are responsible for the continuous improvement of accessibility on the Bud platform.

The Accessibility Working Group regularly meets and consists of representatives from the User Experience, Development and Quality Assurance teams. The Group reports progress and updates to the company’s Product Steering Group, which is a collaboration of all Heads of Department for Product, User Experience, New Business, Customer Success, Infrastructure, Development and Quality Assurance.

The Accessibility Working Group acts as subject matter experts for accessibility, helping to educate and train all departments of Bud and also prepares content for further reading on internal microsites and wikis.

New Development and Features

New features go through a design process with the User Experience team, and are produced with accessibility in mind, reducing the risk of inaccessible features and interfaces.

Emphasis is placed on the use of standardised components to provide a consistent experience and visual appearance to the platform. Our components and design system are built within WCAG 2.1 AA Guidelines.

We use a design collaboration platform called Figma, which has a native component system, as well as plugins for accessibility colour tests. As new components are added to our design system, we maintain internal documentation and rationale for best practice and accessibility purposes.

We create our components in a frontend tool called Storybook. We use Storybook to develop and test UI components in isolation and maintain them as part of an on-going component library. Once developed and tested in Storybook, components are then rolled out into the platform.

We aim to check new production code for accessibility, using a code-quality service called SonarCloud to check code against accessibility requirements which provides any recommendations to improve accessibility. Within our development environment, new functionality is tested and reviewed by Quality Assurance.

All delivery team members are also encouraged to attend regular accessibility courses and training, making sure all delivery team members have sound knowledge and understanding of accessibility standards and how we may apply them to continuously improve the platform.

Quality Assurance and Testing

Accessibility Audits are run by external accessibility auditors based on different users and their journeys throughout our platform. Accessibility tests are conducted by our Quality Assurance Team, using various accessibility testing software and native device assistive technologies.

Any issues found with existing functionality are raised as Product Backlog Items and tagged as an 'accessibility' issue and moved into our development backlog. Product Backlog Items are then investigated by the team to understand the severity and effort required to fix the issue. In some cases, if the severity of the issue is high the development team will look to facilitate and work on the issue as a matter of urgency.

The following testing tools are utilised by the teams to supplement manual and automated testing, this list of tools is reviewed regularly: 

  • Accessibility Insights for Web by Microsoft
  • Sonar Cloud
  • Storybook Accessibility Plugin
  • Device native assistive technologies
  • AXE integration within our automation testing
  • NVDA (Screen Readers)

Exceptions

Whilst Bud strives to adhere to the accepted guidelines and standards for accessibility and usability, it is not always possible to do so in all areas of the platform.

Exception Comment
Mouse-dependent signatures on digital documents and reviews. We have implemented a keyboard alternative signature for our Other Skills & Training Application Summary Document, which will be implemented into other areas of the platform which require signatures.  
Some content in accordion containers is not available to keyboard users The component for this is currently being refined and standardised.
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. The production of a new typography component has been completed, which aims to replace headers and content in the platform. This component will detach styling from structure, this will ensure accessibly structured pages. The component will also allow for screen-reader only text to support additional structural requirements.
Some buttons and content elements are not labelled with their associated information. This component is currently in development, which aims to standardise buttons on the platform, with additional requirements built in for screen-reader only context.
Some non-text content and icons are not labelled with correct alt-tags or presentation-only labels

The production of a new icon component has been completed, with built in controls for determining decorative and informative icons. We aim to roll out this component in conjunction with the typography component, to provide screen-reader only context where appropriate.


We have an additional component which is currently being deployed on the platform to replace our avatars (profile pictures and first/last name initial) and regard these as information-only.

Some functionality within our business reports is not optimised for screenreaders An initiative is in place to refine the focus order and non-text content alternatives for unoptimised content.

 Document Information

Information Value
Version 4.2
Date of version 08.02.24
Owner Stuart Janicki (Head of User Experience)
Contact Information stuart.janicki@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.

Document Future Review Periods

Period Document review start date
2024 Quarter 2 08.04.2024
2024 Quarter 3 08.07.2024
2024 Quarter 4 08.10.2024
2025 Quarter 1 23.01.2025

Was this article helpful?

3 out of 4 found this helpful

Have more questions? Submit a request