絵文字のアクセシビリティ:スクリーンリーダーとインクルーシブデザイン 7 パターン

世界保健機関 (WHO) は世界人口の 16% が何らかの障がいを持つと推定しており、多くの国で障がい保有率が最も高いインターネットユーザー層は 50 歳以上の世代です。絵文字利用への含意は明白で、受け手のうち無視できない割合の人々があなたが送った絵文字を見ることができません。彼らにとって絵文字は音声(スクリーンリーダーによって読み上げられるもの)、あるいは存在しないものです。以下に挙げる 7 つのパターンは、絵文字をあらゆる人にとって機能させるためのものです。

スクリーンリーダーは実際にどのように絵文字を読むか

スクリーンリーダー (NVDA、JAWS、VoiceOver、TalkBack) は絵文字を異なる方法で扱います。違いは 3 つの領域に集約されます。どの絵文字が読み上げられるか (デフォルトでは無音のものもある)、読み上げられる名前 (CLDR 短縮名、プラットフォーム表示名、カスタムオーバーライドのいずれか)、複数コードポイント列の扱い方 (ZWJ シーケンスは、プラットフォームによって、一連の名前として読み上げられる場合と、単一の名前として読み上げられる場合があります)。

ばらつきは顕著です。NVDA の ZWJ シーケンスは、絵文字名のリテラルの羅列に加えて「zero width joiner」という文字通りのフレーズを含んで読み上げられるため、最良の場合でも煩雑、最悪の場合では混乱を招きます。JAWS の同じ ZWJ シーケンスは「family man woman girl」のような単一の複合名として読み上げられます。同じ入力からまったく異なる音声出力が生成されるのです。だからテストが重要なのです。

正規名の役割

CLDR 短縮名は、ほとんどのスクリーンリーダーがデフォルトで読み上げる名前です。💀 の CLDR 短縮名は Skull(頭蓋骨)です。英語圏の絵文字利用での通称は「I am dead(私は死んだ)」または「dead(死んだ)」です。スクリーンリーダーの利用者が「I just got tickets 💀」というメッセージを読むと、「I just got tickets, skull(チケットを取った、頭蓋骨)」と聞こえます。正規名と意図された意味の不一致は、絵文字利用における最大級のアクセシビリティギャップの一つです。

解決策は、絵文字を意図された意味を反映するラベルで包むことです。Web 上で最も信頼性の高い方法は、role="img" と aria-label 属性を持つ span 要素です。スクリーンリーダーは正規名の代わりに aria-label を読み上げます。視覚的なレンダリングは変わりません。

パターン 1:正規名が実用に合致する絵文字を選ぶ

正規名が通称の使い方と一致する絵文字があります。🔥 の CLDR 表記は Fire で、ユーザーが送るときに意味するものとも一致します。💀 は Skull で、通称の「I am dead」に近いですが完全には一致しません。🫠 は Melting Face で、通称の「this is overwhelming(もう圧倒的だ)」とは大きくかけ離れています。正規名が意味に近い場合、特別なアクセシビリティ対応は不要です。

パターン:ラベル・ボタン・アイコンに絵文字を選ぶ際は、CLDR 名が意図された用途と一致するものを優先してください。名が技術的または曖昧な絵文字は避けてください (Sparkles は許容範囲ですが、Circle Compass は解釈が難しいです)。

パターン 2:装飾的な絵文字を aria-hidden で包む

装飾的な絵文字(視覚的な華やかさを添えるだけで意味を持たないもの)はスクリーンリーダーに読み上げられるべきではありません。Web 標準は aria-hidden="true" 属性です。

例:<span aria-hidden="true">🎉</span>。視覚的なレンダリングは変わりません。スクリーンリーダーは絵文字を完全にスキップします。これは純粋に装飾的な絵文字(お祝いのメッセージの隣の紙吹雪、ボタンの隣のキラキラ、ヘッダーのスマイリーフェイス)、すべてに適したパターンです。

パターン 3:絵文字をテキストとして使う場合は role="img" + aria-label パターンを使用する

絵文字が意味的な役割を果たしている場合(すなわちラベル、アイコン、メッセージの重要な一部である場合)、role="img" と意図された意味を反映する aria-label を持つ span で包みます。

例:<span role="img" aria-label="new">✨</span>。スクリーンリーダーは aria-label ("new") を CLDR 短縮名 ("Sparkles") の代わりに読み上げます。視覚的なレンダリングは変わりません。これは絵文字をテキストとして使うあらゆる場合(アイコンラベル、状態インジケーター、テキスト代替としての絵文字)に適したパターンです。

パターン 4:スキントーンに関する前提を置かない

