WCAG 2.5.8 : Taille de cible (minimum)

Ce que signifie cette règle

WCAG 2.5.8 Taille de la cible (minimum) est un critère de succès de niveau AA introduit dans WCAG 2.2. Il stipule que la taille de la cible pour les entrées au pointeur doit être d’au moins 24×24 pixels CSS, avec une exception importante : si la cible elle-même est plus petite que 24×24 pixels CSS, il doit alors y avoir un espacement de décalage suffisant autour d’elle de sorte que la zone totale — y compris l’espacement — atteigne le seuil de 24×24 dans toutes les directions. En d’autres termes, la boîte englobante de la cible plus tout espace blanc adjacent exempt d’autres cibles doit, collectivement, atteindre 24 pixels CSS horizontalement et 24 pixels CSS verticalement.

Le critère s’applique à tout élément pouvant recevoir un événement de pointeur : liens (<a>), boutons (<button>), cases à cocher, boutons radio, contrôles select, curseurs, widgets personnalisés avec des écouteurs d’événements de pointeur, et tout élément auquel est attribué un rôle ARIA impliquant une interactivité. Il ne s’applique pas aux éléments non interactifs tels que les images décoratives ou le texte statique, même s’ils sont de grande taille.

Une cible réussit ce critère lorsque au moins une des conditions suivantes est vraie :

• La taille rendue de la cible est d’au moins 24×24 pixels CSS dans les deux dimensions.
• La cible est plus petite que 24 pixels CSS dans une ou deux dimensions, mais le décalage entre le bord de la cible et l’élément interactif adjacent le plus proche est suffisamment grand pour que la zone combinée cible-plus-décalage soit d’au moins 24×24 pixels CSS.
• La cible est un élément en ligne au sein d’une phrase ou d’un bloc de texte, ce qui est explicitement exclu car le reflow de telles cibles perturberait la lecture.
• La taille visuelle de la cible est entièrement déterminée par la feuille de style user-agent par défaut du navigateur et l’auteur ne l’a pas modifiée — c’est l’exception pour les contrôles natifs.
• Une présentation non interactive de la même information existe et la petite cible est simplement une alternative, pas le seul moyen d’activation.

Une cible échoue lorsqu’elle est plus petite que 24×24 pixels CSS et qu’il n’y a pas suffisamment d’espacement de décalage pour compenser, et qu’aucune des exceptions ci-dessus ne s’applique. Parmi les échecs courants dans le monde réel, on trouve les petits boutons composés uniquement d’icônes (comme une icône de fermeture 16×16 dans une modale), les liens de navigation serrés avec un rembourrage minimal, et les rangées d’icônes de partage social où chaque icône est rendue à 20×20 pixels avec seulement 2px de marge entre elles.

Il convient de noter que WCAG 2.5.8 est une exigence minimale. Le critère AAA associé 2.5.5 Taille de la cible (améliorée) exige au moins 44×44 pixels CSS sans exception d’espacement de décalage, et de nombreuses directives d’ergonomie recommandent 44–48 pixels CSS comme cible tactile confortable. Satisfaire 2.5.8 représente le plancher, pas le plafond.

Pourquoi c’est important

Les déficiences motrices affectent la précision du pointeur de nombreuses façons. Les personnes atteintes de la maladie de Parkinson, de tremblement essentiel, de paralysie cérébrale, de sclérose en plaques, d’hémiplégie post-AVC ou de troubles musculo-squelettiques liés à des mouvements répétitifs peuvent être incapables de placer un pointeur de manière fiable sur une petite cible. Les personnes âgées subissent également un déclin naturel de la motricité fine : environ 15% des personnes de plus de 65 ans déclarent avoir des difficultés importantes à utiliser une souris ou un écran tactile. Au-delà des pathologies, même les utilisatrices et utilisateurs temporairement limités — quelqu’un qui tient un smartphone d’une main dans un bus en mouvement, ou quelqu’un dont le doigt est grand par rapport à un petit écran de téléphone — ont du mal avec les cibles minuscules.

Selon l’Organisation mondiale de la Santé, plus de 1,3 milliard de personnes dans le monde vivent avec une forme de handicap, et la déficience motrice figure parmi les catégories les plus courantes. Lorsque les éléments interactifs sont trop petits ou trop proches les uns des autres, ces personnes subissent des activations accidentelles, des appuis manqués et des erreurs répétées qui rendent un site pratiquement inutilisable. La frustration est aggravée sur les appareils tactiles où il n’existe pas d’état de survol permettant de confirmer la position du curseur avant de cliquer.

