From bc7e79341ee10fcf8d48b1789f9382fddb0bcf73 Mon Sep 17 00:00:00 2001 From: julieng Date: Thu, 11 Nov 2021 07:55:03 +0100 Subject: convert content to md --- .../index.md | 253 ++--- .../fr/web/accessibility/aria/aria_guides/index.md | 34 +- .../accessibility/aria/aria_live_regions/index.md | 192 ++-- .../accessibility/aria/aria_techniques/index.md | 218 ++--- .../aria_techniques/using_the_alert_role/index.md | 132 ++- .../using_the_alertdialog_role/index.md | 86 +- .../using_the_aria-describedby_attribute/index.md | 82 +- .../using_the_aria-invalid_attribute/index.md | 107 +- .../using_the_aria-label_attribute/index.md | 63 +- .../using_the_aria-labelledby_attribute/index.md | 177 ++-- .../using_the_aria-orientation_attribute/index.md | 59 +- .../using_the_aria-relevant_attribute/index.md | 26 +- .../using_the_aria-required_attribute/index.md | 83 +- .../using_the_aria-valuemax_attribute/index.md | 59 +- .../using_the_aria-valuemin_attribute/index.md | 57 +- .../using_the_aria-valuenow_attribute/index.md | 101 +- .../using_the_aria-valuetext_attribute/index.md | 59 +- .../using_the_article_role/index.md | 55 +- .../aria_techniques/using_the_group_role/index.md | 152 ++- .../aria_techniques/using_the_link_role/index.md | 116 ++- .../aria_techniques/using_the_log_role/index.md | 97 +- .../using_the_presentation_role/index.md | 50 +- .../using_the_progressbar_role/index.md | 62 +- .../aria_techniques/using_the_slider_role/index.md | 110 +-- .../aria_techniques/using_the_status_role/index.md | 89 +- .../web/accessibility/aria/forms/alerts/index.md | 155 ++- .../aria/forms/basic_form_hints/index.md | 182 ++-- files/fr/web/accessibility/aria/forms/index.md | 12 +- .../aria/forms/multipart_labels/index.md | 33 +- .../aria/how_to_file_aria-related_bugs/index.md | 224 +++-- files/fr/web/accessibility/aria/index.md | 126 ++- .../accessibility/aria/roles/banner_role/index.md | 36 +- .../accessibility/aria/roles/button_role/index.md | 282 +++--- .../aria/roles/checkbox_role/index.md | 92 +- .../accessibility/aria/roles/dialog_role/index.md | 177 ++-- .../accessibility/aria/roles/listbox_role/index.md | 99 +- .../accessibility/aria/roles/switch_role/index.md | 4 +- .../accessibility/aria/roles/textbox_role/index.md | 73 +- .../aria/web_applications_and_aria_faq/index.md | 351 +++---- files/fr/web/accessibility/aria/widgets/index.md | 2 +- files/fr/web/accessibility/community/index.md | 14 +- files/fr/web/accessibility/index.md | 78 +- .../keyboard-navigable_javascript_widgets/index.md | 165 ++-- .../mobile_accessibility_checklist/index.md | 159 ++- .../web/accessibility/understanding_wcag/index.md | 63 +- .../perceivable/color_contrast/index.md | 171 ++-- .../understanding_wcag/perceivable/index.md | 1023 ++++++++++++++------ 47 files changed, 3107 insertions(+), 2933 deletions(-) diff --git a/files/fr/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.md b/files/fr/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.md index 5c3e8b8a90..3789895ae7 100644 --- a/files/fr/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.md +++ b/files/fr/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.md @@ -10,160 +10,191 @@ translation_of: Web/Accessibility/An_overview_of_accessible_web_applications_and original_slug: >- Accessibilité/Aperçu_d_applications_Web_et_de_composants_dynamiques_accessibles --- -

Le Web est en perpétuelle évolution. En effet, les sites à contenu statique sont de plus en plus remplacés par des sites dynamiques à l’utilisation assez proche des applications de bureaux. Les sites Web dynamiques utilisent abondamment JavaScript et AJAX. Les designers créent des widgets et des éléments d'interface grâce aux langages du Web notamment HTML, CSS et Javascript. Ce tournant dans l’histoire du Web permet d'améliorer grandement l'expérience utilisateur et l'utilisation sur mobile (responsive). Mais certains utilisateurs peuvent être exclus par manque d'accessibilité. En effet, JavaScript avait la réputation d'être inaccessible aux technologies d'assistance tel que les interpréteurs d’écran. Or, il existe maintenant des techniques pour rendre le Web accessible à une large palette d’utilisateurs.

+Le Web est en perpétuelle évolution. En effet, les sites à contenu statique sont de plus en plus remplacés par des sites dynamiques à l’utilisation assez proche des applications de bureaux. Les sites Web dynamiques utilisent abondamment JavaScript et AJAX. Les designers créent des widgets et des éléments d'interface grâce aux langages du Web notamment HTML, CSS et Javascript. Ce tournant dans l’histoire du Web permet d'améliorer grandement l'expérience utilisateur et l'utilisation sur mobile (responsive). Mais certains utilisateurs peuvent être exclus par manque d'accessibilité. En effet, JavaScript avait la réputation d'être inaccessible aux technologies d'assistance tel que les interpréteurs d’écran. Or, il existe maintenant des techniques pour rendre le Web accessible à une large palette d’utilisateurs. + +## Problématique + +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 `
` ou le tag ``. 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](/fr/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._ + +```html + +
    +
  1. + Chapitre 1 +
  2. +
  3. + Chapitre 2 +
  4. +
  5. + Quiz +
  6. +
+ +
+
Le contenu du chapitre 1 va ici
+
Le contenu du chapitre 2 va ici
+
Le contenu du Quiz va ici
+
+``` -

Problématique

+_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._ +![Screenshot of the tabs widget](tabs_widget.png) -

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.

+## ARIA -

Exemple 1: Code dune tabulation sans informations ARIA. Il n'y a aucune information permettant de décrire la forme du widget et ses fonctions.

+[WAI-ARIAI](https://www.w3.org/WAI/standards-guidelines/aria/), les spécifications concernant les applications **internet "riches" et accessibles** sont publiées par l’iniative du [W3C sur l’accessibilité](https://www.w3.org/WAI/), 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. -
<!-- This is a tabs widget. How would you know, looking only at the markup? -->
-<ol>
-  <li id="ch1Tab">
-    <a href="#ch1Panel">Chapitre 1</a>
-  </li>
-  <li id="ch2Tab">
-    <a href="#ch2Panel">Chapitre 2</a>
-  </li>
-  <li id="quizTab">
-    <a href="#quizPanel">Quiz</a>
-  </li>
-</ol>
+> **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**.
 
-<div>
-  <div id="ch1Panel">Le contenu du chapitre 1 va ici</div>
-  <div id="ch2Panel">Le contenu du chapitre 2 va ici</div>
-  <div id="quizPanel">Le contenu du Quiz va ici</div>
-</div>
+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é. -

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 dassistance nest présente.
- Screenshot of the tabs widget

+Les attributs ARIA ont été conçus de façon à être interprétés directement par les navigateurs Web et interagir directement avec les APIs d'accessibilité natives des systèmes d'exploitation. Quand les spécifications ARIA sont implementées, les technologies d'assistance peuvent interagir avec les widgets JavaScript personnalisés de la même façon qu'ils interagissent avec leurs équivalents de bureau. Les technologies d'assistance peuvent ainsi fournir une expérience utilisateur homogène. -

ARIA

+_Example 3 : L'exemple ci-dessous ajoute des attributs ARIA aux balises déjà présentes._ -

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.

+```html + + +
    + + + +
-
-

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.

+
+ +
Chapter 1 content goes here
+
Chapter 2 content goes here
+
Contenu du Quiz;/div>
+``` -

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é.

- -

Les attributs ARIA ont été conçus de façon à être interprétés directement par les navigateurs Web et interagir directement avec les APIs d'accessibilité natives des systèmes d'exploitation. Quand les spécifications ARIA sont implementées, les technologies d'assistance peuvent interagir avec les widgets JavaScript personnalisés de la même façon qu'ils interagissent avec leurs équivalents de bureau. Les technologies d'assistance peuvent ainsi fournir une expérience utilisateur homogène.

- -

Example 3 : L'exemple ci-dessous ajoute des attributs ARIA aux balises déjà présentes.

- -
<!-- Les tabulations sont bien définies  -->
-<!-- Des attributs ARIA ont été ajoutés pour lister les différentes tabulations. -->
-<ol role="tablist">
-  <li id="ch1Tab" role="tab">
-    <a href="#ch1Panel">Chapter 1</a>
-  </li>
-  <li id="ch2Tab" role="tab">
-    <a href="#ch2Panel">Chapter 2</a>
-  </li>
-  <li id="quizTab" role="tab">
-    <a href="#quizPanel">Quiz</a>
-  </li>
-</ol>
+Les versions récentes des navigateurs majeurs du marché fournissent un support ARIA Firefox, Chrome, Safari, Internet Explorer... De nombreuses technologies d'assistance libres d’accès tel que NVDA et Orca fournissent aussi un support ARIA. Le support de ces spécifications est aussi de plus en plus présent dans les balises des librairies JavaScript : JQuery UI, YUI, Google Closure et Dojo Dijit.
 
-<div>
-  <!-- Remarquez les attributs role and aria-labelledby servant à décrire les tabulations. -->
-  <div id="ch1Panel" role="tabpanel" aria-labelledby="ch1Tab">Chapter 1 content goes here</div>
-  <div id="ch2Panel" role="tabpanel" aria-labelledby="ch2Tab">Chapter 2 content goes here</div>
-  <div id="quizPanel" role="tabpanel" aria-labelledby="quizTab">Contenu du Quiz;/div>
-</div>
-
+### Les changement représentationnels -

Les versions récentes des navigateurs majeurs du marché fournissent un support ARIA Firefox, Chrome, Safari, Internet Explorer... De nombreuses technologies d'assistance libres d’accès tel que NVDA et Orca fournissent aussi un support ARIA. Le support de ces spécifications est aussi de plus en plus présent dans les balises des librairies JavaScript : JQuery UI, YUI, Google Closure et Dojo Dijit.

+Les changements représentationnels incluent l'utilisation du CSS pour changer l'apparence du contenu (mettre une bordure rouge autour de données invalides, changer la couleur de fond d’une case à cocher), le faire apparaitre ou disparaitre. -

Les changement représentationnels

+#### Les Changements d'états -

Les changements représentationnels incluent l'utilisation du CSS pour changer l'apparence du contenu (mettre une bordure rouge autour de données invalides, changer la couleur de fond d’une case à cocher), le faire apparaitre ou disparaitre. 

+Les attributs pour décrire l’état actuel d'un widget sont fournis, par exemple : -

Les Changements d'états

+- **`aria-checked`** indique l’état d'une case à cocher ou d'un bouton radio, +- **`aria-disabled`** indique qu’un élément est visible, mais désactivé, +- **`aria-expanded`** indique qu’un élément est déroulé. -

Les attributs pour décrire l’état actuel d'un widget sont fournis, par exemple :

+La liste n’est pas exhaustive. Pour voir la liste complète, consulter [les spécifications des états et propriétés ARIA)](https://www.w3.org/TR/wai-aria-1.1/#introstates). -
    -
  • aria-checked indique l’état d'une case à cocher ou d'un bouton radio,
  • -
  • aria-disabled indique qu’un élément est visible, mais désactivé,
  • -
  • aria-expanded indique qu’un élément est déroulé.
  • -
+Les développeurs devraient se servir des états ARIA pour indiquer l'état des widgets et utiliser les sélecteurs d'attributs CSS pour en modifier l'apparence en fonction des changements d'états plutôt qu'au moyen d'un script qui modifierait des classes sur le widget. -

La liste n’est pas exhaustive. Pour voir la liste complète, consulter les spécifications des états et propriétés ARIA).

+#### Les changements de visibilité -

Les développeurs devraient se servir des états ARIA pour indiquer l'état des widgets et utiliser les sélecteurs d'attributs CSS pour en modifier l'apparence en fonction des changements d'états plutôt qu'au moyen d'un script qui modifierait des classes sur le widget.

+Lorsque la visibilité du contenu est modifiée (c'est-à-dire qu'un élément est masqué ou affiché), les développeurs doivent modifier la valeur de la propriété **`aria-hidden`**. Les techniques décrites ci-dessus doivent être utilisées pour déclarer du CSS permettant de cacher visuellement un élément en utilisant `display:none`. -

Les changements de visibilité

+Les parties pertinentes de l'exemple sont expliquées ci-dessous.Dans cet exemple, le code HTML de l’info-bulle a le format indiqué dans l'exemple 2a. La ligne 9 définit l’état **`aria-hidden`** à `true`. -

Lorsque la visibilité du contenu est modifiée (c'est-à-dire qu'un élément est masqué ou affiché), les développeurs doivent modifier la valeur de la propriété aria-hidden. Les techniques décrites ci-dessus doivent être utilisées pour déclarer du CSS permettant de cacher visuellement un élément en utilisant display:none.

- -

Les parties pertinentes de l'exemple sont expliquées ci-dessous.Dans cet exemple, le code HTML de l’info-bulle a le format indiqué dans l'exemple 2a. La ligne 9 définit l’état aria-hidden à true.

- -
<div class="text">
-    <label id="tp1-label" for="first">First Name:</label>
-    <input type="text" id="first" name="first" size="20"
+```html
+
+ + + +
+``` -

Le CSS pour ce balisage est montré dans l'exemple 2b. Notez qu’il n’y a pas de nom de classe personnalisé utilisé, seul le statut de l'attribut aria-hidden à la ligne 1.
- Exemple 2b. Un attribut basé sur le sélecteur indiquant l'état.

+Le CSS pour ce balisage est montré dans l'exemple 2b. Notez qu’il n’y a pas de nom de classe personnalisé utilisé, seul le statut de l'attribut **`aria-hidden`** à la ligne 1*. +Exemple 2b. Un attribut basé sur le sélecteur indiquant l'état.* -
div.tooltip[aria-hidden="true"] {
+```css
+div.tooltip[aria-hidden="true"] {
   display: none;
   }
