WCAG 1.1.1: 非テキストコンテンツ

このルールの意味

WCAG 達成基準 1.1.1 非テキストコンテンツは、「知覚可能」という原則の下にあるレベル A の要件です。これは、ユーザーに提示されるすべての非テキストコンテンツには、その目的と同等の役割を果たすテキストによる代替がなければならないと定めています。「非テキストコンテンツ」は広く定義されており、ラスター画像（JPEG、PNG、GIF、WebP）、ベクターグラフィックス（SVG）、画像ベースのボタンやフォーム入力、イメージマップ、canvas 要素、音声クリップ、動画、アニメーション、CAPTCHA、装飾的な飾りなどを含みます。

テキストによる代替は要素の種類によって複数の形を取り得ます。たとえば <img> 要素の alt 属性、SVG やロールを持つ要素に対する aria-label や aria-labelledby、<object> 内の title 要素、figure に関連付けられた <figcaption> などです。重要なのは、代替テキストが視覚的コンテンツそのものと同じ情報や機能を伝えることです。単なるファイル名や汎用的なプレースホルダーであってはなりません。

この達成基準では、適切なテキスト代替がどのようなものかを決定する、いくつかの具体的なケースを定義しています。

• コントロールと入力: 非テキストコンテンツがコントロールである、またはユーザー入力を受け付ける場合（画像ボタンやリンクとして使われる画像など）、テキスト代替は見た目ではなく、その目的や機能を説明しなければなりません。
• 時間依存メディア: 単独のプレゼンテーションとして用いられる音声のみまたは動画のみのコンテンツには、最低限、その内容を識別する説明的なラベルが必要です。完全なトランスクリプトやキャプションについては後続の達成基準（1.2.x）で扱われます。
• テストと感覚的体験: コンテンツがテストや演習であり、テキストで提示すると目的が損なわれる場合（視覚的なパズルなど）、テキスト代替は非テキストコンテンツを特定し、説明するだけで構いません。
• CAPTCHA: テキスト代替は CAPTCHA の目的を説明し、別の感覚モダリティを用いた代替形式の CAPTCHA を提供しなければなりません。
• 装飾、レイアウト、不可視コンテンツ: 画像が純粋に装飾目的である、スペース調整に使われている、またはユーザーに提示されない場合、支援技術が無視できるように実装すべきです。典型的には空の alt="" 属性や role="presentation" を用います。

合格となるのは、意味のあるすべての非テキスト要素が、その目的を同等に伝えるプログラム的なテキスト代替を持つか、あるいは明示的に装飾としてマークされ、支援技術がそれをスキップできる場合です。不合格となるのは、画像に alt 属性がまったくない場合、alt の値がファイル名である場合（例: alt="img_header_logo_v2.png"）、意味のあるコンテンツとして使われている SVG に <title> 要素もアクセシブルネームもない場合、あるいは装飾画像に誤って説明的な alt テキストが付与され、スクリーンリーダーユーザーにとってノイズになっている場合です。

なぜ重要か

世界保健機関によると、世界で約 22 億人が何らかの視覚障害または失明を抱えています。スクリーンリーダーユーザーは、合成音声や点字ディスプレイに依存してデジタルコンテンツを利用しており、画像、アイコン、チャート、グラフィカルなコントロールを理解するために完全にテキスト代替に頼っています。正確な alt テキストがなければ、EC サイトの商品ページは視覚的な文脈のない価格の羅列に過ぎなくなり、ロゴが並ぶ銀行のナビゲーションはラベルのないボタンの列となり、病院の症状チェッカーの図は自己トリアージを試みるユーザーにとって見えないものになります。

具体的なシナリオを考えてみましょう。ある視覚障害のあるユーザーがジャケットを購入するためにトルコの EC プラットフォームを訪れます。商品カルーセルには、ジャケットのさまざまな角度や色のバリエーションを示す 6 枚の画像があります。これらの画像に意味のある alt テキストが一つもなければ、ユーザーのスクリーンリーダーは「画像、画像、画像」と 6 回繰り返すだけです。どのバリエーションがネイビーブルーでどれが黒なのか、どの画像が背面ポケットを示しているのかを判断できず、購入を断念するかもしれません。同じ商品リンクを持つ晴眼の同僚は 2 分もかからずに購入を完了します。このギャップはアクセシビリティの失敗であると同時にビジネス上の損失でもあります。

