アクセシビリティの検査ツールで高い点数が出た。これで「対応済み」と言ってよいのでしょうか。私たちは実際の制作で、数値が良くてもキーボードでは開けないメニューや、動きを止められない表示、読み上げると役割が伝わらないリンクに出会いました。
一方で、人が丁寧に確認したからといって、規格の全項目へ正式に適合したと証明できるわけでもありません。確認した配慮と、確認できていない適合性を混ぜると、よかれと思った説明が過大な表明になります。
そこで私たちは、アクセシビリティを公開直前の合否判定にせず、構成・デザイン・実装・検証へ分けます。自動検査で見つける問題、人が操作して初めて分かる問題、専門的な適合確認が必要な範囲を区別して扱います。
最初に、目標と表明の強さを分ける
「使いにくさを減らしたい」「指定された項目へ対応したい」「規格への適合を公表したい」では、必要な確認範囲が違います。最初に、対象ページ、対象機能、参照する基準、確認方法、結果の残し方を決めます。
- 日常的な制作品質として配慮する範囲
- 要件として確認する基準と達成レベル
- 対象に含めるページ、PDF、動画、フォーム
- 自社確認、第三者試験、利用者検証の役割
- 公開時にどこまで説明するか
目標が曖昧なままでは、制作側は無限に対応し、発注側は何を確認できたのか判断できません。対応項目だけでなく、表明できる範囲まで合意します。
最終検査へ集めず、工程ごとに確認する
完成後にまとめて直そうとすると、構造や色、動作の変更が全ページへ広がります。私たちは、問題が決まる工程へ確認を戻します。
- 構成：見出し階層、リンクの目的、読む順序、代替手段
- デザイン：コントラスト、色以外の手掛かり、フォーカス中や非活性の状態
- 実装：HTMLの意味、キーボード操作、フォーカス移動、動きの停止
- 入稿：画像の代替文、リンク文言、動画の説明、原稿の構造
- 検証：自動検査、目視、操作、読み上げ、対象範囲の記録
工程ごとに分けると、実装担当だけが最後に抱える問題ではなくなります。構成やデザインの判断として早い段階で直せるため、後戻りも減らせます。
自動検査で分かること、人が操作して分かること
自動検査は、機械的に判定できる欠落や形式の確認に有効です。ただし、文章が分かりやすいか、フォーカス順が自然か、開いたメニューから安全に戻れるかまでは判断できません。
自動検査を使いやすい項目
- 一部のコントラスト、ラベル、属性、構文の問題
- 繰り返し発生している実装上の欠落
- 修正前後で同じ条件を再確認すること
人が操作して確認する項目
- キーボードだけで目的の操作を完了できるか
- フォーカス位置と移動順を見失わないか
- 読み上げたときにリンクやボタンの役割が伝わるか
- 動きを停止しても情報へ到達できるか
- エラーの内容と直し方が理解できるか
どちらか一方ではなく、得意な判定を組み合わせます。点数は確認の入口であって、利用できることの証明書ではありません。
静止画にない状態もデザインする
完成した一枚の画面だけでは、操作時の品質を確認できません。フォーカス中、選択中、停止中、エラー、非活性、文字量が増えた状態もデザイン対象です。
色だけで違いを伝えず、形、文言、位置、アイコンなどを組み合わせます。ブランドの色や写真表現を捨てるのではなく、文字の読みやすさと役割を保てる組み合わせを探します。
確認できたことと、確認していないことを残す
制作では、利用できる端末、支援技術、ページ数、検証期間に限りがあります。すべてを確認したように見せず、対象範囲と結果を残します。
- 確認したページと共通部品
- 使用したブラウザ、端末、入力方法
- 自動検査と人による確認の区分
- 修正した項目と、判断を保留した項目
- 対象外としたファイルや外部サービス
正式な適合表明が必要な場合は、対象範囲、試験方法、結果の公開方法を含め、専門的な検証を別途計画します。日常的な配慮と正式な適合確認を区別することが、説明の信頼性を守ります。
公開前のチェックリスト
- 目標とする基準、対象ページ、確認方法を決めたか
- 構成・デザイン・実装・入稿へ確認項目を分けたか
- 色だけで状態や違いを伝えていないか
- キーボードだけで主要操作を完了できるか
- フォーカス位置と移動順を確認したか
- 動きを止めても情報へ到達できるか
- 自動検査の点数だけで完了としていないか
- 確認できた範囲と未確認範囲を記録したか
- 公開上の表現が検証結果を超えていないか