-
+``` -

Le JavaScript à mettre à jour est la propriété aria-hidden du formulaire montré dans l'exemple 2c. Notez que le script met à jour seulement l'attribut aria-hidden à la (ligne 2) ; il n'y a pas besoin d'ajouter ou de supprimer un nom de classe personnalisé.

+Le JavaScript à mettre à jour est la propriété **`aria-hidden`** du formulaire montré dans l'exemple 2c. Notez que le script met à jour seulement l'attribut **`aria-hidden`** à la (ligne 2) ; il n'y a pas besoin d'ajouter ou de supprimer un nom de classe personnalisé. -

Exemple 2c. JavaScript pour mettre à jour l'attribut aria-checked.

+_Exemple 2c. JavaScript pour mettre à jour l'attribut aria-checked._ -
var showTip = function(el) {
+```js
+var showTip = function(el) {
   el.setAttribute('aria-hidden', 'false');
-}
+} +``` + +### Les changements de rôles + +ARIA permet aux développeurs de déclarer un rôle sémantique pour un élément qui produirait des sémantiques fausses. Par exemple, quand une liste non ordonnée est utilisée pour créer un menu, {{ HTMLElement("ul") }} devrait avoir un **`role`** de `menubar` et chaque {{ HTMLElement("li") }} devrait avoir un **`role`** de `menuitem`. Le **`role`** d'un élément ne doit pas changer. À la place, il faut supprimer l'élément original et le remplacer par un nouveau **`role`**. + +Considérons une zone d’écriture, soit une zone qui permet à l’utilisateur d’éditer une partie de son texte, sans changer de contexte. Cette zone a un mode "vue", dans lequel le texte n’est pas éditable, et un mode "édition", dans lequel le texte peut être modifié. Un développeur peut être tenté d’implémenter le mode "vue" avec un texte en lecture seule via l’élément {{ HTMLElement("input") }} et en configurant le  **`role`**  ARIA à  `button`, puis passe au mode "édition" en rendant l’élément écrivable et en supprimant le **`role`** attribué dans le mode "édition" (puisque les éléments de type {{ HTMLElement("input") }} ont leur propre rôle sémantique). + +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") }}. + +## La navigation au clavier + +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. + +Traditionnellement, la navigation au clavier sur le Web était limitée à la touche Tabulation. Un utilisateur appuie sur Tab pour faire la mise au point de chaque lien, bouton ou formulaire sur la page dans un ordre linéaire, en utilisant Maj+Tab pour revenir en arrière. C’est une forme unidimensionnelle de navigation en avant ou en arrière, un élément à la fois. Sur les pages assez denses, un utilisateur clavier doit souvent appuyer plusieurs fois sur la touche Tab avant d’accéder à la section requise. La mise en œuvre de conventions de clavier de type bureautique sur le Web peut considérablement accélérer la navigation pour de nombreux utilisateurs. + +Voici un résumé de la façon dont la navigation au clavier devrait fonctionner dans une application Web compatible ARIA : + +- La touche + + Tab + + devrait fournir le focus au widget dans son ensemble. Par exemple, la tabulation d’une barre de menu devrait mettre l’accent sur le premier élément du menu. + +- Les touches fléchées devraient permettre la sélection ou la navigation dans le widget. Par exemple, en utilisant les touches + + + + et + + + + , vous devez déplacer le focus sur les éléments de menu précédent et suivant. + +- Lorsque le widget n’est pas à l’intérieur d’un formulaire, les touches + + Entrée -

Les changements de rôles

+ et -

ARIA permet aux développeurs de déclarer un rôle sémantique pour un élément qui produirait des sémantiques fausses. Par exemple, quand une liste non ordonnée est utilisée pour créer un menu, {{ HTMLElement("ul") }} devrait avoir un role de menubar et chaque {{ HTMLElement("li") }} devrait avoir un role de menuitem. Le role d'un élément ne doit pas changer. À la place, il faut supprimer l'élément original et le remplacer par un nouveau role.

+ Espace -

Considérons une zone d’écriture, soit une zone qui permet à l’utilisateur d’éditer une partie de son texte, sans changer de contexte. Cette zone a un mode "vue", dans lequel le texte n’est pas éditable, et un mode "édition", dans lequel le texte peut être modifié. Un développeur peut être tenté d’implémenter le mode "vue" avec un texte en lecture seule via l’élément {{ HTMLElement("input") }} et en configurant le  role  ARIA à  button, puis passe au mode "édition" en rendant l’élément écrivable et en supprimant le role attribué dans le mode "édition" (puisque les éléments de type {{ HTMLElement("input") }} ont leur propre rôle sémantique).

+ permettent de sélectionner ou d’activer le contrôle. -

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") }}.

+- Dans un formulaire, la touche -

La navigation au clavier

+ Espace -

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.

+ doit sélectionner ou activer le contrôle, tandis que la touche -

Traditionnellement, la navigation au clavier sur le Web était limitée à la touche Tabulation. Un utilisateur appuie sur Tab pour faire la mise au point de chaque lien, bouton ou formulaire sur la page dans un ordre linéaire, en utilisant Maj+Tab pour revenir en arrière. C’est une forme unidimensionnelle de navigation en avant ou en arrière, un élément à la fois. Sur les pages assez denses, un utilisateur clavier doit souvent appuyer plusieurs fois sur la touche Tab avant d’accéder à la section requise. La mise en œuvre de conventions de clavier de type bureautique sur le Web peut considérablement accélérer la navigation pour de nombreux utilisateurs.

+ Entrée -

Voici un résumé de la façon dont la navigation au clavier devrait fonctionner dans une application Web compatible ARIA :

+ doit soumettre l’action par défaut du formulaire. -
    -
  • La touche Tab devrait fournir le focus au widget dans son ensemble. Par exemple, la tabulation d’une barre de menu devrait mettre l’accent sur le premier élément du menu.
  • -
  • Les touches fléchées devraient permettre la sélection ou la navigation dans le widget. Par exemple, en utilisant les touches et , vous devez déplacer le focus sur les éléments de menu précédent et suivant.
  • -
  • Lorsque le widget n’est pas à l’intérieur d’un formulaire, les touches Entrée et Espace permettent de sélectionner ou d’activer le contrôle.
  • -
  • Dans un formulaire, la touche Espace doit sélectionner ou activer le contrôle, tandis que la touche Entrée doit soumettre l’action par défaut du formulaire.
  • -
  • En cas de doute, imitez le comportement standard du bureau du contrôle que vous créez.
  • -
+- 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 \
    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 \
  1. ). 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 ](/fr/docs/Contr%C3%B4les_DHTML_personnalis%C3%A9s_navigables_au_clavier)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](http://dev.aol.com/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](http://www.w3.org/WAI/PF/aria-practices/Overview.html) qui inclut la navigation au clavier et les raccourcis pour une variété de widgets. -

    Voir aussi

    +## Voir aussi - +- [ARIA](/fr/docs/Accessibilit%C3%A9/ARIA) +- [Des applications WEB et la FAQ ARIA](/fr/docs/Accessibilit%C3%A9/ARIA/FAQ_Applications_Web_et_ARIA) +- [WAI-ARIA Spécification](http://www.w3.org/TR/wai-aria/) +- [WAI-ARIA Best Practices](http://www.w3.org/WAI/PF/aria-practices/Overview.html) +- [DHTML Style Guide](http://dev.aol.com/dhtml_style_guide) diff --git a/files/fr/web/accessibility/aria/aria_guides/index.md b/files/fr/web/accessibility/aria/aria_guides/index.md index 6b5aaeb7d9..cc9585dc68 100644 --- a/files/fr/web/accessibility/aria/aria_guides/index.md +++ b/files/fr/web/accessibility/aria/aria_guides/index.md @@ -7,22 +7,20 @@ tags: translation_of: Web/Accessibility/ARIA/ARIA_Guides original_slug: Accessibilité/ARIA/Guides_ARIA --- -

    ARIA (Accessible Rich Internet Applications ou Applications Internet riches accessibles) défini une manière de rendre le web plus accessible pour les personnes en situation de handicap. Les quelques principes suivant permettent de s'assurer d'une meilleure accessibilité :

    +**ARIA** (Accessible Rich Internet Applications ou Applications Internet riches accessibles) défini une manière de rendre le web plus accessible pour les personnes en situation de handicap. Les quelques principes suivant permettent de s'assurer d'une meilleure accessibilité : -
      -
    • Traiter les erreurs dans les formulaires
    • -
    • Labelliser les composants d’interface
    • -
    • Labelliser les composants composés (Composite Widgets) et des zones (Regions)
    • -
    • Gérer le focus dans les composants composés (aria-activedescendant vs roving tabindex)
    • -
    • Utiliser les rôles de points de repère (Landmark Roles)
    • -
    • Traiter les actualisations dynamiques & des zones « Live »
    • -
    • Mode Virtuel contre mode non virtuel dans les produits de technologies d’assistance
    • -
    • Utiliser le Glisser & déposer
    • -
    • Notifier les utilisateurs sur les lecteurs d’écran non-ARIA
    • -
    • Arranger la structure avec le rôle presentation
    • -
    • Masquer les trames des tableaux
    • -
    • Gérer les dialogues modaux et non modaux
    • -
    • Utiliser ARIA avec HTML5
    • -
    • Comment tester ARIA ?
    • -
    • ARIA sur les périphériques mobiles
    • -
    +- Traiter les erreurs dans les formulaires +- Labelliser les composants d’interface +- Labelliser les composants composés (Composite Widgets) et des zones (Regions) +- Gérer le focus dans les composants composés (`aria-activedescendant` vs roving tabindex) +- Utiliser les rôles de points de repère (Landmark Roles) +- Traiter les actualisations dynamiques & des zones « Live » +- Mode Virtuel contre mode non virtuel dans les produits de technologies d’assistance +- Utiliser le Glisser & déposer +- Notifier les utilisateurs sur les lecteurs d’écran non-ARIA +- Arranger la structure avec le rôle `presentation` +- Masquer les trames des tableaux +- Gérer les dialogues modaux et non modaux +- Utiliser ARIA avec HTML5 +- Comment tester ARIA ? +- ARIA sur les périphériques mobiles diff --git a/files/fr/web/accessibility/aria/aria_live_regions/index.md b/files/fr/web/accessibility/aria/aria_live_regions/index.md index 9c921bac5e..e13259bdd1 100644 --- a/files/fr/web/accessibility/aria/aria_live_regions/index.md +++ b/files/fr/web/accessibility/aria/aria_live_regions/index.md @@ -8,120 +8,82 @@ tags: translation_of: Web/Accessibility/ARIA/ARIA_Live_Regions original_slug: Accessibilité/ARIA/Zones_live_ARIA --- -

    Introduction

    - -

    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

    - -

    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.

    - -
    -
    aria-live :
    -
    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".

    -
    -

    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é.

    - -

    Pour les zones de moindre importance, ou qui seraient perturbantes à cause d’actualisations répétées et rapprochées ou toute autre raison, il est possible de les rendre silencieux avec aria-live="off".

    - -

    Cas d’étude simple : une ''combobox'' actualise des informations utiles à l’écran

    - -

    Un site web spécialisé dans l’ornithologie fournit une liste déroulante avec des noms d’oiseaux. Lorsqu’un oiseau est sélectionné dans la liste, une zone de la page web est actualisée avec les détails concernant la famille d’oiseaux choisie.

    - -

    <select size="1" id="bird-selector" aria-controls="bird-info"><option> .... </select>

    - -
    <div role="region" id="bird-info" aria-live="polite">
    - -

    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.

    - -

    Préférences de rôles pour les zones « live » spécialisées

    - -

    Dans les cas prédéfinis répandus ci-dessous, il est préférable d’utiliser un des rôles de zone « live » spécifique fourni :

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    RôleDescriptionCompatibilité
    logChat, erreur, jeux ou autres types de journalisationPour maximiser la compatibilité, ajouter un aria-live="polite" redondant lorsque vous utiliserez ce rôle.
    statusUne barre d’état ou une zone de l’écran qui fournit un état actualisé de quelque chose. Les utilisateurs de lecteur d’écran ont à leur disposition une commande spéciale pour lire l’état courant.Pour maximiser la compatibilité, ajouter un aria-live="polite" redondant lorsque vous utiliserez ce rôle.
    alertMessage d’erreur ou avertissement souligné à l’écran. Les alertes sont particulièrement importantes pour la validation côté client notifiée à l’utilisateur. (TBD: lien vers un tutoriel sur les formulaires ARIA avec des informations plus complètes)Pour maximiser la compatibilité, ajouter un aria-live="assertive" redondant lorsque vous utiliserez ce rôle. Attention, cette redondance occasionne un problème de double restitution orale dans VoiceOver sur iOS.
    progressbarÉlément hybride entre un composant d’interface et une zone « Live ». Utilisez ce rôle avec les attributs aria-valuemin, aria-valuenow et aria-valuemax. (TBD : Ajouter plus d’informations pour cet élément). 
    marqueePour faire défiler un texte, comme pour un téléscripteur ou un afficheur alphanumérique. 
    timerPour tout type de minuterie ou d’horloge, tel qu’un compte-à-rebours ou un chronomètre. 
    - -

    Zones « live » avancées

    - -

    (TBD : Qu'est-ce qui est pris en charge par qui ?)

    - -

    Le support général des zones "Live" a été ajouté à JAWS à partir de la version 10.0. Windows Eyes supporte les zones "Live" depuis la version 8.0 "pour une utilisation en dehors du mode de navigation (Browse Mode) pour Microsoft Internet Explorer et Mozilla Firefox". NVDA a ajouté un support basique pour les zones "Live" pour Mozilla Firefox en 2008 et qui a été amélioré en 2010 et 2014. En 2015 un support basique fut également ajouté à Internet Explorer (MSHTML).

    - -

    The Paciello Group propose des informations sur l'état du support des zones "Live"(2014). Paul Jadam s'est intéressé plus particulièrement au support des attributs aria-atomic and aria-relevant.

    - -
    -
    aria-atomic :
    -
    L’attribut aria-atomic=BOOLÉEN est utilisé pour définir si le lecteur d’écran doit ou non présenter la zone « Live » comme un ensemble, même si une partie seulement de la zone est modifiée – Les valeurs possibles sont false/true. La valeur par défaut est false.
    -
    aria-relevant :
    -
    L’attribut aria-relevant=[LISTE_DES_CHANGEMENTS] est utilisé pour définir quel type de changements est adéquat à une zone « Live » – les valeurs possibles sont additions (addition)/removals (suppression)/text (texte)/all (tous). La valeur par défaut est « additions text. »
    -
    aria-labelledby :
    -
    L’attribut aria-labelledby=[LISTE_ID] est utilisé pour associer un ou des libellés à une zone. Le fonctionnement est similaire à celui d'aria-controls mais les références d'id pointent vers les libellés associés aux blocs identifiés, et les références multiples sont également séparées par un espace.
    -
    aria-describedby :
    -
    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

    - -

    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).

    - -
    <ul id="roster" aria-live="polite" aria-relevant="additions removals">
    -	<!-- utilisez JavaScript ici pour ajouter/supprimer des utilisateurs-->
    -</ul>
    -
    - -

    Détails des propriétés « live » d’ARIA :

    - -
      -
    • L’attribut aria-live="polite" indique au lecteur d’écran qu’il doit attendre que l’utilisateur soit inactif avant de lui présenter une mise à jour. C’est la valeur la plus communément utilisée, car interrompre l’utilisateur avec la valeur assertive briserait son flux de lecture.
    • -
    • L’attribut aria-atomic n’est pas défini (false par défaut), ainsi seuls les utilisateurs ajoutés ou supprimés devraient être lus et non l’intégralité de la liste, à chaque mise à jour.
    • -
    • L’attribut aria-relevant="additions removals" assure à la fois que les utilisateurs ajoutés et supprimés de la liste seront lus.
    • +## Introduction + +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 + +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. + +- aria-live : + - : 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"`. + + > **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é. + +Pour les zones de moindre importance, ou qui seraient perturbantes à cause d’actualisations répétées et rapprochées ou toute autre raison, il est possible de les rendre silencieux avec `aria-live="off"`. + +### Cas d’étude simple : une ''combobox'' actualise des informations utiles à l’écran + +Un site web spécialisé dans l’ornithologie fournit une liste déroulante avec des noms d’oiseaux. Lorsqu’un oiseau est sélectionné dans la liste, une zone de la page web est actualisée avec les détails concernant la famille d’oiseaux choisie. + +`` + +```html +
      +``` + +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. + +## Préférences de rôles pour les zones « live » spécialisées + +Dans les cas prédéfinis répandus ci-dessous, il est préférable d’utiliser un des rôles de zone « live » spécifique fourni : + +| Rôle | Description | Compatibilité | +| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| log | Chat, erreur, jeux ou autres types de journalisation | Pour maximiser la compatibilité, ajouter un `aria-live="polite"` redondant lorsque vous utiliserez ce rôle. | +| status | Une barre d’état ou une zone de l’écran qui fournit un état actualisé de quelque chose. Les utilisateurs de lecteur d’écran ont à leur disposition une commande spéciale pour lire l’état courant. | Pour maximiser la compatibilité, ajouter un `aria-live="polite"` redondant lorsque vous utiliserez ce rôle. | +| alert | Message d’erreur ou avertissement souligné à l’écran. Les alertes sont particulièrement importantes pour la validation côté client notifiée à l’utilisateur. (TBD: lien vers un tutoriel sur les formulaires ARIA avec des informations plus complètes) | Pour maximiser la compatibilité, ajouter un `aria-live="assertive"` redondant lorsque vous utiliserez ce rôle. Attention, cette redondance occasionne un problème de double restitution orale dans VoiceOver sur iOS. | +| progressbar | Élément hybride entre un composant d’interface et une zone « Live ». Utilisez ce rôle avec les attributs `aria-valuemin`, `aria-valuenow` et `aria-valuemax`. (TBD : Ajouter plus d’informations pour cet élément). |   | +| marquee | Pour faire défiler un texte, comme pour un téléscripteur ou un afficheur alphanumérique. |   | +| timer | Pour tout type de minuterie ou d’horloge, tel qu’un compte-à-rebours ou un chronomètre. |   | + +## Zones « live » avancées + +(TBD : Qu'est-ce qui est pris en charge par qui ?) + +Le support général des zones "Live" a été ajouté à JAWS à partir de la version 10.0. Windows Eyes supporte les zones "Live" depuis la version 8.0 "pour une utilisation en dehors du mode de navigation (Browse Mode) pour Microsoft Internet Explorer et Mozilla Firefox". NVDA a ajouté un support basique pour les zones "Live" pour Mozilla Firefox en 2008 et qui a été amélioré en 2010 et 2014. En 2015 un support basique fut également ajouté à Internet Explorer (MSHTML). + +The Paciello Group propose des [informations sur l'état du support des zones "Live"](https://www.paciellogroup.com/blog/2014/03/screen-reader-support-aria-live-regions/)(2014). Paul Jadam s'est intéressé plus particulièrement au [support des attributs aria-atomic and aria-relevant](http://pauljadam.com/demos/aria-atomic-relevant.html). + +- aria-atomic : + - : L’attribut `aria-atomic=BOOLÉEN` est utilisé pour définir si le lecteur d’écran doit ou non présenter la zone « Live » comme un ensemble, même si une partie seulement de la zone est modifiée – Les valeurs possibles sont `false`/`true`. La valeur par défaut est `false`. +- aria-relevant : + - : L’attribut `aria-relevant=[LISTE_DES_CHANGEMENTS]` est utilisé pour définir quel type de changements est adéquat à une zone « Live » – les valeurs possibles sont `additions` (addition)/`removals` (suppression)/`text` (texte)/`all` (tous). La valeur par défaut est « `additions text`. » +- aria-labelledby : + - : L’attribut `aria-labelledby=[LISTE_ID]` est utilisé pour associer un ou des libellés à une zone. Le fonctionnement est similaire à celui d'`aria-controls` mais les références d'id pointent vers les libellés associés aux blocs identifiés, et les références multiples sont également séparées par un espace. +- aria-describedby : + - : 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 + +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). + +```html +
        +
      +``` + +#### Détails des propriétés « live » d’ARIA : + +- L’attribut `aria-live="polite"` indique au lecteur d’écran qu’il doit attendre que l’utilisateur soit inactif avant de lui présenter une mise à jour. C’est la valeur la plus communément utilisée, car interrompre l’utilisateur avec la valeur `assertive` briserait son flux de lecture. +- L’attribut `aria-atomic` n’est pas défini (`false` par défaut), ainsi seuls les utilisateurs ajoutés ou supprimés devraient être lus et non l’intégralité de la liste, à chaque mise à jour. +- L’attribut `aria-relevant="additions removals"` assure à la fois que les utilisateurs ajoutés et supprimés de la liste seront lus. -

      TBD : Cas d’étude(s) réel(s) de l’attribut aria-atomic="true".

      +TBD : Cas d’étude(s) réel(s) de l’attribut aria-atomic="true". diff --git a/files/fr/web/accessibility/aria/aria_techniques/index.md b/files/fr/web/accessibility/aria/aria_techniques/index.md index 58c2d37553..74687a3930 100644 --- a/files/fr/web/accessibility/aria/aria_techniques/index.md +++ b/files/fr/web/accessibility/aria/aria_techniques/index.md @@ -9,111 +9,113 @@ tags: translation_of: Web/Accessibility/ARIA/ARIA_Techniques original_slug: Accessibilité/ARIA/Techniques_ARIA --- -

      Rôles

      -

      Rôles de composant d’interface

      - -

      Rôles composés

      -

      Les techniques ci-dessous décrivent chaque rôle composé ainsi que leurs rôles enfants obligatoires ou facultatifs.

      -
        -
      • Grid (tableau, contenant les rôles row (ligne), gridcell (cellule), rowheader (en-tête de ligne) et columnheader (en-tête de colonne))
      • -
      • Menubar / Menu (contenant les rôles menuitem, menuitemcheckbox et menuitemradio)
      • -
      • Listbox (boîte de liste, contenant le rôle option)
      • -
      • Tablist (boîte à onglets, contenant les rôles tab et tabpanel)
      • -
      • Tree (arbre, contenant les rôles group et treeitem)
      • -
      • Radiogroup (voir le rôle Radio)
      • -
      • Treegrid
      • -
      -

      Rôles de structure de document

      - -

      Rôles de points de repère

      -
        -
      • Application
      • -
      • Banner
      • -
      • Complementary
      • -
      • Contentinfo
      • -
      • Form
      • -
      • Main
      • -
      • Navigation
      • -
      • Search
      • -
      -

      États et propriétés

      -

      Attributs de composants d’interface

      - -

      Attributs de zones « live »

      -
        -
      • aria-live
      • -
      • aria-relevant
      • -
      • aria-atomic
      • -
      • aria-busy
      • -
      -

      Attributs de glisser-déposer

      -
        -
      • aria-dropeffect
      • -
      • aria-dragged
      • -
      -

      Attributs de relation

      - +### Rôles + +#### Rôles de composant d’interface + +- [Alert](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_alert) +- [Alertdialog](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_alertdialog) +- [Button](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_button) +- [Checkbox](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_checkbox) +- [Dialog](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_dialog) +- [Link](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_link) +- [Log](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_log) +- Marquee +- [Progressbar](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_progressbar) +- [Radio](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_radio) +- Scrollbar +- [Slider](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_slider) +- Spinbutton +- [status](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_status) +- [textbox](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_textbox) +- Timer +- Tooltip + +#### Rôles composés + +Les techniques ci-dessous décrivent chaque rôle composé ainsi que leurs rôles enfants obligatoires ou facultatifs. + +- Grid (tableau, contenant les rôles `row` (ligne), `gridcell` (cellule), `rowheader` (en-tête de ligne) et `columnheader` (en-tête de colonne)) +- Menubar / Menu (contenant les rôles `menuitem`, `menuitemcheckbox` et `menuitemradio`) +- [Listbox](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_listbox) (boîte de liste, contenant le rôle `option`) +- Tablist (boîte à onglets, contenant les rôles `tab` et `tabpanel`) +- Tree (arbre, contenant les rôles `group` et `treeitem`) +- [Radiogroup (voir le rôle `Radio`)](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_radio) +- Treegrid + +#### Rôles de structure de document + +- [Article](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_article) +- Definition +- Directory +- Document +- [Group](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_group) +- Heading +- Img +- List, listitem +- Math +- Note +- [Presentation](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_presentation) +- Region +- Separator +- [Toolbar](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_toolbar) + +#### Rôles de points de repère + +- Application +- [Banner](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_banner) +- Complementary +- Contentinfo +- Form +- Main +- Navigation +- Search + +### États et propriétés + +#### Attributs de composants d’interface + +- aria-autocomplete +- aria-checked +- aria-disabled +- aria-expanded +- aria-haspopup +- aria-hidden +- [aria-invalid](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-invalid) +- [aria-label](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-label) +- aria-level +- aria-multiline +- aria-multiselectable +- [aria-orientation](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-orientation) +- aria-pressed +- aria-readonly +- [aria-required](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-required) +- aria-selected +- aria-sort +- [aria-valuemax](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-valuemax) +- [aria-valuemin](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-valuemin) +- [aria-valuenow](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-valuenow) +- [aria-valuetext](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-valuetext) + +#### Attributs de zones « live » + +- aria-live +- aria-relevant +- aria-atomic +- aria-busy + +#### Attributs de glisser-déposer + +- aria-dropeffect +- aria-dragged + +#### Attributs de relation + +- [aria-activedescendant](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-activedescendant) +- aria-controls +- [aria-describedby](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-describedby) +- aria-flowto +- [aria-labelledby](/fr/docs/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-labelledby) +- aria-owns +- aria-posinset +- aria-setsize diff --git a/files/fr/web/accessibility/aria/aria_techniques/using_the_alert_role/index.md b/files/fr/web/accessibility/aria/aria_techniques/using_the_alert_role/index.md index 075b85ac58..f1858e0e89 100644 --- a/files/fr/web/accessibility/aria/aria_techniques/using_the_alert_role/index.md +++ b/files/fr/web/accessibility/aria/aria_techniques/using_the_alert_role/index.md @@ -9,116 +9,110 @@ tags: translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_alert --- -

      Description

      +### Description -

      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)](http://www.w3.org/TR/wai-aria/roles#alert) 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 :

      +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 : -
        -
      • Une valeur non valide a été saisie dans un champ de formulaire ;
      • -
      • La session d’un utilisateur est sur le point d’expirer ;
      • -
      • La connexion au serveur a été interrompue, les modifications locales ne seront pas sauvegardées.
      • -
      +- Une valeur non valide a été saisie dans un champ de formulaire ; +- La session d’un utilisateur est sur le point d’expirer ; +- La connexion au serveur a été interrompue, les modifications locales ne seront pas sauvegardées. -

      De fait de sa nature intrusive, le rôle alert doit être utilisé avec parcimonie et uniquement dans les situations où l’attention de l’utilisateur est immédiatement requise. Les changements dynamiques de moindre urgence devraient utiliser une méthode moins agressive, telle que aria-live="polite" ou autres rôles de zone live.

      +De fait de sa nature intrusive, le rôle `alert` doit être utilisé avec parcimonie et uniquement dans les situations où l’attention de l’utilisateur est immédiatement requise. Les changements dynamiques de moindre urgence devraient utiliser une méthode moins agressive, telle que `aria-live="polite"` ou autres rôles de zone live. -

      Effets possibles sur les agents utilisateurs et les technologies d’assistance

      +### Effets possibles sur les agents utilisateurs et les technologies d’assistance -

      Lorsque le rôle alert est ajouté à un élément, ou qu’un tel élément devient visible, l’agent utilisateur devrait suivre les étapes suivantes :

      +Lorsque le rôle `alert` 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 ayant un rôle d’alerte à l’API d’accessibilité du système d’exploitation ;
      • -
      • Déclencher un événement d'alerte accessible à l’aide l’API d’accessibilité du système d’exploitation si elle le prend en charge.
      • -
      +- Présenter l’élément ayant un rôle d’alerte à l’API d’accessibilité du système d’exploitation ; +- Déclencher un événement d'alerte accessible à l’aide l’API d’accessibilité du système d’exploitation si elle le prend en charge. -

      Les technologies d’assistance devraient être à l’écoute de tels évènements et les notifier à l’utilisateur en conséquence :

      +Les technologies d’assistance devraient être à l’écoute de tels évènements et les notifier à l’utilisateur en conséquence : -
        -
      • Les lecteurs d’écran peuvent interrompre la sortie en cours (qu’elle soit vocale ou en braille) et immédiatement annoncer ou afficher le message d’alerte ;
      • -
      • Les loupes ou agrandisseurs d’écran peuvent indiquer qu’une alerte est survenue et quel en est le texte.
      • -
      +- Les lecteurs d’écran peuvent interrompre la sortie en cours (qu’elle soit vocale ou en braille) et immédiatement annoncer ou afficher le message d’alerte ; +- 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. -

      Exemples

      +### Exemples -

      Exemple 1 : Ajout du rôle dans le code HTML

      +#### Exemple 1 : Ajout du rôle dans le code HTML -

      L’extrait de code ci-dessous montre comment le rôle alert est directement ajouté dans le code source HTML. Au moment où l’élément finit de se charger, le lecteur d’écran doit être notifié de l’alerte. Si l’élément était dans le code source original lorsque la page s’est chargée, le lecteur d’écran annonce immédiatement l’erreur après la lecture du titre de la page.

      +L’extrait de code ci-dessous montre comment le rôle `alert` est directement ajouté dans le code source HTML. Au moment où l’élément finit de se charger, le lecteur d’écran doit être notifié de l’alerte. Si l’élément était dans le code source original lorsque la page s’est chargée, le lecteur d’écran annonce immédiatement l’erreur après la lecture du titre de la page. -
      <h2 role="alert">Votre formulaire ne peut être soumis à cause de 3 erreurs de validation.</h2>
      -
      +```html +

      Votre formulaire ne peut être soumis à cause de 3 erreurs de validation.

      +``` -

      Exemple 2 : Ajout dynamique d'un élément avec le rôle alert

      +#### Exemple 2 : Ajout dynamique d'un élément avec le rôle `alert` -

      Cet extrait de code crée dynamiquement un élément avec un rôle alert et l’ajoute à la structure du document.

      +Cet extrait de code crée dynamiquement un élément avec un rôle `alert` et l’ajoute à la structure du document. -
      var myAlert = document.createElement("p");
      +```js
      +var myAlert = document.createElement("p");
       myAlert.setAttribute("role", "alert");
       
       var myAlertText = document.createTextNode("Vous devez accepter nos conditions d’utilisation pour créer un compte.");
       myAlert.appendChild(myAlertText);
       document.body.appendChild(myAlertText);
      -
      +``` -

      Note : le même résultat peut être obtenu avec moins de code en utilisant une bibliothèque de scripts telle que jQuery :

      +**Note :** le même résultat peut être obtenu avec moins de code en utilisant une bibliothèque de scripts telle que *jQuery* : -
      $("<p role='alert'>Vous devez accepter nos conditions d’utilisation pour créer un compte.</p>").appendTo(document.body);
      -
      +```js +$("

      Vous devez accepter nos conditions d’utilisation pour créer un compte.

      ").appendTo(document.body); +``` -

      Exemple 3 : Ajout d'un rôle alert à un élément existant

      +#### Exemple 3 : Ajout d'un rôle `alert` à un élément existant -

      Parfois, il peut être utile d’ajouter un rôle alert à un élément déjà visible dans la page plutôt que de créer un nouvel élément. Ceci permet au développeur de répéter une information devenue plus pertinente ou urgente pour l’utilisateur. Par exemple, un contrôle de formulaire peut avoir des instructions sur les valeurs attendues. Si une valeur différente est saisie, role="alert" peut être ajouté au texte de l’instruction pour que le lecteur d’écran l’annonce comme une alerte. L'extrait de pseudo-code ci-dessous illustre cette approche :

      +Parfois, il peut être utile d’ajouter un rôle `alert` à un élément déjà visible dans la page plutôt que de créer un nouvel élément. Ceci permet au développeur de répéter une information devenue plus pertinente ou urgente pour l’utilisateur. Par exemple, un contrôle de formulaire peut avoir des instructions sur les valeurs attendues. Si une valeur différente est saisie, `role="alert"` peut être ajouté au texte de l’instruction pour que le lecteur d’écran l’annonce comme une alerte. L'extrait de pseudo-code ci-dessous illustre cette approche : -
      <p id="formInstruction">Vous devez cocher au moins trois options</p>
      -
      +```html +

      Vous devez cocher au moins trois options

      +``` -
      // Lorsque l’utilisateur essaye de soumettre le formulaire avec moins de 3 cases cochées :
      -document.getElementById("formInstruction").setAttribute("role", "alert");
      +```js +// Lorsque l’utilisateur essaye de soumettre le formulaire avec moins de 3 cases cochées : +document.getElementById("formInstruction").setAttribute("role", "alert"); +``` -

      Exemple 4 : Rendre visible un élément avec le rôle alert

      +#### Exemple 4 : Rendre visible un élément avec le rôle `alert` -

      Si un élément possède déjà role="alert" et qu’il est initialement caché par des règles CSS, le rendre visible déclenchera l’alerte comme si elle venait juste d’être ajoutée à la page. Cela signifie qu’une alerte existante peut être « réutilisée » plusieurs fois.

      +Si un élément possède déjà `role="alert"` et qu’il est initialement caché par des règles CSS, le rendre visible déclenchera l’alerte comme si elle venait juste d’être ajoutée à la page. Cela signifie qu’une alerte existante peut être « réutilisée » plusieurs fois. -

      Note : dans la plupart des cas cette approche n’est pas recommandée, parce qu'il n'est pas idéal de masquer une erreur ou un texte d’alerte qui n’est pas applicable à ce moment précis. Les utilisateurs de technologies d’assistance plus anciennes pourraient toujours percevoir le texte d’alerte même si l’alerte ne s’applique pas à ce moment, faisant croire de façon erronée aux utilisateurs à l’existence d’un problème.

      +**Note :** dans la plupart des cas cette approche n’est pas recommandée, parce qu'il n'est pas idéal de masquer une erreur ou un texte d’alerte qui n’est pas applicable à ce moment précis. Les utilisateurs de technologies d’assistance plus anciennes pourraient toujours percevoir le texte d’alerte même si l’alerte ne s’applique pas à ce moment, faisant croire de façon erronée aux utilisateurs à l’existence d’un problème. -
      .hidden {
      +```css
      +.hidden {
         display:none;
         }
      -
      +``` -
      <p id="expirationWarning" role="alert" class="hidden">Votre session expirera dans 2 minutes</p>
      -
      +```html + +``` -
      // suppression de la classe 'hidden' rend l’élément visible, ce qui entraînera l’annonce de l’alerte par le lecteur d’écran :
      -document.getElementById("expirationWarning").className = ""; 
      +```js +// suppression de la classe 'hidden' rend l’élément visible, ce qui entraînera l’annonce de l’alerte par le lecteur d’écran : +document.getElementById("expirationWarning").className = ""; +``` -

      Notes 

      +### Notes  -
        -
      • 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.
      • -
      +- 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`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_alertdialog) est préférable. -

      Attributs ARIA utilisés

      +### Attributs ARIA utilisés - +- [alert (en)](http://www.w3.org/TR/wai-aria/roles#alert) -

      Techniques ARIA connexes

      +### Techniques ARIA connexes - +- [Utiliser le rôle `alertdialog`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_alertdialog) ; +- [Utiliser la propriété `aria-invalid`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_la_propriété_aria-invalid). -

      Autres ressources

      +### Autres ressources - +- Guide des bonnes pratiques ARIA - Rôle `Alert` : [http://www.w3.org/TR/wai-aria-practices/#alert (en)](http://www.w3.org/TR/wai-aria-practices/#alert) diff --git a/files/fr/web/accessibility/aria/aria_techniques/using_the_alertdialog_role/index.md b/files/fr/web/accessibility/aria/aria_techniques/using_the_alertdialog_role/index.md index 70f746dff9..3a9521f0a3 100644 --- a/files/fr/web/accessibility/aria/aria_techniques/using_the_alertdialog_role/index.md +++ b/files/fr/web/accessibility/aria/aria_techniques/using_the_alertdialog_role/index.md @@ -9,74 +9,64 @@ tags: translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_alertdialog --- -

      Description

      +### Description -

      Cette technique présente l’utilisation du rôle alertdialog role.

      +Cette technique présente l’utilisation du rôle [`alertdialog`](http://www.w3.org/TR/2009/WD-wai-aria-20091215/roles#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`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_dialog_role) 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).
      • -
      • Contrairement aux alertes classiques, une boîte de dialogue d’alerte doit avoir au moins un contrôle pouvant recevoir le focus et ce dernier doit s’y placer lors de l’affichage de la boîte de dialogue. Généralement les boîtes de dialogues d’alertes ont au moins un bouton de confirmation, de fermeture ou d’annulation qui peut être utilisé pour recevoir le focus. De plus, les boîtes de dialogues d’alerte peuvent avoir d’autres contrôles interactifs tels que des champs de saisie, des onglets ou des cases à cocher. Le contrôle sur lequel placer le focus dépendra de l’objet de la boîte de dialogue.
      • -
      • L’ordre de tabulation dans la boite de dialogue de l’alerte doit boucler.
      • -
      +- 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`). +- Contrairement aux alertes classiques, une boîte de dialogue d’alerte doit avoir au moins un contrôle pouvant recevoir le focus et ce dernier doit s’y placer lors de l’affichage de la boîte de dialogue. Généralement les boîtes de dialogues d’alertes ont au moins un bouton de confirmation, de fermeture ou d’annulation qui peut être utilisé pour recevoir le focus. De plus, les boîtes de dialogues d’alerte peuvent avoir d’autres contrôles interactifs tels que des champs de saisie, des onglets ou des cases à cocher. Le contrôle sur lequel placer le focus dépendra de l’objet de la boîte de dialogue. +- L’ordre de tabulation dans la boite de dialogue de l’alerte doit boucler. -

      La différence avec les boîtes de dialogues classiques réside dans le fait que le rôle alertdialog devrait uniquement être utilisé lorsque des alertes, des erreurs ou des avertissements ont lieu. En d’autres termes, lorsque les informations et les contrôles d’une boîte de dialogue nécessitent l’attention immédiate de l’utilisateur il est préférable d’utiliser le rôle alertdialog plutôt que dialog. Il revient au développeur de faire la distinction entre les deux.

      +La différence avec les boîtes de dialogues classiques réside dans le fait que le rôle `alertdialog` devrait uniquement être utilisé lorsque des alertes, des erreurs ou des avertissements ont lieu. En d’autres termes, lorsque les informations et les contrôles d’une boîte de dialogue nécessitent l’attention immédiate de l’utilisateur il est préférable d’utiliser le rôle `alertdialog` plutôt que `dialog.` Il revient au développeur de faire la distinction entre les deux. -

      Du fait de sa nature urgente, les boîtes de dialogues d’alertes doivent toujours être modales.

      +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`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_alert)). -

      Effets possibles sur les agents utilisateurs et les technologies d’assistance

      +### Effets possibles sur les agents utilisateurs et les technologies d’assistance -

      Lorsque le rôle alertdialog est utilisé, l’agent utilisateur devrait suivre les étapes suivantes :

      +Lorsque le rôle `alertdialog` est utilisé, l’agent utilisateur devrait suivre les étapes suivantes : -
        -
      • Présenter l’élément comme une boîte de dialogue à l’API d’accessibilité du système d’exploitation.
      • -
      • Déclencher un évènement d’alerte accessible à l’aide l’API d’accessibilité du système d’exploitation si elle le prend en charge.
      • -
      +- Présenter l’élément comme une boîte de dialogue à l’API d’accessibilité du système d’exploitation. +- Déclencher un évènement d’alerte accessible à l’aide l’API d’accessibilité du système d’exploitation si elle le prend en charge. -

      Lorsque la boîte de dialogue de l’alerte apparaît, les lecteurs d’écran devraient annoncer l’alerte.

      +Lorsque la boîte de dialogue de l’alerte apparaît, les lecteurs d’écran devraient annoncer l’alerte. -

      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.

      +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. -

      Exemples

      +### Exemples -

      Exemple 1 : Une boîte de dialogue d’alerte

      +#### Exemple 1 : Une boîte de dialogue d’alerte -

      L’extrait de code ci-dessous présente la façon de baliser une boîte de dialogue d’alerte qui ne contient qu’un message et un bouton OK.

      +L’extrait de code ci-dessous présente la façon de baliser une boîte de dialogue d’alerte qui ne contient qu’un message et un bouton `OK`. -
      <div role="alertdialog" aria-labelledby="dialog1Titre" aria-describedby="dialog1Desc">
      -  <div role="document" tabindex="0">
      -    <h2 id="dialog1Titre">Votre session est sur le point d’expirer</h2>
      -    <p id="dialog1Desc">Pour prolonger votre session, cliquez sur le bouton OK</p>
      -    <button>OK</button>
      -  </div>
      -</div>
      +```html +
      +
      +

      Votre session est sur le point d’expirer

      +

      Pour prolonger votre session, cliquez sur le bouton OK

      + +
      +
      +``` -

      Exemples concrets :

      +#### Exemples concrets : -

      À définir

      +À définir -

      Notes

      +### Notes -

      Attributs ARIA utilisés

      +### Attributs ARIA utilisés - +- [alertdialog](http://www.w3.org/TR/wai-aria/roles#dialog) ; +- [aria-labelledby](http://www.w3.org/TR/wai-aria/states_and_properties#aria-labelledby) ; +- [aria-describedby](http://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby). -

      Techniques ARIA connexes

      +### Techniques ARIA connexes - +- [Utiliser le rôle `dialog`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_dialog) ; +- [Utiliser le rôle `alert`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_alert). diff --git a/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.md b/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.md index 5a2a646678..20d9ded8d0 100644 --- a/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.md +++ b/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.md @@ -8,78 +8,70 @@ tags: translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-describedby --- -

      L'attribut aria-describedby est utilisé pour indiquer les identifiants des éléments qui décrivent l'objet. Il est utilisé pour établir une relation entre des composants ou des groupes et un texte les décrivant. Il est similaire à aria-labelledby où un label décrit la nature d'un objet, tandis qu'une description fournit plus d'informations pouvant être utiles à l'utilisateur.

      +L'attribut [`aria-describedby`](https://www.w3.org/TR/wai-aria/#aria-describedby) est utilisé pour indiquer les identifiants des éléments qui décrivent l'objet. Il est utilisé pour établir une relation entre des composants ou des groupes et un texte les décrivant. Il est similaire à [aria-labelledby](/fr/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute) où un label décrit la nature d'un objet, tandis qu'une description fournit plus d'informations pouvant être utiles à l'utilisateur. -

      L'attribut aria-describedby n'est pas uniquement utilisé pour des éléments de formulaire ; il peut également être utilisé pour associer un texte statique avec des composants graphiques, des groupes d'éléments, des panneaux, des zones possédant un titre, des définitions, etc. La section Exemples ci-dessous fournit plus d'informations sur l'utilisation de cet attribut dans ces cas précis.

      +L'attribut `aria-describedby` n'est pas uniquement utilisé pour des éléments de formulaire ; il peut également être utilisé pour associer un texte statique avec des composants graphiques, des groupes d'éléments, des panneaux, des zones possédant un titre, des définitions, etc. La section [Exemples](#examples) ci-dessous fournit plus d'informations sur l'utilisation de cet attribut dans ces cas précis. -

      Cet attribut peut être utilisé avec n'importe quel élément de formulaire HTML ; il n'est pas limité aux éléments auxquels un rôle ARIA a été assigné.

      +Cet attribut peut être utilisé avec n'importe quel élément de formulaire HTML ; il n'est pas limité aux éléments auxquels un rôle ARIA a été assigné. -

      Valeur

      +## Valeur -

      La valeur de cet attribut est une liste d'identifiants d'éléments, séparés par des espaces

      +La valeur de cet attribut est une liste d'identifiants d'éléments, séparés par des espaces -

      Effets possibles sur les agents utilisateurs et les 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. -

      Exemples

      +## Exemples -

      Exemple 1 : Descriptions des points de repère (landmarks) d'une application

      +### Exemple 1 : Descriptions des points de repère (landmarks) d'une application -

      Dans l'exemple ci-dessous, un paragraphe d'introduction décrit une application de calendrier. aria-describedby est utilisé pour associer le paragraphe avec le conteneur de l'application.

      +Dans l'exemple ci-dessous, un paragraphe d'introduction décrit une application de calendrier. `aria-describedby` est utilisé pour associer le paragraphe avec le conteneur de l'application. -
      -<div role="applicaton" aria-labelledby="calendar" aria-describedby="info">
      -    <h1 id="calendar">Calendrier<h1>
      -    <p id="info">
      +```html
      +
      +

      Calendrier

      +

      Ce calendrier affiche les prévisions de match du Racing Métro. - </p> - <div role="grid"> +

      +
      … - </div> -</div> -

      +
      +
+``` -

