Accessibility Audit 2024

Introduction

This audit was completed in May 2024.

People may not have a choice when using a public sector website or app, so it’s important they work for everyone. The people who need them the most are often the people who find them hardest to use.

Regulations came into force for public sector bodies on 23 September 2018. They state that you must make your website or mobile app more accessible by making it ‘perceivable, operable, understandable and robust’. The full name of the regulations is the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

Overview

The Calderdale Next Chapter website has 186 active pages based on page views taken from website analytics between 1st January 2024 and 1st May 2024.

Website analytics provide a wider insight into how our page numbers evolve since launch. They may include pages that are no longer published and miss pages that have received no recent traffic.

The Calderdale Next Chapter website is made up of 3 core page types (published amount in brackets):

Articles (150)
Projects (28)
Unique or basic page (18)

Unique/basic pages do not follow a pre-defined layout like Articles or Projects.

3 different component types:

Header
Footer
Project carousel

Components are small pieces of self-contained design and functionality. They are managed in one place but used across multiple pages. This is beneficial as we can test smaller samples and apply one fix which updates all instances.

There are 173 published PDFs, an increase of 12 since the last assessment.

Sample

Criteria

We use a representative sample of pages and features to test how accessible our websites are.
Our sample takes into consideration:

Pages that share the same source.
Reusable components that share the same source.
Unique features that use bespoke functionality to complete tasks.
Popular user journeys based on website analytics.

We believe this is the most effective approach to test our system as it allows us to test the widest range of layouts and functionality without having to run extensive tests on multiple comparable pages.

Inventory

Test process

All pages listed in the inventory are tested using the same process. They are first scanned using tools that can quickly detect common issues. We use a combination of:

WAVE
Axe dev tools
Google Lighthouse

An additional manual check is carried out aided by the NVDA screen reader application to address concerns that automated tools are unable to process.

We use Adobe Acrobat DC to test PDF documents. We first use the built-in accessibility checking function to quickly detect common issues. We then do a manual check of the document which includes checking the document tags, reading order, colour contrast, grammar and more.

Results

Our audit has identified areas where there is room for improvement and barriers that need overcoming. The results from this audit will be shared with the system and content owners so that remedial action can be taken.

Some errors may affect more than one page where they share the same source code such as in global elements like that header and footer. Where the same error is detected, it will only be recorded once against the page where it is first encountered.

Homepage

The homepage is an example of a unique page. No critical errors were detected in the automated check of the page. Google Lighthouse scored the page 100% for accessibility.

Automated checks highlighted:

2 ‘Read more’ links in the news section of the page as being both redundant and suspicious.
Skip to main content link is marked as content sat outside of a landmark region.
One image has an alt text that is longer than necessary.

A manual test of the page uncovered:

Skip to main content link goes to a new page rather than the main region of the page.

Projects

The projects page is an example of a unique page. No critical errors were detected in the automated check of the page. Google Lighthouse scored the page 100% for accessibility.

Automated checks of the page highlighted no areas of concern.

Manual checks didn’t find any additional areas of concern.

News

The news page is an example of a unique page. No critical errors were detected in the automated check of the page. Google Lighthouse scored the page 99% for accessibility.

Automated checks highlighted no areas of concern.

Manual checks didn’t find any additional areas of concern.

A629 Phase 1B Supporting Documents

This page is an example of a basic page. No critical errors were detected in the automated check of the page. Google Lighthouse scored the page 100% for accessibility.

Automated checks highlighted:

2 redundant links – adjacent links have the same destination but both have different labels.

Manual checks uncovered:

Ambiguous link labels – multiple links to “report” and “minutes”.

A629 Salterhebble to Shaw Hill

This is an example of a project page which shares its design and functionality with all other project pages. No critical errors were detected in the automated check of the page. Google Lighthouse scored the page 97% for accessibility.

Automated checks highlighted:

A redundant link within the 'Supporting Documents' section. This is also linked to in the main body.

Manual checks uncovered:

PDF document hyperlinks have file name descriptions which aren’t user friendly.
The map embed can receive focus – this could be a hindrance for screen readers.

New bridge and new routes now open

This is an example of a news article page which shares its design and functionality with all other news articles. One contrast error was detected in the automated check of the page. Google Lighthouse scored the page 95% for accessibility.

Automated checks highlighted:

Colour contrast is insufficient between link colour and grey background.
Long alt text on the map image

Manual checks uncovered no additional areas of concern.

A629 Chapel Lane to Stafford Road

This is an example of a PDF file linked to from a project page.

An automated check of the document highlighted:

No heading structure
document language has not been set.

A manual check of the document uncovered:

There are no semantic headings or easy means of navigation due to absence of tags.
49 missing alt texts, all 'paths' that make up the map.
The document elements do not tab in a coherant order.

West Yorkshire-plus Transport Fund A629 Halifax to Huddersfield

This item is a large PDF file made up of 46 pages.

An automated check of the document highlighted:

Insufficient metadata – no title or subject and ambiguous author.
Images missing alt text.
No heading structure or navigation.
Tables without Header Cells.

A manual check of the document uncovered:

The documents tag structure is incorrect.

2020 Supplemental CPO A629 1b Statement of Reasons

This item is a large PDF file made up of 31 pages. An automated check of the document highlighted:

Insufficient metadata – no title or subject and ambiguous author.
Bookmarks failed – document over 21 pages without bookmarks.
16 figure related alternative text errors.
5 table summary errors.

A manual check of the document uncovers:

Although there appears to be a visual menu – there are no links or bookmark functionality.
The numbers in the menu don’t correspond with page numbers which may cause confusion.
There are very few semantic headings. The headings that do exist are sporadic at tagged incorrectly.
The contents menu is 20 separate paragraphs instead of a semantic list or Table of Contents.
The reading order does not match the visual flow of the document.
Lots of empty content – for example, the document begins: “blank blank graphic light vertical blank blank borough council of Calderdale……… HIGHWAYS ACT 1980 blank blank 2020”.
Single lists are split into multiple separate lists when over multiple pages
There are several images of graphs – does each graph have an accessible means of conveying the same information?
There are image(s) of table(s) instead of semantic tables that can be parsed.
Improper use of tables in appendices.

Recommendations

Based on the assessment results, the following actions are recommended to improve the accessibility of the website:

System owner to update website code to address technical issues highlighted
System owner to explore pages outside of the test sample for any other areas that can be improved
Content owner to schedule remedial action for inaccessible PDF documents prioritising them based on publish date or popularity.
Content owner to publish all future updates in one of the following formats in order of most appropriate:
- Native web page built with semantic HTML in accordance with WCAG 2.1;
- Semantically tagged PDF files designed in accordance with WCAG 2.1;
- Partially compliant document or webpage that demonstrates an attempt has been made to meet basic accessibility requirements where possible. This must include a fully accessible counterpart uploaded alongside the original.