Recommandations d'accessibilité pour XUL

Introduction

Bienvenue dans les recommandations d'accessibilité pour XUL. En suivant ces principes et pratiques, vous pourrez écrire des applications XUL de manière à ce que tous les utilisateurs, même ceux souffrant de handicaps physiques, sensoriels ou communicatifs puissent l'utiliser et l'apprécier. L'accessibilité n'a rien de difficile, mais nécessite une compréhension basique des différents types de handicaps, des technologies assistives courantes et des fonctionnalités spéciales d'accessibilité fournies par le langage XUL. Plus que tout, l'accessibilité a besoin d'un effort conscient de votre part, et d'un désir d'intégrer tout le monde.

Nous espérons que ces recommandations seront suffisamment claires et détaillées pour que tout le monde — même ceux qui n'ont aucune expérience dans le domaine de l'accessibilité — puisse les comprendre. Il existe également une communauté de développeurs spécialisés dans l'accessibilité au sein du projet Mozilla qui n'hésiteront pas à vous aider pour toutes les inquiétudes et questions suscitées par le fait de rendre vos applications XUL entièrement accessibles.

Recommandations

Accès au clavier

L'accès au clavier est important pour les utilisateurs ne pouvant pas utiliser de souris. Beaucoup d'utilisateurs de lecteurs d'écran et de handicapés physiques s'appuient sur le clavier comme outil d'entrée principal. Ces utilisateurs ont besoin d'un contrôle au clavier aisé, prévisible et bien documenté.

Ordre de tabulation

Fournissez un ordre de tabulation logique et assurez-vous que les utilisateurs puissent naviguer parmi tout le contenu à l'aide d'un clavier. Par défaut, l'ordre de tabulation est déterminé par l'ordre des éléments dans le code sous-jacent. Il peut également être redéfini programmatiquement à l'aide de l'attribut tabindex si nécessaire, mais cela doit se faire avec modération et être testé en profondeur lorsqu'on l'utilise. L'ordre de navigation doit être logique, généralement de gauche à droite et de haut en bas. L'ordre de navigation peut varier selon la nature de l'application ou le sens de lecture de la langue utilisée.

Assurez-vous que l'ordre de tabulation est logique et que l'on puisse accéder à tous les éléments interactifs simplement sans utiliser de souris. Vous devriez arriver à effectuer toutes les tâches possibles, que ce soit directement dans l'application ou depuis des éléments du menu ou de menus contextuels.

Arbres

Fournissez une manière alternative d'effectuer les opérations inaccessibles. Le sélecteur de colonne et les en-têtes de colonne dans les arbres XUL ne sont pas accessibles au clavier, pour respecter le comportement standard des arbres sur la plupart des systèmes d'exploitations actuels. Il est donc nécessaire de fournir une alternative accessible au clavier pour accéder à ces fonctions.

Un exemple d'arbre plus accessible est visible dans le gestionnaire de marque-pages de Firefox. Celui-ci permet aux utilisateurs de trier les marque-pages selon une certaine colonne d'information et de choisir les colonnes à afficher. Comme les en-têtes de colonne et le sélecteur de colonne, dans le coin supérieur droit de l'arbre, ne peuvent pas recevoir le focus, ils ne sont pas accessibles au clavier. Dans le gestionnaire de marque-pages, cette fonctionnalité est rendue accessible au clavier via le menu Affichage.

Boutons de barres d'outils

