WCAG 2.5.5 : Taille de la cible (améliorée)

Ce que signifie cette règle

WCAG 2.5.5 Target Size (Enhanced) est un critère de niveau AAA dans WCAG 2.2 qui définit une taille minimale stricte pour les éléments interactifs. Plus précisément, il exige que la taille de la cible — la zone cliquable ou tappable de tout composant d’interface utilisateur — soit d’au moins 44 par 44 pixels CSS en largeur comme en hauteur. Cela s’applique à toutes les interactions basées sur un pointeur, y compris les clics de souris, les tapotements sur écran tactile et l’utilisation d’un stylet.

Il est important de comprendre ce qui constitue exactement la « cible » dans ce contexte. La cible est l’ensemble de la zone activable du contrôle, et non seulement sa représentation visuelle. Une petite icône peut être visuellement de 16×16 pixels, mais si le padding environnant étend la zone cliquable à 44×44 pixels, le critère peut tout de même être satisfait. Cela signifie que les développeurs peuvent utiliser le padding de manière stratégique pour répondre à l’exigence sans modifier radicalement le design visuel.

Le critère définit une réussite comme tout élément interactif dont la zone cible mesure au moins 44×44 pixels CSS. Un échec se produit lorsque la zone activable d’un élément interactif est inférieure à ce seuil dans l’une ou l’autre dimension — par exemple, un lien qui fait 44 pixels de large mais seulement 20 pixels de haut échouerait tout de même.

WCAG 2.5.5 prévoit plusieurs exceptions officielles où l’exigence de 44×44 ne s’applique pas. Ce sont :

• Espacement : Des cibles sous-dimensionnées sont acceptables si un espacement suffisant les sépare de toutes les autres cibles. La cible doit être positionnée de sorte que, si un cercle de 44×44 pixels CSS était centré sur elle, ce cercle n’intersecterait aucune autre cible ni la boîte englobante du cercle de 44×44 de toute autre cible. Cette exception évite que la règle n’impose des changements de mise en page lorsque des contrôles adjacents sont intrinsèquement petits mais bien séparés.
• Équivalent : Un contrôle alternatif sur la même page remplit la même fonction et respecte l’exigence de taille minimale.
• En ligne : La cible se trouve dans une phrase ou sa taille est autrement contrainte par l’interligne du texte non cible. Les hyperliens au sein d’un paragraphe de texte courant, par exemple, sont exemptés car leur redimensionnement perturberait le flux du texte.
• Contrôle de l’agent utilisateur : La taille est entièrement déterminée par le navigateur ou le système d’exploitation et ne peut pas être modifiée par l’auteur. Les contrôles de formulaire natifs du navigateur dans leur état non stylé peuvent entrer dans cette catégorie.
• Essentiel : Une présentation particulière de la cible est essentielle à l’information transmise. Il s’agit d’une exception étroite pour les cas où modifier la taille de la cible altérerait fondamentalement le sens ou la fonctionnalité.

Ce critère a été introduit dans WCAG 2.2 et remplace les recommandations antérieures, moins strictes, concernant les cibles de pointeur. Son critère compagnon, WCAG 2.5.8 Target Size (Minimum) au niveau AA, fixe un seuil plus bas de 24×24 pixels CSS avec un calcul basé sur l’espacement, mais 2.5.5 reste la référence en matière d’accessibilité renforcée.

Pourquoi c’est important

Les troubles moteurs et de dextérité affectent une part importante de la population mondiale. Selon l’Organisation mondiale de la Santé, environ 1,3 milliard de personnes — soit 16 % de la population mondiale — vivent avec une forme de handicap significatif, les affections motrices et musculosquelettiques étant parmi les plus répandues. Des pathologies telles que la maladie de Parkinson, le tremblement essentiel, la paralysie cérébrale, la sclérose en plaques, l’hémiplégie post-AVC et les troubles musculo-squelettiques liés aux gestes répétitifs réduisent toutes la capacité d’une personne à effectuer des mouvements précis avec un pointeur. Sur les appareils mobiles, même les personnes sans handicap peuvent avoir des difficultés avec de petites cibles lorsqu’elles portent des gants, lorsque leurs mains sont mouillées ou simplement lorsqu’elles utilisent un téléphone à une main.

