アクセシビリティ

概要

アクセシビリティ（accessibility、先頭のaと末尾のyの間に11文字あることから「a11y」と略されます）は、視覚・聴覚・運動・認知などの障害や、利用環境の違いによらず、誰もがWebのコンテンツと機能を使えるようにする設計の考え方と技術の総称です。画面を読み上げるスクリーンリーダー、キーボードだけでの操作、拡大表示、音声入力 — 人はさまざまな方法でWebにアクセスしており、アクセシビリティはその多様な入口すべてに対してページを開いておくことを意味します。

具体的な作業としては、HTML を意味に沿って正しく書くこと、キーボードだけで全操作を完結できるようにすること、十分な色コントラストを確保すること、画像に代替テキストを付けることなどが中心です。国際的な基準として W3C の WCAG（Web Content Accessibility Guidelines）があり、達成基準がA・AA・AAAの3段階で定義されています。多くの法制度や調達基準は「AA準拠」を実質的な合格ラインとしています。

なぜ生まれたか

Webの原点は、もともとアクセシブルでした。HTMLは文書の構造を記述する言語であり、構造さえ正しければ、読み上げソフトも点字ディスプレイも同じ文書を各自の方法で提示できたからです。Webの発明者ティム・バーナーズ＝リーは「Webの力はその普遍性にある。障害の有無にかかわらず誰もがアクセスできることが本質的な要素だ」と述べています。

ところがWebが視覚的にリッチになるにつれ、「画面が見えて、マウスでクリックできる」ことを暗黙の前提としたUIが増えていきました。見出しに見えるだけの装飾された div、クリックできるだけの span、色だけで伝えられるエラー表示 — 見た目は同じでも、そこには支援技術が読み取れる意味が残っていません。JavaScript で動的に組み立てられる SPA の時代にはこの傾向が加速し、画面が切り替わったことすらスクリーンリーダーに伝わらないアプリが量産されました。アクセシビリティは「新しく足す機能」ではなく、Webが本来持っていた普遍性を、リッチなUIの時代にも保ち続けるための体系として整備されてきたのです。1999年のWCAG 1.0以来、その中心には一貫して「見た目ではなく意味を記述する」という原則があります。

詳細

アクセシビリティツリー — 支援技術への橋

仕組みの中心にあるのがアクセシビリティツリーです。ブラウザは DOM と CSS からページを描画するのと並行して、各要素の「役割（ロール: これはボタンか、見出しか）」「名前（アクセシブルネーム: 何のボタンか）」「状態（押されているか、展開されているか）」を抽出した別の木構造を組み立てます。スクリーンリーダーなどの支援技術は、画面のピクセルではなく、OSのアクセシビリティAPIを通じてこの木を読み取ってユーザーに提示します。つまり、ブラウザのレンダリングが「目で見る人向けの出力」だとすれば、アクセシビリティツリーは「支援技術向けのもうひとつの出力」であり、ここに意味が載っていないUIは、どれだけ美しくても支援技術からは空白なのです。

セマンティックHTMLが最初の一歩、ARIAは最後の手段

このツリーに意味を載せる最も確実で安価な方法が、セマンティック（意味的）な HTML を使うことです。<button> と書けば、ロール「ボタン」、キーボードフォーカス、EnterとSpaceでの発火、無効化状態の伝達まで、ブラウザがすべて無償で提供します。同じ見た目を <div onclick> で作った場合、これらを全部自前で再実装しなければなりません。見出しは <h1>〜<h6>、ナビゲーションは <nav>、入力欄には <label> — 適材適所の要素選びこそがアクセシビリティの土台です。

素のHTMLで表現できないUI（タブ、ツリー表示、モーダルダイアログなど）のために用意されているのが WAI-ARIA です。role や aria-expanded などの属性でアクセシビリティツリー上の役割・状態を明示的に記述できます。ただしARIAは「支援技術にそう伝える」だけで、キーボード操作などの振る舞いは一切付いてきません。ARIA仕様の第一原則は「ネイティブのHTML要素で足りるならそれを使え」であり、「ARIAを使わないより、悪いARIAを使う方が有害」というのが実務の合言葉です。まず正しいHTML、どうしても足りないときだけARIA、が正しい順序です。

キーボード・コントラスト・実務の勘所

運動障害のあるユーザーや、スクリーンリーダーのユーザーの多くはマウスを使いません。すべての操作がTabキーでの移動とEnter/Spaceで完結すること、今どこにフォーカスがあるかが目視できること（outline: none でフォーカスリングを消すのは典型的なやらかしです）、モーダルを開いたらフォーカスをその中に移し、閉じたら元に戻すこと — キーボード対応はアクセシビリティの試金石で、これが通れば多くの支援技術も概ね動きます。視覚面では、WCAGが本文テキストに4.5:1以上のコントラスト比を求めており、色だけに頼らない情報伝達（エラーを赤色だけでなく文言でも示す）も基本です。検証には axe や Lighthouse などの自動チェックが役立ちますが、機械的に検出できるのは問題の一部で、最終的にはキーボードだけ・スクリーンリーダーだけで実際に操作してみる手動確認が欠かせません。

障害者「だけ」のためではない

アクセシビリティを特定のユーザー向けの追加対応と捉えると本質を見誤ります。腕を骨折している人（一時的制約）、赤ちゃんを抱いていて片手しか使えない人、炎天下で画面が見えにくい人、騒がしい場所で音声が聞けない人（状況的制約）— 誰もが人生のさまざまな場面で「障害がある状態」を経験します。字幕は聴覚障害者のための機能として生まれ、いまや電車内の動画視聴の標準になりました。適切な見出し構造は検索エンジンにも読みやすく、コントラストの改善は全員の可読性を上げます。アクセシビリティ対応は、そのまま全員のユーザビリティ向上なのです。

法制度の面でも対応は「任意の善意」から「義務」へ移りつつあります。米国ではADA（障害を持つアメリカ人法）に基づくWebサイトへの訴訟が年数千件規模で起きており、EUは欧州アクセシビリティ法（EAA）で2025年から民間サービスにも対応を義務づけました。日本でも2024年施行の改正障害者差別解消法により、民間事業者にも合理的配慮の提供が義務化されています。アクセシビリティは倫理であると同時に、いまや品質要件でありコンプライアンスでもある — その両面で押さえておくべき語彙です。