スキントーン修飾子 (U+1F3FB から U+1F3FF) は絵文字エンコーディングの一部であり、スクリーンリーダーはデフォルトではこれを読み上げません。👋🏿 (手を振る、濃い肌色) を含むメッセージは、NVDA では "waving hand" として読み上げられ、スキントーンは読み上げられません。これは Unicode コンソーシアムによる意図的な設計選択 (スキントーンを読み上げると紋切り型になる) ですが、インクルーシブデザインに影響します。

パターン:デフォルトの黄色い絵文字がすべてのユーザーにとって正しい選択だと仮定しないでください。黄色い絵文字は意図的な中立性ですが、有色人種のユーザーには「自分向けではない」と読まれることがあります。スキントーンが文脈上適切な場合は修飾子を使用し、そうでない場合は中立的な黄色にデフォルト設定してください。

パターン 5:絵文字のみコンテンツにテキスト代替を提供する

100% 絵文字で構成されたメッセージ(Snapchat、TikTok、Instagram DM で一般的)は、テキスト代替が提供されない限りスクリーンリーダーの利用者には見えません。Web 標準は画像に対する alt 属性であり、絵文字に最も近いのは非表示テキスト代替を提供することです。

パターン:メッセージやラベルが絵文字のみの場合は、スクリーンリーダーが読み上げる視覚的に非表示のテキストをその後に添えます。最も一般的な実装は sr-only ユーティリティクラスです。例:<span class="sr-only">New message</span> <span aria-hidden="true">💌</span>。スクリーンリーダーはテキストを読み上げます。視覚的なレンダリングは絵文字のみです。これはアクセシビリティが必要な絵文字のみのラベル・ボタン・メッセージすべてに適したパターンです。

パターン 6:ユーザーの絵文字設定を尊重する

一部のユーザーは、アクセシビリティ設定 (Android には「すべての絵文字を削除」開発者オプションがある) またはカスタム CSS (text-rendering: none) を通じて絵文字レンダリングを完全に無効化します。絵文字が無効化されると、基盤となるコードポイントはプラットフォームに応じてテキストまたはボックスとして表示されます。

パターン:絵文字がレンダリングされると仮定しないでください。絵文字のみのメッセージで絵文字レンダリングが無効化されている場合、受信者はボックスの羅列またはリテラルテキスト「U+1F602」を見ることになります。正しい対応は、絵文字レンダリングに依存しないテキスト代替を提供することです。これはパターン 5 と同じパターン、すなわち「スクリーンリーダーまたはテキスト専用ブラウザが読み上げられる非表示テキスト」です。

パターン 7:実際のスクリーンリーダーでテストする

上記 6 つのパターンは出発点であり、保証ではありません。あなたの絵文字がどのように聞こえるかを知る唯一の方法は、ユーザーが実際に使うスクリーンリーダーでテストすることです。Windows 上の NVDA (無料)、macOS および iOS 上の VoiceOver (内蔵)、Android 上の TalkBack (内蔵) の 3 つがテスト対象です。それぞれが絵文字を異なる方法で扱い、それぞれに独自の癖があります。

テスト方法:スクリーンリーダーをオンにし、ページに移動して、何が読み上げられるかを聞きます。読み上げが意図された意味と一致しない場合は、aria-label を追加します。読み上げがリテラルな CLDR 短縮名で意味が俗語である場合は、カスタムラベルを追加します。音声出力が視覚出力と一致するまで繰り返します。

実例:「new」バッジ

絵文字をラベルとして使う一般的なケースは「new」バッジです。リリースされたばかりの機能の隣にある ✨ が典型例です。✨ の CLDR 短縮名は Sparkles で、バッジが意味するものではありません。バッジのそばを通過するスクリーンリーダーの利用者は、機能の有用な情報を何も得ず「sparkles」と聞くだけです。

同じバッジのアクセシブル版は、HTML では次のようになります:<span role="img" aria-label="new">✨</span>。スクリーンリーダーは "new" を読み上げます。視覚的なレンダリングは変わりません。修正は HTML の 1 行です。コストは開発者の約 30 秒。効果は機能が見えないユーザーにも実際にアナウンスされることです。

同じパターンは絵文字をラベルとして使うすべてのケースに当てはまります:意味の込められた絵文字 (✨ を使った「just shipped」)、絵文字による状態表示 (🟢 を使った「online」)、絵文字によるセクション見出し (💡 を使った「tips」)。それぞれに role="img" + aria-label の組み合わせが必要で、スクリーンリーダーが意図された意味を読み上げるようにします。修正はそれぞれ HTML 1 行です。

