POUR — Perceptible, Utilisable, Compréhensible, Robuste — sont les quatre principes fondamentaux qui sous-tendent chaque critère de succès des WCAG. Maîtrisez-les et vous disposerez d’un cadre clair et exploitable pour créer des sites web qui fonctionnent pour tout le monde, tout en restant en conformité avec la loi.

Imaginez passer des heures à peaufiner le design de votre site web, pour découvrir ensuite qu’une part significative de vos visiteurs ne peut tout simplement pas l’utiliser. C’est la réalité pour environ 1,3 milliard de personnes dans le monde — soit environ 16 % de la population mondiale — qui vivent avec une forme de handicap. Selon le rapport WebAIM Million 2025, 94,8 % des sites web présentent encore au moins une défaillance d’accessibilité détectable, la page d’accueil moyenne comportant plus de 51 erreurs d’accessibilité distinctes. La bonne nouvelle : il existe un cadre de référence solide qui coupe court au bruit et vous indique exactement à quoi doit ressembler un contenu web accessible. Il s’appelle POUR.

Qu’est-ce que POUR et d’où cela vient-il ?

POUR est l’acronyme des quatre principes fondamentaux qui sous-tendent les Web Content Accessibility Guidelines (WCAG) : Perceivable, Operable, Understandable et Robust. Publiées et maintenues par le World Wide Web Consortium (W3C) via son Web Accessibility Initiative (WAI), les WCAG constituent la référence internationale en matière d’accessibilité web. La version stable actuelle — WCAG 2.2 — organise l’ensemble de ses 13 lignes directrices et leurs dizaines de critères de succès testables selon ces quatre principes.

Considérez POUR comme une hiérarchie de questions à poser à tout contenu web. Les utilisateurs peuvent-ils réellement le détecter ? Peuvent-ils interagir avec lui ? Peuvent-ils lui donner du sens ? Et continuera-t-il à fonctionner à mesure que la technologie évolue ? Si la réponse à l’une de ces questions est non, une personne réelle est exclue de votre site à l’instant même. Ce n’est pas une hypothèse — c’est l’expérience quotidienne de millions d’utilisateurs de lecteurs d’écran, de personnes naviguant uniquement au clavier, de personnes avec des différences cognitives et d’utilisateurs d’anciennes technologies d’assistance.

Comprendre POUR va au-delà de l’obligation morale. Les lois et réglementations dans le monde — l’Americans with Disabilities Act (ADA) aux États-Unis, l’European Accessibility Act (EAA) dans l’UE, et l’Equality Act au Royaume-Uni — s’appuient sur les WCAG comme norme technique. Lorsqu’une entreprise fait face à un procès pour défaut d’accessibilité, la plainte est presque toujours traçable à la violation d’un ou plusieurs principes de POUR. Rien qu’en 2025, 5 114 actions en justice liées à l’accessibilité numérique au titre de l’ADA ont été intentées, les entreprises d’eCommerce étant le secteur le plus fréquemment visé. Connaître POUR revient, en pratique, à connaître votre exposition juridique.

Chaque principe se décline en lignes directrices — des objectifs généraux — qui elles-mêmes se déclinent en critères de succès spécifiques et testables, classés en niveau A (minimum), niveau AA (renforcé — la norme la plus largement exigée) et niveau AAA (avancé). Le reste de ce guide passe en revue chaque principe en détail, avec des exemples pratiques et des modèles de code que vous pouvez appliquer immédiatement.

Principe 1 : Perceivable — S’ils ne peuvent pas le détecter, cela n’existe pas

La spécification WCAG est claire : l’information et les composants de l’interface utilisateur doivent être présentables aux utilisateurs de manière à ce qu’ils puissent les percevoir. En d’autres termes, rien sur votre page ne peut être invisible à tous les sens d’un utilisateur simultanément. Un graphique qui transmet une information uniquement par la couleur est invisible pour une personne daltonienne. Une vidéo sans sous-titres est effectivement silencieuse pour une personne sourde. Une image décorative avec un texte alternatif verbeux fait perdre du temps à un utilisateur de lecteur d’écran. La perceptibilité consiste à s’assurer que chaque canal de communication dispose d’un recours pour les utilisateurs qui ne peuvent pas accéder à ce canal.

