Par M.Benassaya – User eXperience & Accessibility Expert chez SQUAD

Dans un contexte sociétal où l’évolution technologique a pris énormément d’ampleur et continue chaque jour de s’intégrer dans notre quotidien, le web a été un moteur puissant et facilitateur dans le développement des nouveaux usages et des nouvelles technologies. D’ailleurs, son impact ne se cantonne pas uniquement à un rôle de tremplin car le web reste à l’heure actuelle un rouage essentiel dans notre nouvel écosystème où tout se dématérialise. De l’administration à l’éducation, en passant par la culture et d’une manière plus générale, les relations humaines, le web est au cœur de notre quotidien et nous fournit un accès à l’information vaste et étendu. Cette notion d’ubiquité (fait d’être présent partout à la fois ou en plusieurs lieux en même temps.Larousse) numérique, où l’information et l’interaction sont partout et permanentes, doit nous ramener aux notions d’égalité et d’autonomie dans l’accès à l’information. En effet, la « simple » mise à disposition de l’information ou de services suffit – elle à être exploitée et exploitable par tous ?

La réponse est non car le contexte d’utilisation d’un site web est prépondérant pour rendre compte de son utilisabilité, c’est-à-dire la capacité à être utilisé par des utilisateurs identifiés, pour atteindre des objectifs précis avec efficacité, efficience et satisfaction tel que la norme ISO 9241 – 11 le définit (ISO, 1998). Cette définition nous indique que l’universalité du web est fortement liée, voire même ne prend sens, que par la prise en compte des variabilités individuelles dans l’interaction et des besoins spécifiques inhérents à chaque type de personnes. Par exemple, un utilisateur en situation de déficience visuelle ne naviguera pas de la même manière, ni avec les mêmes stratégies et outils qu’un utilisateur voyant. Les personnes non-voyantes vont avoir recours à des aides techniques, tel qu’un lecteur d’écran et/ou une plage braille pour réaliser leur tâche de navigation. Le web et son évolution devraient être pour les personnes en situation d’handicap synonyme de révolution du fait des services en lignes qui permettent la réalisation de certaines tâches quotidiennes et/ou administratives sans avoir à se déplacer et/ou être autonome. Or le constat est tout autre : l’inaccessibilité des sites web se révèle être une source d’exclusion. C’est en ce sens que la fracture numérique existe car cette mise à disposition d’informations ne suffit pas à garantir l’accès à l’information.

C’est la raison pour laquelle, les institutions gouvernementales de différents pays ont décidé de poser un cadre légal et réglementé sur l’accessibilité numérique afin de rendre accessible les sites web (En France la loi du 11 Février 2005 pour « l’égalité des droits et des chances » impose aux divers services de communication publique d’être accessible aux personnes en situation d’handicap. Cependant la loi tend à évoluer à s’étendre à l’ensemble des sites web des secteurs public et privé). Pour ce faire, ces institutions ont mis à disposition des règles de conception à destination des concepteurs d’interfaces web. Ces règles de conception sont basées sur le référentiel standard et international WCAG (Web Content Accessibility Guidelines) (WCAG, 1999). Ces règles expliquent comment concevoir un site web accessible à travers un ensemble de préconisations. La mise à disposition de ces normes a pour but de sensibiliser et de guider les concepteurs pour développer des sites accessibles et compatibles avec les aides techniques. L’élaboration de ces normes d’accessibilité sont liés à la création de l’initiative sur l’accessibilité du web (Web Accessibility Initiative, WAI) (1997) par le W3C. La première version de ce référentiel consécutive à la création de WAI date de 1999 mais d’autres versions ont suivi afin de s’adapter aux évolutions technologiques, graphiques et interactives du web.

L’histoire

Afin de situer l’arrivée de la version 2.1 des normes WCAG, il est important de retracer brièvement la genèse et les grandes étapes de l’accessibilité au travers du W3C et du référentiel WCAG.

En termes d’évolution, la WCAG 1.0 comportait 14 directives dont les 11 premières visaient à assurer une transformation « élégante » du contenu dans les différents contextes utilisateurs (par exemple, fournir des alternatives équivalentes aux contenus visuels et auditifs ou encore ne pas s’en remettre exclusivement aux couleurs). Leur champ d’application portait essentiellement sur des contenus HTML.

