Introduction

This policy states how Quba will work to make sure services it provides are accessible. 

Our policy states that the minimum standards of WCAG must be met before a product is considered complete. Although this is a baseline, Quba strives to go above the minimum baseline set out by WCAG.

This policy has been written to make sure that a consistent approach will be applied to Quba. We will work with best endeavours to ensure all our output is fully accessible and adheres to WCAG 2.2 guidelines.

Quba has the following accessibility values:

  • To build an all-inclusive culture.
  • Value each individual’s needs, and to prioritise these needs.
  • We adjust and understand individual client needs.
  • We make sure the services and products we provide uphold accessibility standards.
  • We engage to improve accessibility across society as a whole.

Who is this policy aimed at?

This policy is public and provided to our clients, partners and network, so that they can understand how Quba incorporates accessibility.

An internal version of this policy is available to Quba employees as part of our ISO certification.

Scope of policy

The policy applies to the following:

  • Products and services which run in a web browser
  • Products and services which run on a mobile application
  • Newsletters
  • Email communication
  • Webinars
  • Video content
  • Audio content
  • Published documentation (e.g. PDFs, Word, PowerPoint, Excel etc) 

Accessibility legislation and standards

Accessibility is covered by five pieces of legislation:

Our testing approach

We conduct testing on our products using the following:

  1. HTML validation
  2. Automated checks (e.g. PowerMapper, BrowserStack etc)
  3. Manual auditing via check against the WCAG 2.2
  4. External accessibility audits
  5. Assistive technology checks using screen reader and speech recognition
  6. Mobile testing 

Manual testing

We know that automated testing finds only 30/40% of issues hence we need to run manual checks to be extra sure we are tackling all the accessibility issues. Manual testing is conducted using the criteria based on the WCAG2.2 Guidelines.

Assistive software testing

Products and services must undergo technical testing with each of the following types of assistive software.

  • Screen reader - used by people who are blind, visually impaired or have difficulty reading. A screen reader must be able to read the content of the product.
  • Speech recognition - used by people who are visually impaired but have sufficient useful sight to access digital content.
  • Voice recognition software - used by people with mobility impairments. Anybody who has difficulty using a mouse or keyboard may use voice recognition software.

Quba partners with Recite Me to offer assisitive technology. 

Mobile testing

We will be testing our products with mobile devices to make sure that the services work in the correct manner on the device. As our users might be using the service on a mobile device hence, we will make sure that it is correctly accommodated.

We will follow a mobile testing checklist to make sure we are adhering to the accessibility standards.

Accessibility Statement

  • An accessibility statement must be created for every product.
  • This should be accessed via a link in the footer in the user interface.

For a statement to be valid, teams must include all the information outlined in the GOV.UK Model accessibility statement.

The accessibility statement must be updated if any of the following apply:

  • The published version of WCAG changes
  • The compliance status changes
  • A defect with the product is raised
  • The product version is upgraded or a new release is deployed
  • The accessibility statement is 12 months old

Escalation process for non-compliance (Clients)

An escalation process is followed if issues are raised that need to be escalated

1. Contact us via one of the following methods:

Email

accessibility@quba.co.uk 

Telephone

0114 279 7779

Post

Ben Franklin
Quba Digital Ltd
Cubo
38 Carver Street
Sheffield
S1 4FS

2. Fix

The team will check and validate the issue, and provide a fix within 7 days.

3. Inform

The client will be informed that a fix has been provided.

4. Retest

The issue is retested to ensure it functions correctly.

Revision history

Last update: 07/04/2025

Last update by: Ben Franklin

Next minimum update: 06/04/2026