失明にとどまらず、この達成基準は、読み上げツールに依存して読書を補っている認知障害のあるユーザー、キーボードや音声で操作し、インタラクティブなコントロールに明確なラベルを必要とする運動障害のあるユーザー、画像が読み込まれない可能性のある低帯域幅環境のユーザーにも恩恵をもたらします。そのような場合、alt テキストは機能的なフォールバックとして機能します。さらに、適切に作成された alt テキストは、検索エンジンのクローラーが画像の alt 属性を関連するテキストシグナルとして扱うため、検索エンジンのインデックス作成を改善し、SEO の成果を直接的に支援します。

関連する Axe-core のルール

axe-core アクセシビリティエンジンは、7 つの個別の自動ルールを通じて WCAG 1.1.1 を強制します。それぞれのルールが何をチェックし、どこに限界があるのかを理解することは、完全なテスト戦略にとって不可欠です。

• image-alt: すべての <img> 要素に alt 属性（装飾画像の場合は空でも可）または aria-label、aria-labelledby、title によるアクセシブルネームがあるかをチェックします。alt 属性がまったくない画像を検出します。ブラウザはその場合、ファイルパスをアクセシブルネームとして公開してしまいます。
• input-image-alt: <input type="image"> 要素に空でない alt 属性があるかをチェックします。画像入力は送信ボタンとして機能し、その見た目ではなく機能を伝えなければなりません。画像入力の alt がない、または空であると、スクリーンリーダーではそのボタンが事実上利用不能になります。
• area-alt: イメージマップ内のすべての <area> 要素に、alt、aria-label、または aria-labelledby による空でないテキスト代替があるかをチェックします。イメージマップは、いまだ一部のエンタープライズアプリケーションや公共部門のポータルで使われているレガシーパターンであり、各ホットスポットはリンク先や機能を個別に説明しなければなりません。
• object-alt: <object> 要素にアクセシブルネームがあるかをチェックします。<object> 要素は歴史的に Flash コンテンツ、PDF、その他のメディアを埋め込むために使われてきましたが、ラベルがなければスクリーンリーダーは埋め込まれたコンテンツを識別できません。
• svg-img-alt: role="img" を持つインラインの <svg> 要素にアクセシブルネームがあるかをチェックします。通常は子要素の <title>（対応する aria-labelledby とともに）や SVG ルートの aria-label 属性によって提供されます。モダンな UI ではアイコンやイラストに SVG が広く使われており、このルールは意味を持つのにラベルがない SVG を検出します。
• role-img-alt: role="img" を持つ任意の要素にアクセシブルネームがあるかをチェックします。これは、画像コンテナとして使われる <div> や <span> など、SVG 以外の要素にも適用できます。このパターンは、ネイティブの画像要素を使わないカスタムアイコンシステムや CSS の background-image 実装で一般的です。
• image-redundant-alt: 画像の alt テキストが隣接する可視テキストを重複している状況を検出します。典型的には、アンカー内に画像とテキストラベルが並んでいる場合です。これは厳密な失敗ではありませんが、冗長な alt テキストによりスクリーンリーダーが同じ情報を 2 回読み上げ、聴取体験を損ないます。このルールを適切に解決するには人間の判断が必要です。重複が本当に冗長なのか、意図的に付加的なものなのかを判断できるのは人だけだからです。

axe-core を含む自動ツールは、alt テキストの質を評価できず、その存在と基本構造しか評価できない点に注意が必要です。alt="photo" や alt="decorative border" のような画像であっても、ルール上は合格となる場合がありますが、どちらも意味のある内容ではありません。そのため、alt テキストが各画像の内容と目的を正確に説明しているかを確認するには、自動スキャンと並行して必ず手動レビューが必要です。

テスト方法

