La plupart des librairies JavaScript proposent des composants côté client qui miment le comportement familier des interfaces de bureaux classiques. Carrousels, barres de menu et d’autres composants peuvent être créés avec JavaScript, CSS et HTML. Mais du moment que les spécifications HTML 4 ne proposaient pas de tags pour décrire sémantiquement ce type de composants, les développeurs se contentaient d'éléments génériques tel que le tag <div> ou le tag <span>. Or, si d’apparence ces composants ressemblaient parfaitement à ceux spécifiques aux applications de bureau, on ne disposait pas d'informations sémantiques suffisantes pour les rendres accessibles aux technologies d’assistance. L’accès au contenu dynamique d’une page Web peut devenir problématique plus particulièrement pour les utilisateurs qui, pour une raison ou pour une autre ne peuvent pas voir l’écran. Les niveaux de stock, les indicateurs de progression... modifient le DOM de telle sorte que les technologies d'assistance n’y ont pas accès. C'est dans ce contexte que ARIA entre en jeu.
+
La plupart des librairies JavaScript proposent des composants côté client qui miment le comportement familier des interfaces de bureaux classiques. Carrousels, barres de menu et d’autres composants peuvent être créés avec JavaScript, CSS et HTML. Mais du moment que les spécifications HTML 4 ne proposaient pas de tags pour décrire sémantiquement ce type de composants, les développeurs se contentaient d'éléments génériques tel que le tag <div> ou le tag <span>. Or, si d’apparence ces composants ressemblaient parfaitement à ceux spécifiques aux applications de bureau, on ne disposait pas d'informations sémantiques suffisantes pour les rendres accessibles aux technologies d’assistance. L’accès au contenu dynamique d’une page Web peut devenir problématique plus particulièrement pour les utilisateurs qui, pour une raison ou pour une autre ne peuvent pas voir l’écran. Les niveaux de stock, les indicateurs de progression... modifient le DOM de telle sorte que les technologies d'assistance n’y ont pas accès. C'est dans ce contexte que ARIA entre en jeu.
Exemple 1: Code d’une tabulation sans informations ARIA. Il n'y a aucune information permettant de décrire la forme du widget et ses fonctions.
@@ -38,14 +38,14 @@ original_slug: >-
</div>
Example 2: Telles qu'elles sont représentées ci-dessous, les tabulations peuvent être reconnues en tant que tel par les utilisateurs. Or aucune information sémantique exploitable par une technologie d’assistance n’est présente.
-
+
ARIA
WAI-ARIAI, les spécifications concernant les applications internet "riches" et accessibles sont publiées par l’iniative du W3C sur l’accessibilité, et fournissent la sémantique essentielle au bon fonctionnement des lecteurs d'écran. ARIA permet aux développeurs de décrire en quelque sorte leurs widgets plus finement en ajoutant des attributs spéciaux à leurs balises. Ces spécifications comblent le vide qui existait entre les spécifications du standard HTML et des widgets. ARIA spécifie des rôles et des états permettant de décrire en quelque sorte le fonctionnement des widgets d’interfaces utilisateurs les plus connus.
-
Beaucoup d’entre eux ont été ajouté plus tard dans HTML5, et les développeurs devraient toujours préférer utiliser la balise HTML correspondante plutôt qu’utiliser ARIA.
+
Attention : Beaucoup d’entre eux ont été ajouté plus tard dans HTML5, et les développeurs devraient toujours préférer utiliser la balise HTML correspondante plutôt qu’utiliser ARIA.
Les spécifications ARIA distinguent 3 types d’attributs : rôles, états et propriétés. Les rôles sont utilisés pour les widgets ne faisant pas partie des spécifications HTML 4 comme des sliders, menus, barres, boites de dialogue... Les propriétés sont utilisées pour représenter les caractéristiques de ces widgets, elles décrivent les caractéristiques de ces widgets comme s'il sont déplaçables avec la souris, requièrent un élément ou ont un popup associés à eux. Les états, comme leur nom l'indique, servent à representer l'état actuel de ces éléments en informant les technologies d'assistance s'il est occupé, désactivé, sélectionné ou masqué.
@@ -126,7 +126,7 @@ original_slug: >-
Exemple 2c. JavaScript pour mettre à jour l'attribut aria-checked.
-
var showTip = function(el) {
+
var showTip = function(el) {
el.setAttribute('aria-hidden', 'false');
}
@@ -138,10 +138,6 @@ original_slug: >-
Ne faites pas ça. À la place, il vaut mieux implémenter le mode "vue" avec un autre élément, comme {{ HTMLElement("div") }} ou {{ HTMLElement("span") }} avec un role de button, et le mode "édition" avec un élément texte {{ HTMLElement("input") }}.
Souvent, les développeurs négligent la prise en charge du clavier lorsqu’ils créent des widgets personnalisés. Pour être accessible à une large gamme d’utilisateurs, toutes les fonctionnalités d’une application Web ou d’un widget doivent également pouvoir être contrôlées avec le clavier, sans nécessiter de souris. En pratique, cela implique généralement de suivre les conventions prises en charge par des widgets similaires sur le bureau, en tirant pleinement partie des touches Tab, Entrée, Espace et des flèches.
@@ -158,16 +154,16 @@ original_slug: >-
En cas de doute, imitez le comportement standard du bureau du contrôle que vous créez.
-
Ainsi, pour l’exemple de widget Tabs ci-dessus, l’utilisateur devrait être capable de naviguer dans le conteneur du widget (le <ol> dans notre balisage) en utilisant les touches Tab et Maj+Tab. Une fois que le focus du clavier est à l’intérieur du conteneur, les touches fléchées devraient permettre à l’utilisateur de naviguer entre chaque onglet (les éléments <li>). De là, les conventions varient d’une plateforme à l’autre. Sous Windows, l’onglet suivant doit être automatiquement activé lorsque l’utilisateur appuie sur les touches fléchées. Sous Mac OS X, l’utilisateur peut appuyer sur Entrée ou sur Espace pour activer l’onglet suivant. Un tutoriel en profondeur pour créer Widget navigables grâce à des contrôles Javascript comme décrit ici afin de montrer comment avoir ce comportement en JS.
+
Ainsi, pour l’exemple de widget Tabs ci-dessus, l’utilisateur devrait être capable de naviguer dans le conteneur du widget (le <ol> dans notre balisage) en utilisant les touches Tab et Maj+Tab. Une fois que le focus du clavier est à l’intérieur du conteneur, les touches fléchées devraient permettre à l’utilisateur de naviguer entre chaque onglet (les éléments <li>). De là, les conventions varient d’une plateforme à l’autre. Sous Windows, l’onglet suivant doit être automatiquement activé lorsque l’utilisateur appuie sur les touches fléchées. Sous Mac OS X, l’utilisateur peut appuyer sur Entrée ou sur Espace pour activer l’onglet suivant. Un tutoriel en profondeur pour créer Widget navigables grâce à des contrôles Javascript comme décrit ici afin de montrer comment avoir ce comportement en JS.
-
Pour plus de détails à propos de ces conventions de navigation au clavier, un aperçu ici DHTML style guide est disponible. Il délivre un aperçu de la façon dont la navigation au clavier devrait fonctionner pour chaque type de widget pris en charge par ARIA. Le W3C offre également un document utile ARIA Best Practices qui inclut la navigation au clavier et les raccourcis pour une variété de widgets.
+
Pour plus de détails à propos de ces conventions de navigation au clavier, un aperçu ici DHTML style guide est disponible. Il délivre un aperçu de la façon dont la navigation au clavier devrait fonctionner pour chaque type de widget pris en charge par ARIA. Le W3C offre également un document utile ARIA Best Practices qui inclut la navigation au clavier et les raccourcis pour une variété de widgets.
Dans le passé, un changement dans une page web débouchait souvent sur une relecture intégrale, ce qui agaçait souvent l’utilisateur, ou au contraire très peu ou pas de lecture du tout, rendant inaccessible une partie, voire l’ensemble des informations. Jusqu’à récemment, les lecteurs d’écran n’étaient en mesure d’améliorer cela du fait de l’absence d’éléments standardisés pour prévenir le lecteur d’écran d’un changement. Les zones « live » ARIA comblent cette lacune et fournissent des solutions aux lecteurs d’écran afin de savoir si et comment interrompre l'utilisateur lors d’un changement.
-
Zones « live » basiques
+
Zones « live » basiques
Le contenu dynamique qui s’actualise sans rechargement de la page est généralement une zone ou un composant d’interface. Les changements de contenu simples, sans interaction possible, devraient être marqués comme des zones « live ». Ci-dessous, voici une liste de chaque propriété relative à une zone « live » ARIA et sa description.
L’attribut aria-live=VALEUR_POLITESSE est utilisé pour définir la priorité avec laquelle le lecteur d’écran devrait traiter une mise à jour dans une zone « live » – les valeurs possibles sont : off/polite/assertive. La valeur par défaut est off. Cet attribut est de loin le plus important.
aria-controls :
-
L’attribut aria-controls=[LISTE_IDs] est utilisé pour associer un contrôle avec les zones qu’il contrôle. Les zones sont identifiées comme un ID dans un élément {{ HTMLElement("div") }}, et plusieurs zones peuvent être associées à un unique contrôle, en séparant les identifiants des zones par un espace, par exemple : aria-controls="maZoneID1 maZoneID2".
-
Nous ne savons pas si aria-controls pour les zones « live » est utilisé dans des technologies d’assistance modernes, et si oui lesquelles. Des recherches sont nécessaires.
+
L’attribut aria-controls=[LISTE_IDs] est utilisé pour associer un contrôle avec les zones qu’il contrôle. Les zones sont identifiées comme un ID dans un élément {{ HTMLElement("div") }}, et plusieurs zones peuvent être associées à un unique contrôle, en séparant les identifiants des zones par un espace, par exemple : aria-controls="maZoneID1 maZoneID2".
+
+
Attention :Nous ne savons pas si aria-controls pour les zones « live » est utilisé dans des technologies d’assistance modernes, et si oui lesquelles. Des recherches sont nécessaires.
+
+
+
Normalement, seul aria-live="polite" est utilisé. Toute zone recevant une mise à jour qu’il est important de faire suivre à l’utilisateur, mais pas au point de le déranger dans sa navigation, devrait recevoir cet attribut. Le lecteur d’écran lira les changements dès que l’utilisateur sera inoccupé.
Lorsque l’utilisateur sélectionne un nouvel oiseau, l’information est lue. Du fait de la valeur polite, le lecteur d’écran attendra une pause de la part de l’utilisateur. Ainsi, descendre dans la liste ne déclenchera pas la lecture pour chaque oiseau visité par l’utilisateur, mais uniquement pour celui qui sera finalement choisi.
L’attribut aria-describedby=[LISTE_ID] est utilisé pour associer une ou des descriptions à une zone. Le fonctionnement est similaire à celui d'aria-controls mais les références d'id pointent vers les textes descriptifs associés aux blocs identifiés, et les références multiples sont également séparées par un espace.
-
Cas d’étude avancé : liste de contacts
+
Cas d’étude avancé : liste de contacts
Un site de chat voudrait afficher la liste des utilisateurs actuellement connectés. L'affichage de la liste des utilisateurs doit alors refléter l’état de connexion ou de déconnexion des utilisateurs de manière dynamique (sans actualisation de la page).
Effets possibles sur les agents utilisateur et les technologies d’assistance
-
-
- Note : les opinions diffèrent sur la façon dont les technologies d’assistance devraient traiter ces techniques. Les informations fournies ci-dessus sont une de ces opinions et ne sont en aucune manière normatives.
-
Exemples
-
Exemple 1 :
-
-
Code
-
Exemples fonctionnels :
-
Notes
-
Attributs ARIA utilisés
-
Techniques ARIA associées
-
Compatibilité
-
TBD : Ajouter les informations de prise en charge des combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance
Cette technique présente l’utilisation du rôle alert (en) et décrit les effets produits sur les navigateurs et les technologies d’assistance.
-
+
Cette technique présente l’utilisation du rôle alert (en) et décrit les effets produits sur les navigateurs et les technologies d’assistance.
Le rôle alert est utilisé pour communiquer un message important et généralement avec une notion d'urgence à l’utilisateur. Lorsque ce rôle est ajouté à un élément, le navigateur émettra un événement d'alerte accessible aux produits de technologie d’assistance qui pourront alors le notifier à l’utilisateur. Le rôle alert est le plus utile lorsqu’il s’agit d’attirer l’attention de l’utilisateur, par exemple si :
Les loupes ou agrandisseurs d’écran peuvent indiquer qu’une alerte est survenue et quel en est le texte.
-
Note : plusieurs points de vue existent sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
+
Note : plusieurs points de vue existent sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
L’utilisation du rôle alert sur un élément implique que cet élément a l’attribut aria-live="assertive" ;
Le rôle alert ne devrait être utilisé que pour du contenu texte statique. L’élément sur lequel on utilise le rôle alert ne devrait pas pouvoir recevoir le focus, car les lecteurs d’écran annonceront automatiquement l’alerte où que se trouve le focus clavier ;
-
Si une alerte fournit également des contrôles interactifs – tels que des contrôles de formulaire qui permettraient à l’utilisateur de rectifier une erreur, ou un bouton OK pour annuler l’alerte – le rôle alertdialog est préférable.
+
Si une alerte fournit également des contrôles interactifs – tels que des contrôles de formulaire qui permettraient à l’utilisateur de rectifier une erreur, ou un bouton OK pour annuler l’alerte – le rôle alertdialog est préférable.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation du rôle alertdialog role.
-
+
Cette technique présente l’utilisation du rôle alertdialog role.
-
Le rôle alertdialog est utilisé pour notifier à l’utilisateur des informations urgentes qui requièrent son attention immédiate. Comme le nom l’indique, alertdialog est un type de boîte de dialogue. Cela signifie que la plupart des instructions fournies à propos de l’utilisation du rôle dialog s’appliquent également au rôle alertdialog :
+
Le rôle alertdialog est utilisé pour notifier à l’utilisateur des informations urgentes qui requièrent son attention immédiate. Comme le nom l’indique, alertdialog est un type de boîte de dialogue. Cela signifie que la plupart des instructions fournies à propos de l’utilisation du rôle dialog s’appliquent également au rôle alertdialog :
La boîte de dialogue d’alerte doit toujours avoir un nom accessible (attribué à l’aide de aria-labelledby ou de aria-label) et, dans la plupart des cas, le texte d’alerte sera marqué comme étant la description accessible de la boîte de dialogue d’alerte (définie avec de l’attribut aria-describedby).
Du fait de sa nature urgente, les boîtes de dialogues d’alertes doivent toujours être modales.
-
Note : ce rôle ne devrait être utilisé que pour des messages d’alertes associés à des contrôles interactifs. Si une boîte de dialogue d’alerte ne comporte que du contenu statique et qu’elle ne possède absolument aucun contrôle interactif, alertdialog n’est probablement pas le rôle le plus judicieux à utiliser. Le rôle alert est plus adapté pour ce cas (comme décrit dans l’article sur la technique d’utilisation du rôle alert).
+
+
Note : ce rôle ne devrait être utilisé que pour des messages d’alertes associés à des contrôles interactifs. Si une boîte de dialogue d’alerte ne comporte que du contenu statique et qu’elle ne possède absolument aucun contrôle interactif, alertdialog n’est probablement pas le rôle le plus judicieux à utiliser. Le rôle alert est plus adapté pour ce cas (comme décrit dans l’article sur la technique d’utilisation du rôle alert).
+
Effets possibles sur les agents utilisateurs et les technologies d’assistance
Lorsque la boîte de dialogue est correctement labélisée et que le focus se place sur un contrôle qu’elle contient, les lecteurs d’écran devraient annoncer le rôle accessible de la boîte de dialogue, son nom et éventuellement sa description, avant d’annoncer l’élément qui a reçu le focus.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Effets possibles sur les agents utilisateurs et les technologies d'assistance
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d'assistance devraient traiter cette technique. L'information fournie ci-dessus est l'une de ces opinions et n'est pas normative.
+
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d'assistance devraient traiter cette technique. L'information fournie ci-dessus est l'une de ces opinions et n'est pas normative.
Cette technique présente l’utilisation de l’attribut aria-invalid.
-
+
Cette technique présente l’utilisation de l’attribut aria-invalid.
L’attribut aria-invalid est utilisé pour indiquer que la valeur saisie dans un champ de saisie n’est pas conforme au format attendu par l’application. Cela comprend les formats tels que les adresses électroniques ou les numéros de téléphone. aria-invalid peut également être utilisé pour indiquer qu’un champ obligatoire n’a pas été rempli. L’attribut devrait être programmatiquement défini comme étant le résultat du processus de validation.
Les agents utilisateurs devraient informer l’utilisateur lorsqu’un champ n’est pas valide. Les développeurs d’applications devraient fournir des suggestions pour la correction du problème, lorsque c’est possible. Les auteurs devraient empêcher la soumission de formulaires contenant des erreurs.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournit ci-dessus est l’une de ces opinions et n’est pas normative.
+
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournit ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Les lecteurs d'écran lisent le contenu textuel de cet attribut.
Usage
-
L’attribut aria-label ne doit être utilisé que lorsque le texte d’un label n’est pas visible à l’écran. Si le texte du label de l’élément existe et est visible, utilisez plutôt l’attribut aria-labelledby.
+
L’attribut aria-label ne doit être utilisé que lorsque le texte d’un label n’est pas visible à l’écran. Si le texte du label de l’élément existe et est visible, utilisez plutôt l’attribut aria-labelledby.
Cet attribut peut être utilisé avec n’importe quel élément HTML. Néanmoins, il n'est pas nécessaire de l'utiliser si l'élément possède déjà un mécanisme pour légender son contenu. Par exemple l'élément <label> pour les éléments de formulaire, ou l'attribut alt pour les images.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation de l’attribut aria-labelledby.
-
+
Cette technique présente l’utilisation de l’attribut aria-labelledby.
L’attribut aria-labelledby est utilisé pour indiquer les ID des éléments qui labellisent l’objet. Il est utilisé pour établir une relation entre les composants, ou les groupes, et leurs labels. Les utilisateurs de technologies d’assistance telles que les lecteurs d’écran, naviguent généralement dans un document en tabulant entre les zones de l’écran. Si un label n’est pas associé à un élément de saisie, un composant ou un groupe, il ne sera pas lu par le lecteur d’écran.
-
aria-labelledby est très similaire à l’attribut aria-describedby : un label décrit la nature d’un objet, alors qu’une description fournit plus d’informations pouvant être utiles à l’utilisateur.
+
aria-labelledby est très similaire à l’attribut aria-describedby : un label décrit la nature d’un objet, alors qu’une description fournit plus d’informations pouvant être utiles à l’utilisateur.
L’attribut aria-labelledby n’est pas uniquement utilisé avec les éléments de formulaire ; il peut également être utilisé pour associer un texte statique avec des composants, des groupes d’éléments, des panneaux, des zones possédant un titre, des définitions, etc. La section {{ anch("Exemples") }} ci-dessous fournit plus d’informations sur l’utilisation de cet attribut dans ces cas précis.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
-
Lorsque les deux attributs aria-labelledby et aria-label sont utilisés, les agents utilisateurs donnent la priorité à aria-labelledby lors du calcul de la propriété de nom accessible.
+
Lorsque les deux attributs aria-labelledby et aria-label sont utilisés, les agents utilisateurs donnent la priorité à aria-labelledby lors du calcul de la propriété de nom accessible.
Dans l’exemple ci-dessous, les éléments d’en-têtes sont associés avec les contenus dont ils sont les intitulés. Notez que la zone référencée est celle qui contient l’en-tête.
-
<div role="main" aria-labelledby="foo">
+
<div role="main" aria-labelledby="foo">
<h1 id="foo">Le feu devenu incontrôlable gagne les abords d’Aubagne</h1>
Un fort mistral a propagé le feu de forêt qui s’est déclaré ce lundi soir suite aux fortes températures de ces derniers jours…
</div>
@@ -65,9 +63,9 @@ original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-labe
Exemple 3 : Groupes de boutons radio
-
Dans l’exemple ci-dessous, le conteneur d’un radiogroup est associé avec son label à l’aide de l’attribut aria-labelledby :
+
Dans l’exemple ci-dessous, le conteneur d’un radiogroup est associé avec son label à l’aide de l’attribut aria-labelledby :
<div role="dialog" aria-labelledby="titreDialogue">
<h2 id="titreDialogue">Choisir un fichier</h2>
… Contenus de la boîte de dialogue
</div>
@@ -90,7 +88,7 @@ original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-labe
Dans l’exemple ci-dessous, la définition d’un terme qui est décrit dans le flux naturel de la narration, est associée au terme lui-même à l’aide de l’attribut aria-labelledby:
-
<p>Le docteur expliqua que c’était un <dfn id="placebo">placebo</dfn>, <span role="definition" aria-labelledby="placebo"> ou
+
<p>Le docteur expliqua que c’était un <dfn id="placebo">placebo</dfn>, <span role="definition" aria-labelledby="placebo"> ou
une préparation inerte prescrite plus pour le soulagement mental du patient que ses effets possible sur une pathologie.</span>
</p>
@@ -99,7 +97,7 @@ une préparation inerte prescrite plus pour le soulagement mental du patient que
Dans l’exemple ci-dessous, les définitions sont associées avec les termes qu’elles définissent à l’aide de l’attribut aria-labelledby :
-
<dl>
+
<dl>
<dt id="anatheme">anathème</dt>
<dd role="definition" aria-labelledby="anatheme">une interdiction ou une condamnation prononcée par une autorité ecclésiastique
et accompagnée de l’excommunication</dd>
@@ -114,9 +112,9 @@ une préparation inerte prescrite plus pour le soulagement mental du patient que
Exemple 7 : Menus
-
Dans l’exemple ci-dessous, un menu contextuel est associé avec son label à l’aide de l’attribut aria-labelledby :
+
Dans l’exemple ci-dessous, un menu contextuel est associé avec son label à l’aide de l’attribut aria-labelledby :
-
<div role="menubar">
+
<div role="menubar">
<div role="menuitem" aria-haspopup="true" id="fichierMenu">Fichier</div>
<div role="menu" aria-labelledby="fichierMenu">
<div role="menuitem">Ouvrir</div>
@@ -139,16 +137,12 @@ une préparation inerte prescrite plus pour le soulagement mental du patient que
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
L’attribut aria-relevant est une valeur optionnelle utilisée pour décrire quels types de modifications ont été apportés à une région aria-live, ainsi que ceux qui sont pertinents et doivent être annoncés. Toute modification jugée comme non pertinente se comporte de la même manière que si l’attribut aria-live n’était pas activé.
+
L’attribut aria-relevant est une valeur optionnelle utilisée pour décrire quels types de modifications ont été apportés à une région aria-live, ainsi que ceux qui sont pertinents et doivent être annoncés. Toute modification jugée comme non pertinente se comporte de la même manière que si l’attribut aria-live n’était pas activé.
L’attribut aria-relevant est habituellement utilisé lorsque le contenu d’une page web peut être mis à jour alors que la page est affichée.
Cette technique présente l’utilisation de l’attribut aria-required.
-
+
Cette technique présente l’utilisation de l’attribut aria-required.
L’attribut aria-required est utilisé pour indiquer que l’utilisateur doit obligatoirement remplir un champ de formulaire avant de le soumettre. Cet attribut peut être utilisé avec n’importe quel élément de formulaire HTML ; il n’est pas limité aux éléments auxquels a été assigné un rôle ARIA.
-
{{ HTMLVersionInline("5") }} a introduit l’attribut required, mais aria-required est toujours utile pour les agents utilisateurs qui ne prennent pas encore en charge HTML5.
+
{{ HTMLVersionInline("5") }} a introduit l’attribut required, mais aria-required est toujours utile pour les agents utilisateurs qui ne prennent pas encore en charge HTML5.
Remarquez que cet attribut ne changera pas automatiquement la présentation du champ.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation de l’attribut aria-valuemax.
-
+
Cette technique présente l’utilisation de l’attribut aria-valuemax.
-
L’attribut aria-valuemax est utilisé pour définir la valeur maximale autorisée pour un composant à intervalle tels qu’une barre de progression progressbar, un bouton rotatif spinbutton ou un curseur slider. Si aria-valuenow a des valeurs minimale et maximale connues, le développeur devrait fournir les propriétés de aria-valuemax et aria-valuemin. La valeur de aria-valuemaxDOIT être supérieure ou égale à celle de aria-valuemin.
+
L’attribut aria-valuemax est utilisé pour définir la valeur maximale autorisée pour un composant à intervalle tels qu’une barre de progression progressbar, un bouton rotatif spinbutton ou un curseur slider. Si aria-valuenow a des valeurs minimale et maximale connues, le développeur devrait fournir les propriétés de aria-valuemax et aria-valuemin. La valeur de aria-valuemaxDOIT être supérieure ou égale à celle de aria-valuemin.
Si la valeur aria-valuemax n’est pas déterminée, ou si aria-valuemin n’est pas inférieure ou égale à la valeur de aria-valuemax, cela créera une condition d’erreur qui sera gérée par la technologie d’assistance.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
L’attribut aria-valuemin est utilisé pour définir la valeur minimale autorisée pour un composant à intervalle tel qu’une barre de progression progressbar, un bouton rotatif spinbutton ou un curseur slider. Si aria-valuenow a des valeurs limites connues (minimum et maximum), le développeur devrait spécifier les propriétés de aria-valuemax et aria-valuemin. La valeur de aria-valueminDOIT être inférieure ou égale à celle de aria-valuemax.
+
L’attribut aria-valuemin est utilisé pour définir la valeur minimale autorisée pour un composant à intervalle tel qu’une barre de progression progressbar, un bouton rotatif spinbutton ou un curseur slider. Si aria-valuenow a des valeurs limites connues (minimum et maximum), le développeur devrait spécifier les propriétés de aria-valuemax et aria-valuemin. La valeur de aria-valueminDOIT être inférieure ou égale à celle de aria-valuemax.
Si aria-valuemin n’est pas inférieure ou égale à la valeur de aria-valuemax, cela créera une condition d’erreur qui sera gérée par la technologie d’assistance.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Pour les éléments possédant les rôles slider et spinbutton, les technologies d'assistance DEVRAIENT retourner la valeur courante à l'utilisateur.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d'assistance devraient traiter cette technique. L'information fournie ci-dessus est l'une de ces opinions et n'est pas normative.
+
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d'assistance devraient traiter cette technique. L'information fournie ci-dessus est l'une de ces opinions et n'est pas normative.
L’attribut aria-valuetext est utilisé pour définir un texte alternatif, lisible par l'homme, de la valeur aria-valuenow d’un composant à intervalle tel qu’une barre de progression, un bouton rotatif spinbutton ou un curseur slider.
+
L’attribut aria-valuetext est utilisé pour définir un texte alternatif, lisible par l'homme, de la valeur aria-valuenow d’un composant à intervalle tel qu’une barre de progression, un bouton rotatif spinbutton ou un curseur slider.
-
Les développeurs DEVRAIENT uniquement définir l’attribut aria-valuetext lorsque la valeur retournée ne peut pas être précisément représentée sous forme de nombre.
+
Les développeurs DEVRAIENT uniquement définir l’attribut aria-valuetext lorsque la valeur retournée ne peut pas être précisément représentée sous forme de nombre.
-
Par exemple, dans le cas d'un curseur qui peut retourner les valeurs petite, moyenneet grand, les valeurs de aria-valuenow pourraient aller de 1 à 3, indiquant ainsi la position de chaque valeur dans l’intervalle, mais la valeur de aria-valuetext sera l'une des chaînes suivantes : petite, moyenne ou grande.
+
Par exemple, dans le cas d'un curseur qui peut retourner les valeurs petite, moyenneet grand, les valeurs de aria-valuenow pourraient aller de 1 à 3, indiquant ainsi la position de chaque valeur dans l’intervalle, mais la valeur de aria-valuetext sera l'une des chaînes suivantes : petite, moyenne ou grande.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
-
Si l’attribut aria-valuetext est absent, les technologies d’assistance compteront uniquement sur l’attribut aria-valuenow pour la valeur courante. Si aria-valuetext est spécifié, les technologies d’assistance DEVRAIENT retourner cette valeur plutôt que celle de aria-valuenow.
+
Si l’attribut aria-valuetext est absent, les technologies d’assistance compteront uniquement sur l’attribut aria-valuenow pour la valeur courante. Si aria-valuetext est spécifié, les technologies d’assistance DEVRAIENT retourner cette valeur plutôt que celle de aria-valuenow.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation du rôle article (en) et décrit les effets produits sur les navigateurs et les technologies d’assistance.
-
+
Cette technique présente l’utilisation du rôle article (en) et décrit les effets produits sur les navigateurs et les technologies d’assistance.
Le rôle article est utilisé pour identifier une section de page qui forme une partie indépendante d'un document, d'une page ou d'un site. Les exemples d'article peuvent être des billets de blogs ou des articles d'un magazine ou d'un journal ou encore les commentaires soumis par les utilisateurs. Ils sont indépendants dans le sens où leur contenu pourrait être autonome, par exemple pour un flux de syndication.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
-
Lorsque l'utilisateur navigue dans un élément ayant le rôle article, les technologies d'assistance qui interceptent généralement les événements clavier standards doivent basculer en mode de navigation du document, plutôt que de passer les événements clavier à l'application web.
+
Lorsque l'utilisateur navigue dans un élément ayant le rôle article, les technologies d'assistance qui interceptent généralement les événements clavier standards doivent basculer en mode de navigation du document, plutôt que de passer les événements clavier à l'application web.
-
Les technologies d'assistance doivent fournit une fonctionnalité permettant à l'utilisateur de naviguer dans la hiérarchie de chacun des éléments article imbriqués.
+
Les technologies d'assistance doivent fournit une fonctionnalité permettant à l'utilisateur de naviguer dans la hiérarchie de chacun des éléments article imbriqués.
-
Note: il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation du rôle group et décrit les effets produits sur les navigateurs et les technologies d’assistance.
-
+
Cette technique présente l’utilisation du rôle group et décrit les effets produits sur les navigateurs et les technologies d’assistance.
-
Le rôle group est utilisé pour identifier un ensemble d’objets de l’interface utilisateur qui, contrairement à une region, ne sont pas destinés à être intégrés dans une table de contenus ou une page récapitulative (telles que des structures dynamiquement créées par des scripts ou par les technologies d’assistance) ; un groupe ne devrait pas être considéré comme une partie perceptible majeure d’une page. Lorsque le rôle group est ajouté à un élément, , le navigateur émettra un événement group accessible aux produits de technologie d’assistance qui pourront alors le notifier à l’utilisateur.
+
Le rôle group est utilisé pour identifier un ensemble d’objets de l’interface utilisateur qui, contrairement à une region, ne sont pas destinés à être intégrés dans une table de contenus ou une page récapitulative (telles que des structures dynamiquement créées par des scripts ou par les technologies d’assistance) ; un groupe ne devrait pas être considéré comme une partie perceptible majeure d’une page. Lorsque le rôle group est ajouté à un élément, , le navigateur émettra un événement group accessible aux produits de technologie d’assistance qui pourront alors le notifier à l’utilisateur.
-
Un groupe devrait utilisé pour former un ensemble logique d’éléments avec des fonctions connexes, tels que les enfants dans un composant d’arborescence formant un ensemble apparenté dans une hiérarchie, ou une collection d’éléments ayant le même conteneur dans un répertoire. Cependant, lorsqu’on utilise un groupe pour former une liste, les développeurs doivent limiter ses enfants aux éléments listitem. Les éléments de groupe devraient être imbriqués.
+
Un groupe devrait utilisé pour former un ensemble logique d’éléments avec des fonctions connexes, tels que les enfants dans un composant d’arborescence formant un ensemble apparenté dans une hiérarchie, ou une collection d’éléments ayant le même conteneur dans un répertoire. Cependant, lorsqu’on utilise un groupe pour former une liste, les développeurs doivent limiter ses enfants aux éléments listitem. Les éléments de groupe devraient être imbriqués.
La gestion correcte d’un groupe par les technologies d’assistance est déterminée par le contexte dans lequel il est fourni.
-
Si un auteur pense qu’une section est suffisamment importante pour faire partie de la table des matières d’une page, il devrait assigner un rôle de region ou un rôle standard de point de repère à cette section.
+
Si un auteur pense qu’une section est suffisamment importante pour faire partie de la table des matières d’une page, il devrait assigner un rôle de region ou un rôle standard de point de repère à cette section.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
Les technologies d’assistance devraient être à l’écoute de tels événements et les notifier à l’utilisateur en conséquence :
-
Les lecteurs d’écran devraient annoncer le groupe lorsque le focus atteint l’un des contrôles appartenant au groupe, et si aria-describedby a été défini, la description peut être lue. Après cela seulement le contrôle focalisé devrait être annoncé.
+
Les lecteurs d’écran devraient annoncer le groupe lorsque le focus atteint l’un des contrôles appartenant au groupe, et si aria-describedby a été défini, la description peut être lue. Après cela seulement le contrôle focalisé devrait être annoncé.
Les loupes d’écran devraient agrandir le groupe.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation du rôle link et décrit les effets produits sur les navigateurs et les technologies d’assistance.
-
+
+
Cette technique présente l’utilisation du rôle link et décrit les effets produits sur les navigateurs et les technologies d’assistance.
+
Le rôle link est utilisé pour identifier un élément qui crée un hyperlien vers une ressource qui peut être dans l’application ou à l’extérieur. Lorsque ce rôle est ajouté à un élément, la tabulation peut être utilisée pour donner le focus au lien et la barre d’espace ou la touche Entrée peuvent exécuter le lien.
-
L’attribut tabindex peut éventuellement être utilisé avec ce rôle pour spécifier directement la position de l’élément dans l’ordre de tabulation.
+
L’attribut tabindex peut éventuellement être utilisé avec ce rôle pour spécifier directement la position de l’élément dans l’ordre de tabulation.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
Lorsque le rôle link est ajouté à un élément, ou qu’un élément possédant ce rôle devient visible, l’agent utilisateur devrait suivre les étapes suivantes :
- Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
Exemples
Exemple 1 : Ajoute le rôle dans le code HTML
L’extrait de code ci-dessous montre comment le rôle link est ajouté dans le code source HTML.
@@ -55,22 +55,21 @@ function navigateLink(evt) {
</body>
Si l'activation du lien déclenche une action mais ne déplace pas le focus du navigateur ou que cela ouvre une nouvelle page, vous devriez considérer l'utilisation du rôle button au lieu du rôle link.
+
Si l'activation du lien déclenche une action mais ne déplace pas le focus du navigateur ou que cela ouvre une nouvelle page, vous devriez considérer l'utilisation du rôle button au lieu du rôle link.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation du rôle log et décrit les effets produits sur les navigateurs et les technologies d’assistance.
-
+
Cette technique présente l’utilisation du rôle log et décrit les effets produits sur les navigateurs et les technologies d’assistance.
-
Le rôle log est utilisé pour identifier un élément qui crée une zone live où de nouvelles informations sont ajoutées dans un ordre significatif et où les anciennes informations peuvent être supprimées. Par exemple, un journal de salon de discussion, l’historique d’une messagerie ou un fichier d’erreurs. Contrairement aux autres types de zones live, ce rôle est ordonné de façon séquentielle et les nouvelles informations sont uniquement ajoutées à la fin de l’enregistrement. Lorsque ce rôle est ajouté à un élément, le navigateur émettra un événement log accessible aux produits de technologie d’assistance qui pourront alors le notifier à l’utilisateur.
+
Le rôle log est utilisé pour identifier un élément qui crée une zone live où de nouvelles informations sont ajoutées dans un ordre significatif et où les anciennes informations peuvent être supprimées. Par exemple, un journal de salon de discussion, l’historique d’une messagerie ou un fichier d’erreurs. Contrairement aux autres types de zones live, ce rôle est ordonné de façon séquentielle et les nouvelles informations sont uniquement ajoutées à la fin de l’enregistrement. Lorsque ce rôle est ajouté à un élément, le navigateur émettra un événement log accessible aux produits de technologie d’assistance qui pourront alors le notifier à l’utilisateur.
Par défaut, les mises à jour ne contiennent que les changements apportés à la zone live et elles sont annoncées à l'utilisateur lorsqu'il est inactif. Si l'utilisateur a besoin d'entendre l'ensemble de la zone live lorsqu'un changement se produit, il faut utiliser aria-atomic="true". Pour faire les annonces le plus tôt possible et lorsque l'utilisateur peut être interrompu, aria-live="assertive" peut être défini pour lancer des mises à jour plus agressives.
Les loupes d'écran devraient indiquer visuellement la disponibilité d'une mise à jour du fichier de journalisation.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
-
Autres ressources
-
Bonnes pratiques ARIA – Implémentation des zones live : #LiveRegions.
+
Bonnes pratiques ARIA – Implémentation des zones live : #LiveRegions.
Cette page présente l'usage du rôle presentation et décrit l'effet qu'il a sur les navigateurs et les technologies d'assistance.
+
Cette page présente l'usage du rôle presentation et décrit l'effet qu'il a sur les navigateurs et les technologies d'assistance.
Description
-
Le rôle presentation est utilisé pour retirer toute représentation sémantique pour un élément donné ainsi que pour ses descendants. Par exemple, un tableau utilisé pour la mise en page pourrait avoir un rôle presentation appliqué sur l'élément table pour retirer la sémantique de l'élément en lui-même ainsi que tout ses sous-éléments, comme l'en-tête de tableau ou même les données de tableau elles-mêmes.
-
Effets possibles sur les agents utilisateurs et les technologies d’assistance
Les agents utilisateurs ou les technologies d'assistance ne devrait normalement pas lire les éléments marqués comme étant de rôle presentation.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation du rôle progressbar.
-
+
Cette technique présente l’utilisation du rôle progressbar.
Le rôle progressbar devrait être utilisé pour un élément qui affiche la progression d’un tâche prenant un certain temps ou s’effectuant en plusieurs étapes.
-
Une barre de progression indique que la requête de l’utilisateur a été prise en compte et que l’application progresse vers la finalisation de l’action demandée. Si la valeur courante de la barre de progression peut être connue, le développeur pourra indiquer la progression à l’aide des attributs aria-valuenow, aria-valuemin et aria-valuemax. Si la valeur de progression est indéterminée, le développeur peut omettre l’attribut aria-valuenow.
+
Une barre de progression indique que la requête de l’utilisateur a été prise en compte et que l’application progresse vers la finalisation de l’action demandée. Si la valeur courante de la barre de progression peut être connue, le développeur pourra indiquer la progression à l’aide des attributs aria-valuenow, aria-valuemin et aria-valuemax. Si la valeur de progression est indéterminée, le développeur peut omettre l’attribut aria-valuenow.
Lorsqu’une tâche progresse, la valeur aria-valuenow doit être dynamiquement actualisée pour indiquer la progression aux produits de technologies d’assistance.
-
Si le rôle progressbar décrit la progression du chargement d’une zone particulière d’une page, l’auteur DOIT utiliser l’attribut aria-describedby pour pointer vers l’état courant, et définir l’attribut aria-busy à true pour la zone jusqu’à la fin du chargement. Il n’est pas possible à l’utilisateur de modifier la valeur de progressbar car elle est toujours en lecture seule.
+
Si le rôle progressbar décrit la progression du chargement d’une zone particulière d’une page, l’auteur DOIT utiliser l’attribut aria-describedby pour pointer vers l’état courant, et définir l’attribut aria-busy à true pour la zone jusqu’à la fin du chargement. Il n’est pas possible à l’utilisateur de modifier la valeur de progressbar car elle est toujours en lecture seule.
-
Note : généralement les technologies d’assistance retourneront la valeur de l’attribut aria-valuenow sous la forme d’un pourcentage d’une plage de valeurs comprise entre aria-valuemin et aria-valuemax, sauf si aria-valuetext est spécifié. Il est préférable de définir les valeurs pour les attributs aria-valuemin, aria-valuemax et aria-valuenow de façon appropriée pour ce calcul.
+
+
Note : généralement les technologies d’assistance retourneront la valeur de l’attribut aria-valuenow sous la forme d’un pourcentage d’une plage de valeurs comprise entre aria-valuemin et aria-valuemax, sauf si aria-valuetext est spécifié. Il est préférable de définir les valeurs pour les attributs aria-valuemin, aria-valuemax et aria-valuenow de façon appropriée pour ce calcul.
-
Note : les éléments possédant le rôle progressbar ont une valeur aria-readonly implicite définie à true.
+
+
Note : les éléments possédant le rôle progressbar ont une valeur aria-readonly implicite définie à true.
+
Effets possibles sur les agents utilisateurs et les technologies d’assistance
Les lecteurs devraient annoncer les mises à jour de la progression dès qu’elles se produisent. Si la barre de progression a un label, il devrait également être mentionné.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
+
\ No newline at end of file
diff --git a/files/fr/web/accessibility/aria/aria_techniques/using_the_radio_role/index.html b/files/fr/web/accessibility/aria/aria_techniques/using_the_radio_role/index.html
deleted file mode 100644
index cf566aa1e2..0000000000
--- a/files/fr/web/accessibility/aria/aria_techniques/using_the_radio_role/index.html
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: Utilisation du groupe rôle
-slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_radio_role
-tags:
- - NeedsContent
-translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_radio_role
-original_slug: Accessibilité/ARIA/Techniques_ARIA/Utilisation_du_groupe_rôle
----
-
-
-
Description
-
-
-
-
Effets possibles sur les agents utilisateurs et les technologies d'assistance
-
-
Note:il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ici est l’une de ces opinions et n’est pas normative.
-
-
Exemples
-
-
Exemple 1 :
-
-
-
-
Code
-
-
Exemples concrets :
-
-
-
-
-
Notes
-
-
Attributs ARIA utilisés
-
-
Techniques ARIA connexes
-
-
Compatibilité
-
-
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation du rôle slider.
-
+
Cette technique présente l’utilisation du rôle slider.
Le rôle slider est utilisé pour des balises qui permettent à l'utilisateur de sélectionner une valeur dans un intervalle donné. Le rôle slider est assigné à la « molette », le contrôle qui est ajusté pour modifier la valeur. Typiquement, un autre élément est stylé pour représenter visuellement l'intervalle de valeurs possibles, et le curseur est positionné visuellement pour représenter la valeur dans cet intervalle. Lorsque l'utilisateur interagit avec la molette, l'application doit programmatiquement ajuster l'attribut aria-valuenow du curseur de défilement (et si possible aria-valuetext) pour refléter la valeur courante. Voir la section {{ anch("Exemples") }} ci-dessous pour plus d'informations.
Le curseur doit pouvoir recevoir le focus et être manipulable au clavier. Lorsque l'utilisateur tabule pour amener le focus sur le curseur, il doit arriver sur la molette : le contrôle qu'un utilisateur de souris fera glisser. Les touches flèches doivent agir de la façon suivante (attention toutefois, dans les applications, aux directions de flèches pour les langues s'écrivant de droite à gauche) :
Effets possibles sur les agents utilisateurs et les technologies d’assistance
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation du rôle status et décrit les effets produits sur les navigateurs et les technologies d’assistance.
-
-
Le rôle status est un type de zone live et un conteneur dont le contenu est un message d’informations destiné à l’utilisateur. Ce message n’est pas assez important pour justifier une alerte. Il est souvent présenté comme une barre d’état. Lorsque le rôle est ajouté à un élément, le navigateur émettra un événement status accessible aux produits de technologies d’assistance qui pourront alors le notifier à l’utilisateur.
-
Le contenu des informations d’état doit être fourni dans un objet d’état et il faut s’assurer que cet objet ne reçoive pas le focus. Si une autre partie de la page contrôle ce qui s’affiche dans l’objet d’état, la relation doit être explicitement définie à l’aide de l’attribut aria-controls.
+
+
Cette technique présente l’utilisation du rôle status et décrit les effets produits sur les navigateurs et les technologies d’assistance.
+
+
Le rôle status est un type de zone live et un conteneur dont le contenu est un message d’informations destiné à l’utilisateur. Ce message n’est pas assez important pour justifier une alerte. Il est souvent présenté comme une barre d’état. Lorsque le rôle est ajouté à un élément, le navigateur émettra un événement status accessible aux produits de technologies d’assistance qui pourront alors le notifier à l’utilisateur.
+
Le contenu des informations d’état doit être fourni dans un objet d’état et il faut s’assurer que cet objet ne reçoive pas le focus. Si une autre partie de la page contrôle ce qui s’affiche dans l’objet d’état, la relation doit être explicitement définie à l’aide de l’attribut aria-controls.
Les technologies d’assistance devraient réserver des cellules dans la grille Braille pour rendre l’état.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
Lorsque le rôle status est ajouté à un élément, ou qu’un tel élément devient visible, l’agent utilisateur devrait suivre les étapes suivantes :
Les loupes d’écran devraient agrandir l’objet d’état.
- Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Exemples
Exemple 1 : ajout du rôle status dans le code HTML
L’extrait de code ci-dessous montre comment le rôle status est ajouté directement dans le code source HTML.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Autres ressources
-
Bonnes pratiques ARIA – Implémentation des zones live : #LiveRegions.
+
Bonnes pratiques ARIA – Implémentation des zones live : #LiveRegions.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
-
-
- Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
-
Exemples
-
Exemple 1 :
-
-
Code
-
Exemples concrets :
-
-
-
Notes
-
Attributs ARIA utilisés
-
Techniques ARIA connexes
-
Compatibilité
-
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Tout d’abord, veuillez lire la technique aria-required pour commencer, si vous ne l’avez pas déjà lu, puisque la technique abordée en est le prolongement.
+
Tout d’abord, veuillez lire la technique aria-required pour commencer, si vous ne l’avez pas déjà lu, puisque la technique abordée en est le prolongement.
La code JavaScript obtenu ressemble à ce qui suit, inséré au-dessus de la balise fermante {{ HTMLElement("head") }} :
-
<script type="application/javascript">
+
<script type="application/javascript">
function removeOldAlert()
{
var oldAlert = document.getElementById("alert");
@@ -91,7 +91,7 @@ function checkValidity(aID, aSearchTerm, aMsg)
</script>
-
La fonction checkValidity
+
La fonction checkValidity
Le cœur est la fonction checkValidity. Elle accepte trois paramètres : l’ID du champ de saisi qui doit être validé, le terme à recherche pour assurer la validité, et le message d’erreur à insérer dans l’alerte.
@@ -106,17 +106,17 @@ function checkValidity(aID, aSearchTerm, aMsg)
Si le terme recherché est trouvé, l’attribut aria-invalid est réinitialisé à true. De plus, toute alerte qui subsisterait serait supprimée.
-
La fonction addAlert
+
La fonction addAlert
Cette fonction commence par enlever toutes les alertes restantes. Son fonctionnement est simple : elle cherche un élément avec un identifiant alert, et si elle en trouve un, l’enlève du modèle objet de document (DOM).
-
Ensuite, la fonction crée un élément {{ HTMLElement("div") }} qui contient le texte de l’alerte. On lui attribue l’ID alert. Et son rôle est défini comme celui d’une « alert ». C’est inspiré par ARIA, même si le nom de l’attribut ne comporte par « aria ». Cela découle du fait que ce rôle est basé sur le module XHTML Role Attribut qui a été tout simplement porté sur HTML pour plus de simplicité.
+
Ensuite, la fonction crée un élément {{ HTMLElement("div") }} qui contient le texte de l’alerte. On lui attribue l’ID alert. Et son rôle est défini comme celui d’une « alert ». C’est inspiré par ARIA, même si le nom de l’attribut ne comporte par « aria ». Cela découle du fait que ce rôle est basé sur le module XHTML Role Attribut qui a été tout simplement porté sur HTML pour plus de simplicité.
Le texte est ajouté à l’élément {{ HTMLElement("div") }}, qui est lui-même ajouté au document.
Au moment où cela se produira, Firefox déclenchera un événement « alert » pour la technologie d’assistance lorsque la {{ HTMLElement("div") }} apparaîtra. La plupart des lecteurs d’écran prendront celui-ci automatiquement et le liront. C’est similaire à la barre de notification de Firefox qui apparaît lorsque vous désirez mémoriser un mot de passe. Cette alerte que nous venons de créer n’a pas de bouton sur lequel cliquer, elle se contente de nous dire ce qui est erroné.
-
Ajouter de la magie à l’événement onblur
+
Ajouter de la magie à l’événement onblur
Tout ce qu’il reste à faire, c’est ajouter un gestionnaire d’événement. Nous avons besoin de modifier les deux {{ HTMLElement("input") }} de l’adresse électronique et du nom par ce qui suit :
@@ -138,7 +138,7 @@ function checkValidity(aID, aSearchTerm, aMsg)
Dans les deux cas, lorsque le focus revient sur le champ concerné, votre lecteur d’écran devrait vous dire que le champ est invalide. JAWS 9 prend en charge cette fonction, mais pas JAWS 8, aussi il se peut que ça ne fonctionne pas pour toutes les versions des lecteurs d’écran pris en charge.
-
Quelques questions qu’on peut se poser
+
Quelques questions qu’on peut se poser
Q. Pourquoi mettre à la fois un (required) dans le texte du label et l’attribut aria-required sur certains éléments {{ HTMLElement("input") }} ?
@@ -147,12 +147,6 @@ function checkValidity(aID, aSearchTerm, aMsg)
R. Cela n’est pas autorisé par, au moins, la spécification de l’API Windows, et probablement par d’autres. De plus, laisser le focus se déplacer sans réelle intervention de l’utilisateur n’est généralement pas considéré comme une chose à faire.
-
-
TBD : let's rethink this – personally, I think setting focus might be good if done without causing a keyboard trap.
-
-
()Il faudrait y réfléchir – personnellement, je pense que définir le focus peut être une bonne chose si c’est fait sans causer de perturbation à la navigation au clavier).
-
-
-
Conclusion
+
Conclusion
L’accessibilité des sites web est grandement améliorée lorsqu’on fournit des alertes accessibles pour la validation côté client. Il n’y a rien de plus frustrant pour un utilisateur que de remplir un formulaire d’une vingtaine de champs, voire plus, de le soumettre, de constater que seuls quelques champs ne sont pas correctement renseignés et de devoir tout recommencer depuis le début pour s’assurer que les valeurs sont correctement mémorisées, ou de fournir des informations redondantes.
Lors de l’implémentation de formulaires à l’aide d’éléments de formulaire HTML classiques, il est important de fournir des labels pour les contrôles et d’associer explicitement un label avec son contrôle. Lorsqu’un utilisateur de lecteur d’écran navigue sur une page, le lecteur d’écran décrit les contrôles de formulaire ; mais sans association directe entre un contrôle et son label, le lecteur d’écran n’a aucun moyen de savoir quel est le label correspondant.
L’élément HTML {{ HTMLElement("label") }} est approprié pour les éléments liés aux formulaires, mais de nombreux contrôles de formulaires sont implémentés sous forme de composants JavaScript dynamiques et utilisent les éléments {{ HTMLElement("div") }} ou {{ HTMLElement("span") }}. WAI-ARIA, la spécification Accessible Rich Internet Applications (Applications Internet Riches Accessibles) de la Web Accessibility Initiative (Initiative pour l’Accessibilité du web) du W3C, fournit l’attribut aria-labelledby dans ces cas de figure.
+
L’élément HTML {{ HTMLElement("label") }} est approprié pour les éléments liés aux formulaires, mais de nombreux contrôles de formulaires sont implémentés sous forme de composants JavaScript dynamiques et utilisent les éléments {{ HTMLElement("div") }} ou {{ HTMLElement("span") }}. WAI-ARIA, la spécification Accessible Rich Internet Applications (Applications Internet Riches Accessibles) de la Web Accessibility Initiative (Initiative pour l’Accessibilité du web) du W3C, fournit l’attribut aria-labelledby dans ces cas de figure.
L’exemple ci-dessous montre un groupe de boutons radio implémenté à l’aide d’une liste non-ordonnée. Remarquez, à la ligne 3, que l’attribut aria-labelledby de l’élément {{ HTMLElement("ul") }} est défini comme « rg1_label », et est identique à l’id de l’élément {{ HTMLElement("h3") }} de la ligne 1, qui sert de label au groupe de boutons radio.
Les contrôles de formulaire peuvent parfois avoir une description qui leur est associée, en plus du label. ARIA fournit l’attribut aria-describedby pour associer directement une description à un contrôle donné.
+
Les contrôles de formulaire peuvent parfois avoir une description qui leur est associée, en plus du label. ARIA fournit l’attribut aria-describedby pour associer directement une description à un contrôle donné.
L’exemple ci-dessous montre un élément {{ HTMLElement("button") }} décrit par une phrase contenue dans un élément {{ HTMLElement("div") }} séparé. L’attribut aria-describedby du {{ HTMLElement("button") }} fait référence à l’id de l’élément {{ HTMLElement("div") }}.
(Notez que l’attribut aria-describedby est utilisé de différentes façons, en plus des contrôles de formulaires.)
-
Champs obligatoires et invalides
+
Champs obligatoires et invalides
Les développeur Web utilisent souvant des éléments de présentation visuels pour indiquer les champs obligatoires ou invalides, mais les technologies d’assistance ne peuvent pas toujours déduire ces informations à partir de la présentation. ARIA fournit des attributs pour indiquer l’obligation de renseigner un contrôle de formulaire ou la validité de son contenu :
-
La propriété aria-required peut être appliquée à un élément de formulaire pour indiquer à une technologie d’assistance qu’il est obligatoire pour compléter le formulaire.
-
L’état aria-invalid peut être programmatiquement appliquée pour indiquer à une technologie d’assistance quel champ contient des données incorrectes, afin que l’utilisateur sache qu’il a saisi des données invalides.
+
La propriété aria-required peut être appliquée à un élément de formulaire pour indiquer à une technologie d’assistance qu’il est obligatoire pour compléter le formulaire.
+
L’état aria-invalid peut être programmatiquement appliquée pour indiquer à une technologie d’assistance quel champ contient des données incorrectes, afin que l’utilisateur sache qu’il a saisi des données invalides.
L’exemple ci-dessous montre un formulaire simple avec 3 champs. Aux lignes 4 et 12, les attributs aria-required sont définis à true (en plus de l’astérisque en début de champ) indiquant que le nom et l’adresse électronique sont obligatoires. La seconde partie de l’exemple est un snippet JavaScript qui valide le format de l’adresse électronique et qui définit l’attribut aria-invalid du champ « Courriel » (ligne 12 du code HTML) selon le résultat (en plus de la modification de la présentation de l’élément).
@@ -113,8 +113,8 @@ original_slug: Accessibilité/ARIA/formulaires/Indications_elementaires_pour_les
setElementBorderColour(emailElement, valid); // colore la bordure en rouge sur le second argument est false
};
-
Utiliser ARIA avec des labels comportant des champs
-
Problème
+
Problème
Un formulaire pose une question à un utilisateur, mais la zone de réponse est une partie de la phrase qui constitue la question. Un exemple classique que nous connaissons tous dans notre navigateur, c’est la paramètre des préférences « Effacer l’historique après [x] jours. » « Effacer l’historique après » est à la gauche de la boîte texte, « x » est le nombre, par exemple 21, et le mot « jours » suit la boîte texte, formant ainsi un phrase qu'il est facile de comprendre.
JAWS 8.0 possède sa propre logique pour trouver les labels, ce qui lui fait systématiquement supplanter le nomAccessible que peut avoir une boîte texte dans un document HTML. Avec JAWS 8, je n’ai trouvé aucun moyen de lui faire accepter le label de l’exemple ci-dessus. Mais NVDA et Window-Eyes le font très bien, et Orca sur Linux n’a aucun problème non plus.
-
Peut-on faire la même chose sans ARIA ?
-
-
Ben Millard fait remarquer dans un billet que les contrôles peuvent être imbriqués dans des labels, comme démontré dans l'exemple ci-dessus avec HTML 4, simplement en imbriquant l'élément input dans le label. Merci pour cette info, Ben ! Elle est vraiment utile et montre que certaines techniques existantes depuis des années nous échappe, même aux gourous que nous sommes. Cette technique fonctionne dans Firefox ; cependant, elle ne fonctionne actuellement pas dans de nombreux autres navigateurs, y compris IE. Donc, pour les labels comprenant des contrôles de formulaires, l'utilisation de aria-labelledby est encore la meilleure approche.
+
Peut-on faire la même chose sans ARIA ?
-
TBD: Ajouter plus d’infos sur la compatibilité
+
Ben Millard fait remarquer dans un billet que les contrôles peuvent être imbriqués dans des labels, comme démontré dans l'exemple ci-dessus avec HTML 4, simplement en imbriquant l'élément input dans le label. Merci pour cette info, Ben ! Elle est vraiment utile et montre que certaines techniques existantes depuis des années nous échappe, même aux gourous que nous sommes. Cette technique fonctionne dans Firefox ; cependant, elle ne fonctionne actuellement pas dans de nombreux autres navigateurs, y compris IE. Donc, pour les labels comprenant des contrôles de formulaires, l'utilisation de aria-labelledby est encore la meilleure approche.
L'état de la technologie ARIA a toujours dépendu de la communauté. Si vous remarquez un problème d'implémentation, veuillez prendre un instant pour en informer les développeurs. Voici comment déposer les bugs :
-
Quand vous trouvez un bug, veuillez en aviser les tables de compatibilité liées dans la page des exemples.
+
+
Note : Quand vous trouvez un bug, veuillez en aviser les tables de compatibilité liées dans la page des exemples.
+
A faire : ajouter la bon lien d'accessibilité à la table
Accessible Rich Internet Applications(ARIA) (qu'on pourrait traduire par « applications internet riches et accessibles ») sont un ensemble un attribut qui définit comment rendre le contenu et les applications web accessibles.
+
Accessible Rich Internet Applications(ARIA) (qu'on pourrait traduire par « applications internet riches et accessibles ») sont un ensemble un attribut qui définit comment rendre le contenu et les applications web accessibles.
-
ARIA complète HTML afin que les éléments interactifs et les widgets puissent être utilisés par les outils d'assistance quand les fonctionnalités standard ne le permettent pas. Ainsi, ARIA permet de rendre accessible les widgets JavaScript, les indications dans les formulaires, les messages d'erreur et les mises à jour dynamiques du contenu, etc.
+
ARIA complète HTML afin que les éléments interactifs et les widgets puissent être utilisés par les outils d'assistance quand les fonctionnalités standard ne le permettent pas. Ainsi, ARIA permet de rendre accessible les widgets JavaScript, les indications dans les formulaires, les messages d'erreur et les mises à jour dynamiques du contenu, etc.
-
Attention ! La plupart de ces widgets ont été intégrés au sein d'HTML5 et mieux vaudra donc utiliser les éléments « sémantiques » HTML lorsqu'ils sont disponibles. Ainsi, les éléments natifs disposent de fonctionnalités de navigation au clavier, de rôles et d'états définis en standard. Toutefois, lorsque vous choisissez d'utiliser ARIA, il vous revient de recoder les fonctionnalités équivalentes dans vos scripts.
+
Attention : La plupart de ces widgets ont été intégrés au sein d'HTML5 et mieux vaudra donc utiliser les éléments « sémantiques » HTML lorsqu'ils sont disponibles. Ainsi, les éléments natifs disposent de fonctionnalités de navigation au clavier, de rôles et d'états définis en standard. Toutefois, lorsque vous choisissez d'utiliser ARIA, il vous revient de recoder les fonctionnalités équivalentes dans vos scripts.
Voici un widget utilisé pour une barre de progression :
Il est aussi important de tester l'ARIA écrit avec des technologies d'assistance réelles. Bien qu'il existe certains émulateurs et simulateurs, rien ne vaut un test réel afin d'obtenir suffisamment de garanties.
Un guide pratique pour les développeurs qui fournit également des suggestions quant aux attributs ARIA à utiliser sur les éléments HTML sur la base d'implémentations concrètes.
Les éléments tels que <input>, <button> disposent de fonctionnalités natives pour l'utilisation au clavier. Si on triche en utilisant des <div> et ARIA, on doit s'assurer que l'accessibilité au clavier soit préservée.
Un rapide résumé des régions interactives par les concepteurs du lecteur d'écran JAWS. Les régions dynamiques sont également prises en charge par NVDA pour Firefox et par VoiceOver avec Safari.
Cette technique présente l’utilisation du rôle banner (en).
+
Cette technique présente l’utilisation du rôle banner (en).
La zone d’entête principale d'un site devrait être structurée avec <header role="banner">. Cette zone peut contenir le logo du site, sa description, le moteur de recherche.
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
Le rôle button devrait être utilisé pour les éléments cliquables qui déclenchent une réponse lorsqu'activés par l'utilisateur. Ajouter role="button" permettra à un élément d'apparaître comme un bouton de contrôle pour un lecteur d'écran. Ce rôle peut être utilisé avec l'attribut aria-pressed afin de créer des boutons interrupteurs.
+
Le rôle button devrait être utilisé pour les éléments cliquables qui déclenchent une réponse lorsqu'activés par l'utilisateur. Ajouter role="button" permettra à un élément d'apparaître comme un bouton de contrôle pour un lecteur d'écran. Ce rôle peut être utilisé avec l'attribut aria-pressed afin de créer des boutons interrupteurs.
Note : Si on utilise role="button" plutôt que les éléments sémantiques <button> ou <input type="button">, il faudra : permettre à l'élément de recevoir le focus, définir des gestionnaires d'évènements pour click et keydown, y compris la gestion des touches Entrée et Espace, afin de traiter la saisie de l'utilisateur. Voir l'exemple de code officiel de WAI-ARIA.
+
Note : Si on utilise role="button" plutôt que les éléments sémantiques <button> ou <input type="button">, il faudra : permettre à l'élément de recevoir le focus, définir des gestionnaires d'évènements pour click et keydown, y compris la gestion des touches Entrée et Espace, afin de traiter la saisie de l'utilisateur. Voir l'exemple de code officiel de WAI-ARIA.
Description
@@ -248,8 +248,8 @@ function toggleButton(element) {
Les boutons sont des contrôles interactifs et, à ce titre, peuvent recevoir le focus. Si le rôle button est ajouté à un élément qui ne peut recevoir le focus nativement (comme <span>, <div> ou <p>), l'attribut tabindex devra être utilisé afin de permettre le focus sur le bouton.
-
-Attention ! Lorsqu'on utilise des liens avec le rôle button, il faut rajouter un gestionnaire d'évènement pour la touche Espace. En effet, les boutons s'activent avec Espace ou Entrée tandis que, nativement, les liens ne se déclenchent qu'avec Entrée.
+
+
Attention : Lorsqu'on utilise des liens avec le rôle button, il faut rajouter un gestionnaire d'évènement pour la touche Espace. En effet, les boutons s'activent avec Espace ou Entrée tandis que, nativement, les liens ne se déclenchent qu'avec Entrée.
Lorsqu'on utilise le rôle button, les lecteurs d'écran annonce l'élément comme un bouton, généralement en énonçant « clic » suivi du nom accessible du bouton. Le nom accessible correspond au contenu de l'élément ou à la valeur de aria-label ou à l'élément référencé avec l'attribut aria-labelledby, ou à une description si elle existe.
@@ -297,10 +297,5 @@ function toggleButton(element) {
+
\ No newline at end of file
diff --git a/files/fr/web/accessibility/aria/roles/checkbox_role/index.html b/files/fr/web/accessibility/aria/roles/checkbox_role/index.html
index 04926e9349..7b6168e783 100644
--- a/files/fr/web/accessibility/aria/roles/checkbox_role/index.html
+++ b/files/fr/web/accessibility/aria/roles/checkbox_role/index.html
@@ -9,9 +9,9 @@ translation_of: Web/Accessibility/ARIA/Roles/checkbox_role
original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_checkbox
---
Description
-
-
Cette technique présente l’utilisation du rôle checkbox.
-
+
+
Cette technique présente l’utilisation du rôle checkbox.
+
Le rôle checkbox est utilisé pour des contrôles interactifs à cocher. Si un élément utilise role="checkbox", il est obligatoire pour cet élément d’avoir également un attribut aria-checked qui présente l’état de la case à cocher aux technologies d’assistance. Alors que le contrôle de formulaire HTML natif checkbox ne peut avoir que deux états (« coché » ou « décoché »), un élément avec le rôle role=checkbox peut présenter trois états pour l'attribut aria-checked :
Les lecteurs d’écran devraient annoncer l’élément comme une case à cocher, et, éventuellement, fournir des instructions sur les façons de l’activer.
- Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation du rôle dialog (en).
-
+
Cette technique présente l’utilisation du rôle dialog (en).
Le rôle dialog est utilisé pour marquer une fenêtre ou une boîte de dialogue d’application web qui sépare le contenu ou l’UI du reste de l’application web ou de la page. Visuellement, les boîtes de dialogues sont généralement placées par dessus le contenu de la page, à l’aide d’un calque (ou « Overlay »). Les boîtes de dialogue peuvent être non-modales (ce qui signifie qu’il est toujours possible d’interagir avec le contenu situé hors de la boîte de dialogue) ou modales (ce qui signifie qu’on ne peut interagir qu’avec le contenu de la boîte de dialogue).
Si une boîte de dialogue a une barre de titre visible, le texte de cette barre peut être utilisé comme label pour la boîte elle-même. La meilleure façon de le faire est d’utiliser l’attribut aria-labelledby pour l’élément role="dialog". De plus, si la boîte de dialogue contient une description supplémentaire, en plus du titre de la boîte, le texte de la description peut être associé avec la boîte de dialogue à l’aide de l’attribut aria-describedby. Cette approche est illustrée dans l’extrait de code ci-dessous :
<div role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
<h2 id="dialog1Title">Vos informations personnelles ont correctement été actualisées.</h2>
<p id="dialog1Desc">Vous pouvez modifier vos informations personnelles à n’importe quel moment depuis la section « Compte utilisateur. »</p>
@@ -41,7 +39,9 @@ original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_dialog
</div>
-
Gardez en tête que le titre d’une boîte de dialogue et sa description ne doivent pas être focalisables afin de toujours être perçus par les lecteurs d’écran opérant en mode non-virtuel. La combinaison du rôle ARIA dialog et des techniques de labélisation devrait permettre aux lecteurs d’écran d’annoncer les informations de la boîte de dialogue lorsque le focus arrive sur cette dernière.
+
+
Note : Gardez en tête que le titre d’une boîte de dialogue et sa description ne doivent pas être focalisables afin de toujours être perçus par les lecteurs d’écran opérant en mode non-virtuel. La combinaison du rôle ARIA dialog et des techniques de labélisation devrait permettre aux lecteurs d’écran d’annoncer les informations de la boîte de dialogue lorsque le focus arrive sur cette dernière.
Quand la boîte de dialogue s’affiche à l’écran, le focus clavier devrait être placé sur le contrôle focalisable par défaut de la boîte de dialogue. Ce contrôle dépend de la fonction des boîtes de dialogue. Pour les boîtes de dialogue ne fournissant qu’un texte simple, ce pourra être un bouton « OK ». Pour les boîtes de dialogue contenant un formulaire, ce pourra être le premier champ à renseigner du formulaire.
Pour la plupart des boîtes de dialogue, le comportement attendu est que l’ordre de tabulation de la boîte tourne, c’est-à-dire que le premier élément focalisable sera focalisé après que le dernier élément focalisable de la boîte de dialogue aura été atteint lorsque l’utilisateur tabule. En d’autres termes, l’ordre de tabulation doit être contenu par la boîte de dialogue.
Si la boîte de dialogue peut être déplacée ou redimensionnée, assurez-vous que ces actions peuvent être exécutées par les utilisateurs de clavier tout comme les utilisateurs de souris. De la même façon, si une boîte de dialogue fournit certaines fonctionnalités, comme des barres d’outils ou des menus contextuels, celles-ci doivent également être accessibles et pouvoir être actionnées par les utilisateurs de clavier.
-
Les boîtes de dialogue peuvent être modales ou non modales. Lorsqu’une boîte de dialogue modale s’affiche à l’écran, il n’est pas possible d’interagir avec le reste du contenu de la page. En d’autres termes, l’UI principale de l’application ou le contenu de la page est considéré comme temporairement désactivé tant que la boîte de dialogue modale est affichée. Pour les boîtes de dialogue non modales il est toujours possible d’interagir avec du contenu extérieur à la boîte lorsqu’elle est affichée. Pour les boîtes de dialogue non modales, il y devra toujours y avoir un raccourci clavier global permettant de déplacer le focus entre les boîtes de dialogue ouvertes et la page principale. Pour plus d’informations, lisez le guide Gérer les dialogues modaux et non modaux.
+
Les boîtes de dialogue peuvent être modales ou non modales. Lorsqu’une boîte de dialogue modale s’affiche à l’écran, il n’est pas possible d’interagir avec le reste du contenu de la page. En d’autres termes, l’UI principale de l’application ou le contenu de la page est considéré comme temporairement désactivé tant que la boîte de dialogue modale est affichée. Pour les boîtes de dialogue non modales il est toujours possible d’interagir avec du contenu extérieur à la boîte lorsqu’elle est affichée. Pour les boîtes de dialogue non modales, il y devra toujours y avoir un raccourci clavier global permettant de déplacer le focus entre les boîtes de dialogue ouvertes et la page principale. Pour plus d’informations, lisez le guide Gérer les dialogues modaux et non modaux.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
Lorsque la boîte de dialogue est correctement labélisée et que le focus est déplacé vers un contrôle à l’intérieur de la boîte, les lecteurs d’écran devraient annoncer le rôle accessible du dialogue, son nom et éventuellement sa description avant d’annoncer l’élément qui a reçu le focus.
-
Note : plusieurs points de vue existent sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
+
Note : plusieurs points de vue existent sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Exemples
Exemple 1 : une boîte de dialogue contenant un formulaire
<div role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
<h2 id="dialog1Title">Formulaire de souscription</h2>
<p id="dialog1Desc">Nous ne partageons pas ces informations avec des tierces parties.</p>
@@ -108,7 +110,7 @@ original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_dialog
Pour prendre en charge les navigateurs ou les produits de technologies d’assistance qui ne prennent pas ARIA en charge, il est également possible d’appliquer le balisage dialog à un élément fieldset comme contenu alternatif. Ainsi le titre de la boîte de dialogue sera toujours annoncé correctement :
<fieldset role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
<legend>
<span id="dialog1Title">Vos informations personnelles ont correctement été actualisées.</span>
<span id="dialog1Desc">Vous pouvez modifier vos informations personnelles à n’importe quel moment depuis la section « Compte utilisateur ».</span>
@@ -121,29 +123,27 @@ original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_dialog
Note : bien qu'il soit possible d’empêcher les utilisateurs de clavier de bouger le focus vers des éléments en dehors des boîtes de dialogues, les utilisateurs de lecteurs d’écran ont toujours la possibilité de parcourir ce contenu pratiquement en utilisant le curseur virtuel du lecteur d’écran. À cause de cela, les boîtes de dialogue sont considérées comme des cas spéciaux du rôle application : on s’attend à ce qu’elles soient parcourues avec le mode de navigation non-virtuel par les utilisateurs de lecteur d’écran.
+
+
Note : bien qu'il soit possible d’empêcher les utilisateurs de clavier de bouger le focus vers des éléments en dehors des boîtes de dialogues, les utilisateurs de lecteurs d’écran ont toujours la possibilité de parcourir ce contenu pratiquement en utilisant le curseur virtuel du lecteur d’écran. À cause de cela, les boîtes de dialogue sont considérées comme des cas spéciaux du rôle application : on s’attend à ce qu’elles soient parcourues avec le mode de navigation non-virtuel par les utilisateurs de lecteur d’écran.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Cette technique présente l’utilisation du rôle listbox et décrit les effets produits sur les navigateurs et les technologies d’assistance.
-
+
Cette technique présente l’utilisation du rôle listbox et décrit les effets produits sur les navigateurs et les technologies d’assistance.
Le rôle listbox est utilisé pour identifier un élément qui crée une liste à partir de laquelle un utilisateur peut sélectionner un ou plusieurs éléments statiques et peut contenir des images, contrairement à l’élément HTML {{ HTMLElement("select") }}. Lorsque ce rôle est ajouté à un élément, le navigateur émettra un événement accessible listbox aux produits de technologie d’assistance qui pourront alors le notifier à l’utilisateur.
-
Chaque entrée de la boîte liste devrait avoir un rôle d’option et devrait être une descendante de la boîte liste dans l’arbre DOM. Si une ou plusieurs entrées ne sont pas des descendantes de la boîte liste dans le DOM, référez-vous aux Bonnes pratiques ARIA pour obtenir plus de détails sur les propriétés additionnelles qui doivent être définies.
+
Chaque entrée de la boîte liste devrait avoir un rôle d’option et devrait être une descendante de la boîte liste dans l’arbre DOM. Si une ou plusieurs entrées ne sont pas des descendantes de la boîte liste dans le DOM, référez-vous aux Bonnes pratiques ARIA pour obtenir plus de détails sur les propriétés additionnelles qui doivent être définies.
-
Lorsqu’on navigue entre les différents éléments d’une liste, le premier élément de la liste sera sélectionné par défaut en l’absence de sélection existante. Les flèches haut et bas permettent de naviguer dans la liste, et appuyer sur Maj+Flèche haut/bas déplacera et développera la sélection. Saisir un ou plusieurs lettres permet de naviguer dans la liste des éléments (une seule et même lettre positionnera la sélection sur chacun des éléments qui commence par elle, plusieurs lettres placeront la sélection sur le premier élément commençant par la chaîne). Si l’élément courant est associé à un menu contextuel, Maj+F10 affichera ce menu. Si les éléments de la liste peuvent être cochés, Espace peut être utilisée pour basculer l’état de la checkboxes. Pour les éléments de liste sélectionnables, Espace bascule l’état de sélection, Maj+Espace peut être utilisé pour sélection des éléments contigus, Ctrl+Flèche déplace le curseur sans sélectionner d’élément, et Ctrl+Espace peut être utilisé pour sélectionner des éléments non-contigus. Il est recommandé d’utiliser une case à cocher, un lien ou tout autre méthode pour permettre la sélection de tous les éléments, et Ctrl+A peut être utilisé comme raccourci pour cela.
+
Lorsqu’on navigue entre les différents éléments d’une liste, le premier élément de la liste sera sélectionné par défaut en l’absence de sélection existante. Les flèches haut et bas permettent de naviguer dans la liste, et appuyer sur Maj+Flèche haut/bas déplacera et développera la sélection. Saisir un ou plusieurs lettres permet de naviguer dans la liste des éléments (une seule et même lettre positionnera la sélection sur chacun des éléments qui commence par elle, plusieurs lettres placeront la sélection sur le premier élément commençant par la chaîne). Si l’élément courant est associé à un menu contextuel, Maj+F10 affichera ce menu. Si les éléments de la liste peuvent être cochés, Espace peut être utilisée pour basculer l’état de la checkboxes. Pour les éléments de liste sélectionnables, Espace bascule l’état de sélection, Maj+Espace peut être utilisé pour sélection des éléments contigus, Ctrl+Flèche déplace le curseur sans sélectionner d’élément, et Ctrl+Espace peut être utilisé pour sélectionner des éléments non-contigus. Il est recommandé d’utiliser une case à cocher, un lien ou tout autre méthode pour permettre la sélection de tous les éléments, et Ctrl+A peut être utilisé comme raccourci pour cela.
Effets possibles sur les agents utilisateurs et les technologies d’assistance
Lorsque le rôle listbox est ajouté à un élément, ou qu’un tel élément devient visible, l’agent utilisateur devrait suivre les étapes suivantes :
-
Présenter l’élément comme ayant un rôle d’alerte à l’API d’accessibilité du système d’exploitation. Alternativement, s’il est un enfant de ou s’il appartient à une boîte combinée combobox, présenter l’élément comme un menu ;
+
Présenter l’élément comme ayant un rôle d’alerte à l’API d’accessibilité du système d’exploitation. Alternativement, s’il est un enfant de ou s’il appartient à une boîte combinée combobox, présenter l’élément comme un menu ;
Déclencher un événement liste (ou dans les cas spéciaux, un événement menu) accessible à l’aide l’API d’accessibilité du système d’exploitation si elle le prend en charge.
Les loupes d’écran devraient agrandir la boîte liste.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
Pour être accessible au clavier, les développeurs doivent gérer le focus de chaque descendant de ce rôle.
+
Pour être accessible au clavier, les développeurs doivent gérer le focus de chaque descendant de ce rôle.
Il est recommandé aux développeurs d’utiliser différents styles pour la sélection lorsque la liste n’a pas le focus, par exemple, une sélection inactive est parfois affichée avec une couleur d’arrière-plan plus claire.
-
Si la boîte liste ne fait pas partie d’un autre composant, il faut définir sa propriété aria-labelledby.
-
Si une ou plusieurs entrées ne sont pas des descendants DOM de la boîte liste, il faudra définir des propriétés aria-* supplémentaires (voir Bonnes pratiques ARIA).
-
S’il existe une bonne raison pour étendre la boîte liste, le rôle combobox peut être plus approprié.
+
Si la boîte liste ne fait pas partie d’un autre composant, il faut définir sa propriété aria-labelledby.
+
Si une ou plusieurs entrées ne sont pas des descendants DOM de la boîte liste, il faudra définir des propriétés aria-* supplémentaires (voir Bonnes pratiques ARIA).
+
S’il existe une bonne raison pour étendre la boîte liste, le rôle combobox peut être plus approprié.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
Le rôle ARIA switch est très similaire au role checkbox, à la sémantique près — il a deux états représentant on/off, au lieu de checked/unchecked.
+
Le rôle ARIA switch est très similaire au role checkbox, à la sémantique près — il a deux états représentant on/off, au lieu de checked/unchecked.
Extrait des spec ARIA 1.1 : l'attribut aria-checked d'un switch indique si l'entrée est on (true) ou off (false). La valeur mixed n'est pas supportée, et les agents utilisateurs DOIVENT la traiter comme équivalente à false pour ce rôle.
Cette technique présente l’utilisation du rôle textbox et décrit les effets produits sur les navigateurs et les technologies d’assistance.
-
+
Cette technique présente l’utilisation du rôle textbox et décrit les effets produits sur les navigateurs et les technologies d’assistance.
Le rôle textbox est utilisé pour identifier un élément permettant la saisie d’un texte librement formaté. Lorsque ce rôle est ajouté à un élément, le navigateur émettra un événement textbox accessible aux produits de technologie d’assistance qui pourront alors le notifier à l’utilisateur.
Les loupes d’écran devraient agrandir la boite de texte.
-
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
+
Note : il existe plusieurs points de vue sur la façon dont les technologies d’assistance devraient traiter cette technique. L’information fournie ci-dessus est l’une de ces opinions et n’est pas normative.
À définir : ajouter les informations de prise en charge pour les combinaisons les plus courantes d’agents utilisateurs et de produits de technologies d’assistance.
WAI-ARIA est la spécification Applications Internet Riches Accessibles de la Web Accessibility Initiative (Initiative pour l’accessibilité du Web) du W3C. ARIA fournit des moyens de rendre plus accessible les applications Web et les composants dynamiques à une plus grande part des utilisateurs, y compris ceux utilisant des technologies d’assistance telles que les lecteurs d’écrans ou les agrandisseurs.
+
WAI-ARIA est la spécification Applications Internet Riches Accessibles de la Web Accessibility Initiative (Initiative pour l’accessibilité du Web) du W3C. ARIA fournit des moyens de rendre plus accessible les applications Web et les composants dynamiques à une plus grande part des utilisateurs, y compris ceux utilisant des technologies d’assistance telles que les lecteurs d’écrans ou les agrandisseurs.
ARIA fournit des éléments sémantiques additionnels afin de décrire les rôles, les états et la fonction de nombreux contrôles d’interfaces utilisateurs répandus, tels que les menus, les curseurs, les arbres et les dialogues. Il fournit également des informations structurelles supplémentaires, permettant aux auteurs d’identifier des points de repère, des zones et des grilles dans leurs pages Web. ARIA permet aux applications et aux composants JavaScript dynamiques d’interagir avec une grande variété de technologies d’assistance de bureau.
Prise en charge encore expérimentale des lecteurs d’écran jusqu’à Chrome 15
@@ -49,12 +49,12 @@ original_slug: Accessibilité/ARIA/FAQ_Applications_Web_et_ARIA
La prise en charge des zones live requiert Safari 5 avec VoiceOver sur iOS5 ou OS X Lion
Dans certains cas, les versions les plus jeunes peuvent prendre en charge certaines fonctionnalités d’ARIA. Des tableaux de compatibilité des navigateurs peuvent être consultés depuis différentes sources :
Plutôt que de les intégrer directement dans le balisage, les attributs ARIA sont généralement ajoutés à l’élément et dynamiquement actualisés à l’aide de code JavaScript tel que celui-ci :
-
// Trouver le <div> de la barre de progression dans le DOM.
+
// Trouver le <div> de la barre de progression dans le DOM.
var progressBar = document.getElementById("percent-loaded");
// Définition de ses rôles et états ARIA ,
@@ -181,15 +181,15 @@ function updateProgress(percentComplete) {
Qu'en est-il de la validation ?
-
Les nouveaux attributs introduits dans ARIA, tels que les role et ceux préfixés avec aria-, ne font pas officiellement partie des spécification HTML 4 ou XHTML 4. À ce titre, les pages comportant des éléments ARIA peuvent ne pas être valides lorsqu’on les soumet au validateur du W3C.
+
Les nouveaux attributs introduits dans ARIA, tels que les role et ceux préfixés avec aria-, ne font pas officiellement partie des spécification HTML 4 ou XHTML 4. À ce titre, les pages comportant des éléments ARIA peuvent ne pas être valides lorsqu’on les soumet au validateur du W3C.
-
La première solution possible à ce problème est d’éviter de placer les rôles et les états ARIA directement dans le code HTML. À la place, il faut utiliser JavaScript pour ajouter dynamiquement ARIA à votre page, tel que montré dans la réponse à la question Pouvez-vous me montrez un exemple d’ARIA en action ? ci-dessus. Votre page sera toujours théoriquement invalide, mais elle passera correctement toutes les contrôles de validation statiques.
+
La première solution possible à ce problème est d’éviter de placer les rôles et les états ARIA directement dans le code HTML. À la place, il faut utiliser JavaScript pour ajouter dynamiquement ARIA à votre page, tel que montré dans la réponse à la question Pouvez-vous me montrez un exemple d’ARIA en action ? ci-dessus. Votre page sera toujours théoriquement invalide, mais elle passera correctement toutes les contrôles de validation statiques.
Une autre alternative est l’utilisation d’un doctype HTML5, qui prend nativement en charge . Le validateur HTML5 du W3C trouvera même pour vous les utilisations non valides d’ARIA dans les pages HTML5.
Comment HTML5 s’associe-t-il avec ARIA ?
-
HTML5 introduit de nombreuses nouvelles balises sémantiques. Certaines d’entre elles recoupent les rôles ARIA, tel que le nouvelle élément <progress>. Dans le cas où le navigateur prend en charge une balise HTML5 qui existe également dans ARIA, il n’est généralement pas nécessaire d’ajouter les rôles et les états ARIA à l’élément. ARIA comprend de nombreux rôles, états et propriétés qui ne sont pas disponibles en HTML5, aussi continueront-ils d’être utiles aux développeurs HTML5. Pour plus d’informations, Steve Faulkner a écrit un très bon aperçu des relations entre HTML5 et ARIA.
+
HTML5 introduit de nombreuses nouvelles balises sémantiques. Certaines d’entre elles recoupent les rôles ARIA, tel que le nouvelle élément <progress>. Dans le cas où le navigateur prend en charge une balise HTML5 qui existe également dans ARIA, il n’est généralement pas nécessaire d’ajouter les rôles et les états ARIA à l’élément. ARIA comprend de nombreux rôles, états et propriétés qui ne sont pas disponibles en HTML5, aussi continueront-ils d’être utiles aux développeurs HTML5. Pour plus d’informations, Steve Faulkner a écrit un très bon aperçu des relations entre HTML5 et ARIA.
Dégradation élégante de HTML5 vers ARIA
@@ -197,7 +197,7 @@ function updateProgress(percentComplete) {
Voici un exemple de code utilisé pour une barre de progression en HTML5 :
-
<!DOCTYPE html>
+
<!DOCTYPE html>
<html>
<head><title>Dégrader élégamment la barre de progression</title></head>
<body>
@@ -209,7 +209,7 @@ function updateProgress(percentComplete) {
… et voici le code JavaScript qui assurera le fonctionnement de la barre de progression même dans les navigateurs les plus anciens :
-
var progressBar = document.getElementById("progress-bar");
+
var progressBar = document.getElementById("progress-bar");
// Vérifions que le navigateur implémente la balise HTML5 <progress>.
var supportsHTML5Progress = (typeof (HTMLProgressElement) !== "undefined");
@@ -264,15 +264,15 @@ initDemo();
L’accessibilité dans le développement web signifie permettre l'utilisation des sites web par le plus grand nombre de personnes, même lorsque les capacités de ces personnes sont limitées d’une manière ou d'une autre. Voici quelques informations qui vous permettront de développer du contenu accessible.
+
L’accessibilité dans le développement web signifie permettre l'utilisation des sites web par le plus grand nombre de personnes, même lorsque les capacités de ces personnes sont limitées d’une manière ou d'une autre. Voici quelques informations qui vous permettront de développer du contenu accessible.
« L'accessibilité du web signifie que les personnes handicapées peuvent l'utiliser. Plus spécifiquement, elle signifie que ces gens peuvent percevoir, comprendre, naviguer, interagir avec le web, et y contribuer. L'accessibilité du web bénéficie également à d'autres, notamment les personnes âgées ayant des capacités diminuées dues au vieillissement. » ( L'accessibilité du Web définie dans Wikipédia)
-
« L'accessibilité numérique est la mise à la disposition de tous les individus – quels que soient leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales – des ressources numériques. » W3C Accessibility
+
« L'accessibilité numérique est la mise à la disposition de tous les individus – quels que soient leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales – des ressources numériques. » W3C Accessibility
-
Tutoriels clefs
+
Tutoriels clefs
La documentation MDN Accessibilité contient des tutoriaux modernes et à jour en ce qui concerne les points essentiels de l'accessibilité:
Un nombre important de ressources du web peuvent être accessibles juste en utilisant correctement les éléments HTML dans leur usage approprié. Cet article résume en détail comment le HTML peut être utilisé afin de garantir une accessibilité maximum.
CSS et JavaScript, quand ils sont utilisés convenablement, ont le potentiel de permettre des expériences Web accessibles… ou bien ils peuvent significativement nuire à celle-ci si mal utilisés. Cet article décrit certaines pratiques exemplaires en langages CSS et JavaScript qui devraient être prises en compte pour garantir que le contenu, même complexe, soit aussi accessible que possible.
+
CSS et JavaScript, quand ils sont utilisés convenablement, ont le potentiel de permettre des expériences Web accessibles… ou bien ils peuvent significativement nuire à celle-ci si mal utilisés. Cet article décrit certaines pratiques exemplaires en langages CSS et JavaScript qui devraient être prises en compte pour garantir que le contenu, même complexe, soit aussi accessible que possible.
Dans la continuité de l'article précédent, créer des interactions d'interface utilisateur (UX) complexes impliquant un HTML non sémantique et un contenu dynamique mis à jour par JavaScript peut être parfois compliqué. WAI-ARIA est une technologie qui peut aider à résoudre de tels problèmes en ajoutant d'autres sémantiques que les navigateurs et les technologies d'assistance peuvent reconnaître et utiliser afin de permettre aux utilisateurs d’être informés correctement. Ici, nous allons montrer comment l'utiliser à un niveau de base pour améliorer l'accessibilité.
+
Dans la continuité de l'article précédent, créer des interactions d'interface utilisateur (UX) complexes impliquant un HTML non sémantique et un contenu dynamique mis à jour par JavaScript peut être parfois compliqué. WAI-ARIA est une technologie qui peut aider à résoudre de tels problèmes en ajoutant d'autres sémantiques que les navigateurs et les technologies d'assistance peuvent reconnaître et utiliser afin de permettre aux utilisateurs d’être informés correctement. Ici, nous allons montrer comment l'utiliser à un niveau de base pour améliorer l'accessibilité.
Une autre catégorie de contenu pouvant créer des problèmes d'accessibilité est le multimédia : le contenu vidéo, audio et les images auxquels on doit fournir des textes équivalents pertinents afin qu'ils soient exploitables par les technologies d'assistance et compris par leurs utilisateurs. Cet article explique comment faire.
+
Une autre catégorie de contenu pouvant créer des problèmes d'accessibilité est le multimédia : le contenu vidéo, audio et les images auxquels on doit fournir des textes équivalents pertinents afin qu'ils soient exploitables par les technologies d'assistance et compris par leurs utilisateurs. Cet article explique comment faire.
Étant donné que l'accès au Web sur les appareils mobiles est très populaire, et que les plates‑formes populaires telles que iOS et Android disposent d'outils d'accessibilité à part entière, il est important de considérer l'accessibilité de votre contenu Web sur ces plates‑formes. Cet article examine les considérations d'accessibilité spécifiques aux mobiles.
+
Étant donné que l'accès au Web sur les appareils mobiles est très populaire, et que les plates‑formes populaires telles que iOS et Android disposent d'outils d'accessibilité à part entière, il est important de considérer l'accessibilité de votre contenu Web sur ces plates‑formes. Cet article examine les considérations d'accessibilité spécifiques aux mobiles.
Le problème : les pages DHTML actuelles ne sont pas accessibles au clavier
+
Le problème : les pages DHTML actuelles ne sont pas accessibles au clavier
Un nombre croissant d'applications Web utilise JavaScript pour imiter des contrôles (
widgets
) applicatifs comme des menus, des vues arborescentes, des champs de texte enrichis et des panneaux à onglets. Les développeurs Web innovent constamment et les applications futures contiendront des éléments complexes et interactifs comme des feuilles de calcul, des calendriers, des graphes organisationnels et plus encore. Jusqu'à présent, les développeurs désirant rendre leurs contrôles basés sur des <div> et autres <span> stylés ne disposaient pas des techniques nécessaires. Pourtant, l'accessibilité au clavier fait partie des nécessités dont tout développeur Web devrait tenir compte.
Prenons un exemple concret : la plupart des menus DHTML ne se comportent pas comme des menus normaux en ce qui concerne l'accès au clavier. Même s'il y a moyen d'accéder au menu avec le clavier, une erreur courante est de placer chaque élément du menu dans l'ordre de tabulation (souvent réalisé implicitement en faisant de chaque choix du menu un élément <a>). En réalité, le comportement correct d'un menu est que le menu entier doit figurer une seule fois dans l'ordre de tabulation, et les flèches doivent être utilisées pour se déplacer de choix en choix au sein du menu. Ceci vaut également pour les autres contrôles de « navigation groupée » comme les vues arborescentes, tableaux et panneaux à onglets.
Il est à présent possible pour les auteurs HTML de faire les choses correctement. La manière de rendre ces contrôles compatibles avec les technologies d'assistance est détaillée dans : ARIA : Applications riches Internet accessibles.
-
La solution : modifier le comportement standard de tabindex
-
Firefox 1.5 suit l'exemple de Microsoft Internet Explorer en étendant l'attribut tabindex pour permettre à n'importe quel élément d'obtenir ou non le focus. En suivant le système d'IE pour tabindex, il devient possible de permettre aux contrôles DHTML, déjà accessibles au clavier dans IE, de l'être également dans Firefox 1.5. Les règles doivent subir quelques petites entorses afin de permettre aux auteurs de rendre leurs contrôles personnalisés accessibles.
+
La solution : modifier le comportement standard de tabindex
+
Firefox 1.5 suit l'exemple de Microsoft Internet Explorer en étendant l'attribut tabindex pour permettre à n'importe quel élément d'obtenir ou non le focus. En suivant le système d'IE pour tabindex, il devient possible de permettre aux contrôles DHTML, déjà accessibles au clavier dans IE, de l'être également dans Firefox 1.5. Les règles doivent subir quelques petites entorses afin de permettre aux auteurs de rendre leurs contrôles personnalisés accessibles.
Le tableau qui suit décrit le nouveau comportement de tabindex :
Pour rendre un contrôle simple navigable avec tabulation, la solution est d'utiliser tabindex="0" sur l'élément <div>> ou <span> le représentant. Vous pouvez consulter un exemple d'une case à cocher basée sur un <span> accessible au clavier tant dans Firefox 1.5 que dans IE (bien que la règle :before pour l'image de la case à cocher ne fonctionne pas dans IE).
-
Pour les contrôles de groupe (comme les menus, les panneaux à onglets, grilles ou vues arborescentes) l'élément parent doit avoir tabindex="0", et chaque choix descendant (onglet/cellule/ligne) doit avoir tabindex="-1". Un évènement keydown surveillant les flèches directionnelles peut ensuite utiliser element.focus() pour donner le focus au contrôle descendant approprié et lui donner un style lui donnant un aspect particulier montrant qu'il a le focus. Vous pouvez consulter un exemple d'une vue arborescente DHTML accessible au clavier et aux lecteurs d'écran dans Firefox (
+
Utilisation du nouveau système
+
Pour rendre un contrôle simple navigable avec tabulation, la solution est d'utiliser tabindex="0" sur l'élément <div>> ou <span> le représentant. Vous pouvez consulter un exemple d'une case à cocher basée sur un <span> accessible au clavier tant dans Firefox 1.5 que dans IE (bien que la règle :before pour l'image de la case à cocher ne fonctionne pas dans IE).
+
Pour les contrôles de groupe (comme les menus, les panneaux à onglets, grilles ou vues arborescentes) l'élément parent doit avoir tabindex="0", et chaque choix descendant (onglet/cellule/ligne) doit avoir tabindex="-1". Un évènement keydown surveillant les flèches directionnelles peut ensuite utiliser element.focus() pour donner le focus au contrôle descendant approprié et lui donner un style lui donnant un aspect particulier montrant qu'il a le focus. Vous pouvez consulter un exemple d'une vue arborescente DHTML accessible au clavier et aux lecteurs d'écran dans Firefox (
nightlies
). Le travail pour le faire fonctionner dans IE est encore en cours.
N'oubliez pas que ceci ne fait pas encore partie d'un standard W3C ou autre organisme officiel. Pour l'instant, il est nécessaire de faire quelques entorses aux règles afin d'obtenir une pleine accessibilité au clavier.
-
Astuces d'écriture
-
Utilisation d'onfocus pour suivre le focus
+
Astuces d'écriture
+
Utilisation d'onfocus pour suivre le focus
Les attributs de gestion d'évènements onfocus et onblur peuvent à présent être utilisés sur tous les éléments. Il n'y a pas d'interface DOM standard pour obtenir l'élément ayant actuellement le focus dans le document, par conséquent il est nécessaire d'utiliser une variable JavaScript pour le suivre.
Ne supposez pas que tous les changements de focus viendront des évènements clavier ou souris, car les technologies d'assistance, comme les lecteurs d'écran, peuvent donner le focus à n'importe quel élément pouvant en disposer et cela doit être traité élégamment par le contrôle JavaScript.
-
Changement dynamique de la possibilité d'obtenir le focus à l'aide de la propriété tabIndex
+
Changement dynamique de la possibilité d'obtenir le focus à l'aide de la propriété tabIndex
Ceci peut être utile à réaliser si un contrôle personnalisé devient actif ou inactif. Les contrôles inactifs ne doivent pas être dans l'ordre de tabulation. Cependant, il est typiquement possible de les atteindre avec les flèches s'ils font partie d'un contrôle de navigation groupé.
-
Utilisation de setTimeout avec element.focus() pour donner le focus
+
Utilisation de setTimeout avec element.focus() pour donner le focus
N'utilisez pas createEvent(), initEvent() et dispatchEvent() pour donner le focus à un élément, parce que les évènements DOM focus sont seulement considérés comme informels — générés par le système après que quelque chose ait reçu le focus, mais pas réellement pour donner le focus. Le retardateur est nécessaire, tant dans IE que dans Firefox 1.5, pour empêcher les scripts de faire des choses étranges et inattendues si l'utilisateur clique sur des boutons ou d'autres contrôles. Concrètement, le code pour donner le focus à un élément ressemblera à quelque chose comme ceci :
setTimeout("gFocusItem.focus();",0); // gFocusItem doit être une variable globale
-
Ne pas utiliser :focus ou des sélecteurs d'attribut pour styler le focus
+
Ne pas utiliser :focus ou des sélecteurs d'attribut pour styler le focus
Il ne sera pas possible d'utiliser :focus ou des sélecteurs d'attribut pour styler l'élément ayant le focus, si vous voulez que cela apparaisse également dans IE. Changez plutôt le style dans un gestionnaire d'évènement onfocus. Par exemple, pour le traitement du focus d'un élément de menu, ajoutez this.style.backgroundColor = "gray";.
-
Toujours dessiner le focus pour les éléments avec tabindex="-1" et qui reçoivent le focus par programmation
+
Toujours dessiner le focus pour les éléments avec tabindex="-1" et qui reçoivent le focus par programmation
IE ne dessinera pas automatiquement l'encadrement du focus pour les éléments qui reçoivent le focus de manière programmée. Choisissez entre changer la couleur de fond via quelque chose comme this.style.backgroundColor = "gray"; ou ajoutez une bordure pointillée via this.style.border = "1px dotted invert". Dans le cas d'une bordure pointillée, il sera nécessaire de s'assurer que ces éléments aient une bordure invisible de <tt>1px</tt> au départ, afin que l'élément ne change pas de taille lorsque le style de bordure est appliqué (les bordures prennent de la place et IE n'implémente pas les encadrements CSS).
-
Utilisation de onkeydown pour les évènements clavier, plutôt que onkeypress
+
Utilisation de onkeydown pour les évènements clavier, plutôt que onkeypress
IE ne déclenchera pas les évènements keypress pour les touches non alphanumériques.
-
Empêcher les évènements clavier d'effectuer des fonctions du navigateur
+
Empêcher les évènements clavier d'effectuer des fonctions du navigateur
Si une touche comme une flèche directionnelle est utilisée, empêchez le navigateur d'utiliser cette touche pour faire quelque chose d'autre (comme faire défiler la page) en utilisant un code similaire à ce qui suit :
Si handleKeyDown() renvoie false, l'évènement sera consommé, empêchant le navigateur d'effectuer quelque action que ce soit, basée sur la touche pressée.
-
Utilisation d'évènements clavier pour permettre l'activation de l'élément
+
Utilisation d'évènements clavier pour permettre l'activation de l'élément
Pour chaque gestionnaire d'évènement lié à la souris, un évènement clavier correspondant est nécessaire. Par exemple, si vous avez onclick="faireQuelqueChose()" vous aurez aussi besoin de onkeydown="return event.keyCode != 13 || faireQuelqueChose();" afin de permettre à la touche Entrée d'activer cet élément.
-
Utilisation de try/catch pour éviter les erreurs JavaScript
-
Ce système n'est actuellement pas supporté par Opera, Safari et les versions anciennes de Mozilla (1.7 et précédentes). Comme certains navigateurs ne supportent pas les nouvelles possibilités comme la propriété tabIndex sur tous les éléments, utilisez try/catch aux endroits appropriés. Les contrôles doivent rester utilisables avec la souris sur les navigateurs ne supportant pas le système DHTML de navigation au clavier. Son support est déjà planifié pour Opera et Safari (via les spécifications du WHATWG).
-
Ne pas se baser sur un comportement cohérent de la répétition d'une touche, pour l'instant
+
Utilisation de try/catch pour éviter les erreurs JavaScript
+
Ce système n'est actuellement pas supporté par Opera, Safari et les versions anciennes de Mozilla (1.7 et précédentes). Comme certains navigateurs ne supportent pas les nouvelles possibilités comme la propriété tabIndex sur tous les éléments, utilisez try/catch aux endroits appropriés. Les contrôles doivent rester utilisables avec la souris sur les navigateurs ne supportant pas le système DHTML de navigation au clavier. Son support est déjà planifié pour Opera et Safari (via les spécifications du WHATWG).
+
Ne pas se baser sur un comportement cohérent de la répétition d'une touche, pour l'instant
Malheureusement, onkeydown peut ou non être répété suivant le système d'exploitation utilisé. Consultez le {{ Bug(91592) }} dans la base de données Bugzilla.
Cet ensemble d'articles fournit des explications rapides pour vous aider à comprendre les étapes à suivre pour vous conformer aux recommandations décrites dans les Directives d'accessibilité du contenu Web 2.0 ou 2.1 du W3C (ou simplement WCAG, aux fins de cet article).
+
Cet ensemble d'articles fournit des explications rapides pour vous aider à comprendre les étapes à suivre pour vous conformer aux recommandations décrites dans les Directives d'accessibilité du contenu Web 2.0 ou 2.1 du W3C (ou simplement WCAG, aux fins de cet article).
Les WCAG 2.0 et 2.1 fournissent un ensemble détaillé de lignes directrices pour rendre le contenu Web plus accessible aux personnes ayant une grande variété de handicaps. Il est complet mais incroyablement détaillé et assez difficile à comprendre rapidement. Pour cette raison, nous avons résumé les étapes pratiques que vous devez suivre pour satisfaire les différentes recommandations, avec d'autres liens vers plus de détails si nécessaire.
Chacun des liens ci-dessous vous mènera à des pages qui développent davantage ces domaines, vous donnant des conseils pratiques sur la façon de rédiger votre contenu Web afin qu'il soit conforme aux critères de succès décrits dans chacune des directives WCAG 2.0 et 2.1 qui se subdivisent davantage en chaque principe.
-
Perceptile: Les utilisateurs doivent pouvoir le percevoir d'une manière ou d'une autre, en utilisant un ou plusieurs de leurs sens.
-
Opérable: Les utilisateurs doivent pouvoir contrôler les éléments de l'interface utilisateur (par exemple, les boutons doivent être cliquables d'une manière ou d'une autre - souris, clavier, commande vocale, etc.).
-
Compréhensible: Le contenu doit être compréhensible pour ses utilisateurs.
-
Robuste: Le contenu doit être développé à l'aide de normes Web bien adoptées qui fonctionneront sur différents navigateurs, maintenant et à l'avenir.
+
Perceptile: Les utilisateurs doivent pouvoir le percevoir d'une manière ou d'une autre, en utilisant un ou plusieurs de leurs sens.
+
Opérable: Les utilisateurs doivent pouvoir contrôler les éléments de l'interface utilisateur (par exemple, les boutons doivent être cliquables d'une manière ou d'une autre - souris, clavier, commande vocale, etc.).
+
Compréhensible: Le contenu doit être compréhensible pour ses utilisateurs.
+
Robuste: Le contenu doit être développé à l'aide de normes Web bien adoptées qui fonctionneront sur différents navigateurs, maintenant et à l'avenir.
Ce guide est destiné à fournir des informations pratiques pour vous aider à créer de meilleurs sites Web plus accessibles. Cependant, nous ne sommes pas des avocats et rien de tout cela ne constitue un avis juridique. Si vous êtes préoccupé par les implications juridiques de l'accessibilité du Web, nous vous recommandons de vérifier la législation spécifique régissant l'accessibilité du Web / des ressources publiques dans votre pays ou région, et de demander l'avis d'un avocat qualifié.
This article provides practical advice on how to write your web content so that it conforms to the success criteria outlined in the Perceivable principle of the Web Content Accessibility Guidelines (WCAG) 2.0 and 2.1. Perceivable states that users must be able to perceive it in some way, using one or more of their senses.
+
This article provides practical advice on how to write your web content so that it conforms to the success criteria outlined in the Perceivable principle of the Web Content Accessibility Guidelines (WCAG) 2.0 and 2.1. Perceivable states that users must be able to perceive it in some way, using one or more of their senses.
Complex images or charts should have an accessible alternative provided, either on the same page or linked to. Use a regular link rather than the longdesc attribute.
UI Controls such as form elements and buttons should have text labels that describe their purpose.
-
Buttons are simple — you should make sure the button text describes the function of the button (e.g. <button>Upload image</button>). For further information on other UI controls, see UI controls.
+
Buttons are simple — you should make sure the button text describes the function of the button (e.g. <button>Upload image</button>). For further information on other UI controls, see UI controls.
Implement decorative (non-content) images, video, etc., in a way that is invisible to assistive technology, so it doesn't confuse users.
-
Decorative images should be implemented using CSS background images (see Backgrounds). If you have to include an image via an {{htmlelement("img")}} element, give it a blank alt (alt=""), otherwise screenreaders may try to read out the filepath, etc.
+
Decorative images should be implemented using CSS background images (see Backgrounds). If you have to include an image via an {{htmlelement("img")}} element, give it a blank alt (alt=""), otherwise screenreaders may try to read out the filepath, etc.
If you are including background video or audio that autoplays, make it as unobtrusive as possible. Don't make it look/sound like content, and provide a control to turn it off. Ideally, don't include it at all.
1.2.1 Provide alternatives for pre-recorded audio-only and video-only content (A)
A transcript should be provided for prerecorded audio-only media, and a transcript or audio description should be provided for prerecorded video-only media (i.e. silent video).
-
See Audio transcripts for transcript information. No audio description tutorial available as yet.
+
See Audio transcripts for transcript information. No audio description tutorial available as yet.
1.2.2 Provide captions for web-based video (A)
You should provide captions for video presented on the web, e.g. HTML5 video. This is for the benefit of people who can't hear the audio part of the video.
1.2.3 Provide text transcript or audio description for web-based video (A)
You should provide text transcripts or audio descriptions for video presented on the web, e.g. HTML5 video. This is for the benefit of people who can't see the visual part of the video, and don't get the full content from the audio alone.
-
See Audio transcripts for transcript information. No audio description tutorial available as yet.
+
See Audio transcripts for transcript information. No audio description tutorial available as yet.
1.2.8 Provide an alternative for prerecorded media (AAA)
For all content that features video, a descriptive text transcript should be provided, for example a script of the movie you are watching. This is for the benefit of hearing impaired viewers who cannot hear the content.
For any live audio content being broadcast, a descriptive text should be provided, for example a script of the play or musical you are listening to. This is for the benefit of hearing impaired viewers who cannot hear the content.
A sensible, logical reading order should be easy to determine for any content, even if it is visually presented in an unusual way. The order should be made obvious by use of correct semantic elements (e.g. headings, paragraphs), with CSS being used to create any unusual layout styles, irrespective of the markup.
Color should not be solely relied upon to convey information — for example, in forms you should never mark required fields purely with a color (like red). Instead (or as well as), something like an asterisk with a label of "required" would be more appropriate.
For any audio that plays for longer than three seconds, accessible controls should be provided to play and pause the audio/video, and mute/adjust volume.