WCAG 達成基準 · Level AAA

WCAG 2.5.5: ターゲットのサイズ(拡張)

WCAG 2.5.5 は、ボタンやリンクなどのインタラクティブなターゲットが少なくとも 44×44 CSS ピクセルのサイズであることを求めています。これは、運動障害や震え、巧緻性の低下がある人々が、隣接する要素を誤って作動させることなく、確実にコントロールを操作できるようにするためです。

この規定の意味

WCAG 2.5.5 Target Size (Enhanced) は WCAG 2.2 におけるレベル AAA の達成基準であり、インタラクティブ要素に対して厳格な最小サイズを定めています。具体的には、あらゆるユーザーインターフェイスコンポーネントのクリックまたはタップ可能な領域であるターゲットのサイズが、幅・高さともに少なくとも44×44 CSS ピクセルであることを求めています。これは、マウスクリック、タッチスクリーンタップ、スタイラス入力など、すべてのポインタベースのインタラクションに適用されます。

この文脈で「ターゲット」が正確には何を指すのかを理解することが重要です。ターゲットとは、コントロールの視覚的な見た目だけでなく、その全体のアクティブ化可能な領域を指します。小さなアイコンが見た目上は 16×16 ピクセルであっても、周囲のパディングによってクリック可能な領域が 44×44 ピクセルに拡張されていれば、この達成基準は満たされます。つまり、開発者は視覚デザインを大きく変えずに要件を満たすために、パディングを戦略的に利用することができます。

この達成基準では、ターゲット領域が少なくとも 44×44 CSS ピクセルであるインタラクティブ要素を適合と定義しています。インタラクティブ要素のアクティブ化可能な領域が、いずれか一方の寸法でもこの閾値を下回る場合は不適合となります。たとえば、幅が 44 ピクセルでも高さが 20 ピクセルしかないリンクは不適合です。

WCAG 2.5.5 では、44×44 の要件が適用されない公式な例外がいくつか定義されています。以下のとおりです。

  • 間隔 (Spacing): ターゲットが小さくても、他のすべてのターゲットから十分なオフセット間隔で離れている場合は許容されます。ターゲットは、44×44 CSS ピクセルの円をその中心に置いたとき、その円が他のいかなるターゲットや、他のターゲットの 44×44 の円のバウンディングボックスとも交差しないような位置に配置されていなければなりません。この例外は、隣接するコントロールが本質的に小さいが十分に離れている場合に、レイアウト変更を強制しないようにするためのものです。
  • 同等 (Equivalent): 同一ページ上に同じ機能を果たし、かつ最小サイズ要件を満たす代替コントロールが存在する場合。
  • インライン (Inline): ターゲットが文中にあり、そのサイズが非ターゲットテキストの行の高さによって制約されている場合。たとえば本文段落内のハイパーリンクは、サイズを変更するとテキストの流れが乱れるため、この例外の対象となります。
  • ユーザーエージェント制御 (User agent control): サイズがブラウザまたはオペレーティングシステムによって完全に決定され、制作者が変更できない場合。スタイルを当てていないネイティブブラウザのフォームコントロールなどが該当することがあります。
  • 本質的 (Essential): ターゲットの特定の見せ方が、伝達される情報にとって本質的である場合。これは、ターゲットサイズを変更すると意味や機能が根本的に変わってしまうようなケースに限定された狭い例外です。

この達成基準は WCAG 2.2 で導入され、以前のより緩やかなポインタターゲットに関するガイダンスに取って代わるものです。対応する達成基準であるレベル AA の WCAG 2.5.8 Target Size (Minimum) は、24×24 CSS ピクセルというより低い基準と間隔に基づく計算を定めていますが、2.5.5 は強化されたアクセシビリティのゴールドスタンダードであり続けます。

なぜ重要か

