WCAG 1.4.10 : Réagencement

Ce que signifie cette règle

WCAG 1.4.10 Reflow est un critère de succès de niveau AA introduit dans WCAG 2.1 et repris dans WCAG 2.2. Il précise que le contenu web doit pouvoir se reflow — c’est‑à‑dire se réorganiser et se redimensionner — de façon à rester entièrement utilisable avec une largeur de fenêtre d’affichage équivalente à 320 pixels CSS, sans obliger l’utilisateur à faire défiler horizontalement pour lire ou interagir avec le contenu. Le point de référence de 320 pixels CSS correspond à ce qu’un utilisateur voit lorsqu’il règle le niveau de zoom de son navigateur à 400 % sur un écran standard de 1280 px de large.

L’exigence centrale est qu’aucune perte d’information ou de fonctionnalité ne se produise à cette largeur contrainte. Tout le texte doit rester lisible, tous les contrôles interactifs doivent rester opérables, et tout le contenu significatif doit rester visible sans déclencher de défilement bidimensionnel. Le défilement vertical est autorisé — le critère interdit uniquement le défilement horizontal pour le contenu qui s’écoule verticalement (et le défilement vertical pour le contenu qui s’écoule horizontalement, bien que cela soit rare). Une mise en page qui oblige les utilisateurs à faire défiler simultanément de haut en bas et de gauche à droite pour lire un paragraphe de texte échouerait à ce critère.

Le W3C définit des exceptions explicites où le défilement bidimensionnel est acceptable. Celles‑ci incluent le contenu pour lequel une mise en page bidimensionnelle est essentielle à son utilisation et à sa signification : grands tableaux de données avec de nombreuses colonnes, cartes complexes et diagrammes géographiques, lecteurs vidéo et leurs contrôles de lecture, barres d’outils avec plusieurs boutons d’action disposés côte à côte, et jeux ou diagrammes interactifs qui nécessitent une relation spatiale précise entre les éléments. Ces exceptions doivent être interprétées de manière restrictive — l’exemption s’applique au contenu lui‑même (par exemple, les cellules d’un tableau de données), et non à la navigation, aux titres ou au texte explicatif qui l’accompagnent.

Une page réussit ce critère si : lorsque le navigateur est zoomé à 400 % (ou que la fenêtre d’affichage est réglée sur 320 px de large), le contenu se reflow en une seule colonne, la navigation se replie ou se superpose de manière appropriée, les images se redimensionnent proportionnellement, et l’utilisateur peut accomplir tout ce qu’il pouvait faire au niveau de zoom par défaut en utilisant uniquement le défilement vertical. Une page échoue si un défilement horizontal est nécessaire pour lire des phrases, atteindre des boutons ou accéder à tout contenu non exempté.

Pourquoi c’est important

Environ 2,2 milliards de personnes dans le monde vivent avec une forme de déficience visuelle, selon l’Organisation mondiale de la santé. Une proportion significative de ces personnes s’appuie sur le zoom du navigateur, la loupe du système d’exploitation ou des logiciels dédiés d’agrandissement d’écran (tels que ZoomText ou Windows Magnifier) pour rendre le texte et les éléments d’interface suffisamment grands pour être perçus confortablement. Lorsqu’une mise en page se casse à des niveaux de zoom élevés — forçant le contenu hors de l’écran ou nécessitant un défilement horizontal — ces utilisateurs sont confrontés à une expérience de lecture fragmentée où chaque phrase exige un mouvement de panoramique d’avant en arrière. Ce n’est pas simplement gênant ; cela peut rendre un contenu complexe pratiquement inaccessible.

Considérons un utilisateur de 65 ans atteint de dégénérescence maculaire liée à l’âge qui consulte le portail de prise de rendez‑vous d’un hôpital turc avec son navigateur réglé sur un zoom de 300 %. Si le formulaire de réservation s’affiche avec des colonnes de largeur fixe, le bouton « Submit » peut être entièrement repoussé au‑delà du bord droit de la zone visible. L’utilisateur n’a aucun moyen de savoir que le bouton existe, encore moins d’interagir avec lui. Il ne peut pas prendre son rendez‑vous de manière autonome. Il s’agit d’un préjudice direct et concret causé par le non‑respect de Reflow.

