From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- .../a11y/accessibility_troubleshooting/index.html | 117 +++++ .../apprendre/a11y/css_and_javascript/index.html | 368 ++++++++++++++ files/fr/apprendre/a11y/html/index.html | 530 +++++++++++++++++++++ files/fr/apprendre/a11y/index.html | 56 +++ files/fr/apprendre/a11y/mobile/index.html | 311 ++++++++++++ files/fr/apprendre/a11y/multimedia/index.html | 374 +++++++++++++++ files/fr/apprendre/a11y/wai-aria_basics/index.html | 425 +++++++++++++++++ .../a11y/what_is_accessibility/index.html | 198 ++++++++ 8 files changed, 2379 insertions(+) create mode 100644 files/fr/apprendre/a11y/accessibility_troubleshooting/index.html create mode 100644 files/fr/apprendre/a11y/css_and_javascript/index.html create mode 100644 files/fr/apprendre/a11y/html/index.html create mode 100644 files/fr/apprendre/a11y/index.html create mode 100644 files/fr/apprendre/a11y/mobile/index.html create mode 100644 files/fr/apprendre/a11y/multimedia/index.html create mode 100644 files/fr/apprendre/a11y/wai-aria_basics/index.html create mode 100644 files/fr/apprendre/a11y/what_is_accessibility/index.html (limited to 'files/fr/apprendre/a11y') diff --git a/files/fr/apprendre/a11y/accessibility_troubleshooting/index.html b/files/fr/apprendre/a11y/accessibility_troubleshooting/index.html new file mode 100644 index 0000000000..27f7489b2e --- /dev/null +++ b/files/fr/apprendre/a11y/accessibility_troubleshooting/index.html @@ -0,0 +1,117 @@ +--- +title: 'Évaluation: dépannage d''accessibilité' +slug: Apprendre/a11y/Accessibility_troubleshooting +tags: + - Accessibilité + - Apprendre + - CSS + - Débutant + - HTML + - JavaScript +translation_of: Learn/Accessibility/Accessibility_troubleshooting +--- +

{{LearnSidebar}}
+ {{PreviousMenu("Learn/Accessibility/Mobile", "Learn/Accessibility")}}

+ +

Dans l’évaluation de ce module, nous vous présentons un site simple, qui présente un certain nombre de problèmes d’accessibilité que vous devez diagnostiquer et résoudre.

+ + + + + + + + + + + + +
Conditions préalables:Connaissances informatiques de base, une compréhension de base de HTML, CSS et JavaScript, une compréhension de la  previous articles in the course.
Objectif:Tester les connaissances de base sur les principes fondamentaux d'accessibilité.
+ +
+
+
+

Point de départ

+ +
 
+
+
+
+ +

Pour lancer cette évaluation, vous devez aller chercher le  ZIP containing the files that comprise the example. Décompressez le contenu dans un nouveau répertoire quelque part sur votre ordinateur local

+ +

Le site d'évaluation terminé devrait ressembler à ceci:

+ +

+ +

Vous verrez quelques différences / problèmes avec l'affichage de l'état de départ de l'évaluation - ceci est principalement dû aux différences dans le balisage, ce qui cause des problèmes de style car le CSS n'est pas appliqué correctement. Ne vous inquiétez pas, vous allez résoudre ces problèmes dans les prochaines sections!

+ +

Résumé du projet

+ +

Pour ce projet, vous êtes présenté avec un site naturel fictif affichant un article "factuel" sur les ours. Dans l'état actuel des choses, plusieurs problèmes d'accessibilité se posent. Votre tâche consiste à explorer le site existant et à le réparer au mieux de vos capacités, en répondant aux questions ci-dessous.

+ +
+

Couleur

+
+ +

Le texte est difficile à lire en raison du schéma de couleurs actuel. Pouvez-vous tester le contraste de couleurs actuel (texte / arrière-plan), en rapporter les résultats, puis le corriger en modifiant les couleurs attribuées?

+ +

Semantic HTML

+ +
    +
  1. Le contenu n'est toujours pas très accessible - faites un rapport sur ce qui se passe lorsque vous essayez de naviguer à l'aide d'un lecteur d'écran.
    2. +
  2. Pouvez-vous mettre à jour le texte de l'article pour faciliter la navigation des utilisateurs de lecteurs d'écran?
    3. +
  3. La partie du menu de navigation du site ( <div class="nav"></div>) pourrait être rendue plus accessible en la plaçant dans un élément sémantique HTML5 approprié. Lequel devrait-il être mis à jour? Faites la mise à jour.
    4. +
+ +
+

Note: Vous devrez mettre à jour les sélecteurs de règles CSS qui attribuent aux balises le même style que les balises sémantiques. Une fois que vous avez ajouté des éléments de paragraphe, vous remarquerez que le style est meilleur.

+
+ +

Les images

+ +

Les images sont actuellement inaccessibles aux utilisateurs de lecteur d'écran. Pouvez-vous réparer ceci?

+ +

Le lecteur audio

+ +
    +
  1. Le lecteur  <audio> n'est pas accessible aux malentendants (pouvez-vous ajouter une sorte d'alternative accessible pour ces utilisateurs)?
    2. +
  2. Le lecteur  <audio> n'est pas accessible aux utilisateurs de navigateurs plus anciens qui ne prennent pas en charge l'audio HTML5. Comment pouvez-vous leur permettre d'accéder encore à l'audio?
    3. +
+ +

Les formulaires

+ +
    +
  1. L'élément  <input> dans le formulaire de recherche en haut pourrait être associé à une étiquette, mais nous ne souhaitons pas ajouter une étiquette de texte visible qui risquerait de gâcher la conception et qui n'est pas vraiment utile aux utilisateurs voyants. Comment ajouter une étiquette uniquement accessible aux lecteurs d’écran? ?
    2. +
  2. Les deux éléments  <input> du formulaire de commentaire ont des étiquettes de texte visibles, mais ils ne sont pas associés sans ambiguïté à leurs étiquettes. Comment y parvenir? Notez que vous devrez également mettre à jour certaines règles CSS.
    3. +
+ +

Le contrôle afficher / masquer les commentaires

+ +

Le bouton de commande afficher / masquer les commentaires n’est pas actuellement accessible au clavier. Pouvez-vous le rendre accessible au clavier, à la fois en termes de focalisation à l'aide de la touche de tabulation et d'activation à l'aide de la touche de retour?

+ +

La table

+ +

Le tableau de données (data table ) n'est pas très accessible actuellement. Il est difficile pour les utilisateurs de lecteur d'écran d'associer des lignes et des colonnes de données. De plus, le tableau ne contient aucun type de résumé permettant de clarifier ce qu'il montre. Pouvez-vous ajouter des fonctionnalités à votre code HTML pour résoudre ce problème?

+ +

Autres considérations?

+ +

Pouvez-vous énumérer deux autres idées d’amélioration qui rendraient le site Web plus accessible?

+ +

Évaluation

+ +

Si vous suivez cette évaluation dans le cadre d'un cours organisé, vous devriez pouvoir donner votre travail à votre enseignant / mentor pour qu'il la corrige. Si vous vous auto-apprenez, vous pouvez obtenir le guide de notation assez facilement en le demandant sur la discussion thread for this exercise,  ou sur le canal IRC #mdn  sur Mozilla IRC. Essayez d'abord l'exercice - il n'y a rien à gagner à tricher!

+ +

{{PreviousMenu("Learn/Accessibility/Mobile", "Learn/Accessibility")}}

+ +

Dans ce module

+ + diff --git a/files/fr/apprendre/a11y/css_and_javascript/index.html b/files/fr/apprendre/a11y/css_and_javascript/index.html new file mode 100644 index 0000000000..3f59d3a489 --- /dev/null +++ b/files/fr/apprendre/a11y/css_and_javascript/index.html @@ -0,0 +1,368 @@ +--- +title: Meilleures pratiques d'accessibilité CSS et JavaScript +slug: Apprendre/a11y/CSS_and_JavaScript +tags: + - Accessibilité + - Apprendre + - Article + - CSS + - Codage des scripts + - Guide + - JavaScript + - contraste + - couleur + - discret +translation_of: Learn/Accessibility/CSS_and_JavaScript +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Accessibility/HTML","Learn/Accessibility/WAI-ARIA_basics", "Learn/Accessibility")}}
+ +

CSS et JavaScript, lorsqu'ils sont utilisés correctement, peuvent également permettre des expériences web accessibles... ou peuvent nuire considérablement à l'accessibilité s'ils sont mal utilisés. Cet article décrit certaines des meilleures pratiques CSS et JavaScript à prendre en compte pour garantir que même un contenu complexe soit aussi accessible que possible.

+ + + + + + + + + + + + +
Prérequis :Connaissances informatiques de base, compréhension de base de HTML, CSS et JavaScript, et compréhension de  Qu'est ce que l'accessibilité ?
Objectif :Familiarisez-vous avec l’utilisation appropriée de CSS et de JavaScript dans vos documents Web afin d’optimiser l’accessibilité et de ne pas la compromettre.
+ +

CSS et JavaScript, des technologies accessibles ?

+ +

CSS et JavaScript n’ont pas la même importance immédiate en matière d’accessibilité que le HTML, mais ils peuvent toujours aider ou nuire à l’accessibilité, en fonction de leur utilisation. En d'autres termes, il est important que vous preniez en compte certains conseils de meilleures pratiques pour vous assurer que votre utilisation de CSS et de JavaScript ne ruine pas l'accessibilité de vos documents.

+ +

CSS

+ +

Commençons par regarder le CSS.

+ +

Sémantique correcte et attentes de l'utilisateur

+ +

Il est possible d’utiliser CSS pour détourner l'apparence d'un élément HTML pour qu'il ressemble à un autre, mais cela ne veut pas dire que vous devriez le faire. Comme nous l’avons souvent mentionné dans notre article HTML : une bonne base pour l'accessibilité, vous devez utiliser, dans la mesure du possible, l’élément sémantique approprié. Sinon, cela peut créer de la confusion et des difficultés d'usage pour tout le monde, plus particulièrement pour les utilisateurs handicapés. L'utilisation de la sémantique correcte a beaucoup à voir avec les attentes des utilisateurs  — les éléments ont une apparence et un comportement particuliers, en fonction de leurs fonctionnalités, et ces conventions communes sont attendues par les utilisateurs.

+ +

Par exemple, un utilisateur de lecteur d'écran ne peut pas naviguer dans une page via des éléments d'en-tête si le développeur n'a pas utilisé les éléments d'en-tête de manière appropriée pour annoter le contenu. De la même manière, un en-tête perd son utilité visuelle si vous le stylisez de sorte qu'il ne ressemble pas à un en-tête.

+ +

La règle de base est la suivante : adaptez les styles et les comportements à votre conception sans rompre les habitudes utilisateur qui permettent une expérience intuitive. Les sections suivantes résument les principales fonctionnalités HTML à prendre en compte.

+ +

Structure du contenu du texte "standard"

+ +

Titres, paragraphes, listes — le contenu de texte de base de votre page :

+ +
<h1>En-têtes</h1>
+
+<p>paragraphes</p>
+
+<ul>
+  <li>Ma liste</li>
+  <li>a deux éléments.</li>
+</ul>
+ +

Quelques styles CSS typiques pourraient ressembler à ceci :

+ +
h1 {
+  font-size: 5rem;
+}
+
+p, li {
+  line-height: 1.5;
+  font-size: 1.6rem;
+}
+ +

Vous devriez :

+ + + +

Voir Fondamentaux du texte HTML et  Introduction au style de texte pour plus d'informations.

+ +

Texte mis en emphase

+ +

On met en avant une portion de texte grâce au balises inline <em> :

+ +
<p> L'eau est <em> très chaude </em>.</p>
+
+<p> Les gouttelettes d’eau accumulées sur les surfaces s’appellent  <strong>condensation</strong>.</p>
+ +

Vous voudrez peut-être ajouter quelques couleurs simples à votre texte mis en importance :

+ +
strong, em {
+  color: #a60000;
+}
+ +

Cependant, vous aurez rarement besoin de styliser des éléments d’emphase de manière significative. Les conventions standard de texte en gras () et en italique (emphase) sont très reconnaissables, et le changement de style peut être source de confusion. Pour mettre des contenus en avant de manière efficace, voir Fondamentaux du texte HTML.

+ +

Les abréviations

+ +

Un élément permettant d'associer une abréviation, un acronyme ou un sigle à sa forme développée :

+ +
<p> Le contenu web est marqué à l'aide de  <abbr title="Hypertext Markup Language">HTML</abbr>.</p>
+ +

Encore une fois, vous voudrez peut-être appliquer une mise en forme simple sur ces éléments :

+ +
abbr {
+  color: #a60000;
+}
+ +

Par convention, on souligne en pointillés les abréviations et il n’est pas judicieux de s’écarter significativement cette règle reconnue. Pour plus d'informations sur les abréviations, voir Abréviations.

+ +
+

Liens

+
+ +

Hyperliens  la façon dont vous accédez à de nouveaux endroits sur le Web :

+ +
<p> Visiter la  <a href="https://www.mozilla.org"> Page d'accueil de Mozilla </a>.</p>
+ +

Un style de lien très simple est présenté ci-dessous :

+ +
a {
+  color: #ff0000;
+}
+
+a:hover, a:visited, a:focus {
+  color: #a60000;
+  text-decoration: none;
+}
+
+a:active {
+  color: #000000;
+  background-color: #a60000;
+}
+ +

Les conventions de style sur les liens sont le soulignement et une couleur différente (par défaut : bleu) dans leur état normal (non visité) de celle utilisée lorsque le lien a déjà été visité (par défaut : violet) et de celle utilisée lorsque le lien est activé (par défaut : rouge). De plus, le pointeur de la souris se change en icône de pointeur lorsque les liens sont déplacés, et le lien reçoit une surbrillance lorsqu'il est ciblé (par exemple, via une tabulation) ou activé. L'image suivante montre la surbrillance dans Firefox (contour en pointillé) et Chrome (contour bleu) :

+ +

+ +

+ +

Vous pouvez faire preuve de créativité avec les styles de lien, tant que vous continuez à donner aux utilisateurs des informations visuelles en retour lorsqu'ils interagissent avec les liens. Quelque chose doit effectivement se produire pour signaler les changements d'états d'un lien, et vous ne devriez pas vous débarrasser du curseur de pointeur ou du contour — ces deux outils sont des aides très importantes pour l'accessibilité pour ceux qui utilisent les contrôles du clavier.

+ +

Éléments form

+ +

Éléments permettant aux utilisateurs de saisir des données sur des sites web :

+ +
<div>
+  <label for="name">Entrez votre nom</label>
+  <input type="text" id="name" name="name">
+</div>
+ +

Vous pouvez voir de bons exemples de CSS dans notre exemple form-css.html et (en direct).

+ +

La plupart du CSS que vous rédigerez pour les formulaires servira à dimensionner les éléments, à aligner les étiquettes et les entrées, et à leur donner une apparence nette et ordonnée.

+ +

Toutefois, vous ne devriez pas trop vous écarter des indications visuelles classiques qui signalent qu'un élément du formulaire est ciblé, c'est fondamentalement la même chose que pour les liens (voir ci-dessus). Vous pouvez mettre en forme les états ciblé / survolé du formulaire pour rendre ce comportement plus cohérent sur les navigateurs ou pour obtenir une meilleure intégration au design de votre page, mais ne vous en débarrassez pas complètement. Là encore, les utilisateurs s’appuient sur ces indices pour comprendre ce qui se passe.

+ +

Tableaux

+ +

Tableaux pour la présentation des données tabulées.

+ +

Vous pouvez voir un bon exemple simple de  table-css.html et (en direct).

+ +

En appliquant les propriétés du module CSS des tableaux, vous pourrez adapter les tables HTML à votre design avec une apparence pas trop affreuse. Il est judicieux de vous assurer que les en-têtes de table se démarquent (normalement en gras), et de zébrer les lignes via le pseudo-sélecteur :nth-child(n) pour faciliter la lecture.

+ +

Couleur et contraste de couleur

+ +

Lorsque vous choisissez un jeu de couleurs pour votre site web, assurez-vous que la couleur du texte contraste bien avec la couleur de fond. Votre design peut sembler agréable, mais cela n’est pas bon si les personnes malvoyantes, par exemple atteintes de daltonisme, ne peuvent pas lire votre contenu.

+ +

Il existe un moyen simple de vérifier si votre contraste est suffisamment important pour ne pas causer de problèmes. Il existe un certain nombre d’outils de vérification du contraste en ligne dans lesquels vous pouvez entrer vos couleurs de premier plan et d’arrière-plan afin de les vérifier. Par exemple, le vérificateur de contraste de couleur du WebAIM est simple à utiliser et explique ce dont vous avez besoin pour vous conformer aux critères WCAG relatifs au contraste des couleurs.

+ +
+

Note : Un taux de contraste élevé permettra également à toute personne utilisant un smartphone ou une tablette avec un écran brillant de mieux lire les pages dans un environnement lumineux, tel qu'exposé à la lumière du soleil.

+
+ +

Un autre conseil est de ne pas compter uniquement sur la couleur pour les panneaux / informations, car cela ne sera pas bon pour ceux qui ne peuvent pas voir la couleur. Au lieu de marquer les champs de formulaire obligatoires en rouge, par exemple, marquez-les d'un astérisque et en rouge.

+ +

Cacher des choses

+ +

Dans de nombreux cas, une conception visuelle nécessitera de ne pas afficher tout le contenu en même temps. Par exemple, dans notre Exemple de boîte d'information à onglets (voir notre code source), nous avons trois panneaux d’informations, mais nous les positionnons les uns sur les autres et fournissons des onglets sur lesquels on peut cliquer pour les afficher à tour de rôle (c’est aussi accessible au clavier – vous pouvez également utiliser Tab et Entrée pour les sélectionner).

+ +

+ +