運動機能や巧緻性の障害は、世界人口のかなりの割合に影響を与えています。世界保健機関によると、約 13 億人、すなわち世界人口の 16% が何らかの重大な障害を抱えて生活しており、その中でも運動器系や筋骨格系の疾患が最も一般的なものの一つです。パーキンソン病、本態性振戦、脳性まひ、多発性硬化症、脳卒中による片麻痺、反復性ストレス障害などの状態は、いずれも人がポインタを正確に動かす能力を低下させます。モバイルデバイスでは、障害のないユーザーであっても、手袋をしているとき、手が濡れているとき、あるいは片手でスマートフォンを操作しているときなど、小さなターゲットに苦労することがあります。

具体的な現実のシナリオを考えてみましょう。関節リウマチのある人が、薬を購入するためにタッチスクリーンタブレットでトルコの EC プラットフォームを閲覧しているとします。チェックアウトフローには、小さなラジオボタン、細いドロップダウンメニュー、そして 24×18 ピクセルの「注文を確定」ボタンが含まれています。タップを誤るたびに誤ったオプションが選択されるか何も起こらず、ユーザーは何度もやり直しを強いられます。このフラストレーションは単なる不便にとどまらず、購入自体を断念させてしまう可能性があり、アクセシビリティの欠如がビジネスにとって直接的な収益損失へとつながります。

運動障害以外にも、十分なサイズのターゲットは幅広いユーザーに利益をもたらします。高齢者は、細かな運動制御の低下と視力の低下が同時に起こることが多く、小さなターゲットは二重の意味で困難になります。認知障害のあるユーザーはポインタの位置合わせに時間がかかり、ターゲットが密集していると隣接するコントロールを誤って起動しやすくなります。視力があり身体的にも健常なユーザーであっても、モバイルデバイスでは大きなターゲットの恩恵を受けます。これは、長年にわたり大手テクノロジー企業のデザイン慣行を牽引してきた事実です。Apple の Human Interface Guidelines では最小タップターゲットとして 44×44 ポイントを推奨しており、Google の Material Design ガイドラインでは同様の理由から少なくとも 48×48 density-independent pixels を推奨しています。

SEO とユーザビリティの観点からは、Google の Core Web Vitals 指標である「Interaction to Next Paint (INP)」は、ユーザーのインタラクションが素早く正確に登録されるインターフェイスを高く評価します。ターゲットが小さすぎることによるタップミスは、インタラクション失敗率やタスク完了時間、直帰率を押し上げます。これらは検索順位に間接的な影響を与えうるシグナルです。そのため、ポインタレベルでのアクセシビリティ改善は、コンプライアンスを超えた測定可能なビジネス上の影響を持ちます。

関連する Axe-core のルール

WCAG 2.5.5 は手動テストを必要とします。この強化された達成基準に対して、すべてのターゲットサイズ違反を確実に検出できる完全自動の axe-core ルールは存在しません。自動ツールがここで苦戦する理由は多岐にわたります。実効的なターゲットサイズは、パディング、マージン、疑似要素の寸法などを含む計算済み CSS レイアウトに依存し、それらはビューポート、デバイスピクセル比、動的レンダリングによって変化します。さらに、間隔の例外を適用するには、隣接するターゲット間の幾何学的オフセットを計算する必要がありますが、これは完全なレンダリング後のレイアウトツリーと近接分析を要し、自動 DOM 解析ツールではあらゆるケースで正確に実行することができません。加えて、ある要素が「インライン」または「同等」の例外に該当するかどうかは、セマンティクスや文脈の理解を必要とし、自動ルールエンジンの範囲を超えています。

  • target-size (axe-core experimental): Axe-core には target-size という実験的ルールが含まれており、インタラクティブ要素を WCAG 2.5.8 レベル AA の 24×24 CSS ピクセルと間隔オフセットの閾値に照らしてチェックします。このルールは小さな違反の一部を表面化させることはできますが、2.5.5 で求められるより厳格な 44×44 の閾値は適用しておらず、パディングや疑似要素によってレンダリングされたヒット領域が DOM スナップショットに反映されない場合の違反を見逃す可能性があります。このルールの結果は、完全な監査ではなく出発点として扱ってください。
  • 手動による目視確認: 2.5.5 を完全にカバーする自動ルールが存在しないため、テスターはブラウザの開発者ツール、CSS ピクセルルーラー、アクセシビリティ拡張機能などを用いてインタラクティブターゲットを目視で確認・計測する必要があります。これには、パディングがヒット領域に含まれていること、および間隔の例外が単に想定されているのではなく実際に満たされていることの確認が含まれます。