En 2008, Les WCAG 2.0 quant à elles, capitalisaient non seulement sur des règles de la WCAG 1.0 mais élargissaient leur champ d’application à plusieurs types de technologies (par exemple : CSS, XML, Silverlight, Flash, PDF, etc.). L’accent était également mis sur la facilité d’appropriation et d’implémentation en aidant les concepteurs à intégrer ces normes via un guide explicatif aussi bien en termes d’intégration que d’évaluation. Une autre évolution concerne la structuration des directives. La WCAG 2.0 se revête d’une approche thématique orientée sur 4 principes fondamentaux des contenus :

• Perceptibles
• Utilisables
• Robustes
• Compréhensibles

Dans chacun de ces principes sont répartis les 12 directives générales qui elles-mêmes se décomposent en un ou plusieurs critères de succès de niveau A, AA (Niveau légal en France et dans de nombreux pays) et AAA.

L’extension de la WCAG 2.0 (WCAG, 2008) vers la 2.1 (WCAG, 2018) comporte donc le rajout de directives dans lesquelles sont précisées de nouveaux critères de succès. Cependant, la construction de la version 2.1, à l’image des précédentes versions, est un processus itératif qui a conduit à des modifications / suppressions des directives et de critères pensés initialement.

La WCAG 2.1, des modifications passées et à venir

Le groupe de travail visant à produire cette extension 2.1 de la WCAG a été créé depuis l’été 2016 (Access42, 2017)). Un an plus tard, une première version du document de travail est mise à disposition et présente 3 nouvelles directives, à savoir (Access42, 2017) :

√ Directive 2.5 – pointeur accessible : L’objectif est de faciliter l’utilisation de la fonctionnalité des pointeurs par les utilisateurs. Elle devrait définir la façon dont les sites web doivent prendre en charge tous les types de pointeurs (souris, toucher, stylet…). En Août 2017, cette directive était sujette à discussion et susceptible d’être supprimée. En Janvier 2018, le groupe de travail a statué sur la préservation de la directive et des critères associés.

√ Directive 2.6 – capteurs de données supplémentaires : S’assurer que les inputs des capteurs de l’appareil ne constituent pas une barrière pour les utilisateurs. Cette règle est spécifiquement dédiée aux terminaux mobiles. Elle demande par exemple à ce que la consultation d’un contenu soit indépendante de l’orientation du terminal.

X Directive 2.7 – vocal : Permettre aux utilisateurs qui naviguent via la modalité orale de pouvoir prédire les noms des composants d’interface à énoncer. Elle nécessite que l’étiquette d’un composant interactif soit comprise dans le label de l’élément. Cette directive n’a pas été préservée, cependant le seul critère associé a été reporté dans la directive existante « 2.4 – Navigable ».

Le W3C fonctionne en groupe de travail qui mettent à disposition des ébauches de documents de travail au fur et à mesure de leur avancement. Ceci permet de recueillir des retours sur la pertinence et la faisabilité des recommandations présentes dans leurs documents. C’est la raison pour laquelle en l’espace de quelques mois, des modifications sont apportées au document de travail. D’ailleurs la version de la WCAG 2.1 que nous présentons ci-après, tend à être de nouveau modifiée car certains critères sont présentés « à risques ». Le document en date du 30 Janvier est en phase de « Candidate Recommendation », qui vise à tester et à améliorer le niveau d’implémentation des recommandations. La version finale et validée du document est prévue pour Juin 2018.

 Les nouveaux critères de la WCAG 2.1

Dans cette version de la WCAG 2.1, il y a au travers des deux nouvelles directives vues précédemment (2.5 et 2.6) et répartis dans d’autres directives, 17 critères en plus. Les voici, organisés selon le niveau d’obligation (Les critères à risques sont marqués par le pictogramme :).

NIVEAU A

• 2.4.11 Raccourcis de touches de caractères : Si un raccourci clavier est implémenté dans le contenu en utilisant uniquement des lettres (y compris les lettres majuscules et minuscules), des signes de ponctuation, des chiffres ou des symboles, alors au moins l’un des éléments suivants est vrai :

