HTML email is still HTML, rendered by a user agent — a webmail client is a browser, and a native mail app's rendering engine isn't fundamentally different. WCAG's success criteria don't carve out an email-specific exception, and they apply just as directly to a CSS-only poll, quiz, or accordion as they do to the equivalent web component. This is a practical checklist for the four criteria that matter most to interactive, checkbox-hack-driven email.
Why WCAG applies here at all
WCAG 2.2 is written in terms of "content" rendered by a "user agent," not "web pages" specifically — it's not a formal, email-specific standard, since email as a medium isn't named in the spec at all, but the underlying content is HTML either way. That's why the accessibility community treats WCAG's success criteria as the practical bar for email content, the same way this checklist does, rather than treating email as a separate category the guidelines don't reach.
1.1.1 Non-text Content — every image needs a real alt
Product photos, hero images, decorative separators, and icon-only buttons all need an alt attribute a screen reader can announce — or, for genuinely decorative images that carry no information, an explicit empty alt="" so the screen reader skips them rather than reading a meaningless filename. This matters more in interactive blocks than static ones: a spin-to-win wheel or a scratch-off reveal that's entirely image-driven, with no text alternative describing the outcome, leaves a screen-reader user with no way to know what they won.
1.4.3 / 1.4.11 — Contrast for text and interactive controls
WCAG sets a 4.5:1 minimum contrast ratio for normal body text (3:1 for large text, per 1.4.3), and a 3:1 minimum for the visual boundaries of UI components and graphics (1.4.11). Both apply directly to interactive elements, not just paragraph copy — a poll option's border, a quiz answer button's background against its container, a countdown timer's digits against its backdrop. A low-contrast interactive control isn't just an aesthetic miss; it can make the control invisible to a low-vision recipient entirely.
2.1.1 Keyboard — the checkbox-hack technique's genuine advantage
A real <input type="radio">/<input type="checkbox"> paired with a <label for="..."> is natively focusable and operable with Tab plus Space or Enter, in any client that renders form controls at all — no extra markup, no extra work, because that's how browsers have always treated real form controls. See CSS :checked State Machines for how the technique itself works. This is a genuine advantage over what a JavaScript-driven web carousel typically does — a <div onclick> with no keyboard handler — and it's an advantage interactive email gets by construction, not by extra effort, as long as real <label>/<input> pairs are used rather than bare clickable <div>s.
2.5.8 Target Size (Minimum) — new in WCAG 2.2
Success Criterion 2.5.8, introduced in WCAG 2.2, sets a 24×24 CSS pixel floor for interactive targets, with exceptions for inline text, essential layout constraints, or an equivalent larger control available elsewhere. It's most relevant on mobile — where the majority of email opens happen — for the smallest interactive elements a studio makes easy to shrink too far: carousel dots, star-rating icons, quiz answer chips packed tightly together.
4.1.2 Name, Role, Value — labelling :checked controls correctly
A screen reader announces a control's name, role, and current state from real semantic markup — which is exactly what a <label> wrapping a real <input> provides for free, and exactly what's missing from a bare styled <div> standing in for a button. In practice this means every poll option, quiz answer, and accordion header needs real label text a screen reader can read aloud, not just a background image or an icon with no accompanying text.
Practical checklist
- Every image carries a real
alt, or an explicit emptyalt=""if it's decorative. - Interactive control text and borders meet 4.5:1 (text) / 3:1 (UI component) contrast.
- Every
:checkedinteraction uses a real<input>+<label for="...">pair — never a bare clickable<div>. - Interactive targets are at least 24×24 CSS pixels, especially on mobile-oriented blocks.
- Poll/quiz/accordion labels carry real, readable text — not an image or icon alone.