Les utilisateurs de lecteur d’écran ne s’inquiètent de rien. Ils sont satisfaits du contenu tant que l’ordre des sources est logique et ils peuvent tout comprendre. Le positionnement absolu (tel qu'utilisé dans cet exemple) est généralement considéré comme l'un des meilleurs mécanismes permettant de masquer un contenu pour obtenir un effet visuel, car il n'empêche pas les lecteurs d'écran d'y accéder.

+ +

Par contre, vous ne devriez pas utiliser {{cssxref("visibility")}}:hidden ou {{cssxref("display")}}:none, car ils masquent le contenu des lecteurs d'écran sauf si vous souhaitez que ce contenu leur soit masqué.

+ +
+

Note : Contenu invisible juste pour les utilisateurs de lecteur d'écran contient beaucoup plus de détails utiles concernant ce sujet.

+
+ +

Accepter que les utilisateurs puissent remplacer les styles

+ +

Acceptez que les utilisateurs puissent remplacer vos styles

+ +

Il est possible pour les utilisateurs de remplacer vos styles par leurs propres styles personnalisés, par exemple :

+ + + +

Les utilisateurs peuvent le faire pour diverses raisons. Un utilisateur malvoyant peut vouloir agrandir le texte de tous les sites Web qu’il visite, ou un utilisateur présentant un déficit de couleur grave peut vouloir afficher tous les sites Web dans des couleurs très contrastées, faciles à lire. Quel que soit le besoin, vous devriez être à l'aise avec cela et rendre vos conceptions suffisamment flexibles pour que de tels changements fonctionnent dans votre conception. Par exemple, vous voudrez peut-être vous assurer que votre zone de contenu principale peut gérer un texte plus volumineux (le défilement commencera peut-être pour permettre à tout le monde de le voir), et ne le cachera pas ou ne sera pas complètement interrompu.

+ +

JavaScript

+ +

JavaScript peut également compromettre l’accessibilité, selon son utilisation.

+ +

Le JavaScript moderne est un langage puissant, et nous pouvons faire beaucoup de choses avec cela de nos jours, du contenu simple et des mises à jour d'interface utilisateur aux jeux 2D et 3D à part entière. Aucune règle ne stipule que tout le contenu doit être accessible à 100% à toutes les personnes. Vous devez simplement faire ce que vous pouvez et rendre vos applications aussi accessibles que possible.

+ +

Le contenu et les fonctionnalités simples sont facilement accessibles – texte, images, tableaux, formulaires et bouton-poussoir activant des fonctions. Comme nous l'avons vu dans notre article HTML : une bonne base pour l'accessibilité,  les principales considérations sont les suivantes :

+ + + +

Nous avons également examiné un exemple d'utilisation de JavaScript pour intégrer des fonctionnalités là où il manque – voir Remettre l'accessibilité au clavier. Ce n'est pas l'idéal – vous devez utiliser le bon élément pour le bon travail – mais cela montre que c'est possible dans des situations où, pour une raison quelconque, vous ne pouvez pas contrôler le balisage utilisé. Un autre moyen d'améliorer l'accessibilité pour les widgets non sémantiques reposant sur JavaScript consiste à utiliser WAI-ARIA pour fournir une sémantique supplémentaire aux utilisateurs de lecteurs d'écran. Le prochain article couvrira également cela en détail.

+ +

Les fonctionnalités complexes telles que les jeux 3D ne sont pas si faciles à rendre accessibles – un jeu 3D complexe créé à l'aide de L'API WebGL : graphismes 2D et 3D pour le web sera rendu sur un élément {{htmlelement("canvas")}}, qui n'a pour l'instant aucune possibilité de fournir textes alternatifs ou autres informations à utiliser par les utilisateurs malvoyants. On peut soutenir qu’un tel jeu ne compte pas vraiment ce groupe de personnes dans son public cible principal, et il serait déraisonnable de s’attendre à ce que vous le rendiez accessible à 100% aux aveugles, quelle que soit l’implantation des contrôles clavier faite pour qu'il soit utilisable par les utilisateurs sans souris. De plus, rendez le jeu de couleurs suffisamment contrasté pour pouvoir rendre le jeu vidéo utilisable par ceux qui ont des déficiences de la perception des couleurs.

+ +

Le problème avec trop de JavaScript

+ +

Le problème survient souvent lorsque les utilisateurs se fient trop à JavaScript. Parfois, vous voyez un site Web où tout a été fait avec JavaScript – le code HTML a été généré par JavaScript, le CSS a été généré par JavaScript, etc. Ceci présente toutes sortes de problèmes d'accessibilité et d'autres choses qui y sont associées, donc ce n'est pas conseillé.

+ +

En plus d'utiliser le bon élément pour le bon travail, vous devez également vous assurer que vous utilisez la bonne technologie pour le bon travail ! Réfléchissez bien pour savoir si vous avez besoin de cette boîte d’informations 3D brillante reposant sur JavaScript, ou si un texte ordinaire avec du CSS conviendrait. Réfléchissez bien pour savoir si vous avez besoin d'un widget de formulaire non standard complexe ou d'une saisie de texte. Et ne générez pas tout votre contenu HTML en utilisant JavaScript si possible.

+ +

Le garder discret

+ +

Lors de la création de votre contenu, gardez à l'esprit l'idée d'un JavaScript discret, en retrait. JavaScript est discret quand il est utilisé pour améliorer des fonctionnalités, il devient gênant quand ces mêmes fonctionnalités sont développées entièrement en JavaScript. Les fonctions de base de votre page devraient idéalement tourner sans JavaScript, même s’il est évident que ce n’est pas toujours possible. La règle est d'utiliser lorsque cela est possible les fonctionnalités intégrées au navigateur.

+ +

De bons exemples d'utilisation de JavaScript discret incluent :

+ + + +

Par exemple, nous avons écrit un exemple de validation de formulaire côté client rapide — voir form-validation.html (voir aussi la démonstration en direct). Ici, vous verrez un formulaire simple. Lorsque vous essayez de soumettre le formulaire avec un ou les deux champs vides, l'envoi échoue et un message d'erreur s'affiche pour vous indiquer ce qui ne va pas.

+ +

Ce type de validation de formulaire est discret — vous pouvez toujours utiliser le formulaire parfaitement sans que le JavaScript soit disponible, et toute implémentation de formulaire sensée aura également une validation côté serveur, car il est trop facile pour les utilisateurs malveillants de contourner la validation côté client (en désactivant JavaScript dans le navigateur, par exemple). La validation côté client est toujours très utile pour signaler les erreurs — les utilisateurs peuvent savoir instantanément quelles erreurs ils commettent, au lieu d'attendre un aller-retour vers le serveur et un rechargement de page. C'est un avantage certain en termes de convivialité.

+ +
+

Note : La validation côté serveur n'a pas été implémentée dans cette simple démonstration.

+
+ +

Nous avons également rendu cette validation de formulaire assez accessible. Nous avons utilisé des éléments {{htmlelement("label")}} pour nous assurer que les libellés des formulaires sont liés de manière non équivoque à leurs entrées, afin que les lecteurs d'écran puissent les lire au fur et à mesure :

+ +
<label for="name"> Entrez votre nom :</label>
+<input type="text" name="name" id="name">
+ +

Nous ne faisons la validation qu'une fois le formulaire soumis — ceci afin de ne pas mettre à jour l'interface utilisateur trop souvent et de ne pas perturber les utilisateurs du lecteur d'écran (et éventuellement d'autres) :

+ +
form.onsubmit = validate;
+
+function validate(e) {
+  errorList.innerHTML = '';
+  for(var i = 0; i < formItems.length; i++) {
+    var testItem = formItems[i];
+    if(testItem.input.value === '') {
+      errorField.style.left = '360px';
+      createLink(testItem);
+    }
+  }
+
+  if(errorList.innerHTML !== '') {
+    e.preventDefault();
+  }
+}
+ +
+

Note :  Dans cet exemple, nous masquons et montrons la boîte de message d'erreur en utilisant le positionnement absolu plutôt qu'une autre méthode telle que la visibilité ou l'affichage, car cela n'empêche pas le lecteur d'écran de pouvoir lire le contenu de celui-ci.

+
+ +

La validation du formulaire réel serait beaucoup plus complexe que cela : vous voudriez vérifier que le nom saisi ressemble réellement à un nom, que l’âge entré est en réalité un nombre et qu’il est réaliste (par exemple, pas un nombre négatif, ni à quatre chiffres). Ici, nous venons d'implémenter la vérification simple qu'une valeur a été renseignée dans chaque champ de saisie (if(testItem.input.value === '')).

+ +

Une fois la validation effectuée, si les tests réussissent, le formulaire est soumis. S'il y a des erreurs  (if(errorList.innerHTML !== ''))  nous arrêtons la soumission du formulaire ( à l'aide de event.preventDefault()), et affichons tous les messages d'erreur créés (voir ci-dessous). Ce mécanisme signifie que les erreurs ne seront affichées que s’il y a des erreurs, ce qui est meilleur pour la facilité d’utilisation.

+ +

Pour chaque entrée pour laquelle aucune valeur n'a été renseignée lors de la soumission du formulaire, nous créons un élément de liste avec un lien et l'insérons dans la liste errorList.

+ +
function createLink(testItem) {
+  var listItem = document.createElement('li');
+  var anchor = document.createElement('a');
+  anchor.textContent = testItem.input.name + ' field is empty: fill in your ' + testItem.input.name + '.';
+  anchor.href = '#' + testItem.input.name;
+  anchor.onclick = function() {
+    testItem.input.focus();
+  };
+  listItem.appendChild(anchor);
+  errorList.appendChild(listItem);
+}
+ +

Chaque lien a un double objectif — il vous dit quelle est l’erreur, vous pouvez aussi cliquer dessus / l’activer pour passer directement à l’élément d’entrée en question et corriger votre saisie.

+ +
+

Note :  La partie focus()  de cet exemple est un peu délicate. Chrome et Edge (et les versions plus récentes d'IE) focalisent l'élément lorsque l'utilisateur clique sur le lien, sans avoir besoin du bloc onclick/focus().  Safari ne mettra en évidence que l'élément de formulaire avec le lien, il a donc besoin du bloc onclick/focus()  pour le focaliser. Firefox ne focalise pas les entrées correctement dans ce contexte, les utilisateurs de Firefox ne peuvent donc pas en profiter pour le moment (bien que tout le reste fonctionne bien). Le problème de Firefox devrait bientôt être résolu - des efforts sont en cours pour donner la parité des comportements de Firefox aux autres navigateurs (voir {{bug(277178)}}).

+
+ +

De plus, le champ errorField est placé en haut de l'ordre source (bien qu'il soit positionné différemment dans UI à l'aide de CSS), ce qui signifie que les utilisateurs peuvent savoir exactement ce qui ne va pas avec les soumissions de formulaire et accéder aux éléments d'entrée en question en remontant au début de la page

+ +

Pour terminer, nous avons utilisé certains attributs de WAI-ARIA dans notre démonstration pour résoudre les problèmes d’accessibilité causés par des zones de contenu constamment mises à jour sans rechargement de page (les lecteurs d’écran ne le détectent pas et n'en avertissent pas les utilisateurs par défaut) :

+ +
<div class="errors" role="alert" aria-relevant="all">
+  <ul>
+  </ul>
+</div>
+ +

Nous expliquerons ces attributs dans notre prochain article, qui couvre WAI-ARIA de manière beaucoup plus détaillée.

+ +
+

Note :  Certains d'entre vous penseront probablement au fait que les formulaires HTML5 ont des mécanismes de validation intégrés tels que les attributs required, min/minlength, et max/maxlength  (voir {{htmlelement("input")}} référence d'élément pour plus d'informations). Nous avons fini par ne pas les utiliser dans la démo, car la prise en charge multi-navigateurs est inégale (par exemple, IE10 et versions ultérieures, pas de prise en charge de Safari).

+
+ +
+

Note : WebAIM's Validation de formulaire et récupération d'erreur utilisables et accessibles (EN) fournit des informations supplémentaires utiles sur la validation de formulaire accessible.

+
+ +

Autres problèmes d'accessibilité JavaScript

+ +

Il y a d'autres choses à prendre en compte quand on met en œuvre des solutions JavaScript tout en réflechissant à l'accessibilité. Voilà déjà une liste de points à surveiller, que nous complèterons à chaque fois qu'un nouveau cas se présente.

+ +

Événements spécifiques à la souris

+ +

Comme vous le savez peut-être, la plupart des interactions utilisateur sont implémentées dans JavaScript côté client à l'aide de gestionnaires d'événements, ce qui nous permet d'exécuter des fonctions en réponse à certains événements. Certains événements peuvent avoir des problèmes d'accessibilité. L'exemple principal que vous rencontrerez concerne des événements spécifiques à la souris tels que  mouseover, mouseout, dblclick, etc. Les fonctionnalités qui s'exécutent en réponse à ces événements ne seront pas accessibles à l'aide d'autres mécanismes, tels que les contrôles du clavier.

+ +

Pour résoudre de tels problèmes, vous devez doubler ces événements avec des événements similaires pouvant être activés par d'autres moyens (appelés gestionnaires d'événements indépendants du périphérique) —focus et blur (event) fourniraient une accessibilité aux utilisateurs de clavier. 

+ +

Regardons un exemple qui illustre cela. Considérons une image miniature ; quand elle est survolée ou ciblée (comme sur un catalogue de produits de commerce électronique) une version plus grande de l’image s'affiche.

+ +

Nous avons créé un exemple très simple, que vous pouvez trouver sur Exemple d'événements de souris et de clavier (voir aussi le code source). Le code comporte deux fonctions qui affichent et cachent l'image agrandie ; ceux-ci sont gérés par les lignes suivantes qui les définissent en tant que gestionnaires d'événements :

+ +
imgThumb.onmouseover = showImg;
+imgThumb.onmouseout = hideImg;
+
+imgThumb.onfocus = showImg;
+imgThumb.onblur = hideImg;
+ +

Les deux premières lignes exécutent les fonctions lorsque le pointeur de la souris survole et cesse de survoler la vignette, respectivement. Cela ne nous permettra toutefois pas d'accéder à la vue agrandie à l'aide du clavier ; pour cela, nous avons inclus les deux dernières lignes, qui exécutent les fonctions lorsque l'image est nette et floue (lorsque la mise au point s'arrête). Cela peut être fait en tapant sur l'image, car nous avons inclus  tabindex="0" dessus.

+ +

