Évaluer rapidement le niveau d’accessibilité d’un site web – GAAD 2023
Vous souhaitez vous faire une première idée du niveau général d’accessibilité d’un site web aux personnes handicapées ? Alors ce webinaire est fait pour vous !
En effet, un ensemble de manipulations rapides, de techniques simples et d’astuces vous seront présentées afin que vous puissiez estimer par vous-même la prise en compte ou non d’un certain nombre de règles d’accessibilité (UX, UI, techniques ou encore éditoriales).
Ce webinaire a été animé le 17 mai 2023 sur Teams.
Vidéo du webinaire
La vidéo du webinaire ci-après est sous-titrée et traduite en LSF.
Transcription de la vidéo

Sébastien Delorme :
— Bonjour à toutes et à tous.
Je vais juste vérifier que vous m’entendez bien. Effectivement, oui, parce que je vois que l’interprète LSF, que ça fonctionne…
Je vais juste vérifier rapidement la vélotypie. Effectivement, c’est tout bon.
Global Accessibility Awareness Day

Du coup, bienvenue sur ce premier webinaire d’introduction de la GAAD.
Juste pour poser un petit peu le contexte, du coup, je vous rappelle que ces quatre webinaires seront sous-titrés, vous aurez accès aux sous-titres sur le lien qui s’affiche. Il est également interprété en langue des signes, il y a une vignette sur Teams qui met en avant les deux signaux de la matinée.
Il est également enregistré, vous pourrez retrouver ce webinaire et les trois suivants sur notre blog quelques jours après la diffusion, sous-titré et traduit en langue des signes.
Je vais maintenant passer la parole à Johan.
Je serai le modérateur sur la journée, si vous avez la moindre question, n’hésitez pas à la poser par écrit dans l’espace questions-réponses dans le chat, je les récupère et je les transmets à Johan en fin de présentation.
Merci pour votre présence. Je laisse la parole à Johan.
Johan Ramon :
— Bonjour à toutes et à tous.
Très heureux de vous retrouver ce matin dans le cadre de la GAAD édition 2023.
La GAAD, c’est la Global Accessibility Awareness Day, la journée mondiale de sensibilisation à l’accessibilité numérique.
Cette journée a lieu demain en principe, mais demain étant férié en France, nous avons choisi de vous proposer ces quatre webinaires la veille, soit aujourd’hui, pour sensibiliser le plus de personnes.
Johan Ramon

Moi, c’est Johan Ramon, je suis expert et responsable accessibilité numérique au sein de la société Ideance. Je travaille dans le domaine de l’accessibilité numérique depuis pas loin de quinze ans maintenant, et j’ai été développeur front-end / intégrateur HTML.
Sébastien Delorme

Je suis accompagné de Sébastien qui est aussi expert accessibilité numérique et président et fondateur d’Ideance.
Ideance

Ideance, rapidement, c’est une société de conseil et d’expertise en accessibilité numérique où nos principales missions sont d’accompagner des organismes publics, des entreprises privées mais aussi des associations à la prise en compte de ce sujet de l’accessibilité numérique dans la réalisation de leurs différents supports numériques (sites Web, documents bureautiques, etc.).
On mène des audits d’accessibilité, on fait des accompagnements de projet et on anime des formations.

J’ai choisi de vous présenter ce matin un webinaire intitulé « Évaluer rapidement le niveau d’accessibilité d’un site Web ».
Ce webinaire devrait vous aider à…

Ce que ça va vous permettre en principe ce webinaire, c’est d’évaluer de manière autonome, par vous-même, la prise en compte ou non d’un certain nombre de règles d’accessibilité sur un site Web.
J’insiste bien sur « un certain nombre ». On verra juste après.
Et vous allez pouvoir par vous-mêmes tester ces quelques règles et critères via un ensemble de manipulations simples, de techniques rapides et de tips que je vais vous présenter au fur et à mesure de l’avancée du webinaire.
Quand vous aurez mené ces tests, vous pourrez vous faire une idée du niveau général d’accessibilité aux personnes handicapées du site Web que vous êtes en train de tester.
En revanche, il ne vous permettra pas de…

En revanche, ce webinaire ne va pas vous permettre de vérifier pleinement, complètement la prise en compte de toutes les règles d’accessibilité.
C’est un petit panel, un petit échantillon de règles que j’ai sélectionnées et qui sont vérifiables par tout un chacun, peu importe son profil.
Donc, cette présentation ne sera pas exhaustive et il y a certaines règles qui sont un peu plus sensibles à tester que j’ai mises de côté, car on est dans le cadre d’une découverte de ce sujet, donc, j’ai voulu rester grand public.
Du coup, par rebond, ça ne permettra pas de connaître précisément le niveau d’accessibilité du site Web testé et ça ne vous permettra pas non plus de connaître son niveau de conformité au Référentiel Général d’Amélioration de l’Accessibilité (RGAA) qui liste toutes les règles et bonnes pratiques qui doivent être suivies obligatoirement pour garantir la pleine accessibilité et conformité d’un site Web.
L’accessibilité web, quésaco ?

On va rentrer dans le vif du sujet, mais avant ça, il me semblait important de vous rappeler les grands principes de l’accessibilité Web sous la forme d’une introduction de :
- C’est quoi l’accessibilité ?
- Qui elle concerne, concrètement ?
- Pourquoi il est important de la respecter et de la mettre en place ?
- Et comment la respecter de manière efficace ?
L’accessibilité web, c’est quoi ?

Une définition rapide de ce qu’est l’accessibilité, c’est :
Faire en sorte que tous les services, tous les contenus, toutes les fonctionnalités que vous proposez sur un site Web soient compréhensibles, utilisables, autrement dit accessibles aux personnes handicapées, aux personnes déficientes.
L’accessibilité web, pour qui ?