1. Arrêter : Un mécanisme est disponible pour désactiver le raccourci
2. Reprendre : Un mécanisme est disponible pour relancer le raccourci afin d’utiliser un ou plusieurs caractères clavier non imprimables (par exemple Ctrl, Alt, etc.).
3. Actif seulement au focus : Le raccourci clavier pour un composant d’interface est seulement actif lorsque le composant a le focus.

• 2.4.12 Etiquette dans le nom :  pour les composants de l’interface utilisateur avec des étiquettes qui incluent du texte ou des images de texte, le nom contient le texte présenté visuellement.
• 2.5.1 Gestuelles de pointeur : Toutes les fonctionnalités qui utilisent des gestes multipoints ou des trajectoires pour l’opération peuvent être utilisées avec un seul pointeur sans un geste basé sur le chemin, à moins qu’un geste multipoints ou un geste basé sur le chemin soit essentiel.

2.5.2 Annulation du pointeur : Pour les fonctionnalités qui peuvent être exploitées à l’aide d’un seul pointeur, au moins un des points suivants est vrai :

1. Pas de down event : Le down-event du pointeur n’est pas utilisé pour exécuter une partie de la fonction
2. Interrompre ou annuler : L’achèvement de la fonction est associé à l’up – event est un mécanisme disponible pour interrompre la fonction avant l’achèvement ou annuler la fonction après l’achèvement
3. Inversion par l’up -event : L’up – event inverse tout résultat du down event précédent ;
4. Essentiel : Il est essentiel de compléter la fonction lors du down-event.

• 2.6.1 Activation par le mouvement : La fonctionnalité qui peut être commandée par le mouvement de l’appareil ou le mouvement de l’utilisateur, peut également être commandée par des composants de l’interface utilisateur , ainsi la réponse au mouvement peut être désactivée pour empêcher un déclenchement accidentel, sauf lorsque :

1. Interface compatible : Le mouvement est utilisé pour faire fonctionner la fonctionnalité via une interface compatible avec l’accessibilité
2. Essentiel : Le mouvement est essentiel pour la fonction est cela invaliderait l’activité

NIVEAU AA

• 1.3.4 Identifier les objectifs communs : La définition de chaque champ de saisie recueillant des informations sur l’utilisateur peut être déterminée par programmation quand :

1. Le champ de saisie a une définition qui correspond aux noms des champs HTML 5.2 Remplissage automatique.
2. Le contenu est mis en œuvre à l’aide de technologies qui permettent d’identifier la signification attendue des données d’entrée de formulaires.

• 1.4.10 Recomposition des contenus : Le contenu peut être présenté sans perte d’information ou de fonctionnalités, et sans avoir à défiler dans deux dimensions. En d’autres termes, le contenu peut être agrandi jusqu’à 400% sans perte de contenu et sans utilisation de l’ascenseur horizontal pour un contenu présenté verticalement. Inversement pour un contenu présenté horizontalement.

• 1.4.11 Contraste pour les éléments non – textuels : La présentation visuelle des éléments suivants présente un rapport de contraste d’au moins 3:1 par rapport aux couleurs adjacentes :

1. Composants d’interfaces : Information visuelle utilisée pour indiquer les états et les délimitations des composants de l’interface, excepté pour les composants inactifs ou si l’apparence du composant est déterminée par l’agent utilisateur ou non modifié par l’auteur.
2. Objets graphiques : éléments graphiques nécessaires à la compréhension du contenu, excepté lorsqu’une présentation graphique particulière est essentielle à la transmission de l’information.

• 1.4.12 Espacement des textes : Dans le contenu implémenté en utilisant des langages de balisage qui supportent les propriétés de style de texte suivantes, aucune perte de contenu ou de fonctionnalité ne se produit en définissant tout ce qui suit et en ne changeant aucune autre propriété de style :

1. Hauteur de ligne au moins égale à 1,5 fois la taille de la police
2. Espacement des lettres d’au moins 2 fois la taille de la police
3. Espacement des lettres d’au moins 0,12 fois la police
4. Espacement des mots d’au moins 0,16 fois la taille de police

Exception : Les langages humains et les scripts qui n’utilisent pas une ou plusieurs de ces propriétés de style de texte dans un texte écrit peuvent se conformer en utilisant uniquement les propriétés qui sont habituelles.

