Information for platform owners and developers
Accessibility standards
We have legal obligations to ensure our digital content is accessible under the Equality Act 2020 and Public Sector Accessibility Regulations 2018. The Public Sector Bodies Accessibility Regulations 2018 stipulate that our online content must meet the Web Content Accessibility Guidelines (WCAG).
The European Accessibility Act also refers to WCAG and applies to any platforms we use that operate in the EU.
Web accessibility standards
All digital platforms must adhere to the WCAG 2.2 AA standard as a minimum to comply with the 2018 Digital Accessibility legislation.
This includes an accessibility statement, which also has its own requirements.
It's not always possible to be compliant with the standards for a range of reasons, but in those cases the accessibility statement must declare this, the reason for non-compliance and when it is going to be fixed. Clear signposting to alternatives must also be included.
+++
Four main principles in the WCAG standard
- Perceivable: regardless of sensory abilities, content should be presented in a way that works for all. Examples: alt text for images, contrast ratios, audio descriptions and captioning for video
- Operable: all users should be able to select buttons and use all features of the site. Examples: Keyboard accessible, functionality beyond the keyboard
- Understandable: information should be presented in a predictable way. Examples: Language, no jargon or abbreviations, input assistance in the form of error identification, labels or instructions when content requires input.
- Robust: web content should work with all assistive screen readers. Examples: Structured documents, parsing (complete tags, names, roles and values).
Accessibility Statements
All digital platforms need to publish an accessibility statement.
For websites, the statement should be published as an HTML page, linked to from a prominent place like the website footer.
For mobile apps, make the statement available in an accessible format where users can download the app.
All central systems have accessibility statements published to comply with the legislation to meet the above deadlines.
System owners are responsible for their own accessibility statements.
Procurement guidance
Even if you are not going through a formal procurement process, you can use this guidance to ask questions of vendors.
Vendors should ideally be able to give us a Voluntary Product Accessibility Template (VPAT) detailing compliance with WCAG. They may even have an accessibility roadmap
It can be difficult to understand each criteria, but a VPAT should flag up any partially compliant aspects of the tool as well as any non-compliant aspects of the tool.
If you are thinking about questions to ask of suppliers or third party tools, the procurement guidance created by George Rhodes and RNIB is really helpful.
More information
Accessibility checkers and testing
Accessibility checkers
Automated checkers and testing tools
Many accessibility checkers will claim to run automated checks to ensure compliance with WCAG 2.2; however, no tool alone can check WCAG compliance. Automated checkers can be very useful for colour contrast, headings and ARIA labels.
- Matthew Deeprose's Level 3 Accessibility Testing describes where we might deploy automated checkers to help with testing.
- Accessibility testing tools (HeadingsMap, Atkinson Hyperlegible fonts, ANDI and WAVE)
- UK Gov Accessibility Testing Tools
- Testing for conformance with WCAG
Microsoft 365 tools
The Microsoft accessibility checker is a useful tool that helps content creators identify potential accessibility improvements while they create content in Word, PowerPoint, and Excel.