Email accessibility guidelines

Keeping your emails accessible

This checklist offers you a blend of legal requirements and best practice from our digital teams. You can either use this as a quick checklist, or discover more about each point in detail.

Explore our webpage guidelines first

Make sure that you have explored our webpage accessibility guidelines, which cover the following:

Writing
Format
Colour
Images
Multimedia
Documents

All of these apply to your work on emails too. Also, remember to include a clear email subject line.

See guidelines for webpages

Emails come in two formats, Plain text or HTML. HTML emails include images, colours and links and look more designed. Plain text emails are more likely to be accessible because there is less which can go wrong.

If you create HTML emails, as well as following all our basic accessibility guidelines.

Make sure you use a font size of 16px or larger, which is not thin
Make sure the text is readable with good contrast and does not rely on colour alone for meaning
Make sure the user can change the size to suit themselves
Do not include any text on images that you don't explain in words or cover with some alternative (alt) text, follow this guide to imagery and multimedia
If you are using layouts with tables, you should design your email as you would if you were designing a web page. For example: make sure the text can be navigated without a mouse and reflows to fit all devices.
See a comprehensive collection of

Taking these steps will make your emails better for all users.

Testing and user-testing

Testing and user testing

No tool or simulator can quite replace talking to people living with different disabilities. Testing your email with disabled users will give you more accurate feedback.

However, you can try using a speech reader yourself to hear how your email sounds.

You can download NVDA from the software centre.
You can also try screen readers built-into operation systems:

Accessible Emails

As with web pages, emails are required to meet the Web Content Accessibility Guidelines (WCAG) criteria as part of our legal obligations under Public Sector Bodies Accessibility Regulations (PSBAR).

It also aligns with our aim to be an inclusive institution and allows us to reach the widest range of possible students.

Writing for accessibility

To ensure we meet our obligations emails should be written and presented in a way which is digitally accessible. This includes:

Written content

Simple language and plain English

You need to make sure that your copy is readable and understandable for all our audiences. This helps non-native speakers, as well as users who process information differently.

We recommend that you:

Keep your text at a reading age of Grade 9 or below
Keep your sentences under 25 words, and paragraphs under 50 words
Avoid difficult words, metaphors, puns, contractions, abbreviations and acronyms

Links

Links and buttons should be descriptive and make sense without other clues such as images or surrounding text. Users may struggle to see these or may have skipped past them while using a screen reader.

You should not list a full URL on screen instead use a button or a full sentence of hyperlinked text. These should be positioned at the end of a paragraph not within it.

If it is a download link, state the file type and size.

Be careful when adding attachments or linking to files to download that the file itself has also been checked for accessibility.

Structure

Headings

Always use headings and subheadings to divide up your text. Screenreaders rely on them to help give context and allow users to skip to the relevant section. They are also useful for sighted users to do the same.

You should never use heading styles for visual effect. If you need a piece of text to be larger or in bold and can鈥檛 code it yourself ask someone who can.

Lists

Use bullet point lists
With short sentences of up to 15 words each
Limit your options to 3 or 4 bullet points

Tables

Only use data tables when necessary for displaying data. Do not use them to format your page there are block layouts in components editor for that.

If you do need a table use the predefined master snippets in Azorus to ensure it is accessible. (This adds all the necessary code in the background which copying and pasting from elsewhere won't give you)

Formatting

Bold, italics, all-caps

Incorrect use of bold/italics or capitalisation can make text harder to read and screen readers do not pick them up as a form of emphasis either.

Our new brand only uses standard and bold text, italics and all caps should not be used at all.

Text alignment

Keep text and content left-aligned. Justified or centred text, can be harder for some users to read especially if they are magnifying, resizing or zooming on text.

Font

When using Azorus template you will be using Arial, if you are creating emails in other platforms please stick to Arial.

Colour

Using colour to convey meaning

Although colours can add visual interest to an email they should not be used as the single way of getting a point across.

Other elements such as descriptive text, labels or shapes should also provide context.

Colour contrasts

Used correctly the digital brand colours meet the accessibility standards which are:

Regular text should have a contrast greater than 4.5:1 with background colour.
Large text (>18pt/14pt bold) should have contrast greater than 3:1
Graphical elements should have contrast greater than 3:1

You can check the contrast ratios of the colours you are using with the

Images

Images with text

Image such as header banners which include text as part of the image are inaccessible as screen readers cannot identify the text. Instead you should use either code or predefined elements within the Azorus templates to create a banner with a separate image and text block.

You will still need to manually check there is adequate contrast between the image and the text.

Alt tags and descriptions

Make sure images have descriptive alt text. imagine you are describing the image to a real human who cannot see it. What would you need to tell them to convey the meaning.

Some images do not need alt text as they are not conveying any meaning. Find out if you need alt text using .

Icons

Do not create your own icons all icons must come from the brand team to ensure consistency and accessibility.

GIFs

Do not use flashing gifs of videos which cannot be paused by the user.

Testing

Testing accessibility

There is no substitute for through testing but it is often too difficult or expensive to fully test everything we build.

You can make a good start by paying attention to the alerts from sitebuilder's built in accessibility checker which runs a number of automated checks.

To go a little further you can use:

(for reading age and clarity)
(browser extension for Chrome or Edge)

You can also run some more manual checks yourself such as using TAB to check your page can be navigated via keyboard or use zoom to test how it responds to magnification.

You can also download some assistive technology from the software centre to experience your web page as someone using these programs would.

Plain text or HTML?

Our preferred platform, Azorus, has pre-built HTML templates which should be responsive and accessible in most common email clients.

If you wish to create a plain text version as well it would ensure it displays as intended in all clients however it is not a requirement for accessibility.

People's accessibility needs can vary and any one of us could have additional needs either permanently or temporarily.

Who benefits from this?

If you are building webpages to go alongside your email you will need to make those accessible too.

Make an accessible web page

Are you emailing students about something potentially scary or difficult? The compassionate communications project aims to help improve how we deliver crucial news to students.

Visit the Compassionate Communications Project

神马福利影片

Digital Accessibility

Keeping your emails accessible

Basic accessibility

Explore our webpage guidelines first

Plain text or HTML?

Plain text or HTML?

Testing and user-testing

Testing and user testing

Accessible Emails

Writing for accessibility

Simple language and plain English

Links

Headings

Lists

Tables

Bold, italics, all-caps

Text alignment

Font

Using colour to convey meaning

Colour contrasts

Images with text

Alt tags and descriptions

Icons

GIFs

Testing accessibility

Plain text or HTML?