One of the most important things we do here in Web Services is to work with other teams across the university to ensure their websites and systems are fully accessible. We do this using our accessibility audit process.
This article will take you through an example audit and talk about why we do this.
Accessibility audit case study – LibGuides
- Who we supported: Library and Learning Centre (LLC)
- What we audited: LibGuides
- How we did it: Our audit process
- What we found: Issues with colour contrast, heading structure, font size, alternative text and focus states
LibGuides delivers useful resources for students across all subjects and is managed by the Library and Learning Centre team. The LibGuides system mainly consists of guides but also provides links to eBooks, journals and other online resources.
We were asked to take part in a project to improve the content within LibGuides. Our aim was to help the team to understand how accessible their content was, and then help address any issues that were discovered.
There are hundreds of pages across each subject in the LibGuides system so we knew we couldn’t assess everything ourselves. So, after performing a few accessibility audits to demonstrate the process, we trained the project team to perform the audit process themselves.
When thinking about what to assess, we selected individual pages carefully to ensure we covered as many different templates and types of content as possible. The pages were then allocated to different members of the project team.
Each person spent around 1-2 hours performing an accessibility audit of their assigned content, using both manual and automated checks and tools to make an accurate assessment of how each page performed.
We recorded issues in a document and included screenshots. These issues were shared and discussed together.
One of the desired outcomes of the project was to create an accurate and detailed accessibility statement that could be published for LibGuides. This document contains details of any outstanding accessibility issues and when a fix for those issues is expected to happen. It also provides contact details for when someone comes across an accessibility issue and wishes to report it.
Prioritised list of accessibility issues
Once all the audits were complete and discussed, we had a list of prioritised accessibility issues that could be addressed. Some were more urgent than others. For example, videos and images that had no alternative text have a negative impact on some visitors, so we addressed these as a priority.
In some cases, the project team were able to update content quickly to address issues. In other cases, we were required to update the LibGuides styles to fix issues with colour contrast and font sizes.
Several complex issues were discovered that required work from the vendor/supplier. These issues were collated and delivered to them to fix.
The result of all this hard work is that the LibGuides system meets the needs of our audiences and the WCAG 2.1 accessibility guidelines. We improved the readability of the content and the overall usability of the system.
Following the accessibility audit, we ran a training session for the LLC team on how to create accessible content. This session armed the team with the knowledge they required to create web content that is easy to read and understand for everyone.
The Creating Accessible Web Content course runs as an OPD session several times a year. At the time of writing, the next session is scheduled for 17 March 2022.
Accessibility work on a website or app is never finished. There are several factors why this is the case, including:
- Minor content issues that can creep in over time (forgetting to add alt text to images when in a rush, for example)
- Technology changes and evolves over time as well
- New recommendations get added to the WCAG guidelines
And this is why we work in a continuous cycle of audits and improvements with all of the websites, apps and web-based systems across the university.
Why accessibility is so vital
Why do we do this work? The university’s website receives millions of visitors every month. Statistically, around 20% of those visitors will have some sort of disability or impairment that affects how they use a website.
When a university website, app or browser-based system is fully accessible, it meets the needs of every visitor, no matter who they are, where they are, and what device they are using. It means everyone can find, read and understand our online content, including those visitors who have a disability or impairment.
- There are over 10 million people in the UK who live with a disability – that’s one-in-six people
- 8.1 million people have significant vision impairments, including two million people who are blind
- Around 14% of students at the University of Dundee declare a disability each year (at least 1,900 current students)
- Hundreds more don’t declare their disability (2,400+ students is a fair estimate)
- We must also consider prospective students, staff, potential staff, research funders, alumni, general public, and so on
It’s also important to remember that temporary and situational disabilities can affect anyone at any time. An example temporary disability is a broken arm or sprained wrist that might prevent you from using your mouse and require you to use your keyboard to navigate instead. An example of a situational disability is when you can’t see your screen clearly due to strong sunlight, or you can’t play the sound on a video because you’re in public and must rely on captions instead.
Digital accessibility has never been more important for us at the University of Dundee because most people interact with us online and not face-to-face. Here are just a few example scenarios where a significant accessibility issue with a website or system would be a problem:
- International students applying for a course
- Students distance learning from home
- Staff working from home
Being accessible means anticipating needs and not reacting to issues (assuming the issues are even reported). This requires us to be proactive and assess all of our digital systems and content to find and fix accessibilities issues promptly.
If someone can access our content online, the website or system that presents that content must be accessible by law according to The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.
What is an accessibility audit?
An accessibility audit is a thorough assessment of a website or app that helps people who manage that resource to discover accessibility problems. They can then prioritise and address these problems so their website or app meets the UK’s public sector accessibility regulations.
It involves testing a website or web app by performing both manual and automated tests. The process uses several tools and browser extensions, and screen readers for desktop and mobile devices.
The process allows people to discover issues in many areas, including:
- Colour contrast
- Text legibility
- Content structure
- Alternative text
- Compatibility with screen readers, magnifiers and other adaptive tools
The aim of the process is to discover when we might be causing problems for people with disabilities or impairments in how we deliver our online content. It helps to bring issues to light so they can be fixed. This helps ensure our content is discoverable, readable, and understandable for everyone.
We use the Web Content Accessibility Guidelines (WCAG) 2.1 guidelines to help us understand whether or not a website or app is accessible.
Read our guide on the accessibility audit process.
Accessibility auditing is just part of our ongoing efforts as a team and institution to make our digital platforms as accessible as possible so we can be fully inclusive and reach a wider audience.
The new university strategy will help raise further awareness, support and action so we can strengthen our efforts to serve every single staff member, student and member of the public who use our digital tools.
If you are responsible for a website, app or web-based system and wish to ensure it is accessible for your entire audience, contact Web Services via Help4U or email email@example.com.
Thank you for reading.