Les quatre lignes directrices WCAG sous Perceivable sont : alternatives textuelles, médias temporels, contenu adaptable et contenu distinguable. Les alternatives textuelles (Ligne directrice 1.1) exigent que chaque élément non textuel — images, icônes, graphiques, infographies, fichiers audio, vidéo — ait un équivalent textuel qui remplit la même fonction. Une image utilisée comme lien vers la page d’accueil doit avoir un texte alternatif du type « Retour à la page d’accueil », et non « logo.png » ou une chaîne vide. Les images décoratives, en revanche, doivent utiliser alt='' afin que les lecteurs d’écran les ignorent complètement, évitant ainsi le bruit inutile.

Les médias temporels (Ligne directrice 1.2) couvrent les sous-titres, les audiodescriptions et les transcriptions pour le contenu vidéo et audio. Les sous-titres synchronisés soutiennent les personnes sourdes ou malentendantes. Les audiodescriptions — une piste de narration décrivant l’action à l’écran — soutiennent les personnes aveugles. Les transcriptions servent les deux groupes et bénéficient également aux utilisateurs dans des environnements bruyants ou à ceux qui traitent plus facilement le texte écrit que l’audio.

Le contenu adaptable (Ligne directrice 1.3) signifie que votre contenu doit garder son sens lorsque sa présentation est retirée. Si un utilisateur voyant voit un champ obligatoire mis en évidence en rouge, un utilisateur de lecteur d’écran doit savoir qu’il est obligatoire via le balisage programmatique, et pas seulement par la couleur visuelle. Des instructions du type « cliquez sur le bouton vert à droite » échoueront complètement pour une personne aveugle. La règle est claire : les instructions ne peuvent pas reposer uniquement sur des caractéristiques sensorielles comme la forme, la couleur, la taille ou la position visuelle.

Le contenu distinguable (Ligne directrice 1.4) régit le contraste, le redimensionnement du texte et le contrôle audio. WCAG 2.2 niveau AA exige un ratio de contraste d’au moins 4,5:1 pour le texte normal et 3:1 pour le texte de grande taille. Le texte à faible contraste est la défaillance d’accessibilité la plus répandue sur le web : dans l’analyse WebAIM Million de février 2026, du texte à faible contraste a été trouvé sur 83,9 % des pages d’accueil, avec une moyenne de 34 occurrences distinctes par page. Le texte doit également rester lisible lorsqu’il est redimensionné jusqu’à 200 % sans perte de contenu ni de fonctionnalité, et aucun contenu ne doit perdre d’information lorsqu’il est affiché à 320 pixels CSS de large (critère Reflow, 1.4.10).

Les défaillances Perceivable les plus courantes — texte alternatif manquant, faible contraste de couleur et champs de formulaire non étiquetés — ne sont pas des problèmes d’ingénierie complexes. Ce sont des omissions quotidiennes qui peuvent généralement être corrigées en quelques minutes une fois que vous savez où regarder.

Voici une comparaison rapide entre un balisage d’image inaccessible et accessible :

<!-- Inaccessible: no alt attribute -->
<img src='product-chart.png'>

<!-- Accessible: descriptive alt text -->
<img src='product-chart.png' alt='Bar chart showing a 40% increase in Q3 revenue compared to Q2'>

<!-- Decorative image: tell assistive tech to skip it -->
<img src='divider-wave.png' alt='' role='presentation'>

Principe 2 : Operable — Chaque fonction doit fonctionner avec chaque méthode d’entrée

L’opérabilité concerne l’interaction. Les WCAG indiquent que les composants de l’interface utilisateur et la navigation doivent être opérables — ce qui signifie que l’interface ne peut pas exiger une interaction qu’un utilisateur ne peut pas effectuer. L’expression la plus claire de ce principe est l’accessibilité au clavier. De nombreux utilisateurs avec des handicaps moteurs, des troubles musculo-squelettiques ou la cécité s’appuient entièrement sur un clavier (ou une technologie d’assistance émulant un clavier, comme un contacteur, un contrôleur sip-and-puff ou un logiciel de commande vocale) pour naviguer sur le web. Si votre menu déroulant ne s’ouvre qu’au survol de la souris, ces utilisateurs sont exclus.

