WCAG 達成基準 · Level AA
WCAG 2.5.8: ターゲットのサイズ（最小）
WCAG 2.5.8は、ボタンやリンクなどのインタラクティブなターゲットが、24×24 CSSピクセルの最小サイズを持つか、より小さいターゲットの周囲に十分な間隔を設けることを求めています。これは、運動障害のあるユーザーがそれらを確実に操作できるようにするためです。この基準を満たさないと、ポインターを正確に操作できない人にとって、誤操作やフラストレーションの原因となります。
- Level AA
- Wcag
- Wcag 2 2 aa
- 操作可能
- アクセシビリティ
このルールの意味
WCAG 2.5.8 Target Size (Minimum) は、WCAG 2.2 で導入されたレベルAAの達成基準です。これは、ポインター入力のターゲットサイズは少なくとも 24×24 CSS ピクセルでなければならないと定めています。ただし重要な例外が1つあります。ターゲット自体が 24×24 CSS ピクセルより小さい場合、その周囲に十分なオフセット間隔が設けられていて、ターゲットとその間隔を含む合計の領域が、あらゆる方向で 24×24 の閾値を満たしていればよい、というものです。言い換えると、ターゲットのバウンディングボックスと、その周囲にある他のターゲットが存在しない余白を合わせた領域が、水平方向に 24 CSS ピクセル、垂直方向に 24 CSS ピクセルに達していなければなりません。
この基準は、ポインターイベントを受け取ることができるあらゆる要素に適用されます。リンク（<a>）、ボタン（<button>）、チェックボックス、ラジオボタン、セレクトコントロール、スライダー、ポインターイベントリスナーを持つカスタムウィジェット、インタラクティブであることを示す ARIA ロールが付与された要素などです。装飾画像や静的テキストのような非インタラクティブ要素には、たとえサイズが大きくても適用されません。
ターゲットがこの基準に適合するのは、次のいずれかが真である場合です。
- ターゲットのレンダリングされたサイズが、両方の次元で少なくとも 24×24 CSS ピクセルである。
- ターゲットが一方または両方の次元で 24 CSS ピクセル未満だが、ターゲットの端と最も近い隣接インタラクティブ要素とのオフセットが十分に大きく、ターゲットとオフセットを合わせた領域が少なくとも 24×24 CSS ピクセルになる。
- ターゲットが文やテキストブロック内のインライン要素であり、こうしたターゲットをリフローさせると読書を妨げるため、明示的に除外されている場合。
- ターゲットの視覚的なサイズがブラウザのデフォルトのユーザーエージェントスタイルシートによって完全に決定されており、作者がそれを変更していない場合 — これはネイティブコントロールの例外です。
- 同じ情報の非インタラクティブな提示が存在し、小さいターゲットは単なる代替手段であって、唯一の操作手段ではない場合。
ターゲットが不適合となるのは、ターゲットが 24×24 CSS ピクセルより小さく、かつそれを補うだけのオフセット間隔がなく、上記のいずれの例外にも該当しない場合です。現実世界でよく見られる不適合例としては、小さなアイコンのみのボタン（モーダル内の 16×16 の閉じるアイコンなど）、パディングがほとんどない密集したナビゲーションリンク、各アイコンが 20×20 ピクセルでその間に 2px のマージンしかないソーシャルシェアアイコンの行などがあります。
WCAG 2.5.8 はあくまで最低限の要件であることにも注意が必要です。関連する AAA の達成基準 2.5.5 Target Size (Enhanced) では、オフセット間隔の例外なしに少なくとも 44×44 CSS ピクセルが求められています。また、多くのユーザビリティガイドラインでは、快適なタッチターゲットとして 44〜48 CSS ピクセルを推奨しています。2.5.8 を満たすことは出発点であり、到達点ではありません。
なぜ重要か
運動機能障害は、ポインターの精度にさまざまな形で影響します。パーキンソン病、本態性振戦、脳性まひ、多発性硬化症、脳卒中による片麻痺、反復性ストレス障害などのある人は、小さなターゲットにポインターを正確に合わせることができない場合があります。高齢者もまた、微細運動制御の自然な低下を経験します。65歳以上の人のおよそ 15% が、マウスやタッチスクリーンの使用に大きな困難を感じていると報告しています。臨床的な状態に限らず、状況的に制約を受けるユーザー — 例えば、動いているバスの中で片手でスマートフォンを持っている人や、指が小さなスマートフォン画面に対して相対的に大きい人 — も、小さなターゲットに苦労します。
世界保健機関によると、世界で 13 億人以上が何らかの障害を抱えて生活しており、その中でも運動機能障害は最も一般的なカテゴリーの1つです。インタラクティブ要素が小さすぎたり互いに近すぎたりすると、これらのユーザーは誤操作、タップミス、繰り返し発生するエラーに直面し、そのサイトは事実上利用不能になります。特にタッチデバイスでは、クリックを確定する前にカーソル位置を確認できるホバー状態が存在しないため、フラストレーションはいっそう増大します。
具体的なシナリオを考えてみましょう。トルコの電子機器を販売する EC サイトが、各商品ページの上部に 5 つのソーシャルシェアアイコンを 1 行で表示しており、それぞれが 18×18 ピクセルで、その間には 3px の隙間しかありません。本態性振戦のあるユーザーが商品を WhatsApp で共有しようとしても、何度も誤って別のアイコンをタップしてしまい、意図しない Facebook 共有が行われてしまいます。彼女はこれらの共有をすぐに取り消すことができず、タスクはあまりにエラーが多くなるため、最終的に完全に諦めてしまいます。各アイコンを 24×24 CSS ピクセルに拡大するか、クリック可能領域が 24×24 に達するようにパディングを追加すれば、視覚デザインを大きく変えることなくこの問題を解決できます。
アクセシビリティの観点を超えても、十分なターゲットサイズはコンバージョン率の向上、直帰率の低下、インタラクションの準備性に関連する Core Web Vitals スコアの改善と相関しています。検索エンジンによるモバイルファーストインデックスも、タッチ操作の使いやすさが高いページを優遇するため、ターゲットサイズはアクセシビリティと SEO が交差する要素でもあります。
関連する Axe-core のルール
- target-size (experimental): このルールは、インタラクティブ要素のレンダリングされたサイズが少なくとも 24×24 CSS ピクセルであるか、あるいはそれより小さい要素については、合計の到達可能領域が閾値を満たすだけの十分なオフセット間隔が存在するかどうかをチェックします。このルールは、フォーカス可能かつポインターインタラクティブな要素の計算済み寸法とバウンディングレクトを取得し、サイズまたはオフセットのテストに不合格となるものをフラグします。現在はexperimentalとしてマークされているため、axe-core のデフォルトルールセットには含まれておらず、
runOnly: { type: 'tag', values: ['wcag22aa', 'experimental'] }を指定するか、axe DevTools で experimental ルールを有効にすることで明示的に有効化する必要があります。このルールは、インラインテキストリンクや、ブラウザがプラットフォームごとに異なるサイズでレンダリングするネイティブコントロールに対して誤検出を生む可能性があるため、自動スキャン後には必ず手動レビューを行うことが推奨されます。また、複雑な CSS レイアウト、transform、重なり合う z-index スタッキングコンテキストが関わる場合、間隔ベースの適合を確実に検出することはできません。そのため、DevTools で計算済みスタイルを手動で確認することが依然として不可欠です。
ターゲットサイズは、視覚的なレンダリング、計算済み CSS、ビューポートの寸法、隣接するインタラクティブ要素との近接性に依存するため、自動ツールは明らかな不適合を検出することはできても、人間の判断を代替することはできません。ツールはボタンのバウンディングボックスを測定できますが、特に動的または JavaScript 駆動のインターフェースにおいて、2 つの隣接ターゲット間のオフセットが本当に他のインタラクティブ要素から完全に自由であるかどうかを判断するには、手動での検証が必要です。
テスト方法
- axe DevTools による自動スキャン: axe DevTools ブラウザ拡張機能をインストールします。テスト対象のページを開きます。axe DevTools パネルでスキャンを実行する前に experimental ルールを有効にします（ルールタグフィルターを探し、
experimentalを追加します）。スキャン完了後、ルール IDtarget-sizeで結果をフィルタリングします。フラグされた各要素について、報告された寸法を確認します。experimental ルールは誤検出率が高い傾向があるため、不適合として確定する前に必ず手動で検証してください。 - Lighthouse による自動スキャン: Chrome DevTools または CLI から Lighthouse のアクセシビリティ監査を実行します。Lighthouse には、48×48 CSS ピクセル未満で間隔が不十分なターゲットをチェックする tap-targets 監査が含まれています。これは WCAG 2.5.8 より厳しい閾値を用いている点に注意してください。そのため、Lighthouse の不適合は WCAG の不適合のスーパーセットとなります。レポートでフラグされた要素を確認し、24×24 の WCAG 閾値と照合して、どれが実際のレベルAAの不適合であり、どれがベストプラクティス上の推奨にとどまるかを判断します。
- ブラウザ DevTools による手動測定: DevTools を開き、各インタラクティブ要素を検査します。Computed パネルで
widthとheightを確認します。いずれかが 24px 未満の場合、ボックスモデルビューに切り替えてpaddingを確認します。パディングによってターゲットが 24×24 に達していれば適合です。そうでない場合は、要素のバウンディングレクトを使って、最も近い隣接インタラクティブ要素までの間隔を測定します。コンソールでdocument.querySelector('your-selector').getBoundingClientRect()を実行し、隣接要素の座標と比較します。各次元での合計の間隔が実効的な到達可能領域を 24px にまで広げていれば適合です。 - タッチシミュレーション: Chrome DevTools でデバイスエミュレーションを有効にし、タッチ最適化されたデバイスプロファイルに切り替えます。小さなインタラクティブ要素をタップしてみます。意図した要素の操作が難しい場合や、隣接要素が誤って起動してしまう場合を記録します。
- キーボードとスクリーンリーダーによるテスト（参考）: WCAG 2.5.8 はポインターに関する基準ですが、小さなターゲットにも視覚的なフォーカスインジケーターがあり、キーボードで到達可能かどうかを確認することで、複合的な問題を特定しやすくなります。NVDA と Firefox、または JAWS と Chrome を使用してインタラクティブ要素をナビゲートし、サイズにかかわらず到達・操作可能であることを確認します。
- 実機テスト: 実際のモバイルデバイス — 可能であれば大画面の Android と小さめの iOS デバイスの両方 — でテストし、デスクトップで適合しているターゲットが、モバイルビューポートサイズでも適合していることを確認します。CSS ピクセル密度やズームの挙動が、知覚されるターゲットサイズに影響を与える場合があるためです。
修正方法
小さなアイコンのみのボタン — 不適切な例
<!-- Close ボタンは 16x16 CSS ピクセルしかなく、パディングもなく、
他のコントロールに隣接している -->
<button class='close-btn' aria-label='Close dialog'>
<svg width='16' height='16' aria-hidden='true'></svg>
</button>
<style>
.close-btn {
width: 16px;
height: 16px;
padding: 0;
border: none;
background: none;
cursor: pointer;
}
</style>小さなアイコンのみのボタン — 適切な例
<!-- パディングを追加することで、視覚的なアイコンは 16x16 のまま、
インタラクティブ領域を 24x24 CSS ピクセルに拡大する。
min-width/min-height により、ターゲットが WCAG 2.5.8 の閾値を
満たすことを保証する。 -->
<button class='close-btn' aria-label='Close dialog'>
<svg width='16' height='16' aria-hidden='true'></svg>
</button>
<style>
.close-btn {
min-width: 24px;
min-height: 24px;
padding: 4px;
border: none;
background: none;
cursor: pointer;
display: inline-flex;
align-items: center;
justify-content: center;
}
</style>密集したナビゲーションリンク — 不適切な例
<!-- 各リンクは高さが約 20px でマージンは 1px しかなく、
ターゲット間のオフセット間隔が不十分 -->
<nav aria-label='Main navigation'>
<ul class='nav-list'>
<li><a href='/about'>About</a></li>
<li><a href='/services'>Services</a></li>
<li><a href='/contact'>Contact</a></li>
</ul>
</nav>
<style>
.nav-list li { margin: 1px 0; }
.nav-list a { font-size: 12px; line-height: 1.4; display: block; }
</style>密集したナビゲーションリンク — 適切な例
<!-- 各アンカーにパディングを付与することで、ターゲット領域の高さが
少なくとも 24px になる。テキスト自体が 24px 未満であっても、
項目間の隙間が十分に広くなり、オフセットルールを満たす。 -->
<nav aria-label='Main navigation'>
<ul class='nav-list'>
<li><a href='/about'>About</a></li>
<li><a href='/services'>Services</a></li>
<li><a href='/contact'>Contact</a></li>
</ul>
</nav>
<style>
.nav-list { list-style: none; padding: 0; margin: 0; }
.nav-list a {
display: block;
padding: 6px 8px; /* 垂直方向のパディングによりブロックの高さが 24px 以上になる */
font-size: 14px;
line-height: 1.4;
text-decoration: none;
}
</style>ヒットエリアが極端に小さいチェックボックス — 不適切な例
<!-- 多くのブラウザでデフォルトのチェックボックスは視覚的に 13px で、
追加のターゲット領域を提供する関連付けられたラベルがない -->
<input type='checkbox' id='agree'>
<span>I agree to the terms</span>関連付けられたラベル付きチェックボックス — 適切な例
<!-- <label> で input をラップすることで、ラベルテキスト全体も
有効なポインターターゲットになる。ラベルの line-height と padding により、
合計のヒットエリアは容易に 24x24 CSS ピクセルを超える。
input 自体にもフォールバックとして min-width/min-height を指定する。 -->
<label class='checkbox-label'>
<input type='checkbox' id='agree' class='checkbox-input'>
I agree to the terms
</label>
<style>
.checkbox-label {
display: inline-flex;
align-items: center;
gap: 8px;
padding: 4px 0;
cursor: pointer;
min-height: 24px;
}
.checkbox-input {
min-width: 24px;
min-height: 24px;
cursor: pointer;
}
</style>ソーシャルシェアアイコンの行 — 不適切な例
<!-- 各アイコンは 18x18px で隙間は 2px しかなく、
各アイコンの到達可能領域は 20px にとどまり、24px の閾値を下回る -->
<div class='share-row'>
<a href='#' aria-label='Share on Twitter'>
<img src='twitter.svg' width='18' height='18' alt=''>
</a>
<a href='#' aria-label='Share on Facebook'>
<img src='facebook.svg' width='18' height='18' alt=''>
</a>
</div>
<style>
.share-row { display: flex; gap: 2px; }
.share-row a { display: inline-block; line-height: 1; }
</style>ソーシャルシェアアイコンの行 — 適切な例
<!-- 各アンカーはパディングにより min-width と min-height が 24px となり、
アンカー間の隙間も少なくとも 3px あるため、パディングがなくても
オフセットルールを個別に満たす。 -->
<div class='share-row'>
<a href='#' class='share-link' aria-label='Share on Twitter'>
<img src='twitter.svg' width='18' height='18' alt=''>
</a>
<a href='#' class='share-link' aria-label='Share on Facebook'>
<img src='facebook.svg' width='18' height='18' alt=''>
</a>
</div>
<style>
.share-row { display: flex; gap: 6px; }
.share-link {
display: inline-flex;
align-items: center;
justify-content: center;
min-width: 24px;
min-height: 24px;
padding: 3px;
}
</style>よくある間違い
- ボタン自体ではなく、ボタン内のアイコンに
widthとheightを設定してしまうこと: 開発者はしばしば SVG や画像を 16〜20px に制限しますが、<button>要素自体にmin-width: 24px; min-height: 24pxと適切なパディングが必要で、十分なタップターゲットを作る必要があることを忘れがちです。 padding: 0やグローバルリセットでボタンや input からブラウザのデフォルトパディングを削除してしまうこと: フォーム要素のパディングをゼロにする CSS リセットは、ネイティブコントロールを使いやすいサイズに保っているバッファを取り除いてしまいます。リセット後には必ず明示的なパディングを再度追加してください。display: blockやdisplay: inline-blockを指定せずに、line-heightだけでリンクの高さを増やそうとすること: インライン要素は、ブロック要素のようにheightや垂直方向のパディングに反応しないため、リンクが視覚的には高く見えても、実際のクリック可能なバウンディングボックスは小さいままの場合があります。- ラッパーに
pointer-events: noneを指定し、小さな内側要素にクリックハンドラーを付与すること: これはラッパーに適用したパディングや最小サイズを無効化し、実効的なターゲットを内側要素のレンダリングサイズにまで縮小してしまいます。 - ボタンコンテナに
overflow: hiddenを適用してボタンのパディングをクリップしてしまうこと: 視覚的なクリック領域はコンテナの境界までクリップされるため、実効的なターゲットはボタン自身の寸法が示すよりも小さくなります。 scale()などの CSS transform を考慮し忘れること: 多くのブラウザでは、transform: scale(0.7)で視覚的に縮小されたボタンも、ポインターイベントに対しては元のバウンディングボックスを保持しますが、この挙動は一貫性がなく信頼できません。ターゲットは最終的なレンダリングスケールで必要なサイズになるように設計してください。<label>と<input>がプログラム的に関連付けられていないのに、大きな<label>が小さな<input>を補っていると誤解すること:<label>が input のidと一致するforを持っていない場合や、input が label 内にラップされていない場合、ラベルテキストをクリックしても input はアクティブになりません。そのため、機能するターゲット領域は input 自体の小さな領域に限られます。- ターゲットが実際にレンダリングされるビューポートサイズでテストしないこと: デスクトップでは 32×32 CSS ピクセルのボタンが、流動的なスケーリングやビューポート相対単位（
vw、vmin）の影響で、狭いモバイルビューポートでは 22×22 CSS ピクセルでレンダリングされることがあり、モバイルでのみ発生する不適合を生むことがあります。 - WCAG 2.5.8 のインラインテキストリンクに対する例外を広く解釈しすぎること: この例外は、段落内のハイパーリンクのように、本当にテキストの流れの中にあるリンクにのみ適用されます。フォームの下にある「Forgot password?」リンクのように、テキスト風にスタイルされた単独のリンクはインラインリンクではなく、24×24 の閾値を満たす必要があります。
- サードパーティのウィジェットや埋め込みコンポーネントを監査しないこと: クッキー同意バナー、チャットウィジェット、アナリティクスのオーバーレイには、外部スクリプトによって挿入される小さなボタン（同意、閉じる、最小化など）が頻繁に含まれます。これらもページのアクセシビリティの一部であり、コードが自社で作成されたものでなくても WCAG 2.5.8 に準拠していなければなりません。
トルコのアクセシビリティ規制との関係
2025年6月21日付官報第 32933 号で公布されたトルコ大統領通達 2025/10 は、トルコで事業を行う幅広いデジタルサービス提供者に対して、拘束力のあるアクセシビリティ要件を定めています。この通達は技術標準として WCAG 2.2 を明示的に参照しており、家族・社会サービス省（Aile ve Sosyal Hizmetler Bakanlığı）が発行する Erişilebilirlik Logosu（アクセシビリティロゴ）を取得するには、レベルAAへの適合が必要です。WCAG 2.5.8 は WCAG 2.2 におけるレベルAAの達成基準であるため、この義務的な枠組みの適用範囲に直接含まれます。
通達の対象となる主体には、中央および地方レベルの公的機関・政府機関、銀行や金融サービス企業、病院や民間医療提供者、20万件以上の加入者を持つ通信事業者、EC プラットフォーム、旅行代理店、民間輸送会社、国民教育省（Milli Eğitim Bakanlığı）に認可された私立学校などが含まれます。これらすべての組織にとって、WCAG 2.5.8 への準拠は単なるベストプラクティス上の推奨ではなく、アクセシビリティロゴの表示能力や監査時の法令遵守の証明に結びつく規制上の義務です。
実務的には、トルコの銀行のモバイル対応 Web アプリケーションは、振込確認ボタン、ワンタイムパスワード入力フィールド、ナビゲーションコントロールがすべて 24×24 CSS ピクセルの最小ターゲットサイズを満たしていなければなりません。同様に、EC サイトは、カートに追加ボタン、数量セレクター、フィルターコントロールが、すべてのデバイスプロファイルにおいて十分なサイズであることを確認する必要があります。医療ポータルは、セルが小さいことで悪名高い予約カレンダーを監査し、それらのセルを拡大するか、十分なオフセット間隔を設けなければなりません。通信事業者のセルフサービスポータルは、アカウント管理リンクやデータプランセレクター内のトグルコントロールが閾値を満たしているかどうかを確認する必要があります。
通達に従わない場合、行政制裁の対象となる可能性があり、また、トルコの消費者の間で信頼のシグナルとして利用が進んでいるアクセシビリティロゴを表示できなくなるおそれがあります。制裁にとどまらず、不適合は所管当局への苦情の対象にもなり得ます。トルコでは高齢者人口が増加しており、トルコ統計機構の予測では、2040年までに 65 歳以上の人が人口の 16.3% を占めるとされています。小さなターゲットがもたらす実務的な影響は今後さらに大きくなるため、早期の準拠は倫理的な優先事項であると同時に、長期的に見て健全なビジネス戦略でもあります。