Mais ça concerne qui ?
Je l’ai cité juste avant, ça concerne principalement les personnes handicapées.
On a tendance à dire que ça concerne entre 15 et 20% de la population.
Et parmi les personnes handicapées, on peut citer les personnes dites déficientes motrices ou encore les personnes déficientes auditives, les personnes déficientes visuelles, les personnes déficientes cognitives, psychiques, les personnes déficientes mentales ou intellectuelles.
Parmi les personnes déficientes motrices, il y a les personnes tétraplégiques qui ne peuvent pas utiliser leurs membres supérieurs ou inférieurs, il y a aussi les personnes infirmes motrices cérébrales qui auront des difficultés à utiliser une souris classique et qui vont se tourner vers d’autres dispositifs de pointage comme des souris adaptées ou qui vont utiliser exclusivement leur clavier pour naviguer sur une interface numérique.
Côté personnes déficientes auditives, ça concerne les personnes sourdes et les personnes malentendantes qui ont un besoin particulier concernant tout ce qui va être multimédia, fichiers audio et vidéo.
On peut citer parmi les personnes déficientes visuelles les personnes atteintes de cécité, aveugles, qui utilisent, pour certaines, des lecteurs d’écrans, qui sont des outils d’assistance qui restituent tout ce qui s’affiche à l’écran et toutes les interactions que l’on fait avec le site Web, soit via un retour audio via synthèse vocale, soit via une plage braille.
On peut aussi citer les personnes dites malvoyantes, par exemple atteintes de glaucome, presbytes, daltoniennes, dont le besoin particulier face à des interfaces numériques, c’est la possibilité de pouvoir adapter l’affichage (changer les couleurs, agrandir la taille des textes, la réduire, modifier les interlignages…), tous ces réglages-là qui sont faits généralement depuis les navigateurs ou systèmes d’exploitation.
Parmi les personnes déficientes cognitives, on peut citer les personnes avec des troubles de l’apprentissage comme les personnes dyslexiques, dysorthographiques, dyspraxiques.
Les personnes dyslexiques, ce sont des personnes qui auront des difficultés de lecture, qui vont mettre plus de temps par exemple à prendre connaissance des contenus.
Pareil que pour les personnes malvoyantes, leurs besoins, c’est principalement de pouvoir adapter l’affichage, changer des polices de caractère, de nouveau changement des espacements ou des interlignages.
Enfin, un petit exemple de personnes atteintes de déficience mentale, on peut citer par exemple les personnes autistes qui auront besoin d’interfaces simplifiées qui ne soient pas trop compliquées à utiliser.
L’accessibilité Web, ça concerne principalement ce panel, mais pas que.
L’accessibilité web, pourquoi ?

Maintenant, pourquoi il est important d’appliquer, de respecter cette prise en compte de l’accessibilité sur le site Web, mais aussi de manière générale sur le numérique ?
C’est un droit fondamental pour ces personnes handicapées.
Un site Web accessible va favoriser l’inclusion de ces personnes dans la société, ça va leur donner de l’autonomie pour accomplir des démarches en ligne, pour faire de l’achat en ligne, pour consulter des contenus, consulter les vidéos et j’en passe.
Et aussi, ça a l’effet positif, cette mise en accessibilité, cette garantie de l’accessibilité, d’éviter les discriminations et de réduire les inégalités.
Notez aussi qu’un grand nombre d’entreprises privées (dont le chiffre d’affaires est au minimum de 250 millions d’euros par an), ainsi que tous les organismes publics, ont cette obligation légale de mise en accessibilité depuis maintenant un certain nombre d’années.
Donc, il y a deux volets sur cet aspect.
Le premier, c’est ce volet éthique RSE qui est le droit fondamental pour les personnes handicapées, et il y a le second volet du pourquoi qui est plus sur l’obligation légale, respecter une loi en vigueur.
Je ne rentre pas trop dans le détail, ce n’est pas l’objet de ce webinaire, mais si vous voulez en savoir plus, il y a plein de ressources que je vous présenterai à la fin de la conférence si j’ai un peu de temps.
L’accessibilité web, comment ?

Comment mettre en place l’accessibilité Web et numérique de manière plus générale ?
C’est suivre un certain nombre de règles et de bonnes pratiques qui peuvent être d’ordre fonctionnel : est-ce que j’ai différents moyens de navigation proposés sur mon site ?
Qui peuvent être aussi d’ordre graphique, liés à de l’UI et de l’UX : est-ce que j’ai des contrastes suffisants, par exemple ?
On a aussi des règles et bonnes pratiques davantage liées à tout ce qui est technique et liées au développement, savoir structurer et coder correctement ses fichiers HTML, CSS, JavaScript.
Et enfin, des règles qui concernent davantage la rédaction et la publication de contenus pour garantir une bonne accessibilité du site Web tout au long de sa vie, dans la publication des articles, des contenus, des évènements et j’en passe.
Voilà pour cette introduction, ce rapide rappel des grands principes de l’accessibilité Web.
Tester l’adaptation de l’affichage

On va maintenant rentrer dans le vif du sujet avec une première thématique, une première section de tests à mener pour vérifier s’il y a une prise en compte du sujet de l’accessibilité sur le site Web que vous envisagez de tester.
Cette première section, c’est tester certaines adaptations de l’affichage.
Le site web est-il responsive ?

