Accessibility Nationwide

Hello, I’m Paul Airy Email Specialist at Communities and Founder of Beyond the Envelope.

At the end of 2020, nationwide building society, the world’s largest building society, sent its first accessible email.

The journey to that point had taken the best part of two years, with teams from Communities and Nationwide working together.

This talk is a case study of that journey, and how we married accessibility nationwide.

Two years earlier, nationwide had decided they weren’t where they wanted to be in terms of implementing accessibility into email, and that they should do something about it.

They felt their emails were accessible to a point, but didn’t know how accessible so they engaged communities, their partner of choice to help.

The first part of the process was to formulate a high level brief and high level brief was comprised of two parts.

The first part, and the most important part was to design and develop accessible emails for their recipients, their members. And the criteria was that the email should be w CAG 2.1 compliant to level double A.

The second part was that the process of creating emails should be accessible for their creators, the marketing team. And the criteria was that they could do that without HTML, or CSS in their email creation to Salesforce Marketing Cloud content builder.

Meeting that brief would acquire a team or other teams of stakeholders, each of whom would have a valuable part to play from nationwide. This included the marketing team, who were the primary stakeholders as they would be creating the emails.

The nationwide experienced language team who would be designing the emails the accessibility team, who would be ensuring that the accessibility of the emails aligned with the society’s other accessibility implementations.

The UX research team, which I’ll come to shortly, on the project manager from communities, this included the email development team who would be developing the emails, the account manager who worked with nationwide on campaigns on a day to day basis, the project manager or myself, email specialist, whose role it was to ensure the emails were designed and developed to web 2.1, double A, and liaised with the relevant teams to achieve that.

But before we could design or develop anything, there was some foundational work to do.

W CAG are the Web Content Accessibility Guidelines, and not the email content accessibility guidelines.

So I had to spend some time identifying and documenting which of the guidelines were relevant to email and which were not. Some of the guidelines like those relating to contrast, were clear and non negotiable.

Others, like those relating to text size, were less clear and require discussion and agreement with stakeholders.

Documentation proved to be really valuable when it came to designing and developing the emails.

It also proved to be valuable when I began working with the accessibility team, I helped the accessibility team create the nationwide email accessibility standards. These standards outlined the principles of accessibility and how to put them into practice on the emails a marketing team will go on to create.

These are just a few of the many practices that were included in that document.

To ensure the process of creating emails will be accessible, it was important to understand the current process and for this research was required. This is where the UX research team came in. The UX research team interviewed a number of stakeholders, primarily from the marketing team who worked on the campaigns on a day to day basis. These were observed, albeit virtually, by myself, and members of other teams

began by asking questions about how they created emails, little they were currently using Salesforce Marketing Cloud classic content, and common themes began to emerge.

One theme was an unwieldy number of modules, or content blocks, as they are referred to which they were using to create emails from this being one example.

As well as there being so many, they were not always fit for purpose, which meant they would have to have new content blocks developed that met their requirements.

Another thing was allowed to have some of those content blocks. The two column layout content blocks proved to be particularly problematic, and kept breaking all the time, which was a challenge, given the next theme that emerged.

The HTML and CSS skill set across the team was varied. If less confident members made any changes to content in the HTML, there was a risk that an email might get broken.

Then there was colour or rather the potential misuse of it, which might well impact accessibility, not to mention branding.

The UX research team then went on to ask about accessibility, and on this to the understanding across the team was varied. That wasn’t a surprise. As a nationwide email accessibility standards were currently being written, and no training had yet been delivered.

This research enabled us to formulate a low level brief, a brief, but the nationwide experience language team and I would use to design the emails.

Accessibility has to be considered throughout the email design, development and campaign creation process. So we would build it into the design itself.

We wanted to help marketers ensure that emails were on brand and use the correct typography, layout and colour palette. So we would build in branding to, we would reduce the amount of content blocks down to a maximum of 10. The requirements for these content blocks will be defined by the marketing team from the outset, so they would be fit for purpose.

We would eliminate the need for marketers to use HTML and CSS, enabling them to create their emails by dragging and dropping in content builder.

So that end, the designed will be one column to make them more accessible and easier to work with.

This is an example of a typical email that was being sent out at the time.

It displayed as a desktop email on email clients that do not support media queries, rendering the text illegible. We discovered through research that most of the members were opening their emails on a mobile device. This led to an adoption of a mobile first email design strategy for our new designs.

We also observed there wasn’t distinct heading hierarchy. There were some clear W CAG failures, like the colour of this text.

