Accessibility Statement

Introduction

This article outlines Bud’s commitment to accessibility, ensuring the platform is usable by everyone, regardless of technology or ability. It details the implementation of best practices and adherence to the Web Content Accessibility Guidelines (WCAG) 2.2 AA standards. By following these guidelines, Bud aims to enhance the user experience for individuals with various impairments. This guide is essential for understanding Bud’s efforts to create an inclusive and accessible digital environment.

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

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.2 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 or 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.2 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.2 AA Guidelines which were published in October 2023.

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 =continually add to and maintain internal documentation with best practice and accessibility recommendations.

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.

 Document Information

Document Change History  

Document Future Review Periods