はじめに
機能としてはちゃんと動いているのに、絶妙に操作しにくい。
そのような経験ありませんか？
キーボード操作・色のコントラスト・スクリーンリーダー
——いずれも機能テストの緑色では保証されない別軸の品質です。
「使える」品質を、標準準拠と人間中心の2軸で見ていきます。
TL;DR
- 「使える」品質は機能テストとは別軸で検証する必要がある
- 検証には2つの軸がある：標準準拠の軸（WCAG等） と 人間中心の軸（観察と評価）
- どちらも自動化で全部はカバーできない。シフトレフトでデザイン段階から織り込むのが現実的
1. 機能は通った。でも「使えない」と言われた
社内向けのタスク管理画面を作ったとします。タスクの登録・更新・削除、ステータス変更、フィルタ。CRUD一通りの機能テストはすべて緑です。
$ pytest tests/test_task_management.py
============================= test session starts =============================
collected 24 items
tests/test_task_management.py::test_create_task PASSED [ 4%]
tests/test_task_management.py::test_update_status PASSED [ 8%]
tests/test_task_management.py::test_delete_task PASSED [ 12%]
tests/test_task_management.py::test_filter_by_due_date PASSED [ 16%]
...
============================= 24 passed in 1.82s ==============================
ところがリリース後、運用部門から次のような声が届きます。
- マウスのドラッグ前提で並べ替えるUIになっており、キーボードしか使えない利用者がタスクを並べ替えられない
- ステータスを「緑＝完了、赤＝期限切れ」のように色だけで表現していて、色の判別が難しい利用者には情報が伝わらない
- タスクが30件並ぶと目的のものに辿り着けない。機能としては全件表示できているのに、人間の認知の限界を超えている
これらは「バグ」ではありません。たとえば完了ボタンを次のように書いたとします。
<div onclick="completeTask(123)" style="color: green;">完了</div>
クリックすれば機能テストは緑です。けれど <div> だとTabキーでフォーカスが当たらず、キーボードのみの利用者は操作の入り口に立てません。
この「機能は正しいが使えない」領域を、次の2つの観点で扱います。
- アクセシビリティ：障害の有無や状況に関わらず、誰もがWebやアプリを利用できる状態
- ユーザビリティ：使いやすさ・分かりやすさ・心地よさを指す品質特性
2. 「使える」を2軸で整理する
「使えない」の原因は1種類ではありません。標準と照合できるものと、人間が観察しないと掴めないものに大別できます。
| 軸 | 何を測るか | どう測るか | 主な技法 |
|---|---|---|---|
| 標準準拠の軸（アクセシビリティ） | 客観的な基準への適合 | 基準と照合する | 自動チェックツール＋手動確認 |
| 人間中心の軸（ユーザビリティ） | 主観的な使い心地・詰まり方 | 人間が観察する | ユーザー観察セッション |
2軸は対立ではなく補完関係にあります。
アクセシビリティはユーザビリティの一部とも言えますが、検証アプローチが大きく異なるため、別々の軸として扱うほうが整理しやすくなります。
冒頭で挙げた3つの「使えない」を当てはめると、
(a) キーボード操作で詰まる、
(b) 色だけで状態を表現は標準準拠の軸で捉えられます。
(c) 30件並ぶと辿り着けないは人間中心の軸で観察するほうが筋がよさそうだと見当が付きます。
3. 標準準拠の軸：WCAGと自動チェック、そしてその限界
標準準拠の軸は、「やるべきことが明文化されている」という意味で最も強力な手がかりです。
基準と照合すれば抜け漏れを機械的に潰せます。
ただし、「自動チェックさえ通せばOK」と思って進めると、半分近くを取りこぼします。
このフロー全体のうち、自動チェックで完結する領域と、人間が見ないと判断できない領域があります。順に見ていきます。
3-1. WCAGの4原則（POUR）
標準準拠の軸の中心にあるのが WCAG（Web Content Accessibility Guidelines） です。
Webコンテンツが満たすべき要件をW3Cがまとめた国際標準で、4つの原則の頭文字をとって POUR と呼ばれます。
| 原則 | 何を保証するか | タスク管理画面でのNG例 |
|---|---|---|
| 知覚可能（Perceivable） | 情報がユーザーの感覚で受け取れる | 「期限切れ」を赤色だけで表現する |
| 操作可能（Operable） | 全機能が代替手段で操作できる | 完了ボタンが <div> でTabフォーカスが当たらない |
| 理解可能（Understandable） | 表示と操作が予測可能で平易 | エラーメッセージが「Error: code 42」だけ |
| 堅牢（Robust） | 支援技術が正しく解釈できる | role属性・ARIA属性が欠落している |
支援技術の代表が スクリーンリーダー（画面要素を音声で読み上げる仕組み）です。堅牢の原則は、要素の役割や状態をこれらに正しく伝えるためのものです。
設計時は、利用者像をペルソナ（特定のユーザー像を代表する仮想的なキャラクター）として置くと具体的になります。
キーボード操作のみの利用者、色の判別が難しい利用者、スクリーンリーダー利用者などが代表例です。
WCAGの適合レベルとバージョン
WCAGには A / AA / AAA の3つの適合レベルがあります（A=最低限、AA=多くの法令で推奨、AAA=最も厳しい）。
実プロジェクトでは AA を目指すことが多くなっています。
2026年時点でW3C公式の最新勧告は WCAG 2.2 です。
本記事では4原則（POUR）の概観に絞るためバージョン差分には深入りしませんが、実プロジェクトでは最新版の成功基準を参照することをおすすめします。
3-2. 自動チェックツールで何が検出できるか
POURの原則のうち、機械が照合できる項目は多くあります。代表的なツールをカテゴリ別に整理します。
| ツール | 形態 | 得意領域 |
|---|---|---|
| axe-core | 関数API・各種テストフレームワーク連携 | E2Eテストに組み込んで自動チェック |
| Pa11y CI | コマンドライン（Node） | CIパイプラインで複数URLを一括監査 |
| Lighthouse | ブラウザDevTools・CLI | 開発中の手元確認、スコア可視化 |
| WAVE | ブラウザ拡張・Webサービス | 画面上の問題箇所を視覚的に表示 |
| eslint-plugin-jsx-a11y | 静的解析プラグイン | コードを書きながらJSXの問題を検出 |
これらが検出してくれる典型例は、<img> のalt属性欠落や、文字色と背景色のコントラスト比不足などです。
見出し階層の飛び・label未結合・id重複といった構造的な誤りも、機械的な照合で確実に拾えます。
axe-coreを使った自動チェックは、たとえばPythonのE2Eテストから次のように書けます。
from playwright.sync_api import sync_playwright
from axe_playwright_python.sync_playwright import Axe
def test_task_list_accessibility():
with sync_playwright() as p:
browser = p.chromium.launch()
page = browser.new_page()
page.goto("http://localhost:3000/tasks")
axe = Axe()
results = axe.run(page)
assert results.violations_count == 0, results.generate_report()
browser.close()
これでE2Eテストの一部としてアクセシビリティ違反を検出できます。
書きながら検出したいなら静的解析プラグインを、CIで網羅したいならPa11y CIやaxe-coreを、と用途で使い分けます。
3-3. 自動チェックには明確な限界がある
axe-core公式ドキュメントでは、自動検出できるのはWCAG関連課題の平均約57% とされており、残り4割強は機械では判定できません。
機械では判定できないのは、文脈や流れの妥当性を問う領域です。
たとえばalt属性が付いていても、その中身が画像の意味を正しく説明しているかは機械では判断できません。
キーボードでタスクフローを最後まで完遂できるかも、個々の要素のtabindexだけでは見えません。
こうした領域は人間の手動確認が必要で、キーボードのみのフロー試行とスクリーンリーダーでの読み上げ順確認が代表的な手段になります。
標準準拠の軸は、自動チェックと手動チェックの両輪で初めて成立します。
OS側のアクセシビリティ機能
各OSには拡大鏡・高コントラスト・読み上げ・スティッキーキーといった支援技術が標準搭載されており、プロダクト側はこれらと協調できるように作る必要があります。
4. 人間中心の軸：観察でしか掴めない品質を測る
標準準拠の軸を全部満たしても、「実際に使ってもらうと詰まる」UIは存在します。
たとえばタスクが30件並んでフィルタは効くけれど、目的のタスクに辿り着くまでにユーザーが何回も画面を行き来する——これは標準には違反していません。
「使いやすさ」は主観的で、観察しないと見えないものです。
4-1. ユーザビリティの3要素と品質要因
ユーザビリティが扱う領域は、大きく3つの要素に整理できます。
| 要素 | 観点 |
|---|---|
| 使いやすさ（Ease of use） | 目的の操作にどれだけ素直に辿り着けるか |
| 速さ（Speed） | 操作の応答速度、タスク完了までの時間 |
| 心地よさ（Pleasantness） | 操作の手応えや表示の理解しやすさ |
観察の指針となる品質要因も合わせて押さえておきます。これらは観察セッションで「何を見るか」のチェックポイントになります。
| 品質要因 | 何を見るか |
|---|---|
| 理解可能性（Comprehensibility） | 機能の構造と用語がユーザーの世界観に合っているか |
| 一貫性（Consistency） | プロダクト内・OS慣習・過去バージョンとの一貫性 |
| ナビゲーション（Navigation） | 目的の操作までのクリック数・経路の発見しやすさ |
| 応答性（Responsiveness） | 操作に対する即時のフィードバック、進行状況の可視化 |
たとえばタスク管理画面で、ステータスの呼び方が画面ごとに「完了／Done／済」と揺れていたら一貫性の問題です。
タスク登録ボタンを押した後にスピナーも何も出なければ応答性の問題です。
4-2. 観察ベースのテスト：何をどう測るか
ユーザビリティ検証は「テストケースを書く」のではなく「ユーザーを観察する」のが中心になります。観察セッションの基本フローは次のようになります。
対象ユーザーは、製品を初めて触る人を含めるのが理想です。
バイアスがない状態でどこに詰まるかが見えやすいためです。
実際の利用者を集めるのが難しい場合は、開発・テスト以外のメンバー（営業・カスタマーサポートなど）が代替候補になります。
タスクは具体的なゴールを提示します。
「タスクを登録してください」よりも「来週月曜が期限のタスクを3件登録し、今週中のタスクだけ表示してください」のほうが観察しやすくなります。
物理的なユーザビリティラボ（観察室・マジックミラー）は1つの選択肢ですが、現代では画面録画＋発話記録＋オンライン会議でも十分代替できます。
重要なのは、操作画面・本人の発言・表情のいずれもが後から振り返れる形で残っていることです。
4-3. 観察時の記録項目
セッション中に何を記録するかは、あらかじめチェックリスト化しておくと観察者ごとのバラつきが小さくなります。
| 記録項目 | 何を判断する材料か |
|---|---|
| タスク達成率 | 割り当てたタスクを最後まで完了できたか |
| 所要時間 | 想定時間との乖離。長すぎる箇所は要改善 |
| 詰まり箇所 | どの画面・どの操作で止まったか |
| 戻り操作の回数 | 誤った経路に進んで戻った回数 |
| 表情・発言 | イライラ・困惑・喜びなど主観的反応 |
これらは「合格／不合格」を決めるための数字ではなく、改善の手がかりを集めるためのものです。
観察で見つかった詰まりは、機能不具合とは別の設計改善の素材として扱います。
観察セッション自体も単発イベントではなく、設計を磨くサイクルに組み込むのが現実的です。
5. 両軸を組み合わせる：シフトレフトで「使える」を最初から織り込む
両軸を「リリース直前にまとめてやろう」とすると、画面構造や色の使い方を変える手戻りが数十画面に及び、修正範囲が広すぎて崩壊します。
ここで効いてくるのが シフトレフト（開発ライフサイクルの前段階で品質を作り込む発想）で、「使える」品質も機能と同じく前倒しで織り込むのが現実的です。
前倒しの効きどころは、後段で発覚すると修正範囲が広がる種類の問題ほど大きくなります。
コントラスト比をデザインシステムに組み込んでおけば、実装後に色を全画面で直す手戻りはなくなる——これがシフトレフトの典型的な果実です。
逆に、観察セッションで見つかる「ナビゲーションの詰まり」のような問題はCIには載らない領域です。
早期に簡易プロトタイプで試しておかないと、リリース直前に大規模な作り直しを呼び込みます。
おわりに
「使える」品質は、機能正しさとは別軸で検証する——この視点に立つと景色が変わります。
アクセシビリティとユーザビリティは別物ではなく、同じ「人が使えるか」を測る2つの軸として統合的に扱えるようになります。
機能テストの緑色だけ見て安心していた頃の自分には、ぜひ届けたい話でした。