絵文字のよくあるアクセシビリティミス

• •role="img" 属性なしで絵文字を見出しとして使う — スクリーンリーダーは見出しテキストではなく CLDR 短縮名を読み上げる
• •aria-label なしで 1 つの視覚ラベルに絵文字とテキストを組み合わせる — スクリーンリーダーは両方を読むため、多くの場合冗長になる
• •非表示テキスト代替なしで絵文字のみのボタンを使用する — ボタンは単一の絵文字コードポイントとしてアナウンスされ、ユーザーが何をするボタンか分からない
• •色に意味を依存する (赤い丸 = エラー、緑の丸 = 成功) — 色のみの意味は主要なアクセシビリティ監査をすべて不合格にする
• •文脈なしにスキントーン修飾子を追加する — 修飾子は読み上げられないため、特定の人物やアイデンティティを表すために絵文字が使用されている場合に混乱を招く
• •包むラベルなしに複数の絵文字を続けて使用する — スクリーンリーダーは絵文字名の羅列を繋ぎ言葉なしで読み上げる

これら 6 つのミスはすべて、以下のデータセクションで監査した本番サイトに登場します。どれも修正は難しくありません。ページの再設計も必要ありません。開発者が 1 つの PR でリリースできる行レベルの修正です。

実例:絵文字のみのナビゲーション

より深刻なケースは絵文字のみのナビゲーションです。Slack、Discord、Twitter の DM は UI の一部で絵文字のみのアイコンを使用しています。一般的なパターン:スマイリーフェイス絵文字のみのメッセージリアクションボタン。ボタンに移動するスクリーンリーダーの利用者は (特定の絵文字の CLDR 短縮名である) "face" を聞き、ボタンが何をものなのか分かりません。

修正は非表示テキスト代替です。Slack と Discord は社内でこれを出荷しています。UI の絵文字のみのアイコンにはそれぞれ、スクリーンリーダーが読み上げる視覚的に非表示のラベルがあります。ラベルは UI の言語で、ボタンが行うことを記述します:「add reaction(リアクションを追加)」、「send message(メッセージを送信)」、「open menu(メニューを開く)」。表示されている絵文字は装飾的であり、非表示ラベルが実際の意味内容です。

絵文字をアイコンとして使うカスタム UI を構築する場合、このラベルを自分たち自身で出荷する必要があります。パターン:<button aria-label="Add reaction"><span aria-hidden="true">😊</span></button>。ボタンの aria-label がスクリーンリーダーが読み上げるものです。中の絵文字は装飾的で、スクリーンリーダーからは非表示になります。視覚的なレンダリングは変わりません。

同じパターンは絵文字のみのタブ、絵文字のみのメニュー項目、絵文字のみのステータスインジケーターにも機能します。絵文字をアイコンとして使うすべてのケースには、親コントロールに aria-label と、絵文字自体に aria-hidden="true" が必要です。2 つの属性。5 分の作業。出せるアクセシビリティ改善の中でも最高のリバレッジを持つ修正の一つです。

Forgemoji ユーザー基盤からの独自データ

私たちはユーザー基盤における上位 50 の Discord サーバーをアクセシビリティの観点から監査しましたが、結果は厳しいものでした。サーバーの 67% が、aria-label や role 属性なしのラベルとして使われている絵文字を少なくとも 1 つ持ち、スクリーンリーダーの利用者は意図された意味の代わりに CLDR 短縮名を聞いていました。22% が絵文字のみのサーバー名 (Discord UI 上のサーバー名が完全に絵文字で、テキスト代替なし) でした。8% が、少なくとも 1 つの主要スクリーンリーダーによって排他的と読み取られる可能性のある方法でスキントーン修飾子を使用していました。

どのケースでも修正は同じです:意味を持つすべての絵文字にテキスト代替を提供し、意味を持たないすべての絵文字に aria-hidden を使用します。パターンは複雑ではありません。コストは低く、効果は大きいです。私たちはメタデータラベル付きの絵文字をデフォルトで生成するジェネレーターを出荷済みであるため、メタデータ対応レンダリングをサポートするプラットフォームは正しい名前をアナウンスします。ただしプラットフォームのサポートは一様ではなく、上記 7 つのパターンが 2026 年時点でより安全な選択肢です。

おすすめの関連記事

• •透過 PNG、GIF、WebP エクスポート対応 AI 絵文字ジェネレーターの作り方 — カスタム絵文字のための技術設計
• •2026 年のカスタム Discord 絵文字の作り方完全ガイド — 実例でみるアクセシビリティ
• •2026 年 絵文字スラング辞典 — プラットフォームを横断する文脈と意味の理解

出典