Une règle d’accessibilité demande à ce que le site Web soit adaptatif, c’est-à-dire qu’il soit responsive, qu’il s’affiche correctement lorsque la taille de l’écran est réduite.
Et la règle officielle, que l’on retrouve dans les standards, demande que, lorsque la taille de l’écran est réduite jusqu’à 320 pixels, il ne faut pas qu’il y ait de perte d’information ni de perte de service ou de fonctionnalité et il ne faut pas non plus l’apparition d’une scrollbar horizontale.
Cette règle est importante pour de nombreuses personnes en situation de handicap.
On peut par exemple citer les personnes, j’en parlais tout à l’heure, tétraplégiques, qui sont déficientes motrices, qui ne peuvent pas faire usage d’un clavier ni même d’une souris et qui auront tendance à piloter leur smartphone par exemple à la voix.
Ces personnes n’ont que cette possibilité de consulter le site Web sur un périphérique de petite taille.
Typiquement, elle pourrait socler leur smartphone et avoir la possibilité de consulter le site seulement en mode portrait sur une toute petite taille d’écran smartphone, il est donc important que toutes les informations que l’on a sur la version classique soient aussi disponibles sur la version mobile.
Ce besoin et l’importance d’avoir un site responsive, ça touche aussi les personnes aveugles parce qu’une personne aveugle peut très bien avoir…
On peut imaginer qu’elle a un écran noir, par exemple, elle ne connaît pas la taille de son écran, et elle peut très bien être sur un environnement desktop, sur son navigateur mais que celui-ci soit d’une toute petite taille et dans ce cas-là, il est important qu’elle ait accès à tous les contenus présents sur la version par défaut.
Allons voir un exemple, un bon exemple d’un site qui est parfaitement construit et responsive jusqu’à 320 pixels.
Je vais sur le site de la Métropole du Grand Paris, sur la page qui présente la Métropole.
Le test à mener pour vérifier que le site est responsive jusqu’à 320 pixels sans perte de contenus, c’est la manipulation CTRL + Shift + M qui permet de rentrer en mode adaptatif, et ensuite, vous pouvez réduire la largeur de votre page Web en vous positionnant jusqu’à 320 pixels, l’idéal étant de tester sur différents paliers.
Je me mets directement à 320 pixels.
Il faut vérifier qu’il n’y ait pas l’apparition d’une scrollbar horizontale en bas de la page Web, et que tous les contenus présents sur la version par défaut soit aussi disponibles sur cette version 320 pixels.
Evidemment, il peut y avoir réagencement des contenus, des fonctionnalités, modification de leur apparence, mais il faut qu’elles soient encore fonctionnelles.
Sur la version full, pleine, on a différents menus de navigation, un moteur de recherche dans l’en-tête, un fil d’Ariane et j’en passe.
Ces éléments, on a le sentiment qu’ils disparaissent en 320 pixels, mais en réalité, ils sont toujours disponibles mais présentés d’une autre manière.
Les menus sont encore disponibles sous le menu hamburger. Donc ça répond à la règle. Les contenus sont encore là et il n’y a pas de scrollbar horizontale.
Je ne vais pas y passer plus de temps, si vous avez des questions, n’hésitez pas à passer par le canal.
Les textes restent-ils lisibles lorsqu’agrandis ?

Deuxième règle facile à tester, c’est la possibilité d’agrandir la taille des textes.
La règle demande qu’un site Web et ses textes puissent être agrandis jusqu’à 200%, et lorsque la taille des textes est agrandie, il ne faut pas qu’il y ait perte d’information ou de fonctionnalité.
Cette règle est importante pour les personnes malvoyantes qui auraient besoin d’une taille de texte plus grande pour leurs préférences de consultation.
Pour tester ce critère, je vais cette fois-ci changer de site. Je vais me mettre sur le site d’Ideance.
Pour agrandir la taille des textes, soit vous passez par votre clavier en faisant CTRL plus +, et CTRL + - pour réduire la taille des textes, et vous allez voir en haut de votre navigateur, à droite de votre barre d’url, il me semble que c’est le cas sous Chrome, même sous Edge, la taille du texte en pourcentage.
Là, j’ai fait deux fois CTRL plus +, je suis à 133%, et l’idée est d’aller jusqu’à six fois CTRL plus + pour atteindre le fameux palier de 200% et, de la même manière que tout à l’heure, il faut vérifier que tous les textes sont présents, lisibles et, de nouveau aussi, il peut y avoir un réagencement des fonctionnalités et des contenus, un changement visuel, tant que les éléments sont encore présents, utilisables et fonctionnels, c’est accessible.
Là, le menu sur la version à 100% est horizontal. Quand je bascule en mode 200%, cette fois-ci, le menu est caché derrière un bouton hamburger, il est réagencé mais c’est pleinement accessible.
Notez qu’il y a deux types de zoom. Là, ça va être un poil plus sensible. Deux types de zooms dans les navigateurs.
Ils peuvent être paramétrés sous Firefox dans le menu « Affichage > Zoom ».
Par défaut, le zoom qui est activé dans le navigateur, c’est le zoom graphique, qui a la particularité, lorsqu’il est utilisé, de tout zoomer, à la fois les textes et les images.
En revanche, il y a une option pour zoomer seulement les textes.
La règle d’accessibilité dit : si les textes s’agrandissent bien dans l’un des deux zooms, graphique ou zoom texte seulement, c’est OK, ça veut dire que, si votre site s’agrandit bien en zoom graphique, il n’est pas forcément nécessaire qu’il s’agrandisse en zoom texte seulement, et inversement.
Idem, ce complément est un poil plus technique donc n’hésitez pas à demander des compléments dans le canal de conversation.
Vérifier la présence et la pertinence des titres

Une autre thématique et d’autres règles que je voulais aborder avec vous, règles aussi particulièrement importantes pour l’accessibilité, c’est de vérifier la présence et la pertinence des titres dans les pages Web.
Les pages ont-elles un titre principal pertinent ?

