Basics

Data tables in email – Part 3

Okay – in Part 1 we talked about how people use data tables, what the important parts are and a few of the obvious issues we have in email surrounding data tables. In Part 2 we talked through how to test them and common e-receipt designs and how we would want to construct them so they make sense to all users. Today I’m doing Part 3 and we’re going to go deep into what happens when we throw data tables into email clients!

So I did what I do best and did the deep testing around table headers and how they work in email clients and wow was I surprised, and maybe I shouldn’t have been surprised since tables are the literal structure that holds html emails together… but here I am.

Testing results:

Table headers worked just fine in emails (18/21 email clients tested) – there was only one email client that absolutely failed and that was Outlook 365 (no surprises there!)

Using ids and headers worked nearly as well (17/21 email clients tested) – they worked everywhere except for Outlook 365 and the Yahoo app on android, so nearly the same as the above.

I ran into a bit more trouble getting the subtotals to be read appropriately (as in stating the connections between the row headers and the content – ie. “Subtotal: $30”) But both the semantic table header solution and the ids and headers solution worked nearly the same. (16 and 15 email clients supported)

If you recall in Part 2, I was concerned about having one large table (which is important for cohesiveness of the table content and relationships to the data) but the semantic table header solution caused more complications because the Description and Subtotal, Tax, and Total headers all competed with themselves. This is why using the ids and headers was such a good solution – it clearly separated the Description column header from the Subtotal section’s row headers.

I was surprised to discover that actually worked pretty well on Android Talkback on both gmail and yahoo mail apps, as well as Yahoo.com using Voiceover on a mac. That is only 3 out of 21 tested email clients, but that’s better than the 0 of only using semantic headers so…

Since both options had about the same amount of support I think you could use either solution to suit you, but probably easiest to stick with the simpler, semantic use of table headers. You can take a closer look at my data table on data tables here if you want the details.

That also means that since we know that our column headers and row headers in more complicated table setups will get crossed (like my example) we should do what we can to make sure our table headers are as short and sweet as possible.

Surprise! Gmail maintains relationship attributes!!

There was one thing that I found in my testing that caused a massive double take, and it’s so cool I wanted to catalog it here even if it’s essentially a big nothing burger since it still didn’t really do what I was wanting.

Email clients are notoriously weird about accessibility features and attributes. Mark Robbin’s notes on aria-labeledby are a good starting point, as is nearly a whole bunch of this blog, but specifically this post about aria-label vs alt text, then there’s the whole VML thing, how landmarks work better than expected, and just the whole of my interactivity series.

For a quick reminder – this is what the aria-labelledby attribute (and it’s associate id) does in gmail:

In the web world, the id and the aria-labelledby are relationship attributes that tie the heading title and the “read more” text together. We would expect AT to read the above link as “13 ARIA attributes you need to know, read more” – just by connecting the two ids (attr and rm13) and aria-labelledby together.

But in the screenshot, you can see the original id values “attr” and “rm13” with a red underline, and the green prefix that gmail had added. You can also see the aria-labelledby attribute doesn’t have that prefix in it, which is essentially why we can’t use aria-labelledby in email, too many email clients kill the relationship between the two parts.

So we email developers have this really long and established experience of having to find weird hacky ways to meet accessibility where we can, all the while hoping email clients will actually catch up.

So you can imagine my shock when I started testing the different data table solutions from last week’s post and it… wasn’t that bad??

I checked gmail first and sure enough when I got my tables in I looked at the code and there it was – the added prefix on the ids in green: 

But!!! Look there!! In the headers attribute those same prefixes are there!! Exactly the same!!

Amazing <3 

So this means that those relationship attributes are connected in gmail the way they are supposed to!

Honestly makes me wonder if somebody at gmail just needs to do whatever they did with headers to the aria-labelledby attribute. (Could it be that easy??!!!) 