Considérons un scénario concret : un site de e-commerce turc vendant de l’électronique affiche une rangée de cinq icônes de partage social en haut de chaque page produit, chacune de 18×18 pixels avec un espace de 3px entre elles. Une utilisatrice atteinte de tremblement essentiel qui essaie de partager un produit sur WhatsApp appuie à plusieurs reprises sur la mauvaise icône, déclenchant des partages Facebook non souhaités. Elle n’a aucun moyen d’annuler rapidement ces partages, et la tâche devient tellement sujette aux erreurs qu’elle y renonce complètement. Augmenter chaque icône à 24×24 pixels CSS, ou ajouter du padding pour que la zone cliquable atteigne 24×24, résoudrait le problème sans modifier significativement le design visuel.

Au-delà de l’accessibilité, une taille de cible adéquate est corrélée à des taux de conversion plus élevés, des taux de rebond plus faibles et de meilleurs scores Core Web Vitals liés à la réactivité de l’interaction. L’indexation mobile-first par les moteurs de recherche favorise également les pages offrant une bonne utilisabilité tactile, faisant de la taille des cibles un facteur à l’intersection de l’accessibilité et du SEO.

Règles Axe-core associées

• target-size (expérimental) : Cette règle vérifie si les éléments interactifs ont une taille rendue d’au moins 24×24 pixels CSS ou, pour les éléments plus petits, si un espacement de décalage suffisant existe pour que la zone totale atteignable respecte le seuil. La règle interroge les dimensions calculées et les rectangles englobants des éléments focalisables et interactifs au pointeur et signale ceux qui échouent au test taille-ou-décalage. Comme elle est actuellement marquée expérimentale, elle n’est pas incluse dans l’ensemble de règles par défaut d’axe-core et doit être explicitement activée avec runOnly: { type: 'tag', values: ['wcag22aa', 'experimental'] } ou en activant les règles expérimentales dans axe DevTools. La règle peut produire de faux positifs pour les liens textuels en ligne et les contrôles natifs que les navigateurs dimensionnent différemment selon les plateformes, de sorte qu’un examen manuel est toujours recommandé après un scan automatisé. Elle ne peut pas détecter de manière fiable les réussites basées sur l’espacement lorsque des mises en page CSS complexes, des transformations ou des contextes de superposition z-index se chevauchant sont impliqués, c’est pourquoi l’inspection manuelle des styles calculés dans DevTools reste essentielle.

Comme la taille de la cible dépend du rendu visuel, du CSS calculé, des dimensions de la fenêtre d’affichage et de la proximité des éléments interactifs voisins, les outils automatisés peuvent signaler les échecs évidents mais ne peuvent pas remplacer le jugement humain. Un outil peut mesurer la boîte englobante d’un bouton, mais déterminer si le décalage entre deux cibles adjacentes est réellement exempt d’autres éléments interactifs — en particulier dans les interfaces dynamiques ou pilotées par JavaScript — nécessite une vérification manuelle.

Comment tester

1. Analyse automatisée avec axe DevTools : Installez l’extension de navigateur axe DevTools. Ouvrez la page à tester. Dans le panneau axe DevTools, activez les règles expérimentales avant de lancer l’analyse (recherchez le filtre de balise de règle et ajoutez experimental). Une fois l’analyse terminée, filtrez les résultats par l’ID de règle target-size. Pour chaque élément signalé, notez les dimensions indiquées. Vérifiez la constatation manuellement avant de l’enregistrer comme échec confirmé, car les règles expérimentales présentent un taux plus élevé de faux positifs.
2. Analyse automatisée avec Lighthouse : Lancez un audit d’accessibilité Lighthouse dans Chrome DevTools ou via la CLI. Lighthouse inclut un audit des cibles tactiles qui vérifie les cibles plus petites que 48×48 pixels CSS avec un espacement insuffisant — notez que cela utilise un seuil plus strict que WCAG 2.5.8, de sorte que les échecs Lighthouse sont un sur-ensemble des échecs WCAG. Examinez les éléments signalés dans le rapport et recoupez avec le seuil WCAG de 24×24 pour déterminer lesquels constituent de véritables échecs de niveau AA par rapport à de simples recommandations de bonnes pratiques.
3. Mesure manuelle avec les DevTools du navigateur : Ouvrez DevTools et inspectez chaque élément interactif. Dans le panneau Calculated (Computed), vérifiez width et height. Si l’une des valeurs est inférieure à 24px, passez à la vue Box Model et vérifiez le padding. Si le padding porte la cible à 24×24, elle réussit. Sinon, mesurez l’écart avec l’élément interactif adjacent le plus proche en utilisant le rectangle englobant de l’élément : exécutez document.querySelector('your-selector').getBoundingClientRect() dans la console et comparez les coordonnées des éléments voisins. Si l’écart combiné dans chaque dimension porte la zone atteignable effective à 24px, la cible réussit.
4. Simulation tactile : Dans Chrome DevTools, activez l’émulation d’appareil et basculez vers un profil d’appareil optimisé pour le tactile. Essayez d’appuyer sur chaque petit élément interactif. Notez tout cas où l’activation de l’élément souhaité est difficile ou où des éléments adjacents sont déclenchés accidentellement.
5. Tests clavier et lecteur d’écran (pour le contexte) : Bien que WCAG 2.5.8 soit spécifiquement un critère pour les pointeurs, vérifier que les petites cibles ont également des indicateurs de focus visibles et sont accessibles au clavier permet d’identifier des problèmes combinés. Utilisez NVDA avec Firefox ou JAWS avec Chrome pour parcourir les éléments interactifs et confirmer qu’ils sont atteignables et activables quelle que soit leur taille.
6. Tests sur appareils réels : Testez sur un appareil mobile physique — idéalement à la fois un appareil Android à grand écran et un appareil iOS plus petit — pour confirmer que les cibles qui réussissent sur desktop réussissent également aux tailles de fenêtre d’affichage mobile, car la densité de pixels CSS et le comportement de zoom peuvent affecter la taille perçue de la cible.