La Ligne directrice 2.1 exige que toutes les fonctionnalités soient disponibles au clavier. Cela signifie que chaque élément interactif — liens, boutons, contrôles de formulaire, widgets personnalisés, curseurs, sélecteurs de date, boîtes de dialogue modales — doit être accessible via la touche Tab et opérable via des commandes clavier. De manière cruciale, cela signifie aussi qu’il ne doit exister aucun piège au clavier : si le focus se déplace dans un composant comme une fenêtre modale, les utilisateurs doivent pouvoir en sortir en utilisant uniquement le clavier (généralement via la touche Échap). Un utilisateur piégé n’a d’autre recours que de fermer son navigateur.

Tout aussi importante est la visibilité du focus (Ligne directrice 2.4, Critère de succès 2.4.7). Les utilisateurs voyants qui naviguent au clavier doivent voir où se trouve le focus à tout moment. Supprimer le contour de focus par défaut du navigateur — une pratique devenue populaire pour des raisons esthétiques — est l’une des décisions les plus préjudiciables en matière d’accessibilité qu’un développeur puisse prendre. Lorsque le focus est invisible, un utilisateur au clavier navigue à l’aveugle. Si vous remplacez les styles de focus par défaut du navigateur, vous devez fournir une alternative visible avec un ratio de contraste d’au moins 3:1 par rapport à l’arrière-plan environnant.

<!-- Inaccessible: focus outline suppressed globally -->
* { outline: none; }

<!-- Accessible: custom visible focus style -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
  border-radius: 2px;
}

La Ligne directrice 2.2 traite du temps. Certains utilisateurs ont besoin de beaucoup plus de temps pour lire le contenu, remplir des formulaires ou répondre aux avertissements de fin de session. Pour toute limite de temps définie par votre contenu, les utilisateurs doivent pouvoir la désactiver, la prolonger (jusqu’à au moins 10 fois la valeur par défaut) ou être avertis avant son expiration et disposer d’au moins 20 secondes pour répondre par une action simple. Les carrousels à défilement automatique, les quiz chronométrés et les modales de fin de session sont des coupables fréquents.

La Ligne directrice 2.3 interdit le contenu qui clignote plus de trois fois par seconde, car ce type de contenu peut déclencher des crises photosensibles. La Ligne directrice 2.4 couvre la navigabilité — s’assurer que les utilisateurs peuvent trouver le contenu et savoir où ils se trouvent. Les exigences pratiques incluent un moyen de passer les blocs de navigation répétitifs (un lien « Passer au contenu principal » est l’implémentation la plus simple), des titres de page descriptifs, un ordre de focus logique, un texte de lien significatif (« Lire le rapport du T3 » plutôt que « cliquez ici ») et des indicateurs de focus visibles. WCAG 2.2 a également ajouté la Ligne directrice 2.5, qui couvre les modalités d’entrée : toute fonctionnalité utilisant des gestes multipoints ou basés sur un tracé (pincer pour zoomer, balayer) doit également être opérable avec un seul pointeur, et les cibles tactiles doivent respecter des dimensions minimales.

L’accessibilité au clavier n’est pas une préoccupation de niche. Les personnes aveugles, les utilisateurs avancés, les personnes avec des handicaps moteurs et toute personne dont le trackpad vient de tomber en panne en dépendent. Concevoir d’abord pour le clavier, c’est concevoir pour la résilience.

Principe 3 : Understandable — La clarté n’est pas optionnelle

Même si le contenu est perceptible et que chaque interaction est opérable, un utilisateur peut être complètement perdu si le contenu lui-même est déroutant. Le principe Understandable exige que l’information présentée et le fonctionnement de l’interface soient compréhensibles pour les utilisateurs. Ce principe est particulièrement important pour les personnes avec des handicaps cognitifs, des troubles de l’apprentissage, une faible littératie numérique, ou toute personne utilisant votre site dans une langue qui n’est pas sa langue maternelle.

La Ligne directrice 3.1 porte sur la lisibilité. L’exigence la plus fondamentale est que la langue de la page soit identifiée dans le code — via l’attribut lang sur l’élément <html>. Cet unique attribut permet aux lecteurs d’écran de basculer vers le moteur de prononciation approprié. Des déclarations de langue manquantes ont été trouvées sur 15,8 % des pages d’accueil dans les données WebAIM 2025, ce qui signifie que le lecteur d’écran peut prononcer une page en anglais avec un accent français (ou inversement) si la langue par défaut de l’utilisateur est différente. Lorsqu’une page change de langue en cours de contenu — ce qui est courant sur les sites multilingues — l’attribut lang doit être appliqué à l’élément concerné.