Nous avons deux types de titres.
Il y a ce qu’on appelle le titre principal des pages, c’est ce qui s’affiche dans l’onglet de votre navigateur.
Le titre principal, la balise <title>
pour les plus techniques d’entre vous, c’est un élément particulièrement important pour les personnes qui naviguent avec des synthèses vocales ou des plages braille parce que c’est la première information qui sera restituée au chargement de la page.
Si le <title>
est pertinent, ça permet pour ces personnes qui utilisent des lecteurs d’écran, au chargement de la page, d’être certaines qu’elles sont sur la page où elles souhaitaient être.
Ce qui est attendu, en termes d’accessibilité, c’est de reprendre dans ce <title>
le nom de la page courante ainsi que le nom du site.
De nouveau, je vais sur Internet pour vous présenter trois bons exemples.
Je me rends sur le site de Spie. Je suis sur la page « Développement durable » et je remarque que, dans mon onglet de navigateur, le titre principal reprend bien le nom de la page courante ainsi que le nom du site.
Un autre exemple, toujours sur ce même site : je me suis mis sur la page « Notre politique RSE ». Dans le titre de la page, j’ai bien « Notre politique RSE » et « Spie ».
Et pour aller un petit peu plus loin, il y a une particularité pour les pages qui possèdent des moyens de filtrer des contenus, pour les pages qui possèdent des systèmes de pagination.
Étant donné que la règle sur ce titre principal demande d’avoir des titres explicites, uniques et pertinents, une très bonne pratique d’accessibilité, c’est, en plus de reprendre le nom de la page courante (« Résultat de la recherche pour « handicap » »), d’indiquer le ou les filtres utilisés ainsi que la page courante utilisée dans le système de pagination.
Si je survole mon onglet de navigateur, je remarque que cette page de résultats de recherche indique comme titre principal « Résultats de recherche pour handicap », et ce qui nous intéresse, c’est « Filtrés par actualités, page 1 sur 2 », et le nom du site, « Spie ».
C’est le niveau supérieur d’accessibilité. C’est un poil un peu plus technique. N’hésitez pas si vous avez besoin de compléments d’info.
Les pages ont-elles des titres de section ?

Et les autres titres que l’on a coutume d’évoquer en accessibilité Web, c’est ce qu’on appelle les titres de section.
Les titres de section, pour les plus techniques, c’est les balises <hn>
allant de <h1>
à <h6>
.
Quand on a une hiérarchie de titres de section logique et complète, ça permet de comprendre comment sont organisés et hiérarchisés les contenus dans la page et ça permet aussi d’accélérer la navigation pour ces mêmes personnes.
Et, pour évaluer de manière générale une bonne utilisation des titres de section dans une page Web, je vous recommande fortement l’utilisation d’une extension, disponible à la fois sous Firefox et aussi sous Chrome, qui s’appelle « HeadingsMap ».
Allons voir à quoi ça ressemble. Je vous présente les pages de l’extension. Elle est disponible ici, vous tapez HeadingsMap sur Google, ce sera le premier lien de résultats de recherche. Et idem, l’extension est disponible aussi sous Firefox, même recherche. Vous trouverez ça très rapidement.
Et comment ça s’utilise ?
On va changer de site. Je vais me rendre sur le site de Tourisme Hérault Mobility.
J’avais installé l’extension au préalable. J’ai dans ma barre d’adresse un bouton et si je clique dessus, j’ai dans un panneau latéral tous les titres de section utilisés dans la page.
On clique sur un titre, ça permet de le mettre en surbrillance et de m’indiquer son niveau.
Là, mon outil me dit que le texte « Bienvenue sur le site Hérault mobility » a été codé tel un titre de niveau 1. C’est très bien parce qu’il s’agit réellement du premier titre de section de ma page.
Ensuite, si je poursuis, si je clique sur le titre de niveau 2 « Connaître le niveau d’accessibilité », de nouveau, il sera mis en surbrillance avec un contour rouge qui me permet de voir qu’effectivement, « Connaître le niveau d’accessibilité » est un titre de niveau 2 parce qu’il chapeaute du contenu. Idem pour « Vous déplacer », c’est aussi un titre de niveau 2.
J’ai le sentiment, au fur et à mesure de mes tests, qu’il y a des titres qui ont bien été employés dans la page, et deux, leur hiérarchie semble cohérente.
Je me fais une première idée en disant : il y a eu une prise en compte du critère.
Si on va un petit peu plus bas, on attaque une nouvelle section qui sont les sites à explorer, structurée avec un titre de niveau 2. Ensuite, les sites en question, juste en dessous, les cards, elles, sont bien titrées avec des titres de niveau 3.
On a donc une hiérarchie de titre qui a l’air pleinement accessible.
Retenez qu’une page Web doit posséder des titres de section. Ces titres de section doivent être hiérarchisés de manière logique et complète. Et pour vous aider à ça, il existe une extension très pratique qui s’appelle « HeadingsMap ».
Évaluer le niveau d’accessibilité des formulaires

Nouvelle section et thématique : quelques règles cette fois-ci qui vont porter sur les formulaires.
Les libellés sont-ils proches de leur champ ?

Première chose qui peut être testée assez facilement, je pense, c’est l’agencement, la mise en page des formulaires.
Une règle demande que les libellés des champs soient proches les uns des autres.
Un libellé doit être le plus proche possible de son champ correspondant. Il faut idéalement que quelques pixels les séparent.
On va de nouveau aller sur une page Web pour vous montrer comment vérifier ça. Cette fois-ci, je me rends sur le site de Brest métropole, je suis sur leur formulaire « Contacter nos services ».
Ce que je vais vérifier, c’est que les libellés (nom, prénom, adresse, etc), toutes les étiquettes soient visuellement proches de leur champ de saisie correspondant.
Si je m’arrête au champ « Nom », je vois que, visuellement, il est très proche de son champ correspondant.
Si je descends en bas, j’arrive sur la case à cocher « Données personnelles », je remarque que la case est très proche de l’étiquette, ça a l’air d’être parfaitement accessible sur cette page au niveau de cette règle.
Petite particularité, les règles internationales demandent que les étiquettes des listes déroulantes et champs de saisie se positionnent au-dessus ou à gauche.
En revanche, les étiquettes des boutons radio et des cases à cocher doivent être positionnées à droite ou en dessous. La règle impose ceci.
Et j’ai oublié de l’indiquer, cette règle de positionnement des étiquettes proches de leur champ de saisie correspondant est particulièrement importante pour les personnes malvoyantes qui utilisent des loupes d’écran.
On a des personnes qui utilisent des loupes systèmes, comme je le montre ici, qui peuvent avoir des niveaux de zoom très élevés, jusqu’à 900%.
Et quand on a des champs de saisie trop éloignés de leur étiquette, ça peut entraîner des confusions et erreurs de saisie, on pense renseigner un champ et on en renseigne finalement un autre.
Cet accolage des étiquettes à leur champ, c’est très important aussi pour les personnes avec des troubles de l’apprentissage.
Je vais peut-être accélérer un petit peu, je vois que le temps court.
Les champs obligatoires sont-ils indiqués ?