Exemple 2 : Un bouton de fermeture

+### Exemple 2 : Un bouton de fermeture -

Dans l'exemple ci-dessous, un lien qui fonctionne comme le bouton Fermer d'une boîte de dialogue est décrit ailleurs dans le document. L'attribut aria-describedby est utilisé pour associer la description au lien.

+Dans l'exemple ci-dessous, un lien qui fonctionne comme le bouton `Fermer` d'une boîte de dialogue est décrit ailleurs dans le document. L'attribut `aria-describedby` est utilisé pour associer la description au lien. -
-<button aria-label="Fermer" aria-describedby="descriptionClose"
-    onclick="myDialog.close()">X</button>
+```html
+
 …
 
-<div id="descriptionClose">
+
La fermeture de cette fenêtre entraînera la perte des informations saisies et vous renverra vers la page principale. -</div> -
+
+``` -

Notes

+## Notes -
    -
  • L'attribut aria-describedby n'est pas destiné à référencer les descriptions d'une ressource externe. Comme il s'agit d'un identifiant, il doit référencer un élément du DOM du document courant.
  • -
+- L'attribut `aria-describedby` n'est pas destiné à référencer les descriptions d'une ressource externe. Comme il s'agit d'un identifiant, il doit référencer un élément du DOM du document courant. -