Considérons un scénario concret du monde réel : une personne atteinte de polyarthrite rhumatoïde navigue sur une plateforme de e-commerce turque sur une tablette tactile pour acheter des médicaments. Le flux de paiement comprend de petits boutons radio, des menus déroulants étroits et un bouton « Confirmer la commande » de 24×18 pixels. Chaque mauvais tapotement sélectionne soit la mauvaise option, soit ne fait rien, obligeant l’utilisateur à réessayer plusieurs fois. La frustration n’est pas simplement un désagrément — elle peut l’amener à abandonner complètement l’achat, transformant un échec d’accessibilité en perte de revenus directe pour l’entreprise.

Au-delà des troubles moteurs, des cibles de taille adéquate bénéficient à un large éventail d’utilisateurs. Les personnes âgées présentent fréquemment une diminution simultanée de la motricité fine et de l’acuité visuelle, ce qui rend les petites cibles doublement difficiles. Les personnes ayant des handicaps cognitifs peuvent mettre plus de temps à positionner un pointeur et sont plus susceptibles de déclencher des contrôles adjacents si les cibles sont trop rapprochées. Même les utilisateurs voyants et valides bénéficient de cibles plus grandes sur les appareils mobiles — une réalité qui a façonné les conventions de design des grandes entreprises technologiques depuis des années. Les Human Interface Guidelines d’Apple recommandent une cible de tapotement minimale de 44×44 points, et les directives Material Design de Google recommandent au moins 48×48 pixels indépendants de la densité pour les mêmes raisons.

Du point de vue du SEO et de l’ergonomie, la métrique « Interaction to Next Paint » (INP) des Core Web Vitals de Google valorise les interfaces où les interactions utilisateur sont enregistrées rapidement et correctement. Les mauvais tapotements causés par des cibles sous-dimensionnées augmentent les taux d’échec d’interaction, allongent le temps nécessaire pour accomplir une tâche et augmentent les taux de rebond — autant de signaux qui peuvent affecter indirectement le classement dans les résultats de recherche. Les améliorations d’accessibilité au niveau des cibles de pointeur ont donc des conséquences commerciales mesurables au-delà de la conformité.

Règles Axe-core associées

WCAG 2.5.5 nécessite des tests manuels. Il n’existe aucune règle axe-core entièrement automatisée qui signale de manière fiable toutes les violations de taille de cible pour ce critère renforcé. Les raisons pour lesquelles les outils automatisés peinent dans ce domaine sont multiples : la taille effective de la cible dépend de la mise en page CSS calculée, y compris le padding, la marge et les dimensions des pseudo-éléments, qui varient selon la fenêtre d’affichage, le ratio de pixels de l’appareil et le rendu dynamique. De plus, l’exception d’espacement nécessite de calculer l’écart géométrique entre les cibles adjacentes — un calcul qui requiert l’arbre de mise en page rendu complet et une analyse de proximité que les outils automatisés basés sur le parsing du DOM ne peuvent pas effectuer avec précision dans tous les cas. En outre, déterminer si un élément relève de l’exception « en ligne » ou « équivalent » nécessite une compréhension sémantique et contextuelle qui dépasse les capacités des moteurs de règles automatisées.

• target-size (axe-core experimental) : Axe-core inclut une règle expérimentale nommée target-size qui vérifie les éléments interactifs par rapport au seuil WCAG 2.5.8 de niveau AA de 24×24 pixels CSS avec des offsets d’espacement. Bien que cette règle puisse faire ressortir certaines violations plus modestes, elle n’applique pas le seuil plus strict de 44×44 exigé par 2.5.5, et elle peut manquer des violations lorsque le padding ou les pseudo-éléments affectent la zone de clic rendue d’une manière que le snapshot du DOM ne capture pas. Considérez tout résultat de cette règle comme un point de départ, et non comme un audit complet.
• Inspection visuelle manuelle : Comme aucune règle automatisée ne couvre entièrement 2.5.5, les testeurs doivent inspecter visuellement et mesurer les cibles interactives à l’aide des outils de développement du navigateur, de règles en pixels CSS ou d’extensions de navigateur dédiées à l’accessibilité. Cela inclut la vérification que le padding est inclus dans la zone de clic et que les exceptions d’espacement sont réellement respectées — et non simplement supposées.

