Accessibility requirements for eDMs: Part 1

  • Author: Access iQ ®
  • Date: 3 Jun 2013
  • Access: Free

Quick facts

Many people believe web accessibility begins and ends with their organisation’s website. In reality, it should encompass all communications.  This includes your Word templates, your PDF's and your eDMs.

One of the things Access iQ™ has struggled with is finding an agency capable of delivering an accessible electronic direct mail (eDM) template in MailChimp, a third party email marketing service. So we came up with our own eDM template brief to help with the process.

This article outlines the different components of eDMs and provides you with the information to understand how each component needs to be accessible.

You'll want to remove any reference to Access iQ™ and occasionally we've left our particular information in the brief as examples. The usefulness of this brief also relies on your ability to test and verify the outputs of the agency because more than likely they will not be able to do it.

This guide is intended to be comprehensive rather than exhaustive.  Is there anything we've missed or we can add to improve it?  Leave a comment or get in touch.

This is the first installment of a three-part series — check back for part two and part three in the coming weeks.

Part 1 covers:

The brief

All components of an eDM template must meet Web Content Accessibility Guidelines 2.0 (WCAG 2.0) Level AA standards. This includes, but is not limited to, the use of:

  • Tables
  • Images
  • Fonts
  • Colours

In order to develop a template that complies with WCAG 2.0 Level AA, you must comply with all items contained within this brief.

Accessibility requirements

Alternative text and images

Images play an important role in conveying information on websites. However not all users can see them. Therefore when an image is used on a website or eDM, the purpose conveyed in the image needs to be made available to them.

For people who are blind or vision impaired and who use screen readers to interpret information on a screen, the screen reader will read the alt text when the image receives focus. As such, it’s important that the alt text also conveys the equivalent purpose of the image. 

  • All images within the template must have an alt attribute, even if the value of the alt attribute (the alt text) is empty e.g <img alt=""/>
  • If an image is purely decorative, the alt text must remain empty e.g <img alt=""/> An image is only decorative if no information or meaning is lost if it was removed. This acknowledges that an image is present but communicates that the image has no function or meaning. This is different to not including an alt attribute at all; as some screen readers may attempt to describe an image with whatever it can find when it does not detect an alt attribute. An empty alt attribute tells the screen reader the image is decorative or has no useful information so that it will not read information in the element.
  • For your reference, if an image is meaningful or provides context, the alt text must describe the purpose of the image.

We recommend that you ask your designers to supply empty alt attributes for all images so that you can provide the alt text yourself.  If you need more information on how to create alternative text read our resource Images: accessibility for content authors may help.

Images of text

Within web design, there may be decorative images such as background and spacer images that only serve superficial purposes. A decorative image provides absolutely no information to the user and serves no informative function within the website.

According to WCAG 2.0 Success Criterion 1.1.1 Non-text content:

If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

Decorative images that are part of the template design should be created using CSS. There are two specific WCAG 2.0 Techniques that describe methods of achieving this:

  1. Technique C18 recommends using CSS margin and padding rules instead of spacer images for layout design.
  2. Technique C9 recommends using CSS properties like background, background-image, content combined with the :before and :after pseudo-elements and list-style-image to include purely decorative images and images used for visual formatting.

Adding these images using CSS instead of within an img element ensures that these images are ignored by assistive technology such as screen readers. If the image is decorative only and cannot be included using CSS, then the alt attribute of the img element must be present but empty so that a screen reader disregards them.

What to include in the brief:

  • Use real text instead of images of text (text created and displayed as an image). Real text can be styled using CSS to create call-to-action style buttons, for instance.
  • If a particular design element must be represented as text within images, please consult Access iQ™ before any design and template work commences.
  • In cases where text within graphics is approved for use, include alt text that describes:
    • The purpose of the image (if the image is not a link), or
    • The destination of the link (if the image is a link). 

Links

Create meaningful links so that people who use assistive technologies like screen readers or screen magnifiers can understand the purpose of a link. That is, creating accessible links by choosing link text that describes the function of a link — whether it is the text of the link itself or surrounding text and webpage elements.

More than likely you've seen a page that has links labelled 'Read more'. On its own, it provides little guidance on the purpose of the link, which is why it is generally regarded as poor practice. If a person using a screen reader wants to pull up a list of links on the page, a link labelled 'Read more' won't tell them what the link is for.