Toujours dans les formulaires, règle facile à tester aussi, c’est l’indication des champs obligatoires.
Dans un formulaire, ce qui est important, c’est de distinguer les champs obligatoires des champs facultatifs.
La première approche, c’est celle qu’a utilisée la Fondation Valentin Haüy. Ils ont utilisé une mention « Nécessaire » dans l’étiquette à côté de « Prénom », le champ est obligatoire, ils ont mis « Nécessaire ». Ils auraient pu utiliser le wording « Obligatoire », mais « Nécessaire » fonctionne.
L’autre approche, c’est de passer… Je vais cette fois-ci sur le blog d’Ideance, de passer par des astérisques (*) qui sont souvent utilisés dans les formulaires, qui sont entrés dans les mœurs.
Mais si vous utilisez un symbole pour indiquer que le champ est obligatoire, il est nécessaire, au tout début du formulaire, d’indiquer une légende qui précise que ce fameux astérisque est utilisé pour les champs obligatoires.
On le voit très souvent lors de nos audits, cette légende est souvent à la fin du formulaire. La règle d’accessibilité impose bien d’avoir cette légende sur le caractère obligatoire du champ en tout début de formulaire.
Les champs sont-ils reliés à leur libellé ?

Poursuivons sur notre vérification et évaluation de l’accessibilité des formulaires avec un autre test, cette fois-ci, qui va nous demander d’utiliser notre souris et de vérifier si les champs de saisie, les cases à cocher, les boutons radio sont bien reliés à leur libellé, à leur étiquette correspondante.
Une technique simple : vous prenez votre souris, je reviens sur le site Brest métropole, et vous cliquez sur les libellés à la souris.
Le comportement attendu, c’est que le focus soit donné au champ de saisie correspondant.
Si je clique sur « Prénom », j’ai mon curseur de saisie qui s’est mis automatiquement dans le champ correspondant.
Et ça, c’est une garantie que l’étiquette est bien rattachée techniquement à son champ, ce qui va nous garantir que c’est accessible pour certaines technologies d’assistance, dont les synthèses vocales ou plages braille.
Attention, il y a des faux positifs. La liste déroulante « Civilité », j’ai cliqué dessus et ça ne m’a pas donné le focus au champ. Mais en réalité, techniquement, j’ai vérifié au préalable, ces deux éléments sont bien reliés.
C’est pour ça que ce test, le clic sur les libellés pour donner le focus champ, peut engendrer des faux positifs, vous allez cliquer sur un élément, ça ne donnera pas le focus, mais en réalité, c’est bien fait.
C’est un test qui ne donnera pas tous les cas de figure mais qui donnera une idée du niveau d’accessibilité du formulaire.
Des aides à la saisie sont-elles présentes ?

Et dernier test sur la thématique formulaire, c’est de vérifier, seulement pour les champs dont la saisie attendue est spécifique et particulière, comme un format de date, comme un format de mot de passe, comme des restrictions pour une pièce jointe qui serait à mettre dans son formulaire, pour tout ce qui est champ susceptible d’engendrer des erreurs de saisie, il est important de proposer au préalable, c’est-à-dire au chargement de la page, et sans disparaître, des messages d’aide à la saisie.
Allons voir de nouveau, on va rester sur ce site… Oui, on reste sur la page « Contacter nos services » du site de Brest Métropole.
Nous avons un champ avec saisie particulière, c’est un champ d’upload de pièces jointes qui a des restrictions, il n’accepte que des fichiers en dessous de 5 Mo et des types autorisés qui sont seulement PDF, doc, docx, etc.
L’aide à la saisie est proposée au chargement de la page, ce qui évite de nombreuses erreurs de saisie et aussi pas mal de frustrations.
Autre exemple d’aide à la saisie, cette fois-ci, je me rends sur l’espace personnel du site TGV Inoui, dans le formulaire de création d’identifiant, nous avons un champ « Mot de passe » qui a des restrictions, huit caractères minimum, avec des majuscules, des minuscules et de nouveau des restrictions.
Cette aide à la saisie est proposée proche du champ de saisie concerné, elle est toujours apparente et proposée au chargement de la page.
Les aides à la saisie ne doivent pas être mises pour tous les champs, ce ne serait pas nécessaire dans un champ « Nom », « Prénom », etc.
Mais pour un champ « Date de naissance », une aide à la saisie de type « JJ/MM/AAAA » est pertinente.
Évaluer le niveau d’accessibilité des vidéos et des animations

Maintenant, voyons comment évaluer le niveau général d’accessibilité des vidéos, des animations et contenus animés.
Les vidéos ont-elles une transcription textuelle ?

