While most screen readers understand emojis and can read them, that might not be the optimal experience for users. Let's listen to NVDA read this sample subject line with an emoji: The biggest sale of the year You can hear how rambling an emoji sounds next to the text. Although emojis are now commonplace and assistive technology users are probably used to hearing them, it can still feel awkward depending on the emoji. Like any other element or copy in an email, the best way to see if it works or not is to test it and listen to your email using a tool like NVDA or the email checker. Litmus accessibility. Should I also apply "role=presentation" to DIVs? Alice : No! role="presentation" is only meant to tell screen readers to ignore the semantic meaning of markup, so tables need this because tabular data such as charts require all column and row information so that people can read through them and understand them properly. In emails, developers often rely on tables for presentation rather than tabular data, which is why tables require it.
DIVs, on the other hand, have no semantic meaning that should be replaced for screen readers. For customers who insist on using image-based emails, are there best practices to follow? Bettina : It's hard! There are countless reasons why sending image-only emails is a terrible idea. So first, do everything you can to convince your customer that this Image Masking Service approach comes with a horrible subscriber experience. Our blog post on why you shouldn't send image-only emails has lots of information and tips to help you make your case. If there's no way to put your client on the right track, all you can do is optimize your off-image view with ALT text ( you can even style that ALT text ) and use Bulletproof buttons so that at least your CTAs still work when images are disabled.
Does using web fonts impact accessibility? Alice : Code-wise, it shouldn't. From a design perspective, this means that you should always ensure that the web font and its web safe backup meet contrast ratio standards to be readable. For example, if your web font is thicker than the fallback, just make sure the fallback also passes the contrast ratio scores, because the fallback is what users of, say, Gmail might see instead. The only change we haven't made to our code model is the use of the semantic element for headings or paragraphs. We are currently styling the table cell for the text. What issues can this pose for accessibility? Alice : I guess the table that wraps the text already has its role set to 'presentation' or 'none' to limit unnecessary noise from the screen reader. So, aside from this issue, not using the correct heading/paragraph tags would present a navigational problem for assistive devices, as some technologies allow users to jump between headings (and its associated paragraphs) like if it was a table of contents.