Par défaut, les boutons de barres d'outils ne peuvent pas recevoir le focus depuis le clavier. La manière conseillée de remédier à ce problème est de dupliquer toute fonctionnalité associée avec une barre d'outils ailleurs dans l'application, via un élément de menu principal ou contextuel par exemple. Dans les cas où cette duplication n'est pas possible (comme dans une fenêtre sans barre de menus), il est possible de permettre aux boutons de barres d'outils d'obtenir le focus en ajoutant la règle CSS spéciale -moz-user-focus: normal. (La fenêtre d'aperçu avant impression de Firefox utilise cette technique de secours.) Cela ne doit se faire qu'en dernier ressort, et être cohérent au sein d'une même fenêtre (c'est-à-dire que soit tous les boutons sont accessibles au clavier, soit aucun ne l'est).

Raccourcis clavier

Les raccourcis clavier sont très utiles pour les utilisateurs devant naviguer au clavier. Il existe de nombreuses manières d'en fournir. Celles-ci sont bien documentées dans le Tutoriel XUL:Raccourcis clavier.

Il convient de faire particulièrement attention lors du choix des raccourcis clavier. Lors de la création d'une extension (que ce soit pour Firefox ou une autre application XUL), assurez-vous que les raccourcis clavier que vous définissez n'interfèrent pas avec ceux déjà définis par l'application de base. Reportez-vous aux ressources suivantes lors de la définition de raccourcis clavier.

Menus contextuels

Le menu contextuel est le petit menu activé par un clic droit de la souris sur une zone de contenu ou un élément (ou à l'aide de Shift + F10 ou VK_APPS sous Windows et Ctrl + Click ou Ctrl + Espace sur un Mac). Utilisez le gestionnaire d'évènement oncontextmenu ou l'attribut context pour créer des menus contextuels. Ne les codez pas pour s'ouvrir spécifiquement lors d'un clic-droit. L'évènement oncontextmenu et l'attribut context fonctionnent avec les déclencheurs de menus spécifiques à chaque plateforme, que ce soient les touches du clavier ou les clics de souris appropriés.

Scripts dépendant de la souris

Les fonctions associées aux évènements souris comme onmouseover, onmousemove et ondrag peuvent uniquement être activés à l'aide de la souris. Fournissez des points d'accès alternatifs au clavier pour ces fonctions. Envisagez d'utiliser des éléments de menus contextuels ou d'autres éléments XUL parallèlement aux raccourcis clavier.

Défilement

Assurez-vous que le défilement est possible au clavier. Beaucoup d'éléments XUL peuvent être rendus défilables à l'aide de CSS. D'autres éléments, comme arrowscrollbox et listbox, sont conçus pour défiler automatiquement. En règle générale, les éléments prévus pour défiler sont inaccessibles si l'utilisateur ne peut pas faire défiler tout le contenu à l'aide du clavier. L'élément arrowscrollbox, par exemple, ne peut pas recevoir le focus ni défiler à l'aide du clavier. Un élément listbox, par contre, peut recevoir le focus et son contenu peut défiler. À peu près tous les éléments XUL peuvent être rendus défilables en définissant un style "overflow: auto" ou "overflow: scroll". Cette flexibilité doit être utilisée de manière réfléchie.

Maintien du focus

L'utilisateur doit typiquement pouvoir contrôler l'endroit où se trouve le focus actuel. Évitez de changer le focus automatiquement. Cependant, désactiver, masquer ou détruire l'élément qui a le focus (ou l'un de ses éléments parents) peut provoquer la perte du focus. Pour empêcher cela, déplacez le focus à l'élément suivant avant de désactiver, masquer ou détruire l'élément qui a le focus.

L'exemple qui suit montre une fonction JavaScript qui peut être appelée avant de détruire un élément pour vérifier s'il a le focus et le déplacer si nécessaire.

function moveFocus(element)
{
    if(element == document.commandDispatcher.focusedElement)
    {
        document.commandDispatcher.advanceFocus();
        return true;
    }

    return false;
}

Les changements de focus inattendus peuvent embrouiller ou désorienter les utilisateurs. Un exemple récurrent concerne les numéros de téléphones à entrer dans des champs de formulaire. Les numéros de téléphone aux États-Unis sont souvent affichés dans un format XXX-XXX-XXXX ou (XXX) XXX-XXXX. Pour conserver ce format, certains formulaires contiennent trois champs différents. Le problème se pose lorsqu'un développeur décide d'ajouter une fonctionnalité sautant vers le second champ du formulaire dès que 3 chiffres ont été entrés dans le premier champ de formulaire. Ce comportement se répète pour le champ suivant du formulaire. Les utilisateurs qui ont l'habitude de se déplacer eux-mêmes dans les champs de formulaire se retrouvent souvent à répéter l'opération de passage au champ suivant et passent donc au dessus d'un des champs du formulaire.

Focus initial dans un dialogue

Le focus initial dans une fenêtre de dialogue XUL (c'est-à-dire le focus à l'ouverture de la fenêtre) devrait toujours se trouver sur un contrôle spécifique et non sur le dialogue lui-même. Dans un dialogue comportant des onglets, le focus doit généralement commencer au premier contrôle de l'onglet sélectionné. Dans tous les autres dialogues, le focus doit commencer au premier contrôle (bien qu'il puisse s'agir de n'importe quel autre contrôle s'il y a une bonne raison de le faire, du moment que ce n'est pas le dialogue lui-même).