<!-- Page language declaration -->
<html lang='en'>

<!-- Inline language switch -->
<p>The phrase <span lang='fr'>joie de vivre</span> means joy of living.</p>

La Ligne directrice 3.2 porte sur la prévisibilité. Les pages et les composants doivent se comporter de manière cohérente et conforme aux attentes. Les menus de navigation doivent apparaître au même endroit et dans le même ordre sur l’ensemble des pages. Sélectionner une valeur dans une liste déroulante ne doit pas déclencher une navigation automatique sans avertissement — si vous avez besoin d’un comportement d’envoi automatique, les utilisateurs doivent en être informés. Les composants qui se ressemblent sur votre site (un bouton de fermeture uniquement par icône, un champ de recherche) doivent se comporter de la même manière. Les changements de contexte inattendus — un nouvel onglet qui s’ouvre sans avertissement, une page qui se rafraîchit automatiquement — sont désorientants et particulièrement problématiques pour les utilisateurs de lecteurs d’écran qui peuvent ne pas remarquer immédiatement le changement.

La Ligne directrice 3.3 traite de l’assistance à la saisie — l’un des domaines les plus impactants en pratique pour l’accessibilité. Lorsque les utilisateurs commettent des erreurs en remplissant des formulaires, ils doivent savoir trois choses : qu’une erreur s’est produite, quel champ en est la cause et comment la corriger. Se contenter de styliser un champ erroné en rouge ne suffit pas — le message d’erreur doit être textuel, associé de manière programmatique au champ concerné et suffisamment précis pour être exploitable. « Ce champ est obligatoire » est légèrement mieux que rien. « Veuillez saisir votre adresse e-mail au format [email protected] » est réellement utile. WCAG 2.2 a également ajouté les Critères de succès 3.3.7 (Redundant Entry) et 3.3.8 (Accessible Authentication), ce dernier interdisant les tests de fonction cognitive — comme des puzzles ou des défis de mémoire — comme unique mécanisme d’authentification, reconnaissant que ces barrières affectent de manière disproportionnée les personnes avec des handicaps cognitifs.

Un design compréhensible ne consiste pas à simplifier le contenu à l’excès. Il s’agit de supprimer les frictions inutiles. Un langage clair, des schémas cohérents et des messages d’erreur utiles servent tous les utilisateurs — pas seulement ceux en situation de handicap.

Principe 4 : Robust — Conçu pour durer à travers les technologies

Robust est le principe qui reçoit généralement le moins d’attention au moment du design et qui cause le plus de problèmes à long terme. L’exigence est que le contenu soit suffisamment robuste pour être interprété de manière fiable par une grande variété d’user agents, y compris les technologies d’assistance — et à mesure que les technologies évoluent, le contenu doit rester accessible. En pratique, cela signifie écrire un HTML propre, valide et sémantique, et utiliser ARIA de manière réfléchie, afin que les lecteurs d’écran d’aujourd’hui et les moteurs de navigateur de demain puissent tous comprendre votre contenu.

La Ligne directrice 4.1 est la seule ligne directrice sous Robust dans WCAG 2.2, et son critère de succès le plus important restant est 4.1.2 : Name, Role, Value. Pour chaque composant de l’interface utilisateur — formulaires, liens, boutons, widgets personnalisés — le nom (comment il s’appelle), le rôle (de quel type d’élément il s’agit) et la valeur ou l’état (si une case à cocher est cochée, si un accordéon est développé) doivent être déterminables de manière programmatique. Ce sont les informations que les technologies d’assistance lisent à partir de l’arbre d’accessibilité pour indiquer aux utilisateurs avec quoi ils interagissent.

La manière la plus fiable de satisfaire 4.1.2 est d’utiliser des éléments HTML natifs, qui portent des sémantiques intégrées automatiquement exposées à l’arbre d’accessibilité. Un élément <button> est nativement un bouton — il reçoit le rôle correct, il est focalisable par défaut et il s’active à la fois avec Entrée et Espace. Un <div> stylisé pour ressembler à un bouton ne possède aucune de ces propriétés, à moins que vous n’ajoutiez manuellement role='button', tabindex='0' et des gestionnaires d’événements JavaScript pour les événements clavier et pointeur. Les sémantiques natives sont gratuites ; les implémentations personnalisées nécessitent une maintenance constante.