Au‑delà des utilisateurs malvoyants, Reflow bénéficie à un large éventail de personnes. Les utilisateurs ayant des déficiences motrices qui utilisent un accès par contacteur ou des dispositifs de suivi de la tête trouvent le défilement horizontal extrêmement difficile, voire impossible à effectuer de manière fiable. Le handicap cognitif touche une part importante de la population, et la recherche montre de manière constante que les mises en page étroites à une seule colonne — typiques d’un Reflow bien implémenté — réduisent la charge cognitive et améliorent la compréhension en lecture. Les personnes utilisant des appareils à petit écran ou lisant en mode écran partagé en bénéficient également directement, même sans handicap.

D’un point de vue technique et commercial, une mise en œuvre correcte de Reflow recoupe presque entièrement la création d’un design responsive bien structuré. Cela signifie que la conformité à 1.4.10 améliore naturellement l’ergonomie mobile, réduit les taux de rebond et contribue positivement aux indicateurs Core Web Vitals qui influencent le classement dans les moteurs de recherche. Pour les plateformes de e‑commerce turques en particulier, où le trafic mobile domine, la conformité à Reflow et l’optimisation commerciale pour le mobile poursuivent essentiellement le même objectif.

Règles axe-core associées

WCAG 1.4.10 Reflow nécessite un test manuel plutôt qu’une analyse automatisée. Aucune règle axe-core ne peut automatiser entièrement la détection des échecs de Reflow, car le critère dépend du comportement visuel et fonctionnel de l’ensemble d’une mise en page rendue à une taille de fenêtre d’affichage spécifique — ce qui requiert un véritable environnement de navigateur, un jugement humain sur la possibilité de défilement et une vérification qu’aucune information n’a été perdue. Les outils automatisés ne peuvent pas distinguer de manière fiable entre un défilement bidimensionnel intentionnel (pour une carte ou un tableau exempté) et un débordement de mise en page non intentionnel causé par un conteneur de largeur fixe.

• Test manuel — largeur de fenêtre de 320 px : Redimensionnez la fenêtre d’affichage du navigateur à exactement 320 pixels CSS de large (ou zoomez à 400 % sur un écran de 1280 px de large) et faites défiler verticalement chaque gabarit de page, état d’écran et composant interactif. Vérifiez qu’aucun contenu n’est rogné, qu’aucune barre de défilement horizontale n’apparaît pour le contenu non exempté, et que toute la fonctionnalité reste accessible. Axe DevTools signalera cela comme un élément « Needs Review » plutôt qu’une violation automatique, car l’analyse de mise en page par outil ne peut pas déterminer si un débordement représente un véritable échec ou relève d’une exemption.
• Signal partiel automatisé — vérification de la balise meta viewport : Axe-core peut détecter si la page utilise une balise meta name='viewport' avec user-scalable=no ou maximum-scale=1, qui empêchent toutes deux les utilisateurs de zoomer et rendent donc impossible d’atteindre l’état de zoom à 400 % visé par Reflow. Bien qu’il s’agisse techniquement d’un problème distinct (WCAG 1.4.4), il est étroitement lié et sa présence garantit un échec de Reflow. Axe signale cela sous la règle meta-viewport. Toute page qui bloque le zoom bloque également, par définition, la conformité à Reflow.
• Audit manuel des composants : Au‑delà de la mise en page de page entière, des composants individuels tels que les carrousels, en‑têtes fixes, boîtes de dialogue modales, widgets de chat flottants, bannières de cookies et tableaux de données nécessitent chacun une vérification individuelle à 320 px. Un en‑tête de page peut se reflow correctement tandis qu’une fenêtre modale promotionnelle s’affiche avec une largeur fixe de 600 px et un bouton de fermeture inaccessible — un échec qu’une revue manuelle composant par composant seule permettra de détecter.

Comment tester