And content was segmented and constrained, and we wanted it to flow and be easier to read.

So there will be some constant considerations throughout the design and development process to ensure we met the high level brief set out at the beginning and the low level brief set out following the research considerations including email clients, webmail clients adapt how the designs would display on these would be a constant topic during consultations.

Typography was key of course, we will come to that shortly. And then there was layout.

The National wide experience language team then began to work on the email that aren’t constantly consulting me to ensure the designs would display as they had envisaged them, and that they were w ACOG 2.1 compliant to level double A.

We began by looking at typography.

The typeface kabaneri was being widely used by natural mode, especially offline. But early in the process, we decided not to use it, due to the fact that it’s thick and thin strokes made it hard to read.

Instead, Helvetica was selected. This sans-serif typeface was easier to read on the serif typeface kabaneri. However, given that Helvetica was not web safe, and could not be guaranteed to be installed on members devices, we also selected a fallback typeface

that fallback typeface was Arial. As this has similar characteristics to Helvetica, but is very much web safe.

We also considered nationwide and bespoke fonts NBS medium and NBS bold as a future progressive enhancement.

When it came to text size, and paragraph size, in particular, we considered a number of options. As Wk 2.1 does not specify a minimum size, only that text should be able to be resized without the use of assistive technology, up to 200%.

We decided on 16 pixels for Paragraph Font Size on my recommendation. And for Lionheart, I refer to the guidelines which specify that line spacing should be one and a half times the size of the tech side, which we styled at 1.5. And

type scale was created using the paragraph as a base size with heading styled larger and bolder.

Without then began looking at the content blocks.

In answer to the brief, they were designed with accessibility and branding built in, and with the flexibility the marketer needed to add on demand image untouched content. All the key elements were considered, including lists, links, buttons, and divided.

This is a newsletter header content block.

The basic header content block, the body content block on the footer content block.

The buttons were designed to be bullet proof. And we opted to develop these with border radius and without VML. It was agreed and understood, they would appear rectangular on versions of Microsoft Outlook.

Colours were checked throughout the process to ensure they met w current 2.12 below. Now we were ready to develop.

The content lock designs were handed to the email developer and work began to bring them to life in content builder.

More of the teams now began to work together as a marketing team were presented with the new content blocks in situ

In contact builder, and they began to experiment with them.

The response was delightful is easy. That’s exactly what we wanted to hear. Yes, there was a few niggles, but only minor ones, it was all going great. Until the same way that I had been working with a nationwide experienced language team on the design, I would work in with email developer on the development.

One of the implementations we made was the application of a role to the HTML tables, so that screen readers would treat them as presentational tables, and not data tables.

I discovered that in order that they will function as drag and drop elements, content builder was wrapping the content blocks were developed within HTML tables. And these tables did not have a role applied to them, and could not have a role applied to them.

This significantly compromised the accessibility of the emails. And so I immediately reached out to nationwide and Salesforce.

This led to a rare series of calls direct with the Salesforce Marketing Cloud content builder product team, who responded to us with a number of different solutions that involve having to work with HTML and CSS. And with those responded to them by saying how that would not be feasible.

However, the content builder team, were keen to express how important accessibility was to Salesforce and thanked us for highlighting the issue and committed to putting a fix on the product roadmap, which they did.

The emails were now finished.

We began with emails that were accessible to an extent.

We finished with emails that were accessible from a design and development perspective. And with the documentation that would ensure they will continue to be they were mobile first.

They were spacious and easy to read.

So result, there were some initial teething issues. But nothing serious, hasn’t been any broken emails.

Of course, accessibility has been successfully implemented.

And what did nationwide have to say?

We found a great balance in achieving our accessibility goals for email, whilst also making them far easier to create.

Now, for some takeaways.

Accessibility starts with design. It continues with development and ends with content and therefore it never really ends. And it’s continually being implemented.

Build into design as much accessibility as possible, leaving as little as possible for marketers and content editors.

When challenged on design, and whether something’s accessible or not, let the guidelines guide you.

And remember, the guidelines aren’t comprehensive. They won’t tell you what typeface or type size to use, for example, so you’ll have to use your discretion.

Lee leave as little accessibility implementation as possible for marketers and content editors.

Train marketers and content editors on relevant accessibility implementation techniques, such as the application of alternative text, put things in place to quality, check accessibility.

And finally, drag and drop tools. Don’t assume they’ll code accessibly. Always check.

Be aware of wiziwig, what you see is what you get features that could break accessibility and if possible lock design down.

Thank you