L'événement click est intéressant — cela semble dépendre de la souris, mais la plupart des navigateurs activent les gestionnaires d'événement element.onclick  après avoir  pressé Entrée  sur un lien ou un élément de formulaire ciblé, ou lorsqu'un tel élément est touché sur un écran tactile. Cependant, cela ne fonctionne pas par défaut lorsque vous autorisez un événement à ne pas être mis au point par défaut à l'aide de tabindex. Dans ce cas, vous devez détecter précisément le moment exact où cette touche est enfoncée (voir Remettre l'accessibilité au clavier).

+ +

Résumé

+ +

Nous espérons que cet article vous a fourni beaucoup de détails et de compréhension sur les problèmes d'accessibilité liés à l'utilisation de CSS et de JavaScript sur les pages Web.

+ +

Ensuite, WAI-ARIA !

+ +
{{PreviousMenuNext("Learn/Accessibility/HTML","Learn/Accessibility/WAI-ARIA_basics", "Learn/Accessibility")}}
+ +
+

Dans ce module

+ + +
diff --git a/files/fr/apprendre/a11y/html/index.html b/files/fr/apprendre/a11y/html/index.html new file mode 100644 index 0000000000..03b80cbb80 --- /dev/null +++ b/files/fr/apprendre/a11y/html/index.html @@ -0,0 +1,530 @@ +--- +title: 'HTML : une bonne base pour l''accessibilité' +slug: Apprendre/a11y/HTML +tags: + - Accessibilité + - Article + - Clavier + - Débutant + - Forms + - HTML + - Liens + - a11y + - boutons + - sémantique +translation_of: Learn/Accessibility/HTML +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Accessibility/What_is_Accessibility","Learn/Accessibility/CSS_and_JavaScript", "Learn/Accessibility")}}
+ +

Une grande partie des contenus web peut être rendue accessible simplement en s'assurant d'utiliser les éléments HTML appropriés systématiquement. Cet article détaille comment HTML peut être utilisé pour un maximum d'accessibilité.

+ + + + + + + + + + + + +
Prérequis :Compétences informatiques de base, compréhension basique de HTML (voir Introduction à HTML), et compréhension de Qu'est ce que l'accessibilité ?
Objectif :Se familiariser avec les fonctionnalités de HTML qui bénéficient à l'accessibilité, et comment les utiliser de manière appropriée dans vos documents web.
+ +

HTML et accessibilité

+ +

Plus vous apprenez le HTML — plus vous lisez de ressources, regardez d'exemples — plus vous recontrerez un thème récurrent : l'importance d'utiliser du HTML sémantique, parfois appelé POSH (Plain Old Semantic HTML). C'est l'usage des éléments HTML appropriés autant que possible.

+ +

Vous pouvez vous demander pourquoi c'est si important. Après tout, vous pouvez utiliser une combinaison de CSS et de JavaScript pour faire fonctionner n'importe quel élément HTML de la manière que vous souhaitez. Par exemple, un bouton de lecture pour une vidéo sur votre site pourrait être codé ainsi :

+ +
<div>Lire la vidéo</div>
+ +

Mais comme vous le verrez en détail plus loin, il est beaucoup plus sensé d'utiliser le bon élément à cet effet :

+ +
<button>Lire la vidéo</button>
+ +

Non seulement  <button> possède des styles adéquats par défaut (que vous voudrez probablement surcharger), il intègre aussi l'accès au clavier — on peut tabuler dessus, et l'activer avec la touche entrée.

+ +

Le HTML sémantique ne demande pas plus de temps à écrire que du (mauvais) balisage non-sémantique si vous le faites de manière constante dès le début de votre projet, et il a également des bénéfices au delà de l'accessibilité :

+ +
    +
  1. Facilite les développements — comme mentionné ci-dessus, certaines fonctionnalités sont gratuites, et c'est indiscutablement plus compréhensible.
    2. +
  2. Meilleur pour le mobile — le HTML sémantique est indiscutablement plus léger en la taille du fichier que le code spaghetti non sémantique, et plus aisé à rendre responsive. 
    3. +
  3. Bon pour le SEO — les moteurs de recherche donnent plus d'importance aux mots clés contenus dans les titres, liens, etc. que des mots-clés contenus dans des <div> non sémantiques, et donc vos documents seront plus facilement trouvés par vos clients.
    4. +
+ +

Continuons et jetons un œil au HTML accessible dans le détail.

+ +
+

Note : C'est une bonne idée d'avoir un lecteur d'écran configuré, pour tester les exemples ci-dessous. Voir notre guide pour gérer les problèmes courants d'accessibilité pour plus de détails.

+
+ +

Une bonne sémantique

+ +

Nous avons déjà parlé de l'importance d'une bonne sémantique, et pourquoi nous devons utiliser le bon élément HTML pour le bon usage. Il ne faut pas l'ignorer car c'est une des principales causes d'importants problèmes d'accessibilité si ce n'est pas fait correctement.

+ +

En vérité sur le Web, les développeurs font d'étranges choses avec HTML. Certains abus en HTML sont hérités de vieilles pratiques obsolètes pas complètement oubliées, d'autre sont juste de l'ignorance. Dans tous les cas, vous devez remplacer ce mauvais code partout où vous le verrez, dès que vous le pourrez.

+ +

Parfois vous ne pourrez pas vous débarrasser du mauvais balisage — vos pages seront générées par quelque framework côté serveur dont vous n'aurez pas le contrôle total, ou vous aurez des contenus tiers (comme des bannières publicitaires) que nous ne contrôlerez pas.

+ +

L'objectif cependant n'est pas « tout ou rien » — toute amélioration que vous pouvez faire aidera la cause de l'accessibilité.

+ +

Contenus textuels

+ +

L'une des meilleures aides en accessibilité qu'un utilisateur de lecteur d'écran peut avoir est une bonne structure des titres, paragraphes, listes, etc. Un bon exemple sémantique devrait ressembler au code suivant :

+ +
<h1>Mon titre</h1>
+
+<p>Ceci est la premère section de mon document.</p>
+
+<p>Je vais ajouter ici un autre paragraphe.</p>
+
+<ol>
+  <li>Voici</li>
+  <li>une liste pour</li>
+  <li>toi à lire.</li>
+</ol>
+
+<h2>Mon sous-titre</h2>
+
+<p>Ceci est la première sous-section de mon document. J'aurais aimé que les gens puissent trouver ce contenu!</p>
+
+<h2>Mon second sous-titre</h2>
+
+<p>Ceci est la seconde sous-section de mon document. Je pense qu'elle est plus intéressante que la dernière.</p>
+ +

Nous avons préparé pour vous une version avec un texte plus long afin de l'essayer avec lecteur d'écran (voir la bonne sémantique). Si vous essayez de naviguer dans ce document, vous verrez qu'il est assez simple de s'y retrouver :

+ +
    +
  1. Le lecteur d'écran lit à voix haute chaque élément au fur et à mesure que vous progressez dans le contenu, vous notifiant ce qui est un paragraphe, ce qui est un titre, etc.
    2. +
  2. Il s'arrête après chaque élément, vous laissant aller à n'importe quel endroit vous convenant.
    3. +
  3. Vous pouvez sauter au précédent ou au prochain titre avec de nombreux lecteurs d'écran.
    4. +
  4. Vous pouvez aussi dresser une liste de tous les titres avec de nombreux lecteurs d'écrans, vous permettant de les utiliser comme une table des matières pratique pour trouver un contenu spécifique.
    5. +
+ +

Les gens écrivent parfois des titres, des paragraphes, etc. utilisant le HTML de présentation et retours à la ligne, quelque chose comme ce qui suit :

+ +
<font size="7">Mon titre</font>
+<br><br>
+Ceci est la première section de mon document.
+<br><br>
+Je vais ajouter ici un autre paragraphe.
+<br><br>
+1. Voici
+<br><br>
+2. une liste pour
+<br><br>
+3. toi à lire.
+<br><br>
+<font size="5">Mon sous-titre</font>
+<br><br>
+<p>Ceci est la première sous-section de mon document. J'aurais aimé que les gens puissent trouver ce contenu!
+<br><br>
+<font size="5">My 2nd subheading</font>
+<br><br>
+Ceci est la seconde sous-section de mon document. Je pense qu'elle est plus intéressante que la dernière.
+ +

Si vous essayez notre version plus longue avec un lecteur d'écran (voir la mauvaise sémantique), vous n'aurez pas une très bonne expérience – le lecteur d'écran n'a plus rien à utiliser comme indicateur, il ne peut pas récupérer une table des matières utilisable, et la page entière est vue comme un bloc unique, lu tout d'une traite.

+ +

Il y a aussi d'autres problèmes au-delà de l'accessibilité – le contenu est plus dur à mettre en forme avec le CSS, ou à manipuler avec JavaScript par exemple, car il n'y a pas d'élément à utiliser comme sélecteurs.

+ +

Utiliser un langage clair

+ +

Le langage que vous employez peut aussi affecter l'accessiblité. En général vous ne devriez pas utiliser un langage trop complexe, ni utiliser un jargon ou de l'argot inutiles. Cela ne profite pas qu'aux gens avec des handicaps congnitifs ou autres ; cela profite au lecteur pour qui le texte n'est pas écrit dans sa langue maternelle, pour des gens plus jeunes… à tout un chacun en fait ! Mis à part cela, vous devriez essayer d'éviter d'utiliser un langage et des caractères qui ne sont pas lus clairement à voix haute par le lecteur d'écran. Par exemple :

+ + + +

Disposition des pages

+ +

Dans les âges sombres, les gens avaient pour habitude de créer les dispositions de leurs pages avec des tableaux HTML — en utilisant différentes cellules de ces tableaux pour contenir l'en-tête, le pied de page, une barre latérale, la colonne du contenu principal, etc. Ce n'est pas une bonne idée car un lecteur d'écran va donner des lectures déroutantes, surtout si la disposition est complexe et a de nombreux tableaux imbriqués.

+ +

Essayez notre exemple table-layout.html, qui ressemble à quelque chose comme ça :

+ +
<table width="1200">
+      <!-- main heading row -->
+      <tr id="heading">
+        <td colspan="6">
+
+          <h1 align="center">Header</h1>
+
+        </td>
+      </tr>
+      <!-- nav menu row  -->
+      <tr id="nav" bgcolor="#ffffff">
+        <td width="200">
+          <a href="#" align="center">Home</a>
+        </td>
+        <td width="200">
+          <a href="#" align="center">Our team</a>
+        </td>
+        <td width="200">
+          <a href="#" align="center">Projects</a>
+        </td>
+        <td width="200">
+          <a href="#" align="center">Contact</a>
+        </td>
+        <td width="300">
+          <form width="300">
+            <input type="search" name="q" placeholder="Search query" width="300">
+          </form>
+        </td>
+        <td width="100">
+          <button width="100">Go!</button>
+        </td>
+      </tr>
+      <!-- spacer row -->
+      <tr id="spacer" height="10">
+        <td>
+
+        </td>
+      </tr>
+      <!-- main content and aside row -->
+      <tr id="main">
+        <td id="content" colspan="4" bgcolor="#ffffff">
+
+          <!-- main content goes here -->
+        </td>
+        <td id="aside" colspan="2" bgcolor="#ff80ff" valign="top">
+          <h2>Related</h2>
+
+          <!-- aside content goes here -->
+
+        </td>
+      </tr>
+      <!-- spacer row -->
+      <tr id="spacer" height="10">
+        <td>
+
+        </td>
+      </tr>
+      <!-- footer row -->
+      <tr id="footer" bgcolor="#ffffff">
+        <td colspan="6">
+          <p>©Copyright 2050 by nobody. All rights reversed.</p>
+        </td>
+      </tr>
+    </table>
+ +

Si vous essayez de naviguer à l'aide d'un lecteur d'écran, cela vous indiquera probablement qu'il existe un tableau à examiner (bien que certains lecteurs d'écran puissent deviner la différence entre les présentations de tableau et les tableaux de données). Vous devrez ensuite (en fonction du lecteur d’écran que vous utilisez) devoir accéder à la table en tant qu’objet et en examiner les caractéristiques séparément, puis sortir à nouveau de la table pour continuer à naviguer dans le contenu.

+ +

Les structures de table sont un vestige du passé – elles semblaient logiques lorsque le support CSS n’était pas répandu dans les navigateurs, mais elles semaient la confusion chez les utilisateurs de lecteurs d’écran, tout en étant mauvaises pour de nombreuses autres raisons (utilisation abusive des tableaux, nécessite plus de balisage, design manquant de souplesse). Ne les utilisez pas !

+ +

Vous pouvez vérifier ces affirmations en comparant votre expérience antérieure avec un  exemple plus moderne de structure de site Web, qui pourrait ressembler à ceci :

+ +
<header>
+  <h1>Entête</h1>
+</header>
+
+<nav>
+  <!--  navigation principale ici  -->
+</nav>
+
+<!--  Voici le contenu principal de notre page  -->
+<main>
+
+  <!--  Il contient un article  -->
+  <article>
+    <h2>Intitulé de l'article</h2>
+
+    <!--  contenu de l'article ici  -->
+  </article>
+
+  <aside>
+    <h2>en relation</h2>
+
+    <!--  à part le contenu ici  -->
+  </aside>
+
+</main>
+
+<!--  Et voici notre pied de page principal utilisé dans toutes les pages de notre site Web. -->
+
+<footer>
+  <!--  contenu du pied de page ici  -->
+</footer>
+ +

Si vous essayez notre exemple plus moderne de structure avec un lecteur d’écran, vous verrez que le balisage de présentation ne gêne plus ni ne rend la lecture du contenu confuse. Il est également beaucoup plus léger et plus petit en termes de taille de code, ce qui signifie une maintenance plus facile du code et une sollicitation moindre de la bande passante par l'utilisateur (particulièrement critique en cas de connexions lentes).

+ +

Une autre considération à prendre en compte lors de la création de dispositions consiste à utiliser des éléments sémantiques HTML5 comme dans l'exemple ci-dessus (voir Référence des éléments HTML). Vous pouvez créer une disposition en utilisant uniquement des éléments {{htmlelement("div")}} imbriqués, mais il est préférable d'utiliser des éléments de sectionnement appropriés pour envelopper votre navigation principale ({{htmlelement("nav")}}), footer ({{htmlelement("footer")}}), en répétant des unités de contenu ({{htmlelement("article")}}), etc. Elles fournissent une sémantique supplémentaire aux lecteurs d’écran (et à d’autres outils) pour donner à l’utilisateur des indices supplémentaires sur le contenu qu’il navigue (voir Prise en charge du lecteur d’écran pour les nouveaux éléments de section HTML5 pour une idée de la prise en charge du lecteur d’écran).

+ +
+

Note : Outre le fait que votre contenu présente une bonne sémantique et une présentation attrayante, il convient que son ordre source soit logique : vous pouvez toujours le placer où vous le souhaitez à l'aide de CSS par la suite, mais vous devez définir l'ordre exact des sources pour commencer. les utilisateurs de lecteur d’écran qui se liront auront du sens.

+
+ +

Contrôles de l'interface utilisateur

+ +

Par contrôles d'interface utilisateur, nous entendons les parties principales des documents web avec lesquelles les utilisateurs interagissent – le plus souvent des boutons, des liens et des contrôles de formulaire. Dans cette section, nous examinerons les problèmes d’accessibilité de base à prendre en compte lors de la création de tels contrôles. Des articles ultérieurs sur WAI-ARIA et le multimédia aborderont d'autres aspects de l'accessibilité de l'interface utilisateur.

+ +

L'un des aspects clés de l'accessibilité des contrôles de l'interface utilisateur est que, par défaut, les navigateurs leur permettent d'être manipulés par le clavier. Vous pouvez essayer ceci en utilisant notre exemple accessibilité du clavier natif (voir le code source) – ouvrez-le dans un nouvel onglet et essayez d’appuyer sur la touche de tabulation; après quelques appuis, vous devriez voir le focus de l'onglet commencer à se déplacer à travers les différents éléments qui peuvent être mis au point ; les éléments focalisés se voient attribuer un style par défaut en surbrillance dans chaque navigateur (il diffère légèrement d’un navigateur à l’autre) afin que vous puissiez déterminer quel élément est ciblé.

+ +

+ +

Vous pouvez ensuite appuyer sur Entrée/Retour pour suivre un lien sélectionné ou appuyer sur un bouton (nous avons inclus du JavaScript pour que les boutons alertent un message), ou commencer à taper pour saisir du texte dans une entrée de texte (les autres éléments de formulaire ont des contrôles différents, par exemple, l'élément  {{htmlelement("select")}} peut avoir ses options affichées et alterner entre les touches fléchées haut et bas). 

+ +
+

Note :  Différents navigateurs peuvent avoir différentes options de contrôle du clavier disponibles. Voir comment gérer les problèmes courants d'accessibilité pour plus de détails.

+
+ +

Vous obtenez essentiellement ce comportement gratuitement, en utilisant simplement les éléments appropriés, par exemple :

+ +
<h1>Liens</h1>
+
+<p> Ceci est un lien vers  <a href="https://www.mozilla.org">Mozilla</a>.</p>
+
+<p> Un autre lien, pour  <a href="https://developer.mozilla.org">Mozilla Developer Network</a>.</p>
+
+<h2>Boutons</h2>
+
+<p>
+  <button data-message="This is from the first button">Cliquez moi!</button>
+  <button data-message="This is from the second button"> Cliquez moi aussi !</button>
+  <button data-message="This is from the third button">Et moi!</button>
+</p>
+
+<h2>formulaire</h2>
+
+<form>
+  <div>
+    <label for="name"> Remplis ton nom :</label>
+    <input type="text" id="name" name="name">
+  </div>
+  <div>
+    <label for="age"> Entrez votre âge :</label>
+    <input type="text" id="age" name="age">
+  </div>
+  <div>
+    <label for="mood"> Choisissez votre humeur :</label>
+    <select id="mood" name="mood">
+      <option>Heureux</option>
+      <option> Triste </option>
+      <option> Fâché </option>
+      <option> Préoccupé </option>
+    </select>
+  </div>
+</form>
+ +

Cela signifie que vous devez utiliser des liens, des boutons, des éléments de formulaire et des étiquettes de manière appropriée (y compris l'élément {{htmlelement("label")}} pour les contrôles de formulaire).

+ +

Cependant, il est encore une fois que les gens font parfois des choses étranges avec HTML. Par exemple, vous voyez parfois des boutons balisés en utilisant {{htmlelement("div")}}s, par exemple :

+ +
<div data-message="This is from the first button"> Cliquez-moi!</div>
+<div data-message="This is from the second button">  Cliquez moi aussi!</div>
+<div data-message="This is from the third button"> Et moi!</div>
+ +

Il est toutefois déconseillé d’utiliser un tel code. Vous perdriez immédiatement l’accessibilité au clavier natif que vous auriez obtenue si vous aviez utilisé des éléments  {{htmlelement("button")}}. De plus, vous n’obtenez aucun des styles CSS par défaut que les boutons ont.

+ +

Remettre l'accessibilité au clavier

+ +

Ajouter de tels avantages en retour demande un peu de travail (vous pouvez utiliser un exemple de code dans notre exemple fake-div-buttons.html – voir également le source code). Ici, nous avons donné à nos faux boutons <div> la possibilité se focaliser (y compris via la touche Tab) en donnant à chacun l'attribut tabindex="0" :

+ +
<div data-message="This is from the first button" tabindex="0"> Cliquez-moi!</div>
+<div data-message="This is from the second button" tabindex="0"> Cliquez moi aussi!</div>
+<div data-message="This is from the third button" tabindex="0"> Et moi!</div>
+ +

Fondamentalement, l'attribut {{htmlattrxref("tabindex")}} est principalement destiné à permettre aux éléments que l'on peut cibler avec la touche Tab d'avoir un ordre de tabulation personnalisé (spécifié dans l'ordre numérique positif), au lieu d'être simplement tabulés dans leur ordre source par défaut. C'est presque toujours une mauvaise idée, car cela peut causer une confusion majeure. Utilisez-le uniquement si vous en avez vraiment besoin, par exemple si la mise en page affiche les éléments dans un ordre visuel très différent de celui du code source et si vous souhaitez que les éléments fonctionnent de manière plus logique. Il y a deux autres options pour tabindex :

+ + + +

Bien que l’addition ci-dessus nous permette de tabuler les boutons, elle ne nous permet pas de les activer via la touche Entrée/Retour. Pour ce faire, nous avons dû ajouter le bout de code JavaScript suivant :

+ +
document.onkeydown = function(e) {
+  if(e.keyCode === 13) { // The Enter/Return key
+    document.activeElement.onclick(e);
+  }
+}
+ +

Ici, nous ajoutons un écouteur à l’objet document pour détecter le moment où un bouton a été appuyé sur le clavier. Nous vérifions quel bouton a été pressé via la propriété keyCode de l'objet événement; s'il s'agit du code clé qui correspond Return/Enter, nous exécutons la fonction stockée dans le gestionnaire du bouton onclick à l'aide de document.activeElement.onclick(). activeElement nous donne l'élément qui est actuellement ciblé sur la page.

+ +
+

Note : N'oubliez pas que cette technique ne fonctionnera que si vous définissez vos gestionnaires d'événements d'origine via les propriétés du gestionnaire d'événements (par exemple, onclick), addEventListener ne fonctionnera pas.

+
+ +

C’est beaucoup de tracas supplémentaire pour reconstruire la fonctionnalité. Et il y aura sûrement d’autres problèmes. Mieux vaut utiliser le bon élément pour le bon travail en premier lieu.

+ +

Étiquettes de texte significatives

+ +

Les étiquettes de texte de contrôle UI sont très utiles pour tous les utilisateurs, mais leur mise au point est particulièrement importante pour les utilisateurs handicapés.

+ +

Vous devez vous assurer que les libellés des boutons et des liens sont compréhensibles et distinctifs. Ne vous contentez pas d'utiliser « Cliquez ici » pour vos étiquettes, car les utilisateurs et utilisatrices de lecteur d'écran créent parfois une liste de boutons et de contrôles de formulaire. La capture d'écran suivante montre nos commandes répertoriées par VoiceOver sur Mac.

+ +

+ +

Assurez-vous que vos étiquettes ont une signification hors contexte, qu'elles soient lues séparément ou dans le contexte du paragraphe dans lequel elles se trouvent. Par exemple, voici un exemple de texte de lien de qualité :

+ +
<p> Les baleines sont vraiment des créatures géniales . <a href="whales.html"> En savoir plus sur les baleines </a>.</p>
+ +

c'est un mauvais texte du lien :

+ +
<p> Les baleines sont des créatures vraiment impressionnantes. Pour en savoir plus sur les baleines,  <a href="whales.html">cliquez ici</a>.</p>
+
+ +
+

Note:Vous pouvez trouver beaucoup plus d'informations sur l'implémentation de liens et les meilleures pratiques dans notre article sur la création d'hyperliens. Vous pouvez également voir quelques bons et mauvais exemples dans Bons-liens.html et Mauvais-liens.html.

+
+ +

Les libellés de formulaire sont également importantes pour vous donner un indice sur ce que vous devez entrer dans chaque entrée de formulaire. Ce qui suit semble être un exemple assez raisonnable :

+ +
 Remplis ton nom : <input type="text" id="name" name="name">
+ +

Cependant, ce n'est pas très utile pour les utilisateurs handicapés. Dans l'exemple ci-dessus, rien n'associe de manière non équivoque l'étiquette à la saisie de formulaire et explique clairement comment la remplir si vous ne la voyez pas. Si vous y accédez avec certains lecteurs d’écran, vous ne recevrez peut-être qu’une description du type « éditer le texte".

+ +

Ce qui suit est un exemple bien meilleur :

+ +
<div>
+  <label for="name">Entrez votre nom:</label>
+  <input type="text" id="name" name="name">
+</div>
+ +

Avec le code comme celui-ci, le label sera clairement associée à input; la description ressemblera davantage à "Entrez votre nom: éditez le texte".

+ +

+ +

En prime, dans la plupart des navigateurs, associer a un label à une form input signifie que vous pouvez cliquer sur celle-ci pour sélectionner / activer l'élément label. Cela donne à input une zone de résultats plus grande, ce qui facilite la sélection

+ +
+

Note:vous pouvez voir des exemples de bonnes et de mauvaises de formulaire dans exemple de bon formulaire et exemple de mauvais formulaire.

+
+ +

Tableaux de données accessibles

+ +

Une table de données de base peut être écrite avec un balisage très simple, par exemple :

+ +
<table>
+  <tr>
+    <td>Nom</td>
+    <td>Age</td>
+    <td>Sexe</td>
+  </tr>
+  <tr>
+    <td>Gabriel</td>
+    <td>13</td>
+    <td>Male</td>
+  </tr>
+  <tr>
+    <td>Elva</td>
+    <td>8</td>
+    <td>Femelle</td>
+  </tr>
+  <tr>
+    <td>Freida</td>
+    <td>5</td>
+    <td>Femelle</td>
+  </tr>
+</table>
+ +

Mais cela pose des problèmes : un utilisateur de lecteur d’écran ne peut pas associer des lignes ou des colonnes en tant que groupes de données. Pour ce faire, vous devez savoir quelles sont les lignes d'en-tête et si elles sont dirigées vers le haut, des colonnes, etc. Cela ne peut être fait que visuellement pour le tableau ci-dessus (voir bad-table.html et essayez vous-même l'exemple).

+ +

Regardez maintenant notre tableau d'exemple sur les groupes punk – vous pouvez voir quelques aides à l'accessibilité au travail ici :

+ + + +
+

Note : voir notre article  Tableaux HTML : dispositions avancées et accessibilité pour plus de détails sur les tables de données accessibles.

+
+ +

Alternatives textuelles

+ +

Alors que le contenu textuel est intrinsèquement accessible, il n'en est pas de même pour le contenu multimédia : le contenu image/vidéo ne peut pas être vu par les personnes malvoyantes et le contenu audio ne peut pas être entendu par les malentendants. Nous verrons plus loin le contenu audio et vidéo dans l'article multimédia accessible, mais pour cet article, nous examinerons l'accessibilité pour l'élément humble {{htmlelement("img")}}.

+ +

Nous avons un exemple simple écrit, accessible-image.html, comporte quatre copies de la même image :

+ +
<img src="dinosaur.png">
+
+<img src="dinosaur.png"
+     alt=" Un Tyrannosaure Rex rouge: Un dinosaure à deux pattes se tenant droit comme un humain, avec de petits bras et une grosse tête avec beaucoup de dents acérées.">
+
+<img src="dinosaur.png"
+     alt=" Un Tyrannosaure Rex rouge: Un dinosaure à deux pattes se tenant droit comme un humain, avec de petits bras et une grosse tête avec beaucoup de dents acérées."
+     title=" Le dinosaure rouge de Mozilla ">
+
+
+<img src="dinosaur.png" aria-labelledby="dino-label">
+
+<p id="dino-label"> Tyrannosaure rouge Rex de Mozilla: Dinosaure à deux jambes, debout comme un être humain, avec des armes légères et une grosse tête avec beaucoup de dents acérées.</p>
+
+ +

La première image, lorsqu'elle est visualisée par un lecteur d'écran, n'offre pas beaucoup d'aide à l'utilisateur. VoiceOver, par exemple, lit « /dinosaur.png, image ». Il lit le nom du fichier pour essayer de fournir de l'aide. Dans cet exemple, l'utilisateur ou l’utilisatrice saura au moins qu'il s'agit d'un dinosaure, mais les fichiers peuvent souvent être chargés avec des noms de fichiers générés par une machine (par exemple, à partir d'un appareil photo numérique) et ces noms de fichiers ne fourniront probablement aucun contexte au contenu de l'image.

+ +
+

Note: c'est pourquoi vous ne devriez jamais inclure de contenu textuel dans une image. Les lecteurs d'écran ne peuvent tout simplement pas y accéder. Il y a aussi d'autres inconvénients - vous ne pouvez pas le sélectionner et le copier/coller. Juste ne le faite pas !

+
+ +

Quand un lecteur d'écran rencontre la deuxième image, il lit l'intégralité de l'attribut alt – « Un Tyrannosaure Rex rouge : Un dinosaure à deux pattes se tenant droit comme un humain, avec des armes de petit calibre et une grosse tête avec beaucoup de dents acérées. »

+ +

Cela met en évidence l’importance non seulement d’utiliser des noms de fichiers significatifs au cas où ce qui est appelé alt text n’est pas disponible, mais aussi de s’assurer que le texte alternatif est fourni dans les attributs alt chaque fois que possible. Notez que le contenu de l'attribut alt doit toujours fournir une représentation directe de l'image et de ce qu'elle transmet visuellement. Aucune connaissance personnelle ou description supplémentaire ne devrait être incluse ici, car elle n’est pas utile pour les personnes qui n’ont jamais rencontré l’image auparavant.

+ +

Une chose à considérer est de savoir si vos images ont une signification dans votre contenu, ou si elles sont purement décoratives, n’ont donc aucune signification. S'ils sont décoratifs, il est préférable de les inclure dans la page en tant qu'images d'arrière-plan CSS.

+ +
+

Note : Lisez Les images en HTML et Images adaptatives pour plus d’informations sur la mise en œuvre des images et les meilleures pratiques.

+
+ +

Si vous souhaitez fournir des informations contextuelles supplémentaires, vous devez les insérer dans le texte entourant l'image ou dans un attribut title, comme indiqué ci-dessus. Dans ce cas, la plupart des lecteurs d’écran liront le texte alternatif, l’attribut title et le nom du fichier. En outre, les navigateurs affichent le texte du titre sous forme d’infos lors du survol de la souris.

+ +

+ +

Jetons un autre coup d'oeil à la quatrième méthode :

+ +
<img src="dinosaur.png" aria-labelledby="dino-label">
+
+<p id="dino-label"> Le Tyrannosaure rouge Mozilla  ... </p>
+ +

Dans ce cas, nous n'utilisons pas du tout l'attribut alt Nous avons plutôt présenté notre description de l'image sous forme de paragraphe de texte normal, en lui attribuant un id puis nous avons utilisé l'attribut aria-labelledby pour : faire référence à cela id, ce qui amène les lecteurs d’écran à utiliser ce paragraphe comme alt text/label pour cette image. Ceci est particulièrement utile si vous souhaitez utiliser le même texte comme étiquette pour plusieurs images – quelque chose qui n’est pas possible avec alt.

+ +
+

Note: aria-labelledby fait partie de la spécification WAI ARIA, qui permet aux développeurs d'ajouter une sémantique supplémentaire à leur balisage afin d'améliorer l'accessibilité du lecteur d'écran, le cas échéant. Pour en savoir plus sur son fonctionnement, lisez notre article WAI-ARIA basic.

+
+ +

Autres mécanismes alternatifs de texte

+ +

Les images ont également d'autres mécanismes disponibles pour fournir un texte descriptif. Par exemple, il existe un attribut longdesc destiné à pointer sur un document web distinct contenant une description étendue de l'image, par exemple :

+ +

+<img src="dinosaur.png" longdesc="dino-info.html">
+ +

Cela semble être une bonne idée, en particulier pour les infographies telles que les grands graphiques contenant de nombreuses informations, qui pourraient peut-être être représentées sous forme de tableau de données accessible (voir section précédente). Cependant, longdesc n’est pas toujours pris en charge par les lecteurs d’écran et le contenu est totalement inaccessible aux utilisateurs autres que les lecteurs d’écran. Il est sans doute préférable d’inclure la description longue sur la même page que l’image, ou d’y accéder par un lien régulier.

+ +

HTML5 comprend deux nouveaux éléments  — {{htmlelement("figure")}} et {{htmlelement("figcaption")}} — qui sont supposés associer une figure quelconque (ce peut être n'importe quoi, pas nécessairement une image) à une légende de figure :

+ +
<figure>
+  <img src="dinosaur.png" alt=" Le Mozilla Tyrannosaurus ">
+  <figcaption> Un Tyrannosaure Rex rouge: Un dinosaure à deux pattes se tenant droit comme un humain, avec de petits bras et une grosse tête avec beaucoup de dents acérées .</figcaption>
+</figure>
+ +

Malheureusement, la plupart des lecteurs d’écran ne semblent pas encore associer de légendes à leurs figures, mais la structure des éléments est utile pour le style CSS. Elle permet également de placer une description de l’image à côté de la source.

+ +

Attributs alt vides

+ +

+<h3>
+  <img src="article-icon.png" alt="">
+   Tyrannosaurus Rex: le roi des dinosaures 
+</h3>
+ +

Il peut arriver qu'une image soit incluse dans la conception d'une page, mais son objectif principal est la décoration visuelle. Vous remarquerez dans l'exemple de code ci-dessus que l'attribut  alt de l'image est vide – il s'agit pour que les lecteurs d'écran reconnaissent l'image, mais n'essayent pas de décrire l'image (au lieu de cela, ils diraient simplement « image », ou similaire) .

+ +

La raison d'utiliser un vide alt au lieu de ne pas l'inclure est due au fait que de nombreux lecteurs d'écran annoncent l'URL complète de l'image si aucun alt n'est fourni. Dans l'exemple ci-dessus, l'image agit comme une décoration visuelle de l'en-tête auquel elle est associée. Dans ce cas, et dans les cas où une image est uniquement une décoration et n'a pas de valeur de contenu, vous devez mettre un vide alt sur vos images. Une autre alternative consiste à utiliser l'attribut aria role role = "presentation" – cela empêche également les lecteurs d'écrans de lire du texte alternatif.

+ +
+

Note : si possible, vous devriez utiliser CSS pour afficher des images qui ne sont que des décorations.

+
+ +
+

Résumé

+
+ +

Vous devriez maintenant bien connaître l'écriture HTML accessible pour la plupart des cas. Notre article sur les bases de WAI-ARIA comblera également certaines lacunes dans cette connaissance, mais cet article s’occupe des bases. Ensuite, nous allons explorer CSS et JavaScript, et comment l’accessibilité est affectée par leur bon ou mauvais usage.

+ +

{{PreviousMenuNext("Learn/Accessibility/What_is_Accessibility","Learn/Accessibility/CSS_and_JavaScript", "Learn/Accessibility")}}

diff --git a/files/fr/apprendre/a11y/index.html b/files/fr/apprendre/a11y/index.html new file mode 100644 index 0000000000..23ff90513d --- /dev/null +++ b/files/fr/apprendre/a11y/index.html @@ -0,0 +1,56 @@ +--- +title: Accessibilité +slug: Apprendre/a11y +tags: + - ARIA + - Accessibilité + - Apprendre + - CSS + - Débutant + - HTML + - JavaScript +translation_of: Learn/Accessibility +--- +
{{LearnSidebar}}
+ +

Apprendre le HTML, le CSS et le JavaScript est utile si vous voulez devenir développeur web, mais vos connaissances devront aller au delà de la simple utilisation des technologies — vous devrez les utiliser de manière responsable, de la bonne manière, de façon à maximiser l'audience de vos sites web et ne priver personne de leur usage. Pour y parvenir, vous devrez respecter les bonnes pratiques (lesquelles sont démontrées à travers les sujets du HTML, du CSS et du JavaScript), effectuer des tests sur les différents navigateurs et prendre l'accessibilité en considération dès le départ. Dans ce module, nous allons traiter de cette dernière en détail.

+ +

Prérequis

+ +

Pour tirer le meilleur parti de ce module, il serait judicieux de parcourir les sections relatives à HTML, CSS et JavaScript en premier (au moins les deux premiers modules de chacune de ces sections) ou, peut-être encore mieux, de travailler les parties pertinentes du module d'accessibilité au fur et à mesure que vous travaillez les sujets technologiques connexes.

+ +
+

Note : Si vous travaillez sur un ordinateur, une tablette ou un autre appareil sur lequel vous n'avez pas la possibilité de créer vos propres fichiers, vous pouvez essayer la plupart des exemples de code dans un programme de code en ligne tel que JSBin ou Thimble.

+
+ +

Guides

+ +
+
Qu'est-ce que l'accessibilité ?
+
Cet article amorce le module avec un bon aperçu de ce qu'est réellement l'accessibilité – cela inclut les groupes de personnes que nous devons considérer et pourquoi, quels outils les différentes personnes utilisent pour interagir avec le Web et comment nous pouvons intégrer l'accessibilité dans le processus de développement web.
+
HTML : une bonne base pour l'accessibilité
+
Une grande partie du contenu web peut être rendue accessible simplement lorsqu'on utilise les bons éléments HTML dans les bons cas. Cet article examine en détail comment HTML peut être utilisé pour assurer une accessibilité maximale.
+
Meilleures pratiques d'accessibilité CSS et JavaScript
+
Lorsqu'ils sont utilisés correctement, CSS et JavaScript peuvent permettre des expériences web accessibles… mais ils peuvent considérablement nuire à l'accessibilité s'ils sont mal utilisés. Cet article décrit certaines pratiques exemplaires pour CSS et JavaScript qui doivent être prises en compte afin de s'assurer que le contenu, même complexe, soit le plus accessible possible.
+
Principes de base du WAI-ARIA
+
À la suite de l'article précédent, il est parfois compliqué de créer des contrôles complexes et accessible pour une interface utilisateur qui contient du HTML non sémantique et du contenu dynamique mis à jour grâce à JavaScript. WAI-ARIA est une technologie qui peut aider à résoudre de tels problèmes en ajoutant une sémantique supplémentaire que les navigateurs et les technologies d'assistance peuvent reconnaître et utiliser afin de permettre aux utilisateurs de savoir ce qui se passe. Nous allons montrer ici comment l'utiliser, à un niveau basique, pour améliorer l'accessibilité.
+
Accessibilité pour les contenus multimédias
+
Un autre type de contenu susceptible de créer des problèmes d'accessibilité est le multimédia : les contenus vidéo, audio et les image doivent être dotés de textes alternatifs appropriés afin qu'ils puissent être compris par les technologies d'assistance et leurs utilisateurs. Cet article montre comment.
+
Accessibilité mobile
+
On accède désormais au Web depuis son smartphone. Les plateformes iOS et Android possèdent des outils d'accessibilité à part entière. Il est tout aussi important de prendre en compte l'accessibilité de votre contenu web sur ces plateformes. Cet article examine les considérations d'accessibilité spécifiques au mobile.
+
+ +

Évaluations

+ +
+
Diagnostic et amélioration de l'accessibilité
+
Dans ce module d'évaluation, nous vous présentons un site simple comportant un certain nombre de problèmes d'accessibilité que vous devez diagnostiquer et corriger.
+
+ +

Voir aussi

+ + diff --git a/files/fr/apprendre/a11y/mobile/index.html b/files/fr/apprendre/a11y/mobile/index.html new file mode 100644 index 0000000000..6fd7b657d1 --- /dev/null +++ b/files/fr/apprendre/a11y/mobile/index.html @@ -0,0 +1,311 @@ +--- +title: Accessibilité mobile +slug: Apprendre/a11y/Mobile +tags: + - Accessibilité + - Article + - Débutant + - Mobile + - responsive + - toucher +translation_of: Learn/Accessibility/Mobile +--- +
+
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Accessibility/Multimedia","Learn/Accessibility/Accessibility_troubleshooting", "Learn/Accessibility")}}
+ +

L'accès Web sur les appareils mobiles étant si populaire et les plates-formes populaires telles qu'IOS et Android disposant d'outils d'aide à l'accessibilité complets, il est important de prendre en compte l'accessibilité de votre contenu Web sur ces plates-formes. Cet article examine les considérations relatives à l'accessibilité spécifiques aux mobiles.

+ + + + + + + + + + + + +
Prerequisites:Connaissances de base en informatique, compréhension de base de HTML, CSS et JavaScript et compréhension de la  previous articles in the course.
Objective:Comprendre quels problèmes d'accessibilité existent sur les appareils mobiles et comment les résoudre.
+ +

Accessibilité sur les appareils mobiles

+ +

L’état de l’accessibilité - et la prise en charge des normes Web en général - est bon pour les appareils mobiles modernes. Le temps où les appareils mobiles utilisaient des technologies Web complètement différentes des navigateurs de bureau, forçait les développeurs à utiliser le sniffing de navigateur et à leur servir des sites complètement séparés (même si de nombreuses entreprises détectent encore l'utilisation d'appareils mobiles et leur servent un domaine distinct).

+ +

De nos jours, les appareils mobiles en général peuvent gérer des sites Web "complets", et les principales plates-formes ont même des lecteurs d'écran intégrés pour permettre aux utilisateurs malvoyants de les utiliser avec succès. Les navigateurs mobiles modernes ont tendance à avoir un bon support pour  WAI-ARIA, aussi

+ +

Pour rendre un site Web accessible et utilisable sur mobile, il vous suffit de suivre les bonnes pratiques générales en matière de conception de sites Web et d'accessibilité.

+ +

Certaines exceptions nécessitent une attention particulière pour le mobile; les principaux sont:

+ + + +

Résumé des tests de lecteur d'écran sur Android et iOS

+ +

Les plates-formes mobiles les plus courantes disposent de lecteurs d’écran entièrement fonctionnels. Celles-ci fonctionnent à peu près de la même manière que les lecteurs d’écran de bureau, sauf qu’elles sont largement utilisées avec des gestes tactiles plutôt que des combinaisons de touches.

+ +

Regardons les deux principaux: TalkBack sur Android et VoiceOver sur iOS.

+ +

Android TalkBack

+ +

Le lecteur d’écran TalkBack est intégré au système d’exploitation Android.

+ +

Pour l'activer, sélectionnez Paramètres> Accessibilité> TalkBack, puis appuyez sur le curseur pour l'activer. Suivez toute invite supplémentaire à l'écran qui vous est présentée.

+ +

Note:  Les anciennes versions de TalkBack sont activées dans slightly different ways.

+ +

Lorsque TalkBack est activé, les commandes de base de votre appareil Android seront un peu différentes. Par exemple:

+ +
    +
  1. Une simple pression sur une application la sélectionne et l'appareil lit en quoi elle consiste.
    2. +
  2. Glisser vers la gauche ou la droite permet de se déplacer entre les applications, ou les boutons / contrôles si vous êtes dans une barre de contrôle. L'appareil lira chaque option.
    3. +
  3. Double-cliquer n'importe où ouvrira l'application / sélectionner l'option.
    4. +
  4. Vous pouvez également "explorer par le toucher" - maintenez votre doigt appuyé sur l'écran et faites-le glisser, et votre appareil lira les différentes applications / éléments que vous déplacez.
    5. +
+ +

Si vous souhaitez désactiver TalkBack:

+ +
    +
  1. Accédez à votre application Paramètres en utilisant les gestes ci-dessus.
    2. +
  2. Accédez à Accessibilité> TalkBack .
    3. +
  3. Accédez au commutateur et activez-le pour le désactiver. .
    4. +
+ +

Note: Vous pouvez accéder à votre écran d'accueil à tout moment en glissant vers le haut et à gauche dans un mouvement fluide. Si vous avez plus d'un écran d'accueil, vous pouvez passer d'un écran à l'autre en faisant glisser deux doigts vers la gauche et vers la droite. .

+ +

Pour une liste plus complète des gestes TalkBack, voir  Use TalkBack gestures.

+ +

Déverrouiller le téléphone

+ +

Lorsque TalkBack est activé, le déverrouillage du téléphone est un peu différent.

+ +

Vous pouvez balayer deux doigts à partir du bas de l'écran de verrouillage. Si vous avez défini un code d'accès ou un modèle pour déverrouiller votre appareil, vous serez redirigé vers l'écran de saisie approprié pour le saisir.

+ +

Vous pouvez également explorer en touchant le bouton Déverrouiller en bas au centre de l'écran, puis en appuyant deux fois.

+ + + +

TalkBack vous permet d'accéder aux menus contextuels globaux et locaux, où que vous ayez navigué sur l'appareil. Le premier fournit des options globales relatives à l'appareil dans son ensemble, et le second fournit des options relatives uniquement à l'application / à l'écran actuel.

+ +

Pour accéder à ces menus:

+ +
    +
  1. Accédez au menu global en glissant rapidement vers le bas, puis à droite .
    2. +
  2. Accédez au menu local en balayant rapidement vers le haut, puis à droite.
    3. +
  3. Balayez vers la gauche et la droite pour naviguer entre les différentes options. .
    4. +
  4. Une fois que vous avez sélectionné l'option de votre choix, double-cliquez dessus pour la choisir.
    5. +
+ +

Pour plus de détails sur toutes les options disponibles dans les menus contextuels global et local, voir  Use global and local context menus.

+ +

Parcourir des pages Web

+ +

Vous pouvez utiliser le menu contextuel local dans un navigateur Web pour rechercher des options permettant de naviguer dans des pages Web en utilisant uniquement les en-têtes, les contrôles de formulaire ou les liens, ou de naviguer ligne par ligne, etc.

+ +

Par exemple, avec TalkBack activé:

+ +
    +
  1. Ouvrez votre navigateur web.
    2. +
  2. Activer la barre d'URL.
    3. +
  3. Entrez une page Web comportant de nombreux en-têtes, telle que la page de couverture de bbc.co.uk. Pour entrer le texte de l'URL: +
      +
    • Sélectionnez la barre d’URL en glissant gauche / droite jusqu’à ce que vous y arriviez, puis en double tapant .
      • +
    • Maintenez votre doigt appuyé sur le clavier virtuel jusqu'à obtenir le caractère souhaité, puis relâchez-le pour le saisir. Répétez pour chaque caractère.
      • +
    • Une fois que vous avez terminé, trouvez la touche Entrée et appuyez dessus.
      • +
    +
    4. +
  4. Balayez vers la gauche et la droite pour vous déplacer entre différents éléments de la page. .
    5. +
  5. Faites glisser votre doigt vers le haut et vers la droite avec un mouvement fluide pour accéder au menu de contenu local.
    6. +
  6. Balayez vers la droite jusqu'à ce que vous trouviez l'option "En-têtes et points de repère".
    7. +
  7. Appuyez deux fois pour le sélectionner. Vous pouvez maintenant glisser à gauche et à droite pour vous déplacer entre les rubriques et les points de repère ARIA.
    8. +
  8. Pour revenir au mode par défaut, entrez de nouveau dans le menu contextuel local en balayant l'écran vers le haut, le curseur à droite, sélectionnez "Par défaut", puis tapez deux fois pour l'activer.
    9. +
+ +

Note:  Voir  aussi Get started on Android with TalkBack pour obtenir une documentation plus complète.

+ +

iOS VoiceOver

+ +

Une version mobile de VoiceOver est intégrée au système d'exploitation iOS.

+ +

Pour l'activer, accédez à l'application Paramètres, puis sélectionnez Général > Accessibilité > VoiceOver. Appuyez sur le curseur VoiceOver pour l'activer (vous verrez également un certain nombre d'autres options liées à VoiceOver sur cette page).

+ +

Une fois que VoiceOver est activé, les gestes de contrôle de base de l'iOS seront un peu différents :

+ +
    +
  1. Un simple tapement entraînera la sélection de l'élément sur lequel vous appuyez; votre appareil parlera de l'élément sur lequel vous avez tapé.
    2. +
  2. Vous pouvez également parcourir les éléments à l’écran en balayant vers la gauche ou vers la droite pour les déplacer, ou en faisant glisser votre doigt sur l’écran pour naviguer entre les différents éléments (lorsque vous trouvez l’élément souhaité, vous pouvez le retirer pour le sélectionner).
    3. +
  3. Pour activer l'élément sélectionné (par exemple, ouvrir une application sélectionnée), appuyez deux fois n'importe où sur l'écran.
    4. +
  4. Faites glisser votre doigt avec trois doigts pour faire défiler une page.
    5. +
  5. Appuyez avec deux doigts pour effectuer une action liée au contexte - par exemple, prendre une photo alors que vous êtes dans l'application Appareil photo.
    6. +
+ +

Pour le désactiver à nouveau, revenez à Paramètres> Général> Accessibilité> VoiceOver en utilisant les gestes ci-dessus, puis basculez le curseur VoiceOver sur Désactivé.

+ +

Déverrouiller le téléphone

+ +

Pour déverrouiller le téléphone, vous devez appuyer sur le bouton d'accueil (ou balayer) comme d'habitude. Si vous avez défini un code d'authentification, vous pouvez sélectionner chaque numéro en balayant / glissant (comme expliqué ci-dessus), puis en appuyant deux fois pour entrer chaque numéro lorsque vous avez trouvé le bon.

+ +

Utiliser le rotor

+ +

Lorsque VoiceOver est activé, vous disposez d'une fonction de navigation appelée Rotor, qui vous permet de choisir rapidement parmi un certain nombre d'options utiles courantes. Pour l'utiliser:

+ +
    +
  1. Tournez deux doigts sur l’écran comme si vous tourniez un cadran. Chaque option sera lue à voix haute au fur et à mesure que vous tournez. Vous pouvez aller et venir pour parcourir les options.
    2. +
  2. Une fois que vous avez trouvé l'option que vous voulez: +
      +
    • Relâchez vos doigts pour le sélectionner.
      • +
    • S'il s'agit d'une option dont vous pouvez parcourir la valeur (telle que le volume ou la vitesse de parole), vous pouvez effectuer un balayage vers le haut ou le bas pour augmenter ou diminuer la valeur de l'élément sélectionné.
      • +
    +
    3. +
+ +

Les options disponibles sous Rotor dépendent du contexte. Elles diffèrent en fonction de l'application ou de la vue dans laquelle vous vous trouvez (voir l'exemple ci-dessous).

+ +

Parcourir des pages Web

+ +

Essayons la navigation Web avec VoiceOver:

+ +
    +
  1. Ouvrez votre navigateur web.
    2. +
  2. Activer la barre d'URL.
    3. +
  3. Entrez une page Web comportant de nombreux en-têtes, telle que la page de couverture de bbc.co.uk. Pour entrer le texte de l'URL: +
      +
    • Sélectionnez la barre d’URL en glissant gauche / droite jusqu’à ce que vous y arriviez, puis en double-tapant.
      • +
    • Pour chaque caractère, maintenez votre doigt appuyé sur le clavier virtuel jusqu'à ce que vous obteniez le caractère souhaité, puis relâchez votre doigt pour le sélectionner. Appuyez deux fois pour le taper.
      • +
    • Une fois que vous avez terminé, trouvez la touche Entrée et appuyez dessus.
      • +
    +
    4. +
  4. Balayez vers la gauche et la droite pour vous déplacer entre les éléments de la page. Vous pouvez appuyer deux fois sur un élément pour le sélectionner (par exemple, suivre un lien).
    5. +
  5. Par défaut, l’option de rotor sélectionnée sera Speaking Rate; vous pouvez actuellement balayer de haut en bas pour augmenter ou diminuer le débit.
    6. +
  6. Maintenant, tournez deux doigts autour de l'écran comme un cadran pour afficher le rotor et passez d'une option à l'autre. Voici quelques exemples d'options disponibles: +
      +
    • Taux de parole : Modifiez le taux de parole.
      • +
    • Conteneurs : déplacez-vous entre différents conteneurs sémantiques de la page.
      • +
    • En-têtes : déplacez-vous entre les en-têtes de la page.
      • +
    • Liens : permet de se déplacer entre les liens de la page.
      • +
    • Contrôles de formulaire : déplacez-vous entre les contrôles de formulaire de la page.
      • +
    • Langue : déplacez-vous entre différentes traductions, si elles sont disponibles.
      • +
    +
    7. +
  7. Sélectionnez les en-têtes. Vous pouvez maintenant glisser de haut en bas pour vous déplacer entre les titres de la page.
    8. +
+ +

Note:  Pour une référence plus complète couvrant les gestes VoiceOver disponibles et d'autres astuces sur le test d'accessibilité sur iOS, voir aussi Test Accessibility on Your Device with VoiceOver.

+ +

Mécanismes de contrôle

+ +

Dans notre article relatif à l'accessibilité CSS et JavaScript, nous avons examiné l'idée d'événements spécifiques à un certain type de mécanisme de contrôle  (see Mouse-specific events). En résumé, cela pose des problèmes d'accessibilité car d'autres mécanismes de contrôle ne peuvent pas activer la fonctionnalité associée.

+ +

Par exemple, l'événement  click  est bon en termes d'accessibilité - un gestionnaire d'événements associé peut être appelé en cliquant sur l'élément sur lequel il est défini, en le sélectionnant et en appuyant sur Entrée / Retour ou en le tapant sur un périphérique à écran tactile. Essayez notre simple-button-example.html exemple (see it running live) pour voir ce que nous entendons. .

+ +

Sinon, des événements spécifiques à la souris, tels que  mousedown et mouseup créent des problèmes - leurs gestionnaires d'événements ne peuvent pas être appelés à l'aide de contrôles autres que la souris.

+ +

Si vous essayez de contrôler notre exemple  simple-box-drag.html (see example live) avec un clavier ou une touche, vous verrez le problème. Cela se produit car nous utilisons un code tel que:

+ +
div.onmousedown = function() {
+  initialBoxX = div.offsetLeft;
+  initialBoxY = div.offsetTop;
+  movePanel();
+}
+
+document.onmouseup = stopMove;
+ +

Pour activer d'autres formes de contrôle, vous devez utiliser des événements différents mais équivalents. Par exemple, les événements tactiles fonctionnent sur les périphériques à écran tactile:

+ +
div.ontouchstart = function(e) {
+  initialBoxX = div.offsetLeft;
+  initialBoxY = div.offsetTop;
+  positionHandler(e);
+  movePanel();
+}
+
+panel.ontouchend = stopMove;
+ +

Nous avons fourni un exemple simple qui montre comment utiliser simultanément les événements de la souris et des événements tactiles — voir multi-control-box-drag.html (see the example live aussi).

+ +

Note: Vous pouvez également voir des exemples fonctionnels montrant comment implémenter différents mécanismes de contrôle à   Implementing game control mechanisms.

+ +

Responsive design

+ +

Responsive design a l’habitude de faire en sorte que vos mises en page et les autres fonctionnalités de vos applications changent de manière dynamique en fonction de facteurs tels que la taille de l’écran et la résolution, de sorte qu’elles soient utilisables et accessibles aux utilisateurs de différents types d’appareils. .

+ +

En particulier, les problèmes les plus courants auxquels le mobile doit faire face sont les suivants:

+ + + +

Note:  Nous ne fournirons pas une analyse complète des techniques de conception réactive ici, car elles sont couvertes ailleurs au sein de MDN (voir les liens ci-dessus).

+ +

Considérations mobiles spécifiques

+ +

Il existe d'autres problèmes importants à prendre en compte lors de la création de sites plus accessibles sur mobile. Nous en avons énuméré quelques-uns ici, mais nous en ajouterons davantage lorsque nous y penserons.

+ +

Ne pas désactiver le zoom

+ +

En utilisant  viewport, il est possible de désactiver le zoom, en utilisant un code comme celui-ci dans votre {{htmlelement("head")}}:

+ +
<meta name="viewport" content="user-scalable=no">
+ +

Vous ne devriez jamais faire cela autant que possible - beaucoup de gens comptent sur le zoom pour voir le contenu de votre site web, aussi, enlever cette fonctionnalité est une très mauvaise idée. Il y a certaines situations où le zoom peut casser l'interface utilisateur; Dans de tels cas, si vous estimez que vous devez absolument désactiver le zoom, vous devez fournir un autre type d’équivalent, tel qu’une commande permettant d’augmenter la taille du texte de manière à ne pas endommager votre interface utilisateur.

+ +

Garder les menus accessibles

+ +

Étant donné que l'écran est beaucoup plus étroit sur les appareils mobiles, il est très courant d'utiliser des requêtes multimédia et d'autres technologies pour réduire le menu de navigation à une minuscule icône en haut de l'écran, sur laquelle vous pouvez appuyer pour afficher le menu uniquement si c'est nécessaire - lorsque le site est visualisé sur mobile. Ceci est généralement représenté par une icône "trois lignes horizontales" et le motif de conception est par conséquent appelé "menu hamburger".

+ +

Lorsque vous implémentez un tel menu, vous devez vous assurer que le contrôle qui le révèle est accessible par les mécanismes de contrôle appropriés (normalement tactile pour mobile), comme indiqué dans {{anch("Control mechanisms")}} ci-dessus, et que le reste de la page est déplacé ou caché d'une manière ou d'une autre pendant l'accès au menu, afin d'éviter toute confusion lors de la navigation. .

+ +

Cliquez ici pour un  good hamburger menu example.

+ +

Entrée utilisateur

+ +

Sur les appareils mobiles, la saisie de données a tendance à être plus agaçante pour les utilisateurs que l'expérience équivalente sur les ordinateurs de bureau. Il est plus pratique de taper du texte dans les entrées de formulaire à l'aide d'un clavier d'ordinateur de bureau ou d'ordinateur portable que d'un clavier virtuel à écran tactile ou d'un petit clavier physique mobile.

+ +

Pour cette raison, il vaut la peine d'essayer de minimiser la quantité de frappe nécessaire. Par exemple, au lieu de forcer les utilisateurs à saisir chaque fois le titre de leur travail en utilisant une entrée de texte standard, vous pouvez proposer un menu  {{htmlelement("select")}}  contenant les options les plus courantes (ce qui aide également à cohérence dans la saisie des données), et offrent une option "Autre" qui affiche un champ de texte dans lequel taper les valeurs aberrantes. Vous pouvez voir un exemple simple de cette idée en action dans common-job-types.html ( voir le common jobs example live).

+ +

Il est également utile d’envisager l’utilisation de types de saisie de formulaire au format HTML5, tels que la date sur les plates-formes mobiles car ils les gèrent bien (Android et iOS, par exemple, affichent des widgets utilisables qui correspondent bien à l’expérience de l’appareil. Voir  html5-form-examples.html  pour quelques exemples (voir HTML5 form examples live) — essayez de les charger et de les manipuler sur des appareils mobiles. Par exemple:

+ + + +

Si vous souhaitez fournir une solution différente pour les ordinateurs de bureau, vous pouvez toujours proposer un balisage différent à vos périphériques mobiles à l'aide de la détection de fonctionnalités. Reportez-vous à  input types  pour obtenir des informations brutes sur la détection de différents types d'entrée et consultez notre article feature detection article pour en savoir plus. .

+ +

Résumé

+ +

Dans cet article, nous vous avons fourni des détails sur les problèmes courants spécifiques à l'accessibilité mobile et sur la façon de les résoudre. Nous vous avons également montré comment utiliser les lecteurs d'écran les plus courants pour vous aider à effectuer des tests d'accessibilité.

+ +
+

Voir également

+
+ + + +
{{PreviousMenuNext("Learn/Accessibility/Multimedia","Learn/Accessibility/Accessibility_troubleshooting", "Learn/Accessibility")}}
+ +
+

Dans ce module

+ + +
+
diff --git a/files/fr/apprendre/a11y/multimedia/index.html b/files/fr/apprendre/a11y/multimedia/index.html new file mode 100644 index 0000000000..e8b03c52b0 --- /dev/null +++ b/files/fr/apprendre/a11y/multimedia/index.html @@ -0,0 +1,374 @@ +--- +title: Accessible multimedia +slug: Apprendre/a11y/Multimedia +tags: + - Accessibilité + - Apprendre + - Audio + - Débutant + - HTML + - Images + - JavaScript + - Multimedia + - Video +translation_of: Learn/Accessibility/Multimedia +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Accessibility/WAI-ARIA_basics","Learn/Accessibility/Mobile", "Learn/Accessibility")}}
+ +

Le multimédia est une autre catégorie de contenu susceptible de créer des problèmes d'accessibilité: les contenus vidéo, audio et images doivent disposer de solutions de remplacement textuelles appropriées pour être compris par les technologies d'assistance et leurs utilisateurs. Cet article montre comment.

+ + + + + + + + + + + + +
Conditions requise:Connaissances informatiques de base, une compréhension de base de HTML, CSS et JavaScript, une compréhension de Qu'est ce que l'accessibilité?
Objectif:Comprendre les problèmes d'accessibilité derrière le multimédia et comment les résoudre .
+ +

Multimédia et accessibilité

+ +

Jusqu'ici, dans ce module, nous avons examiné une variété de contenus et ce qui doit être fait pour en assurer l'accessibilité, du simple contenu textuel aux tableaux de données, en passant par les images, les contrôles natifs tels que les éléments de formulaire et les boutons, et des structures de balisage encore plus complexes. (avec  WAI-ARIA l'attribut).

+ +

Cet article, par contre, examine une autre catégorie générale de contenu pour laquelle il est difficile d’assurer l’accessibilité au multimédia. Les images, les vidéos, les éléments {{htmlelement ("canvas")}} les animations Flash, etc. ne sont pas aussi faciles à comprendre par les lecteurs d'écran ou à naviguer au clavier, et nous devons leur donner un coup de main.

+ +

Mais ne désespérez pas - nous vous aiderons ici à naviguer parmi les techniques disponibles pour rendre le multimédia plus accessible.

+ +

Simple images

+ +

Nous avons déjà couvert des alternatives textuelles simples pour les images HTML dans notre article   HTML : une bonne base pour l'accessibilité  —  vous pouvez vous y référer pour plus de détails. En bref, vous devez vous assurer que, dans la mesure du possible, le contenu visuel dispose d’un texte alternatif que les lecteurs d’écran peuvent lire et lire à leurs utilisateurs.

+ +

 

+ +
+
Par exemple:
+
+ +
<img src="dinosaur.png"
+     alt=" Un Tyrannosaure Rex rouge: Un dinosaure a deux pattes se tenant droit comme un humain, avec de petits bras et une grosse tete avec beaucoup de dents acerees .">
+
+ +

Commandes audio et vidéo accessibles

+ +

La mise en œuvre de contrôles audio / vidéo sur le Web ne devrait pas poser de problème, n'est-ce pas? Enquêtons .

+ +

Le problème avec les contrôles HTML5 natifs

+ +

Les instances audio et vidéo HTML5 sont même fournies avec un ensemble de commandes intégrées vous permettant de contrôler le contenu multimédia directement. Par exemple (voir  native-controls.html code source et en direct):

+ +
<audio controls>
+  <source src="viper.mp3" type="audio/mp3">
+  <source src="viper.ogg" type="audio/ogg">
+  <p> Votre navigateur ne supporte pas l\'audio HTML5. Voici un <a href="viper.mp3"> lien vers l\'audio </a>  au lieu .</p>
+</audio>
+
+<br>
+
+<video controls>
+  <source src="rabbit320.mp4" type="video/mp4">
+  <source src="rabbit320.webm" type="video/webm">
+  <p>Votre navigateur ne supporte pas l\'audio HTML5. Voici un <a href="rabbit320.mp4">lien vers la video</a> instead.</p>
+</video>
+ +

L'attribut controls comporte des boutons de lecture / pause, une barre de recherche, etc. - les commandes de base que vous êtes en droit d'attendre d'un lecteur multimédia. Il semble que dans Firefox et Chrome :

+ +

Screenshot of Video Controls in Firefox

+ +

Screenshot of Video Controls in Chrome

+ +

Cependant, il y a des problèmes avec ces contrôles :

+ + + +

Pour remédier à cela, nous pouvons créer nos propres contrôles personnalisés. Regardons comment.

+ +

Création de contrôles audio et vidéo personnalisés

+ +

La vidéo et l'audio HTML5 partagent une API - HTML Media Element - qui vous permet de mapper des fonctionnalités personnalisées à des boutons et à d'autres commandes, que vous définissez vous-même. .

+ +

Prenons l'exemple vidéo ci-dessus et ajoutons-leur des contrôles personnalisés .

+ +

Basic setup

+ +

Tout d'abord, prenez une copie de notre  custom-controls-start.html, custom-controls.css, rabbit320.mp4, et rabbit320.webm fichiers et enregistrez-les dans un nouveau répertoire sur votre disque dur .

+ +

Créez un nouveau fichier appelé main.js et enregistrez-le dans le même répertoire .

+ +

Tout d’abord, regardons le code HTML pour le lecteur vidéo, dans le code HTML:

+ +
<section class="player">
+  <video controls>
+    <source src="rabbit320.mp4" type="video/mp4">
+    <source src="rabbit320.webm" type="video/webm">
+    <p>Votre navigateur ne supporte pas l\'audio HTML5. Voici un <a href="rabbit320.mp4">lien vers la video</a> instead.</p>
+  </video>
+
+  <div class="controls">
+    <button class="playpause">Play</button>
+    <button class="stop">Stop</button>
+    <button class="rwd">Rwd</button>
+    <button class="fwd">Fwd</button>
+    <div class="time">00:00</div>
+  </div>
+</section>
+ +

JavaScript basic setup

+ +

Nous avons inséré quelques boutons de commande simples sous notre vidéo. Bien sûr, ces contrôles ne feront rien par défaut; pour ajouter des fonctionnalités, nous allons utiliser JavaScript .

+ +

Nous devrons d’abord stocker les références à chacun des contrôles - ajoutez ce qui suit en haut de votre fichier JavaScript:

+ +
var playPauseBtn = document.querySelector('.playpause');
+var stopBtn = document.querySelector('.stop');
+var rwdBtn = document.querySelector('.rwd');
+var fwdBtn = document.querySelector('.fwd');
+var timeLabel = document.querySelector('.time');
+ +

Ensuite, nous devons saisir une référence au lecteur vidéo / audio lui-même - ajoutez cette ligne sous les lignes précédentes:

+ +
var player = document.querySelector('video');
+ +

Ceci contient une référence à un objet {{domxref ("HTMLMediaElement")}} qui possède plusieurs propriétés et méthodes utiles disponibles qui peuvent être utilisées pour connecter des fonctionnalités à nos boutons.

+ +

Avant de passer à la création de notre fonctionnalité de bouton, supprimons les contrôles natifs afin qu'ils ne gênent pas nos contrôles personnalisés. Ajoutez ce qui suit, encore une fois au bas de votre JavaScript:

+ +
player.removeAttribute('controls');
+ +

Le fait de procéder ainsi plutôt que de ne pas inclure les attributs de contrôle en premier lieu présente l'avantage que si notre JavaScript échoue pour une raison quelconque, l'utilisateur dispose toujours de certains contrôles.

+ +

Câbler nos boutons

+ +

Commençons par configurer le bouton lecture / pause. Nous pouvons le faire basculer entre lecture et pause avec une simple fonction conditionnelle, comme ci-dessous. Ajoutez-le à votre code, en bas:

+ +
playPauseBtn.onclick = function() {
+  if(player.paused) {
+    player.play();
+    playPauseBtn.textContent = 'Pause';
+  } else {
+    player.pause();
+    playPauseBtn.textContent = 'Play';
+  }
+};
+ +

Ensuite, ajoutez ce code en bas, qui contrôle le bouton d'arrêt:

+ +
stopBtn.onclick = function() {
+  player.pause();
+  player.currentTime = 0;
+  playPauseBtn.textContent = 'Play';
+};
+ +

Il n'y a pas de fonction  stop()  disponible sur {{domxref("HTMLMediaElement")}}s,  nous le mettons donc en pause()  et, dans le même temps, définissons la valeur currentTime sur 0.

+ +

Ensuite, nos boutons de rembobinage et d’avance rapide - ajoutez les blocs suivants au bas de votre  code:

+ +
rwdBtn.onclick = function() {
+  player.currentTime -= 3;
+};
+
+fwdBtn.onclick = function() {
+  player.currentTime += 3;
+  if(player.currentTime >= player.duration || player.paused) {
+    player.pause();
+    player.currentTime = 0;
+    playPauseBtn.textContent = 'Play';
+  }
+};
+ +

Celles-ci sont très simples, il suffit d’ajouter ou de soustraire 3 secondes à  currentTime chaque fois qu’on clique dessus. Dans un vrai lecteur vidéo, vous voudrez probablement une barre de recherche plus élaborée, ou similaire.

+ +

Notez que nous vérifions également si la durée  currentTime est supérieure à la durée totale du support ou si le support n'est pas en cours de lecture lorsque le bouton Fwd est enfoncé. Si l'une ou l'autre de ces conditions est vraie, nous arrêtons simplement la vidéo pour éviter que l'interface utilisateur ne se détériore si elle tente d'effectuer une avance rapide lorsque la vidéo n'est pas en cours de lecture ou si la fin de la vidéo est terminée. .

+ +

Enfin, ajoutez ce qui suit à la fin du code pour contrôler l’affichage du temps écoulé:

+ +
player.ontimeupdate = function() {
+  var minutes = Math.floor(player.currentTime / 60);
+  var seconds = Math.floor(player.currentTime - minutes * 60);
+  var minuteValue;
+  var secondValue;
+
+  if (minutes<10) {
+    minuteValue = "0" + minutes;
+  } else {
+    minuteValue = minutes;
+  }
+
+  if (seconds<10) {
+    secondValue = "0" + seconds;
+  } else {
+    secondValue = seconds;
+  }
+
+  mediaTime = minuteValue + ":" + secondValue;
+  timeLabel.textContent = mediaTime;
+};
+ +

Chaque fois que l'heure est mise à jour (une fois par seconde), nous activons cette fonction. Il calcule le nombre de minutes et de secondes à partir de la valeur actuelle donnée en secondes, ajoute un 0 au début si la valeur de minute ou de seconde est inférieure à 10, puis crée la lecture d'affichage et l'ajoute à l'étiquette de temps.

+ +

Lectures complémentaires

+ +

Cela vous donne une idée de base sur la manière d’ajouter des fonctionnalités de lecteur personnalisées aux instances de lecteur vidéo / audio. Pour plus d'informations sur l'ajout de fonctionnalités plus complexes aux lecteurs vidéo / audio, y compris les solutions de secours Flash pour les navigateurs plus anciens, voir aussi:

+ + + +

Nous avons également créé un exemple avancé pour montrer comment créer un système orienté objet permettant de rechercher tous les lecteurs vidéo et audio de la page (quel que soit leur nombre) et d'y ajouter nos contrôles personnalisés. Voir  custom-controls-oojs ( également voir le code source).

+ +

Transcriptions audio

+ +

Pour permettre aux sourds d'accéder au contenu audio, vous devez créer des transcriptions de texte. Ceux-ci peuvent être soit inclus sur la même page que l'audio d'une manière ou d'une autre, soit inclus sur une page séparée et liés à.

+ +

En termes de création de la transcription, vos options sont les suivantes:

+ + + +

Comme dans la plupart des choses de la vie, vous avez tendance à avoir ce que vous payez. la précision et le temps requis pour produire la transcription varient selon les services. Si vous payez une transcription pour une entreprise digne de confiance ou un service d’AI, vous le ferez probablement rapidement et avec une qualité élevée. Si vous ne voulez pas payer pour cela, vous le ferez probablement avec une qualité inférieure et / ou lentement.

+ +

Il n’est pas acceptable de publier une ressource audio mais de promettre de publier la transcription ultérieurement. De telles promesses ne sont souvent pas tenues, ce qui érodera la confiance entre vous et vos utilisateurs. Si le son que vous présentez ressemble à une réunion en face-à-face ou à une performance parlée en direct, il serait acceptable de prendre des notes pendant la performance, de les publier intégralement avec l'audio, puis de demander de l'aide pour les nettoyer par la suite.

+ +

Exemples de transcription

+ +

Si vous utilisez un service automatisé, vous devrez probablement utiliser l'interface utilisateur fournie par l'outil. Par exemple, jetez un coup d’œil à  Audio Transcription Sample 1 et choisissez plus > Transcript.

+ +

Si vous créez votre propre interface utilisateur pour présenter votre audio et la transcription associée, vous pouvez le faire comme bon vous semble, mais il serait peut-être judicieux de l'inclure dans un panneau pouvant être affiché / masqué; voir notre exemple  transcription audio-ui exemple (voir aussi le code source).

+ +

Descriptions audio

+ +

Dans les cas où des éléments visuels accompagnent votre son, vous devez fournir une description de l’audio pour décrire ce contenu supplémentaire.

+ +

Dans de nombreux cas, il s'agira simplement d'une vidéo. Dans ce cas, vous pouvez implémenter des légendes à l'aide des techniques décrites dans la section suivante de l'article.

+ +

Cependant, il y a des cas extrêmes. Vous pouvez par exemple avoir un enregistrement audio d'une réunion qui fait référence à une ressource d'accompagnement telle qu'une feuille de calcul ou un graphique. Dans de tels cas, vous devez vous assurer que les ressources sont fournies avec la transcription audio +, et les lier spécifiquement aux endroits où elles sont mentionnées dans la transcription. Cela aidera évidemment tous les utilisateurs, pas seulement les sourds.

+ +
+

Note: Une transcription audio aidera en général plusieurs groupes d'utilisateurs. En plus de permettre aux utilisateurs sourds d'accéder aux informations contenues dans l'audio, pensez à un utilisateur disposant d'une connexion à faible bande passante et qui trouverait que le téléchargement de l'audio est gênant. Pensez également à un utilisateur dans un environnement bruyant, comme un pub ou un bar, qui tente d'accéder à l'information mais ne l'entend pas par dessus le bruit.

+
+ +

Pistes de texte vidéo

+ +

Pour rendre la vidéo accessible aux sourds, aux aveugles ou même à d'autres groupes d'utilisateurs (par exemple, ceux dont la bande passante est faible ou qui ne comprennent pas la langue dans laquelle la vidéo est enregistrée), vous devez inclure des pistes de texte avec votre contenu vidéo. .

+ +
+

Note: Les pistes de texte sont également utiles pour n'importe quel utilisateur, pas seulement pour les personnes handicapées. Par exemple, certains utilisateurs peuvent ne pas être en mesure d’entendre le son car ils se trouvent dans des environnements bruyants (comme un bar bondé lorsqu’un match de sport est diffusé) ou peuvent ne pas déranger les autres s’ils sont dans un endroit calme (comme une bibliothèque). .)

+
+ +

Ce n'est pas un nouveau concept - les sous-titres codés sont disponibles depuis assez longtemps dans les services de télévision:

+ +

Frame from an old-timey cartoon with closed captioning "Good work, Goldie. Keep it up!"

+ +

Alors que de nombreux pays proposent des films en anglais avec sous-titres écrits dans leur propre langue maternelle, des sous-titres en différentes langues sont souvent disponibles sur DVD, par exemple

+ +

An English film with German subtitles "Emo, warum erkennst du nicht die Schonheit dieses Ortes?"

+ +

Il existe différents types de pistes de texte avec des objectifs différents. Les principaux que vous rencontrerez sont:

+ + + +

Implémentation de pistes de texte vidéo HTML5

+ +

Les pistes de texte à afficher avec une vidéo HTML5 doivent être écrites au format WebVTT, un format de texte contenant plusieurs chaînes de texte ainsi que des métadonnées, telles que l'heure à laquelle vous souhaitez afficher chaque chaîne de texte et même des informations de style / positionnement limitées. Ces chaînes de texte sont appelées cues .

+ +

Un fichier WebVTT typique ressemblera à ceci:

+ +
WEBVTT
+
+1
+00:00:22.230 --> 00:00:24.606
+ Ceci est le premier sous-titre.
+
+2
+00:00:30.739 --> 00:00:34.074
+ C'est le deuxième .
+
+  ...
+ +

Pour que ceci soit affiché avec la lecture du média HTML, vous devez:

+ + + +

Voici un exemple:

+ +
<video controls>
+    <source src="example.mp4" type="video/mp4">
+    <source src="example.webm" type="video/webm">
+    <track kind="subtitles" src="subtitles_en.vtt" srclang="en">
+</video>
+ +

Cela donnera une vidéo avec des sous-titres affichés, un peu comme ceci:

+ +

Video player with standard controls such as play, stop, volume, and captions on and off. The video playing shows a scene of a man holding a spear-like weapon, and a caption reads "Esta hoja tiene pasado oscuro."

+ +

Pour plus de détails, veuillez lire  Ajouter des légendes et des sous titres à des vidéos HTML 5.  Vous trouverez un exemple  qui accompagne cet article sur Github, écrit par Ian Devlin (voir aussi le code source.) Cet exemple utilise du JavaScript. pour permettre aux utilisateurs de choisir entre différents sous-titres. Notez que pour activer les sous-titres, vous devez appuyer sur le bouton "CC" et sélectionner une option - Anglais, Allemand ou Español.

+ +
+

Note: Les pistes de texte et les transcriptions vous aident également avec {{glossary ("SEO")}}, car les moteurs de recherche se développent particulièrement bien avec le texte. Les pistes de texte permettent même aux moteurs de recherche de se lier directement à un endroit en cours de vidéo.

+
+ +

Autre contenu multimédia

+ +

Les sections ci-dessus ne couvrent pas tous les types de contenu multimédia que vous pourriez vouloir placer sur une page Web. Vous devrez peut-être également gérer des jeux, des animations, des diaporamas, des vidéos intégrées et du contenu créé à l'aide d'autres technologies disponibles, telles que:

+ + + +

Pour ce type de contenu, vous devez traiter les problèmes d’accessibilité au cas par cas. Dans certains cas, ce n'est pas si grave, par exemple:

+ + + +

Cependant, il est difficile de rendre les autres multimédias accessibles. Si, par exemple, vous avez affaire à un jeu immersif en 3D ou à une application de réalité virtuelle, il est vraiment difficile de fournir des alternatives textuelles pour une telle expérience, et vous pouvez soutenir que les utilisateurs non-voyants ne sont pas vraiment dans le groupe-cible de telles applications.

+ +

Vous pouvez toutefois vous assurer qu'une telle application présente un contraste de couleur suffisant et une présentation claire de sorte qu'elle soit perceptible par les personnes ayant une vision basse / daltonisme, et qu'elle soit également accessible au clavier. Rappelez-vous que l'accessibilité consiste à faire tout ce que vous pouvez, plutôt que de chercher à atteindre une accessibilité à 100% tout le temps, ce qui est souvent impossible.

+ +
+

Résumé

+
+ +

Ce chapitre présente un résumé des problèmes d’accessibilité des contenus multimédias, ainsi que des solutions pratiques.

+ +

{{PreviousMenuNext("Learn/Accessibility/WAI-ARIA_basics","Learn/Accessibility/Mobile", "Learn/Accessibility")}}

+ +

 

+ +

Dans ce module

+ + + +

 

diff --git a/files/fr/apprendre/a11y/wai-aria_basics/index.html b/files/fr/apprendre/a11y/wai-aria_basics/index.html new file mode 100644 index 0000000000..6a55cde5cb --- /dev/null +++ b/files/fr/apprendre/a11y/wai-aria_basics/index.html @@ -0,0 +1,425 @@ +--- +title: Les bases de WAI-ARIA +slug: Apprendre/a11y/WAI-ARIA_basics +tags: + - ARIA + - Accessibilité + - Apprendre + - Article + - Débutant + - Guide + - HTML + - JavaScript + - WAI-ARIA + - sémantique +translation_of: Learn/Accessibility/WAI-ARIA_basics +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Accessibility/CSS_and_JavaScript","Learn/Accessibility/Multimedia", "Learn/Accessibility")}}
+ +

Après l'article précédent, il peut être difficile de créer des contrôles UI complexes impliquant du code HTML non sémantique et du contenu dynamique mis à jour par JavaScript. WAI-ARIA est une technologie qui peut aider à résoudre de tels problèmes en ajoutant une sémantique supplémentaire que les navigateurs et les technologies d'assistance peuvent reconnaître et utiliser pour informer les utilisateurs de ce qui se passe. Nous montrerons ici comment l'utiliser au niveau de base pour améliorer l'accessibilité.

+ + + + + + + + + + + + +
  Prerequis:Connaissances informatiques de base, une compréhension de base de HTML, CSS et JavaScript, une compréhension des articles précédents du cours.
Objectif :Se familiariser avec WAI-ARIA et savoir comment l'utiliser pour fournir une sémantique supplémentaire utile afin d'améliorer l'accessibilité, le cas échéant.
+ +

Qu'est WAI-ARIA?

+ +

Commençons par regarder ce que WAI-ARIA est , et ce qu’il peut faire pour nous.

+ +

Un nouvel ensemble de problèmes

+ +

Car les applications web ont commencé à devenir plus complexes et dynamiques, un nouvel ensemble de fonctionnalités d'accessibilité et de problèmes ont commencé à apparaître.

+ +

Par exemple, HTML5 a introduit un certain nombre d’éléments sémantiques pour définir des fonctionnalités de page communes  ({{htmlelement("nav")}}, {{htmlelement("footer")}}, etc.)  Avant de les utiliser, les développeurs utilisaient simplement {{htmlelement("div")}} s avec des identifiants ou des classes, par exemple <div class="nav"> , mais ils posaient problème, car il n’existait pas de moyen facile de trouver facilement une fonctionnalité de page spécifique telle que la navigation principale par programmation. .

+ +

La solution initiale consistait à ajouter un ou plusieurs liens cachés en haut de la page pour créer un lien vers la navigation (ou autre), par exemple:

+ +
<a href="#hidden" class="hidden">Passer à la navigation</a>
+ +

Mais ceci n’est pas encore très précis et ne peut être utilisé que lorsque le lecteur d’écran lit en haut de la page.

+ +

Autre exemple, les applications ont commencé à comporter des commandes complexes telles que des sélecteurs de date pour choisir les dates, des curseurs pour choisir des valeurs, etc. HTML5 fournit des types spéciaux  input pour rendre de tels contrôles:

+ +
<input type="date">
+<input type="range">
+ +

Celles-ci ne sont pas bien prises en charge sur tous les navigateurs et il est également très difficile de les nommer, ce qui les rend peu utiles pour l'intégration aux conceptions de sites Web. En conséquence, les développeurs font souvent appel à des bibliothèques JavaScript qui génèrent des contrôles tels qu'une série d'éléments {{htmlelement("div")}} s imbriqués ou d'éléments de table avec des noms de classe, qui sont ensuite stylés à l'aide de CSS et contrôlés à l'aide de JavaScript.

+ +

Le problème ici est que, visuellement, ils fonctionnent, mais que les lecteurs d’écran ne peuvent pas comprendre ce qu’ils sont, et on dit aux utilisateurs qu’ils peuvent voir une multitude d’éléments sans sémantique pour décrire ce qu’ils veulent dire.

+ +

Entrez WAI-ARIA

+ +

WAI-ARIA est une spécification écrite par le W3C et définissant un ensemble d'attributs HTML supplémentaires pouvant être appliqués aux éléments pour fournir une sémantique supplémentaire et améliorer l'accessibilité en cas de manque. Trois caractéristiques principales sont définies dans la spécification:

+ + + +

Un point important sur les attributs WAI-ARIA est qu'ils n'affectent en rien la page Web, à l'exception des informations exposées par les API d'accessibilité du navigateur (où les lecteurs d'écran obtiennent leurs informations). WAI-ARIA n'affecte pas la structure de la page Web, le DOM, etc., bien que les attributs puissent être utiles pour sélectionner des éléments par CSS.

+ +
+

Note: Vous pouvez trouver une liste utile de tous les rôles ARIA et de leurs utilisations, avec des liens vers des informations supplémentaires, dans les spécifications WAI-ARIA — voir la définition des rôles.

+ +

La spécification contient également une liste de toutes les propriétés et de tous les états, avec des liens vers des informations complémentaires - voir  Définitions des états et des propriétés (tous les attributs aria- *).

+
+ +

Où WAI-ARIA est supporté?

+ +

Ce n’est pas une question simple. Il est difficile de trouver une ressource concluante qui explicite quelles fonctionnalités de WAI-ARIA sont supportées où, parce que:

+ +
    +
  1. Il y a beaucoup de fonctionnalités dans la spécification WAI-ARIA
    2. +
  2. Il y a beaucoup de combinaisons de systèmes d’exploitation, navigateurs et lecteurs d’écrans à considérer
    3. +
+ +

Ce dernier point est la clé: pour utiliser un lecteur d’écran, votre système d’exploitation a besoin d’un navigateur ayant les APIs d’accessibilité nécessaires, de manière à présenter l’information dont les lecteurs d’écran ont besoin pour faire leur travail. Les systèmes d’exploitation les plus populaires ont un à deux navigateurs avec les quels les lecteurs d’écrans peuvent travailler. Le Paciello Group a un article plutôt à jour fournissant des informations pour ceci — voir Rough Guide: browsers, operating systems and screen reader support updated.

+ +

Ensuite, vous devez vous demander si les navigateurs en question supportent les fonctionnalités ARIA et les présenter via leurs APIs, mais aussi du fait que les lecteurs d’écrans reconnaissent ou non cette information et la présentent à leurs utilisateurs d’une manière utile.

+ +
    +
  1. Browser support is generally quite good — at the time of writing, caniuse.com stated that global browser support for WAI-ARIA was around 88%.
    2. +
  2. Screenreader support for ARIA features isn't quite at this level, but the most popular screenreaders are getting there. You can get an idea of support levels by looking at Powermapper's WAI-ARIA Screen reader compatibility article.
    3. +
+ +

In this article, we won't attempt to cover every WAI-ARIA feature, and its exact support details. Instead, we will cover the most critical WAI-ARIA features for you to know about; if we don't mention any support details, you can assume that the feature is well-supported. We will clearly mention any exceptions to this.

+ +
+

Note: Some JavaScript libraries support WAI-ARIA, meaning that when they generate UI features like complex form controls, they add ARIA attributes to improve the accessibility of those features. If you are looking for a 3rd party JavaScript solution for rapid UI development, you should definitely consider the accessibility of its UI widgets as an important factor when making your choice. Good examples are jQuery UI (see About jQuery UI: Deep accessibility support), ExtJS, and Dojo/Dijit.

+
+ +

When should you use WAI-ARIA?

+ +

We talked about some of the problems that prompted WAI-ARIA to be created earlier on, but essentially, there are four main areas that WAI-ARIA is useful in:

+ +
    +
  1. Signposts/Landmarks: ARIA's role attribute values can act as landmarks that either replicate the semantics of HTML5 elements (e.g. {{htmlelement("nav")}}), or go beyond HTML5 semantics to provide signposts to different functional areas, e.g search, tabgroup, tab, listbox, etc.
    2. +
  2. Dynamic content updates: Screenreaders tend to have difficulty with reporting constantly changing content; with ARIA we can use aria-live to inform screenreader users when an area of content is updated, e.g. via XMLHttpRequest, or DOM APIs.
    3. +
  3. Enhancing keyboard accessibility: There are built-in HTML elements that have native keyboard accessibility; when other elements are used along with JavaScript to simulate similar interactions, keyboard accessibility and screenreader reporting suffers as a result. Where this is unavoidable, WAI-ARIA provides a means to allow other elements to receive focus (using tabindex).
    4. +
  4. Accessibility of non-semantic controls: When a series of nested <div>s along with CSS/JavaScript is used to create a complex UI-feature, or a native control is greatly enhanced/changed via JavaScript, accessibility can suffer — screenreader users will find it difficult to work out what the feature does if there are no semantics or other clues. In these situations, ARIA can help to provide what's missing with a combination of roles like button, listbox, or tabgroup, and properties like aria-required or aria-posinset to provide further clues as to functionality.
    5. +
+ +

One thing to remember though — you should only use WAI-ARIA when you need to! Ideally, you should always use native HTML features to provide the semantics required by screenreaders to tell their users what is going on. Sometimes this isn't possible, either because you have limited control over the code, or because you are creating something complex that doesn't have an easy HTML element to implement it. In such cases, WAI-ARIA can be a valuable accessibility enhancing tool.

+ +

But again, only use it when necessary!

+ +
+

Note: Also, try to make sure you test your site with a variety of real users — non-disabled people, people using screenreaders, people using keyboard navigation, etc. They will have better insights than you about how well it works.

+
+ +

Practical WAI-ARIA implementations

+ +

In the next section we'll look at the four areas in more detail, along with practical examples. Before you continue, you should get a screenreader testing setup put in place, so you can test some of the examples as you go through.

+ +

See our section on testing screenreaders for more information.

+ +

Signposts/Landmarks

+ +

WAI-ARIA adds the role attribute to browsers, which allows you to add extra semantic value to elements on your site wherever they are needed. The first major area in which this is useful is providing information for screenreaders so that their users can find common page elements. Let's look at an example — our website-no-roles example (see it live) has the following structure:

+ +
<header>
+  <h1>...</h1>
+  <nav>
+    <ul>...</ul>
+    <form>
+      <!-- search form  -->
+    </form>
+  </nav>
+</header>
+
+<main>
+  <article>...</article>
+  <aside>...</aside>
+</main>
+
+<footer>...</footer>
+ +

If you try testing the example with a screenreader in a modern browser, you'll already get some useful information. For example, VoiceOver gives you the following:

+ + + +

If you go to VoiceOver's landmarks menu (accessed using VoiceOver key + U and then using the cursor keys to cycle through the menu choices), you'll see that most of the elements are nicely listed so they can be accessed quickly.

+ +

+ +

However, we could do better here. the search form is a really important landmark that people will want to find, but it is not listed in the landmarks menu or treated like a notable landmark, beyond the actual input being called out as a search input (<input type="search">). In addition, some older browsers (most notably IE8) don't recognise the semantics of the HTML5 elements.

+ +

Let's improve it by the use of some ARIA features. first, we'll add some role attributes to our HTML structure. You can try taking a copy of our original files (see index.html and style.css), or navigating to our website-aria-roles example (see it live), which has a structure like this:

+ +
<header>
+  <h1>...</h1>
+  <nav role="navigation">
+    <ul>...</ul>
+    <form role="search">
+      <!-- search form  -->
+    </form>
+  </nav>
+</header>
+
+<main>
+  <article role="article">...</article>
+  <aside role="complementary">...</aside>
+</main>
+
+<footer>...</footer>
+ +

We've also given you a bonus feature in this example — the {{htmlelement("input")}} element has been given the attribute aria-label, which gives it a descriptive label to be read out by a screenreader, even though we haven't included a {{htmlelement("label")}} element. In cases like these, this is very useful — a search form like this one is a very common, easily recognised feature, and adding a visual label would spoil the page design.

+ +
<input type="search" name="q" placeholder="Search query" aria-label="Search through site content">
+ +

Now if we use VoiceOver to look at this example, we get some improvements:

+ + + +

Beyond this, the site is more likely to be accessible to users of older browsers such as IE8; it is worth including ARIA roles for that purpose. And if for some reason your site is built using just <div>s, you should definitely include the ARIA roles to provide these much needed semantics!

+ +

The improved semantics of the search form have shown what is made possible when ARIA goes beyond the semantics available in HTML5. You'll see a lot more about these semantics and the power of ARIA properties/attributes below, especially in the {{anch("Accessibility of non-semantic controls")}} section. For now though, let's look at how ARIA can help with dynamic content updates.

+ +

Dynamic content updates

+ +

Content loaded into the DOM can be easily accessed using a screenreader, from textual content to alternative text attached to images. Traditional static websites with largely text content are therefore easy to make accessible for people with visual impairments.

+ +

The problem is that modern web apps are often not just static text — they tend to have a lot of dynamically updating content, i.e. content that updates without the entire page reloading via a mechanism like XMLHttpRequest, Fetch, or DOM APIs. These are sometimes referred to as live regions.

+ +

Let's look at a quick example — see aria-no-live.html (also see it running live). In this example we have a simple random quote box:

+ +
<section>
+  <h1>Random quote</h1>
+  <blockquote>
+    <p></p>
+  </blockquote>
+</section>
+ +

Our JavaScript loads a JSON file via XMLHttpRequest containing a series of random quotes and their authors. Once that is done, we start up a setInterval() loop that loads a new random quote into the quote box every 10 seconds:

+ +
var intervalID = window.setInterval(showQuote, 10000);
+ +

This works OK, but it is not good for accessibility — the content update is not detected by screenreaders, so their users would not know what is going on. This is a fairly trivial example, but just imagine if you were creating a complex UI with lots of constantly updating content, like a chat room, or a strategy game UI, or a live updating shopping cart display — it would be impossible to use the app in any effective way without some kind of way of alerting the user to the updates.

+ +

WAI-ARIA fortunately provides a useful mechanism to provide these alerts — the aria-live property. Applying this to an element causes screenreaders to read out the content that is updated. How urgently the content is read out depends on the attribute value:

+ + + +

We'd like you to take a copy of aria-no-live.html and quotes.json, and update your <section> tag as follows:

+ +
<section aria-live="assertive">
+ +

This will cause a screenreader to read out the content as it is updated.

+ +
+

Note: Most browsers will throw a security exception if you try to do an XMLHttpRequest call from a file:// URL, e.g. if you just load the file by loading it directly into the browser (via double clicking, etc.). To get it to run, you will need to upload it to a web server, for example using GitHub, or a local web server like Python's SimpleHTTPServer.

+
+ +

There is an additional consideration here — only the bit of text that updates is read out. It might be nice if we always read out the heading too, so the user can remember what is being read out. To do this, we can add the aria-atomic property to the section. Update your <section> tag again, like so:

+ +
<section aria-live="assertive" aria-atomic="true">
+ +

The aria-atomic="true" attribute tells screenreaders to read out the entire element contents as one atomic unit, not just the bits that were updated.

+ +
+

Note: You can see the finished example at aria-live.html (see it running live).

+
+ +
+

Note: The aria-relevant property is also quite useful for controlling what gets read out when a live region is updated. You can for example only get content additions or removals read out.

+
+ +

Enhancing keyboard accessibility

+ +

As discussed in a few other places in the module, one of the key strengths of HTML with respect to accessibility is the built-in keyboard accessibility of features such as buttons, form controls, and links. Generally, you are able to use the tab key to move between controls, the Enter/Return key to select or activate controls, and occasionally other controls as needed (for example the up and down cursor to move between options in a <select> box).

+ +

However, sometimes you will end up having to write code that either uses non-semantic elements as buttons (or other types of control), or uses focusable controls for not quite the right purpose. You might be trying to fix some bad code you've inherited, or you might be building some kind of complex widget that requires it.

+ +

In terms of making non-focusable code focusable, WAI-ARIA extends the tabindex attribute with some new values:

+ + + +

We discussed this in more detail and showed a typical implementation back in our HTML accessibility article — see Building keyboard accessibility back in.

+ +

Accessibility of non-semantic controls

+ +

This follows on from the previous section — when a series of nested <div>s along with CSS/JavaScript is used to create a complex UI-feature, or a native control is greatly enhanced/changed via JavaScript, not only can keyboard accessibility suffer, but screenreader users will find it difficult to work out what the feature does if there are no semantics or other clues. In such situations, ARIA can help to provide those missing semantics.

+ +

Form validation and error alerts

+ +

First of all, let's revisit the form example we first looked at in our CSS and JavaScript accessibility article (read Keeping it unobtrusive for a full recap). At the end of this section we showed that we have included some ARIA attributes on the error message box that appears when there are validation errors when you try to submit the form:

+ +
<div class="errors" role="alert" aria-relevant="all">
+  <ul>
+  </ul>
+</div>
+ + + +

We could go further with our ARIA usage, and provide some more validation help. How about indicating whether fields are required in the first place, and what range the age should be?

+ +
    +
  1. At this point, take a copy of our form-validation.html and validation.js files, and save them in a local directory.
    2. +
  2. Open them both in a text editor and have a look at how the code works.
    3. +
  3. First of all, add a paragraph just above the opening <form> tag, like the one below, and mark both the form <label>s with an asterisk. This is normally how we mark required fields for sighted users. + 
    <p>Fields marked with an asterisk (*) are required.</p>
    +
    4. +
  4. This makes visual sense, but it isn't as easy to understand for screenreader users. Fortunately, WAI-ARIA provides the aria-required attribute to give screenreaders hints that they should tell users that form inputs need to be filled in. Update the <input> elements like so: + 
    <input type="text" name="name" id="name" aria-required="true">
+
+<input type="number" name="age" id="age" aria-required="true">
    +
    5. +
  5. If you save the example now and test it with a screenreader, you should hear something like "Enter your name star, required, edit text".
    6. +
  6. It might also be useful if we give screenreader users and sighted users an idea of what the age value should be. This is often presented as a tooltip, or placeholder inside the form field perhaps. WAI-ARIA does include aria-valuemin and aria-valuemax properties to specify min and max values, but these currently don't seem very well supported; a better supported feature is the HTML5 placeholder attribute, which can contain a message that is shown in the input when no value is entered, and is read out by a number of screenreaders. Update your number input like this: + 
    <input type="number" name="age" id="age" placeholder="Enter 1 to 150" aria-required="true">
    +
    7. +
+ +
+

Note: You can see the finished example live at form-validation-updated.html.

+
+ +

WAI-ARIA also enables some advanced form labelling techniques, beyond the classic {{htmlelement("label")}} element. We already talked about using the aria-label property to provide a label where we don't want the label to be visible to sighted users (see the {{anch("Signposts/Landmarks")}} section, above). There are some other labelling techniques that use other properties such as aria-labelledby if you want to designate a non-<label> element as a label or label multiple form inputs with the same label, and aria-describedby, if you want to associate other information with a form input and have it read out as well. See WebAIM's Advanced Form Labeling article for more details.

+ +

There are many other useful properties and states too, for indicating the status of form elements. For example, aria-disabled="true" can be used to indicate that a form field is disabled. Many browsers will just skip past disabled form fields, and they won't even be read out by screenreaders, but in some cases they will be perceived, so it is a good idea to include this attribute to let the screenreader know that a disabled input is in fact disabled.

+ +

If the disabled state of an input is likely to change, then it is also a good idea to indicate when it happens, and what the result is. For example, in our form-validation-checkbox-disabled.html demo there is a checkbox that when checked, enables another form input to allow further information be entered. We've set up a hidden live region:

+ +
<p class="hidden-alert" aria-live="assertive"></p>
+ +

which is hidden from view using absolute positioning. When this is checked/unchecked, we update the text inside the hidden live region to tell screenreader users what the result of checking this checkbox is, as well as updating the aria-disabled state, and some visual indicators too:

+ +
function toggleMusician(bool) {
+  var instruItem = formItems[formItems.length-1];
+  if(bool) {
+    instruItem.input.disabled = false;
+    instruItem.label.style.color = '#000';
+    instruItem.input.setAttribute('aria-disabled', 'false');
+    hiddenAlert.textContent = 'Instruments played field now enabled; use it to tell us what you play.';
+  } else {
+    instruItem.input.disabled = true;
+    instruItem.label.style.color = '#999';
+    instruItem.input.setAttribute('aria-disabled', 'true');
+    instruItem.input.removeAttribute('aria-label');
+    hiddenAlert.textContent = 'Instruments played field now disabled.';
+  }
+}
+ +

Describing non-semantic buttons as buttons

+ +

A few times in this course already, we've mentioned the native accessibilty of (and the accessibility issues behind using other elements to fake) buttons, links, or form elements (see UI controls in the HTML accessibility article, and {{anch("Enhancing keyboard accessibility")}}, above). Basically, you can add keyboard accessibility back in without too much trouble in many cases, using tabindex and a bit of JavaScript.

+ +

But what about screenreaders? They still won't see the elements as buttons. If we test our fake-div-buttons.html example in a screenreader, our fake buttons will be reported using phrases like "Click me!, group", which is obviously confusing.

+ +

We can fix this using a WAI-ARIA role. Make a local copy of fake-div-buttons.html, and add role="button" to each button <div>, for example:

+ +
<div data-message="This is from the first button" tabindex="0" role="button">Click me!</div>
+ +

Now when you try this using a screenreader, you'll have buttons be reported using phrases like "Click me!, button" — much better.

+ +
+

Note: Don't forget however that using the correct semantic element where possible is always better. If you want to create a button, and can use a {{htmlelement("button")}} element, you should use a {{htmlelement("button")}} element!

+
+ +

Guiding users through complex widgets

+ +

There are a whole host of other roles that can identify non-semantic element structures as common UI features that go beyond what's available in standard HTML, for example combobox, slider, tabpanel, tree. You can see a number of userful examples in the Deque university code library, to give you an idea of how such controls can be made accessible.

+ +

Let's go through an example of our own. We'll return to our simple absolutely-positioned tabbed interface (see Hiding things in our CSS and JavaScript accessibility article), which you can find at Tabbed info box example (see source code).

+ +

This example as-is works fine in terms of keyboard accessibility — you can happily tab between the different tabs and select them to show the tab contents. It is also fairly accessible too — you can scroll through the content and use the headings to navigate , even if you can't see what is happening on screen. It is however not that obvious what the content is — a screenreader currently reports the content as a list of links, and some content with three headings. It doesn't give you any idea of what the relationship is between the content. Giving the user more clues as to the structure of the content is always good.

+ +

To improve things, we've created a new version of the example called aria-tabbed-info-box.html (see it running live). We've updated the structure of the tabbed interface like so:

+ +
<ul role="tablist">
+  <li class="active" role="tab" aria-selected="true" aria-setsize="3" aria-posinset="1" tabindex="0">Tab 1</li>
+  <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="2" tabindex="0">Tab 2</li>
+  <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="3" tabindex="0">Tab 3</li>
+</ul>
+<div class="panels">
+  <article class="active-panel" role="tabpanel" aria-hidden="false">
+    ...
+  </article>
+  <article role="tabpanel" aria-hidden="true">
+    ...
+  </article>
+  <article role="tabpanel" aria-hidden="true">
+    ...
+  </article>
+</div>
+ +
+

Note: The most striking change here is that we've removed the links that were originally present in the example, and just used the list items as the tabs — this was done because it makes things less confusing for screenreader users (the links don't really take you anywhere; they just change the view), and it allows the setsize/position in set features to work better — when these were put on the links, the browser kept reporting "1 of 1" all the time, not "1 of 3", "2 of 3", etc.

+
+ +

The new features are as follows:

+ + + +

In our tests, this new structure did serve to improve things overall. The tabs are now recognised as tabs (e.g. "tab" is spoken by the screenreader), the selected tab is indicated by "selected" being read out with the tab name, and the screenreader also tells you which tab number you are currently on. In addition, because of the aria-hidden settings (only the non-hidden tab ever has aria-hidden="false" set), the non-hidden content is the only one you can navigate down to, meaning the selected content is easier to find.

+ +
+

Note: If there is anything you explicitly don't want screen readers to read out, you can give them the aria-hidden="true"  attribute.

+
+ +

Summary

+ +

This article has by no means covered all that's available in WAI-ARIA, but it should have given you enough information to understand how to use it, and know some of the most common patterns you will encounter that require it.

+ +

See also

+ + + +

{{PreviousMenuNext("Learn/Accessibility/CSS_and_JavaScript","Learn/Accessibility/Multimedia", "Learn/Accessibility")}}

+ +

In this module

+ + diff --git a/files/fr/apprendre/a11y/what_is_accessibility/index.html b/files/fr/apprendre/a11y/what_is_accessibility/index.html new file mode 100644 index 0000000000..047e2763a1 --- /dev/null +++ b/files/fr/apprendre/a11y/what_is_accessibility/index.html @@ -0,0 +1,198 @@ +--- +title: Qu'est ce que l'accessibilité? +slug: Apprendre/a11y/What_is_accessibility +tags: + - Accessibilité + - Aide technique + - Apprendre + - Article + - CSS + - Clavier + - Débutant + - HTML + - JavaScript + - Lecteur d'écran + - Outils + - Utilisateurs +translation_of: Learn/Accessibility/What_is_accessibility +--- +
{{LearnSidebar}}
+ +
{{NextMenu("Learn/Accessibility/HTML", "Learn/Accessibility")}}
+ +

Cet article présente un module général sur ce que l'accessibilité est actuellement — Cela comprend les groupes de personnes que l'on a besoin de considérer et pourquoi, quels outils ils utilisent afin d'intéragir avec les pages web et comment rendre accessible la partie de notre espace de travail web.

+ + + + + + + + + + + + +
Prérequis:Compétences de base en informatique, une compréhension basique de l'HTML et du CSS.
Objectif:Se familiariser avec l'accessibilité en découvrant ce que c'est et en quoi cela vous affecte en tant que développeur.
+ +

Qu'est-ce donc que l'accessibilité?

+ +

L'accessibilité est la mise à disposition de vos sites web au plus grand nombre. On pense souvent que cela s'adresse aux personnes ayant un handicap, mais cela concerne également d'autres groupes comme ceux utilisant des appareils mobiles ou ceux qui ont des connexions internet de faible débit.

+ +

On peut aussi dire que l'accessibilité c'est traiter tout le monde de la même manière, et donner les mêmes opportunités à tous, peu importe leur handicaps ou les circonstances. De la même manière qu'il est injuste d'empêcher une personne d'accéder à un bâtiment parce qu'elle est en fauteuil roulant (les lieux publics sont souvent équipés de rampes d'accès ou d'ascenseur de nos jours), il est également injuste d'empêcher une personne d'accéder à un site web parce qu'elle a des troubles de la vue, ou qu'elle utilise un téléphone portable. Nous sommes tous différents, mais nous sommes aussi tous humains, ce qui nous donne les mêmes droits.

+ +

Rendre son site accessible est la bonne chose à faire, mais c'est aussi demandé par la loi de certains pays, et cela peut vous ouvrir des marchés conséquents pour qui vos services et vos produits ne seraient sinon pas accessibles.

+ +

L'accessibilité et les bonnes pratiques qu'elle implique peuvent bénéficier à tous :

+ + + +

Quel genre de handicap devons nous envisager ?

+ +

Les personnes ayant un handicap sont aussi variées que les personnes sans handicap, tout comme leurs handicaps. L'important ici est de ne pas penser seulement à votre propre ordinateur et à comment vous utilisez le web, mais de commencer à apprendre comment les autres l'utilisent — vous n'êtes pas vos utilisateurs. Les principaux types de handicap à considérer sont expliqués ci-dessous, avec les outils spéciaux que chacun utilise pour accéder aux contenus du web (connus sous le nom de technologies d'assistance).

+ +
+

Note : L'aide-mémoire Handicap et santé de l'Organisation Mondiale de la Santé indique que « Plus d’un milliard de personnes, c’est-à-dire environ 15% de la population mondiale, présentent une forme ou une autre de handicap » , et que « Entre 110 et 190 millions de personnes adultes ont des difficultés importantes sur le plan fonctionnel. »

+
+ +

Les personnes ayant des troubles de la vue

+ +

Cette catégorie comprend les personnes aveugles, malvoyantes, daltoniennes, etc. Beaucoup d'entre eux utilisent des agrandisseurs d'écran (soit de vraies loupes, soit la fonction loupe implémentée dans la plupart des systèmes d'exploitation et navigateurs), et certains utilisent des lecteurs d'écran qui lisent le texte à voix haute:

+ + + +

Il est conseillé de se familiariser avec les lecteurs d'écran ; vous devriez installer un lecteur d'écran et expérimenter avec pour comprendre comment il marche. Lisez notre Guide pour tester les lecteurs d'écrans sur différents navigateurs (en) pour avoir plus d'information sur leur utilisation. La vidéo ci-dessous (en anglais) vous donne un bref aperçu de l'experience.

+ +

{{EmbedYouTube("IK97XMibEws")}}

+ +

Pour ce qui est des statistiques, l'Organisation mondiale de la santé estime que «253 millions de personnes présentent une déficience visuelle : 36 millions d’entre elles sont aveugles et 217 millions présentent une déficience visuelle modérée à sévère. » (Voir Cécité et déficience visuelle). Cela représente une part conséquente des utilisateurs que vous perdriez parce que votre site est mal codé — presque autant que la population des États-Unis.

+ +

Les personnes ayant des troubles de l'audition

+ +

Aussi connues comme les personnes malentendantes ou sourdes, ce groupe correspond aux personnes qui ont perdu, partiellement ou totalement, la perception des sons. Les sourds et malentendants utilisent des technologies d'assistance (voir Aides techniques pour les personnes ayant des troubles de l'audition, de la voix, de la parole ou du langage (en) ), mais il n'existe pas de technologies spécifiques pour l'utilisation du Web et des ordinateurs.

+ +

Il existe cependant des techniques auxquelles il faut penser pour proposer des alternatives aux fichiers audios : de la simple transcription textuelle aux sous-titres qui peuvent être affichés en même temps que la vidéo. Un article décrira plus tard ces méthodes.

+ +

Les sourds et malentendants représentent également une part significative des utilisateurs — «360 millions de personnes dans le monde souffrent de déficience auditive incapacitante», indique l'aide-mémoire Surdité et déficience auditive de l'Organisation Mondiale de la Santé.

+ +

Les personnes ayant des troubles de la mobilité

+ +

Ces personnes ont un handicap ayant rapport au mouvement, qui peuvent comprendre des problèmes purement physique (comme la perte d'un membre ou la paralysie), ou des troubles psychologiques ou génétiques qui mènent à des faiblesse voire à une perte du contrôle des membres. Certains ont des difficultés à exécuter les mouvements précis de la main nécessaires à l'utilisation d'une souris, tandis que d'autres peuvent être plus sérieusement atteints, voire même être paralysés au point d'avoir à utiliser un pointeur frontal pour utiliser un ordinateur.

+ +

Ce genre de handicap peut aussi venir avec l'âge, et non d'un accident ou d'une pathologie particulière, ou encore être la conséquence de limitations matérielles — certains utilisateurs peuvent ne pas avoir de souris.

+ +

En général, cela se traduit au niveau du développement web par la nécessité de rendre les contrôles accessible au clavier — nous discuterons de l'accessibilité au clavier plus tard dans d'autres articles du module, mais cela peut être une bonne idée d'essayer de naviguer sur certains sites en utilisant seulement le clavier. Par exemple, pouvez vous naviguer entre les différents champs d'un formulaire juste avec la touche Tab ? Vous trouverez plus de détails à propos de l'utilisation du clavier dans la section Test d'accessibilité avec le clavier intégré entre différents navigateurs(en).

+ +

De nombreuses personnes souffrent de troubles de la mobilité. Par exemple, en France, 4% des personnes vivant en ménage ordinaire déclarent avoir des difficultés à se servir des mains et doigts, d'après la vue d'ensemble L'approche du handicap par les limitations fonctionnelles et la restriction globale d'activité chez les adultes de 20 à 59 ans de l'INSEE.

+ +

Personnes ayant des déficiences cognitives

+ +

La dernière catégorie d'incapacités est probablement la plus large. Les déficiences cognitives désignent généralement des incapacités allant des maladies mentales aux difficultés d'apprentissage, aux difficultés de compréhension et de concentration telles que  TDAH-trouble d'hyperactivité avec déficit de l'attention, TSA-trouble du spectre de l’autisme,  aux personnes atteintes de schizophrénie, et à de nombreux autres types de désordres, qui peuvent affecter de nombreux aspects de la vie quotidienne en raison de problèmes de mémoire, de résolution de problèmes, de compréhension, d'attention, etc. 

+ +

Le plus souvent, ces incapacités peuvent affecter l'utilisation du site web : difficulté à comprendre comment effectuer une tâche, à se rappeler comment effectuer une tâche déjà accomplie ou à une frustration accrue en cas de confusion dans les flux de travail ou d'incohérences dans la présentation / navigation / autre page.

+ +

Contrairement à d’autres problèmes d’accessibilité web, il est impossible de prescrire des solutions rapides à de nombreux problèmes d’accessibilité web résultant de déficiences cognitives ; la meilleure chance que vous ayez est de concevoir vos sites web de manière à être aussi logiques, cohérents et utilisables que possible. Par exemple, assurez-vous que :

+ + + +

Ce ne sont pas des "techniques d'accessibilité" en tant que telles, ce sont de bonnes pratiques de conception. Elles profiteront à tous ceux qui utilisent vos sites et devraient faire partie intégrante de votre travail.

+ +

En termes de statistiques, encore une fois, les chiffres sont importants. Le  rapport 2014 sur le statut d'invalidité (PDF, 511KB) de l'Université de Cornell indique qu'en 2014, 4,5% des Américains âgés de 21 à 64 ans présentaient une forme de déficience cognitive .

+ +
+

Note :  La page cognitives de apprendreaeduquer fournit une extension utile de ces idées et mérite certainement d'être lue. 

+
+ +

Implémentation de l'accessibilité dans votre projet

+ +

Un mythe commun en matière d'accessibilité est que l'accessibilité est un "supplément" coûteux à mettre en œuvre sur un projet. Ce mythe peut en réalité être vrai si :

+ + + +

Cependant, si vous envisagez l'accessibilité dès le début d'un projet, le coût de la plupart des contenus accessibles devrait être assez minime.

+ +

Lors de la planification de votre projet, tenez compte des tests d'accessibilité dans votre programme de tests, comme pour tout autre segment d'audience cible important (par exemple, les navigateurs de bureau ou mobiles cibles). Testez tôt et souvent, en exécutant idéalement des tests automatisés pour détecter les fonctionnalités manquantes détectables par programme (telles que les images manquantes  alternative text  ou le texte du lien incorrect — voir Element relationships and context), et en effectuant des tests avec des groupes d'utilisateurs désactivés pour voir comment. des fonctionnalités de site plus complexes fonctionnent pour eux, par exemple:

+ + + +

Vous pouvez et devez garder une note sur les problèmes potentiels de votre contenu qui devront être redessinés pour le rendre accessible, assurez-vous qu'il a été testé minutieusement et réfléchissez aux solutions / alternatives. Le contenu textuel (comme vous le verrez dans le prochain article) est simple, mais qu'en est-il de votre contenu multimédia et de vos graphismes 3D fantastiques ? Vous devriez examiner le budget de votre projet et réfléchir de manière réaliste aux solutions disponibles pour rendre ce contenu accessible ? Vous pourriez avoir à payer pour que tout votre contenu multimédia soit transcrit, ce qui peut être coûteux, mais réalisable.

+ +

Aussi, soyez réaliste. "100% d'accessibilité" est un idéal impossible à obtenir — vous rencontrerez toujours un type de problème qui oblige un utilisateur à trouver certains contenus difficiles à utiliser — mais vous devez en faire autant que vous le pouvez. Si vous envisagez d'inclure un graphique à secteurs 3D ultra-graphique créé à l'aide de WebGL, vous pouvez inclure un tableau de données en tant que représentation alternative accessible des données. Vous pouvez également simplement inclure la table et supprimer le graphique à secteurs 3D : la table est accessible à tous, plus rapide à coder, moins gourmande en temps processeur et plus facile à gérer. 

+ +

D'autre part, si vous travaillez sur un site web de galerie présentant des œuvres d'art 3D intéressantes, il serait déraisonnable de s'attendre à ce que chaque œuvre d'art soit parfaitement accessible aux personnes malvoyantes, étant donné qu'il s'agit d'un support entièrement visuel.

+ +

Pour montrer que vous vous souciez de l'accessibilité et que vous en avez pensé, publiez sur votre site une déclaration d'accessibilité détaillant votre politique en matière d'accessibilité et les mesures que vous avez prises pour rendre le site accessible. Si quelqu'un se plaint de ce que votre site a un problème d'accessibilité, commencez un dialogue avec elle, faites preuve d'empathie et prenez les mesures qui s'imposent pour tenter de résoudre le problème.

+ +
+

Note :  Notre article  Gérer les problèmes courants d'accessibilité couvre les spécificités d'accessibilité qui doivent être testées plus en détail.

+
+ +

Résumer :

+ + + +

Directives d'accessibilité et loi

+ +

Il existe de nombreuses listes de contrôle et ensembles de directives disponibles sur lesquels baser les tests d'accessibilité, ce qui peut sembler fastidieux à première vue. Notre conseil est de vous familiariser avec les domaines fondamentaux dans lesquels vous devez prendre soin, ainsi que de comprendre les structures de haut niveau des directives qui vous sont le plus utiles.

+ + + +

Ainsi, alors que le WCAG est un ensemble de directives, votre pays aura probablement des lois régissant l’accessibilité du Web, ou du moins l’accessibilité des services accessibles au public (sites web, télévision, espaces physiques, etc.). C’est une bonne idée. pour savoir quelles sont vos lois. Si vous ne faites aucun effort pour vérifier que votre contenu est accessible, vous pourriez éventuellement avoir des ennuis avec la loi si les personnes handicapées s'en plaignent.

+ +

Cela semble sérieux, mais vous devez vraiment considérer l'accessibilité comme une priorité principale de vos pratiques de développement web, comme indiqué ci-dessus. En cas de doute, demandez conseil à un avocat qualifié. Nous n'allons pas donner plus de conseils que cela, car nous ne sommes pas des avocats.

+ +

API d'accessibilité

+ +

Les navigateurs web utilisent des API d’accessibilité spéciales (fournies par le système d’exploitation sous-jacent) qui présentent des informations utiles pour les technologies d’aide (TA) — les TA ont généralement tendance à utiliser des informations sémantiques. Ces informations ne comprennent donc pas les informations de style, ou JavaScript. Ces informations sont structurées dans une arborescence d'informations appelée arborescence d'accessibilité.

+ +

Différents systèmes d'exploitation ont différentes API d'accessibilité disponibles :

+ + + +

Lorsque les informations sémantiques natives fournies par les éléments HTML dans vos applications Web tombent, vous pouvez les compléter avec des fonctionnalités de la  WAI-ARIA specification,  qui ajoutent des informations sémantiques à l’arbre d’accessibilité pour améliorer l’accessibilité. Vous pouvez en apprendre beaucoup plus sur WAI-ARIA dans notre article sur les bases de WAI-ARIA basics.

+ +
+

Résumé

+
+ +

Cet article aurait dû vous donner une vue d'ensemble utile de haut niveau de l'accessibilité, vous expliquer pourquoi c'est important et voir comment vous pouvez l'intégrer à votre flux de travail. Vous devriez maintenant aussi avoir soif d'apprendre les détails de la mise en œuvre susceptibles de rendre des sites accessibles. Nous commencerons dans cette question dans la section suivante, en nous demandant pourquoi le HTML constitue une bonne base d'accessibilité.

+ +

{{NextMenu("Learn/Accessibility/HTML", "Learn/Accessibility")}}

-- cgit v1.2.3-54-g00ecf