アクセシビリティと AI

この記事の目的

AI UI 自体のアクセシビリティ確保と、AI を支援技術として活用する両面を設計できるようになります。ストリーミング出力とスクリーンリーダーの相性・会話 UI の認知負荷・AI による a11y 向上とその精度限界・多様なリテラシーへの配慮・支援技術での検証を、設計判断として持ち帰れる状態を目指します。

対象読者

AI 機能を持つプロダクトを、多様な利用者が使えるように設計したいデザイナー・PM・エンジニア
AI を支援技術(代替テキスト生成・要約・読み上げ)として使う際の限界も踏まえたい実装者

前提知識

AI プロダクトの UX パターン — 待ち時間・不確実性の提示(a11y に直結)
チャットを超える UI — プロンプトを書けない利用者への配慮

本文

概要: 「AI の a11y」には 2 つの側面がある

アクセシビリティ(a11y)と AI の関係には、2 つの側面があります。1 つは「AI UI 自体が、多様な利用者に使えるか」。もう 1 つは「AI が、支援技術として a11y を高められるか」。この 2 つを分けて設計します。

前者では、ストリーミングや会話という AI 特有の UI が、スクリーンリーダーや認知特性と相性の悪い面を持つことに注意します。後者では、AI が代替テキスト生成や要約で助ける一方、その出力が間違いうることを前提にします。どちらも、AI の非決定性が a11y に固有の課題を生むという点で共通します。

AI UI のアクセシビリティ

WCAG 2.2 の非テキストコンテンツ(1.1.1)、キーボード(2.1.1)、ブロックスキップ(2.4.1)、ステータスメッセージ(4.1.3)などは AI の UI にも適用します。そのうえで、動的な更新や不確実な出力を扱う設計を加えます。

ストリーミングとスクリーンリーダー: 更新方法や支援技術の組み合わせによっては、逐次テキストが繰り返し読み上げられます。トークンごとに割り込むライブ通知を避け、進捗と完了の通知を本文から分ける案を検証します。フォーカスを勝手に移さず、完成した本文を利用者が読み進められるようにします。ストリーミングの体感速度(ストリーミングと Agent の UX 実装パターン)と、支援技術での読み上げやすさは両立させる設計が要ります(生成完了を適切に通知する等)
キーボードで完結できる: マウス前提にせず、入力・送信・提案の採否・中断を、すべてキーボードで操作できるようにします
低速・不安定な環境: 応答が遅い・途切れる環境でも、最低限使える代替を用意します。ストリーミングが前提だと、低速環境で体験が崩れます
エラー時の代替経路: AI が失敗したとき、行き止まりにせず、別の手段(問い合わせ・従来機能)へ導く経路を残します

会話 UI の認知負荷

会話 UI は、認知的な負荷が高くなりがちです。多様な認知特性に配慮します。

長文出力を避ける: AI は長く話しがちですが、長文は読む負荷が高く、要点が埋もれます。要点を先に・短く示し、詳細は求められたら出します
選択肢過多を避ける: 一度に多くの選択肢を出すと、選ぶ負荷が上がります。数を絞り、段階的に示します
一貫した構造: 応答の構造(要点 → 詳細 → 次の一手)を一貫させ、必要な箇所を見つけやすくすることを目指します。理解しやすさは対象利用者で確認します

AI は支援技術として a11y を高められます。ただし出力が間違いうることを常にセットで扱います。

代替テキスト・キャプション生成: 画像の代替テキスト、音声の字幕を AI で生成すると、初稿作成を補助できます。ただし生成物は誤りうるため、重要な箇所は人の確認を挟みます(能力と限界の視覚の崖)
要約・言い換え: 長文の要約、難しい表現の平易化は、読みやすさを改善する候補です。ただし要約は情報を落とし、言い換えは意味を変えうるため、原文へ辿れる導線を残します
読み上げ・音声入出力: 音声での操作は、視覚や運動の制約がある利用者を助けます
精度限界を明示する: AI 支援の結果を「確定情報」として提示せず、誤りうることを示します。a11y を助けるつもりが、誤った情報で妨げないようにします

多様なリテラシーへの配慮

「プロンプトを書ける」利用者だけを想定すると、多くの人を排除します。

プロンプトを書けない利用者: 文章で指示するのが難しい利用者のために、ボタン・テンプレート・選択肢で使える形を用意します(チャットを超える UI)。プロンプトレスな設計は、a11y の観点でも重要です
専門用語を避ける: AI の説明・エラーメッセージを、専門用語なしで理解できる言葉にします
多様な言語・文化: 母語・文化が異なる利用者にも通じる設計を心がけます

検証(支援技術での実機確認)

a11y は、机上のチェックリストだけでは確認できません。実際の支援技術で確かめます。

支援技術で実機確認する: スクリーンリーダー・キーボードのみ・音声操作などで、AI 機能が実際に使えるかを確認します。ストリーミングや会話 UI は、実機で初めて分かる問題が多くあります
多様な利用者のテスト: 可能なら、実際に支援技術を使う利用者にテストしてもらいます
継続的に検証する: AI の応答は変わりうるため、a11y も一度きりでなく継続的に確認します

実務での注意点

アンチパターン

ストリーミングを支援技術と両立させない → スクリーンリーダーで読み上げが崩れる → 生成完了の通知など、支援技術での読み上げやすさを設計する
マウス前提の UI にする → キーボード利用者が操作できない → 入力・送信・採否・中断をキーボードで完結させる
長文・選択肢過多を出す → 認知負荷が高く要点が埋もれる → 要点を先に短く、選択肢は絞って段階的に
AI 生成の代替テキスト・要約を確定情報として出す → 誤りが a11y を妨げる → 精度限界を明示し、重要箇所は人が確認し、原文へ辿れる導線を残す
プロンプトを書ける利用者だけを想定する → 書けない人を排除する → ボタン・テンプレート・選択肢で使える形を用意する
チェックリストだけで a11y を確認したつもりになる → 実機の問題を見逃す → 支援技術で実機確認する

チェックリスト

ストリーミング出力が、スクリーンリーダーで正しく読み上げられるか(完了通知等)
入力・送信・提案の採否・中断が、キーボードで完結できるか
長文・選択肢過多を避け、要点を先に・段階的に示しているか
AI 生成の代替テキスト・要約に精度限界を明示し、原文へ辿れるか
プロンプトを書けない利用者向けに、プロンプトレスな形を用意したか
エラー時に行き止まりにせず、代替経路を残したか
支援技術での実機確認を行っているか

参考資料

W3C, WCAG 2.2 — 1.1.1 非テキストコンテンツ、2.1.1 キーボード、2.4.1 ブロックスキップ、4.1.3 ステータスメッセージ(アクセス日: 2026-09-10)

TODO・未確認事項

なし