GOV.UK hosts half a million web pages, lots of documents and receives an average of 5.1 million visits a day – the true number is likely much higher as we only count users who accept cookies that measure website use. People come to GOV.UK to find government services and information, like learning to drive or viewing lockdown guidance.

In the UK, at least 1 in 5 people have a long-term illness, impairment or disability, and many more have a temporary or situational disability. Our job on the GOV.UK Accessibility Team is to make sure GOV.UK can be used by the largest possible audience.

People should not be excluded because they have vision, hearing, speech, motor or cognitive impairments. By making GOV.UK accessible, we make it better for everyone. As well as being the right thing to do, accessibility is also a legal requirement for all public sector bodies. We’ve always worked to make GOV.UK as accessible as possible, but here’s what we’ve been doing to improve things on GOV.UK over the last few months.

Finding the accessibility problems

To improve the accessibility of GOV.UK, we needed to find where the problems were. For as big a site as GOV.UK, and with the number of people and departments contributing to it, this was quite a challenge.

So, we undertook a manual accessibility audit of more than 60 representative pages of GOV.UK – these are pages that are reflective of most of the site. This helped us to identify where the issues were, and which pages did not meet the international Web Content Accessibility Guidelines [WCAG] 2.1 AA accessibility standard.

We determined the highest priority problems through asking 3 main questions:

• does it meet the WCAG standards?
• what is the impact on the user’s ability to use GOV.UK?
• how often did the problem occur or how likely is it that a user will experience this problem?

For each accessibility issue we found in the audit, we reviewed it to identify why it had happened. Some problems occurred in many pages across GOV.UK and had different origins. We worked with the GOV.UK Data Labs Team to find out how many times the issue occurred, and then we analysed the causes to determine the best way to fix them.

The causes broadly fall into 3 categories:

• technical – those we could fix on GOV.UK because they were caused by GOV.UK’s design/structure
• content – those we could guide departments to fix by updating guidance and highlighting where the content itself was causing problems
• complex – those that were caused by a mix of content and technical issues or both, and required analysis to identify the cause and solution

Fixing the accessibility problems

Technical issues

GOV.UK uses the GOV.UK Design System and GOV.UK Publishing Components to build pages. Using these systems means things are more likely to be accessible and when improvements are made, that improvement can immediately be applied everywhere the component or template is used.

For example, buttons that look like links but behave like a button can cause screen readers to miss information or can make it more difficult for voice control users to activate the button. We changed most instances of this in the GOV.UK publishing components so the accessibility improvement was reflected across GOV.UK, and fixes on the outstanding instances are underway too.

Content issues

We updated the publishing guidance for GOV.UK to include how to make content more accessible and provided departments with reports to show exactly where their content issues were so they could fix them, for example, pages with duplicate titles that did not indicate the page’s topic or purpose.

We also updated guidance for publishing accessible documents. This included important changes to guidance if publishing PDFs. We also updated information about images, tables, videos, headings, titles and translations. We’re working on pulling these things together into a collection so that all the accessibility guidance for publishing teams is more findable.

Complex issues

For complex problems, we analysed them to identify the different causes. When they were caused by a mix of content and technical issues, we fixed the technical problem and then engaged departments on how to fix the content.

One example of a complex issue we found was that tables should always have column headers and sometimes row headers to explain the content. Doing this allows people like Ashleigh (our partially sighted screen reader user persona) to understand a table’s structure as a screen reader can read which headings are for which of the table’s cells.

We worked with the GOV.UK Data Labs Team to find all the pages on GOV.UK that have tables without column and/or row headers. We updated our publishing tools to allow row headers, and then we updated the guidance on publishing accessible tables and asked departments to review their tables.

Another example of a complex issue we found were language attributes. Assistive technologies need to be able to identify the language in which the content is written and identify any changes in the default written language of the content. When the language attribute is missing or incorrect, the language is not understandable by assistive technologies like screen readers.

We worked with the GOV.UK Data Labs Team and found all the places on GOV.UK where non-English content was used but not identified as non-English. We analysed the causes, updated guidance, updated the publishing tools and then informed departments which pages they needed to fix. We’ll be blogging more about this work soon.

Other examples of problems we found and fixed or asked other departments to fix were:

• images without adequate descriptions (alt-text)
• inaccessible documents or attachments
• content that looked like headings but was not, which meant the way it was presented would not be preserved for screen reader users or users who used their own styles

The GOV.UK accessibility statement reflects the current accessibility of GOV.UK.

Challenges and lessons learned

It’s not just about meeting the regulations, it’s about making GOV.UK accessible for everyone

It’s important to us that we do not stop at meeting the standards. GOV.UK should be accessible for everyone so we’re aiming to fix the other accessibility issues we found, even if they’re not covered by WCAG.

On a big platform like GOV.UK, data analysis is invaluable for finding accessibility issues

The manual accessibility audit only checked representative pages on GOV.UK. To find a lot of the problems, we needed a more effective way of finding repeat content or complex problems.

The GOV.UK Data Labs Team helped us by creating a tool that looked through all the GOV.UK pages and identified pages that had specific accessibility problems.

For a big platform like GOV.UK, having an automated way to check all pages helped us find those problems effectively so we could fix them and tell others where there were concerns.

Making GOV.UK accessible is a cross-government task

Departments across government publish content on GOV.UK. We are responsible for providing the tools and guidance needed to make content accessible but departments are responsible for making their content accessible. We helped departments identify issues through reports and guided them on how to fix stuff too.

The content community has included this new guidance in the required training for new GOV.UK publishers. They are also running workshops focused on creating accessible content, and there is a new course being created that is due to launch in early 2021.

Accessibility is a user need and should be considered from the beginning

When building services, creating components/templates and creating content, accessibility needs to be considered from the onset as a user need.

This reduces the need to retro-fit changes for accessibility later in the process and significantly reduces the effort required. This is why it’s our sixth design principle: This is for everyone.

What’s next?

We will keep working to make sure GOV.UK remains as accessible as possible.

We will explore how to change the publishing workflow to prevent or discourage inaccessible content being published. And, we will make sure our training reflects best practice for accessibility.