要旨（「BOOK」データベースより）
「使えない」を「使える」にするデザインと技術。
目次
はじめに
■■■第1章 Webアクセシビリティとは
■■1.1 アクセシビリティとは
■言葉としての定義
■ユーザビリティとの対比
■アクセシビリティは利用しやすさ？
■■1.2 Webアクセシビリティとは
■Webにあるだけで圧倒的にアクセシブル
■Webコンテンツは形を変えられる
■■1.3 Webアクセシビリティと「障害」
■障害種別ごとの概要と利用状況
■加齢と障害
■一時的な障害
■医学モデルと社会モデル
■■1.4 WCAG──Webアクセシビリティの標準
■WCAGの概略
■3つの適合レベルとその内容
■アクセシビリティ サポーテッド
■■1.5 Webアクセシビリティに取り組む理由
■ユーザーを増やせる
■ユーザビリティを高められる
■権利を守り、法を遵守できる
■■1.6 なぜWebアプリケーションでアクセシビリティなのか
■繰り返し利用することで生活や仕事が変化するから
■共同利用のうえでは全員が使える必要があるから
■企業のミッションにつながるから
■■■第2章 Webアクセシビリティの基礎
■■2.1 基礎となるマシンリーダブルを理解する
■何も読み上げられないし、操作できないボタン──「名前」と「役割」
●読み上げられる実装──名前と役割
●読み上げられない実装
■選択したかわからないチェックボックス──「状態」
■HTMLのセマンティクスと、それを補完するWAI-ARIA
●HTMLはセマンティクスを持っている
●HTMLのセマンティクスを補完するWAI-ARIA
●WAI-ARIAよりもHTMLネイティブセマンティクスが優れている理由
■HTMLとWAI-ARIAとAOM（アクセシビリティオブジェクトモデル）
●Webコンテンツからアクセシビリティオブジェクトモデルを生成する
●アクセシビリティオブジェクトモデルを操作するWAI-ARIA
■■2.2 キーボード操作の基本
■よくある事例で課題を知る
●［事例1］キーボードで操作できない──インタラクティブ要素を用いていない
●［事例2］キーボードで操作できない──インタラクティブ要素を隠している
●［事例3］キーボードで操作できない──マウスでしか表示されないUI
●［事例4］キーボード操作の現在位置がわからない
■チェックポイント
■よくある事例を改善する
●［事例1の改善1］インタラクティブ要素を使用して、キーボード操作を可能にする
●［事例1の改善2］フォーカスを受け取り、キーイベントで実行できるようにする──インタラクティブ要素を使えない場合
●［事例2の改善］キーボード操作でフォーカス可能なまま、インタラクティブ要素を隠す
●［事例3の改善］マウスイベントとキーボードイベントを併用し、キーボード操作で表示させる
●［事例4の改善1］適切なフォーカスインジケーターを表示する
●［事例4の改善2］必要なときだけフォーカスインジケーターを表示する
■■2.3 非テキストコンテンツのマシンリーダビリティ
■よくある事例で課題を知る
●［事例1］代替テキストが付与されていない画像
●［事例2］アクセシブルな名前のないUI
●［事例3］装飾のための視覚表現がテキストデータを持っている
■チェックポイント
■よくある事例を改善する
●［事例1の改善1］画像に代替テキストを付与する
●［事例1の改善2］ユーザーが画像に代替テキストを設定できるようにする
●［事例1の改善3］グラフやチャートに対して代替となるコンテンツを提供する
●［事例2の改善］UIにアクセシブルな名前を付与する
●［事例3の改善］装飾のための視覚表現を無視する
■■2.4 コンテンツ構造のマシンリーダビリティ
■よくある事例で課題を知る
●［事例1］見出しが見出しとしてマークアップされていない
●［事例2］情報の関係性をマークアップしていない
●［事例3］情報のグループをマークアップしていない
●［事例4］視覚的な表現のために、間違ったセマンティクスを使用している
■チェックポイント
■よくある事例を改善する
●［事例1の改善］見出しを見出しとしてマークアップする
●［事例2の改善］マークアップで情報を関連付ける
●［事例3の改善］マークアップでグルーピングする
●［事例4の改善］視覚表現のために使用したセマンティクスを削除する
■■■第3章 フォームの改善
■■3.1 ラベルと説明
■よくある事例で課題を知る
●［事例1］プレースホルダーでラベルを表している
●［事例2］ラベルと説明の配置がわかりづらい
●［事例3］フォームコントロールにラベルと説明が関連付けられていない
●［事例4］グループにラベルと説明が関連付けられていない
●［事例5］入力必須の説明が伝わらない
■チェックポイント
■よくある事例を改善する
●［事例1の改善］ラベルや説明をプレースホルダーの外に配置する
●［事例2の改善］フォームコントロール・グループのラベルと説明をわかりやすく配置する
●［事例3の改善1］フォームコントロールにラベルと説明を関連付ける──label要素を使った場合
●［事例3の改善2］フォームコントロールにラベルと説明を関連付ける──WAI-ARIAを使った場合
●［事例3の改善3］フォームコントロールに不可視のラベルを付ける
●［事例4の改善1］グループにラベルと説明を関連付ける──field要素とlegend要素を使った場合
●［事例4の改善2］グループにラベルと説明を関連付ける──WAI-ARIAを使った場合
●［事例5の改善］入力必須をテキストで説明する
■■3.2 入力の支援
■よくある事例で課題を知る
●［事例1］必要以上に入力を求めている
●［事例2］1つの入力値を表すフォームコントロールが分割されている
●［事例3］ブラウザによる自動補完が使えない
●［事例4］入力値の種類に対して適切な入力タイプが選択されていない
●［事例5］選択肢のある入力値に対して適切なフォームコントロールが選択されていない
■チェックポイント
■よくある事例を改善する
●［事例1の改善］入力項目の数を必要最小限にする
●［事例2の改善］1つの入力値を表すフォームコントロールをまとめる
●［事例3の改善］自動補完できるようにマークアップする
●［事例4の改善1］入力値の種類に応じて入力タイプを指定する
●［事例4の改善2］ソフトウェアキーボードの種類を指定する──inputmode属性とpattern属性
●［事例4の改善3］インタフェースからの入力を制限する
──max属性・min属性・step属性・maxlength属性
●［事例5の改善1］選択式のフォームコントロールを検討する──ラジオボタン・チェックボックス
●［事例5の改善2］選択式のフォームコントロールを検討する──セレクトボックス・リストボックス
●［事例5の改善3］選択式のフォームコントロールを検討する──コンボボックス
■■3.3 制約の検証とエラー
■よくある事例で課題を知る
●［事例1］エラーの発生箇所とエラーメッセージの関係がわかりづらい
●［事例2］多様なユーザーへエラーを通知する方法を検討していない
●［事例3］エラーの修正方法がわかりにくい
●［事例4］必要以上に入力を制約している
●［事例5］ユーザー自身が操作を検証する手段がない
■チェックポイント
■よくある事例を改善する
●［事例1の改善1］HTML標準の制約検証を利用する
●［事例1の改善2］独自のエラーをわかりやすくデザインする
●［事例1の改善3］独自のエラーをマークアップする──フォームコントロールの場合
●［事例1の改善4］独自のエラーをマークアップする──グループの場合
●［事例2の改善1］エラーが発生したこととエラーの発生箇所をわかりやすく通知する
●［事例2の改善2］パターン1：送信時にフォームコントロールへフォーカスする
●［事例2の改善3］パターン2：送信時にエラーサマリーを表示する
●［事例2の改善4］パターン3：入力時にリアルタイムで検証する
●［事例3の改善1］エラーの修正方法を理解しやすくする
●［事例3の改善2］エラーの修正候補を提案する
●［事例4の改善］入力の制約を最小限にする
●［事例5の改善］ユーザー自身が操作を検証できるようにする
■■3.4 ユーザーが予測できる動作
■よくある事例で課題を知る
●［事例1］フォームコントロールの値を変更したときに画面遷移が発生する
●［事例2］ページの読み込み時やフォームコントロールへの値の入力時にフォーカスが移動する
■チェックポイント
■よくある事例を改善する
●［事例1の改善］ユーザーがコンテンツの大きな変化を予測できるようにする
●［事例2の改善］ユーザーがフォーカスの移動を予測できるようにする
■■3.5 カスタムコンポーネント
■よくある事例で課題を知る
●［事例1］カスタムコンポーネントの必要性を吟味していない
●［事例2］既存のカスタムコンポーネントサンプルを参考にしていない
●［事例3］キーボード操作が適切に設計されていない
●［事例4］WAI-ARIAの仕様に従ったロールが設定されていない
●［事例5］WAI-ARIAの仕様に従ったプロパティ・ステートが設定されていない
●［事例6］支援技術で検証していない
■チェックポイント
■よくある事例を改善する
●［事例1の改善］そもそもカスタムコンポーネントを利用すべきか検討する
●［事例2の改善］アクセシビリティが配慮されたカスタムコンポーネントサンプルを参照する
●［事例3の改善］適切なキーボード操作を設計する
●［事例4の改善］適切なWAI-ARIAロールを検討する
●［事例5の改善］適切なWAI-ARIAプロパティ・ステートを検討する
●［事例6の改善］支援技術で検証する
■■■第4章 UIデザインの改善
■■4.1 色とコントラスト
■よくある事例で課題を知る
●［事例1］色のみで情報を提供している
●［事例2］コントラスト比が低すぎる
■チェックポイント
■よくある課題を改善する
●［事例1の改善］色以外でも情報を提供する
●［事例2の改善1］文字のコントラスト比を改善する
●［事例2の改善2］文字以外のコントラスト比を改善する
●［事例2の改善3］できる限りコントラスト比を高める。文字を大きくする、太くする（コントラスト比が確保できない場合）
■■4.2 テキストのサイズ
■よくある事例で課題を知る
●［事例1］タッチデバイスでピンチアウトによる画面の拡大を禁止している
●［事例2］画面をズームすると、位置を固定した要素が画面を覆ってしまう
●［事例3］ブラウザの文字サイズ変更機能が反映されない
■チェックポイント
■よくある事例を改善する
●［事例1の改善］ピンチアウトによる画面の拡大を禁止しない
●［事例2の改善］位置を固定した要素はズームしたときの表示方法を検討する
●［事例3の改善］フォントサイズは相対単位で指定する
■■4.3 テキストのレイアウト
■よくある事例で課題を知る
●［事例1］行が長すぎる
●［事例2］行の間隔や段落の間隔が狭い
●［事例3］テキストが両端揃えされている
●［事例4］空白文字を使って文字の間隔を調整している
●［事例5］テキストブロックのサイズを固定している
●［事例6］文字画像でテキストのレイアウトを固定している
■チェックポイント
■よくある事例を改善する
●［事例1の改善］行を適切な長さに抑える
●［事例2の改善］行の間隔・段落の間隔を広くする
●［事例3の改善］両端揃えを使わない
●［事例4の改善］CSSを使って文字の間隔を調整する
●［事例5の改善］テキストブロックのサイズを可変にする
●［事例6の改善］文字画像は最低限の使用にとどめる
■■4.4 ライティング
■よくある事例で課題を知る
●［事例1］ページの言語が指定されていない
●［事例2］ページタイトルがページの主題を表していない
●［事例3］見出しがページの概要を表していない
●［事例4］リンクテキストがリンク先を表していない
●［事例5］感覚的特徴のみに依存している
●［事例6］画面に表示されているテキストのNameプロパティを上書きしている
■チェックポイント
■よくある事例を改善する
●［事例1の改善］lang属性に適切な言語を指定する
●［事例2の改善］主題を説明したページタイトルを付ける
●［事例3の改善］見出しのみを取り出してページの概要が理解できるようにする
●［事例4の改善］リンクテキスト単独でリンク先が理解できるようにする
●［事例5の改善］感覚的特徴に加えてコンテンツを特定するテキストを伝える
●［事例6の改善］表示されているテキストとNameプロパティを一致させる
■■4.5 画像の代替テキスト
■よくある事例で課題を知る
●［事例1］代替テキストが画像の内容を表していない
●［事例2］イラスト・写真・スクリーンショットの代替テキストが「イラスト」「写真」「スクリーンショット」になっている
●［事例3］装飾画像に代替テキストが設定されている
●［事例4］機能を持つ画像の代替テキストが見た目を表している
●［事例5］文字画像が表すテキストのうち一部のみが代替テキストに設定されている
●［事例6］グラフや図の代替テキストに「グラフ」「図」が設定されている
■チェックポイント
■よくある事例を改善する
●［事例1の改善］画像の内容を表す代替テキストを設定する
●［事例2の改善］情報を提供する画像の代替テキストでは重要な情報を短く伝える
●［事例3の改善］装飾画像の代替テキストを空にする
●［事例4の改善］機能を持つ画像の代替テキストには機能の説明を設定する
●［事例5の改善］文字画像の代替テキストには
内容紹介
アクセシビリティとは「利用可能な状況の幅広さ」のこと。より多くの人が、より多くの環境で、より多くの状態で利用できることです。もちろんそこには視覚・上肢・認知などに障害があるケースも含みます。日々繰り返し利用するWebアプリケーションにこそ、アクセシビリティが求められます。
Webサイトに比べて、多くのインタラクションを行うWebアプリケーションでは、アクセシビリティの確保はやや難易度が高いものです。特に既存のWebアプリケーションは複合的な課題を抱えていることが多く、教科書どおりの方法では必ずしも改善できません。
本書では、Webアクセシビリティの基礎である「HTMLとWAI-ARIA」を解説したうえで、Webアプリケーションの要である「フォーム」、色やテキストなど「UIデザインの基本」、モーダルダイアログや通知など「少し複雑なUIパターン」の3分野に分けて、よくある事例を取り上げながら、現実的で段階的な改善方法を紹介します。
さらには、デザインシステムの活用や組織での推進法など、アクセシビリティの取り組みを定着・推進・向上させるためのノウハウも詳説します。
著者紹介（「BOOK著者紹介情報」より）（本データはこの書籍が刊行された当時に掲載されていたものです）
伊原 力也(イハラ リキヤ)
２００４年に株式会社ビジネス・アーキテクツに入社し、情報アーキテクトとして活動。２０１７年にｆｒｅｅｅ株式会社に入社。多様な働き方の実現を目指し、デザインチームのマネジメントおよびアクセシビリティ普及啓発を行う。外部コンサルタントとしてｎｏｔｅ、Ｕｂｉｅ、ＳＴＵＤＩＯ、東京都新型コロナウイルス感染症対策サイトのアクセシビリティ改善をサポート。ウェブアクセシビリティ基盤委員会（ＷＡＩＣ）委員、人間中心設計推進機構（ＨＣＤ‐Ｎｅｔ）評議委員
小林 大輔(コバヤシ ダイスケ)
２０１２年、サイボウズ株式会社に新卒で入社。プログラマーとしてクラウドサービス「ｋｉｎｔｏｎｅ」の実装に携わる。２０１４年、ロービジョンの社員のユーザビリティテストを観察したことをきっかけにアクセシビリティの啓発・改善活動を開始。アクセシビリティエキスパートとして、アクセシブルなデザイン・実装の指導・社内ガイドラインの作成などに従事。２０２１年からはｋｉｎｔｏｎｅのデザインシステム構築に関わる。ウェブアクセシビリティ基盤委員会（ＷＡＩＣ）作業部会１主査
桝田 草一(マスダ ソウイチ)
２００７年、株式会社構造計画研究所に入社し、製造業向けの法人営業・マーケティングを担当。２０１４年にデジパ株式会社に入社し、フロントエンドエンジニアに転身。２０１７年に株式会社サイバーエージェクトに入社。配信プラットフォーム、公営競技投票サービスのウェブフロントエンド開発を経て、アメーバブログ、ＡＢＥＭＡのアクセシビリティ向上プロジェクトを推進。２０２１年に株式会社ＳｍａｒｔＨＲに入社。従業員サーベイ機能のプロダクトデザインを担当。また、アクセシビリティと多言語化を専門とするプログレッシブデザイングループを立ち上げてマネージャーに就任。全社のアクセシビリティ推進に従事している
山本 伶(ヤマモト レイ)
慶應義塾大学政策・メディア研究科修士課程修了後、モバイルゲームを手掛けるベンチャー企業を経て、２０１４年にｆｒｅｅｅ株式会社に入社。フロントエンド開発を中心にエンジニアとして会計・人事労務ソフトの機能開発に携わる。２０１９年にデザイナーに転身し、現在は社内で使われているデザインシステムの構築、社員研修をはじめとするアクセシビリティの普及啓発活動、アクセシビリティの高い製品がリリースされるためのプロセス整備などに取り組んでいる
著者について
伊原 力也 (イハラ リキヤ)
■伊原 力也（いはら りきや）
2004年に株式会社ビジネス・アーキテクツに入社し、情報アーキテクトとして活動。2017年にfreee株式会社に入社。多様な働き方の実現を目指し、デザインチームのマネジメントおよびアクセシビリティ普及啓発を行う。外部コンサルタントとしてnote、Ubie、STUDIO、東京都新型コロナウイルス感染症対策サイトのアクセシビリティ改善をサポート。ウェブアクセシビリティ基盤委員会（WAIC）委員、人間中心設計推進機構（HCD-Net）評議委員。著書（共著）に『デザイニングWebアクセシビリティ』、監訳書に『コーディングWebアクセシビリティ』『インクルーシブHTML＋CSS&JavaScript』（いずれもボーンデジタル刊）がある。
Twitter：@magi1125
小林 大輔 (コバヤシ ダイスケ)
■小林 大輔（こばやし だいすけ）
2012年、サイボウズ株式会社に新卒で入社。プログラマーとしてクラウドサービス「kintone」の実装に携わる。2014年、ロービジョンの社員のユーザビリティテストを観察したことをきっかけにアクセシビリティの啓発・改善活動を開始。アクセシビリティエキスパートとして、アクセシブルなデザイン・実装の指導・社内ガイドラインの作成などに従事。2021年からはkintoneのデザインシステム構築に関わる。ウェブアクセシビリティ基盤委員会（WAIC）作業部会1主査。
Twitter：@sukoyakarizumu
桝田 草一 (マスダ ソウイチ)
■桝田 草一（ますだ そういち）
2007年、株式会社構造計画研究所に入社し、製造業向けの法人営業・マーケティングを担当。2014年にデジパ株式会社に入社し、フロントエンドエンジニアに転身。2017年に株式会社サイバーエージェント入社。配信プラットフォーム、公営競技投票サービスのウェブフロントエンド開発を経て、アメーバブログ、ABEMAのアクセシビリティ向上プロジェクトを推進。2021年に株式会社SmartHRに入社。従業員サーベイ機能のプロダクトデザインを担当。また、アクセシビリティと多言語化を専門とするプログレッシブデザイングループを立ち上げてマネージャーに就任。全社のアクセシビリティ推進に従事している。
Twitter：@masuP9
山本 伶 (ヤマモト レイ)
■山本 伶（やまもと れい）
慶應義塾大学政策・メディア研究科修士課程修了後、モバイルゲームを手掛けるベンチャー企業を経て、2014年にfreee株式会社に入社。フロントエンド開発を中心にエンジニアとして会計・人事労務ソフトの機能開発に携わる。2019年にデザイナーに転身し、現在は社内で使われているデザインシステムの構築、社員研修をはじめとするアクセシビリティの普及啓発活動、アクセシビリティの高い製品がリリースされるためのプロセス整備などに取り組んでいる。
Twitter：@ymrl