1. Pré‑analyse automatisée : Exécutez axe DevTools ou Lighthouse dans Chrome DevTools sur chaque page. Recherchez spécifiquement la violation meta-viewport, qui indique que le zoom est bloqué et garantit un échec de Reflow. Notez également tout avertissement lié au débordement signalé sous « Needs Review ». Enregistrez les résultats, mais gardez à l’esprit qu’une analyse automatisée sans problème ne confirme pas la conformité à Reflow — des étapes manuelles sont obligatoires.
2. Régler la fenêtre d’affichage sur 320 px : Dans Chrome ou Firefox DevTools, ouvrez la barre d’outils des appareils (Ctrl+Shift+M / Cmd+Shift+M), saisissez une taille d’appareil personnalisée de 320×568 pixels (ou toute autre hauteur) et définissez le ratio de pixels de l’appareil sur 1. Vous pouvez aussi ouvrir une fenêtre de navigateur de 1280 px de large et zoomer à 400 % en utilisant Ctrl+= (Cmd+= sur Mac). Les deux méthodes simulent la condition de 320 pixels CSS spécifiée par WCAG.
3. Faire défiler verticalement toute la page : En partant du haut de la page, faites défiler vers le bas uniquement à l’aide de la barre de défilement verticale ou de la molette de la souris. À aucun moment une barre de défilement horizontale ne doit apparaître pour le contenu non exempté. Si c’est le cas, la page échoue. Confirmez que tout le texte est entièrement lisible — aucune phrase n’est coupée, aucun caractère n’est rogné par le bord de la fenêtre d’affichage.
4. Tester toute la fonctionnalité interactive : À une largeur de 320 px, tentez d’accomplir chaque tâche utilisateur clé : remplir et soumettre des formulaires, ouvrir les menus de navigation, activer les modales et boîtes de dialogue, utiliser les accordéons et onglets, interagir avec les carrousels et déclencher tout contenu dynamique. Chaque contrôle doit être atteignable et opérable en utilisant uniquement le défilement vertical et une interaction normale.
5. Vérifier tous les gabarits et états de page : Testez la page d’accueil, les pages de contenu internes, les formulaires, les parcours de paiement, les états d’erreur et toute vue authentifiée. Une navigation responsive qui se replie correctement sur la page d’accueil peut tout de même se casser sur une page produit très imbriquée avec un gabarit différent.
6. Association avec un lecteur d’écran (supplémentaire) : Utilisez NVDA avec Firefox ou VoiceOver avec Safari à une largeur de 320 px pour confirmer que l’ordre et la signification du contenu sont préservés après reflow. Parfois, un reflow basé sur le CSS modifie l’ordre visuel sans changer l’ordre du DOM, rendant les annonces du lecteur d’écran confuses. Ce n’est pas à proprement parler un test de Reflow, mais cela permet de détecter des implémentations de reflow qui créent d’autres problèmes d’accessibilité.
7. Documenter les exemptions : Pour tout contenu qui nécessite un défilement horizontal (tableaux de données, cartes, blocs de code), vérifiez et documentez qu’il relève réellement d’une exception définie par WCAG. Confirmez que le contenu environnant de la page (titres, instructions, navigation) se reflow toujours correctement même si le composant intégré ne le fait pas.

Comment corriger

Conteneur à largeur fixe qui casse la mise en page — Incorrect

<!-- Fixed pixel width forces horizontal scrolling at small viewports -->
<div style='width: 960px; margin: 0 auto;'>
  <p>This content will overflow a 320px viewport and require horizontal scrolling.</p>
  <button>Submit Application</button>
</div>

Conteneur à largeur fixe qui casse la mise en page — Correct

<!-- Use max-width with 100% so container never exceeds its parent but shrinks on small screens -->
<div class='content-wrapper'>
  <p>This content reflows naturally at any viewport width.</p>
  <button>Submit Application</button>
</div>

<!-- In your CSS (external stylesheet) -->
<!-- .content-wrapper { max-width: 960px; width: 100%; margin: 0 auto; box-sizing: border-box; padding: 0 1rem; } -->

Balise meta viewport qui bloque le zoom — Incorrect

<!-- This prevents users from zooming at all, making Reflow impossible to achieve -->
<meta name='viewport' content='width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no'>

Balise meta viewport qui bloque le zoom — Correct

<!-- Allow zooming by removing maximum-scale and user-scalable restrictions -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!-- Users can now zoom to 400% and content will reflow as required by WCAG 1.4.10 -->

Barre de navigation horizontale qui déborde — Incorrect

<!-- Navigation items forced into a single row with no wrapping or collapse mechanism -->
<nav aria-label='Primary navigation'>
  <ul style='display: flex; flex-wrap: nowrap; white-space: nowrap;'>
    <li><a href='/home'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About Us</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/blog'>Blog</a></li>
    <li><a href='/support'>Support</a></li>
  </ul>
</nav>

Barre de navigation horizontale qui déborde — Correct