テスト方法

  1. 自動スキャンをベースラインとして実行する: テスト対象ページで Chrome DevTools の axe DevTools または Lighthouse を開きます。axe DevTools では、実験的ルールとして利用可能であれば「target-size」で結果をフィルタリングします。フラグが立った要素をメモしますが、このスキャンではすべての 2.5.5 違反を検出できず、44×44 ピクセルではなく 2.5.8 の閾値を参照している可能性があることを理解しておきます。Lighthouse のアクセシビリティ監査を使用して、関連するポインタターゲットの警告を探します。
  2. ブラウザ DevTools でターゲットサイズを計測する: Chrome または Firefox の DevTools を開き、Elements パネルを使ってボタン、リンク、フォーム入力、チェックボックス、ラジオボタン、カスタムコントロール、アイコンのみのコントロールなど、各インタラクティブ要素を検査します。Computed styles パネルでレンダリングされた幅と高さを確認します。ブロックレベル要素ではパディングがクリックターゲットに含まれますが、インライン要素ではそうとは限らないことに注意してください。計算されたヒット領域が少なくとも 44×44 CSS ピクセルであることを確認します。
  3. ブラウザの組み込みアクセシビリティツールを使用する: Chrome DevTools では Rendering タブを開き、「Emulate a focused page」を有効にするか、Accessibility Tree を使用して要素を検査します。Firefox では Accessibility Inspector を使用してインタラクティブ要素を特定し、そのバウンディングボックスの寸法と照合します。
  4. 実機のタッチデバイスでテストする: 実際の iOS デバイスを接続し、VoiceOver を有効にしてテストします(サイドボタンを 3 回押して起動)。タップでナビゲートし、ローターを使ってインタラクティブ要素間を移動します。小さなターゲットを起動しようとし、隣接する要素が誤って起動される頻度を記録します。Android デバイスでも TalkBack を使って同様にテストします(右スワイプで移動、ダブルタップで起動)。<div><span> 要素から構築されたカスタムウィジェットに特に注意を払います。
  5. 間隔の例外を手動でテストする: 44×44 ピクセル未満でありながら間隔の例外を主張するターゲットについては、そのターゲットを中心とした 44×44 ピクセルの仮想バウンディングボックスを描き、そのボックス内に他のインタラクティブ要素が入っていないことを目視で確認します。バウンディングボックスを描画するブラウザ拡張機能やオーバーレイツールがここで役立ちます。
  6. キーボードとスクリーンリーダーで検証する: NVDA + Firefox および JAWS + Chrome を使用し、Tab キーで全インタラクティブ要素を順にたどってテストします。キーボードフォーカスはポインタターゲットサイズを直接テストするものではありませんが、すべてのコントロールに到達できるかどうかを確認し、ポインタサイズと照合する要素の一覧を確定するのに役立ちます。macOS の VoiceOver + Safari を使って、カスタムコントロールが正しくアナウンスされ、ポインタクリック時に十分なアクティベーション領域を持つことを確認することもできます。
  7. 複数のビューポートサイズでテストする: ターゲットサイズはデスクトップとモバイルのレイアウトで異なる場合があります。320px、768px、1280px のビューポート幅でテストし、レスポンシブデザインがすべてのブレークポイントで 44×44 の最小値を維持していることを確認します。特にハンバーガーメニュー、カルーセル、データテーブルのアクション列に注意してください。

修正方法

サイズ不足のアイコンのみボタン — 不適切な例

<!-- 小さな SVG アイコンのみでレンダリングされた閉じるボタン。
     レンダリングサイズは約 16x16 CSS ピクセルで、44x44 の最小値を大きく下回る。 -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 0;
  cursor: pointer;
}
</style>

サイズ不足のアイコンのみボタン — 適切な例