Comment tester

1. Exécuter un scan automatisé comme base : Ouvrez axe DevTools ou Lighthouse dans Chrome DevTools sur la page à tester. Dans axe DevTools, filtrez les résultats par « target-size » si disponible dans les règles expérimentales. Notez les éléments signalés, mais gardez à l’esprit que ce scan ne détectera pas toutes les violations de 2.5.5 et peut se référer au seuil 2.5.8 plutôt qu’aux 44×44 pixels. Utilisez l’audit d’accessibilité de Lighthouse pour rechercher des avertissements liés aux cibles de pointeur.
2. Mesurer les tailles de cible avec les DevTools du navigateur : Ouvrez les DevTools de Chrome ou Firefox et utilisez le panneau Éléments pour inspecter chaque élément interactif — boutons, liens, champs de formulaire, cases à cocher, boutons radio, contrôles personnalisés et contrôles composés uniquement d’icônes. Dans le panneau des styles calculés, vérifiez la largeur et la hauteur rendues. N’oubliez pas que le padding est inclus dans la cible de clic pour les éléments de type bloc mais peut ne pas l’être pour les éléments en ligne. Vérifiez que la zone de clic calculée est d’au moins 44×44 pixels CSS.
3. Utiliser les outils d’accessibilité intégrés au navigateur : Dans Chrome DevTools, ouvrez l’onglet Rendering et activez « Emulate a focused page » ou utilisez l’Accessibility Tree pour inspecter les éléments. Pour Firefox, utilisez l’Accessibility Inspector pour identifier les éléments interactifs et recouper leurs dimensions de boîte englobante.
4. Tester sur de vrais appareils tactiles : Connectez un appareil iOS physique et testez avec VoiceOver activé (triple pression sur le bouton latéral pour l’activer). Naviguez en tapotant et utilisez le rotor pour vous déplacer entre les éléments interactifs. Essayez d’activer les petites cibles et notez la fréquence à laquelle des éléments adjacents sont déclenchés par erreur. Répétez sur un appareil Android en utilisant TalkBack (balayez vers la droite pour naviguer, double-tapez pour activer). Portez une attention particulière aux widgets personnalisés construits à partir d’éléments <div> ou <span>.
5. Tester manuellement les exceptions d’espacement : Pour toute cible plus petite que 44×44 pixels qui revendique l’exception d’espacement, dessinez une boîte englobante imaginaire de 44×44 pixels centrée sur cette cible et confirmez visuellement qu’aucun autre élément interactif ne se trouve dans cette boîte. Des extensions de navigateur ou des outils de superposition qui dessinent des boîtes englobantes peuvent aider.
6. Vérification au clavier et avec lecteur d’écran : Testez avec NVDA + Firefox et JAWS + Chrome en parcourant tous les éléments interactifs avec la touche Tab. Bien que le focus clavier ne teste pas directement la taille des cibles de pointeur, il permet de vérifier que tous les contrôles sont atteignables et de confirmer l’inventaire des éléments par rapport auquel vous recouperez les tailles de cible. VoiceOver + Safari sur macOS peut être utilisé pour vérifier que les contrôles personnalisés s’annoncent correctement et disposent de zones d’activation adéquates lors des clics de pointeur.
7. Tester à plusieurs tailles de fenêtre d’affichage : Les tailles de cible peuvent varier entre les mises en page desktop et mobile. Testez avec des largeurs de fenêtre d’affichage de 320px, 768px et 1280px pour confirmer que les designs responsives maintiennent le minimum de 44×44 à tous les points de rupture, en particulier dans les menus hamburger, les carrousels et les colonnes d’actions des tableaux de données.

