リソース

インタラクティブメールをアクセシブルにする: WCAG 2.2チェックリスト

WCAGはWebコンテンツ向けに書かれたものですが、HTMLメールは今もユーザーエージェントによってレンダリングされるHTMLです——ウェブメールクライアントはブラウザですし、ネイティブのメールアプリのレンダリングエンジンも本質的には変わりません。アクセシブルなWebフォームを規定するのと同じ達成基準が、隠しチェックボックスとラベルから構築された投票、クイズ、アコーディオンにも同じように直接当てはまります。

公開日 2026年8月23日 · MailInAppチーム

HTMLメールは今もユーザーエージェントによってレンダリングされるHTMLです——ウェブメールクライアントはブラウザですし、ネイティブのメールアプリのレンダリングエンジンも本質的には変わりません。 WCAGの達成基準はメール特有の例外を設けておらず、同等のWebコンポーネントに適用されるのとまったく同じように、CSSのみの投票、クイズ、アコーディオンにも直接当てはまります。本記事は、チェックボックスハックによって駆動されるインタラクティブメールにとって最も重要な4つの基準について、実践的なチェックリストをまとめたものです。

そもそもなぜWCAGがここに当てはまるのか

WCAG 2.2は、特に「Webページ」ではなく、「ユーザーエージェント」によってレンダリングされる「コンテンツ」という観点で書かれています——メールという媒体は仕様の中でまったく名指しされていないため、正式なメール専用の標準ではありませんが、その根底にあるコンテンツはいずれにせよHTMLです。だからこそ、アクセシビリティコミュニティは、メールをガイドラインの及ばない別カテゴリとして扱うのではなく、このチェックリストと同じように、WCAGの達成基準をメールコンテンツに対する実践的な基準として扱っています。

1.1.1 非テキストコンテンツ——すべての画像に本物のaltを

商品写真、ヒーロー画像、装飾的な区切り線、アイコンのみのボタン——これらはすべて、スクリーンリーダーが読み上げられるalt属性を必要とします。あるいは、情報を一切持たない純粋に装飾的な画像であれば、意味のないファイル名を読み上げさせるのではなくスクリーンリーダーがスキップできるよう、明示的な空のalt=""が必要です。これは、静的なブロックよりもインタラクティブなブロックにおいてより重要になります: 結果を説明するテキストの代替がまったくない、完全に画像だけで構成されたスピン抽選ホイールやスクラッチカードは、スクリーンリーダーを使うユーザーに、自分が何を獲得したのかを知る手段を一切残しません。

1.4.3 / 1.4.11 — テキストとインタラクティブなコントロールのコントラスト

WCAGは、通常の本文テキストに対して4.5:1の最小コントラスト比(1.4.3、大きなテキストの場合は3:1)、UIコンポーネントおよびグラフィックの視覚的境界に対して3:1の最小値(1.4.11)を定めています。どちらも、段落のコピーだけでなく、インタラクティブな要素——投票の選択肢の境界線、コンテナに対するクイズの答えボタンの背景、背景に対するカウントダウンタイマーの数字——にも直接適用されます。低コントラストのインタラクティブなコントロールは、単なる見た目の失敗にとどまらず、弱視の受信者にとってそのコントロール自体が完全に見えなくなってしまう可能性があります。

2.1.1 キーボード — チェックボックスハック技術の本物の優位性

実際の<input type="radio">/<input type="checkbox"><label for="...">の組み合わせは、フォームコントロールを少しでもレンダリングするクライアントであれば、追加のマークアップも追加の作業も一切必要とせず、Tabキーとスペースキーまたは Enterキーでネイティブにフォーカス・操作可能です。これは、ブラウザが実際のフォームコントロールを常にそのように扱ってきたからです。この技術自体の仕組みについてはCSS :checked ステートマシンを参照してください。これは、JavaScriptで駆動される一般的なWebカルーセル——キーボードハンドラを持たない<div onclick>——に対する本物の優位性であり、裸のクリック可能な<div>ではなく実際の<label>/<input>のペアが使われている限り、インタラクティブメールが追加の努力なしに、構造上自然に得られる優位性です。

2.5.8 ターゲットサイズ(最小) — WCAG 2.2で新設

