Laccessibilite numerique

1. Objectifs

   • Définir l'accessibilité numérique et expliquer pourquoi elle concerne tout le monde
   • Connaître les quatre principes et les niveaux des WCAG
   • Appliquer les bonnes pratiques de contraste, de couleur, d'images, de structure et de formulaires
   • Rendre une interface utilisable au clavier et compréhensible par un lecteur d'écran
   • Tester une page avec des outils et à la main
   • Rédiger une grille d'audit avec des corrections concrètes

1. Présentation

   • Imaginez une personne qui ne peut pas utiliser de souris, qui ne voit pas l'écran ou qui consulte votre application en plein soleil. Peut-elle quand même réserver un livre ? L'accessibilité numérique répond à cette question.
   • Selon l'Organisation mondiale de la Santé, environ 1,3 milliard de personnes, soit 16 % de la population mondiale, vivent avec un handicap important. Dans la leçon précédente, nous avons rendu un écran plus simple. Nous allons maintenant vérifier qu'il reste utilisable par le plus grand nombre.

• Nous continuons avec BiblioCampus. Cette leçon comporte un peu de HTML et de CSS, car l'accessibilité se décide aussi dans le code. Pour les activités, créez le dossier 08-accessibilite/ dans votre dépôt GitHub ui-ux-design-bts.

1. Qu'est-ce que l'accessibilité numérique ?

   • L'accessibilité numérique consiste à concevoir des sites, des applications et des documents utilisables par toutes et tous, notamment par les personnes en situation de handicap, avec ou sans technologie d'assistance.
   • Elle ne concerne pas seulement les personnes en situation de handicap permanent :

• Les technologies d'assistance comprennent notamment les lecteurs d'écran, les plages braille, les loupes d'écran, la commande vocale et les contacteurs. Une interface mal conçue peut empêcher ces outils de fonctionner.

1. Les WCAG : la référence internationale

   • Les WCAG (Web Content Accessibility Guidelines) sont les recommandations du W3C pour l'accessibilité des contenus web. La version 2.2 a également été reprise dans la norme internationale ISO/IEC 40500:2025.
   • Elles reposent sur quatre grands principes :

• Les obligations légales varient selon les pays et les organismes. Vérifiez toujours les règles qui s'appliquent à votre projet.

1. Pratique 1 : un contraste suffisant

   • Un texte trop clair devient difficile à lire pour de nombreuses personnes, surtout sur mobile et en pleine lumière. Le rapport de contraste se vérifie avec un outil :

1. Pratique 2 : ne pas compter uniquement sur la couleur

   • Une information donnée seulement par une couleur peut échapper à certaines personnes. Ajoutez un texte, une icône, un motif ou une position :

1. Pratique 3 : décrire les images

   • L'attribut alt remplace une image lorsque celle-ci ne peut pas être vue. Demandez-vous : quelle information perdrait-on sans cette image ?

1. Pratique 4 : structurer la page

   • Utilisez les bons éléments HTML. Les titres, les listes et les zones comme <header>, <nav> et <main> permettent de naviguer plus vite :

<body>
  <header>BiblioCampus</header>
  <nav aria-label="Navigation principale">...</nav>
  <main>
    <h1>Catalogue</h1>
    <h2>Nouveautés</h2>
  </main>
</body>

1. Pratique 5 : rendre les formulaires clairs

   • Un champ doit avoir une étiquette visible et associée. Un message d'erreur doit indiquer le champ concerné et la façon de corriger :

<label for="email">Adresse e-mail</label>
<input id="email" type="email" aria-describedby="email-erreur" aria-invalid="true">
<p id="email-erreur">Saisissez une adresse complète, par exemple sami@domaine.tn.</p>

1. Pratique 6 : permettre l'usage au clavier

   • Certaines personnes utilisent uniquement un clavier ou un dispositif équivalent. Tout ce qui se fait à la souris doit donc être possible au clavier, avec un focus visible:

1. Pratique 7 : penser aux lecteurs d'écran

   • Un lecteur d'écran annonce le rôle et le nom des éléments. Commencez toujours par le HTML natif : un vrai bouton, un vrai lien, une vraie liste.
   • L'ARIA complète le HTML lorsque c'est nécessaire, mais il ne remplace pas une bonne structure. Une erreur d'ARIA peut même aggraver la situation.

1. Pratique 8 : autoriser le zoom et agrandir les cibles

   • Le texte doit rester utilisable lorsqu'il est agrandi à 200 %, et les boutons doivent être faciles à toucher :

• Ces 24 pixels constituent un minimum pour le niveau AA. Les repères de 44 pt sur iOS et 48 dp sur Android, vus dans la leçon sur l'ergonomie, offrent davantage de confort.

1. Pratique 9 : penser aux vidéos, aux sons et aux animations

   • Un contenu audio ou vidéo doit proposer une solution de remplacement adaptée :

• Les animations peuvent aussi gêner certaines personnes. CSS permet de les réduire lorsque l'utilisateur l'a demandé dans les réglages de son appareil :

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

1. Tester l'accessibilité

   • Aucune méthode ne suffit seule. Combinez les outils automatiques, les tests manuels et les retours d'utilisateurs :

