Creating accessible E-Mails and Newsletters

This article is about how newsletters and e-mails can be offered in an accessible way.

I hear some say that newsletters are from the nineties. In many cases, however, they are practical. Some websites omit features such as an RSS feed, Twitter and Facebook and assume that the user will make a visit every day to see if there is anything new.

Disabled persons are probably more likely than average to subscribe to newsletters: newsletter recipients are generally older, not very tech-savvy and surf the Internet irregularly. There are enough experienced users who do not know what RSS is or how to use it. They may not use a social network or only use it for purely private purposes. The rules mentioned here also apply to simple e-mails.

The basics of the newsletter

A newsletter is basically an email. This may seem banal, but many providers confuse a newsletter with a website and start designing. Fixed layouts, large images, colored backgrounds and many other features bore desktop users and annoy those who check their emails on their smartphones.

One of the biggest difficulties in web design is that websites should look the same in every browser. Anyone who moans about this should take a look at the HTML conformity of the e-mail clients, which does not exist. Hardly any web content is likely to reach the user mutilated as often as a styled newsletter.

Standards are often not met

There is hardly any simple web content that meets the banal standards of accessibility less than the newsletter.

Basically, the same standards apply as for HTML websites:

Subheadings with the correct HTML tag
Table of contents with jump anchors as HTML list
Alternative text for images
No table-based multi column layouts

However, these standards are rarely met. Many editors apparently consider "Please activate images" to be good alternative text, table layouts and placeholder graphics are wide spreaded.

Of course, that doesn't make a particularly good impression. For various reasons, it is more common for images not to be loaded, and to have gaps in the text where “Please activate images” is written casts doubt on the professionalism of the provider.

Best practices

In times of small smartphones, text newsletters have their advantages and should always be offered, even if you are actually sending an HTML newsletter. The user should have the choice and be able to change their subscription later. Text mail is inherently flexible, easily scalable, quick to download, and not prone to errors.

Text mails offer little scope for design. In principle, there are only paragraphs and a few special characters such as the hyphen, the bullet point and the like.

But let's get to the HTML newsletter. At the beginning there should be a clear sender. noreply@example.com tells me that the sender wants to make it as difficult as possible for me to reply to the mail. The sender/company should always be recognizable from the email address or the subject. The subject should be clear and arouse curiosity about the content.

Even if the newsletter consists of only two parts, there should be a table of contents or a short introduction at the beginning. The blind person does not see the scroll bar and therefore does not know how extensive the document is. He is just as impatient as the rest of humanity and stops reading after one or two articles that he is not interested in if he is not expecting anything exciting.

The images should be kept small. The number of those who are happy about large pictures in the newsletter is likely to be close to zero. In general, there is nothing wrong with using images in the newsletter, but they should also have meaningful alternative text.

Links in HTML should be unique. For example, it should be clear that the link is internal or that the link leads to the provider's website. If the link opens a video or a PDF, warns the user. Smartphone users don't find this funny.

My recommendation is to keep the newsletter one-dimensional and fluid. This means there should only be one content column and the width should adapt flexibly to the width of the program section. I know I'm repeating myself, but e-mails are preferably read on smartphones these days, and multi-column e-mails with a fixed width of 600 pixels are just as helpful as a DIN A4 PDF document.

A really stupid practice, but one that is quite common, is PDF newsletters. At best, this is still allowed to go through in the newsletter archives on the provider's website. If you don't want your newsletter to be read, send it as a PDF. If you want to scare off your fans, blow up these files to several MB, then no one will love you anymore.

That's a pity, because sometimes at least someone made an effort to make the whole thing pretty and appealing. But a newsletter is not a flyer and convenience clearly takes precedence over aesthetics.

Make the goodbye easy

The opt-out mechanisms should be as simple as possible. The lack of an unsubscribe function classifies the mail as spam.

A direct link that removes the clicker from the mailing list is best. A quick confirmation on the unsubscribe website is fine, after all, they may have accidentally clicked the link.

In some systems, the service itself is controlled via mail, so a reply to unsubscribe@example.org is enough to unsubscribe, which is also a good mechanism as long as it is explained sufficiently and understandably at the end of the mail.

Unfortunately, some senders allow themselves strange habit: The unsubscribe link leads to the start page, where the unsubscribe option is not to be found. Putting a CAPTCHA before signing in or out is, with all due respect, a mockery of users. persons offering this should be virtually tarred and feathered.

data protection

When it comes to newsletters, it is good manners to ask for as little data as possible. In principle, the e-mail address is sufficient. As an exception, we let the question of first and last name go through so that the newsletter can be personalized. If no personalization is possible or planned, the query of such data is unnecessary.

What is certainly not necessary is the query of further data such as the organization, place of residence, telephone number or shoe size. This is actually only acceptable if the newsletter is intended to go exclusively to specific target groups. Even then, I think the query of such data is questionable. After all, we know how sloppily such data is backed up today. If you have the e-mail address of a large organization, you can legitimate yourself sufficiently, querying too much data is exaggerated curiosity.

multipart mails

Newsletters are often sent as a multipart. Text and HTML are in the same email. If you have set up your mail program accordingly, you will see either the text version or the HTML version.

The effort appears to be less for multipart mails. However, there are technical difficulties. Often enough you get to see the HTML or CSS code, which doesn't exactly encourage you to continue reading. Of course, this is usually due to the mail program or an incorrect configuration, but the user always blames the provider and not himself.

In addition, of course, unnecessary traffic is caused. With DSL, these 200 to 300 KB may not matter, but with smartphones it is critical. Smartphones often only download the emails completely when the email has been opened, but these latencies are not welcomed by mobile users. As already mentioned, always let your users decide for themselves which format they want.

A good alternative is to provide a link to a designed web version at the top of the text-only newsletter. Since it is opened in the hopefully modern browser, there are hardly any display problems. All HTML tags are available, so that there should hardly be any accessibility problems if the website itself is designed to be accessible.

Another advantage that should not be underestimated is that the mail server is not so heavily loaded, with several thousand mails every kilobyte becomes noticeable.

CAPTCHAs are a no-go

Please do not use the solving of graphic or other codes, neither for subscribing to nor for unsubscribing from the newsletter. CAPTCHAs are by no means accessible, this also applies to ReCAPTCHA.

Conclusion

As is so often the case with the newsletter, it should be as simple as possible. Providers who, for whatever reason, have caused trouble for the user are thrown out very quickly, end up in the spam filter or are deleted without being read. It's a pity to waste this chance because of graphic vanities. At least someone bothered to subscribe to the newsletter, so they're genuinely interested. And it takes much longer to restore lost trust than it does to gain it once.