La première chose qu’on peut faire, c’est vérifier que les vidéos, si elles sont informatives, qu’elles possèdent une transcription textuelle.
Une transcription textuelle, c’est la reprise de toutes les informations véhiculées par la vidéo au format texte. Soit sur la même page, soit sur une autre page du site Web.
Quand on parle de toutes les informations véhiculées par la vidéo, ça va être tout ce qui est dialogue, voix off, mais aussi les messages affichés à l’écran.
C’est particulièrement important pour de nombreuses personnes en situation de handicap, par exemple celles qui n’ont pas accès au player vidéo, ça peut être aussi utile aux personnes sourdes et malentendantes dans le cas où la vidéo n’est pas sous-titrée, ça peut être intéressant aussi pour les personnes aveugles ou malvoyantes si la vidéo n’est pas audiodécrite.
Comment vérifier ça ? C’est assez facile. Vous allez sur la page où il y a des vidéos, c’est ce qu’on va faire ensemble sur le site de l’Assurance Retraite. Aux alentours de la vidéo, vous vérifiez que vous avez accès à cette fameuse transcription textuelle. Ici, ils l’ont proposée via un système d’accordéon en dessous de la vidéo.
Et l’idée ensuite, c’est de vérifier que cette transcription textuelle reprend bien toutes les informations véhiculées par la vidéo.
Ici, ils ont fait le choix de faire un bouton plier-déplier, il y a d’autres approches comme celle du site des Aveugles de France qui, eux, ont décidé de proposer…
La vidéo est ici, et la transcription textuelle n’est pas sur la page en elle-même mais sur une page dédiée. J’ai cliqué dessus, une nouvelle page s’est chargée dans laquelle j’ai la transcription de la vidéo.
Voilà un test qui me semble assez facile à faire de votre côté.
Les vidéos ont-elles des sous-titres ?

Toujours sur le sujet des vidéos, test aussi uniquement visuel, c’est vérifier que les vidéos sont sous-titrées.
Critère très important, règle très importante pour les personnes déficientes auditives, c’est-à-dire sourdes et malentendantes, et les sous-titres doivent reprendre tous les contenus audios véhiculés par la vidéo (dialogue et voix off).
Les sous-titres doivent être suffisamment lisibles, c’est-à-dire contrastés.
Il ne faut pas qu’ils soient invisibles, c’est-à-dire très clairs sur fond très clair par exemple. Ils n’auraient plus beaucoup d’intérêt.
Et idéalement, les sous-titres devraient être affichables et masquables sur demande. C’est idéalement, car c’est déjà une bonne chose de proposer des sous-titres incrustés
Un exemple de vidéo bien sous-titrée : je me remets sur le site de l’assurance retraite, ils ont fait carrément ceinture et bretelle avec des sous-titres incrustés dans la vidéo, que vous voyez ici.
L’assurance retraite verse chaque mois la retraite dans plus de 180 pays
, c’est exactement ce que la vidéo vient de dire de manière audio, c’est bien sous-titré et incrusté, et les sous-titres de YouTube sont proposés. Il y a du sous-titrage incrusté et externalisé.
Voilà ce que vous pouvez vérifier.
Les animations sont-elles contrôlables ?

Dernière thématique : la navigation clavier. Je vais essayer d’aller plus vite… Ah, si, un point sur les animations à voir avec vous…
Il est attendu pour l’accessibilité que, dès lors que vous avez des contenus animés, ça peut être des vidéos d’arrière-plan (comme sur le site de Chronodrive) ou des carrousels animés.
Il est possible de proposer des animations, mais il faut proposer un moyen de les mettre en pause.
Ça se matérialise souvent par ce type de bouton. Ici, on a un bouton de mise en pause et de relance des animations.
Voilà ce que vous pouvez vérifier quand vous croisez des sites Web avec animation : est-ce qu’il y a la possibilité de les mettre en pause et de les relancer via un bouton physique ?
Je prends aussi le temps de vous présenter un autre exemple sur le site de l’AGEFIPH avec un carrousel animé, qui défile automatiquement, avec aussi un bouton de mise en pause et de relance du mouvement. Voilà un point que vous pouvez vérifier.
Ce bouton de mise en pause doit être bien visible et bien positionné, idéalement avant l’animation pour qu’il soit atteignable et utilisable facilement pour les personnes qui en ont besoin. Et elles sont assez nombreuses, il y a les personnes photosensibles, aveugles ou encore fortement malvoyantes, par exemple.
Tester la navigation au clavier

10h40…
La prise de focus est-elle visible ?

Dernière section, tester la navigation au clavier avec une première chose à tester qui est aussi abordable par tout un chacun, c’est de vérifier que la prise de focus est visible.
Pour tester une prise de focus, il s’agit de quitter sa souris et d’utiliser uniquement la touche de tabulation de son clavier.
Ce qu’on va faire, je vais aller sur un site Web qui gère ça très bien, on retourne sur le site de Spie, je quitte ma souris et j’utilise exclusivement mon clavier et la touche de tabulation et je vais parcourir tous les éléments interactifs présents dans la page (liens, boutons et éléments de formulaire).
Ce qu’il faut vérifier, c’est que j’ai bien un indicateur visuel suffisamment visible qui me présente, qui m’indique où je me situe lors de ma navigation au clavier.
Là, je suis en train d’appuyer sur la touche de tabulation et je vois que j’ai un contour bleu sur l’élément interactif sur lequel je me trouve. J’ai une belle visibilité du focus. Et ça, c’est très important pour les personnes déficientes motrices.
Deuxième exemple, cette fois-ci sur le site Ideance. Cette fois-ci, le contour est jaune, mais il est très lisible et suffisamment contrasté.
C’est le premier test que vous pouvez faire, qui est très important pour les personnes déficientes motrices qui n’utilisent pas de souris.
L’ordre de tabulation est-il logique ?

On peut aussi tester l’ordre de tabulation.
C’est : je tabule de la même manière que je l’ai fait pour vérifier ma visibilité de focus, mais cette fois-ci, je vérifie que l’ordre des éléments que j’atteins est logique, c’est-à-dire de haut en bas et de gauche à droite.
Il faut que ma navigation se fasse en Z, finalement.
Il ne faudrait pas que je tabule sur un premier élément dans l’en-tête, puis ensuite en pied de page, puis dans l’en-tête… Là, on serait face à un ordre de tabulation qui ne serait pas cohérent.
Il faut être sur quelque chose de logique et linéaire.
On a quelques particularités quand on a des fenêtres modales qui s’affichent, mais c’est un peu trop particulier pour évoquer ça aujourd’hui.
Et ce qu’il faut aussi surtout vérifier, mais c’est assez rare d’en croiser, c’est que le focus ne soit pas piégé.
Il peut arriver sur certains sites Web que le focus reste sur un élément et qu’on continue d’appuyer sur la touche de tabulation et que le focus reste coincé sur l’élément en question.
C’est un défaut extrêmement bloquant d’accessibilité, mais c’est assez rare d’en croiser, et heureusement.
L’interface fonctionne-t-elle au clavier seul ?