<!-- Inaccessible custom button -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Accessible: native element -->
<button type='submit'>Submit</button>

<!-- When a custom component is unavoidable -->
<div
  role='button'
  tabindex='0'
  aria-pressed='false'
  onkeydown='handleKey(event)'
  onclick='toggleState()'
>
  Toggle
</div>

Le Critère de succès 4.1.3 (Status Messages, niveau AA) exige que les messages d’état importants — confirmations d’envoi de formulaire, indicateurs de chargement, notifications d’erreur, mises à jour du panier — soient annoncés aux utilisateurs de technologies d’assistance sans nécessiter de déplacement du focus clavier vers ces messages. Le mécanisme standard est celui des régions ARIA live : aria-live='polite' pour les mises à jour non urgentes (« Vos modifications ont été enregistrées ») et aria-live='assertive' pour les interruptions urgentes (« Session expirée »). Sans cela, un utilisateur de lecteur d’écran qui effectue un paiement peut soumettre un formulaire et n’entendre aucun retour — ni confirmation, ni erreur — et ne pas savoir si sa commande a été validée.

<!-- Polite live region for non-urgent status -->
<div aria-live='polite' aria-atomic='true' class='sr-only'>
  <!-- Dynamically injected: 'Your profile has been updated.' -->
</div>

<!-- Assertive live region for urgent alerts -->
<div role='alert' aria-live='assertive'>
  <!-- Dynamically injected: 'Error: Payment failed. Please try again.' -->
</div>

Notez que WCAG 2.2 a supprimé l’ancien Critère de succès 4.1.1 (Parsing), qui exigeait auparavant une validation HTML stricte. Les navigateurs modernes et les technologies d’assistance gèrent les HTML mal formés de manière bien plus robuste qu’autrefois, rendant ce critère obsolète. L’accent est désormais entièrement mis sur des sémantiques significatives et une utilisation correcte d’ARIA.

Comment les quatre principes fonctionnent ensemble

POUR n’est pas une liste de cases isolées à cocher — c’est un cadre intégré. Une défaillance dans un principe se répercute presque toujours sur les autres. Un menu déroulant personnalisé construit uniquement avec des éléments <div> et du CSS échouera généralement sur les quatre principes simultanément : il ne peut pas être perçu par un lecteur d’écran (aucun rôle sémantique), il ne peut pas être opéré au clavier (aucune gestion du focus), il ne peut pas être compris par un utilisateur de lecteur d’écran (aucune annonce d’état) et il ne sera pas robuste à mesure que les API des technologies d’assistance évoluent (aucun nom ni valeur programmatiques).

À l’inverse, bien appliquer un principe améliore souvent les autres. Écrire un HTML sémantique (Robust) rend automatiquement le contenu plus perceptible pour les technologies d’assistance. Fournir des alternatives textuelles pour les images (Perceivable) améliore également la compréhensibilité de ce contenu pour les utilisateurs qui ne peuvent pas voir l’image. Ajouter des indicateurs de focus visibles (Operable) rend l’interface plus compréhensible en clarifiant le contexte d’interaction actuel. Cette interdépendance est intentionnelle — le W3C a conçu POUR comme une grille de lecture holistique, et non comme une checklist modulaire.

Pour les responsables conformité qui construisent un programme d’accessibilité, POUR offre la meilleure façon de catégoriser et de hiérarchiser les travaux de remédiation. Lorsque vous auditez un site et trouvez 50 problèmes d’accessibilité, les regrouper par principe vous indique si vous avez un problème de perceptibilité (peut-être que votre équipe de contenu télécharge des images sans texte alternatif), un problème d’opérabilité (votre équipe front-end utilise des composants personnalisés sans support clavier), un problème de compréhensibilité (votre équipe UX conçoit des schémas de navigation incohérents) ou un problème de robustesse (vos développeurs utilisent ARIA de manière incorrecte ou pas du tout). Des problèmes différents exigent des solutions organisationnelles différentes.