<!-- パディングを追加してヒット領域を少なくとも 44x44 CSS ピクセルに拡張しつつ、
     アイコンの視覚的サイズは維持している。ボタン自体に明示的な
     min-width と min-height を指定し、ブラウザ間での適合を保証している。 -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 14px; /* 16px アイコン + 14px * 2 のパディング = 合計 44px のヒット領域 */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

div で作られたカスタムチェックボックス — 不適切な例

<!-- 視覚的にスタイルされたカスタムチェックボックスだが、
     ターゲットサイズ要件を満たすには小さすぎる。div にパディングがなく、
     20x20 ピクセルでレンダリングされている。 -->
<div role='checkbox' aria-checked='false' tabindex='0' class='custom-check'></div>

<style>
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  cursor: pointer;
}
</style>

div で作られたカスタムチェックボックス — 適切な例

<!-- 視覚的なボックスは 20x20 ピクセルのままだが、label 要素でラップし、
     パディングによってクリック可能な領域全体を 44x44 に拡張している。
     ネイティブの input 要素は、キーボードとポインタの挙動が組み込みで提供されるため、
     role=checkbox よりも強く推奨される。 -->
<label class='check-wrapper'>
  <input type='checkbox' class='sr-only'>
  <span class='custom-check' aria-hidden='true'></span>
  Subscribe to newsletter
</label>

<style>
.check-wrapper {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 44px; /* ラベル全体の行の高さが少なくとも 44px */
  cursor: pointer;
  padding: 12px 0; /* 垂直方向のパディングでヒット領域を拡張 */
}
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  flex-shrink: 0;
}
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
</style>

ツールバー内で間隔が詰まりすぎたナビゲーションリンク — 不適切な例

<!-- 小さなインライン要素としてレンダリングされたツールバーリンク。
     各リンクは幅約 32px、高さ 24px で、
     4px しか離れておらず、サイズ要件と間隔の例外の両方に不適合。 -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 12px;
  padding: 2px 4px;
  margin: 0 2px;
}
</style>

ツールバー内で間隔が詰まりすぎたナビゲーションリンク — 適切な例

<!-- 各リンクにパディングを追加し、ヒット領域を少なくとも 44x44 px に拡張。
     リンク間の隙間も広げているため、将来サイズ要件が緩和されたとしても
     間隔の例外が適用される。 -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 14px;
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 16px; /* 水平方向のパディングで幅を 44px を大きく超えるまで拡張 */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

よくある間違い

  • 視覚的なバウンディングボックスがヒット領域と同じだと仮定する: ボタン内のアイコン画像に width: 44px; height: 44px を設定しても、ボタン自体が 44×44 になるわけではありません。正しいヒット領域を作るには、その寸法または同等のパディングを <button> 要素自体に追加する必要があります。
  • 補償する最小サイズなしに padding: 0 でブラウザスタイルをリセットする: CSS リセットはボタンや入力要素からすべてのパディングを取り除くことがよくあります。リセット後は、アクティベーション領域を回復するために、必ず十分なパディングか明示的な min-widthmin-height を再適用してください。
  • ターゲットの高さを増やすために line-height のみに頼る: line-height を増やすとテキストの行間は変わりますが、アンカーやボタンのクリック可能領域が必ずしも拡張されるとは限りません。代わりに padding-toppadding-bottom を使用してください。
  • 十分な間隔なしに複数の小さなアイコンボタンを横並びに配置する: 24×24 のソーシャルメディア共有アイコンを 2px のマージンだけで横一列に並べると、サイズ要件と間隔の例外の両方に不適合となります。各アイコンを中心とした 44px の円が隣のアイコンと重なってしまうためです。
  • インラインテキストの例外をナビゲーションリンクに誤用する: この例外は、文や段落の流れるテキスト内のリンクに適用されます。ナビゲーションメニュー、ツールバー、リンクのリストはインラインテキストではなく、display: inline を使用していてもこの例外の対象にはなりません。
  • <span>role='button' を付けてカスタムコントロールを作り、span のサイズ指定を忘れる: スクリーンリーダーは span をボタンとしてアナウンスしますが、そのデフォルトのレンダリングサイズはテキスト内容のみによって決まり、通常は 44×44 ピクセルを大きく下回ります。必ず display: inline-flexmin-widthmin-heightpadding を追加してください。
  • 実際のビューポートサイズで実機のタッチデバイスをテストしない: デスクトップの DevTools でピクセルを測るだけでは不十分です。CSS ピクセル密度や OS レベルのタッチターゲットのヒットテスト挙動は、シミュレート環境と実機環境で異なる場合があります。
  • 動的にレンダリングされるコントロールを見落とす: ツールチップ、日付ピッカーの日セル、オートコンプリートの候補項目、モーダルの閉じるボタンなどは、多くの場合 JavaScript ライブラリによってハードコードされた小さなサイズで挿入されます。サードパーティウィジェットの出力を監査し、必要に応じてスタイルを上書きしてください。
  • 計測せずに間隔の例外を主張する: 間隔の例外は幾何学的かつ厳密です。コントロール同士が十分離れているように「見える」だけでは不十分であり、各サイズ不足ターゲットに対して 44px の円テストを適用し、重なりがないことを確認しなければなりません。
  • レスポンシブブレークポイント変更後の検証を忘れる: デスクトップでは 44×44 のボタンが、パーセンテージ幅や flexbox の縮小により、375px のモバイルビューポートでは 30×30 に縮んでしまうことがあります。主要なすべてのブレークポイントでターゲットサイズを再テストしてください。

