アクセシビリティは追加機能ではなくプロダクト品質

初級 | 9分 で読める | 2026.07.10

公式ドキュメント

アクセシビリティは、完成後に余裕があれば追加する機能ではありません。操作できること、情報を理解できること、失敗から戻れることを確認する品質の観点です。

まず5項目を確認する

観点確認方法
キーボードTab、Enter、Spaceだけで操作する
見出し見た目ではなく文書構造の順になっているか
ラベル入力欄の目的を支援技術でも読めるか
コントラスト文字と背景、状態表示を色だけに頼っていないか
状態通知エラー、完了、読み込み中が伝わるか

これらは、怪我で片手が使えない時、明るい屋外、遅い通信、慣れない端末などでも役立ちます。

HTMLを正しく選ぶ

クリックできる見た目を div で作るより、操作なら button、移動なら a を使います。標準要素には、キーボード操作や役割の情報が最初から備わっています。

<label for="email">メールアドレス</label>
<input id="email" name="email" type="email" autocomplete="email">

placeholderだけをラベル代わりにすると、入力後に項目名が見えなくなります。

自動検査だけでは終わらない

Lighthouseやaxeは、検出できる問題を見つける助けになります。しかし、説明が分かりやすいか、フォーカス順が自然か、エラーから直せるかは人が操作して確認します。

実践メモ: 新しい画面を作ったら、マウスを置いてTabキーだけで一周してください。フォーカスが消える場所や、順番が飛ぶ場所を早く見つけられます。

要件として書く

「送信できる」だけでなく、次のように確認可能な条件にします。

  • キーボードだけで送信できる
  • 入力エラーが項目の近くに表示される
  • エラー内容が色以外でも分かる
  • 送信中と完了が読み上げでも伝わる

アクセシビリティがレビューの最後ではなく、仕様の最初に入ります。

参考リソース

次に読む記事

← 一覧に戻る
PR
PR
PR
PR