There are two ways to make your links accessible:

  • By describing the function or purpose of a link in the actual link text or;
  • By providing a means to allow the purpose of the link to be understood.

An easy test for this is to consider whether, if all the links on a page were formatted into a simple list, the purpose of each link would still be clear. Be aware that some screen readers do exactly this.

What to include in the brief:

  • All links must have meaningful link text that describes where the link will take the user.
  • Do not use exposed URLs as link text.
  • Do not use link text that is not meaningful out of context, e.g. "Click here" or "Read more".

The following examples show acceptable and inacceptable link text for an unsubscribe link:

  • Acceptable link text for an unsubscribe link: 

<a href="http://www.example.org/unsubscribe">Unsubscribe</a> 

  • Unacceptable link text for an unsubscribe link (uses exposed URL): 

<p>Unsubscribe by clicking <a href="http://www.example.org/unsubscribe">www.example.org/unsubscribe</a></p>

  • Unacceptable link text for an unsubscribe link (uses link text that is not meaningful out of context)

<p><a href="http://www.example.org/unsubscribe">Click here</a> to unsubscribe</p>

Font size

The ability to control the size of text displayed on a webpage is fundamental to ensuring that many people with low vision are able to perceive web content.

  • Define font size in relative units (em or percentage).
  • Font size for paragraph text should be left as default (Arial 12pt).

Design

Most modern browsers provide a means by which the user can change the size of the text displayed. This is a reflection of the widespread need to control text size, including by people who do not identify as having a disability. Many people need to control text size only in particular circumstances.

While facilities to provide this resize functionality may be out of the control of the designer/developer, it is part of the agency’s job to ensure that neither the web content itself nor the structures that present the content prevent the user from resizing the text to suit their accessibility needs.

What to include in the brief:

  • The template must be able to be zoomed in up to 200% without:
    • Loss of content
    • Loss of functionality
    • Changes in the appearance of the design
  • All mail outs will be conducted in MailChimp.
  • Common design issues identified by MailChimp for Outlook must be considered in the design of any template. These issues are also known to occur in Gmail.

Headings

You should not use formatting styles to convey semantic meaning. Best practice for creating accessible headings is to use the correct HTML markup, i.e <h1>.

Headings provide structure for information on webpages. They mark the beginning of a section on a page, which makes information easier to find, comprehend and to act upon. Typically, they describe or at least hint at the text content that follows.

This functionality is even more important when it comes to people who use screen readers, such as blind or vision impaired users.

While it's common for content to have formatting styles applied to it like setting headings in larger text sizes, different fonts and in bold, italics or underlined text to signify page structure, these visual cues are lost on the blind user and can interfere with comprehension. 

Screen readers interpret content through its markup. If the <h1> tag is missing, screen reader users can't use keyboard shortcuts to skip to different blocks of content and they may have to listen to a whole block of content to find the information they are looking for.  According to a survey conducted by WebAIM in 2012, 47.4 per cent of screen reader users use headings to navigate websites.

If you need to create more styles then create more styles but don't be tempted to label something a <h1> just because you want or need the text to "look" like a <h1>.

What to include in the brief:

The following heading structure should be adhered to:

  • All headings must be marked up using HTML heading elements (<h1>, <h2>, <h3>, <h4>, <h5>, <h6>). CSS can be used to style headings.
  • Heading tags cannot be skipped in descending order (e.g. a <h2> can immediately follow an <h1>, but a <h4> cannot follow an <h2>). You can however skip heading levels in ascending order (you can use a <h4> followed by a <h2>).
  • Number of <h1> elements used within the template to be briefed specifically for each separate template.

Language

Identifying the primary language of a webpage enables assistive technologies to correctly present the language to the user. For example, screen readers or text-to-speech engines that support multiple languages will use this information to voice the text with the appropriate accent and pronunciation.

You can easily and quickly set the default language of the page using the lang or xml:lang attribute for HTML and XHTML respectively.

The lang attribute with a value of “en” (English) must be added to the HMTL element

  • e.g. <HTML lang="en">

Tables for layout

We emphasise that using tables to manage page layout is not best practice. We must also acknowledge again that there are many existing websites that do use tables for content positioning and layout.