Utilisé par les rôles ARIA

+## Utilisé par les rôles ARIA -

Tous les éléments de balisage de base.

+Tous les éléments de balisage de base. - +## Techniques ARIA connexes - +- [Utiliser l'attribut `aria-labelledby`](/fr/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute) -

Compatibilité

+## Compatibilité -

À faire : ajouter les informations de prise en charge pour les combinaisons les plus courantes d'agents utilisateurs et de produits de technologies d'assistance.

+À faire : 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

+## Autres ressources - +- [Spécification WAI-ARIA de `aria-describedby`](https://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby) diff --git a/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-invalid_attribute/index.md b/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-invalid_attribute/index.md index c75af66bb9..ff0906e7fa 100644 --- a/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-invalid_attribute/index.md +++ b/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-invalid_attribute/index.md @@ -8,59 +8,57 @@ tags: translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-invalid_attribute original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-invalid --- -

Description

+### Description -

Cette technique présente l’utilisation de l’attribut aria-invalid.

+Cette technique présente l’utilisation de l’attribut [`aria-invalid`](http://www.w3.org/TR/wai-aria/states_and_properties#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.

+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. -

Cet attribut peut être utilisé avec n’importe quel élément de formulaire HTML typique ; il n’est pas limité aux éléments auxquels a été assigné un rôle ARIA.

+Cet attribut peut être utilisé avec n’importe quel élément de formulaire HTML typique ; il n’est pas limité aux éléments auxquels a été assigné un `rôle` ARIA. -

Valeurs

+### Valeurs -

Vocabulaire

+#### Vocabulaire -
-
false (défaut)
-
Aucune erreur détectée
-
grammar
-
Une faute de grammaire a été détectée.
-
spelling
-
Une faute d’orthographe a été détectée.
-
true
-
La valeur n’a pas passé la validation.
-
+- `false` (défaut) + - : Aucune erreur détectée +- `grammar` + - : Une faute de grammaire a été détectée. +- `spelling` + - : Une faute d’orthographe a été détectée. +- `true` + - : La valeur n’a pas passé la validation. -

Toute valeur absente de ce vocabulaire devrait être traitée comme true.

+Toute valeur absente de ce vocabulaire devrait être traitée comme `true`. -

Effets possibles sur les agents utilisateurs et les technologies d’assistance

+### Effets possibles sur les agents utilisateurs et les technologies d’assistance -

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.

+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. -

Exemples

+### Exemples -

Exemple 1 : validation d’un formulaire de base

+#### Exemple 1 : validation d’un formulaire de base -

L’extrait de code suivant décrit une version simplifiée de deux champs de formulaire avec une fonction de validation de la saisie attachée à la perte de focus. Notez que la valeur par défaut de aria-required étant false, il n’est pas strictement nécessaire d’ajouter à entrer.

+L’extrait de code suivant décrit une version simplifiée de deux champs de formulaire avec une fonction de validation de la saisie attachée à la perte de focus. Notez que la valeur par défaut de `aria-required` étant `false`, il n’est pas strictement nécessaire d’ajouter à entrer. -
<input name="nom" id="nom" aria-required="true" aria-invalid="false"
-        onblur="checkValidity('nom', ' ', 'Le nom saisi n’est pas valide (vous devez saisir un nom et un prénom)');"/>
-<br />
-<input name="courriel" id="courriel" aria-required="true" aria-invalid="false"
-        onblur="checkValidity('courriel', '@', 'L’adresse électronique saisie n’est pas valide');"/>
-
+```html + +
+ +``` -

Remarquez qu’il n’est pas nécessaire de valider les champs de saisie immédiatement à la perte de focus ; l’application peut attendre jusqu’à la soumission du formulaire (bien que ce ne soit pas particulièrement recommandé).

+Remarquez qu’il n’est pas nécessaire de valider les champs de saisie immédiatement à la perte de focus ; l’application peut attendre jusqu’à la soumission du formulaire (bien que ce ne soit pas particulièrement recommandé). -

L’extrait de code ci-dessous décrit une fonction de validation très simple qui ne vérifie que la présence d’un caractère particulier (en réalité, la validation sera un peu plus sophistiquée) :

+L’extrait de code ci-dessous décrit une fonction de validation très simple qui ne vérifie que la présence d’un caractère particulier (en réalité, la validation sera un peu plus sophistiquée) : -
function checkValidity(aID, aSearchTerm, aMsg){
+```js
+function checkValidity(aID, aSearchTerm, aMsg){
     var elem = document.getElementById(aID);
-    var invalid = (elem.value.indexOf(aSearchTerm) < 0);
+    var invalid = (elem.value.indexOf(aSearchTerm) < 0);
     if (invalid) {
       elem.setAttribute("aria-invalid", "true");
       updateAlert(aMsg);
@@ -69,11 +67,12 @@ original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-inva
       updateAlert();
     }
 }
-
+``` -

L’extrait de code ci-dessous décrit des fonctions d’alertes, qui ajoutent (ou suppriment) le message d’erreur :

+L’extrait de code ci-dessous décrit des fonctions d’alertes, qui ajoutent (ou suppriment) le message d’erreur : -
function updateAlert(msg) {
+```js
+function updateAlert(msg) {
     var oldAlert = document.getElementById("alert");
     if (oldAlert) {
         document.body.removeChild(oldAlert);
@@ -88,31 +87,25 @@ original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-inva
         document.body.appendChild(newAlert);
     }
 }
-
+``` -

Remarquez que le rôle ARIA de l’alerte est définit comme étant "alert".

+Remarquez que le `rôle` ARIA de l’alerte est définit comme étant [`"alert"`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_alert). -

Notes

+### Notes -
    -
  • Lorsque aria-invalid est utilisé en conjonction avec l’attribut aria-required, aria-invalid ne devrait pas être défini à true avant la soumission du formulaire – uniquement en réponse à la validation.
  • -
  • Les développements futurs pourraient ajouter des termes au vocabulaire utilisé pour cet attribut. Toute valeur absente du vocabulaire actuel devrait être traitée comme true.
  • -
+- Lorsque `aria-invalid` est utilisé en conjonction avec l’attribut `aria-required`, `aria-invalid` **ne devrait pas** être défini à `true` avant la soumission du formulaire – uniquement en réponse à la validation. +- Les développements futurs pourraient ajouter des termes au vocabulaire utilisé pour cet attribut. Toute valeur absente du vocabulaire actuel devrait être traitée comme `true`. -

Utilisé dans les rôles ARIA

+### Utilisé dans les rôles ARIA -

Tous les éléments de balisage de base.

+Tous les éléments de balisage de base. -

Techniques ARIA connexes

+### Techniques ARIA connexes - +- [Utiliser l’attribut `aria-required`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-required) +- [Utiliser le rôle `alert`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_alert) -

Autres ressources

+### Autres ressources - +- [Spécification WAI-ARIA de la propriété `aria-invalid`](http://www.w3.org/TR/wai-aria/states_and_properties#aria-invalid) +- [WAI Authoring Practices for forms](http://www.w3.org/TR/wai-aria-practices/#ariaform) (Règles WAI de création de formulaires) diff --git a/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.md b/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.md index 54c971151f..2dd44fb491 100644 --- a/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.md +++ b/files/fr/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.md @@ -9,63 +9,58 @@ tags: translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_l_attribut_aria-label --- -

L’attribut aria-label est utilisé pour définir une légende non-visible associée à un élément HTML dont le sens est transmis uniquement par le visuel. Par exemple, une croix pour fermer une fenêtre modale.

+L’attribut `aria-label` est utilisé pour définir une légende non-visible associée à un élément HTML dont le sens est transmis uniquement par le visuel. Par exemple, une croix pour fermer une fenêtre modale. -

Contexte

+## Contexte -

Pour la plupart des usagers, le contexte et l'apparence d'un élément suffisent à déterminer son rôle. Par exemple, une croix pour fermer une fenêtre modale ou une icône de hamburger pour ouvrir un menu.

+Pour la plupart des usagers, le contexte et l'apparence d'un élément suffisent à déterminer son rôle. Par exemple, une croix pour fermer une fenêtre modale ou une icône de hamburger pour ouvrir un menu. -

En revanche, certains usagers tels que les aveugles et malvoyants ne peuvent pas faire de même. Cet attribut permet aux développeurs d'indiquer une alternative textuelle à ces contrôles visuels, qui sera lue par les technologies d'assistance. En revanche, le contenu de l'attribut aria-label ne sera pas visible pour les autres usagers.

+En revanche, certains usagers tels que les aveugles et malvoyants ne peuvent pas faire de même. Cet attribut permet aux développeurs d'indiquer une alternative textuelle à ces contrôles visuels, qui sera lue par les technologies d'assistance. En revanche, le contenu de l'attribut `aria-label` ne sera pas visible pour les autres usagers. -

Effets possibles sur les agents utilisateurs et les 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.

+Les lecteurs d'écran lisent le contenu textuel de cet attribut. -

Usage

+## 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](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_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.

+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 `
+``` -

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 :

+#### Exemple 2 : une boîte de dialogue basée sur un `Fieldset` comme contenu alternatif -
<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>
-    </legend>
+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 :
 
-    <button>Fermer</button>
-</fieldset>
-
+```html +
+ + Vos informations personnelles ont correctement été actualisées. + Vous pouvez modifier vos informations personnelles à n’importe quel moment depuis la section « Compte utilisateur ». + -

Exemples concrets :

+ +
+``` - +#### Exemples concrets : -

Notes

+- [jQuery-UI Dialog](http://jqueryui.com/demos/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.

-
+### Notes + +> **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. -

Attributs ARIA utilisés

+### Attributs ARIA utilisés - +- [dialog (en)](http://www.w3.org/TR/wai-aria/roles#dialog) +- [aria-labelledby (en)](http://www.w3.org/TR/wai-aria/states_and_properties#aria-labelledby) +- [aria-describedby (en)](http://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby) -

Techniques ARIA connexes

+### Techniques ARIA connexes - +- [Utiliser le rôle `alertdialog`](/fr/Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_rôle_alertdialog) -

Autres ressources

+### Autres ressources diff --git a/files/fr/web/accessibility/aria/roles/listbox_role/index.md b/files/fr/web/accessibility/aria/roles/listbox_role/index.md index a3abd6cb40..a454806a8c 100644 --- a/files/fr/web/accessibility/aria/roles/listbox_role/index.md +++ b/files/fr/web/accessibility/aria/roles/listbox_role/index.md @@ -8,85 +8,72 @@ tags: translation_of: Web/Accessibility/ARIA/Roles/listbox_role original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_listbox --- -

Description

+### Description -

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](http://www.w3.org/TR/wai-aria/roles#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.

+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](http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#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](http://www.w3.org/TR/wai-aria-practices/#listbox_div) 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](http://www.w3.org/TR/wai-aria-practices/#checkbox). 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

+### 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 :

+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](http://www.w3.org/TR/wai-aria/roles#combobox), présenter l’élément comme un [menu](http://www.w3.org/TR/wai-aria/roles#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 technologies d’assistance devraient être à l’écoute de tels événements et les notifier à l’utilisateur en conséquence :

+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 label et le rôle de la boîte liste lorsqu’elle obtient le focus. Si un élément de la liste obtient le focus, il devrait être annoncé après, suivi par une indication de la position de l’élément dans la liste si le lecteur d’écran prend en charge cette fonction. Lorsque le focus se déplace dans la liste, le lecteur d’écran devrait annoncer les éléments de la liste appropriés. +- 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. -

Exemples

+### Exemples -

Exemple 1 : une liste de sélection simple qui utilise l’attribut aria-activedescendant

+#### Exemple 1 : une liste de sélection simple qui utilise l’attribut `aria-activedescendant` -

L’extrait de code ci-dessous montre comment le rôle listbox est ajouté directement dans le code source HTML :

+L’extrait de code ci-dessous montre comment le rôle `listbox` est ajouté directement dans le code source HTML : -
<div role="listbox" tabindex="0" id="listbox1" onclick="return listItemClick(event);"
+```html
+
+ onfocus="this.className='focus';" onblur="this.className='blur';" aria-activedescendant="listbox1-1"> +
Vert
+
Orange
+
Rouge
+
Bleu
+
Violet
+
Pervenche
+
+``` -

Voir l’exemple CodeTalks pour plus de détails.

+Voir l’[exemple](http://codetalks.org/source/widgets/listbox/listbox.html) CodeTalks pour plus de détails. -

Exemples concrets :

+#### Exemples concrets : - +- -

Notes

+### Notes -
    -
  • 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é.
  • -
+- Pour être accessible au clavier, les développeurs doivent [gérer le focus](http://www.w3.org/TR/wai-aria/roles#option) 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`](http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#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](http://www.w3.org/TR/wai-aria-practices/#listbox_div)). +- S’il existe une bonne raison pour [étendre](http://www.w3.org/TR/wai-aria/states_and_properties#aria-expanded) la boîte liste, le rôle [combobox](http://www.w3.org/TR/wai-aria/roles#combobox) peut être plus approprié. -

Attributs ARIA utilisés

+### Attributs ARIA utilisés - +- [listbox](http://www.w3.org/TR/wai-aria/roles#listbox) -

Techniques ARIA connexes

+### Techniques ARIA connexes - +- Rôle [combobox](http://www.w3.org/TR/wai-aria/roles#combobox). -

Autres ressources

+### Autres ressources -
    -
  • Bonnes pratiques ARIA – Listbox : #listbox_div
  • -
  • Le modèle de rôles ARIA – Listbox : #listbox
  • -
+- Bonnes pratiques ARIA – Listbox : [#listbox_div](http://www.w3.org/TR/wai-aria-practices/#listbox_div) +- Le modèle de rôles ARIA – Listbox : [#listbox](http://www.w3.org/TR/wai-aria/roles#listbox) diff --git a/files/fr/web/accessibility/aria/roles/switch_role/index.md b/files/fr/web/accessibility/aria/roles/switch_role/index.md index ec25d40d10..1dd2f5d17e 100644 --- a/files/fr/web/accessibility/aria/roles/switch_role/index.md +++ b/files/fr/web/accessibility/aria/roles/switch_role/index.md @@ -9,6 +9,6 @@ tags: translation_of: Web/Accessibility/ARIA/Roles/Switch_role original_slug: Accessibilité/ARIA/Techniques_ARIA/Utilisation_du_groupe_switch --- -

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](/fr/docs/Accessibilit%C3%A9/ARIA/Techniques_ARIA/Utiliser_le_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.

+Extrait des [spec ARIA 1.1 ](http://rawgit.com/w3c/aria/master/aria/aria.html#switch): 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. diff --git a/files/fr/web/accessibility/aria/roles/textbox_role/index.md b/files/fr/web/accessibility/aria/roles/textbox_role/index.md index f0c6824c54..ce0aeb8362 100644 --- a/files/fr/web/accessibility/aria/roles/textbox_role/index.md +++ b/files/fr/web/accessibility/aria/roles/textbox_role/index.md @@ -8,70 +8,65 @@ tags: translation_of: Web/Accessibility/ARIA/Roles/textbox_role original_slug: Accessibilité/ARIA/Techniques_ARIA/Utiliser_le_role_textbox --- -

Description

+### Description -

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`](http://www.w3.org/TR/wai-aria/roles#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.

+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. -

L’utilisation par défaut est pour un champ de saisie monoligne où Entrée ou Retour, enverra le formulaire, par exemple, comme avec le HTML <input type="text">. Lorsqu’on a un champ multilignes et que les retours à la ligne sont pris en charge, par exemple avec l’utilisation d’un élément HTML <textarea>, il est également nécessaire de définir l’attribut aria-multiline="true".

+L’utilisation par défaut est pour un champ de saisie monoligne où Entrée ou Retour, enverra le formulaire, par exemple, comme avec le HTML ``. Lorsqu’on a un champ multilignes et que les retours à la ligne sont pris en charge, par exemple avec l’utilisation d’un élément HTML ` +``` -

Exemples concrets :

+#### Exemples concrets : -

Notes

+### Notes -
    -
  • Les développeurs doivent connaitre la distinction qui existe entre les champs de saisie monolignes et les champs de saisie multilignes lorsqu’ils créent un champ ;
  • -
  • Les champs en lecture seule devraient être indiqués avec l’attribut aria-readonly.
  • -
+- Les développeurs doivent connaitre la distinction qui existe entre les champs de saisie monolignes et les champs de saisie multilignes lorsqu’ils créent un champ ; +- Les champs en lecture seule devraient être indiqués avec l’attribut `aria-readonly`. -

Attributs ARIA utilisés

+### Attributs ARIA utilisés - +- [textbox](http://www.w3.org/TR/wai-aria/roles#textbox). -

Techniques ARIA connexes

+### Techniques ARIA connexes -

N/A

+N/A -

Autres ressources

+### Autres ressources diff --git a/files/fr/web/accessibility/aria/web_applications_and_aria_faq/index.md b/files/fr/web/accessibility/aria/web_applications_and_aria_faq/index.md index 4c4f1a433a..c9815e24a0 100644 --- a/files/fr/web/accessibility/aria/web_applications_and_aria_faq/index.md +++ b/files/fr/web/accessibility/aria/web_applications_and_aria_faq/index.md @@ -9,149 +9,82 @@ tags: translation_of: Web/Accessibility/ARIA/Web_applications_and_ARIA_FAQ original_slug: Accessibilité/ARIA/FAQ_Applications_Web_et_ARIA --- -

Qu’est-ce qu’ARIA ?

- -

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.

- -

Pour plus d’informations sur la création de composants dynamiques accessibles avec ARIA, lire l’article Aperçu d’applications Web et de composants dynamiques accessibles.

- -

Où ARIA est-il pris en charge ?

- -

ARIA est une spécification relativement récente, mais son implémentation se développe. Une large variété de navigateurs communément utilisés, de technologies d’assistance, de kits de développements JavaScript et d’applications prennent maintenant en charge ARIA. Toutefois, de nombreux utilisateurs peuvent encore utiliser d’anciennes versions de ces technologies. Vous devrez sans doute considérer l’implémentation d’ARIA à l’aide des techniques d’améliorations progressives – telle qu’ajouter ARIA en utilisant JavaScript, mais pas directement dans votre balisage – afin de prendre en charge de manière plus élégante les vieux navigateurs et les anciennes technologies d’assistance.

- - - -

ARIA est pris en charge dans les navigateurs suivants :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NavigateurVersion minimaleNotes
Firefox3.0+Fonctionne avec NVDA, JAWS 10+ et Orca
ChromeDernièrePrise en charge encore expérimentale des lecteurs d’écran jusqu’à Chrome 15
Safari4+La prise en charge par Safari 5 est grandement améliorée.
- La prise en charge des zones live requiert Safari 5 avec VoiceOver sur iOS5 ou OS X Lion
Opera9.5+Requiert VoiceOver sous OS X. À définir : comment cela fonctionne-t-il actuellement ?
Internet Explorer8+Fonctionne avec JAWS 10+ et NVDA. Pas de prise en charge des zones live dans NVDA.
- La prise en charge dans IE9 est grandement améliorée.
- -

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 :

- - - -

Technologies d’assistance

- -

Les technologies d’assistance adoptent de plus en plus ARIA. Certaines d’entre elles sont :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Technologies d’assistanceVersion minimale pour un ARIA de baseVersion minimale pour la prise en charge des zones live et des alertes
NVDA2010.2
- (NVDA propose toujours des mises à jour gratuites)
2011.1 pour Firefox, pas de prise en charge des zones live dans IE avant 2011.2.
Orca? (À définir)? (À définir)
VoiceOverOSX 10.5,
- iOS 4
OS X 10.7
- iOS 5
JAWS810
Window-Eyes7Pas de prise en charge des zones live
ZoomText?Pas de prise en charge des zones live
- -

Note : Les versions antérieures de ces outils ont souvent des implémentation d’ARIA partielles et défaillantes.

- -

For notes on JAWS support for ARIA as of JAWS 10, lire cet article du groupe Paciello : JAWS Support for ARIA.

- -

Kits de développement JavaScript

- -

Les rôles, les états et les propriétés ARIA ont été ajoutées à de nombreux kits de développements d’interfaces utilisateur JavaScript, y compris :

- -
    -
  • Dojo/Dijit
  • -
  • jQuery UI
  • -
  • Fluid Infusion
  • -
  • Google Closure
  • -
  • Google Web Toolkit
  • -
  • BBC Glow
  • -
  • Yahoo! User Interface Library (YUI)
  • -
- -

Pour plus d’informations sur l’accessibilité des kits de développement JavaScript :

- - - -

Pouvez-vous me montrez un exemple d’ARIA en action ?

- -

Voici le code HTML pour une barre de progression :

- -
<div id="percent-loaded" role="progressbar" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100" />
-
- -

Cette barre de progression est construite à l’aide de l’élément <div>, qui n’est pas des plus descriptif. Malheureusement, en HTML4 il n’existe pas de balise plus sémantique pour les développeurs, aussi avons nous besoin d’inclure les rôles et les propriétés ARIA. Ils sont spécifiés en ajoutant des attributs à l’élément <div>. Dans cet exemple, l’attribut role="progressbar" informe le navigateur que cet élément est actuellement un composant de barre de progression codé en JavaScript. Les attributs aria-valuemin et aria-valuemax spécifient les valeurs limites de la barre de progression, et aria-valuenow décrit a valeur courante.

- -

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.
+## Qu’est-ce qu’ARIA ?
+
+WAI-ARIA est la spécification [Applications Internet Riches Accessibles](http://www.w3.org/WAI/intro/aria.php) de la [Web Accessibility Initiative](http://www.w3.org/WAI/) (Initiative pour l’accessibilité du Web) du [W3C](http://www.w3.org/). 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.
+
+Pour plus d’informations sur la création de composants dynamiques accessibles avec ARIA, lire l’article [Aperçu d’applications Web et de composants dynamiques accessibles](/fr/docs/Accessibilité/Aperçu_d_applications_Web_et_de_composants_dynamiques_accessibles).
+
+## Où ARIA est-il pris en charge ?
+
+ARIA est une spécification relativement récente, mais son implémentation se développe. Une large variété de navigateurs communément utilisés, de technologies d’assistance, de kits de développements JavaScript et d’applications prennent maintenant en charge ARIA. Toutefois, de nombreux utilisateurs peuvent encore utiliser d’anciennes versions de ces technologies. Vous devrez sans doute considérer l’implémentation d’ARIA à l’aide des techniques d’améliorations progressives – telle qu’ajouter ARIA en utilisant JavaScript, mais pas directement dans votre balisage – afin de prendre en charge de manière plus élégante les vieux navigateurs et les anciennes technologies d’assistance.
+
+### Navigateurs
+
+ARIA est pris en charge dans les navigateurs suivants :
+
+| Navigateur                                                                                       | Version minimale | Notes                                                                                                                                              |
+| ------------------------------------------------------------------------------------------------ | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Firefox                                                                                          | 3.0+             | Fonctionne avec NVDA, JAWS 10+ et Orca                                                                                                             |
+| [Chrome](http://dev.chromium.org/developers/design-documents/accessibility#TOC-WAI-ARIA-Support) | Dernière         | Prise en charge encore expérimentale des lecteurs d’écran jusqu’à Chrome 15                                                                        |
+| Safari                                                                                           | 4+               | La prise en charge par Safari 5 est grandement améliorée. La prise en charge des zones live requiert Safari 5 avec VoiceOver sur iOS5 ou OS X Lion |
+| [Opera](http://www.opera.com/docs/specs/presto28/wai-aria/roleattributes/)                       | 9.5+             | Requiert VoiceOver sous OS X. À définir : comment cela fonctionne-t-il actuellement ?                                                              |
+| [Internet Explorer](http://msdn.microsoft.com/en-us/library/cc891505%28v=vs.85%29.aspx)          | 8+               | Fonctionne avec JAWS 10+ et NVDA. Pas de prise en charge des zones live dans NVDA. La prise en charge dans IE9 est grandement améliorée.           |
+
+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 :
+
+- [caniuse.com](http://caniuse.com/wai-aria)
+- [Le groupe Paciello](http://www.paciellogroup.com/blog/aria-tests/ARIA-SafariaOperaIEFF-update2.html)
+
+### Technologies d’assistance
+
+Les technologies d’assistance adoptent de plus en plus ARIA. Certaines d’entre elles sont :
+
+| Technologies d’assistance | Version minimale pour un ARIA de base                     | Version minimale pour la prise en charge des zones live et des alertes           |
+| ------------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------- |
+| NVDA                      | 2010.2 (NVDA propose toujours des mises à jour gratuites) | 2011.1 pour Firefox, pas de prise en charge des zones live dans IE avant 2011.2. |
+| Orca                      | ? (À définir)                                             | ? (À définir)                                                                    |
+| VoiceOver                 | OSX 10.5, iOS 4                                           | OS X 10.7 iOS 5                                                                  |
+| JAWS                      | 8                                                         | 10                                                                               |
+| Window-Eyes               | 7                                                         | Pas de prise en charge des zones live                                            |
+| ZoomText                  | ?                                                         | Pas de prise en charge des zones live                                            |
+
+Note : Les versions antérieures de ces outils ont souvent des implémentation d’ARIA partielles et défaillantes.
+
+For notes on JAWS support for ARIA as of JAWS 10, lire cet article du *groupe Paciello* : [JAWS Support for ARIA](http://www.paciellogroup.com/blog/2010/10/jaws-support-for-aria/).
+
+### Kits de développement JavaScript
+
+Les rôles, les états et les propriétés ARIA ont été ajoutées à de nombreux kits de développements d’interfaces utilisateur JavaScript, y compris :
+
+- Dojo/Dijit
+- jQuery UI
+- Fluid Infusion
+- Google Closure
+- Google Web Toolkit
+- BBC Glow
+- Yahoo! User Interface Library (YUI)
+
+Pour plus d’informations sur l’accessibilité des kits de développement JavaScript :
+
+- [WAI-ARIA Implementation in JavaScript UI Libraries](http://www.paciellogroup.com/blog/2009/07/wai-aria-implementation-in-javascript-ui-libraries/) (Implémentation de WAI-ARIA dans les bibliothèques JavaScript d’UI) de Steve Faulkner
+
+## Pouvez-vous me montrez un exemple d’ARIA en action ?
+
+Voici le code HTML pour une barre de progression :
+
+```html
+
+``` + +Cette barre de progression est construite à l’aide de l’élément `
`, qui n’est pas des plus descriptif. Malheureusement, en HTML4 il n’existe pas de balise plus sémantique pour les développeurs, aussi avons nous besoin d’inclure les rôles et les propriétés ARIA. Ils sont spécifiés en ajoutant des attributs à l’élément `
`. Dans cet exemple, l’attribut `role="progressbar"` informe le navigateur que cet élément est actuellement un composant de barre de progression codé en JavaScript. Les attributs `aria-valuemin` et `aria-valuemax` spécifient les valeurs limites de la barre de progression, et `aria-valuenow` décrit a valeur courante. + +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 : + +```js +// Trouver le
 de la barre de progression dans le DOM. var progressBar = document.getElementById("percent-loaded"); // Définition de ses rôles et états ARIA , @@ -164,59 +97,63 @@ progressBar.setAttribute("aria-valuemax", 100); // pour actualiser la valeur de la barre de progression. function updateProgress(percentComplete) { progressBar.setAttribute("aria-valuenow", percentComplete); -}
+} +``` -

L’ajout d’ARIA changera-t-il le style ou le comportement de mes pages ?

+## L’ajout d’ARIA changera-t-il le style ou le comportement de mes pages ? -

Non, ARIA n’est rendu disponible que pour les APIs des technologies d’assistance, et n’affecte pas les fonctionnalités natives du navigateur en respectant le DOM ou les styles. Du point de vue des navigateurs, le HTML natif définit le sens et le comportement sémantique d’un élément, et les attributs ARIA agissent comme une surcouche permettant de prendre en charge les APIs des technologies d’assistance. Bien qu’ARIA ne modifiera aucun style par lui-même, comme pour tous les attributs HTML les CSS peuvent profiter des attributs ARIA comme sélecteurs d’élément. Ceci peut fournir un mécanisme pratique pour styles les composants intégrant ARIA.

+Non, ARIA n’est rendu disponible que pour les APIs des technologies d’assistance, et n’affecte pas les fonctionnalités natives du navigateur en respectant le DOM ou les styles. Du point de vue des navigateurs, le HTML natif définit le sens et le comportement sémantique d’un élément, et les attributs ARIA agissent comme une surcouche permettant de prendre en charge les APIs des technologies d’assistance. Bien qu’ARIA ne modifiera aucun style par lui-même, comme pour tous les attributs HTML les CSS peuvent profiter des attributs ARIA comme sélecteurs d’élément. Ceci peut fournir un mécanisme pratique pour styles les composants intégrant ARIA. -
.tab-panel[aria-hidden="true"] {
+```css
+.tab-panel[aria-hidden="true"] {
   display: none;
   }
 
 .tab-panel[aria-hidden="false"] {
   display: block;
   }
-
+``` -

Qu'en est-il de la validation ?

+## 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](http://validator.w3.org/). -

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.

+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 ?

+## 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 ``. 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](http://www.paciellogroup.com/blog/2010/04/html5-and-the-myth-of-wai-aria-redundance/). -

Dégradation élégante de HTML5 vers ARIA

+#### Dégradation élégante de HTML5 vers ARIA -

Pour fournir du contenu aux navigateurs qui n’implémentent pas HTML5, vous pouvez considérer une dégradation élégante de l’utilisation d’ARIA là où c’est nécessaire. Ainsi, en utilisant l’exemple de la barre de progression, vous pouvez dégrader élégamment un role="progressbar" pour les cas où la balise <progressbar> n’est pas prise en charge.

+Pour fournir du contenu aux navigateurs qui n’implémentent pas HTML5, vous pouvez considérer une dégradation élégante de l’utilisation d’ARIA là où c’est nécessaire. Ainsi, en utilisant l’exemple de la barre de progression, vous pouvez dégrader élégamment un `role="progressbar"` pour les cas où la balise `` n’est pas prise en charge. -

Voici un exemple de code utilisé pour une barre de progression en HTML5 :

+Voici un exemple de code utilisé pour une barre de progression en HTML5 : -
<!DOCTYPE html>
-<html>
-  <head><title>Dégrader élégamment la barre de progression</title></head>
-  <body>
-    <progress id="progress-bar" value="0" max="100">0% complété(s)</progress>
-    <button id="update-button">Actualiser</button>
- </body>
-</html>
-
+```html + + + Dégrader élégamment la barre de progression + + 0% complété(s) + +  + +``` -

… et voici le code JavaScript qui assurera le fonctionnement de la barre de progression même dans les navigateurs les plus anciens :

+… 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");
+```js
+var progressBar = document.getElementById("progress-bar");
 
-// Vérifions que le navigateur implémente la balise HTML5 <progress>.
+// Vérifions que le navigateur implémente la balise HTML5 .
 var supportsHTML5Progress = (typeof (HTMLProgressElement) !== "undefined");
 
 function setupProgress() {
   if (!supportsHTML5Progress) {
-    // HTML5 <progress> n’est pas implémenté dans ce navigateur, aussi
+    // HTML5  n’est pas implémenté dans ce navigateur, aussi
     // avons-nous besoin d’ajouter des rôles et des états ARIA à l’élément.
     progressBar.setAttribute("role", "progressbar");
     progressBar.setAttribute("aria-valuemin", 0);
@@ -226,11 +163,11 @@ function setupProgress() {
 
 function updateProgress(percentComplete) {
   if (!supportsHTML5Progress) {
-    // HTML5 <progress> n’est pas implémenté dans ce navigateur,
+    // HTML5  n’est pas implémenté dans ce navigateur,
     // aussi avons-nous besoin de mettre à jour l’attribut aria-valuenow
     progressBar.setAttribute("aria-valuenow", percentComplete);
   } else {
-    // HTML5 <progress> is supported, so update the value attribute instead.
+    // HTML5  is supported, so update the value attribute instead.
     progressBar.setAttribute("value", percentComplete);
   }
 
@@ -247,60 +184,48 @@ function initDemo() {
   }, false);
 }
 initDemo();
-
+``` -

Comment fonctionnent les technologies d’assistance ?

+## Comment fonctionnent les technologies d’assistance ? -

Les technologies d’assistance utilisent une API intégrée à chaque système d’exploitation spécifiquement conçue pour décrire les rôles, les états et la structure de l’interface utilisateur d’une application. Par exemple, un lecteur d’écran utilise cette API pour lire l’interface utilisateur avec un moteur de synthèse vocale (text-to-speech), une loupe l’utilise pour mettre en évidence les zones importantes ou actives de l’écran et un clavier virtuel peut s’en servir pour fournir la disposition de clavier la plus efficace dans un contexte donné ou au contrôle d’une interface utilisateur. Les technologies d’assistance accèdent souvent au DOM d’une page au travers de cette API afin de comprendre la sémantique et les attributs de la page.

+Les technologies d’assistance utilisent une API intégrée à chaque système d’exploitation spécifiquement conçue pour décrire les rôles, les états et la structure de l’interface utilisateur d’une application. Par exemple, un lecteur d’écran utilise cette API pour lire l’interface utilisateur avec un moteur de synthèse vocale (text-to-speech), une loupe l’utilise pour mettre en évidence les zones importantes ou actives de l’écran et un clavier virtuel peut s’en servir pour fournir la disposition de clavier la plus efficace dans un contexte donné ou au contrôle d’une interface utilisateur. Les technologies d’assistance accèdent souvent au DOM d’une page au travers de cette API afin de comprendre la sémantique et les attributs de la page. -

ARIA fournit un pont entre le monde du DOM et le bureau. Les navigateurs exposent les éléments ARIA aux API des technologies d’assistance comme s’ils étaient des composants natifs. En conséquence, l’utilisateur a potentiellement une expérience plus cohérente là où les composants dynamiques JavaScript sont comparables sur le Web à leurs équivalents bureau.

+ARIA fournit un pont entre le monde du DOM et le bureau. Les navigateurs exposent les éléments ARIA aux API des technologies d’assistance comme s’ils étaient des composants natifs. En conséquence, l’utilisateur a potentiellement une expérience plus cohérente là où les composants dynamiques JavaScript sont comparables sur le Web à leurs équivalents bureau. -

Comment tester mon utilisation d’ARIA ? Existe-t-il des outils libres ou gratuits ?

+## Comment tester mon utilisation d’ARIA ? Existe-t-il des outils libres ou gratuits ? -

Il existe plusieurs outils d’inspection et de débogage pour vous aider à tester le comportement d’ARIA :

+Il existe plusieurs outils d’inspection et de débogage pour vous aider à tester le comportement d’ARIA : - +- _Object Inspector_ sur Windows +- _Accessibility Inspector_ sur Mac OS X +- _AccProbe_ sur Linux +- _Inspecteur DOM_ de Firebug +- L’[_Inspecteur d’accessibilité_ de Firebug](http://code.google.com/p/ainspector/) -

Il existe plusieurs lecteurs d’écran gratuits voire libre qui peuvent être utilisés pour mener des tests sur ARIA. On trouve :

+Il existe plusieurs lecteurs d’écran gratuits voire libre qui peuvent être utilisés pour mener des tests sur ARIA. On trouve : - +- [Orca](http://live.gnome.org/Orca) pour Linux +- [NVDA](http://www.nvda-project.org/) pour Windows +- [VoiceOver](http://www.apple.com/accessibility/voiceover/) est intégré à Mac OS X -

Lorsque vous effectuez des tests avec un lecteur d’écran, gardez deux points importants en tête :

+Lorsque vous effectuez des tests avec un lecteur d’écran, gardez deux points importants en tête : -
    -
  1. Les tests occasionnels avec un lecteur d’écran ne pourront jamais remplacer les retours d’expérience, les tests ou l’aide de véritables utilisateurs au quotidien.
  2. -
  3. L’accessibilité est plus vaste que la simple prise en charge des lecteurs d’écran. Essayez de mener des tests avec divers cas d’utilisation et techniques d’accessibilité.
  4. -
+1. Les tests occasionnels avec un lecteur d’écran ne pourront jamais remplacer les retours d’expérience, les tests ou l’aide de véritables utilisateurs au quotidien. +2. L’accessibilité est plus vaste que la simple prise en charge des lecteurs d’écran. Essayez de mener des tests avec divers cas d’utilisation et techniques d’accessibilité. -

Autres techniques et outils de tests pratiques pour les applications et les composants intégrant ARIA :

+Autres techniques et outils de tests pratiques pour les applications et les composants intégrant ARIA : - +- [Yahoo!'s ARIA bookmarklets](http://yaccessibilityblog.com/library/test-aria-focus-bookmarklets.html) +- [simple accessibility evaluation techniques](http://wiki.fluidproject.org/display/fluid/Simple+Accessibility+Review+Protocol) du _Fluid Project_ (techniques simples d’évaluation de l’accessibilité) -

Où se tiennent les discussion concernant ARIA ?

+## Où se tiennent les discussion concernant ARIA ? - +- [Liste de diffusion Wai-xtech](http://lists.w3.org/Archives/Public/wai-xtech/) – Discussions sur les spécification d’ARIA. +- [groupe Google Free-ARIA](http://groups.google.com/group/free-aria) – pour les développeurs et les utilisateurs d’outils et de ressources libres. -

Où peut-on en apprendre davantage à propos d’ARIA ?

+## Où peut-on en apprendre davantage à propos d’ARIA ? - +- [Aperçu d’applications Web et de composants dynamiques accessibles](/fr/docs/Accessibilité/Aperçu_d_applications_Web_et_de_composants_dynamiques_accessibles) +- [Formulaires accessibles](/fr/docs/Accessibilité/Formulaires_accessibles) +- La [FAQ WAI-ARIA](http://www.w3.org/WAI/aria/faq) du W3C. +- [Accessibility of Rich Internet Applications](http://webaim.org/techniques/aria/) (Accessibilité des applications Internet riches) de WebAIM. diff --git a/files/fr/web/accessibility/aria/widgets/index.md b/files/fr/web/accessibility/aria/widgets/index.md index b343f06bf7..728cce4433 100644 --- a/files/fr/web/accessibility/aria/widgets/index.md +++ b/files/fr/web/accessibility/aria/widgets/index.md @@ -5,4 +5,4 @@ tags: - Accessibility translation_of: Web/Accessibility/ARIA/widgets --- -

Cette page s'est auto-générée parce qu'un utilisateur a créé une sous-page à cette page.

+Cette page s'est auto-générée parce qu'un utilisateur a créé une sous-page à cette page. diff --git a/files/fr/web/accessibility/community/index.md b/files/fr/web/accessibility/community/index.md index bf05404332..28cadcb774 100644 --- a/files/fr/web/accessibility/community/index.md +++ b/files/fr/web/accessibility/community/index.md @@ -6,13 +6,11 @@ tags: translation_of: Web/Accessibility/Community original_slug: Accessibilité/Communauté --- -

Ce document fournit des liens vers des listes de diffusions, des forums, et d'autres communautés portées sur l'accessibilité.

+Ce document fournit des liens vers des listes de diffusions, des forums, et d'autres communautés portées sur l'accessibilité. -

Si vous connaissez d'autres, ressources utiles  n'hésitez pas à ajouter un lien ci-dessous.

+Si vous connaissez d'autres, ressources utiles  n'hésitez pas à ajouter un lien ci-dessous. - +- [Newsgroup Mozilla Accessibility](news://news.mozilla.org/netscape.public.mozilla.accessibility) +- [Liste de discussion du groupe WAI](http://www.w3.org/WAI/IG/) +- [Projet d'accessibilité d'Unix](http://www.mozilla.org/projects/ui/accessibility/unix) (référence en anglais) +- [SUN Mozilla Accessibility Task Force](http://www.mozilla.org/access/resources) diff --git a/files/fr/web/accessibility/index.md b/files/fr/web/accessibility/index.md index 0ce3096545..fe021c34d4 100644 --- a/files/fr/web/accessibility/index.md +++ b/files/fr/web/accessibility/index.md @@ -9,57 +9,49 @@ tags: translation_of: Web/Accessibility original_slug: Accessibilité --- -

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é 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](http://fr.wikipedia.org/wiki/Accessibilit%C3%A9_du_web)) -

« 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](http://www.w3.org/standards/webdesign/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é:

+La documentation MDN [Accessibilité](/fr/docs/Accessibilit%C3%A9) contient des tutoriaux modernes et à jour en ce qui concerne les points essentiels de l'accessibilité: -
-
Qu'est-ce que l'accessibilité?
-
Cet article présente un module général sur ce que l'accessibilité est actuellement — Cela inclut ce que des groupes de personnes ont besoin de considérer et pourquoi, quels outils ils utilisent afin d'interagir avec les pages web et comment rendre accessible la partie de notre espace de travail web.
-
HTML: Une bonne base pour 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.
-
Meilleure pratiques d'accessibilité CSS et JavaScript
-
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.
-
Les bases de WAI-ARIA
-
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é.
-
Multimédia accessible
-
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.
-
Accessibilité sur mobile
-
É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.
-
+- [Qu'est-ce que l'accessibilité?](/fr/docs/Apprendre/a11y/What_is_accessibility) + - : Cet article présente un module général sur ce que l'accessibilité est actuellement — Cela inclut ce que des groupes de personnes ont besoin de considérer et pourquoi, quels outils ils utilisent afin d'interagir avec les pages web et comment rendre accessible la partie de notre espace de travail web. +- [HTML: Une bonne base pour l'accessibilité](/fr/docs/Apprendre/a11y/HTML) + - : 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. +- [Meilleure pratiques d'accessibilité CSS et JavaScript](/fr/docs/Apprendre/a11y/CSS_and_JavaScript) + - : 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. +- [Les bases de WAI-ARIA](/fr/docs/Apprendre/a11y/WAI-ARIA_basics) + - : 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é. +- [Multimédia accessible](/fr/docs/Apprendre/a11y/Multimedia) + - : 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. +- [Accessibilité sur mobile](/fr/docs/Apprendre/a11y/Mobile) + - : É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. -

Documentation

+## Documentation -
-
Développement web
-
Un ensemble d'articles soulignant les problèmes d'accessibilité dans le développement web.
-
ARIA
-
Un ensemble d'articles pour apprendre à utiliser ARIA pour améliorer l'accessibilité de vos documents HTML.
-
Développement de Technologie d'assistance (TA)
-
Un ensemble d'articles destiné aux développeurs de technologies d'assistance.
-
Check-list pour l'accessibilité mobile
-
Ce document fournit une liste concise des requis accessibilité pour les développeurs d’applications mobiles.
-
+- [Développement web](/fr/docs/Accessibilité/Développement_Web) + - : Un ensemble d'articles soulignant les problèmes d'accessibilité dans le développement web. +- [ARIA](/fr/docs/Accessibilité/ARIA) + - : Un ensemble d'articles pour apprendre à utiliser ARIA pour améliorer l'accessibilité de vos documents HTML. +- [Développement de Technologie d'assistance (TA)](/fr/docs/Accessibilité/Développement_TA) + - : Un ensemble d'articles destiné aux développeurs de technologies d'assistance. +- [Check-list pour l'accessibilité mobile](/fr/docs/Accessibilité/Checklist_accessibilite_mobile) + - : Ce document fournit une liste concise des requis accessibilité pour les développeurs d’applications mobiles. -

Outils pour les développeurs web

+## Outils pour les développeurs web - +- [Tests d'accessibilité automatisés](http://www-archive.mozilla.org/quality/embed/plans/accessibility/nsIAccessibleTestPlan.html) +- [Fangs, un émulateur de lecteur d'écran](http://www.standards-schmandards.com/index.php?show/fangs) -

Autres ressources

+## Autres ressources -
    -
  • Liste des lecteurs d'écran
  • -
  • OpenWeb — Très bon site offrant à la fois un regard expert sur le web et des exemples concrets d'utilisation des normes du W3C.
  • -
  • Opquast.com — Bonnes pratiques qualité pour les services en ligne.
  • -
  • AccessiWeb — Référentiel AccessiWeb pour l'accessibilité.
  • -
  • AcceDe Web — Documents adaptés aux principaux intervenants d’un projet web.
  • -
+- [Liste des lecteurs d'écran](https://support.mozilla.org/kb/accessibility-features-firefox-make-firefox-and-we) +- [OpenWeb](http://openweb.eu.org/) — Très bon site offrant à la fois un regard expert sur le web et des exemples concrets d'utilisation des normes du W3C. +- [Opquast.com](http://opquast.com/) — Bonnes pratiques qualité pour les services en ligne. +- [AccessiWeb](http://www.accessiweb.org/index.php/accessiweb_2.2_liste_generale.html) — Référentiel AccessiWeb pour l'accessibilité. +- [AcceDe Web](http://accede-web.com/fr/projet-accede-web/) — Documents adaptés aux principaux intervenants d’un projet web. diff --git a/files/fr/web/accessibility/keyboard-navigable_javascript_widgets/index.md b/files/fr/web/accessibility/keyboard-navigable_javascript_widgets/index.md index 967ed7852c..51dce2b52b 100644 --- a/files/fr/web/accessibility/keyboard-navigable_javascript_widgets/index.md +++ b/files/fr/web/accessibility/keyboard-navigable_javascript_widgets/index.md @@ -8,84 +8,87 @@ tags: translation_of: Web/Accessibility/Keyboard-navigable_JavaScript_widgets original_slug: Contrôles_DHTML_personnalisés_navigables_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.

-

Le tableau qui suit décrit le nouveau comportement de tabindex :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Attribut tabindexFocus disponible à la souris ou par JavaScript via element.focus()Navigable avec tabulation
non présentSuit le comportement par défaut de l'élément (oui pour les contrôles de formulaires, les liens, etc).Suit le comportement par défaut de l'élément.
Négatif
- (par exemple tabindex="-1")
OuiNon, l'auteur doit donner le focus avec element.focus() suite à l'utilisation des flèches ou d'autres touches.
Zéro
- (par exemple tabindex="0")
OuiDans l'ordre de tabulation relativement à la position de l'élément dans le document.
Positif
- (par exemple tabindex="33")
OuiLa valeur tabindex change manuellement lorsque cet élément est positionné dans l'ordre de tabulation. Ces éléments seront positionnés dans l'ordre de tabulation avant les éléments ayant tabindex="0" ou qui sont naturellement - - tabulables - .
-

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

-

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

-

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

-

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

-

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

-

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

-

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

-

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 :

-
<span tabindex="-1" onkeydown="return handleKeyDown();">
-
-

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

-

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

-

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.

-

{{ languages( { "en": "en/Key-navigable_custom_DHTML_widgets", "ja": "ja/Key-navigable_custom_DHTML_widgets" } ) }}

+### Le problème : les pages DHTML actuelles ne sont pas accessibles au clavier + +Un nombre croissant d'applications Web utilise [JavaScript](fr/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 `
` et autres `` 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](fr/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 ``). 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](fr/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`](http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/tabindex.asp), il devient possible de permettre aux contrôles [DHTML](fr/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` : + +| Attribut `tabindex` | Focus disponible à la souris ou par JavaScript via `element.focus()` | Navigable avec tabulation | +| ------------------------------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| non présent | Suit le comportement par défaut de l'élément (oui pour les contrôles de formulaires, les liens, etc). | Suit le comportement par défaut de l'élément. | +| Négatif (par exemple `tabindex="-1"`) | Oui | Non, l'auteur doit donner le focus avec `element.focus()` suite à l'utilisation des flèches ou d'autres touches. | +| Zéro (par exemple `tabindex="0"`) | Oui | Dans l'ordre de tabulation relativement à la position de l'élément dans le document. | +| Positif (par exemple `tabindex="33"`) | Oui | La valeur `tabindex` change manuellement lorsque cet élément est positionné dans l'ordre de tabulation. Ces éléments seront positionnés dans l'ordre de tabulation avant les éléments ayant `tabindex="0"` ou qui sont naturellement _tabulables_ . | + +### 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 `
>` ou `` le représentant. Vous pouvez consulter un exemple d'une [case à cocher basée sur un ``](http://www.mozilla.org/access/dhtml/class/checkbox) 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](http://www.mozilla.org/access/dhtml/class/tree) 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 + +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](fr/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](fr/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` + +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 + +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 + +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 + +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 \1px\ 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` + +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 + +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 + +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](http://whatwg.org/)). + +#### 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. + +{{ languages( { "en": "en/Key-navigable_custom_DHTML_widgets", "ja": "ja/Key-navigable_custom_DHTML_widgets" } ) }} diff --git a/files/fr/web/accessibility/mobile_accessibility_checklist/index.md b/files/fr/web/accessibility/mobile_accessibility_checklist/index.md index 9844156521..29dda3d796 100644 --- a/files/fr/web/accessibility/mobile_accessibility_checklist/index.md +++ b/files/fr/web/accessibility/mobile_accessibility_checklist/index.md @@ -10,92 +10,73 @@ tags: translation_of: Web/Accessibility/Mobile_accessibility_checklist original_slug: Accessibilité/Checklist_accessibilite_mobile --- -

Ce document fournit une liste concise des points à vérifier par les développeuses et développeurs pour garantir l'accessibilité d'une application mobile. Ce document est amené à évoluer pour tenir compte de nouvelles bonnes pratiques.

- -

La couleur

- -
    -
  • Le contraste des couleurs DOIT être conforme aux exigences du niveau AA du WCAG 2.1 : -
      -
    • Un contraste dont le ratio est de 4.5:1 pour les textes normaux (dont la fonte est inférieure à 18 points ou 14 points en gras) ;
    • -
    • Un contraste dont le ratio est de 3:1 pour les grands textes (18 points minimum ou 14 points en gras).
    • -
    -
  • -
  • L'information transmise par la couleur DOIT également être disponible par d'autres moyens (texte souligné pour les liens, etc.).
  • -
- -

La visibilité

- -
    -
  • Les techniques de masquage du contenu, telles que l'opacité nulle, l'ordre d'indexation en « z » et le placement hors écran, NE DOIVENT PAS être utilisées exclusivement pour gérer la visibilité.
  • -
  • Tout ce qui est autre, que l'écran actuellement visible, DOIT être vraiment invisible (particulièrement pertinent pour les apps à page unique avec plusieurs « cartes ») : -
      -
    • Utilisez l'attribut hidden ou les propriétés de style visibility ou display.
    • -
    • Sauf si cela est absolument inévitable, l'attribut aria-hidden NE DOIT PAS être utilisé.
    • -
    -
  • -
- -

Le focus

- -
    -
  • Tous les éléments activables DOIVENT être focusables : -
      -
    • Les contrôles standard tels que les liens, les boutons et les champs de formulaire sont accessibles par défaut.
    • -
    • Les contrôles non standard DOIVENT avoir un rôle ARIA approprié qui leur est attribué, comme button, link ou checkbox.
    • -
    -
  • -
  • Le focus DOIT être traité dans un ordre logique et de manière cohérente.
  • -
- -

Les équivalents textuels

- -
    -
  • Un équivalent textuel DOIT être fourni pour chaque élément non textuel non strictement présenté dans l'application. - -
  • -
  • Les images de texte DOIVENT être évitées.
  • -
  • Tous les composants de l'interface utilisateur ayant un texte visible (ou une image de texte) comme étiquette DOIVENT avoir le même texte disponible dans le nom programmatique du composant. WCAG 2.1 : Étiquette dans le nom.
  • -
  • Tous les contrôles de formulaire DOIVENT avoir des étiquettes (éléments <label>) pour le bénéfice des utilisateurs de lecteurs d'écran.
  • -
- -

La gestion des états

- -
    -
  • Les contrôles standard tels que les boutons radio et les cases à cocher sont gérés par le système d'exploitation. Cependant, pour d'autres contrôles personnalisés, les changements d'état DOIVENT être fournis via les états ARIA tels que aria-checked, aria-disabled, aria-selected, aria-expanded et aria-pressed.
  • -
- -

L'orientation

- -
    -
  • Le contenu NE DOIT PAS être limité à une seule orientation, comme le portrait ou le paysage, sauf si cela est essentiel. WCAG 2.1 : Orientation -
      -
    • Des exemples de cas où une orientation est essentielle sont une application pour un piano ou un chèque de banque.
    • -
    -
  • -
- -

Directives générales

- -
    -
  • Un titre d'application DOIT être fourni.
  • -
  • Les titres NE DOIVENT PAS rompre la structure hiérarchique -
    <h1>Titre de premier niveau</h1>
    -  <h2>Titre secondaire</h2>
    -  <h2>Un autre titre secondaire</h2>
    -    <h3>Titre de bas niveau</h3>
    -
  • -
  • L'ARIA Landmark Roles DOIT être utilisé pour décrire une structure d'application ou de document, telle que banner, complementary, contentinfo, main, navigation, search.
  • -
  • Pour les événements tactiles, au moins un des éléments suivants DOIT être vrai (WCAG 2.1 : Annulation du pointeur) : -
      -
    • L'événement de descente NE DOIT PAS être utilisé pour déclencher une action.
    • -
    • L'action est déclenchée par l'événement « up » et une option permettant d'interrompre l'action avant son achèvement est disponible ou une option permettant d'annuler l'action après son achèvement.
    • -
    • L'événement de montée annulera toute action déclenchée par un événement de descente.
    • -
    • Il est essentiel de déclencher l'action sur l'événement de descente. Par exemple, pour jouer à un jeu ou à une application de piano.
    • -
    -
  • -
  • Les cibles tactiles DOIVENT être suffisamment grandes pour que l'utilisateur puisse interagir avec elles (voir BBC Mobile Accessibility Guidelines pour des directives utiles sur la taille des cibles tactiles).
  • -
+Ce document fournit une liste concise des points à vérifier par les développeuses et développeurs pour garantir l'accessibilité d'une application mobile. Ce document est amené à évoluer pour tenir compte de nouvelles bonnes pratiques. + +## La couleur + +- Le contraste des couleurs **DOIT** être conforme aux [exigences du niveau AA du WCAG 2.1](https://www.w3.org/TR/WCAG/#contrast-minimum) : + + - Un contraste dont le ratio est de 4.5:1 pour les textes normaux (dont la fonte est inférieure à 18 points ou 14 points en gras) ; + - Un contraste dont le ratio est de 3:1 pour les grands textes (18 points minimum ou 14 points en gras). + +- L'information transmise par la couleur **DOIT** également être disponible par d'autres moyens (texte souligné pour les liens, etc.). + +## La visibilité + +- Les techniques de masquage du contenu, telles que l'opacité nulle, l'ordre d'indexation en « z » et le placement hors écran, **NE DOIVENT PAS** être utilisées exclusivement pour gérer la visibilité. +- Tout ce qui est autre, que l'écran actuellement visible, **DOIT** être _vraiment_ invisible (particulièrement pertinent pour les apps à page unique avec plusieurs « _cartes_ ») : + + - Utilisez l'attribut `hidden` ou les propriétés de style `visibility` ou `display`. + - Sauf si cela est absolument inévitable, l'attribut `aria-hidden` **NE DOIT PAS** être utilisé. + +## Le focus + +- Tous les éléments activables **DOIVENT** être focusables : + + - Les contrôles standard tels que les liens, les boutons et les champs de formulaire sont accessibles par défaut. + - Les contrôles non standard **DOIVENT** avoir un [rôle ARIA](/fr/docs/Web/Accessibility/ARIA/Roles) approprié qui leur est attribué, comme `button`, `link` ou `checkbox`. + +- Le focus **DOIT** être traité dans un ordre logique et de manière cohérente. + +## Les équivalents textuels + +- Un équivalent textuel **DOIT** être fourni pour chaque élément non textuel non strictement présenté dans l'application. + + - Utilisez _alt_ et _title_ lorsque cela est approprié (voir l'article de Steve Faulkner sur l'[Utilisation de l'attribut HTML title](https://www.tpgi.com/using-the-html-title-attribute-updated/)). + - Si les attributs ci-dessus ne sont pas applicables, utilisez les [États et propriétés ARIA](https://www.w3.org/TR/wai-aria-1.1/#state_prop_def) appropriés tels que `aria-label`, `aria-labelledby`, ou `aria-describedby`. + +- Les images de texte **DOIVENT** être évitées. +- Tous les composants de l'interface utilisateur ayant un texte visible (ou une image de texte) comme étiquette **DOIVENT** avoir le même texte disponible dans le [nom](https://www.w3.org/TR/WCAG21/#dfn-name) programmatique du composant. [WCAG 2.1 : Étiquette dans le nom.](https://www.w3.org/WAI/WCAG21/Understanding/label-in-name.html) +- Tous les contrôles de formulaire **DOIVENT** avoir des étiquettes (éléments [`