Comment corriger

Bouton composé uniquement d’une icône avec taille insuffisante — Incorrect

<!-- A close button rendered as a small SVG icon with no padding.
     The rendered size is approximately 16x16 CSS pixels, far below the 44x44 minimum. -->
<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>

Bouton composé uniquement d’une icône avec taille insuffisante — Correct

<!-- Padding is added to expand the hit area to at least 44x44 CSS pixels
     while preserving the visual icon size. The button itself has explicit
     min-width and min-height to guarantee compliance across browsers. -->
<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 icon + 14px * 2 padding = 44px total hit area */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

Case à cocher personnalisée construite à partir d’un div — Incorrect

<!-- A visually styled custom checkbox that is too small to meet the target size
     requirement. The div has no padding and renders at 20x20 pixels. -->
<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>

Case à cocher personnalisée construite à partir d’un div — Correct

<!-- The visual box remains 20x20 pixels but is wrapped in a label element
     whose total clickable area is expanded to 44x44 via padding.
     Using a native input element is strongly preferred over role=checkbox
     because it provides built-in keyboard and pointer behavior. -->
<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; /* entire label row is at least 44px tall */
  cursor: pointer;
  padding: 12px 0; /* vertical padding expands the hit area */
}
.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>

Liens de navigation dans une barre d’outils avec espacement serré — Incorrect

<!-- Toolbar links rendered as small inline elements.
     Each link is approximately 32px wide and 24px tall,
     and they are spaced only 4px apart — failing both size and spacing exceptions. -->
<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>

Liens de navigation dans une barre d’outils avec espacement serré — Correct

<!-- Each link now has padding that expands its hit area to at least 44x44 px.
     The gap between links is also increased so the spacing exception would
     apply even if sizing were relaxed in future. -->
<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; /* horizontal padding extends width well past 44px */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

Erreurs courantes

• Supposer que la boîte englobante visuelle équivaut à la zone de clic : Définir width: 44px; height: 44px sur l’image d’icône à l’intérieur d’un bouton ne rend pas le bouton de 44×44 — seules ces dimensions appliquées au <button> lui-même ou un padding équivalent créent la bonne zone de clic.
• Utiliser padding: 0 pour réinitialiser les styles du navigateur sans taille minimale compensatoire : Les resets CSS suppriment souvent tout le padding des boutons et des champs de formulaire. Après un reset, réappliquez toujours un padding suffisant ou des valeurs explicites de min-width et min-height pour restaurer la zone d’activation.
• Se fier uniquement à line-height pour augmenter la hauteur de la cible : Augmenter line-height affecte l’espacement du texte mais n’agrandit pas toujours la zone cliquable d’un lien ou d’un bouton. Utilisez plutôt padding-top et padding-bottom.
• Placer plusieurs petits boutons d’icône côte à côte sans espacement suffisant : Une rangée d’icônes de partage sur les réseaux sociaux de 24×24 avec seulement 2px de marge ne respecte ni l’exigence de taille ni l’exception d’espacement, car les cercles de 44px centrés sur chaque icône se chevaucheraient.
• Mal appliquer l’exception de texte en ligne aux liens de navigation : L’exception s’applique aux liens au sein d’une phrase ou d’un paragraphe de texte continu. Les menus de navigation, barres d’outils et listes de liens ne sont pas du texte en ligne et ne relèvent pas de cette exception, même s’ils utilisent display: inline.
• Construire des contrôles personnalisés avec role='button' sur un <span> et oublier de dimensionner le span : Les lecteurs d’écran annonceront le span comme un bouton, mais sa taille rendue par défaut sera déterminée uniquement par son contenu textuel, généralement bien en dessous de 44×44 pixels. Ajoutez toujours display: inline-flex, min-width, min-height et padding.
• Ne pas tester sur de vrais appareils tactiles à la taille réelle de la fenêtre d’affichage : Mesurer les pixels dans les DevTools desktop ne suffit pas. La densité de pixels CSS et le comportement de détection des cibles tactiles au niveau du système d’exploitation peuvent différer entre les environnements simulés et les appareils physiques.
• Ignorer les contrôles rendus dynamiquement : Les info-bulles, les cellules de jour des sélecteurs de date, les éléments de suggestion d’autocomplétion et les boutons de fermeture de modale sont souvent injectés par des bibliothèques JavaScript avec des tailles petites codées en dur. Auditez la sortie des widgets tiers et surchargez leurs styles si nécessaire.
• Revendiquer l’exception d’espacement sans la mesurer : L’exception d’espacement est géométrique et précise. Supposer visuellement que les contrôles semblent suffisamment éloignés ne suffit pas — le test du cercle de 44px doit être appliqué à chaque cible sous-dimensionnée pour confirmer l’absence de chevauchement.
• Oublier de vérifier après des changements de points de rupture responsives : Un bouton qui fait 44×44 sur desktop peut se réduire à 30×30 sur une fenêtre d’affichage mobile de 375px en raison de largeurs en pourcentage ou de rétrécissement flexbox. Re-testez toujours les tailles de cible à chaque point de rupture majeur.

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