Comment corriger

Petit bouton composé uniquement d’une icône — Incorrect

<!-- Close button is only 16x16 CSS pixels, no padding, adjacent to other controls -->
<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>

Petit bouton composé uniquement d’une icône — Correct

<!-- Adding padding increases the interactive area to 24x24 CSS pixels
     while the visual icon remains 16x16. The min-width/min-height
     ensures the target meets the WCAG 2.5.8 threshold. -->
<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>

Liens de navigation serrés — Incorrect

<!-- Each link renders at roughly 20px tall with 1px margin,
     leaving insufficient offset spacing between targets -->
<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>

Liens de navigation serrés — Correct

<!-- Padding on each anchor ensures the target area is at least 24px tall.
     The gap between items is now large enough to satisfy the offset rule
     even if the text itself is smaller than 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; /* vertical padding brings block height to >= 24px */
    font-size: 14px;
    line-height: 1.4;
    text-decoration: none;
  }
</style>

Case à cocher avec zone d’activation minuscule — Incorrect

<!-- The default checkbox is visually 13px on many browsers and has no
     associated label providing additional target area -->
<input type='checkbox' id='agree'>
<span>I agree to the terms</span>

Case à cocher avec label associé — Correct

<!-- Wrapping the input in a <label> makes the entire label text also
     a valid pointer target. The label's line-height and padding ensure
     the combined hit area easily exceeds 24x24 CSS pixels.
     The input itself is given min-width/min-height as a fallback. -->
<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>

Rangée d’icônes de partage social — Incorrect

<!-- Each icon is 18x18px with only 2px gap; the combined
     reachable area for each icon is only 20px, below the 24px threshold -->
<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>

Rangée d’icônes de partage social — Correct

<!-- Each anchor now has min-width and min-height of 24px via padding,
     and the gap between anchors is at least 3px so the offset rule is
     satisfied independently even without the padding. -->
<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>

Erreurs courantes

