PR：この記事にはアフィリエイトリンクが含まれます。
Webアクセシビリティは、あとから特別な機能を追加するだけの話ではありません。情報を探し、内容を理解し、操作を終えられる状態をHTMLやフロントエンド実装で整えることです。
スクリーンリーダーやキーボードを使う人に加え、画面サイズや環境が違っても扱いやすい設計は日々の操作を支えます。HTML、ARIA、キーボード対応をまとめて考えるところから始めましょう。
| 書籍 | 主な内容 | 形態・価格の目安 |
|---|---|---|
 Webアクセシビリティの教科書 | 戦略から実装、組織への浸透まで。WCAG 2.2対応 | 紙・352ページ・3,960円（税込） |
 Webアプリケーションアクセシビリティ | HTML、ARIA、キーボード、フォームやUIの検証 | 紙・576ページ・3,960円（税込） |
 コーディングWebアクセシビリティ | コード例で学ぶWAI-ARIAとUIの実装 | PDF・EPUB。電子版価格は販売ページで確認 |
 インクルーシブHTML+CSS & JavaScript | 多様な利用環境に向けたフロントエンドのパターン | 紙・264ページ・3,080円（税込） |
 フロントエンドの知識地図 | HTML・CSS・JavaScriptとアクセシビリティの基礎 | 紙・344ページ・2,860円（税込） |
紙書籍の欄は定価を目安にしています。実売価格は時期や販売店で変わるため、購入時の表示を確かめてください。
HTMLで意味を伝える
見た目がボタン風の div はクリックできても、ボタンの意味やキーボード操作まで備わるわけではありません。button 要素なら役割や基本の操作が標準で伝わります。意味に合うHTMLを先に選び、装飾は後から加えましょう。
見出しは文字の大きさだけで選ばず、ページの構造に沿って順序立てます。リンク名から移動先が分かるようにしましょう。ナビゲーションやメイン領域にランドマークを置けば、スクリーンリーダーでページ内をたどりやすくなります。
入力欄は画面上のラベルとプログラム上の名前を持たせ、label と結び付けます。同じ見た目のアイコンボタンにも用途が分かる名前が必要です。名前が伝わらないと読み上げ時に操作を判断できません。
『フロントエンドの知識地図』は、開発にこれから携わる人や経験1〜2年の人が全体像をつかむのに使えます。アクセシビリティではWCAGやJIS X 8341-3に加えて、スクリーンリーダーやモーダル、ARIAも扱います。Chromeの開発者ツールやLighthouseから単体テスト、E2Eテストまで触れ、検証の入口も押さえられます。
ARIAで状態を伝える
ARIAは要素の役割や状態を支援技術に伝える仕組みです。見た目や動作を追加する機能ではありません。ネイティブHTMLで表せるときは標準要素を使い、HTMLで足りない情報をARIAで補います。
開閉式の領域では、ボタンが開いているか閉じているかを伝え、操作のたびに状態を更新します。表示が開いているのに読み上げでは閉じたままだと、次に何をすればよいか分かりません。画面と支援技術の情報を同期させます。
検索結果や保存完了のように、操作後に内容が更新される場面では、その変化を適切に伝えます。フォーカスを毎回移す必要はありません。必要な通知を読み上げの流れに沿わせれば、作業を続けやすくなります。
『コーディングWebアクセシビリティ』では、ボタン要素やランドマークのほか、タブとメニューの状態も扱い、ライブリージョンやダイアログのコード例も学べます。紙版の発売は2015年3月で、現在購入できる版はPDFとEPUBです。WAI-ARIAをコード例から学ぶフロントエンド制作者には、この本をおすすめします。
キーボード操作を整える
キーボードだけで画面を使う人は、Tabキーでフォーカスを順に移します。移動順が画面の流れと違うと、どこにいるか分からなくなりがちです。フォーカスが突然飛ぶ、操作部品を飛び越えるといった問題をなくし、独自のTab順は最小限にします。
フォーカスの位置は枠線や色で見えるようにします。装飾の調整で印まで消えると、操作中の場所が分からなくなります。通常の表示と見比べ、背景に対するコントラストも確認してください。
タブ型UIや独自メニューでは、Tabキーで移る場所と矢印キーなどで項目を移る操作を設計します。独自の操作を加えるときは、フォーカスの移動先と選択状態を一貫させましょう。見た目とキー操作の両方が揃っているかも確かめます。
モーダルを開いたら、フォーカスを中へ移し、背後の画面にTab移動が戻らないようにします。閉じたあとは、開くきっかけになったボタンへフォーカスを戻すのが基本です。Escapeキーで閉じられるかも含め、一度の流れで開閉を試します。
フォームを迷わせない
入力欄の説明をプレースホルダーだけに頼ると、入力を始めたとき文言が消えてしまいます。label と入力欄を結び付け、必須条件や形式も入力前に分かる位置へ置きましょう。
エラーは色だけで伝えず、問題の内容と直し方を言葉で示します。エラー文と入力欄をプログラム上でも関連付ければ、読み上げ時に該当箇所を把握しやすくなります。送信後にエラーが出たら、フォーカスの位置も確認してください。
『Webアプリケーションアクセシビリティ』はフォームやモーダル、通知などWebアプリで使われるUIを広く扱います。チェックポイントや改善事例に加え、支援技術での検証方法も載っています。A5判の576ページで、実務中に確認する本として活用できます。
アクセシビリティ検証
自動チェックでは、コントラスト不足や名前の欠落を見つけられます。一方で、読み上げ時の名前が用途に合うか、操作順が自然かは自分で試す必要があります。Lighthouseの結果を手がかりに、手動確認も行いましょう。
次はマウスを使わず、TabやEnter、Spaceと矢印キーで主要画面を操作します。フォーカスが見えるか、必要な操作へ届くか、自然な順で進めるかを確かめます。途中で移動が止まる箇所や順序の乱れは、画面を見るだけでは見落としがちです。
続いてスクリーンリーダーで見出しやランドマークをたどり、フォーム名やボタンの役割と動的な通知を確かめます。表示倍率を上げても内容が欠けず、操作が重ならないかも確認しましょう。異なる利用環境で起きる課題に気付きやすくなります。
テストを最後に一度だけ行うより、部品を作り始めた段階から繰り返すと修正箇所を早く見つけられます。設計から実装、レビューまで同じ観点を共有すれば、個人の経験に頼らず改善を続けられます。チェック項目はチームの画面に合わせて見直しましょう。
結論
案件や組織の計画段階からアクセシビリティを扱うなら、『Webアクセシビリティの教科書』を読むのがおすすめです。フォームやダイアログの改善を進めるWebアプリ担当者には、『Webアプリケーションアクセシビリティ』が具体的な参考書になります。
ARIAのコード例を学ぶフロントエンド制作者には『コーディングWebアクセシビリティ』を、多様なユーザーニーズを意識した実装を学ぶ人には『インクルーシブHTML+CSS & JavaScript』をおすすめします。フロントエンド全体を学び直したい人には、『フロントエンドの知識地図』が適しています。
読んだ内容は画面の実装で確かめます。HTMLの意味とARIAの状態、キーボード操作を続けて検証し、マウスなしでも画面を使えるか確認してください。必要に応じてスクリーンリーダーでも操作する習慣が、日々使えるWebアクセシビリティにつながります。
Amazon の PC をスコア化してみた
Amazonにある8〜14インチの小型WindowsタブレットやノートPCを、スペック別にスコア化して比較・ランキング。