1. axe DevTools または Lighthouse による自動スキャン: axe DevTools ブラウザ拡張機能（Chrome と Firefox で利用可能）をインストールします。テスト対象のページを開き、拡張機能を有効にしてページ全体の解析を実行します。結果を、前述のルール ID（image-alt、input-image-alt、area-alt、object-alt、svg-img-alt、role-img-alt、image-redundant-alt）でフィルタリングします。各検出要素について、ツールは DOM 内の該当ノードをハイライトし、違反内容を説明します。Lighthouse（Chrome DevTools の Accessibility 監査に組み込み）も、要素レベルの詳細とともに image-alt の違反を表示します。すべての違反について、要素セレクタと周辺コンテキストを記録し、開発者への引き継ぎに備えます。
2. 手動での DOM 検査: ブラウザの DevTools の Elements パネルを開き、すべての <img>、<input type="image">、<area>、<object>、<svg> タグを検索します。それぞれについて、適切な alt 属性または ARIA ラベルが存在し、その値がコンテキスト上意味のあるものかを確認します。React や Vue などの JavaScript フレームワークを通じて動的に読み込まれる画像には特に注意してください。これらは静的な HTML スナップショットには現れない場合があります。
3. NVDA と Firefox を用いたスクリーンリーダーテスト: NVDA（無料、Windows）を起動し、Firefox でページを開きます。G キーを使ってグラフィック間を移動します。NVDA は各画像のアクセシブルネームを読み上げます。ファイルパス、「image」、無音の読み上げなどがないか注意して聞きます。これらはいずれも失敗を示します。画像ボタンやリンクについては、Tab キーで各コントロールに移動し、読み上げられるラベルがそのコントロールの実行するアクションを伝えているかを確認します。
4. VoiceOver と Safari（macOS/iOS）を用いたスクリーンリーダーテスト: VoiceOver を有効にします（macOS では Command+F5）。VO+右矢印 で要素ごとにコンテンツを移動するか、アイテムチューザー（VO+U）を開いてローターから Images を選択し、すべての画像とそのラベルの一覧を一度に確認します。iOS では、ページ上を右スワイプし、各画像がどのように読み上げられるかを確認します。
5. JAWS と Chrome を用いたスクリーンリーダーテスト: JAWS では、G キーを押してグラフィック単位で移動します。各画像は明確で意味のある説明を持つべきです。JAWS の仮想ビューア（Insert+F1）を使って、問題のある要素の計算済みアクセシブルネームとロールを確認します。
6. 装飾画像の扱いを検証: 装飾的だと判断した画像について、alt="" が設定されており、それを再び露出させるような title 属性や ARIA ラベルが付いていないことを確認します。スクリーンリーダーでこれらの要素に移動し、読み上げ順で完全にスキップされていることを確認します。

修正方法

情報提供用画像で alt が欠落している — 不正

<!-- Image conveys product information but has no alt attribute -->
<img src='jacket-navy-front.jpg'>

情報提供用画像で alt が欠落している — 正

<!-- alt text describes the visual content and its purpose in context -->
<img src='jacket-navy-front.jpg' alt='Navy blue wool jacket, front view, with double-breasted buttons'>

装飾画像に誤ったラベルが付いている — 不正

<!-- Decorative divider image exposes a descriptive alt that adds noise -->
<img src='divider-ornament.png' alt='Decorative ornamental divider with scrollwork pattern'>

装飾画像が支援技術から正しく隠されている — 正

<!-- Empty alt tells screen readers to skip this image entirely -->
<img src='divider-ornament.png' alt=''>

アクセシブルネームのない SVG アイコン — 不正

<!-- SVG used as a meaningful icon has role="img" but no label -->
<svg role='img' xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'>
  <path d='M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2z'/>
</svg>

アクセシブルネームのある SVG アイコン — 正

<!-- title element provides the accessible name; aria-labelledby associates it -->
<svg role='img' aria-labelledby='icon-account-title' xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'>
  <title id='icon-account-title'>My Account</title>
  <path d='M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2z'/>
</svg>

alt が欠落している画像入力ボタン — 不正

<!-- Image submit button has no alt; screen reader announces only "image" -->
<input type='image' src='btn-search.png'>

説明的な alt を持つ画像入力ボタン — 正

<!-- alt describes the button's function, not its appearance -->
<input type='image' src='btn-search.png' alt='Search'>

よくある間違い