<!-- Hamburger/disclosure pattern for small viewports; full navigation accessible at all sizes -->
<nav aria-label='Primary navigation'>
  <button aria-expanded='false' aria-controls='nav-menu' id='nav-toggle'>
    Menu
  </button>
  <ul id='nav-menu'>
    <li><a href='/home'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About Us</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/blog'>Blog</a></li>
    <li><a href='/support'>Support</a></li>
  </ul>
</nav>
<!-- CSS media query hides #nav-menu by default below a breakpoint and shows it on toggle -->
<!-- The button is hidden above the breakpoint where the full nav is always visible -->

Tableau de données sans prise en charge du reflow — Incorrect

<!-- Wide table with no scroll container; overflows the viewport with no warning to users -->
<table>
  <caption>Quarterly Sales Data</caption>
  <thead>
    <tr>
      <th scope='col'>Region</th>
      <th scope='col'>Q1</th>
      <th scope='col'>Q2</th>
      <th scope='col'>Q3</th>
      <th scope='col'>Q4</th>
      <th scope='col'>Total</th>
    </tr>
  </thead>
</table>

Tableau de données sans prise en charge du reflow — Correct

<!-- Wrap the table in a scrollable container scoped to just the table element -->
<!-- This is an explicit WCAG 1.4.10 exception for complex data tables -->
<div role='region' aria-labelledby='table-caption' tabindex='0' class='table-scroll-container'>
  <table>
    <caption id='table-caption'>Quarterly Sales Data (scroll horizontally to view all columns)</caption>
    <thead>
      <tr>
        <th scope='col'>Region</th>
        <th scope='col'>Q1</th>
        <th scope='col'>Q2</th>
        <th scope='col'>Q3</th>
        <th scope='col'>Q4</th>
        <th scope='col'>Total</th>
      </tr>
    </thead>
  </table>
</div>
<!-- CSS: .table-scroll-container { overflow-x: auto; } -->
<!-- The caption warns users, role=region + aria-labelledby makes it keyboard-focusable -->

Erreurs courantes

• Utiliser overflow: hidden sur l’élément <body> ou un conteneur de plus haut niveau pour supprimer les barres de défilement horizontales sans corriger le débordement sous‑jacent : Cela masque la barre de défilement mais le contenu est toujours rogné et inaccessible, ce qui est sans doute pire qu’un débordement visible, car l’utilisateur n’a aucune indication qu’un contenu existe au‑delà du bord de la fenêtre d’affichage.
• Définir max-scale=1 ou user-scalable=no dans la balise meta viewport pour empêcher une mise en page mobile de « paraître cassée » à un zoom élevé : Cela désactive complètement la capacité de l’utilisateur à zoomer, ce qui constitue à la fois un échec de Reflow et une violation de WCAG 1.4.4 Resize Text.
• Appliquer white-space: nowrap aux conteneurs de texte, listes de navigation ou groupes de boutons sans remplacement spécifique à un breakpoint : Cela force le texte sur une seule ligne quel que soit l’espace disponible et constitue l’une des causes les plus fréquentes de débordement horizontal à 320 px.
• Utiliser des valeurs en pixels absolus dans les définitions CSS Grid grid-template-columns (par exemple, grid-template-columns: 300px 600px) sans solution de repli responsive : À 320 px, les deux colonnes totalisent 900 px et déborderont sans reflow, à moins qu’une media query ne remplace la définition par 1fr ou 100%.
• Intégrer des éléments <iframe> avec des attributs width et height fixes pointant vers du contenu tiers (cartes, vidéos, formulaires) : Les iframes ne se mettent pas automatiquement à l’échelle, de sorte qu’une carte intégrée de 600 px de large débordera une fenêtre d’affichage de 320 px. Enveloppez les iframes dans un conteneur qui préserve le ratio d’aspect et définissez l’iframe elle‑même avec width: 100%.
• Concevoir des boîtes de dialogue modales et des panneaux hors‑canvas avec une largeur minimale fixe supérieure à 320 px : Une modale avec min-width: 500px débordera et masquera probablement son bouton de fermeture hors de l’écran, piégeant les utilisateurs au clavier à l’intérieur de la boîte de dialogue à de petites largeurs de fenêtre d’affichage.
• Considérer les blocs de code et les éléments <pre> comme exemptés de Reflow sans les envelopper dans un conteneur défilant horizontalement : Les blocs de code bruts ne figurent pas parmi les exceptions WCAG. Bien que le contenu de code lui‑même puisse être complexe, la page environnante doit se reflow ; le bloc de code doit défiler indépendamment dans un conteneur avec overflow-x: auto, et ne doit pas provoquer un défilement horizontal de toute la page.
• Oublier de tester les états authentifiés et dynamiques : De nombreuses équipes testent uniquement la page d’accueil en mode déconnecté. Les tableaux de bord, pages de profil utilisateur, formulaires en plusieurs étapes et états d’erreur chargés via JavaScript sont fréquemment construits avec des hypothèses de largeur fixe et échouent à Reflow même lorsque les pages marketing réussissent.
• Utiliser la propriété CSS transform: scale() pour réduire visuellement le contenu plutôt que de mettre en œuvre un véritable design responsive : Le redimensionnement réduit la taille apparente mais ne provoque pas de reflow du contenu — le texte devient minuscule et illisible au lieu de se reflow en une colonne lisible, ce qui enfreint à la fois les critères Reflow et Resize Text.
• Supposer qu’un design responsive mobile réussit automatiquement Reflow : Le design responsive cible généralement des breakpoints à 360 px, 768 px et 1024 px. Le point de référence WCAG de 320 px est plus étroit que la plupart des breakpoints mobiles, ce qui signifie qu’un contenu qui semble correct sur un petit téléphone standard peut tout de même déborder à 320 px. Testez toujours à exactement 320 px, et non à une taille « mobile » générique.