Ensuite et enfin, dernier test que je vous propose de faire, c’est peut-être le plus délicat et qui peut prendre le plus de temps, c’est de vérifier que toutes les interactions possibles sur une page Web, sur un site Web, avec une souris, soient possibles également avec un clavier seul.
S’il est possible d’activer des liens avec une souris, il faut vérifier qu’ils soient actionnables avec le clavier.
S’il y a des menus déroulants, des systèmes d’accordéon, des fenêtres modales, des infobulles qui fonctionnent à la souris, vérifiez qu’ils fonctionnent aussi avec le clavier.
Vérifiez aussi qu’on peut remplir la totalité des formulaires avec un clavier.
Je prends un petit exemple et après, je vais devoir arrêter pour laisser la place aux questions…
Je vais juste prendre un exemple sur le site de la fondation Valentin Haüy, qui possède un menu principal dont certaines entrées sont déroulantes.
J’utilise mon clavier, j’ai de nouveau quitté ma souris. Et je vais faire « Entrée » sur le bouton « Fondation » et je vérifie que le sous-menu s’affiche. C’est le cas.
Je rappuie sur « Entrée » pour vérifier que je peux masquer le menu. Ça marche aussi.
Voilà les actions que vous pouvez faire pour vérifier qu’un site est accessible avec un clavier.
Pour aller plus loin dans vos évaluations

Si vous voulez aller plus loin dans vos tests, on vous recommande…
Des ressources d’accessibilité numérique

On vous propose d’aller jeter un œil à une page de ressources que l’on maintient chez Ideance, qui est sectionnée avec deux sections qui pourraient vous intéresser pour poursuivre ces tests, vos évaluations de sites Web.
Une première section qui présente différents référentiels et différentes checklists de l’évaluation de l’accessibilité numérique, principalement Web. Attention, c’est un peu plus technique. C’est orienté spécialistes accessibilité.
Et une autre section qui pourrait aussi vous intéresser pour poursuivre vos tests, c’est une section qui concerne des outils de tests automatiques, pareil, à utiliser avec vigilance parce que ça nécessite une installation, ça nécessite de s’approprier l’outil, ça renvoie pas mal de faux positifs et de résultats qu’il faut être capable de décortiquer et de comprendre.
Je dirais que c’est un second niveau de vérification d’accessibilité. Mais si le sujet vous intéresse et si vous voulez gratter un petit peu plus, n’hésitez pas à aller jeter un œil à tout ça.
Merci

Merci pour l’écoute, merci pour votre présence.
Et place aux questions si vous en avez.
Des questions ?

