Basics

Functional Accessibility vs Technical Accessibility

I’ve been trying to write this post in my head for a while now, I hit on a good chunk of it when I talked about the Accessible Digital Ecosystem, but I think there’s more I can say here.

We also hit on this a bit in the email geeks accessible email channel, which continues to be an amazing resource if you’re not already on it.

It can be really confusing when you hear different solutions from different sources in our industry. We always want it to be super simple, but at the end of the day there’s a lot of nuance to email specifically, and then there’s also a lot of nuance within accessibility, and that can be hard to sort out.

Generally, when I’m giving advice here, I talk a lot about the functional aspects of email accessibility. Email marketing has limits that keep it from being accessible the way web can be accessible – we’ve talked about some of these before:

  • We use layout tables
  • We love to link everything!!
  • Email clients don’t support a lot of stuff
  • Assistive technologies don’t support a lot of stuff in email clients

Then we have some specific scenarios where web accessibility best practices don’t line up to normal email experiences.

The specific scenario we were talking about in emailgeeks was an issue someone was having when a user was getting the content from the <title> tag in their preview text. They couldn’t replicate it, but the client sent a screenshot. I’ve had this happen too – it’s a pain – there’s a handful of things you can do about it…

But let’s back up a bit – what is the purpose of the title tag?

W3schools gives us some good info:

The <title> tag defines the title of the document. The title must be text-only, and it is shown in the browser’s title bar or in the page’s tab.

The <title> tag is required in HTML documents!

The contents of a page title is very important for search engine optimization (SEO)! The page title is used by search engine algorithms to decide the order when listing pages in search results.

The <title> element:
– defines a title in the browser toolbar
– provides a title for the page when it is added to favorites
– displays a title for the page in search-engine results

    So we know that a title is important – it’s required and it serves a solid purpose from a functional perspective.

    The title of the page is what is displayed at the very top of your browser window that helps you distinguish one tab from the other – along with the favicon. (Unless you’re me – notorious tab junky – and I had to actually close 80% of my tabs just now to confirm this is actually still true)

    From an accessibility perspective, the page’s title is also really important – it tells users what the main content of the page is. It helps users navigate through tabs and pages, and generally gives users additional information about the content of the page.

    Having a title element is required in html documents – every single accessibility checker (including our beloved parcel and litmus) will ding you for not having a title element in your file.

    …but…

    It’s really not necessary in your emails. 

    Functionally – no one is getting your html file and opening it alone in a browser.

    I mean, me, myself, as an email developer – I’m into html files all the live long day. I send html files for review, I review html files, I am forever looking at html files in browsers and editors.

    But users? They’re using an email client.

    They get your email in an email client – which has its own title element.

    Go ahead – open another tab – go to your gmail – click on an email.

    The subject line is the title.

    This is true in every email client I can currently test – and probably true just about everywhere.

    Even in an interpersonal email – the subject line is the title.

    This is how email clients work – even desktop clients like outlook. You double click on that email and it pops up in a new window – and the subject line is the top of that window (functionally the title).

    Special thanks to Steve Atkins for providing a link that says the same thing: https://html.spec.whatwg.org/multipage/semantics.html#the-head-element

    The title element is a required child in most situations, but when a higher-level protocol provides title information, e.g., in the subject line of an email when HTML is used as an email authoring format, the title element can be omitted.

    So… why is this on email checkers? Technicality!!

    Even in the web world – there is a lot of pedantic conversation/arguments about what is technically accessible vs functionally accessible. They are generally great arguments, really, we all learn something new as someone finds examples that prove their point.

    So – back to email – all of these things are true:

    • Your html file is not valid without a title element.
    • Your html file will not pass an accessibility checker without a title element.
    • Your html file is violating WCAG 2.4.2: Page Titled (Level A)
    • Email users will never functionally see the title element – it is replaced by the subject line in every scenario I’ve tested. 

    Note: For clarity – there is one situation where the title tag is important, and that’s the email you see when you click the view in browser link. If you don’t have a title there, you’ll get some weird content in that title bar. This is why it’s still important to have a title there, even if it’s not going to be seen by nearly all of your users.

    There are actually a bunch of these kinds of issues that are functionally not a problem, but technically a problem:

    • Role=”presentation” has no impact functionally, from my tests
    • Setting a language in your html file doesn’t change how the content in your messages are read in my tests – the language you set in your OS or your email client settings does though!
    • Using a relative font size? Not as important as building a flexible email – the font size will change if you use pixels in every email client I’ve tested.

    So… why are we email accessibility nerds telling you to do it?

    Because it’s technically correct, it doesn’t do any harm, and by the off chance that some combination of assistive technologies and email clients does pick up on these technical failures – you’ve got a bulletproof email that will still work.

    What does that mean for you?

    Well – hopefully it helps you prioritize the content of your email so that you can ensure your hard work is actually making positive change.

    What’s important vs what’s not important? Here’s a quick list of my top issues for each:

    Important:

    1. Careful animated gif use*
      1. Bad animated gifs can actually hurt someone
    2. No VML (“bulletproof” buttons and background images)
      1. VML can cause elements of your email to not work, duplicate text, and readout formatting – all major failures.
    3. Appropriate alt text*
      1. There’s a lot to alt text in email
    4. Color contrast (don’t forget dark mode!)*
      1. Poor color contrast can cause your content to not be read
    5. Use semantic text (and live text)
      1. Loads of problems with text semantics and problems with images of text
    6. Intentional linking and descriptive links*
      1. How we treat links in email are critical

    Not as important:

    1. Directional attributes (unless they mess with keyboard navigation)
      1. It’s definitely possible that in some email clients this could be an issue, but not in my tests
    2. Whole-document language declarations
      1. I spent more hours then I’d like to try to change the language in a document, it’s possible that it could be a problem somewhere, but not in my tests
    3. Role presentation/none on tables
      1. This used to be a problem, but recent tests showed no difference – screen readers are better at finding layout tables and reading them appropriately.
    4. Title tags in your html head
      1. See above
    5. Not having an align=center or your table elements
      1. I think this is trying to push not having centered text, but there’s quite a few different ways to change the alignment of text these days, but yes, your text shouldn’t be centered unless it’s just a line or two.

    * Issues you have control over, even in a no-code builder

    To that end, I don’t always agree with the severity some of our email accessibility checkers place on some of these elements. I don’t really broadcast them because, again, they’re not wrong, they’re just not as functionally important as other things I’d rather folks focus on.

    Like – if you have no role presentation on your tables but you have a big vml background image with lots of text and links in it? The vml is the bigger problem.

    I will call both out in an audit, but the severity is the functional implications vs the technical.

    It also helps that these items I’ve determined to be less important are really, really easy to implement if you’re coding. Nearly all of them are resolved once and if you’re using any kind of modules or snippets – you never have to think about them again.

    So it’s a super easy thing to resolve, if you can, and if you can’t you can sleep a little easier knowing that you have bigger fish to fry.