トルコのアクセシビリティ規制との関係

トルコの大統領通達第 2025/10 号は、2025 年 6 月 21 日付官報第 32933 号で公布され、WCAG 2.2 標準に基づく Web およびモバイルアクセシビリティ要件を義務付けています。この通達はトルコ国内で事業を行う特定の主体に適用され、特定の WCAG レベルへの適合に関する法的義務を定めています。

通達の対象となる主体の種類には、中央および地方レベルの公的機関・団体、銀行規制監督庁 (BDDK) によって規制される銀行および金融機関、公立・私立を問わない病院および医療提供者20 万人以上の加入者を持つ通信事業者、一定の売上または取引件数の閾値を超える電子商取引プラットフォーム、オンライン予約サービスを運営する旅行代理店、デジタルチケットや予約を提供する民間輸送会社、そして国民教育省 (MoNE) に認可された私立学校および教育機関が含まれます。

WCAG 2.5.5 Target Size (Enhanced) はレベル AAA の達成基準であり、主としてレベル A および AA の適合に焦点を当てるこの通達が定める最低限の必須要件には含まれていません。しかし、通達は特に一般市民、医療患者、学生にサービスを提供する主体に対し、可能な範囲で AAA 適合を追求することを明示的に奨励しており、それが最高水準のアクセシビリティ実践を表すことを認識しています。

トルコの組織にとって、WCAG 2.5.5 を実装することは、いくつかの文脈で特に戦略的な価値を持ちます。高齢者向けの政府ポータル、慢性疾患の患者が利用する医療予約システム、運動障害のある人がアクセスする銀行アプリケーションなどは、いずれも 44×44 ピクセルのターゲットサイズから大きな恩恵を受けます。トルコは急速に高齢化が進んでおり、トルコ統計機構 (TÜİK) は、2040 年までに 65 歳以上の市民が人口の 16% を超えると予測しています。この層にとって、ポインタターゲットのサイズは重要なユーザビリティ要因です。

AAA が法的に義務付けられていない場合でも、WCAG 2.5.5 を自主的に満たす組織は、訴訟リスクの低減、アクセシビリティ文書を要件とする政府調達における入札資格の強化、EC やフィンテックなど競争の激しい市場におけるユーザー満足度指標の向上といった形で、コミットメントを示すことができます。Accsible の SDK は、この達成基準の達成または達成に近づくのに役立つ、設定可能なタッチターゲット拡張機能を提供しており、そのような取り組みの文書化は、機関の調達プロセスで求められる Accessibility Conformance Report (ACR) や VPAT 提出書の一部とすることができます。