はじめに
引き続き、デジタル庁が提供している「ウェブアクセシビリティ導入ガイドブック」でアクセシビリティの基礎の学習をしています。
４章の「ウェブアクセシビリティの実践プロセス」の要約（メモ）となります。
4.1 情報システムにおけるサービス開発
ウェブアクセシビリティを企画の段階から想定に入れる必要がある。
- 基準を決めること
- 時代の流れに合わせて新しい基準に対応する
基本的なプロセス
- Problem Fit: 課題の発見
- Solution Fit: 解決策の決定
- Market Fit: 経済合理的か、運用できるか、社会への適合性があるか
反復的に繰り返し、プロジェクトを成長させる。
- 企画：アクセシビリティの要件検討
- 調達：アクセシビリティ要件の具体化
- 設計・実装：複数回のアクセシビリティ試験
- リリース
企画
視覚障害、聴覚障害、学習障害、知的障害 => 受け取る情報に差が生じる
- サービスの全体像をわかりやすく提示
- カテゴリーや機能をシンプルに絞る
- サービスを使う理由、メリットを明示
- 具体的な行動の成果が予測可能
- 手順、必要なコスト（時間、場所の移動、費用等）を明快に
- 失敗やエラーを明示
利用者像を明確に
- 誰が
- いつ
- どのような目的で
- どのような頻度で
- どのように
- どの場所やシーンで用いるのか
企画をする際は、組織的な事象にも配慮すること
- 関連して利用されるサービス、アプリがないか
- サービスがどのようなデータ、他システムとの連携を必要とするか
- 法令、規約上の制約事項がないか
企画段階で大まかな方針とマイルストーンを決める必要がある。また、緊急性が求められるプロジェクトこそ、企画段階で検証を行う必要がある。まさにシフトレフト。
調達
- システムの要求事項として、ユーザービリティ、アクセシビリティに関連した機能要件と非機能要件を明確にする
- 業務仕様に、利用者像と利用像の明確化計画、解決策の導出計画、各フェーズでのテスト計画と実施を明記
- 人員計画に、専門家など適切な人材をアサインし、実効性の高いチーム体制を構築するよう求める
- プロトタイピングツール、検証ツールを用意する必要がある場合、どのような機能要件を満たすツールを用いるべきかを明示
設計・実装
- アイディエーション
- ワイヤーフレームの作成
- ワイヤーフレームを用いたユーザビリティとアクセシビリティの検証
- 詳細デザインの作成、詳細仕様の検討
- デザイン上のUIコンポーネントの作成、ガイドライン化
- 静的なUIプロトタイプの実装
- プロトタイプを用いたアクセシビリティテスト
- テストを受けての仕様改修
- 本実装
- 結合テストと並行したアクセシビリティの試験
テスト
初期段階のテストとして
- 全体の構成の明快さなど、インタラクションデザイン、情報設計上の配慮が十分できているか
- 情報の配置が、HTML等で実装していく上で適切にマークアップできるデザインとなっているか
- コントラスト比、文字サイズ等、ワイヤーフレームやUIプロトタイプの段階で検討できることが達成されているか
- モーダルダイアログ、ポップアップメニュー、カルーセル、ハンバーガーメニュー等の実装上配慮が必要な要素を洗い出せているか
静的なプロトタイプを用意できる場合、以下の検証も行う
- チェックツールによるチェックの実施
- 全体の構造が、読み上げた際に理解しやすいものになっているか
- スクリーンリーダーで操作不能になる箇所の洗い出しと、対応方針の確定
調達仕様書への記載
アクセシビリティを一定水準に保つために、調達時にアクセシビリティの基準、試験方法、結果の記載方法を定めて示す。
- 適合レベルと対応度
- 表記「JIS X 8341-3:2016のレベルAAに準拠すること」
- 納品物の規定
- ウェブアクセシビリティ方針
- 「対象範囲」と「適合レベル」
- 実装チェックリスト
- ウェブアクセシビリティ検証結果
- ウェブアクセシビリティ方針
- 納品物を作成するために必要な知識とスキル
- JIS X 8341-3:2016の理解
- WCAG2.0の解説書と達成方法の理解
- HTML、CSS、JavaScriptの仕様の理解
- スクリーンリーダー、拡大機能などの支援技術の理解と操作
- Webページやサイトの実装経験
- JavaScriptライブラリとフレームワークの理解
実装時の配慮とテスト
- セマンティックなHTMLにすることが大切
- アイコンは代替テキストを設定
- スクリプトでコンテンツを切り替える場合、スクリーンリーダにも切り替わったことが伝わるようにする
- モーダルダイアログ、アコーディオン開閉、ハンバーガーメニューは、キーボードでも操作できるようにする。その上で、スクリーンリーダーにUIの動作と状態が伝わるようにする
- 動的なUIを使うときは、フォーカス位置の調整も必ず行う
- 視覚的に隠している要素は、スクリーンリーダーからも読み上げられないようにする
- チェックツールでチェックする
- コンポーネント単位 => ページ単位
- パソコンで読み上げ確認をしてみる
- 以下は手動で確認する必要がある
- モーダルダイアログの開閉
- コンテンツの入れ替え
- 代替テキストの設定など
- PC-Tolker, NVDA
- 以下は手動で確認する必要がある
4.2 広報活動でのウェブを使った情報発信
基本的なプロセス
- 原稿、発進手段ののチェック
- 必要な対応と工数を見積もる
- 代替テキストの作成が必要になるイラスト、図表の洗い出し
- イラスト、図表が複雑になっていないか
- 動画の字幕や手話通訳をつけることができるか
- SNS画像にどのような代替テキストを付与するか
- 原稿の修正、図表等の最適化、代替テキストの付与
- 複雑な図表はシンプルに
- PDFがスキャンされて画像化された場合、元のデジタル画像を入手
- 見出し、段落等を適切にマークアップ
- スライド資料のテキスト読み上げ順序の調整
- PDF、スライド資料にも図表や画像の代替テキストを付与
- 動画配信、ライブ配信等を行う場合
- 書き起こした文章を字幕として提供
- 手話通訳を手配
広報、プレスリリースなどで情報を発信するときの原則
- 画像に代替テキスト
- 音声にキャプション、動画にキャプションと音声解説
- 赤字、太字、下線、拡大のみによる一部強調は使わない
- 見出しだけで、セクションやブロックに含まれる情報を表現する
- 文字と背景のコントラスト比
- リンクを適切に表現
- 音声、映像に代替コンテンツ
- イラストの修正
- 簡略化、分割
- PDFの構造化
- HTMLと同様にアクセシビリティを高くする
4.3 スマートフォンのアクセシビリティ
スマートフォンの支援技術
- iOS – VoiceOver
- Android – TalkBack
スマートフォンとパソコンのデバイスの違い
- 画面分割や情報量も調整したほうが良い
- タップできる大きさに調整する
- 持ち運ぶ => 文字やUIの視認性の確保
スマートフォンでよく使われるUIの実装方法
- WAI-ARIA
- ページ表示時のフルスクリーン再生や、カルーセルが適切かどうかを見極める
スマートフォンのさまざまな入力方法
- シミュレーターだけではなく、実機を使ってテストを行うことを推奨
スマートフォンアプリのアクセシビリティ
- 確認と検収を行うときは、実機とスクリーンリーダーなどで細かく確認することを推奨
さいごに
ガイドブックを学習したことにより、全体像を把握することができました。
アクセシビリティを導入する上で、より具体的で技術的なところは、適宜調べて学んでいく必要がありそうです。
体系的にかつコンパクトにまとまっていて、わかりやすいガイドラインでした！