Sébastien Delorme :
— Merci Johan. Il y a quelques questions pour lesquelles il y a eu des réponses dans le chat que je ne reprendrai pas.
N’hésitez pas à poser de nouvelles questions maintenant, je les reprendrai si besoin. Et je vais reprendre les questions qui n’ont pas eu de réponse.
Pour les plus simples, en termes de réponse, celles qui ont les réponses les plus courtes, une question de Julien qui, pour le rétrécissement de l’écran jusqu’à 320 pixels, demande : quid des tableaux ? Est-ce qu’il y a une exception à la règle pour le défilement horizontal ?
Johan Ramon :
— Tout à fait. Je vais aller dans le RGAA pour être sûr de ne pas vous dire des bêtises, qui détaille la règle.
La règle en question, je ne connais plus… c’est le critère 10.11… La plupart des règles d’accessibilité possèdent des cas particuliers, et justement, sur ce critère, sur cette règle de largeur de 320 pixels, on a une règle qui concerne les tableaux de données qui, eux, peuvent posséder une scrollbar horizontale.
Pour les tableaux de données, il faut, peu importe la taille de l’écran, que tous les contenus soient visibles. En espérant avoir bien répondu à la question.
Sébastien Delorme :
— J’ai une autre question, on va enchaîner sur les titres qui apparaissent dans le haut du navigateur. Quid d’une longueur maximale des <title>
si on a beaucoup de filtres, par exemple, sur un formulaire de recherche ?
Johan Ramon :
— Bonne question aussi.
L’accessibilité, sauf erreur de ma part, je n’ai jamais vu passer de restriction sur un nombre maximum de caractères dans une balise <title>
, elle pourrait accueillir 300, 400, 500 mots, ça ne retoquerait rien et ce serait conforme.
Après, c’est vrai qu’on va quand même recommander d’être assez court pour que ça ne soit pas trop verbeux.
Pour ce sujet des filtres, effectivement, on peut se retrouver sur des formulaires, des pages où il y a énormément de facettes, de filtres utilisables et actionnables et ça pourrait être non pertinent d’intégrer tous les filtres utilisés dans le <title>
parce qu’il deviendrait trop lourd et verbeux.
On peut donc trouver un compromis qui peut être, plutôt que de préciser tous les filtres utilisés, indiquer dans le <title>
le nombre de filtres utilisés.
Exemple : « Résultats de recherche pour le terme « handicap » (cinq filtres utilisés, page 2/3) », plutôt que « Filtre actualité, filtre date, filtre 2023 » etc., qui rendraient le <title>
beaucoup trop long.
Sébastien Delorme :
— Je pense qu’on a encore la possibilité de gérer deux ou trois questions.
J’ai une question… Je ne suis pas sûr qu’on ait la réponse très précise, la question est : par défaut, les formulaires de Google sont-ils accessibles ? Je vais répondre pour Johan…
J’aurais tendance à préciser que, d’expérience, on est sur des niveaux d’accessibilité plutôt bons mais on n’est pas à l’abri de problèmes qu’on pourrait rencontrer. Mais d’expérience, c’est plutôt correct.
Il y a un sujet qui a l’air de passionner les foules parce que j’ai eu plein de + 1 sur ces questions, c’est la question de la représentation visuelle du focus.
Du coup, est-ce que la représentation visuelle du focus par défaut des différents navigateurs permet de toujours obtenir quelque chose de visible ou est-ce qu’il faut revenir dessus ? C’est une question de Julien. Il y a eu pas mal de personnes qui sont intéressées par la réponse.
Johan Ramon :
— Il y a eu d’énormes évolutions des navigateurs, Firefox ou Chrome, sur l’amélioration de la visibilité du focus.
D’après plusieurs tests que j’ai menés il y a quelque temps maintenant, auparavant, les navigateurs affichaient le focus qui était auparavant des pointillés, au clic souris, ce qui avait tendance à faire qu’ils étaient supprimés car estimés disgracieux.
Première amélioration que les navigateurs ont fait, c’est que ça ne s’affiche plus au clic souris. Là, je viens de cliquer sur « Faire un don » sur le site de la fondation Valentin Haüy, le contour ne s’est pas affiché.
A l’époque, le contour s’affichait, ça ne plaisait pas et il était supprimé en CSS, ce qui causait du tort à l’accessibilité.
Maintenant, l’outline ne s’affiche plus au clic souris. Et maintenant, ce n’est plus un contour mais un beau liseré dont la couleur s’adapte à l’arrière-plan et ça aussi, c’est une énorme évolution.
Sur « Faire un don », l’arrière-plan est doublé de deux couleurs. L’outline est à la fois avec un contour bleu et un contour blanc.
Le contour blanc, il est là pour garantir que le focus soit visible si la couleur d’arrière-plan est foncée, et le contour bleu est là pour garantir que le focus est visible si l’arrière-plan est clair.
Notez aussi, je rentre un peu plus dans la technique… Je ne vais pas l’avoir… Bon, je ne vais pas faire la manipulation, mais il est possible dans des paramétrages cachés de Firefox et de Chrome, en tant qu’utilisateur, de changer la couleur et d’autres aspects de l’outline, donc une personne déficiente motrice qui ne serait pas à l’aise avec l’outline par défaut peut aller dans « about:config » de Firefox et demander qu’elle soit rouge par exemple, mais je demande de ne pas surcharger l’outline des navigateurs, mais vraiment de laisser cet outline géré par le navigateur, c’est la meilleure façon de couvrir tous les cas de figure et que votre focus soit toujours visible.
Sur le site d’Ideance, on l’a fait, on a surchargé la visibilité du focus pour qu’il soit jaune, mais on a fait les tests sur l’entièreté de notre site Web, qui est assez restreint, mais quand on surcharge un outline, on a des risques que ça passe sur certaines superpositions mais pas sur d’autres.
Donc, je vais me répéter, mais à titre personnel, je recommande de ne pas toucher l’outline du navigateur et de s’en contenter.
Sébastien Delorme :
— Je vais prendre une dernière question, je suis désolé, on ne pourra pas prendre toutes les questions, il y en a quelques-unes sur lesquelles il n’y aura pas eu de réponse mais je complèterai en précisant où vous pourrez trouver des réponses.
Il y a une question, je vais juste prendre la réponse, sur les entreprises concernées par l’obligation, est-ce que c’est une obligation de résultat, est-ce que le site doit être 100% accessible ou est-ce qu’il y a un minima ?
On sort un petit peu de l’objet du webinaire mais on a tendance à limiter l’accessibilité à la publication d’une déclaration d’accessibilité, mais la loi est claire, c’est une obligation de résultat.
Les organismes doivent être accessibles et conformes au RGAA entre autres, et ensuite, pour l’instant, les sanctions sont plutôt sur la non-transparence sur ces sujets mais l’obligation légale est bien sur l’obligation de résultat.
Il y avait une autre question qui était : est-ce qu’il existe des outils pour rendre accessibles sur le pack office de Microsoft sur les posts LinkedIn ?
Il existe plus que des outils, en fait, c’est plutôt des bonnes pratiques ou des règles à respecter quand on va concevoir nos contenus sur ces plateformes, en espérant qu’effectivement, elles aient la capacité de mettre un texte de remplacement, par exemple, ou à nous offrir la possibilité de mettre un texte de remplacement par exemple…
Sur la partie pack office de Microsoft, il y a un webinaire qui commence à 11h qui est animé par Jennifer, je vous mets le lien dans le chat pour y accéder directement si vous n’y êtes pas inscrit.
Pour LinkedIn, c’est cet après-midi, il y a un webinaire sur l’accessibilité des réseaux sociaux, ce sujet sera probablement abordé.
Pour Place In Canvas, c’est plus spécifique, on pourra y répondre par mail, donc, si vous avez des questions, n’hésitez pas à envoyer un mail à Johan.
L’ensemble des supports, des vidéos enregistrées ou parfois des résumés ou listes de bonnes pratiques seront disponibles sur notre blog, j’ai remis le lien dans le chat, c’est ideance.net/blog.
N’hésitez pas à aller consulter tout ça. Ça nous prendra quelques jours le temps de tout agréger.
Merci pour votre participation et l’intérêt que vous portez à l’accessibilité.
Je suis obligé de couper cinq minutes plus tôt afin de laisser à nos interprètes le temps de souffler un peu avant de se connecter sur la session suivante, idem pour les vélotypistes.
Le lien pour le sous-titrage reste le même et le lien pour le webinaire suivant, vous le retrouvez sur le blog également, je l’ai transmis aussi. Merci encore et à très bientôt.
Bonne suite de GAAD à toutes et tous

Johan Ramon :
— Merci aux interprètes LSF et au sous-titrage et à tout le monde pour votre présence. Bonne suite de GAAD à tout le monde.

Article publié par
Johan RamonResponsable et expert accessibilité numérique