Guidance

Accessibility statement for the Government Skills Campus (GSC)

Published 17 April 2026

This page explains how accessible the Government Skills Campus is, what to do if you have difficulty using it, and how to report accessibility problems with it.

Using this service

The Government Skills Campus is run by the Cabinet Office. We want as many people as possible to be able to use this service. For example, that means you should be able to:

• change colours, contrast levels and fonts using browser or device settings
• zoom in up to 400% without the text splitting off the screen
• navigate most of the service using a keyboard or speech recognition software
• listen to most of the service using a screen reader - (including the most recent versions of JAWS, NVDA and VoiceOver)

AbilityNet (opens in a new tab) has advice on making your device easier to use if you have a disability.

How accessible this service is

The Government Skills Campus is built with HowNow, which has its own accessibility statement (opens in a new tab).

We know some parts of this service are not fully accessible. These issues may make it harder for people to:

• move around the service
• understand information
• complete tasks with assistive technology

The most significant problems include:

Non-text content

The service provides text alternatives for most non-text content, to enable access for users who rely on assistive technologies. Non-text content includes: 

• images
• icons
• multimedia elements

However, some decorative images and complex graphics may lack appropriate alternative text or meaningful descriptions. This could limit accessibility for screen reader users.

Information and relationships

The service generally conveys information and relationships through semantic markup and programmatic associations, supporting assistive technologies. However, some components and layouts may rely on visual formatting alone. This may hinder accessibility for users navigating by screen readers or keyboard.

Keyboard navigation

The service supports keyboard navigation for most interactive elements and functionality. However, certain components may not be fully operable using only the keyboard. This may hinder accessibility for users who rely on non-pointer input methods.

Focus order

The service generally maintains a logical focus order that supports intuitive navigation for keyboard users. However, in certain interactive components or dynamic sections, the focus may jump unpredictably or skip essential elements. This can disrupt the user experience for those relying on keyboard navigation.

Name, role and value

Most user interface components expose their name, role, and value correctly to assistive technologies. However, some custom widgets and dynamic elements lack proper ARIA attributes or semantic HTML. This results in incomplete or inaccurate information being conveyed to screen readers. This can hinder interaction for users who rely on assistive technology.

Minimum contrast

Most text and interactive elements meet the minimum contrast ratio of 4.5:1 against their background. Instances of low-contrast text include:

• placeholder text
• disabled buttons
• secondary labels

These may not meet the required threshold, potentially hindering readability for users with visual impairments.

Reflow

The service supports reflow in many areas. Reflow allows content to adapt when increasing zoom levels and different viewport sizes without requiring horizontal scrolling. Certain complex layouts, or fixed-width containers may introduce horizontal scrolling or content clipping when viewed at 400% zoom. This can hinder readability and navigation for users with low vision.

Non-text contrast

Most visual elements, such as buttons, form controls, and graphical indicators, have enough contrast against the colours next to them. However, some icons, borders, and focus indicators do not consistently meet the minimum contrast ratio of 3:1. This may affect users with visual impairments when identifying interactive components.

Status messages

Some status messages, such as submission confirmations or dynamic updates, are presented visually. However, they are not consistently conveyed to assistive technologies using appropriate ARIA roles or properties. As a result, screen reader users may not be notified of important changes in content or context.

If you need support or different formats while we fix these problems, please contact us.

What to do if you cannot access parts of this service

If you need information on this service in a different format, like accessible PDF, large print, easy read, audio recording or braille, contact the service at gsc@cabinetoffice.gov.uk

We will provide an initial response within 5 working days.

Reporting accessibility problems with this service

We’re always looking to improve the accessibility of this service. If you find any problems not listed on this page, or think we are not meeting accessibility requirements, contact gsc@cabinetoffice.gov.uk

Enforcement procedure

The Equality and Human Rights Commission (EHRC) is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the ‘accessibility regulations’). If you are not happy with how we respond to your complaint, contact the Equality Advisory and Support Service (EASS) (opens in a new tab).

Technical information about this service’s accessibility

Cabinet Office are committed to making this service accessible, following the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

The service has been tested against the Web Content Accessibility Guidelines version 2.2 AA standard (opens in a new tab).

This service is partially compliant with the Web Content Accessibility Guidelines (WCAG) version 2.2 AA standard, due to the non-compliances listed in this statement.

Non-accessible content

The WCAG principles of Perceivable, Operable, Understandable and Robust (POUR) ensure that content is accessible to users with visual, auditory, physical and cognitive disabilities.

We have summarised known issues under each principle and listed the associated WCAG 2.2 success criterion.

Perceivable

The issues detailed below relate to the following WCAG 2.2 success criterion: 

• 1.1.1 (Non-text content)
• 1.3.1 (Info and Relationships)
• 1.4.1 (Use of Color)
• 1.4.3 Contrast (Minimum)
• 1.4.4 Resize Text
• 1.4.5 Images of Text
• 1.4.6 Contrast (Enhanced)
• 1.4.10 (Reflow)
• 1.4.11 (Non-text Contrast)
• 1.4.12 (Text Spacing)
• 1.4.13 (Hover on Focus)

Programmatic and structural issues

