Our web content should be easy for everyone to access, but we need to be specifically mindful that we don’t exclude people with accessibility needs.
While we’ve always tried to make the website work as well as possible for everyone, we’re conscious that it’s not as accessible as it should be, and new legislation has prompted us to make improving it a priority.
Recent changes in legislation state that:
- Websites created after September 2018 must meet level AA of the Web Content Accessibility Guidelines (WCAG) 2.1 by 23 September 2019
- Websites created before this date must meet this standard by 23 September 2020.
There are exemptions for some specific types of content, but most public-facing web content will need to comply by these dates.
Impairments that may make using websites difficult
There are lots of reasons why a person may find web pages difficult to use, for both temporary and permanent reasons. Access needs fall into four main categories:
For example no vision, low vision, sensitivity to light, colour blindness.
This is probably what most people think about when they think about accessibility of websites.
People with a visual impairment may need to use screen reading or screen magnification/zoom software.
For example no hearing, or low level of hearing.
People in this category will benefit from captions on videos, and non-sound indicators.
For example physical issues (such as loss of limb or paralysis), or neurological/genetic disorders that lead to weakness or loss of control in limbs.
Some people might have difficulty making the hand movements required to use a mouse, while others might only use a keyboard, and some people navigate using a head pointer or a single button.
For example learning disabilities, mental illnesses or age-related limitations.
Although there are a wide range of cognitive impairments, people with them experience a common set of problems when accessing websites. These include difficulty with understanding content and remembering how to complete tasks, and confusion caused by inconsistent web page layouts.
Checking for accessibility problems
Most of the content on the University website is published via the web CMS, so we’re starting by checking our CMS templates and the content published using them.
We’re using a combination of methods to check the site:
We’ve bought a licence for a tool called Siteimprove, which scans our pages for accessibility errors, and lets us know which ones are the highest priority to fix.
Siteimprove tests things such as colour combinations, alternative text for images, heading structures, and form and PDF accessibility. It also flags unhelpful link text, such as “click here”.
In addition, Siteimprove checks for broken links, spelling mistakes and readability, helping us improve the overall quality of the website.
There are some issues that an automated tool can’t detect, so we’re using an accessibility checklist to manually check a selection of pages.
For example, we’ll be checking that our pages can be navigated using only a keyboard, and that if an image contains information (rather than just being decorative), that the same information is provided as text.
We’ve been talking to people who have access needs, asking them to show us how they use the York website and the problems they face.
We asked Jisc to carry out a review of our website. Their report highlighted what we’re already doing well and where there are things we need to improve.
- University of York Accessibility Snapshot (University of York staff only)
Fixing the problems
The above methods are helping us build a picture of what we need to fix, and which issues are a priority.
There are two types of fixes that we’ll need to carry out:
1. Changes to CMS templates and the Digital Pattern Library
The first type of fixes to tackle are the ones related to our Digital Pattern Library, and the associated CMS templates. These are being done by the Digital Team within Marketing.
We’ve already made a start on improving colour contrasts, forms, news listings and changing the way our search works.
2. Changes to the content of individual pages
Once we’ve made good progress with the CMS templates, we’ll move on to supporting web page owners fixing any changes to the content of individual pages.
If you’re already following good practice for writing for the web – eg using headings correctly, writing effective link text, providing text alternatives to images – then there probably won’t be much to do. If you’re creating any new content, following this guidance will mean that it’s more likely that the content will be accessible from the start, so you won’t need to come back and fix it later.
We’re preparing guidance on how to fix specific types of content issues. We’ll then get in touch with owners of pages where we’ve identified that there any issues, and provide help in resolving them. We’ll be using Siteimprove to automatically find these issues, so you don’t need to start manually checking all of your existing pages.
Producing an accessibility statement
The legislation also requires us to publish an accessibility statement that explains how accessible our website is. It will also provide people with a way to contact us to report accessibility problems, and a link to a central government website that they can use if they’re not happy with our response.
This will be something that we’ll link to from all of our web pages.
The deadlines for publishing accessibility statements are the same as the deadlines for complying with the standards.
Other work being done around the University
As well as the pages that are published from the web CMS, there are many other things that can be referred to as being part of ‘the website’. These range from tools providing specific pieces of functionality, to large systems such as YorSearch and the VLE. The legislation applies to all of these too.
An e-accessibility working group has been formed, with representation from services from around the University. The group is leading on several initiatives to make digital content easier for everyone to use.
There are lots of useful resources on the e-accessibility wiki, including details of training sessions on topics such as producing accessible documents.
If you’ve got any further questions that weren’t covered in this post, feel free to contact me (email@example.com) or leave a comment below. We’ll be posting more updates as the project progresses.