1. Activité 1 : associer les principes

   • Associez chaque problème à un principe (perceptible, utilisable, compréhensible, robuste) :
     • a) Une vidéo n'a pas de sous-titres.
     • b) Un menu s'ouvre seulement au survol de la souris.
     • c) Un message indique : « Erreur 0xA3 ».
     • d) Une zone <div> imite un bouton, sans rôle pour les technologies d'assistance.
     • e) Un texte gris clair se lit difficilement.
   • Vérifier : a) perceptible, b) utilisable, c) compréhensible, d) robuste, e) perceptible.
   • Quelle personne serait gênée dans chaque cas ?

1. Activité 2 : mesurer des contrastes

   • Avec un vérificateur de contraste, comme celui intégré à de nombreux outils de développement des navigateurs, mesurez ces quatre associations :

• Vérifier : les textes 2 et 4 respectent 4,5 : 1 ; les textes 1 et 3 sont insuffisants pour un texte courant. Corrigez ces deux derniers en changeant le moins possible la couleur.

1. Activité 3 : écrire des textes alternatifs

   • Écrivez l'attribut alt pour :
     • le logo de BiblioCampus, qui mène à l'accueil ;
     • une photo décorative d'étagères ;
     • une icône de corbeille dans un bouton qui supprime une réservation ;
     • un graphique montrant une baisse des retards.
   • Vérifier : par exemple « BiblioCampus, accueil » ; alt=""; « Supprimer la réservation » ; et une phrase qui donne l'information principale du graphique. Il est inutile de commencer par « image de ».

1. Activité 4 : corriger du code

   • Réécrivez ce code avec les bons éléments HTML :

<div class="titre">Connexion</div>
<input placeholder="E-mail">
<div class="bouton" onclick="connexion()">OK</div>
<img src="cadenas.png">

• Vérifier : le titre utilise <h1>, le champ a un <label>, l'action est un vrai <button> avec un texte comme « Se connecter », et l'image a un alt adapté à son rôle (vide si elle est décorative).

1. Activité 5 : auditer un écran

   • Relevez au moins six problèmes d'accessibilité sur cet écran :

• Vérifier : texte et titre peu contrastés, disponibilité indiquée par la couleur seule, champ sans étiquette visible, bouton jaune peu lisible, icône ambiguë et vidéo sans mention de sous-titres. Précisez ce que chaque problème empêche.

1. Activité 6 : utiliser uniquement le clavier

   • Rangez la souris, puis réalisez une tâche sur un site : Tab pour avancer, Maj + Tab pour revenir, Entrée ou Espace pour agir, et Échap pour fermer.

• Vérifier : votre tableau indique si le focus est visible, si l'ordre est logique et si un élément bloque le déplacement.

1. Activité 7 : écouter une page

   • Essayez un lecteur d'écran : NVDA sur Windows, VoiceOver sur Mac ou iPhone, TalkBack sur Android.
   • Faites lire une page simple, puis parcourez les titres et les liens. Notez ce qui est clair et ce qui est incompréhensible.
   • Vérifier : vous citez au moins deux éléments mal annoncés. Soyez prudent : un premier essai ne remplace pas l'avis d'une personne qui utilise ces outils au quotidien.

1. Activité 8 : utiliser un outil automatique

   • Dans Chrome, ouvrez les outils de développement et lancez Lighthouse avec la catégorie Accessibilité sur l'une de vos pages. Corrigez deux erreurs, puis relancez le test.
   • Vérifier : vous conservez les résultats avant et après. Pourquoi un score de 100 ne prouve-t-il pas que le site est totalement accessible ?

1. Activité 9 : changer de conditions d'usage

   • Testez une page dans ces trois conditions :
     • zoom du navigateur à 200 % ;
     • son coupé et vidéos sans image ;
     • affichage en niveaux de gris, réglé dans l'appareil ou le navigateur.
   • Vérifier : pour chaque condition, indiquez ce qui reste utilisable et ce qui se perd.

1. Activité 10 : déposer votre travail sur GitHub

   • Regroupez vos réponses, votre code corrigé et votre grille d'audit dans 08-accessibilite/README.md, puis envoyez le tout :

git add 08-accessibilite
git commit -m "Ajoute la leçon sur l'accessibilité numérique"
git push

• Vérifier : le fichier README.md et votre code apparaissent bien sur la page GitHub du dépôt.

1. Erreurs fréquentes

1. À retenir

   • L'accessibilité permet au plus grand nombre d'utiliser un produit, y compris avec des technologies d'assistance.
   • Les limites peuvent être permanentes, temporaires ou liées à la situation.
   • Les WCAG reposent sur quatre principes : perceptible, utilisable, compréhensible et robuste.
   • Le niveau AA demande notamment un contraste de texte de 4,5 : 1.
   • Le HTML natif, les étiquettes, le clavier et le focus visible sont des bases essentielles.
   • Les tests combinent outils, vérifications manuelles et retours de personnes concernées.

Une application accessible ne fait pas un effort « en plus » pour quelques personnes : elle laisse moins de monde à la porte.