Many interactive and non-text elements (such as images, buttons, and form controls) lack correct alt text, accessible names, programmatic markup (ARIA/semantic HTML), or structural relationships (heading/list errors). This results in unclear information, lost functionality, or restricted use for screen reader, voice activation, and keyboard-only users, as visual-only content (like errors or graphs) is not always conveyed programmatically.

Contrast and legibility issues

Text and non-text elements consistently fail to meet the required minimum and enhanced contrast ratios, hindering legibility for users with visual impairments. This issue extends to focus states/outlines and the bookmark button state, which is indicated by colour alone.

Navigation and display issues

Site navigation is negatively affected in different viewport dimensions or zoom levels (reflow/resize text viewports), resulting in obscured content or information loss. Furthermore, focus is sometimes unexpected or obscured on certain pages, and keyboard users are unable to select a profile image from the gallery.

Operable

The issues detailed below relate to the following WCAG 2.2 success criterion: 

• 2.1.1 Keyboard
• 2.3.3 Animation from Interactions
• 2.4.1 Bypass Blocks
• 2.4.2 Page Titled
• 2.4.3 Focus Order
• 2.4.4 Link Purpose
• 2.4.6 (Headings and Labels)
• 2.4.7 (Focus Visible)
• 2.4.9 (Link Purpose (Level AAA)
• 2.4.11 Focus Not Obscured (Minimum)
• 2.4.12 Focus Not Obscured (Enhanced)
• 2.4.13 Focus Appearance
• 2.5.3 (Label in Name)

Keyboard and focus issues

Many interactive elements (such as buttons, forms, modals, and upload links) are not fully keyboard-operable or lack correct programmatic writing (accessible names, markup), resulting in lost functionality and inaccurate information for screen reader and keyboard users. Keyboard navigation is further hindered by missing “Skip links” and an unexpected or non-sequential focus order in key areas.

Visual and structural obstruction

The focus state is sometimes obscured, fails the minimum contrast ratio, or is taken unexpectedly on some pages. Site navigation also obscures content or loses information when viewed in different dimensions (reflow/resize text viewports).

Labeling and title errors 

Elements such as radio buttons and date pickers frequently lack accessible names. Some buttons use generic accessible names or names that do not contain the visible text. Page titles and the site icon’s alt text are non-descriptive, impairing clarity of information and link destinations.

Programmatic data and markup 

Key information conveyed visually (such as error messages and graphs) is not provided programmatically to screen reader users. Incorrect link, list, and general element markup also disrupts the page structure and function for assistive technologies.

Cognitive issues 

The file upload hover animation can cause cognitive issues.

Understandable (clear)

The issues detailed below relate to the following WCAG 2.2 success criterion: 

• 3.1.2 (Language of Parts)
• 3.2.5 (Change on Request)
• 3.3.2 (Labels or Instructions)

Labels, instructions, and markup errors 

Interactive elements frequently lack persistent visible labels or clear instructions, and mandatory fields are indicated by asterisks without explanation, creating difficulties for screen reader users. Incorrect element markup also affects keyboard-only users and assistive technologies.

Visual change conveyance 

Visual changes, such as links opening in a new tab or missing success messages on save, are not conveyed to assistive technology users.

Voice activation difficulty

Users of voice activation have difficulty interacting with the completion rate filter due to a lack of a visible label and programmatic writing that doesn’t match the visual structure.

Robust (compatible)

The issues detailed below relate to the following WCAG 2.2 success criterion:

• 4.1.2 (Name, Role, Value)
• 4.1.3 (Status Messages)

Inaccurate or missing programmatic information 

Many interactive elements (such as buttons, tooltips, listboxes, and file uploads) have incorrect, missing, or generic ARIA roles, labels, or accessible names. This leads to a loss of information and functionality for assistive technologies and keyboard-only users. Structural markup issues (such as incorrect link/list element markup) also disrupt the page structure and information flow for screen reader users.

Visual-only conveyance 

Key information, such as error messages, graphs, and dynamic status updates (such as1. letter counters), are only displayed visually and are not announced programmatically to screen reader users.

We are working alongside our supplier to fix content which fails to meet the Web Content Accessibility Guidelines version 2.2 AA standard with the aim of achieving compliance by the end of 2026.

What we are doing to improve accessibility

To improve this service’s accessibility, we:

• work with real users who have accessibility issues to make sure that our service meets their needs
• carry out internal tests for compliance with Web Content Accessibility Guidelines 2.2 AA
• work with with independent external agencies to test for compliance with Web Content Accessibility Guidelines 2.2 AA
• independent external agencies to perform usability research
• build and test our services to meet government accessibility requirements (opens in a new tab)
• work closely with our external supplier to raise any known accessibility issues for resolution

Preparation of this accessibility statement

This statement was prepared on 20 January 2026. It was last reviewed on 14 April 2026.

This service was last tested on 29 October 2025 against the WCAG 2.2 AA standard. The test was carried out by the Digital Accessibility Centre (DAC) (opens in a new tab), using a range of assistive technologies on desktop and mobile devices. The tests were carried out on a representative sample of pages.

This statement was updated on 14 April 2026.