POUR en pratique : appliquer le cadre à votre site web

Connaître la théorie est un début. Mettre POUR en pratique exige un processus cohérent qui intègre l’accessibilité à chaque étape du cycle de vie produit — et non un audit ponctuel en fin de projet. Voici les étapes les plus impactantes pour chaque principe.

Pour Perceivable, commencez par une analyse automatisée avec un outil comme WAVE ou Axe pour détecter les problèmes évidents : attributs alt manquants, échecs de contraste, étiquettes de formulaire manquantes et langue de page absente. Ces vérifications automatisées peuvent détecter environ 30–40 % des problèmes WCAG. Auditez ensuite manuellement le reste : observez une page lue par un lecteur d’écran comme NVDA ou VoiceOver, regardez ce qu’une personne daltonienne voit à l’aide d’un simulateur, et vérifiez que chaque élément de sens transmis visuellement l’est aussi par le texte ou la structure.

Pour Operable, débranchez votre souris et naviguez sur chaque page et dans chaque parcours interactif en utilisant uniquement les touches Tab, Entrée, Espace, Échap et les flèches. Vérifiez que le focus ne disparaît jamais, ne se retrouve jamais piégé et se déplace toujours dans un ordre de lecture logique. Passez en revue toutes les interactions temporisées et assurez-vous que les utilisateurs peuvent les prolonger ou les désactiver. Testez sur des appareils tactiles pour vérifier que les interactions basées sur des gestes ont des alternatives au pointeur.

Pour Understandable, auditez les déclarations de langue de vos pages dans tous vos gabarits. Passez en revue chaque formulaire pour vérifier la présence d’étiquettes claires et associées, et testez chaque état d’erreur pour vous assurer que les messages sont spécifiques, textuels et liés de manière programmatique au champ concerné. Réalisez une revue de contenu à l’aide d’un indicateur de lisibilité — visez un niveau de lecture Flesch-Kincaid adapté à votre audience, complété par des réécritures en langage clair pour les sections complexes. Passez en revue les schémas de navigation sur l’ensemble de votre site pour vérifier leur cohérence.

Pour Robust, validez votre HTML. Utilisez les outils de développement du navigateur et l’inspecteur de l’arbre d’accessibilité (intégré aux DevTools de Chrome, Firefox et Safari) pour vérifier que chaque élément interactif possède un nom accessible significatif, le rôle correct et des informations d’état exactes. Auditez chaque widget personnalisé. Testez votre site avec plusieurs lecteurs d’écran — JAWS, NVDA et VoiceOver ont chacun des comportements légèrement différents — et vérifiez que les mises à jour dynamiques comme les erreurs de formulaire, les états de chargement et les notifications toast sont correctement annoncées via des régions live.

Points clés à retenir

POUR est l’ossature des WCAG. Chaque critère de succès WCAG 2.2 se rattache à l’un des quatre principes — Perceivable, Operable, Understandable, Robust — et comprendre ces principes vous aide à raisonner sur l’accessibilité plutôt que de simplement suivre une checklist.
Les défaillances les plus courantes sont évitables. Le texte à faible contraste (présent sur 83,9 % des pages), le texte alternatif manquant, les champs de formulaire non étiquetés et les déclarations de langue de page manquantes sont des défaillances POUR que les outils d’analyse automatisée peuvent identifier et que les développeurs peuvent corriger rapidement.
L’accessibilité au clavier est la base de l’opérabilité. Chaque élément interactif doit être accessible, opérable et quittable au clavier seul — couvrant les personnes avec des handicaps moteurs, la cécité et les limitations situationnelles.
Le HTML sémantique est votre meilleure stratégie de robustesse. Les éléments HTML natifs exposent automatiquement les noms, rôles et états corrects à l’arbre d’accessibilité. Les composants personnalisés construits sur des éléments non sémantiques exigent un travail supplémentaire important et une maintenance continue pour atteindre ce niveau de base.
L’accessibilité est une pratique continue, pas une phase de projet. Intégrez la pensée basée sur POUR dans les revues de design, les checklists de revue de code et les workflows de contenu. Les outils automatisés ne détectent qu’une fraction des problèmes — des tests humains réguliers et des processus de conception inclusive comblent réellement l’écart.

Les principes POUR expliqués : perceptible, utilisable, compréhensible, robuste