Standards, Semantics, Accessibility, and HTML Email

You can love email, you can hate email. An opinion can vary from one extreme to the other when asking any group of people, but almost everyone using the Internet spends part of their day sending, receiving, and reading email. One thing that the majority can agree on is having a dislike for HTML emails. Not only is the inclusion of HTML a red flag for most people (and software) that the message is spam, the email more often than not comes out looking like a billboard that got sent through a washing machine.

Why put together an HTML email at all?

Sometimes as a developer, you’re asked by clients to do things that normally wouldn’t cross your mind for one reason or another. HTML emails could fit into this category for many developers, but the fact of the matter is, it’s almost guaranteed you’ll be asked to put one together for a client at some point in your career. Clients will always love having the ability to send out a mass email that looks better than their competition, there’s no denying that, and there’s nothing wrong with it either. You can’t blame a client for wanting to get the most out of their Web company.

The difficulty for you, the developer, will come in with the design and development of the markup itself. Throughout the design you need to keep things simple. We’re well aware that email markup is a battlefield that no one is comfortable working on, You can still have a very effective HTML email design while keeping it simple and to the point.

Treat HTML emails as you treat webpages

Just because this particular document will be read in an email client does not mean that your development process should be any different than that of a webpage. It’s true that your technique will be modified to handle the new rules of your environment, but the fundamentals are the same. Always keep semantics and best practices in mind.

Are there any best practices for HTML emails? Sure there are, you’re dealing with HTML and CSS, and therefore all of the associated guidelines can be applied. The differences here require that you can assume images are disabled by each and every person reading the document. Many email clients will disable displaying images from external sources by default, which will include every image used for the design of your HTML email.

Tables are not the solution

It has been said many times that the true way to attack an HTML email is to get back into using a table for structuring the design. The standardista in me couldn’t disagree more. I don’t write this to offend anyone who stands behind the technique, but I can’t help feeling that it takes a step back. Using tables to structure the design of an HTML email disregards readers having to use alternative technologies to read their email. Semantic markup will be more beneficial than a table based layout.

In my personal opinion, if an HTML email is requiring the use of tables to achieve your desired effect, it’s time to revisit the design itself. Naturally from time to time, a client will demand a very specific design from you, and the only way to achieve it is using a table. Telling a client you can’t help them because the project inherits bad semantics can’t happen, you’ve got to pay the bills. The idea is to avoid their use until it’s absolutely necessary, and hopefully you’ll continue to be table-less in your development.

One of the most common reasons for using a table is to provide cross-client centering of elements in the design. Having the ability to center elements is very often a benefit to developers and a requirement of the design. Taking that away can severely limit an HTML email. Some popular clients don’t support centering via CSS with:

div#heading { width:500px; margin:0 auto; }

Instead, style your document in such a way where you can control the left and right margins with a known value that will result in the centering of an element. For example:

div#heading { width:500px; margin:0 0 0 4px; }

Using that style will often result in a centered element if you’ve styled your document in such a way where you know the width of your elements and their parents. Centering elements is now more work, but it helps as one technique to avoid having to resort to using a table.

Something else to keep in mind is that it is exponentially more difficult to deal with CSS support within HTML clients than it is for Web browsers. Web browsers will boast their support for CSS and standards-based markup. Email clients? Not so much. At the root level, they’re meant to send and receive email and get that job done. On top of that, superior organizing abilities among other additional features will help your email client stand out above the rest, but you don’t hear many people saying they use Thunderbird because it has great support for HTML and CSS email.

There has been a lot of literature on the ins and outs of HTML and CSS support using various email clients deemed most popular. One of the most extensive and comprehensive articles I’ve found is a piece posted to Campaign Monitor. Testing any HTML/CSS email can literally be an endless process, and knowing some pitfalls ahead of time can be beneficial to you.

Images are very important (to your design)

I’d like to emphasize that it should be a high priority decision to develop an HTML email around the idea that images are going to be disabled by default for the majority of readers. Both inline images and background images will be invisible to many people either permanently (due to email client settings) or until images are enabled by the reader on a per-message basis. It’s been said that first impressions are very important, and that people can tell whether or not they “like” something within seconds of seeing it. Keep that in mind when testing your HTML email. Don’t automatically enable external images, test with them disabled to be sure you’re making the best of your situation. That being said, it’s even more important for you to provide excellent alternate content for your readers, so should they decide not to enable images, your message is still conveyed.

Offer an alternate version for your HTML email

It is very important to offer alternate content for everything, HTML email included. There is a significant probability that a large percentage of readers who are going to receive an email will have the option to display HTML disabled; not only for personal preference by many, but it’s also a common security precaution put into place in corporate environments.

Something to keep in mind at the very least, is including a link to an online version of the message. Allowing a reader to view the document in a Web browser would be the least you could do. Better yet, offer a text-only version of the message for those readers who don’t accept HTML email. Many times, it’s stated that a text-only version is exactly that, and that it’s being displayed because you (the reader) have disabled HTML email. Including a message like that is unnecessary, because the root purpose of the email itself is to convey a message, not a design.

Further Reading

There have been many articles posted detailing actual testing of various techniques in multiple email clients, some of the better articles I’ve found are listed below:

How do you feel about HTML emails? Do you have any tips or tricks that have helped you in a pinch?