Accessibility requirements in your role

Digital accessibility isn't one person's job. It's a day-to-day responsibility for nearly every staff member.

Find a statement that matches your role and see the kinds of things you need to be doing.

'I update or create written web content'

You should always check things such as link text, that your headings are nested properly, and that your informative images have descriptions (typically called 'alt text').

There are other things to consider, too, but if you use our web content accessibility checklist before you publish or update any content it'll remind you of everything you need to do.

Often you'll simply need to adjust things you already do. For example, you're probably already setting headings in your pages but just choose the wrong 'heading level'.

'I create or commission documents, such as those in Word or PDF format'

Lots of the same rules for web content apply to creating Word documents and PDFs; you need a correct heading structure and informative images must have descriptions.

If you're using tables, they need to be set up to have table headers at a minimum. And you should only be using them for data or information.

Using Word documents or PDFs for forms people are supposed to fill out digitally will be extremely problematic for people who use things like screen readers. We'd suggest using Microsoft Forms where you can; it works on desktop and mobile and it's much more accessible than a downloadable document.

If you're commissioning something like a report in PDF or Word format from a third party, get an agreement in writing from the supplier that that the end product will be fully accessible. If it doesn't pass our Word checklist, PDF checklist, or an automated accessibility check in something like Adobe Acrobat Pro then send it back and ask them to meet the requirements.

'I deliver lectures, presentations or training'

Assuming you're using slides, produced via something like PowerPoint, you'll need to consider how easy your slides are to read (think distance, labels and colour), whether the PowerPoint document passes an accessibility check, and how you're verbally delivering your information.

Your text should be large enough to read either via a small screen or at the back of a lecture theatre. It should also have strong contrast - black text on an off-white background is always a safe choice.

Always run the built-in accessibility checker on your document before you finish. It will remind you about things like image descriptions and to check whether your content will be read in the right order by screen readers. Our PowerPoint accessibility checklist will also help you fix all those issues and more.

You should also consider what blind users may be missing if they can only hear your presentation; they'll miss any slide content you don't read aloud. Likewise, deaf users will be able to see all your slide content but not extra detail you only talk about.

Either aim to keep what you show and what you say the same. Or, if you're going to say more than you show, write out and share your script ahead of time.

'I'm a web developer'

What you're producing should meet WCAG 2.1 AA. We don't have direct guidance on accessible development on this website. However, the web is full of great resources, such as the MagentaA11y site that has plenty of developer-focused advice.

The Web Accessibility Project has built a University Design System that's fully accessible. It's stacked with fully designed, developed, and tested patterns and components that meet accessibility regulations. You may be able to use, or encourage the use of, this for websites or systems you're working on.

You could also consider taking the free Udacity Web Accessibility course, which guides you through a suite of developer-focused training.

'I'm involved in buying or approving digital products'

No matter what we're buying or approving we should always be considering accessibility and aiming to only use accessible digital products.

There are few types of digital products where there's very little wiggle room and they absolutely have to be accessible:

If the product will be used via a web browser (eg Chrome, Firefox, Edge) and we either pay for/towards it or develop or control its specification.
A mobile app where we've controlled the specification in some way (even if it's simply taking on University branding) and it's available to be used by the general public and not locked down to only staff and/or students.
If it's being acquired through a high-value tender process then accessibility requirements should be part of the technical specifications and the level of compliance weighed up during the scoring process.

If the product falls into one of these brackets, it should meet WCAG 2.1 AA criteria (the full requirements are within EN 301 549 (PDF), but WCAG accounts for most of the standard) so we can be confident it can be used by all people.

The first step in understanding a third-party product’s level of compliance is to ask the vendor for a voluntary product accessibility template (VPAT) or the results of a third-party accessibility audit. Share this as part of the Contract Information for Software Compliance process or during the tender process. The IT Governance, Risk and Compliance team can help you interpret it and guide on the next steps.

If the product will be used in education, you'll need to ensure the fact it might not be fully accessible is called out in your Minerva module accessibility statement.

'I commission or create videos or podcasts'

All video or audio-only content should be published with a text transcription that relays all the informative audio and, for video, informative visual information. That means what's said as well as other important audio, such as an alarm, and visual detail like graphs or the content of images.

Video should also come with captions. These are different from subtitled in that that contain what's said and other important audio.

Video also needs audio description. This means a version of the video that where important visual information is announced by a narrator.

We have more information about all of this in our video accessibility checklist.