A common example is using a table to give the appearance that content is laid out in two or more columns in the style of a newspaper or magazine.

Screen readers read tables starting from the top row down, and read each column from left to right. The table below is an example of a table where the numbers signify the order in which information will be read out using a screen reader.

The order in which information will be read out by a screen reader, within a table that is used for layout.

What to include in the brief:

When tables are used for layout:

  • Do not include any semantic markup (i.e. <th>, <caption>, <summary>).
  • Ensure that the information maintains a logical reading order when read out by a screen reader.
  • Use only one table in the eDM template, subject to the constraints of MailChimp.
  • Nested tables should not be used. If the design requires nested tables, consult [insert your name as the client] before proceeding.

Advanced accessibility: There may be a case to use an ARIA role="presentation": an element whose implicit native role semantics will not be mapped to the accessibility API.  A use case that is often quoted is a table used for layout and/or any of its associated rows, cells, etc.  But this strategy would require a lot of cross browser and cross assistive technology testing.

Semantic markup

Web standards enforce the separation of presentation from meaning, structure from content. The standards state that presentation, meaning and functionality should remain as separate as possible, partly through the different languages used for each; CSS, HTML, JavaScript. This is how, for example, <em> (for emphasis, which denotes a change in meaning or status) is more semantic than <i> (for italic, which denotes a change in presentation or style). Semantic markup prefers the instructions related to presentation be called from a style sheet using cascading style sheets (CSS) and not in HTML, unless the CSS properties are enclosed in a <style> element in the <head> of the document.

Semantic markup also requires including appropriate and correctly formatted meta information, which by being machine-friendly helps web content to be found, understood, indexed and inter-related to contribute to a semantic web. Some of the meta information like page titles and document language provide meaning and information that help not only understanding but also usefulness. Following some of these conditions is very easy to do, some taking only a few minutes to apply to an entire large website, but have lasting benefits to their place in the internet.

Following web standards and using semantic markup will, by and large, enhance accessibility. This is not because accessibility is built into web standards but because standards-compliant semantic markup is more machine-readable, which includes browsers, search engines and the assistive technologies used by people with disabilities. Good semantic markup also allows better keyboard navigation, making the site easier for everyone to use.

What to include in the brief:

  • Use <strong> and <em> elements, not <b> or <i>.
  • Use <ul> for unordered (bulleted) lists and <ol> for ordered (numbered) lists. Each <li> element (list item) must have a closing tag </li>.
  • Ensure all HTML elements:
    • have complete start and end tags.
    • are nested according to the HTML specification.
    • do not contain duplicate attributes.
  • Do not override or change the CSS outline property.
  • Use inline CSS to style elements such as headings, lists, etc.

Colour contrast

Colour is an important element of web design and is used in web development in a number of ways. Alongside size, shape and position, colour can visually communicate a great deal to users.

  • Don't use colour alone to convey meaning
  • Use a sufficient contrast ratio
  • Be aware that users often need to adjust colour contrast to suit their vision

There are two main accessibility issues with colour:

  • When a webpage relies on colour alone to convey meaning.
  • When there is insufficient contrast between foreground, usually text, and the background, either HTML colour or an image, making text difficult to read by people with a visual disability.

They key to addressing accessibility issues associated with colour is to not rely on colour alone, or to provide users with the ability to change the visual display to eliminate reliance on colour to convey information.

What to include in the brief:

All text must meet colour contrast requirements. The contrast between the colour of the text and its background is measured as a contrast ratio. The colour contrast requirements are:

  • Text and images of text must have a contrast ratio of at least 4.5:1 except for large text.
  • Large text that is 18pt normal or 14pt bold or larger must have a colour ratio of at least 3:1.

Use the Colour Contrast Analyser for Windows or Mac to measure the contrast ratio between text colour and its background.

The Access iQ™ colour palette for instance is made up of eight logo colours and eight dark (accessible) logo colours.

Sample of the Access iQ™ brand colour palate comparing the brand colour with the accessible alternative colour.

  • When used on a white background, all eight dark (accessible) colours meet contrast requirements for all text sizes.
  • When used on a black background, seven out of eight logo colours meet contrast requirements for all text sizes.

Our Web accessibility starts with your branding article shows how we tackled an inaccessible colour palate and how it worked to our advantage.