• Définir width et height sur l’icône à l’intérieur d’un bouton plutôt que sur le bouton lui-même : Les développeurs limitent souvent le SVG ou l’image à 16–20px mais oublient que l’élément <button> a besoin de min-width: 24px; min-height: 24px et d’un padding approprié pour créer une cible tactile adéquate.
• Supprimer le padding par défaut du navigateur sur les boutons et les champs de formulaire avec padding: 0 ou une réinitialisation globale : Les resets CSS qui annulent le padding des éléments de formulaire éliminent la marge de sécurité qui maintient les contrôles natifs à une taille utilisable. Réajoutez toujours un padding explicite après un reset.
• Se fier uniquement à line-height pour augmenter la hauteur d’un lien sans display: block ou display: inline-block : Les éléments en ligne ne réagissent pas à height ou au padding vertical de la même manière que les éléments de type bloc, de sorte qu’un lien peut paraître visuellement plus haut alors que sa boîte cliquable réelle reste petite.
• Utiliser pointer-events: none sur un conteneur et attacher les gestionnaires de clic à un petit élément interne : Cela annule tout padding ou taille minimale appliqués au conteneur, réduisant la cible effective à la taille rendue du petit élément interne.
• Appliquer overflow: hidden à un conteneur de bouton qui rogne le padding du bouton : La zone de clic visuelle est rognée aux limites du conteneur, rendant la cible effective plus petite que ne le suggèrent les dimensions du bouton.
• Oublier de prendre en compte les transformations CSS telles que scale() : Un bouton réduit visuellement via transform: scale(0.7) conserve sa boîte englobante d’origine pour les événements de pointeur dans la plupart des navigateurs, mais ce comportement est incohérent et peu fiable — dimensionnez toujours les cibles à leur échelle rendue finale.
• Supposer qu’un grand <label> compense un petit <input> lorsque le label et l’input ne sont pas associés de manière programmatique : Si le <label> n’utilise pas for correspondant à l’id de l’input, ou si l’input n’est pas englobé dans le label, cliquer sur le texte du label n’active pas l’input, de sorte que seule la petite zone de la cible de l’input est fonctionnelle.
• Ne pas tester aux tailles de fenêtre d’affichage où les cibles sont réellement rendues : Un bouton qui fait 32×32 pixels CSS sur desktop peut être rendu à 22×22 pixels CSS sur une fenêtre mobile étroite en raison d’un redimensionnement fluide ou d’unités relatives à la fenêtre (vw, vmin), créant un échec qui n’apparaît que sur mobile.
• Interpréter trop largement l’exception WCAG 2.5.8 pour les liens textuels en ligne : L’exception s’applique uniquement aux liens véritablement en ligne dans un flux de texte (par exemple, un hyperlien à l’intérieur d’un paragraphe). Les liens autonomes stylisés pour ressembler à du texte — comme un lien « Forgot password? » sous un formulaire — ne sont pas des liens en ligne et doivent respecter le seuil de 24×24.
• Ne pas auditer les widgets tiers et composants embarqués : Les bannières de consentement aux cookies, les widgets de chat et les superpositions d’analytique incluent fréquemment de petits boutons (accepter, fermer, minimiser) injectés par des scripts externes. Ils font toujours partie du profil d’accessibilité de la page et doivent se conformer à WCAG 2.5.8 même si le code n’est pas développé en interne.

Lien avec la réglementation d’accessibilité en Turquie

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences d’accessibilité contraignantes pour un large éventail de prestataires de services numériques opérant en Turquie. La Circulaire fait explicitement référence à WCAG 2.2 comme norme technique, et la conformité de niveau AA est requise pour pouvoir prétendre au Erişilebilirlik Logosu (Logo d’accessibilité) délivré par le Ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı). Étant donné que WCAG 2.5.8 est un critère de niveau AA dans WCAG 2.2, il relève directement du champ d’application de ce cadre obligatoire.

Les types d’entités couverts par la Circulaire incluent les institutions publiques et organismes gouvernementaux aux niveaux central et local, les banques et sociétés de services financiers, les hôpitaux et prestataires de soins de santé privés, les opérateurs de télécommunications comptant 200,000 abonnés ou plus, les plateformes de e-commerce, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le Ministère de l’Éducation nationale (Milli Eğitim Bakanlığı). Pour toutes ces organisations, la conformité à WCAG 2.5.8 n’est pas simplement une recommandation de bonne pratique — c’est une obligation réglementaire liée à la possibilité d’afficher le Logo d’accessibilité et de démontrer la conformité légale lors des audits.

Concrètement, cela signifie que l’application web responsive d’une banque turque doit s’assurer que ses boutons de confirmation de virement, ses champs de saisie de mots de passe à usage unique et ses contrôles de navigation respectent tous la taille minimale de cible de 24×24 pixels CSS. De même, un site de e-commerce doit vérifier que ses boutons d’ajout au panier, ses sélecteurs de quantité et ses contrôles de filtrage sont correctement dimensionnés sur tous les profils d’appareils. Les portails de santé doivent auditer les calendriers de prise de rendez-vous, qui sont notoirement composés de petites cellules de dates, et soit agrandir ces cellules, soit fournir un espacement de décalage suffisant. Les portails en libre-service des opérateurs télécoms doivent vérifier que leurs liens de gestion de compte et les contrôles à bascule dans les sélecteurs de forfaits de données respectent le seuil.

Le non-respect de la Circulaire peut entraîner des sanctions administratives et peut empêcher une organisation d’afficher le Logo d’accessibilité, qui est de plus en plus utilisé comme signal de confiance par les consommatrices et consommateurs turcs. Au-delà des sanctions, la non-conformité expose les organisations à des plaintes déposées auprès des autorités de contrôle compétentes. Étant donné que la Turquie compte une population de personnes âgées en croissance — l’Institut turc de statistique prévoit que les personnes âgées de 65 ans et plus représenteront 16.3% de la population d’ici 2040 — l’impact pratique des petites cibles ne fera qu’augmenter avec le temps, faisant de la conformité précoce à la fois une priorité éthique et une stratégie commerciale solide à long terme.