GOV.UK resources

A list of resources from GDS which are on GOV.UK.

Accessibility for Developers: Introduction

As well as the guidance for Software Engineers and Frontend Developers in this manual, you should read the accessibility for developers introduction on GOV.UK.

Common assistive technologies

If you’re working to the Service Standard you will need to make sure your service works on the GOV.UK list of common assistive technologies.

A 2016 GDS survey on assistive technology and a WebAim screen reader survey was used to create the list. It is updated several times a year, so don’t always assume the list is the same as the last time you checked it.

Leader’s Guide on Accessibility

Members of the cross-Government accessibility community have produced the Leader’s Guide on Accessibility.

The guide is for anyone with responsibility for a digital team, product or service. It will help you work out what role each team member plays in making your service accessible, and what tools and training you and others may need, to help you build accessibility into your product from the start.

It’s available to download in Word and OpenDocument text format:

If you have questions or feedback on this guide, contact Samantha Merrett and Alice Dryden.

Make things accessible and inclusive

Whether you’re building or buying technology it’s important to make things accessible and inclusive.

To meet point 2 of the Technology Code of Practice (TCoP) your plan or design must show how you’re making technology inclusive.

If you’re going through the spend control process you must explain how you’re meeting point 2 or any limitations you’ve encountered.

Publishing accessible documents

See the GOV.UK guidance for publishing accessible documents to learn how to publish accessible documents to meet the needs of all users under the accessibility regulations.

Record a Goose Sighting: Training

Record a Goose Sighting is a fictional service which has been coded to include deliberate accessibility issues, such as missing alt text and broken heading hierarchies.

There is the Record a Goose Sighting worksheet for you to work through and the Record a Goose Sighting answers so you can see if you found everything.

There is also a version of Record a Goose Sighting with no answers, which may be helpful in scenarios where you don’t want people to be able to find the answers themselves. This can be useful for training or knowledge checks.

You can also view the Record a Goose Sighting project on Github and read the blog post training people to do accessibility reviews to understand more about the project.

Service Manual

The GOV.UK Service Manual is the main guidance for any service team. It covers every aspect of designing and building digital services, not just accessibility.

Service Manual: Design guidance

The Service Manual: Design guidance should be used for naming, structuring and scoping your service.

Services for Government users

When we think of digital services, we often think of service which are for the general public. But we can reuse a lot of the existing patterns because Civil Servants are users too. If you’re building a service for staff to use, it still needs to be usable and accessible.

Read the Service Manual guidance on designing services for Government users.

Technology code of practice

he Technology Code of Practice is a set of criteria to help government design, build and buy technology. It’s used as a cross-government agreed standard in the spend controls process.

User profiles

The GDS user profiles were published by GDS in 2017 to help you understand how disabilities and impairments might impact people trying to access your service.

There are 7 user profiles in total:

They provide an example of what user profiles or personas can look like, but they also illustrate some things to avoid:

Personas should have creation and review dates

Any persona or set of personas should include information on when they were created, and how often they are reviewed. This gives users reassurance that they’re based on the latest best practice in persona design and - more importantly - that they reflect the latest research on the accessibility needs they describe. GDS have confirmed that the profiles haven’t been updated since publication in 2017.

Personas should detail how they were created

Personas should include (or link to) details of how they were created, following a robust process based either on primary research with users who have the described accessibility needs, or secondary research with subject matter experts. Again, these details give users reassurance that personas are high-quality, and helps them to understand if they’re useful for a specific purpose.

Personas should detail what they’re intended to be used for

Different content might be required for different purposes: to help inform interaction or content design, to convince stakeholders of the importance of meeting certain accessibility needs, or to educate other User Centred Design professionals. Profiles and personas should be used for the purpose for which they were created - and ‘multi-purpose’ profiles run the risk of doing everything not very well.

Pawel

Created in 2017, the GDS persona for Pawel refers to him ‘having Asperger’s [syndrome]’. However, Asperger’s has since been formally redefined as a form of Autism Spectrum Disorder (ASD), “without disorder of intellectual development and with mild or no impairment of functional language” (International Classification of Diseases, 2018, quoted from informationautism.org).

This shows the importance of adding publication or creation dates to your own personas, and conducting regular reviews. If you want to know about the reason for this change and the ongoing debate about it, here are some useful links:

Using progressive enhancement

When we talk about using progressive enhancement we mean that we start simply and build up to complex.

We should never rely on anything but HTML. CSS styles and JavaScript should always be an additional layer which is not essential for the service to function. If you disable all of these features, although your service might look boring, it should still function.

There are lots of reasons why JavaScript might not load such as a poor internet connections.

Writing for GOV.UK

The official guidance on writing for GOV.UK.

A lot of accessibility issues can be solved just by having well written and well structured content. The guidance contains lots of information on how people read and what is the best way to make sure your content works for everyone.

Writing for user interfaces

Depending on where your content will be published, the things you need to consider might be different. As well as the guidance on writing for GOV.UK you should read the guidance on writing for user interfaces.