WCAG リフロー基準を通過しても、400％拡大では読めないことがある
横方向の基準合格が縦方向の読みやすさまで保証しないことを、実測の数字で確かめた。損失が画面の高さに応じて減らない絶対値であることを軸に、その正体を一つずつ分解した。
タグ
wcag
15件の記事
400%拡大が残す画面領域を実測したら、固定ピクセルという通行料が見つかった
320pxのリフローに合格したページでも、短いビューポートでは本文に残る縦方向の空間が118pxまで減っていた。損失は割合ではなく82pxの固定ピクセル通行料で、その大半はアプリケーションCSSの外側にあるサードパーティの固定コンテナから生じていた。測定手順と回帰ゲートの設計、閾値の置き方まで記録する。
popoverが肩代わりするのは半分だけ: ツールチップ7実装で測ったSC 1.4.13
ツールチップの実装を7つ作り、WCAG 2.2 SC 1.4.13のDismissible・Hoverable・Persistentを個別に測った。CSSだけの3つは全部Dismissibleで落ち、popover="hint"はDismissibleを無料でくれる代わりにHoverableで落ちた。
リフローを320pxの幅だけで測ると半分しか測れない: 400%拡大の高さ200px
WCAG 1.4.10 リフローを 320x844・320x256・320x200 の3条件で同時に測った。横方向の判定は3条件で1ピクセルも違わず、400%拡大で実際に変わるのは高さのほうだ。82pxの sticky ヘッダーがビューポートの41%を占め、本文の可視領域は6割を切っていた。測定スクリプトも置いた。
字間を0.12em広げたら570か所が切れた: チェッカーが通したAA基準
axe-coreはWCAG 1.4.12に違反0件を返した。その基準が要求する4つの値を実際に当てると、570個の要素で文字が切れた。4つを1つずつ分けて当て、どの宣言がコンテンツを失わせるのかを分解した記録。
WCAG 2.2 AAのルールが既定で無効だった: 正解付き1,213件で測った自動チェックの守備範囲
W3C ACTが公開する正解ラベル付きテストケース1,213件にaxe-coreを全件通した。失敗するはずの387件のうち、当該達成基準で違反が出たのは145件(37.5%)。基準36個のうち22個は0件で、沈黙の一部はルールが既定でオフだったことに起因する。
同じページを逆向きに辿ったら違反16件: 固定ヘッダーが飲み込むキーボードフォーカス
同じ6ページをTabで下りながら測ると WCAG 2.4.11 の違反は0件、Shift+Tabで上りながら測ると16件だった。ブラウザがフォーカス対象を画面内に入れる際の寄せ方が進行方向で変わるからだ。CSS一行で16件を0件にした実測記録である。測る向きを変えると、結果そのものが変わる点が核心だ。
サンプル26ページが取りこぼした3種類：WCAG-EM 2.0を1,342ページに当てた記録
W3Cが7月23日にWCAG-EM 2.0をGroup Noteとして公開した。その手順どおりにサンプルを26ページ選び、同じビルドの1,342ページ全部をaxe-coreで走らせて突き合わせた。サンプルが拾えたのは違反4種類のうち1種類。ランダムサンプルが新しい発見を返す確率は0.29%だった。
divグリッドの表が失うもの：アクセシビリティツリーとテキスト抽出の同時実測
同じ営業時間の表を4通りのマークアップで作り、axe-coreと5種類の抽出器に通した。axeは4つとも違反0件。ところがHTMLをMarkdownやテキストへ還元した途端、7行のうち0行しか復元できないマークアップが3つあった。role="table"では届かない層を実測ログで整理する。
aria-modal="true"は何も防いでいなかった — モーダルのフォーカス脱出実測とinert
role="dialog"とaria-modal="true"を備えた「正しく見える」モーダルで、Tabを3回押すとフォーカスがオーバーレイの裏へ抜けた。axeの違反は0件。同じマークアップをaria-hidden、inertに切り替えながら、キーボードフォーカスが実際にどこへ落ちるかを記録した。
WCAG 2.2の最小ターゲットサイズ、92点の緑の裏に隠れたAA不合格
指先が滑る22×22のボタンに、Lighthouseはアクセシビリティ92点を出した。WCAG 2.2が新設したSC 2.5.8(最小24×24)をサンドボックスに仕込み、自作スクリプトとLighthouseで二度測った。自動ツールはサイズ違反こそ捕まえるが、例外判定は人間に丸投げする。24pxの円が重なるかを計算するスペーシング例外まで、実測ログとCSS修正で整理する。
自動アクセシビリティ検査が緑になっても残る四つの壁
チェックアウトページ一枚にWCAG違反を八つわざと埋め込み、axe-coreで走らせた。ルール型の四つは捕まったが、人間の判断が要る四つは緑の裏にそのまま残った。自動化が構造的に見られないものと、その穴を埋める手動レビューのチェックリストを、実測ログとともにまとめる。
アクセシブルネームがずれると、音声操作もAIエージェントもボタンを押せない
ボタンにaria-labelを付けたのに、アクセシビリティツリーは画面に出ていない文字を読んでいる。WCAG 2.5.3 Label in Nameの違反をサンドボックスで再現してツリーで確認し、Lighthouse 13.3.0の新カテゴリAgentic Browsingで0点が100点に変わる過程を実測した。
同じマークアップ、違う判定 — axe-coreをCIに入れるとcolor-contrastが静かに消える理由
AIが吐き出した予約ウィジェットを1つ、jsdomと実ブラウザでそれぞれaxe-coreに通してみた。構造的な違反4件はブラウザなしでも捕まったが、color-contrastだけjsdomではincompleteに落ちた。なぜそうなるのか、カバレッジの穴を開けないためにCIパイプラインをどう2段に組むかを実測ログとともにまとめた。
アクセシビリティ55点から100点へ — LighthouseでWCAG違反を実際に直す
架空のベーカリーのランディングページをLighthouseのアクセシビリティ監査にかけて55点。6つのWCAG違反を1つずつ直して100点にした実測ログと、自動ツールが見逃したキーボードの罠までまとめた。