実践プロセス

サービスの全体像をわかりやすく提示する。カテゴリや機能をできるだけシンプルに絞り込む。利用者像や利用像、解決するべき課題、そしてこれらのスコープがどの程度明確に定まっているのかを検討する。

チェックポイント:

• ユーザー像、利用シーン、課題、スコープを明確にする
• 手元に十分な材料があるか確認する
• 関連して利用されるサービス・アプリがないか
• サービスがどのようなデータ、他システムとの連携を必要とするか
• 法令・規約上の制約事項がないか
• 初年度は企画検証、翌年度は本実装など、段階的な調達を検討する

サービス（システム）の開発スコープが定まったら調達。調達仕様書に記載すべきポイントを明確にする。

チェックポイント:

• システム要求事項として、明確にユーザビリティ・アクセシビリティに関連した機能要件・非機能要件を盛り込む
• 業務仕様に、利用者像・利用像の明確化計画、解決策の導出計画、各フェーズでのテスト計画・実施を盛り込む
• 人員計画に、適切な人材（デザイナー、ウェブアクセシビリティの専門家）をアサインし、実効性の高いチーム体制を構築するよう求める
• プロトタイピングツール、検証ツールを用意する必要がある場合、どのような機能要件を満たすツールを用いるべきか明示する
• 調達仕様書に適合レベルと対応度を記載する

利用者像や利用像、解決するべき課題、スコープを明確化した上で開発を進める。

サブステップ:

1. アイディエーション（解決案の提示）
2. ワイヤーフレームの作成
3. ワイヤーフレームを用いたユーザビリティとアクセシビリティの検証
4. 詳細デザインの作成、詳細仕様の検討（デザイン上のUIコンポーネントの作成、ガイドライン化）
5. 静的なUIプロトタイプの実装
6. プロトタイプを用いたアクセシビリティテスト
7. テストを受けての仕様改修
8. 本実装
9. 結合テストと並行したアクセシビリティの試験

実装時のチェックポイント:

• セマンティックなHTMLにすることが大切
• アイコンは実装方法に関わらず代替テキストを設定できるようにする
• モーダルダイアログ、アコーディオン開閉、ハンバーガーメニューはキーボードでも操作できるようにする
• 動的なUIを使うときは、フォーカス位置の調整も必ず行う
• 視覚的に隠している要素はスクリーンリーダーからも読み上げられないようにする

正式なウェブアクセシビリティの試験を実施する。一般的に1ヶ月程度の時間が必要になる。

チェックポイント:

• チェックツールによるチェックの実施
• 全体の構造が、逐次読み上げ・操作をスクリーンリーダーで行った際に理解しやすいものになっているか
• スクリーンリーダーで操作不能になる箇所の洗い出しと対応方針の確定
• パソコンで読み上げ確認をしてみる
• スマートフォンでの読み上げ確認

試験結果を集計し、対応度を判定する。すべてのページですべての達成基準に適合していれば「準拠」、どれか1つでも達成基準に適合していない場合は「一部準拠」となる。

原稿を確認し、ウェブアクセシビリティ上の課題がありそうなポイントを確認したら、必要な対応と工数を見積もる。

チェックポイント:

• 代替テキストの作成が必要になるイラスト、図表の洗い出し
• イラスト、図表が複雑すぎるものになっていないか
• PDF、スライド等の資料が適切なフォーマットになっているか
• 動画配信を予定している場合、字幕や手話通訳をつけることができるか
• SNSで発信する場合、画像にどのような代替テキストを付与するか

複雑な図表が含まれる場合は、なるべくシンプルな表現に作図し直し、本文で書き改める形で対応できないか原課と調整を行う。

ウェブアクセシビリティ対応を広報発信プロセスに組み込む。

配信内容のアクセシビリティ対応を計画する。

書き起こした文章（トランスクリプト）を字幕として提供する。手話通訳を手配する。

字幕の提供、音声認識技術を用いた字幕書き起こしの修正をリアルタイムで行う。