Test de l'accès au clavier

Pour tester l'accessibilité au clavier débranchez ou désactivez simplement votre souris et essayez d'utiliser votre application uniquement avec le clavier. Vérifiez que l'ordre de tabulation est logique. Assurez-vous de pouvoir accéder à toutes les fonctions soit directement, soit par des moyens alternatifs comme des choix de menus ou des menus contextuels. Assurez-vous également que l'utilisateur puisse lire tout le contenu.

Informations assistives

Les utilisateurs de technologies assistives ont souvent besoin d'un balisage supplémentaire pour comprendre des significations et associations qui peuvent être intuitives pour les utilisateurs valides. Ce balisage supplémentaire est appelé information assistive. Il est aisé de fournir ces informations, mais on l'oublie souvent car elles ne produisent que très peu de changements visuels, voire aucun.

Texte alternatif

Fournissez un texte alternatif pour les images significatives. Il n'est pas nécessaire d'ajouter un texte alternatif lorsqu'une image assure une fonction purement décorative. Utilisez l'attribut alt pour décrire les images HTML et l'attribut tooltiptext pour les éléments XUL utilisant des images (c'est-à-dire les éléments image et les boutons avec images). Pour les boutons de barres d'outils avec images, on recommande d'utiliser à la fois une étiquette textuelle dans l'attribut label et un texte alternatif pour l'image dans l'attribut tooltiptext. Voyez les exemples de code ci-dessous.

<image src="stop.png" tooltiptext="Stop" />

<html:img src="stop.jpg" alt="Stop" />
<html:img src="image_decorative.jpg" alt="" /> <!-- En HTML, l'attribut alt est obligatoire. -->

<toolbarbutton label="Stop" image="stop.png" tooltiptext="Arrêter le chargement de la page" />

Titres

Fournissez des titres uniques aux éléments conteneurs des fenêtres, assistants et dialogues. Les titres fournissent aux utilisateurs les informations les informations les plus basiques concernant l'application. Le titre est souvent la première chose qui est prononcée par un lecteur d'écran lorsqu'une application est ouverte ou activée. Les utilisateurs peuvent également se référer au titre pour comprendre où ils se situent. Les titres sont affichés dans la barre supérieure d'une application. Voyez les exemples de code ci-dessous.

<dialog id="print_dialog" title="Imprimer"                  ...>
<window id="mywindow"     title="Mon application"           ...>
<wizard id="reg_window"   title="Enregistrer le logiciel"   ...>

Labels de formulaires

Les labels ne sont pas automatiquement associés aux éléments de formulaires. Utilisez l'attribut control pour lier une étiquette texte (d'un élément label ou de description) à un élément de formulaire. Les lecteurs d'écran liront alors le label lors du remplissage d'un champ de forumlaire.

<label control="login-username" value="Utilisateur :"/>
<textbox id="login-username"/>

<description control="login-password">Mot de passe :</description>
<textbox id="login-password" type="password"/>

Les formulaires plus grand peuvent être difficiles à mettre en page et à structurer. Bien qu'il y ait toujours de nombreuses manières de structurer un formulaire visuellement, fournissez toujours un label texte pour chaque élément de formulaire. Il ne faut pas utiliser des éléments de formulaire pour en décrire d'autres.