• 1.4.13 Contenu au survol ou au focus : Lorsque l’entrée et la sortie du survol du pointeur ou du focus du clavier déclenche un contenu supplémentaire pour devenir soit visible et caché, respectivement, ce qui suit est vrai :

1. Rejetable : Un mécanisme est disponible pour rejeter le contenu supplémentaire sans déplacer le pointeur ou le focus du clavier, à moins que le contenu supplémentaire ne communique : une erreur d’entrée, ne masque ou ne remplace pas un autre contenu
2. Survolable : Si le survol du pointeur peut déclencher le contenu supplémentaire, alors le pointeur peut être déplacé sur le contenu supplémentaire sans que celui-ci ne disparaisse
3. Persistant : Le contenu supplémentaire reste visible jusqu’à ce que le déclencheur de survol ou de mise au point soit : supprimé, que l’utilisateur le rejette ou que ses informations ne soient plus valides

• 2.6.2 Orientation : Le contenu ne limite pas sa vue et son fonctionnement à une seule orientation d’affichage, comme le portrait ou le paysage, à moins qu’une orientation d’affichage spécifique ne soit essentielle.
• 3.2.6 Changement de statut : Dans le cas d’un contenu implanté à l’aide de langage de balisage, les messages de statut peuvent être déterminés par programmation au travers des rôles ou des propriétés, de sorte qu’ils peuvent être présentés à l’utilisateur via des technologies d’assistance sans recevoir le focus.

NIVEAU AAA

• 1.3.5 Identifier l’objectif : Dans le cas d’un contenu implémenté en utilisant des langages de balisage, l’objectif des composants d’interface utilisateur, des icônes et des régions peuvent être déterminés par programmation.
• 2.2.6 Fin de session : Les utilisateurs sont avertis de la durée de toute inactivité de l’utilisateur qui pourrait entraîner une perte de données, à moins que les données ne soient conservées pendant plus de 20 heures, lorsque l’utilisateur ne réalise aucune action.
• 2.2.7 Animation à partir d’interaction : L’animation en mouvement déclenchée par l’interaction peut être désactivée, à moins que l’animation ne soit essentielle à la fonctionnalité ou à l’information véhiculée.
• 2.5.3 Taille de cible : la taille de la cible pour les entrées de pointeur est d’au moins 44 par 44 pixels CSS excepté quand :

1. Équivalent : La cible est disponible via un lien ou un contrôle équivalent sur la même page qui est d’au moins 44 x 44 pixels CSS
2. En ligne : La cible est dans une phrase ou un bloc de texte
3. Contrôle de l’agent utilisateur : La taille de la cible est déterminée par l’agent utilisateur et n’est pas modifiée par l’auteur
4. Essentiel : Une présentation particulière de la cible est essentielle à l’information communiquée.

• 2.5.4 Mécanismes d’entrée simultanées : le contenu web ne limite pas l’utilisation des modalités d’entrée disponibles sur une plate-forme, sauf si la restriction est essentielle, nécessaire pour assurer la sécurité du contenu, ou requise pour respecter les paramètres de l’utilisateur.

Conclusion, si neuf années ont été nécessaires pour fournir une deuxième version de la WCAG et dix autres pour arriver à l’extension 2.1, cela laisse entrevoir la difficulté de pouvoir corréler positivement les solutions de la WCAG avec l’évolution fulgurante des diverses méthodes, technologies et tendances du web. C’est bel et bien ce qu’essaye de faire le W3C avec cette extension. L’accent est mis sur les exigences concernant les interfaces mobiles, le contrôle vocal ou encore pour palier à certaines déficiences visuelles et cognitives impactées par la richesse informationnelle et interactive des interfaces.