La Circulaire présidentielle n° 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires d’accessibilité web et mobile basées sur la norme WCAG 2.2. La circulaire s’applique à un ensemble défini d’entités opérant en Turquie et fixe des obligations légales de conformité à des niveaux spécifiques de WCAG.

Les types d’entités couvertes par la circulaire incluent : les institutions et organismes publics aux niveaux de l’administration centrale et locale ; les banques et institutions financières réglementées par l’Agence de régulation et de supervision bancaire (BDDK) ; les hôpitaux et prestataires de soins de santé, publics et privés ; les opérateurs de télécommunications comptant 200,000 abonnés ou plus ; les plateformes de e-commerce dépassant certains seuils de revenus ou de transactions ; les agences de voyage proposant des services de réservation en ligne ; les entreprises de transport privées offrant une billetterie ou des réservations numériques ; et les écoles privées et établissements d’enseignement autorisés par le ministère de l’Éducation nationale (MoNE).

WCAG 2.5.5 Target Size (Enhanced) est un critère de niveau AAA et ne fait pas partie des exigences minimales obligatoires établies par la circulaire, qui se concentre principalement sur la conformité aux niveaux A et AA. Cependant, la circulaire encourage explicitement les entités couvertes — en particulier celles qui servent le public, les patients et les élèves — à viser la conformité AAA lorsque cela est possible, reconnaissant qu’elle représente une pratique d’accessibilité de premier ordre.

Pour les organisations en Turquie, la mise en œuvre de WCAG 2.5.5 revêt une valeur stratégique particulière dans plusieurs contextes. Les portails gouvernementaux destinés aux personnes âgées, les systèmes de prise de rendez-vous médicaux utilisés par des patients atteints de maladies chroniques et les applications bancaires consultées par des personnes ayant des troubles moteurs bénéficient tous considérablement de cibles de 44×44 pixels. La Turquie connaît un vieillissement rapide de sa population, et l’Institut turc de statistique (TÜİK) prévoit que les citoyens âgés de 65 ans et plus représenteront plus de 16 % de la population d’ici 2040 — une tranche démographique pour laquelle la taille des cibles de pointeur est un facteur d’ergonomie critique.

Même lorsque le niveau AAA n’est pas légalement obligatoire, les organisations qui respectent volontairement WCAG 2.5.5 démontrent un engagement qui peut réduire le risque de contentieux, renforcer leur éligibilité dans les marchés publics exigeant une documentation d’accessibilité et améliorer les indicateurs de satisfaction utilisateur dans des marchés concurrentiels tels que le e-commerce et la fintech. Le SDK d’Accsible fournit des fonctionnalités configurables d’optimisation des cibles tactiles qui peuvent aider les organisations à atteindre ou à approcher ce critère, et la documentation de ces efforts peut faire partie d’un Accessibility Conformance Report (ACR) ou d’une soumission VPAT exigée par les processus d’achat institutionnels.