Lorsque des éléments de formulaire sont intégrés dans un groupbox avec une étiquette, les technologies assistives comme les lecteurs d'écran liront cette étiquette suivie du label de l'élément de formulaire. Par exemple, dans la section Vie privée des options, il y a trois groupes appelés Historique, Cookies et Vie privée. Si l'utilisateur se déplace avec la tabulation vers le bouton « Exceptions... », il entendra « cookies {pause} exceptions {pause} bouton. » L'élément suivant dira « cookies {pause} les conserver jusqu'à {pause} leur expiration {pause} un sur trois {pause} liste déroulante ». Si le lecteur d'écran lisait uniquement le label, l'utilisateur devrait deviner à quoi se référait le bouton « exceptions » ou la liste déroulante « les conserver jusqu'à ».

Les groupes de contrôles sont essentiels pour les boutons radios ou groupes de cases à cocher concernant un thème similaire (c'est-à-dire où il faut cocher toutes celles qui s'appliquent). Si vous trouvez que des groupes de contrôles imbriqués sont peu agréables visuellement, utilisez CSS pour cacher la bordure du groupe interne afin qu'il reste visible dans le code pour servir aux utilisateurs de technologies assistives.

Les formulaires complexes ont souvent besoin d'un système d'étiquetage plus avancé que ce qui est possible avec les attributs XUL standards. Par exemple, le premier élément du panneau Vie privée des options de Firefox (montré et décrit plus haut) est [case à cocher] Se souvenir des pages visitées lors des [textbox] derniers jours. La difficulté ici provient du fait que le label correct pour la case à cocher (« Se souvenir des pages visitées lors des x derniers jours ») est composé de trois pièces différentes, dont la seconde est la valeur actuellement entrée dans la boîte de texte. Le label correct pour la boîte de texte est en fait le même, mais on ne voudrait pas que les technologies assistives le lisent ou le montrent deux fois de suite. Ce qu'il faut, c'est une manière de spécifier dans le code source que la case à cocher, le champ d'édition et les labels textuels autour font tous partie d'une seule entité, et qu'ils s'étiquettent en quelque sorte l'un l'autre.