Lien avec la réglementation turque en matière d’accessibilité

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 impose la conformité aux normes internationales d’accessibilité du web — WCAG 2.1 niveau AA servant de référence de base — pour les entités concernées. WCAG 2.2 niveau AA, qui intègre tous les critères de 2.1, y compris 1.4.10 Reflow, est fortement encouragé et constitue la norme requise pour obtenir le Erişilebilirlik Logosu (Logo d’accessibilité) délivré par le ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı).

Les types d’entités couvertes par la Circulaire présidentielle 2025/10 incluent les institutions publiques et organismes gouvernementaux à tous les niveaux, les banques et institutions financières, les hôpitaux et prestataires de soins de santé, les entreprises 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 (Millî Eğitim Bakanlığı). Pour chacun de ces secteurs, l’attente est que toutes les interfaces numériques destinées au public — sites web, applications web et contenu web mobile — soient accessibles aux personnes handicapées, y compris celles qui s’appuient sur le zoom et l’ajustement de la fenêtre d’affichage pour percevoir le contenu.

WCAG 1.4.10 Reflow est particulièrement pertinent dans le contexte turc pour plusieurs raisons. Premièrement, la pénétration d’Internet mobile en Turquie est exceptionnellement élevée, et une part importante des utilisateurs accède aux services gouvernementaux, portails bancaires et plateformes de e‑commerce via des navigateurs mobiles à des niveaux de zoom variables. Un système de prise de rendez‑vous hospitaliers qui ne respecte pas Reflow peut empêcher des patient·es âgé·es malvoyant·es de réserver des consultations de manière autonome — un échec direct à la fois de la législation sur l’accessibilité et de la mission de service public des institutions concernées. Deuxièmement, le programme Erişilebilirlik Logosu exige un audit de conformité couvrant tous les critères de succès de niveau AA ; échouer à 1.4.10 disqualifierait un site par ailleurs conforme de l’obtention du logo. Troisièmement, pour les entreprises de télécommunications ayant une large base d’abonnés, des portails en libre‑service et des interfaces de gestion de compte accessibles sont essentiels — un tableau de bord de compte à largeur fixe qui déborde à un zoom de 400 % porte directement préjudice aux abonnés ayant une déficience visuelle qui, autrement, n’auraient pas besoin de se rendre en boutique physique ou d’appeler une ligne d’assistance.

Les organisations qui cherchent à démontrer leur conformité au titre de la réglementation turque en matière d’accessibilité doivent s’assurer que leurs implémentations de design responsive sont spécifiquement validées au seuil de 320 pixels CSS, qu’aucune balise meta viewport ne bloque le zoom utilisateur, et que toute la fonctionnalité interactive — y compris les parcours d’authentification, la soumission de formulaires et le téléchargement de documents — reste entièrement opérable sans défilement horizontal. L’inclusion de tests Reflow dans un historique d’audit d’accessibilité documenté sera essentielle pour démontrer la conformité aux organismes de régulation et pour maintenir l’éligibilité au Erişilebilirlik Logosu.