• ファイル名を alt テキストとして使う: alt="hero_banner_v3_final.jpg" のように書くと、スクリーンリーダーに意味のないファイルパスを読み上げさせることになります。常に、画像が何を示しているのか、またはどのような目的を果たしているのかを説明する alt テキストを書いてください。
• alt テキストを "image" や "photo" にする: alt="image" や alt="photo" のような汎用的な値は空ではないため自動チェックには合格しますが、何の情報も伝えません。スクリーンリーダーはすでに要素のロールを「画像」として読み上げるため、その語を繰り返すのはユーザーの時間を無駄にします。
• 動的に挿入される画像の alt を付け忘れる: JavaScript（例: React で構築された商品カルーセル）を通じて DOM に挿入される画像は、初期 HTML には alt 属性がない場合があります。JavaScript コンポーネントが src をレンダリングするのと同時に alt 属性もレンダリングするようにしてください。
• 意味のある画像に role="presentation" を適用する: コンテンツを持つ画像に role="presentation" や role="none" を使うと、それらはアクセシビリティツリーから完全に除外されます。これは純粋に装飾的な画像にのみ適切です。情報提供用の画像に使うと、スクリーンリーダーユーザーにとってコンテンツが完全に失われます。
• role="img" を使った CSS 背景画像で alt 属性を完全に省略する: <div> に背景画像を設定し、role="img" を付与した場合、開発者が aria-label を追加し忘れることがあります。ラベルがなければ、その要素はアクセシビリティツリー上で名前のない画像として扱われ、alt が欠落しているのと同じくらい問題です。
• 意味ではなく見た目を説明する alt テキストを書く: チャートに対して alt="A blue bar chart" と書くと、視覚的なスタイルは説明できますが、データは説明できません。alt テキストは、alt="Bar chart showing Q3 revenue grew 18% year-over-year" のように、主要なインサイトを伝えるべきです。
• セット内の複数画像に重複した alt テキストを付ける: 商品一覧に同じアイテムのサムネイル画像が 6 枚表示されている場合、すべてに alt="Running shoe" のような同じ alt テキストを付けると、それらを区別できません。セット内の各画像は、その固有の内容や角度を説明すべきです。
• イメージマップ内の <area> 要素に alt を付け忘れる: イメージマップを使う開発者は、親の <img> に alt テキストを追加しても、各 <area> ホットスポットにも、そのリンク先を説明する独自の alt 属性が必要であることを忘れがちです。
• ツールチップテキストを alt テキストの代わりに使う: title 属性は視覚的なツールチップを生成し、一部のスクリーンリーダーはこれを読み上げますが、ブラウザのサポートは一貫しておらず、すべてのアクセシビリティコンテキストで公開されるわけではありません。これは適切な alt 属性を補完するものであり、代替するものではありません。
• スプライトシートや <use> 要素で提供される SVG アイコンをテストしない: <use href="#icon-id"> を通じて参照される SVG スプライトは、シャドウ DOM の境界のため、内部の <title> をすべてのスクリーンリーダーに公開しない場合があります。スプライトベースのアイコンは必ず実際のスクリーンリーダーでテストし、必要に応じて外側の <svg> 要素に aria-label を追加して補完してください。

トルコのアクセシビリティ規制との関係

2025 年 6 月 21 日付官報第 32933 号で公布されたトルコ大統領通達 2025/10 は、トルコで事業を行う幅広い公的・民間主体に対して、デジタルアクセシビリティ要件を義務付けています。この通達は技術標準として WCAG 2.2 を参照しており、レベル A のすべての達成基準（WCAG 1.1.1 非テキストコンテンツを含む）が、ベストプラクティスではなく法的に強制力のある義務となっています。

対象となる主体には、すべての公的機関・政府機関、銀行や金融機関、病院や医療提供者、20 万人以上の加入者を持つ通信会社、EC プラットフォーム、旅行代理店、民間の交通事業者、国民教育省（MoNE）に認可された私立学校が含まれます。公的機関は、通達の発効日から 1 年以内に遵守を達成しなければなりません。民間セクターには 2 年間の実施期間が与えられています。

トルコのデジタル環境では、多くの高トラフィック分野がこの通達の対象となっており、EC マーケットプレイス、バンキングポータル、行政サービスプラットフォームなど、画像への依存度が高いことから、WCAG 1.1.1 は特に重要です。EC サイトの商品写真、政府ポータルのインフォグラフィック形式の公的なお知らせ、銀行アプリケーションのチャート中心の金融ダッシュボード、病院の患者ポータルにおけるフォームベースのインターフェースなどは、すべてこの達成基準の適用範囲に明確に含まれます。

通達におけるレベル A 要件に違反すると、対象主体は規制当局の監視や制裁の可能性にさらされます。WCAG 1.1.1 は、最も頻繁に違反され、かつ最も容易にテストできる達成基準の一つであり、自動ツールと基本的なスクリーンリーダーのウォークスルーの両方で検出可能なため、コンプライアンス監査で大きく取り上げられる可能性が高いです。通達の対象となる組織は、すべての image-alt 違反の修正を、先送りすべき改善ではなく、即時かつ最優先のアクションアイテムとして扱うべきです。Accsible のようなアクセシビリティオーバーレイ SDK を導入することで、リアルタイムに不足しているテキスト代替を検出し、部分的に修正することはできますが、ソースコードレベルでの完全な修正こそが、コンプライアンスに向けた最も堅牢で持続的な道筋です。