Pour résoudre ce problème, on entourera d'abord tous ces contrôles dans un seul élément conteneur, comme (dans ce cas-ci) un hbox. On importe ensuite ce qu'on appelle « l'Accessible, Adaptable Applications Module » (du groupe WAI-ARIA du WC3) en ajoutant xmlns:aaa="https://www.w3.org/2005/07/aaa" comme attribut sur l'élément conteneur. Ceci nous permet d'utiliser l'attribut labelledby (notez le double L — aaa utilise l'orthographe anglaise du Royaume-Uni) pour spécifier que la case à cocher et la boîte de texte sont toutes deux décrites par l'ensemble du groupe de composants. Dans XUL, cela ressemblera à ce qui suit.

<hbox id="historyBox" xmlns:aaa="https://www.w3.org/2005/07/aaa">
  <checkbox id="rememberHistoryDays" aaa:labelledby="historyBox" label="Se souvenir des pages visitées lors des"/>
  <textbox  id="historyDays"         aaa:labelledby="historyBox"/>
  <label>derniers jours.</label>
</hbox>

Test des informations assistives

La meilleure manière de tester est pour de nombreuses raisons de faire le test avec un lecteur d'écran, car la navigation au clavier et la structure sémantique sous-jacente de l'interface utilisateur peuvent être testées simultanément. C'est un excellent indicateur concernant l'accessibilité d'une interface utilisateur, mais en aucun cas un test complet. En fin de compte, pour les applications qui doivent être entièrement accessibles, il est préférable que l'application soit testée par un large panel d'utilisateurs disposant de différentes configurations logicielles et de différentes technologies assistives.

Si vous ne disposez pas d'un logiciel lecteur d'écran (et ne connaissez personne dont c'est le cas), votre meilleure option est de vérifier attentivement le code source pour vous assurer que toutes les règles ci-dessus ont été suivies, et ensuite que les utilisateurs ont un moyen de vous contacter en retour sur l'accessibilité (et d'autres aspects) de votre application.

Affichage

On entend souvent que « la présentation fait tout ». Bien qu'il soit vrai que la présentation est quelque chose d'essentiel, les documents doivent également être structurés de manière à ce que l'utilisateur puisse appeler des préférences d'affichage qui peuvent être nécessaires pour l'accessibilité. La présentation doit aussi être flexible pour s'adapter au redimensionnement des fenêtres et polices. Les applications coopératives s'adaptent bien à l'environnement de l'utilisateur.

Paramètres par défaut du système

Respectez les réglages par défaut du système. Beaucoup d'utilisateurs configurent leur ordinateur pour utiliser des polices plus grandes et/ou des thèmes de couleur particuliers. Par défaut, les menus XUL, labels et autres contrôles obtiennent leur police, taille et paramètres de couleur des réglages de l'utilisateur spécifiés par le système d'exploitation. Respectez ces réglages à moins d'avoir une raison particulière et inévitable de les changer. Le cas échéant, utilisez CSS pour dimensionner les éléments par rapport à leurs tailles par défaut (par exemple, utilisez des tailles en % ou em plutôt que des tailles spécifiques en points ou en pixels).

Couleurs

La couleur est un outil important. Des couleurs différentes peuvent donner des significations différentes aux objets et au texte. Cependant, la couleur seule est inadéquate pour communiquer un sens ou une information particulière à l'utilisateur. Certains, principalement ceux qui sont aveugles ou ne voient pas les couleurs, n'arriveront pas à discerner certaines couleurs. Certains utilisateurs peuvent modifier le schéma de couleurs par défaut de votre application. La couleur doit uniquement être utilisée pour souligner la signification d'un objet ou d'un texte après avoir donné cette signification à l'utilisateur d'une autre manière.

Tailles flexibles

Un des avantages d'XUL est que l'apparence visuelle est très facile à contrôler. Sur le Web, la mise en page est souvent contrainte dans une taille spécifique. Avec XUL, vous pouvez permettre aux éléments de s'étendre lorsque la fenêtre de l'application est redimensionnée. Utilisez l'attribut flex pour fournir cette fonctionnalité.

Test de l'affichage

Vérifiez que votre application est fonctionnelle et que son apparence est plaisante en utilisant des polices et couleurs définies par l'utilisateur. Pour cela, changez les paramètres d'affichage du système en un thème accessible (comme le thème Contraste élevé sous Windows, disponible par Alt-Gauche + Maj-Gauche + Impr. Écran). Assurez-vous que le texte est mis en évidence correctement que que la couleur n'est pas utilisée comme seule manière de communiquer une signification. Assurez-vous également que lorsque les fenêtres sont redimensionnées, votre application s'adapte de bonne grâce.

Interaction entre l'homme et la machine

Lorsque vous utilisez une application, vous vous attendez à disposer d'un certain contrôle et d'un retour sur ce qui se passe. Fournissez aux utilisateurs des instructions et indications claires, et permettez-leur de corriger leurs erreurs. Certains utilisateurs handicapés ont des difficultés lorsqu'on leur demande une réponse rapide. Donnez-leur un temps adéquat pour effectuer leurs tâches.

Instructions

Fournissez une documentation d'aide aux utilisateurs. Même des applications très simples devraient contenir un document d'aide ou un manuel de référence pour l'utilisateur. Décrivez les raccourcis claver et toutes autres considérations concernant l'accessibilité. Les utilisateurs doivent avoir la possibilité de consulter une description complète de toutes les fonctionnalités majeures d'une application. Fournissez également des détails sur l'utilisation de la documentation d'aide lorsqu'elle est longue ou complexe.

Avertissements

Utilisez des avertissements accessibles pour présenter des informations importantes à l'utilisateur. Utilisez des scripts ou l'élément notificationbox pour déclencher des alertes.

Évitez d'utiliser uniquement des alertes audio ou visuelles pour signaler des évènements urgents. Les utilisateurs qui ont réduit ou coupé le son, ou qui sont sourds ou malentendants ne pourront pas reconnaître des alertes uniquement sonores. Les utilisateurs souffrant de déficiences visuelles ne verront pas non plus les alertes qui sont purement visuelles (à moins que celles-ci soient présentées dans un texte fonctionnel également accessible à un lecteur d'écran).

Éléments interactifs

Évitez les petites cibles, qui sont difficiles à voir et à atteindre avec un clic de souris. Vérifiez que la mise en page et le contraste sont suffisants pour distinguer les éléments interactifs les un des autres et par rapport aux parties statiques de l'application.

Récupération en cas d'erreur

Lorsque l'utilisateur provoque une erreur dans une application, permettez une récupération aisée. Par exemple, si l'utilisateur entre des lettres là où un nombre est attendu dans un formulaire, cela ne doit pas faire planter l'application. L'utilisateur doit être averti du problème et pouvoir corriger l'erreur.

Temps de réponse

Le cas échéant, avertissez l'utilisateur des limites de temps et permettez-lui d'ajuster la limite ou de demander plus de temps. Un des miracles de la technologie moderne est qu'elle permet aux personnes souffrant même des plus sévères limitations physiques d'utiliser des ordinateurs. Certains utilisent des contrôles à la bouche ou des périphériques de détection de mouvements comme des capteurs oculaires pour entrer des informations. Ce processus peut être lent. D'autres utilisateurs ont simplement besoin de temps pour comprendre ce qui se produit dans l'application.

Test de l'interaction homme machine

Assurez-vous que la documentation d'aide est à jour. Vérifiez que les avertissements sont affichés à l'aides des éléments XUL appropriés. Assurez-vous que l'utilisateur est informé de toutes ses erreurs et que des instructions et la possibilité d'effectuer à nouveau l'opération correcte sont fournies. Assurez-vous également que les utilisateurs ont le contrôle de leur temps de réponse.

Médias

Audio

Des fichiers audio d'information comme des podcasts peuvent être rendus accessibles en fournissant une transcription mot-à-mot. Les transcriptions doivent identifier correctement les intervenants et décrire les autres sons significatifs comme les rires ou les chansons. Ces transcriptions peuvent prendre du temps à réaliser, mais c'est la seule manière de rendre du contenu sonore accessible.

Vidéos

Un fichier vidéo peut être rendu accessible en ajoutant des sous-titres synchronisés. La plupart des formats vidéo fournissent un moyen d'afficher des sous-titres. Les vidéos devraient également être accompagnées de transcriptions descriptives. En général, ces deux opérations vont ensemble, une fois que vous avez l'une, il est facile de produire l'autre.

Animations

Les animations, le mouvement et les sons peuvent être dérangeantes pour certains utilisateurs souffrants de troubles de l'attention. Fournissez un mécanisme pour désactiver les médias et les mouvements.

Les tremblements ou clignotements ne sont pas uniquement ennuyeux pour tout le monde, mais à une vitesse de plus de 3 cycles par seconde, ils peuvent provoquer un malaise chez les utilisateurs souffrant d'épilepsie photosensible. Si des tremblement ou clignotements sont nécessaires, avertissez l'utilisateur au préalable avant de les provoquer.

Test de médias

Assurez-vous que des alternatives aux médias sont disponibles dans un format accessible.

Autres problèmes

Contrôles personnalisés

Évitez de recréer des fonctionnalités qui existent déjà. Assurez-vous que vos composants personnalisés sont construits en pensant à l'accessibilité. Utilisez les couleurs système CSS pour vous assurer que les nouveaux contrôles interagiront bien avec les autres contrôles ainsi qu'avec les thèmes et couleurs définis par l'utilisateur.

Liste de contrôle d'accessibilité pour XUL

Utilisez la liste de contrôle suivante pour vérifier rapidement l'accessibilité d'une nouvelle application XUL, ou comme point de départ pour régler les problèmes d'accessibilité dans une application existante.

Accès au clavier

Informations assistives

Affichage

Interaction homme-machine

Médias

Autres