Accessibility
Email Accessibility Report 2026
This report serves as a technical audit of the senders, platforms and email clients that define the modern inbox. The results below are from analysis of over 376,000 emails across senders and geographies, looking at how each email scored on a detailed accessibility scorecard. This year’s report also looks beyond the sender, including views of widely used newsletter platforms with built-in email build/authoring tools.
The 2026 Email Accessibility Report reveals an industry at a technical standstill. Despite a marginal uptick, the email ecosystem remains in a state of systemic failure: 99.88% of the 376,348 emails analyzed this year contain ‘Serious’ or ‘Critical’ accessibility defects, leaving only a 0.002% pass rate represented by just eight emails from three brands.
In this year’s report, we are also looking beyond the sender and at widely-used newsletter platforms with built-in email build/authoring tools. We audited 10,566 emails sent via Substack, Shopify and Beehiiv. None passed our automated testing.
When it comes to email clients, we have taken a deeper look this year, nearly doubling our email client accessibility criteria from 20 to 37 feature benchmarks. The data is clear: a major reason why accessibility is failing in email is a lack of implementation.
- 99.88% of HTML emails tested contain accessibility issues categorized as “Serious” or “Critical”.
- Only 8 emails (0.002%) passed all accessibility checks. These emails came from just three separate brands!
- The majority of the issues are not edge cases. These are basic, machine-checkable accessibility failures.
- No email clients support all HTML/CSS accessibility features tested on “Can I Email?”
Tooltips that work for everyone
Here at Eleven Ways, we often get asked for “the correct, accessible tooltip pattern”. Building accessible tooltips is a minefield — especially when you mix in rich content and screen reader quirks. Let’s examine the issues and go in search of a tooltip pattern that truly covers all our bases.
There is no one-size-fits-all solution, you must choose based on your specific use case.
1. Do you really need a tooltip?
Our first recommendation is to place information in an easy-to-reach way near the element. For input fields, adding a description below the field and using aria-describedby is the most straightforward method.
2. Best overall tooltip
For most scenarios, a tooltip based on aria-describedby (as exemplified by Deque) remains the best option.
- Caveat: Do not include links inside the tooltip.
- Caveat: Do not use them in text blocks where they must be read in context.
If you do want to use them on links, you’ll have to wait until Microsoft Narrator is fixed.
CSS
Scrubbable Staggered Animation with CSS @function
Everyone who has spent time creating staggered effects with CSS has reached for animation-delay or transition-delay at some point. Vary the delay slightly for each item, and you get that satisfying cascading effect. It works. But it’s not transferable. You can’t scrub through it, tie it to scroll, or link it to any external progress value. Each element lives in its own isolated timeline.
There’s a different way to think about staggered animation — not as a collection of independently timed objects, but as a single predictable, holistic effect driven by one progress value. You can then easily connect that progress value to an animation, scroll progress, or any other input to drive the staggering.
In this article, we will learn how this can be done using a mathematical formula, which I’ll call the stagger formula. We’ll build it step by step, understand exactly how it works, and implement it in CSS using the new @function rule.
Animate Scroll Triggered - Use Animate.css with the CSS scroll-triggered animations
A tiny CSS-only scroll-trigger adapter for Animate.css.
Animate.css stays unchanged. You keep using the normal Animate.css classes and add one extra class, .animate-triggered, to control when the animation is played while scrolling.
Animate.css animations are normal time-based CSS animations. This adapter does not turn them into scroll-scrubbed animations. Instead, it starts the existing Animate.css animation when the element crosses a scroll trigger range.
That makes it useful for reveal effects such as cards, sections, teasers, tiles, and small scrollytelling steps.
Scroll-Driven, Scroll-Triggered, Scroll States, and View Transitions
I’ve said one and meant another, and I’ve used one when I needed another. Please bear with me as I note the high-level similarities and differences between scroll-driven animations, scroll-triggered animations, container query scroll states, and view transitions for my future self.
The Field Guide to CSS Grid Lanes
Learn Grid Lanes to create masonry layouts in pure CSS. Absorb the possibilities with the Field Guide’s interactive playground. Return to the cheat sheet. Get inspired by six real examples with dozens of variations.
CSS is filling the gaps with rules. A way to style gaps in grid and flex
A practical walkthrough of CSS gap decorations: column-rule, row-rule, rule-break, rule-inset, rule-visibility-items, repeat(), and animation.
CSS Can Now Animate Between Pages: View Transitions Without JavaScript
Cross-document view transitions bring app-like navigation to classic multi-page sites — with a single CSS at-rule and no framework at all.
Demystifying the View Transition Pseudo Tree
Every time a view transition is initiated, a pseudo-element is added to the HTML element for the duration of the view transition. This acts as a snapshot overlay across your entire page.
Each pseudo-element plays a distinct role in how the view transition animates. The browser does most of the heavy lifting, which makes it a little hard to see what’s actually happening under the hood. This article breaks down each pseudo-element in the tree so you know exactly what to target when you need to customize things.
HTML
What is the minimum markup needed to create a modal?
Is it possible to build a modal dialog without any JavaScript at all?
Context-aware headings in HTML
A common issue that we've probably all faced at some point is having a component that includes a heading, which sometimes should be an H2 and sometimes maybe an H3, depending on where it's used.
We solved this by giving editors an option to pick the appropriate heading level in the CMS. That works, but it means more work for them, because they need to keep track of the document outline, and it's also a potential source of error.
Yesterday, I heard about a new experimental attribute that offers a better solution to this problem. The headingoffset content attribute allows us to offset heading levels for descendants.
JavaScript
Observatory - A JavaScript Class to simplify managing Mutation Observers
Observatory is a JavaScript Class to simplify managing Mutation Observers by encapsulating their lifecycles, providing states per-instance, and making it easier to extend and add additional features on top.
GitHub repo here.
Geometric.js - A JavaScript library for doing geometry
Geometric.js is a JavaScript library for working with points, lines, polygons, and angles. It uses plain JavaScript arrays for geometry primitives, includes TypeScript declarations for editor autocomplete and type checking, and works in modern browsers and Node.js.
GitHub repo here.
Micromodal.js - Tiny javascript library for creating accessible modal dialogs
Micromodal.js is a lightweight, configurable and a11y-enabled modal library written in pure JavaScript.
It enables you to create WAI-ARIA guidelines compliant modal dialogs, with confidence and with minimal configuration. At just 1.9kb minified and gzipped, its a tiny library for big change.
GitHub repo here.
Taiga UI - A powerful set of open source components for Angular
Taiga UI is fully-treeshakable Angular UI Kit consisting of multiple base libraries and several add-ons.
It is based on ng-polymorpheus dynamic content approach and uses Web APIs for Angular for required browser APIs.
GitHub repo here.
The quiet problem with unnecessary async
Not every JavaScript function needs to be async. Unnecessary async boundaries can spread Promise-based complexity through an entire application.
A rough rule I follow: async should represent real async boundaries, not hypothetical future requirements. If a function doesn’t await anything, it’s worth asking why it’s async in the first place.
Instead of designing around what a function might someday become, design around what it is today.
Miscellaneous
Lawful Design
There’s a moment in nearly every project where the work stops being about the user. Someone from legal joins the call, and suddenly the clean flow we spent weeks refining has to grow a checkbox, a banner, a paragraph of fine print, or an entire screen that exists only to protect the company. It’s easy to treat this as the enemy of good design. I’d argue the opposite. Legal requirements are constraints, and constraints are where design actually happens.
The trap most teams fall into is treating law and experience as adversaries fighting over the same pixels. The lawyer wants to be defensible. The designer wants freedom. Both of those goals can be true at the same time, but only if the two disciplines are in the room together early instead of handing artifacts back and forth at the end. When legal shows up after the design is “done,” you get the worst of both. A bolted-on disclosure that satisfies no one and a flow the user doesn’t want to use ever again.
The goal of this article is to walk through the places where law touches our work and show that legal expectations and low friction aren’t opposites. The best solution is almost always the one that achieves both.
The Website Specification
The Website Specification is an attempt to answer one question: regardless of the stack you build on, what should a good website do? Not a framework. Not a guide. A spec — what is required, what is recommended, and what to avoid.
The web is a layer cake of standards. WHATWG defines HTML. W3C ratifies WCAG. The IETF publishes the RFCs behind security headers and /.well-known/ URIs. Search engines publish their own rules. Browsers add their own quirks. Designers, developers, and accessibility specialists each carry a slice of the picture. Almost nobody carries the whole picture.
This site collects the slices into one platform-agnostic specification — sources cited, MIT licensed, open for pull requests.
UI Skills for Design Engineers
Discover curated UI Skills for design engineers, including accessibility, motion, frontend craft, and interface quality guides with copy-ready install commands.