Propulsé par le RAAMM

Robuste

Le problème

Certains types d’erreur d’encodage HTML peuvent créer des problèmes aux lecteurs d’écran.

De plus, les mécanismes permettant l’interactivité ne sont pas toujours perceptibles ou utilisables avec les technologies d’adaptation informatique. Toutes les fonctionnalités d’interactivité doivent donc être soigneusement testées avec ces outils. Lorsqu’il n’est pas possible d’assurer la compatibilité, il faut s’assurer que les contenus sont utilisables sans ces fonctionnalités, même si elles contribuent à l’enrichissement de l’expérience de l’utilisateur.

La solution

Validation du code

Dans WCAG 1.0, on exigeait une validation complète du code en priorité de niveau 2.

Depuis WCAG 2.0, cette exigence a été réduite aux types d’erreurs qui peuvent poser problème du point de vue de l’accessibilité.

Il faut aussi noter qu’il s’agit maintenant d’une exigence de niveau A.

Utilisation de JavaScript

À propos de l’utilisation de JavaScript, WCAG 1.0 est beaucoup plus sévère que WCAG 2.0, ce qui s’explique en partie par le fait qu’en 1999, le support de JavaScript dans les outils d’adaptation informatique était très déficient.

Dans WCAG 2.0, on n’exige plus que la page demeure utilisable sans JavaScript, mais plutôt que l’utilisation de JavaScript soit compatible avec les technologies d’adaptation informatique (donc conforme au Document Object Model (DOM) du W3C). – Voir les techniques de programmation proposées par le W3C (en anglais).

Si vous utilisez des menus déroulants :

Si le système de navigation comporte des menus déroulants ou présenté sous forme d’arborescence, mais que l’en-tête de chacun des menus conduit à une page intermédiaire où l’on retrouve tous les liens contenus dans le menu déroulant, ce menu est tout de même jugé accessible, puisque l’utilisateur dispose d’un autre moyen pour accéder au même contenu.

Deux techniques peuvent être utilisées pour rendre un menu déroulant accessible :

  1. La Boite à outils de l’expérience Web propose un menu basé sur l’utilisation des techniques WAI-ARIA prévue à cet effet. Ce type de composant interactif oblige cependant l’utilisateur d’un lecteur d’écran a passer en « mode interactif » aussi appelé « mode formulaire », ce qui peut être un peu déroutant au début. Une aide contextuelle est donc souhaitable pour donner à l’utilisateur un minimum d’information sur son utilisation.
  2. Le site du Laboratoire de promotion de l’accès à l’information propose une façon simple de configurer des accordéons. Dans cet exemple, les boutons déclencheurs sont enchassés dans des titres de niveau 2. Dans un menu qui utiliserait cette technique, ce devrait plutôt être des éléments de liste et un texte hors écran devrait préciser que le bouton donne accès à un sous-menu.

Si vous utilisez des objets programmes :

Si vous incorporez des objets programmes à vos pages, ceux-ci doivent être accessibles avec les logiciels d’adaptation, et vous devez donc les tester pour vous en assurer.

La compagnie SUN a investi beaucoup d’effort pour permettre la réalisation d’applet ou d’applications Java accessibles : http://java.sun.com/products/jfc/accessibility/

Notes : Une simple recherche en français sur les mots « java » et « accessibilité » peut également vous fournir une multitude de références en français.

Si vous utilisez des pages dont le contenu est mis à jour sans rechargement de la page :

Le contenu modifié de façon dynamique doit répondre aux trois conditions suivantes :

  • Le contenu généré doit être accessible.
  • Le concepteur doit prévoir une façon d’avertir l’utilisateur de toute mise à jour du contenu.
  • L’utilisateur doit disposer d’un moyen simple de se déplacer à ce nouveau contenu.

Notes :

  1. Le W3C a développé une spécification appelée WAI-ARIA. Il met aussi à jour périodiquement des notes sur l’utilisation d’ARIA en HTML et un guide de bonnes pratiques WAI-ARIA 1.1.
  2. Il est évidemment toujours possible de proposer une version de remplacement de ce contenu, version qui ne ferait pas appel à ce type de fonctionnalités.

Si un message d’état apparait à l’écran :

Il s’agit d’un nouveau critère de succès introduit pas WCAG 2.1. Il y a deux critères principaux qui déterminent si quelque chose répond à la définition d’un message d’état:

  1. le message fournit à l’utilisateur des informations sur le succès ou les résultats d’une action, sur l’état d’attente d’une application, sur la progression d’un processus ou sur l’existence d’erreurs;
  2. le message n’est pas délivré via un changement de contexte comme un déplacement du focus ou l’apparition d’une boite de dialogue.

Des informations peuvent être ajoutées aux pages sans que cela correspondent à la définition d’un message d’état. Par exemple, la liste des résultats obtenus à partir d’une recherche n’est pas considérée comme un message d’état et n’est donc pas couverte par ce critère de succès. Toutefois, les courts messages texte affichés sur l’achèvement ou l’état de la recherche, tels que "Recherche …", "18 résultats trouvés" ou "Aucun résultat trouvé" sont des message d’état s’ils ne reçoivent pas le focus.

Ces messages d’état peuvent être transmis en utilisant l’une des deux techniques ARIA suivantes : le role=aler ou l’attribut aria-live.

Vous trouverez des explications beaucoup plus complètes ainsi que de nombreux exemple dans la section : Understanding Success Criterion 4.1.3 Status Messages.

Les règles qui s’appliquent à la compatibilité avec les outils d’adaptation

4.1.1 Analyse syntaxique (niveau A) : à moins que les spécifications ne le permettent, dans un contenu implémenté via un langage de balisage, les éléments ont des balises de début et de fin complètes, ils sont imbriqués conformément à leurs spécifications, ils ne contiennent pas d’attributs dupliqués et chaque ID est unique.

Note : les balises de début et de fin auxquelles il manque un caractère critique, comme un chevron fermant ou un guillemet pour une valeur d’attribut, sont considérées incomplètes.

4.1.2 Nom, rôle et valeur (niveau A) : pour tout composant d’interface utilisateur (comprenant mais n’étant pas limité aux éléments de formulaire, liens et composants générés par des scripts), le nom et le rôle peuvent être déterminés par un programme informatique ; les états, les propriétés et les valeurs qui peuvent être paramétrés par l’utilisateur peuvent être définis par programmation ; et la notification des changements de ces éléments est disponible aux agents utilisateurs, incluant les technologies d’assistance.

Note : ce critère de succès s’adresse d’abord aux auteurs qui développent ou programment leurs propres composants d’interface utilisateur. Toutefois, les contrôles HTML standards se conforment déjà à ce critère de succès lorsqu’ils sont utilisés conformément à la spécification.

4.1.3 Status Messages (Level AA) : In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Voir aussi :

  1. Version française pour WCAG 2.0 :
    1. Comprendre le critère de succès 4.1.1 Analyse syntaxique
    2. Comprendre le critère de succès 4.1.2 Nom, rôle et valeur
  2. Vérifier les différences avec la version anglaise révisée du 5 septembre 2013 :
    1. Understanding Success Criterion 4.1.1 Parsing
    2. Understanding Success Criterion 4.1.2 Name, Role, Value
    3. Understanding Success Criterion 4.1.3 Status Messages