Oddly enough – even though these connections still existed, the separation I was trying to create between the Description, Subtotal, Tax and Total headers still didn’t do what they were supposed to do. I couldn’t find a good reason for this – it basically worked just like the semantic table headers in gmail so there wasn’t really a gain here.

Gmail, am I right?

Responsive Tables

Put a finger down if you ever had to try to create a responsive data table for a pharma client and by the end of the project your eyelid was twitching.

Yea… sooooo… it’s not easy being an email developer, we all know this – and for plenty of us it’s a source of pride to do a thing well and when we’re talking about accessible experiences – responsiveness is one of the top ways we can make emails work for everyone.

Reminder: The most popular assistive technology is the smart phone – so having responsive solutions that are truly responsive (no scaling text) is a critical part of what we’re doing here.

Responsive Data Table Solve 1: Refit

So in most situations your e-receipt data situation should be simple enough that it will still fit inside your smaller mobile devices without issue, or it just takes something small like a scale on your image so it shrinks down a bit to fit. In most of the scenarios I’ve looked at, that’s an easy enough fix.

This also highlights why I’m such a big fan of 100% wide mobile emails instead of fixed pixel width, it makes reflowing these so easy. In this scenario it’s easy enough to have maybe one column forced width in desktop and then you can change that width in mobile so it looks right.

The above is probably the easiest/best solution if you can make it work.

Responsive Data Table Solve 2: Hide

Then you have the “hide columns until it fits” solution, which I really don’t like, especially if you’ve used any colspans to control things in desktop – if so then you will want to be sure to test the mobile version of your table to make sure those connections all still work and that you’re still getting a good amount of information.

Responsive Data Table Solve 3: Separate Tables

I also found this really intense e-receipt on https://reallygoodemails.com/emails/weekly-usage-summary-for-rge: 

It’s really long, but if you dig around in the code there’s a few pleasant surprises – 1) The desktop version is using table headers appropriately 🤌😘 and 2) The mobile version is completely separate. This obviously lets you be fully in control of the accessibility aspect of the mobile version, and lets your content run fully out of control with absolute layout changes. This is a really great solution when your e-receipts are this info-packed!

One quick warning: Don’t go too deep into web accessibility solutions for tables, there’s definitely good stuff but the ability for email clients to handle say Mobile Responsive Table Scrolling, for instance, is severely lacking. As always, when looking at web solutions you really gotta test this stuff out irl.

One Last Thing

I think it’s important to point out that navigating around data tables is kind of annoying. It took me hours to test these solutions and determine what was me floundering because I didn’t know what I was doing, and me floundering because the data connections weren’t working.

When we include data tables without appropriate table headers it really makes this navigation more complicated.

Sometimes, when we create emails we don’t think about the end result. I’m confident that my favorite art store retailer wasn’t thinking about how complicated it would be to go through a receipt without table headers that’s full of individual pencils, right?

And while this one really isn’t so complicated from a user perspective (they’re just pencils, after all) it’s easy to see how much more complicated this stuff can get.

Is this 10 digit number a phone number or the order number?

Was this product I bought on sale? Is this price for the sale product or something else?

Am I being taxed the appropriate amount?

So we have to take this stuff seriously and really do the work to make sure that our e-receipts are accessible and easy to use by everyone.

So whether you use ids and headers, or the semantic row and column table headers – make sure that all users can understand the relationships that exist in your data tables… and test your data tables to make sure they do what you want them to do. 🙂 

At the end of all this testing, the takeaway isn’t cutting edge data coding – it’s foundational. Well-structured, semantic table headers are still the most reliable and maintainable way to build accessible data tables in email. The more complex solution didn’t meaningfully improve support. If you’ve been following me along for a while, you’ll know that I tend to lean into the more semantic and simple solutions whenever I can, and here’s email reminding me once again to keep it simple.

So if you’re building e-receipts, start simple, test thoroughly, and let the structure do the heavy lifting.