Update: December 13, 2024: “Thank you so very much for your assistance. I have exciting news! Smile. I went to the online version of the newsletter and navigated by headings as usual. When I heard the word link I pressed return with no result. I then used the contextual menu VO SHIFT M and was given several options from which I could choose to open the link. I selected open in new window and was able to read the article without any problem. I just thought I would let you know. It may be beneficial to others. Thanks again for all of your informative articles and all you do for the community.” – Rhonda Hornbacher, Top Tech Tidbits Reader
Summary: Custom-coded newsletters prioritize accessibility, ensuring compatibility across platforms and mitigating accessibility issues common with block builders. This post explains the nuances of using custom HTML to create and send email newsletters, particularly with VoiceOver in Apple Mail, and the importance of maintaining control over the HTML code itself for consistent accessibility. Despite higher costs, this approach guarantees a more accessible user experience, highlighting the need for improvements in screen reader technology. Read on for insights into these accessibility challenges.
Greetings everyone. Aaron Di Blasi here, Publisher for the Top Tech Tidbits and Access Information News weekly newsletters.
I have spoken with a large number of you regarding this issue via email over the last 4-5 months and I was recently asked by someone in the community to write a post about it so that everyone could be in the know. This is that post.
🍎️ Before we delve into the issue itself, a wee bit of background first.
Both the Top Tech Tidbits and Access Information News weekly newsletters are custom coded each week. What does that mean? It means that the newsletter template itself was written by us (Mind Vault Solutions, Ltd.) and that each weekly newsletter is also written by us, using HTML, each week.
At the end of the week we send you that HTML as a newsletter. Our email distribution platform, Constant Contact, automatically generates a text version for those email clients that still support it.
🍎️ Okay. So why is this so special? Doesn’t everyone custom code their email newsletters?
In a word, no, they do not. The vast majority of email newsletter publishers today, more than 97%, use block builders, which provide an interface for creating newsletters without having to know how to write code.
🍎️ So why not use a block builder?
Because when you run into an accessibility issue, and you will do so quickly, you are left opening tickets and arguing with support and never really getting the accessibility you need. And this continues, over and over, until your newsletter is basically unusable by your audience. Something we had to learn the hard way back in 2004.
By keeping the underlying HTML code under our control we can respond instantly to any access issues that might arise, including workarounds for specific technologies that no longer function properly due to deprecation, obsolescence or both.
But this power comes at a cost, literally, as not all email distribution platforms permit the use of custom HTML.
🍎️ Why not?
Because it introduces security concerns for them.
If they control the code then they can control its security, but this also puts accessibility in their hands as well, and I’ve already explained why that is not a good idea.
So we pay a premium to stay with an email distribution platform that permits us to use our own custom HTML code. I estimate that we could cut distribution costs by approximately 50% if we could move to another distribution platform, but these platforms either do not permit full-on custom HTML, and/or impose character limits that would make our newsletters impossible to send.
And so, the moral of the story that will surprise no one reading this is that accessibility comes at a cost, whether we like it or not. Whether it’s “right” or not. We still must have access. And so we continue to send and maintain both newsletters in this fashion, and will do so for the foreseeable future.
All of this means that we have to have a way to test the code that we write for each and every newsletter each week.
🍎️ Why?
Because we are human beings. And human beings make mistakes. No matter how hard we try not to.
And so, we turn to the world authority on HTML validation. The W3C.
Among many other tools, the W3C provides a free HTML markup validation service.
One of the ways that you can use this tool is by simply visiting the page and entering a web address. The tool will then tell you if the HTML present at that web address is valid (compliant by W3C standards).
You can test this yourself using any newsletter link. Let’s take the most recent issue of Top Tech Tidbits (as of this writing) as an example.
The link to the issue online is: https://www.toptechtidbits.com/tidbits2024/08082024/index.html. So all you have to do is paste this link into the W3C HTML Markup Validation Service and click “Check.”
Now, surprise, surprise, you will see 12 errors listed. But, believe it or not, those errors are “intentional.”
Yes, you read that right. They were intentional.
🍎️ Why?
Because email clients today do not fully support CSS the way that web browsers do, so all email publishers in the world today are forced to use deprecated HTML technologies, like “TABLES” and their deprecated attributes, in order to achieve consistency across email clients. This is a common practice that applies only to HTML that will be rendered inside of an email client, as opposed to a web browser. In these instances we are advised by the W3C to “filter out” these deprecations upon validation. Which we do.
🍎️ Okay, so what does all of this have to do with VoiceOver HTML interpretation inside the Apple Mail client?
A great question that we can now answer.
“We have discovered that VoiceOver has an issue reading back nested heading tags when the HTML is rendered inside of the Apple Mail client. Even if that HTML, and those nested headings, are accurate according to the W3C.”
Many, many readers have reported this issue.
They have also reported that when they used VoiceOver to read the same newsletter online, in, say, Safari, that the issue went away for most, but not all. Which could point to a deprecation issue. That is, software that gets worse the older the technology on which it is used gets.
We’re not really sure what to do about it.
🍎️ Apple? Are you reading? Help!
Though I doubt that’s going to get us any traction.
What I do think might get us traction are the forthcoming updates to VoiceOver. Thanks to AI it looks like Apple plans to do a complete overhaul of VoiceOver, and hopefully, it’s in-email client HTML rendering as well.
We never like to tell readers they have to go somewhere else to read the newsletter, but this is precisely why we provide the very same custom code online each week. So that if your chosen screen reader or email client runs into trouble, you always have an alternate way to access the newsletter.
In short, there is nothing that we can currently do, code-wise, to fix this issue. The issues resides with VoiceOver and the Apple Mail client and the way that specific stack renders HTML presented inside of the Apple Mail client.
An issue that I sincerely hope gets remedied with the forthcoming updates to VoiceOver.
I hope this information helps everyone to better understand the issue.
If you have any comments, tips or experience with this issue that you would like to share with me, or the access community at large, please feel free to reach out to me at publisher@toptechtidbits.com 📧️.