Le constat est que malgré l’existence des WCAG, peu de sites sont accessibles. Plusieurs études menées par l’Union Européenne indiquent que moins de 20% des sites évalués sont conformes aux normes d’accessibilité (Union Européenne, 2005). Les explications de ce chiffre se trouvent dans une étude réalisée auprès de 189 concepteurs (Lespinet-Najib, 2014) sur leur perception de l’accessibilité. Les auteurs observent qu’un répondant sur deux considère que rendre un site accessible représente un coût économique plus élevé qu’un site non-accessible ; un répondant sur trois associe l’accessibilité avec une pauvreté graphique rendant le site peu attractif et peu dynamique ; un répondant sur deux considère qu’il est plus complexe de mettre en œuvre un site accessible qu’un site non accessible. Derrière ces résultats se cachent non seulement une véritable méconnaissance des normes mises en place mais aussi certaines difficultés de compréhension et d’application des normes. En effet, le caractère très général des normes WCAG 2.0 s’accommode difficilement de la grande hétérogénéité des projets de conception. Elles sont donc fortement soumises à l’interprétation des concepteurs, et par conséquent très subjectives dans leur application.

Malgré les évolutions indéniables qu’apportent les WCAG 2.1 en termes d’accessibilité et de couverture des différents contextes d’utilisation, il apparaît coercitif de prendre en compte certains critères sur des sites existants sans repartir de zéro avec toutes les contraintes budgétaires et techniques qu’une telle refonte occasionne (par exemple : 2.4.10 – l’exigence de recomposition des contenus).

L’objectif de la WCAG 2.1 est d’apporter une première passerelle vers les WCAG 3.0 (Mediacurrent, 2018) qui représentent un chantier conséquent en perspective. Il n’est donc pas impossible d’avoir d’autres extensions et versions de ces recommandations avant d’aboutir à la WCAG 3.0. Cependant, à la vue des chiffres sur la mise en conformité des sites web et de la faible adoption de la WCAG 2.0 par les concepteurs, les nouvelles obligations techniques de la WCAG 2.1 peuvent se révéler trop complexe à mettre en place. Il est donc possible que ce pont si important vers les WCAG 3.0 soit infranchissable pour un grand nombre de concepteurs et ne permettent pas aux personnes en situation d’handicap d’accéder à l’univers du web.

Références
Access42 (2017). Les nouveautés des WCAG 2.1. 10 Août 2017. [En ligne]. Consulté le 6 Février 2018 sur https://access42.net/nouveaute-wcag

Accessibility of public sector services in the European Union (2005). Rapport de l’UK presidency of the UE. Web accessibility in European countries: level of compliance with latest international accessibility specifications, notably WCAG 2.0 and approaches or plans to implement those specifications (2009). Rapport de European Union.

Lespinet-Najib, V., Pinède, N., Belio, C., Demontoux, C., et Liquète, V. (2014). L’accessibilité Web, en 2013, en France : Enquête nationale sur les pratiques et les usages des professionnels du Web. Terminal [En ligne], 116 | 2015, mis en ligne le 25 décembre 2014, consulté le 12 Mai 2017. URL : http://terminal.revues.org/649 ; DOI : 10.4000/terminal.649

Mediacurrent (2018). Accessibility updates: WCAG 2.1. 29 Janvier 2018. [En ligne]. Consulté le 6 Février 2018 sur http://www.mediacurrent.com/blog/accessibility-updates-wcag-21

Organisation international de normalisation (ISO) (Ed., 1998). Ergonomic requirements for office work with visual display terminals (VDTs) – Part 11: Guidance on usability (ISO 9241-11).

W3C. (2008). Web Content Accessibility Guidelines (WCAG) 2.0. Consulté le 15 Février 2017 à http://www.w3.org/TR/WCAG20/.

Web Content Accessibility Guidelines (WCAG) 1.0 (1999). W3C Recommendation. World Wide Web Consortium (W3C). Consulté le 6/02/2018 à l’adresse suivante : http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505

Web Content Accessibility Guidelines (WCAG) 2.0 (2008). W3C Recommendation. World Wide Web Consortium (W3C). Consulté le 6/02/2018 à l’adresse suivante : http://www.w3.org/TR/2008/REC-WCAG20-20081211/

Web Content Accessibility Guidelines (WCAG) 2.0 (2018, 30 January). W3C Candidate Recommendation. World Wide Web Consortium (W3C). Consulté le 6/02/2018 à l’adresse suivante : https://www.w3.org/TR/WCAG21/#abstract

 World Wide Web Consortium (W3C) (1997). World Wide Web Consortium Launches International Web Accessibility Initiative. Communiqué de presse, 7 avril 1997