Accessibilite pour les developpeurs : coder de maniere inclusive
Les developpeurs sont les architectes de l'accessibilite au niveau de l'implementation. Tandis que les designers definissent les fondations visuelles et interactives, c'est le code qui determine en fin de compte si un site web fonctionne avec la navigation au clavier, communique correctement avec les lecteurs d'ecran et maintient l'accessibilite a travers les navigateurs et les appareils.
La bonne nouvelle est que la plupart des bonnes pratiques d'accessibilite s'alignent avec les bonnes pratiques generales pour un code propre, semantique et conforme aux normes. Ecrire du code accessible ne consiste pas a ajouter de la complexite — c'est ecrire du code correctement des le depart.
Le HTML semantique d'abord
La chose la plus impactante que vous puissiez faire pour l'accessibilite est d'utiliser correctement les elements HTML semantiques. HTML5 offre un vocabulaire riche d'elements qui portent un sens inherent et des fonctionnalites d'accessibilite. Un element <button> est automatiquement focalisable, activable au clavier et annonce comme un bouton par les lecteurs d'ecran. Un <div> avec un gestionnaire onclick n'a aucune de ces fonctionnalites sans un travail supplementaire considerable.
Utilisez <nav> pour les zones de navigation, <main> pour le contenu principal, <header> et <footer> pour leurs sections respectives, <section> et <article> pour les zones de contenu, <h1> a <h6> pour les titres dans l'ordre hierarchique correct, <ul> et <ol> pour les listes, <table> avec <th> pour les donnees tabulaires, <label> avec les attributs for pour les champs de formulaire, et les elements natifs <button> et <a> pour les controles interactifs.
Ces elements creent un arbre d'accessibilite que les technologies d'assistance utilisent pour presenter votre contenu aux utilisateurs. Lorsque vous les utilisez correctement, une grande partie de l'accessibilite est geree automatiquement.
Structure des titres
Les titres creent le plan structurel de votre page. Les utilisateurs de lecteurs d'ecran naviguent frequemment par les titres pour comprendre l'organisation du contenu et trouver des sections specifiques. Chaque page devrait avoir exactement un <h1>, et les titres doivent suivre une hierarchie logique sans sauter de niveaux — un <h3> ne devrait pas suivre un <h1> sans un <h2> entre les deux.
N'utilisez jamais les elements de titre pour le style visuel. Si vous avez besoin d'un texte grand et gras qui n'est pas un titre, utilisez du CSS sur un autre element. Inversement, si un contenu fonctionne comme un titre, balisez-le comme tel, quelle que soit sa presentation visuelle.
Accessibilite au clavier
Toutes les fonctionnalites doivent etre utilisables uniquement via une interface clavier. Cela signifie que chaque element interactif — liens, boutons, champs de formulaire, menus, modales, curseurs, onglets — doit etre accessible via la touche Tab (ou Maj+Tab pour le sens inverse), activable avec Entree ou Espace, et fermable le cas echeant.
Ne creez jamais de pieges au clavier ou les utilisateurs peuvent entrer dans un element avec Tab mais ne peuvent pas en sortir. Les boites de dialogue modales doivent confiner le focus a l'interieur du dialogue lorsqu'il est ouvert et rendre le focus a l'element declencheur lorsqu'il est ferme, mais la touche Echap doit toujours permettre de fermer le dialogue.
Assurez-vous que l'ordre de focus suit une sequence logique qui correspond a la mise en page visuelle. L'ordre du DOM doit generalement correspondre a la presentation visuelle. Evitez d'utiliser des valeurs tabindex positives, qui remplacent l'ordre de focus naturel et creent de la confusion. Utilisez tabindex="0" pour rendre les elements non interactifs focalisables lorsque c'est necessaire, et tabindex="-1" pour les elements qui ne doivent etre focalisables que par programmation.
Langue de la page
Definissez la langue par defaut de chaque page en utilisant l'attribut lang sur l'element <html>. Cela indique aux lecteurs d'ecran quelles regles de prononciation utiliser. Si la langue change au sein du contenu — par exemple, une expression anglaise dans une page en francais — marquez le changement avec un attribut lang sur l'element contenant.
Accessibilite des formulaires
Les formulaires sont l'endroit ou les utilisateurs fournissent des informations, et ils sont une source frequente de problemes d'accessibilite. Chaque champ de formulaire doit avoir un libelle associe de maniere programmatique, generalement en utilisant l'element <label> avec un attribut for correspondant a l'id du champ. Regroupez les champs lies en utilisant <fieldset> et <legend>.
Lorsque des erreurs de saisie sont detectees, identifiez le champ en erreur et decrivez l'erreur en texte. Fournissez des suggestions de correction lorsque c'est possible. Pour les champs qui acceptent des formats specifiques, fournissez des instructions claires sur le format attendu. Utilisez l'attribut autocomplete pour activer le remplissage automatique du navigateur pour les champs courants comme le nom, l'email, l'adresse et le numero de telephone.
Les messages de statut qui ne recoivent pas le focus — comme « article ajoute au panier » ou « 3 resultats trouves » — doivent etre annonces aux utilisateurs de lecteurs d'ecran via les regions live ARIA ou les roles de statut.
Texte alternatif
Chaque image non decorative doit avoir un texte alternatif significatif qui decrit son contenu ou sa fonction. Pour les images informatives, decrivez ce que l'image transmet. Pour les images fonctionnelles (comme un logo qui renvoie a la page d'accueil), decrivez la fonction. Pour les images decoratives qui n'ajoutent aucune information, utilisez un attribut alt vide (alt="") pour que les lecteurs d'ecran les ignorent completement.
Les images complexes comme les graphiques, les diagrammes ou les schemas peuvent necessiter des descriptions plus longues fournies via une legende, un texte adjacent ou une description detaillee liee.
WAI-ARIA
La specification Accessible Rich Internet Applications fournit une semantique supplementaire pour les situations ou le HTML natif est insuffisant. ARIA vous permet de communiquer des roles, des etats et des proprietes aux technologies d'assistance pour les widgets personnalises et le contenu dynamique.
Cependant, ARIA doit etre utilise avec discernement. La premiere regle d'ARIA est : si vous pouvez utiliser un element HTML natif qui a la semantique et le comportement dont vous avez besoin, faites-le. ARIA n'ajoute pas de fonctionnalite — il ajoute uniquement de la semantique. Un <div role="button"> necessite toujours du JavaScript pour la gestion du clavier, alors qu'un <button> natif le gere automatiquement.
Utilisez les roles de repere ARIA (ou leurs equivalents HTML5) pour definir les regions de la page. Utilisez aria-label et aria-labelledby pour fournir des noms accessibles lorsque le texte visible est insuffisant. Utilisez aria-expanded, aria-selected, aria-checked et d'autres attributs d'etat pour communiquer l'etat actuel des widgets interactifs. Utilisez les regions aria-live pour annoncer les mises a jour de contenu dynamique.
Design responsive et redistribution
Le contenu doit pouvoir etre presente sans perte d'information a 320 pixels CSS de largeur sans necessiter de defilement horizontal. Cela garantit que les utilisateurs qui zooment a 400 % sur un ecran de bureau standard peuvent toujours acceder a tout le contenu. Concevez vos mises en page pour redistribuer le contenu en une seule colonne aux largeurs etroites plutot que de necessiter un defilement dans deux dimensions.
Liens d'evitement
Fournissez un mecanisme permettant aux utilisateurs du clavier de contourner les blocs de contenu repetes, tels que les menus de navigation, et d'acceder directement au contenu principal. L'implementation la plus courante est un lien « Aller au contenu principal » qui est le premier element focalisable de la page et devient visible lorsqu'il recoit le focus.
Checklist de test pour les developpeurs
Avant de deployer toute fonctionnalite, verifiez : toutes les fonctionnalites marchent avec le clavier seul ; l'ordre de focus est logique ; le focus est visible sur tous les elements interactifs ; toutes les images ont un texte alternatif approprie ; tous les champs de formulaire ont des libelles ; la langue de la page est definie ; la hierarchie des titres est correcte ; ARIA est utilise correctement et uniquement lorsque c'est necessaire ; le contenu se redistribue a 320px de largeur ; et les mises a jour de contenu dynamique sont annoncees aux lecteurs d'ecran.
Dans cette section
Votre site web est-il accessible ?
Scannez votre site web gratuitement et obtenez votre score WCAG en quelques minutes.
Scanner votre site gratuitement