WCAG 2.2で導入された達成基準2.5.8は、インラインテキスト、不可欠なレイアウト上の制約、または同等の大きなコントロールが他の場所で利用可能な場合を例外として、インタラクティブなターゲットに対して24×24 CSSピクセルという下限を定めています。これは、メール開封の大多数が発生するモバイルにおいて、スタジオで縮小しすぎてしまいがちな最も小さなインタラクティブ要素——カルーセルのドット、星評価のアイコン、隙間なく詰め込まれたクイズの答えのチップ——に対して、最も関連性が高くなります。

4.1.2 名前、役割、値 — :checkedコントロールを正しくラベル付けする

スクリーンリーダーは、実際のセマンティックなマークアップから、コントロールの名前、役割、現在の状態を読み上げます——これはまさに、実際の<input>を包む<label>が無償で提供するものであり、ボタンの代わりを務めるスタイルだけの裸の<div>にはまさに欠けているものです。実際には、すべての投票の選択肢、クイズの答え、アコーディオンのヘッダーが、背景画像やテキストを伴わないアイコンだけではなく、スクリーンリーダーが読み上げられる本物のラベルテキストを必要とすることを意味します。

実践的なチェックリスト

  • すべての画像に本物のaltを付与する。装飾的な画像の場合は明示的に空のalt=""を付与する。
  • インタラクティブなコントロールのテキストと境界線が、4.5:1(テキスト)/3:1(UIコンポーネント)のコントラストを満たしている。
  • すべての:checkedインタラクションが、実際の<input>+<label for="...">のペアを使用している——裸のクリック可能な<div>は決して使わない。
  • インタラクティブなターゲットが、特にモバイル向けのブロックにおいて、少なくとも24×24 CSSピクセルある。
  • 投票/クイズ/アコーディオンのラベルが、画像やアイコンだけでなく、本物の読み上げ可能なテキストを持っている。

出典

よくある質問

WCAGはウェブサイトだけでなく、メールにも適用されますか?

WCAGの達成基準は、「ユーザーエージェント」によってレンダリングされる「コンテンツ」という観点で書かれており、メール特有の例外を設けていません——そして、HTMLメールはHTMLであり、ブラウザ(ウェブメール)または同等のレンダリングエンジン(ネイティブクライアント)によってレンダリングされます。これはメール専用の正式な標準ではありませんが、アクセシビリティコミュニティは、同じ達成基準をメールコンテンツに対する実践的で正当な基準として適用しています。

キーボードのみを使うユーザーは、CSSの :checked カルーセルやアコーディオンを操作できますか?

正しく構築されていれば、可能です——実際の<input type="radio"/"checkbox">と<label for=...>の組み合わせは、フォームコントロールを少しでもレンダリングするクライアントであれば、追加の作業を一切必要とせず、Tabキーとスペースキーまたは Enterキーでネイティブにフォーカス・操作可能です。これは、そのようなネイティブなキーボード操作経路を持たず、メールがJavaScriptを取り除く以上そもそも使いようもない、div とクリックハンドラによるアプローチに対する、チェックボックスハック技術の本物の優位性です。

WCAG 2.2における最小タッチターゲットサイズはどれくらいですか?

WCAG 2.2で新設された達成基準2.5.8(ターゲットサイズ(最小))は、例外(インラインテキスト、不可欠なレイアウト上の制約、または同等の大きなコントロールが他の場所で利用可能な場合)が当てはまらない限り、インタラクティブなターゲットに対して24×24 CSSピクセルという下限を定めています。これは、開封の大多数を占めるモバイルクライアントにおいて、投票の選択肢、カルーセルのドット、クイズの答えといった最も小さくなりがちなインタラクティブ要素に対して、最も重要になります。

インタラクティブメールのコピーには、どれくらいの色コントラストが必要ですか?

WCAGの1.4.3は、通常の本文テキストに対して4.5:1の最小コントラスト比(大きなテキストの場合は3:1)を定めており、1.4.11はUIコンポーネントおよびグラフィックの視覚的境界に対して3:1の最小値を定めています——どちらも、段落のコピーだけでなく、投票/クイズの選択肢ボタンとそのラベルにも直接適用されます。

本当に重要な受信トレイに向けて構築

無料プランから始められます。すべてのインタラクティブブロックと完全なフォールバックエンジンが、どのプランにも含まれています。