Les règles Web Content Accessibility Guidelines (WCAG) 2.1, établies par un groupe de travail du consortium World Wide Web, constituent un ensemble de règles et de critères de réussite, indépendants de la technologie, permettant d’obtenir des contenus web accessibles et utilisables par les personnes en situation de handicap.
En introduction, le consortium propose une série de sections et de documents annexes :
En outre, voir :
Les règles sont classées selon trois niveaux de conformité : niveau A (le plus bas), niveau AA et niveau AAA (le plus élevé). Pour résumer, les niveaux sont définis comme suit :
Lors de la création de votre site, vous devez déterminer à quel niveau général il doit se conformer.
La section suivante présente les différents aspects des règles WCAG 2.1 ainsi que les critères de réussite associés aux niveaux de conformité A et AA.
Dans ce document, nous utilisons :
Le contenu d’une page web peut être proposé dans différents formats non textuels (photos, vidéos, animations, tableaux et graphiques). Les personnes aveugles ou malvoyantes ne sont pas en mesure de voir le contenu non textuel, mais elles peuvent accéder au contenu textuel en le faisant lire par un lecteur d’écran ou sous forme tactile dans un appareil d’affichage en braille. Ainsi, en proposant des équivalents textuels pour le contenu graphique, les personnes qui ne voient pas le contenu graphique peuvent accéder à une version équivalente des informations véhiculées par le contenu.
Autre avantage utile : les équivalents textuels permettent aux moteurs de recherche d’indexer le contenu non textuel.
Pour les images statiques, la règle de base consiste à fournir un équivalent textuel. Vous pouvez, pour ce faire, utiliser le champ Texte de remplacement ; voir, par exemple, la section du composant principal Image.
Certains composants principaux prêts à l’emploi, tels que Carrousel, ne fournissent pas de champ Texte de remplacement pour ajouter des descriptions de texte de remplacement à des images individuelles. Il existe cependant le champ Étiquette (onglet Accessibilité) pour l’ensemble du composant.
Lors de l’implémentation de ces versions pour votre instance AEM, votre équipe de développement devra configurer ces composants pour prendre en charge l’attribut alt
afin que les auteurs puissent l’ajouter au contenu (voir Ajout de la prise en charge d’éléments et d’attributs HTML supplémentaires).
Certains composants principaux prêts à l’emploi, tels que Carrousel, ne fournissent pas de champ Texte de remplacement pour ajouter des descriptions de texte de remplacement à des images individuelles. Il existe cependant le champ Étiquette (onglet Accessibilité) pour l’ensemble du composant.
Lors de l’implémentation de ces versions pour votre instance AEM, votre équipe de développement devra configurer ces composants pour prendre en charge l’attribut alt
afin que les auteurs puissent l’ajouter au contenu (voir Ajout de la prise en charge d’éléments et d’attributs HTML supplémentaires).
Dans AEM, le champ Texte secondaire doit être renseigné par défaut. Si votre image est purement décorative et que le texte secondaire est superflu, l’option L’image est décorative peut être sélectionnée.
Il existe diverses formes de contenu non textuel. Par conséquent, la valeur du texte secondaire dépend du rôle du graphique dans la page web. Voici quelques-unes des règles de base à respecter :
Voici quelques-uns des types spécifiques de contenu non textuel auquel un texte secondaire doit être associé :
graphic
ou image
) ; l’utilisation d’éléments screenshot
ou illustration
peut clarifier les descriptions de textes de remplacement, mais cela dépend du contexte. La cohérence est un facteur important. Une décision doit être prise pour l’ensemble de l’équipe de création et appliquée tout au long de l’expérience utilisateur.Le niveau de contraste entre l’arrière-plan et le texte au premier plan doit être suffisant. Cela est décrit de manière plus détaillée à la section Contraste (minimum) (1.4.3).
Règle 1.2 – Média temporel : proposer des versions de remplacement aux médias temporels.
Cette section traite du contenu web temporel, notamment le contenu que l’utilisateur peut lire (contenu vidéo, audio et animé, par exemple) et qui peut être pré-enregistré ou en direct.
Les personnes suivantes peuvent éprouver des problèmes à accéder au contenu vidéo et audio :
Les personnes qui utilisent des navigateurs ou des périphériques qui ne prennent pas en charge la lecture du contenu dans des formats multimédias spécifiques (Adobe Flash par exemple) peuvent aussi ne pas avoir accès au contenu vidéo ou audio.
En proposant ces informations dans un autre format (texte par exemple, ou audio pour un contenu vidéo sans audio), elles seront accessibles par les personnes qui ne sont pas en mesure d’accéder au contenu original.
Si le contenu audio ou vidéo est fourni comme alternative à un contenu existant, mais dans un autre format, sur la même page web, il est possible qu’une autre alternative ne soit pas nécessaire.
Les règles, décrites par la section Présentation de WCAG 1.2.1, fournissent d’autres informations.
L’insertion d’un contenu multimédia dans vos pages web AEM est similaire à celle d’une image. Cependant, le contenu multimédia étant plus complexe qu’une image fixe, de nombreux paramètres et options sont nécessaires pour contrôler sa lecture.
Si vous utilisez un contenu multimédia informatif, vous devez également créer des liens vers les équivalents. Par exemple, pour inclure une transcription textuelle, créez une page HTML où afficher la transcription, puis ajoutez un lien en regard ou en dessous du contenu audio.
Les personnes sourdes ou malentendantes n’auront pas accès au contenu audio, ou y auront accès avec de grandes difficultés. Les sous-titres sont des équivalents textuels au contenu audio parlé et non parlé ; ils s’affichent à l’écran au moment approprié durant la vidéo. Ils permettent aux personnes qui ne peuvent pas écouter le contenu audio de comprendre ce qui se passe.
Les sous-titres peuvent être :
Ajoutez des sous-titres non intégrés chaque fois que cela est possible, car les utilisateurs peuvent ainsi décider s’ils souhaitent les afficher.
Pour les sous-titres non intégrés, vous devez créer et fournir un fichier de sous-titrage synchronisé dans un format approprié (SMIL par exemple) avec le fichier vidéo (la procédure à suivre pour ce faire ne fait pas l’objet de ce guide, mais vous trouverez des liens vers des tutoriels dans En savoir plus – Sous-titres (pré-enregistrés) (1.2.2). Pensez à inclure une note avisant les utilisateurs que des sous-titres sont disponibles pour la vidéo, ou à activer la fonctionnalité de sous-titres.
Si vous devez utiliser des sous-titres intégrés, incorporez le texte à la piste vidéo. Pour ce faire, utilisez des applications de montage vidéo qui permettent de superposer du texte sur la vidéo.
Les personnes aveugles ou malvoyantes ne pourront pas accéder au contenu si les informations contenues dans une vidéo ou une animation sont fournies sous forme visuelle seulement ou si la piste audio ne fournit pas suffisamment d’informations pour comprendre ce qui se passe visuellement.
Deux approches peuvent être adoptées pour remplir ce critère de réussite. Les deux sont acceptables :
Les détails exacts de la création de vidéos avec description audio ne font pas partie de ce guide. La création de descriptions vidéo et audio peut prendre du temps, mais d’autres produits Adobe peuvent vous aider à accomplir ces tâches.
Ce critère de réussite est identique aux Sous-titres (pré-enregistrés), du fait qu’il résout les obstacles à l’accessibilité pour les personnes sourdes ou malentendantes ; toutefois, il traite des présentations en direct du type webcast.
Suivez les instructions de la section Sous-titres (pré-enregistrés) ci-dessus. Toutefois, en raison de la nature du média (direct), les sous-titres doivent être créés aussi rapidement que possible, en fonction de ce qui se passe dans la vidéo. Par conséquent, envisagez d’utiliser des outils de sous-titrage en temps réel ou de transcription voix-texte.
Ce document ne vise pas à fournir des instructions détaillées à ce sujet, mais vous trouverez des renseignements utiles en suivant les liens ci-après :
Ce critère de réussite est identique au critère Audio-description ou version de remplacement pour un média temporel (pré-enregistré), excepté que les auteurs doivent fournir une audio-description beaucoup plus détaillée, conforme au niveau AA.
Suivez les instructions de la section Audio-description ou version de remplacement pour un média temporel (pré-enregistré).
Cette règle couvre les exigences nécessaires pour aider les personnes qui :
peuvent ne pas être en mesure d’accéder aux informations présentées par un auteur dans la présentation par défaut de ce contenu (par exemple, une mise en page à plusieurs colonnes ou une page utilisant intensivement des couleurs et/ou des images).
utilisent peut-être un contenu audio uniquement ou un affichage visuel de remplacement, par exemple un contraste élevé ou une grande taille de texte.
Nombre des technologies d’assistance auxquelles ont recours les personnes en situation de handicap s’appuient sur des informations structurelles pour afficher efficacement le contenu ou le rendre plus intelligible. Ces informations structurelles peuvent se présenter sous forme de titres de page, de titres de lignes et de colonnes de tableau et de types de liste. Par exemple, un utilisateur peut recourir à un lecteur d’écran pour parcourir une page d’un titre à un autre. Cependant, si le contenu d’une page semble s’appuyer exclusivement sur une structure de style visuel plutôt que sur le code HTML sous-jacent, aucune information structurelle n’est disponible pour les technologies d’assistance, ce qui limite leur capacité à faciliter la navigation.
Ce critère de réussite vise à garantir que de telles informations structurelles sont fournies par programmation dans le code HTML, ou d’autres techniques de codage, de sorte que les navigateurs et les technologies d’assistance puissent y accéder pour les exploiter.
AEM facilite la construction de pages web significatives au sens sémantique à l’aide des éléments HTML appropriés. Ouvrez le contenu de la page dans l’éditeur de texte enrichi (un composant Texte) et, à l’aide du menu Paraformat (symbole du paragraphe), spécifiez l’élément structurel approprié (paragraphe, en-tête, etc.).
Veillez à ce que vos pages web aient la structure appropriée en utilisant, le cas échéant, les éléments suivants :
En-têtes : tant que les fonctionnalités d’accessibilité du RTE sont activées, AEM offre 3 niveaux d’en-tête de page. Vous pouvez les utiliser pour identifier les sections et sous-sections de contenu. En-tête 1 est le plus haut niveau d’en-tête, En-tête 3 le plus bas. L’administrateur système peut configurer le système pour autoriser l’utilisation d’un plus grand nombre de niveaux d’en-tête.
Listes : vous pouvez spécifier trois types de listes différents en HTML :
<ul>
est utilisé pour les listes non triées (à puces). Les éléments de liste individuels sont identifiés à l’aide de l’élément <li>
. Dans l’éditeur de texte enrichi, utilisez l’icône Liste à puces.<ol>
est utilisé pour les listes numérotées. Les éléments de liste individuels sont identifiés à l’aide de l’élément <li>
. Dans l’éditeur de texte enrichi, cliquez sur l’icône Liste numérotée.Pour modifier un contenu existant en un type de liste particulier, sélectionnez-le, puis choisissez le type de liste approprié. Comme dans l’exemple précédent illustrant la saisie du texte du paragraphe, les éléments de liste appropriés sont automatiquement ajoutés au fichier HTML.
En mode Plein écran, les icônes Liste à puces et Liste numérotée sont visibles. Lorsque vous n’êtes pas en mode Plein écran, les deux options sont disponibles derrière l’icône Listes unique.
Tableaux : les tableaux de données doivent être identifiés à l’aide des éléments de tableau HTML :
<table>
;<tr>
pour chaque ligne du tableau ;<th>
pour chaque en-tête de ligne et de colonne ;<td>
pour chaque cellule de données.En outre, les tableaux accessibles utilisent les éléments et attributs suivants :
<caption>
sert à fournir une légende visible pour le tableau. Les légendes apparaissent par défaut centrées au-dessus du tableau, mais peuvent être positionnées de manière appropriée à l’aide de CSS. La légende est associée au tableau par programmation, ce qui en fait une méthode utile pour fournir une introduction au contenu.<summary>
aide les utilisateurs non voyants à comprendre plus facilement les informations présentées dans un tableau, en fournissant une synthèse de ce qu’un utilisateur voyant peut voir. Cela s’avère particulièrement utile lorsque des mises en page de tableau complexes ou non conventionnelles sont utilisées (cet attribut n’est pas affiché dans le navigateur, il est uniquement lu pour les technologies d’assistance).scope
de l’élément <th>
sert à indiquer si une cellule représente un en-tête pour une ligne ou une colonne particulière. Une approche similaire consiste à utiliser les attributs header et id dans des tableaux complexes, où les cellules de données peuvent être associées à un ou plusieurs en-têtes.Par défaut, ces éléments et attributs ne sont pas directement disponibles, mais l’administrateur du système peut ajouter la prise en charge de ces valeurs dans la boîte de dialogue Propriétés du tableau (voir Ajout de la prise en charge des éléments et attributs HTML supplémentaires).
Pour ouvrir la boîte de dialogue Tableau dans laquelle vous pouvez sélectionner l’onglet Propriétés du tableau :
Vous pouvez ensuite utiliser les propriétés de cellule pour définir si la cellule est une cellule de données ou d’en-tête :
Mise en évidence : utilisez l’élément <strong>
ou <em>
pour indiquer la mise en évidence. N’utilisez pas d’en-têtes pour mettre le texte en évidence au sein des paragraphes.
Surlignez le texte à mettre en évidence.
Cliquez sur l’icône B (pour <strong>
) ou I (pour <em>
) du panneau Propriétés (HTML doit être sélectionné).
Dans une installation AEM standard, l’éditeur de texte enrichi est configuré pour utiliser :
<b>
pour <strong>
<i>
pour <em>
Ils sont identiques dans la pratique, mais <strong>
et <em>
sont préférables, car il s’agit de code HTML correct sémantiquement. Votre équipe de développement peut configurer l’éditeur de texte enrichi pour qu’il utilise <strong>
et <em>
(au lieu de <b>
et <i>
) lors du développement de votre instance de projet.
Tableaux de données complexes : dans certains cas, lorsqu’il existe des tableaux complexes comportant deux niveaux d’en-tête ou plus, les propriétés de tableau de base peuvent ne pas suffire à fournir toutes les informations structurelles nécessaires. Pour ce type de tableaux complexes, il est nécessaire de créer des relations directes entre les en-têtes et leurs cellules associées à l’aide des attributs header et id.
L’attribut id n’est pas disponible dans une installation prête à l’emploi. Il peut être activé en configurant les règles HTML et le sérialiseur dans l’éditeur de texte enrichi.
Par exemple, dans le tableau ci-dessous, les attributs header et id correspondent de façon à créer une association de programmation pour les utilisateurs de technologies d’assistance.
<table>
<tr>
<th rowspan="2" id="h">Homework</th>
<th colspan="3" id="e">Exams</th>
<th colspan="3" id="p">Projects</th>
</tr>
<tr>
<th id="e1" headers="e">1</th>
<th id="e2" headers="e">2</th>
<th id="ef" headers="e">Final</th>
<th id="p1" headers="p">1</th>
<th id="p2" headers="p">2</th>
<th id="pf" headers="p">Final</th>
</tr>
<tr>
<td headers="h">15%</td>
<td headers="e e1">15%</td>
<td headers="e e2">15%</td>
<td headers="e ef">20%</td>
<td headers="p p1">10%</td>
<td headers="p p2">10%</td>
<td headers="p pf">15%</td>
</tr>
</table>
Pour y parvenir dans AEM, vous devez ajouter la balise directement en mode d’édition de la source.
Cette fonctionnalité n’est pas immédiatement disponible dans une installation standard. Vous devez configurer les règles HTML et le sérialiseur dans l’éditeur de texte enrichi.
Ce critère de réussite a pour but de permettre à un agent utilisateur de proposer une autre présentation du contenu tout en préservant l’ordre de lecture nécessaire pour comprendre sa signification. Il est important de pouvoir déterminer par programmation au moins une séquence de contenu compréhensible. Si le contenu ne répond pas à ce critère de réussite, il est possible que les utilisateurs soient troublés ou désorientés dans le cas où la technologie d’assistance lit le contenu dans le désordre ou si d’autres feuilles de style ou modifications de mise en forme sont appliquées.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 1.3.2.
Les concepteurs concentrent généralement leurs efforts sur le côté visuel (couleur, forme, style du texte, ou position absolue ou relative d’un élément du contenu) de la présentation des informations. Même s’il peut s’agir de techniques de conception très efficaces pour véhiculer l’information (et améliorer l’accessibilité générale pour les utilisateurs sans handicap visuel, mais ayant besoin d’une meilleure accessibilité cognitive), les personnes aveugles ou malvoyantes peuvent ne pas être en mesure d’accéder à l’information nécessitant une identification visuelle des attributs (position, couleur ou forme, par exemple).
De même, les informations qui impliquent de distinguer différents sons (contenu verbalisé par un homme ou une femme, par exemple) présentent un obstacle à l’accessibilité pour les personnes malentendantes si elles ne sont pas reproduites dans un équivalent textuel du contenu audio.
Pour connaître les conditions requises en rapport avec les alternatives aux couleurs, voir Utilisation de la couleur.
Veillez à ce que les informations qui reposent sur des caractéristiques visuelles du contenu de la page soient également présentées dans un autre format.
L’utilisation de termes descriptifs est acceptable s’ils ont une signification dans un contexte non visuel. Par exemple, les termes ci-dessus et ci-dessous sont généralement acceptables, puisqu’ils impliquent respectivement le contenu juste avant ou après un élément de contenu particulier ; ils resteront donc significatifs si le contenu est lu à haute voix.
Ce critère de réussite traite spécifiquement de la perception des couleurs. Les autres formes de perception sont traitées à la règle Adaptable (1.3), comme l’accès à la couleur par programme informatique et les autres formes de codage de la présentation visuelle.
La couleur est un moyen évidemment efficace d’améliorer l’aspect esthétique des pages web ; elle est également utile pour véhiculer l’information. Toutefois, en raison de différentes déficiences visuelles (de la cécité au daltonisme), certaines personnes ne sont pas capables de distinguer certaines couleurs. Par conséquent, le codage en couleurs ne constitue pas un moyen fiable de véhiculer l’information.
Par exemple, une personne qui ne distingue pas le vert du rouge ne sera pas en mesure de distinguer différentes nuances de ces couleurs. Si elle voit ces couleurs comme une troisième couleur (marron par exemple), elle ne sera pas non plus en mesure de distinguer le rouge du vert et du marron.
En outre, les personnes qui utilisent des navigateurs qui ne reconnaissent que le texte, des périphériques d’affichage monochromes ou un imprimé en noir et blanc de la page ne verront pas les couleurs.
L’état sélectionné d’un élément d’interface (par exemple, les onglets, boutons de bascule, etc.) doit également être transmis d’une autre manière que par la couleur, et au-delà de la seule présentation visuelle. Pour ces éléments, l’utilisation supplémentaire de modèles, de formes et d’informations de programmation est utile pour créer une expérience utilisateur pleinement inclusive non limitée à un sens spécifique.
Si la couleur sert à véhiculer l’information, veillez à ce que cette information soit accessible sans recourir à la couleur.
Par exemple, assurez-vous que les informations fournies par couleur sont également fournies explicitement dans le texte.
Si la couleur est utilisée comme indice pour fournir des informations, vous devez fournir un indice visuel supplémentaire, tel que la modification du style (gras ou italique, par exemple) ou de la police. Cela aide les personnes malvoyantes ou ne percevant pas bien les couleurs à identifier l’information. Cependant, il ne peut pas être entièrement fiable, car il n’aidera pas les personnes qui ne peuvent pas voir du tout la page. Il est donc (parfois) utile de fournir du texte caché ou d’utiliser des solutions programmatiques, comme la suite de normes web ARIA (Accessible Rich Internet Applications) pour transmettre cette information à des utilisateurs non voyants.
Les personnes qui utilisent un logiciel de lecture d’écran peuvent avoir du mal à entendre la sortie vocale si d’autres fichiers audio sont lus en même temps. Cette difficulté est aggravée lorsque la sortie vocale du lecteur d’écran est basée sur un logiciel (comme la plupart aujourd’hui) et contrôlée par la même commande de volume que le son. De plus, certaines personnes atteintes de déficiences cognitives ou montrant des signes de neurodivergence peuvent être sensibles au son. Ces personnes ne pourront pas modifier le niveau de volume du contenu audio, ce qui sera très perturbant.
Il est donc important que l’utilisateur puisse désactiver le son en arrière-plan.
La maîtrise du volume englobe la possibilité de réduire le son à zéro.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 1.4.2.
Critère de réussite 1.4.3
Niveau AA
Contraste (minimum) : la présentation visuelle du texte et du texte sous forme d’image a un rapport de contraste d’au moins 4,5:1, sauf dans les cas suivants :
Pour plus d’informations, voir Présentation du contraste non textuel afin de vous assurer que les auteurs de contenu comprennent les autres exigences relatives aux éléments non textuels (notamment les icônes et les éléments d’interface).
Les personnes avec certaines déficiences visuelles peuvent ne pas être en mesure de distinguer certaines paires de couleurs à faible contraste. Elles peuvent être confrontées à des obstacles à l’accessibilité si :
Le texte simplement décoratif est exclu de ce critère de réussite.
Veillez à ce que le texte soit suffisamment contrasté par rapport à son arrière-plan. Les rapports de contraste dépendent de la taille et du style du texte en question :
N’oubliez pas que les polices peuvent différer concernant les modes de restitution du dimensionnement PT/PX/EM équivalent.
Pour la sélection des polices et du dimensionnement appropriés du contenu web, il est recommandé de faire preuve de bon sens et de privilégier la lisibilité et la convivialité.
Les sites suivants peuvent vous aider à effectuer des conversions dans d’autres unités :
Pour vérifier les rapports de contraste, utilisez un outil de contraste des couleurs, tel que l’analyseur de contraste des couleurs du groupe Paciello ou l’outil de vérification du contraste des couleurs de webAIM, afin de vérifier les paires de couleurs et de signaler les éventuels problèmes de contraste.
Par ailleurs, si l’aspect de votre page n’est pas un souci majeur, vous avez la possibilité de ne spécifier aucune couleur de texte de premier plan ou d’arrière-plan. Dans ce cas, il n’est pas nécessaire de vérifier le contraste, puisque le navigateur de l’utilisateur déterminera les couleurs du texte et de l’arrière-plan.
S’il n’est pas possible d’obtenir les niveaux de contraste recommandés, vous devez fournir un lien vers une version équivalente alternative de la page (qui ne présente aucun problème de contraste des couleurs) ou permettre à l’utilisateur de régler le contraste du jeu de couleurs de la page selon ses besoins.
Ce critère de réussite a pour but de s’assurer que le texte rendu visuellement, y compris les contrôles basés sur le texte (caractères de texte affichés pour être visibles [par rapport aux caractères de texte encore sous forme de données, en ASCII par exemple]), puisse être mis à l’échelle avec succès. Il pourra ainsi être lu directement par les personnes atteintes de déficiences visuelles légères, qui n’auront pas besoin d’une technologie d’assistance, par exemple d’une loupe. Les utilisateurs peuvent bénéficier de la mise à l’échelle de tout le contenu de la page web, mais l’élément le plus crucial est le texte.
En plus de suivre les directives données à la section Comment remplir le critère de réussite 1.4.4, vous pouvez encourager les auteurs de contenu à utiliser des largeurs et hauteurs fluides et flexibles dans leurs conceptions de page et tailles de police (par exemple, conception web réactive) pour permettre aux lecteurs de redimensionner le texte.
Les logotypes (le texte qui fait partie d’un logo ou d’un nom de marque) sont considérés comme essentiels.
Le texte sous forme d’image est souvent utilisé lorsqu’un style particulier de texte est nécessaire, tel un logotype ou si le texte a été généré à partir d’une autre source (par exemple la copie numérisée d’un document papier). Toutefois, par rapport au texte présenté en code HTML ou stylisé à l’aide d’une feuille de style CSS, il n’est pas possible de modifier la taille ou l’aspect du texte sous forme d’image, ce qui peut être nécessaire pour les personnes malvoyantes ou ayant des difficultés de lecture.
Si des images de texte doivent être utilisées, utilisez CSS pour remplacer les images de texte par du texte équivalent en HTML afin que le texte soit disponible de manière personnalisable. Pour un exemple sur la manière d’y parvenir, reportez-vous à C30: Using CSS to replace text with images of text and providing user interface controls to switch.
Il s’agit de veiller à ce que les utilisateurs puissent accéder à toutes les fonctionnalités à l’aide du clavier.
Ce critère de réussite a pour but de permettre, dans la mesure du possible, d’utiliser le contenu à l’aide d’un clavier ou d’une interface de clavier (pour pouvoir utiliser un clavier supplémentaire). Si le contenu est accessible à l’aide d’un clavier ou d’un clavier alternatif, il peut être utilisé par les personnes atteintes de déficience visuelle (qui ne peuvent pas utiliser des appareils comme les souris, qui nécessitent une coordination oculaire) ou celles qui doivent utiliser des claviers alternatifs ou des périphériques d’entrée jouant le rôle d’émulateurs de clavier. Les émulateurs de clavier comprennent des logiciels de reconnaissance vocale, des logiciels de commande par le souffle, des claviers sur écran, des logiciels de numérisation, ainsi que différents claviers alternatifs et technologies d’assistance. Les personnes malvoyantes peuvent également avoir des difficultés à suivre un pointeur et trouver son contrôle bien plus facile, voir même uniquement possible, à partir du clavier.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 2.1.1.
Ce critère de réussite a pour but de s’assurer que le contenu ne piège pas le focus au clavier dans les sous-sections du contenu d’une page web. Il s’agit d’un problème courant lorsque plusieurs formats sont combinés dans une page et générés à l’aide de plug-ins ou d’applications intégrées.
Il peut arriver que la fonctionnalité de la page web limite la cible du focus à une sous-section du contenu (par exemple, une boîte de dialogue modale). Dans ce cas, vous devez fournir une méthode permettant à un utilisateur de quitter cette sous-section de contenu (par exemple, la touche Échap ferme la boîte de dialogue modale ou un bouton Fermer ferme la boîte de dialogue modale).
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 2.1.2.
Il s’agit de s’assurer que les utilisateurs disposent d’un temps suffisant pour lire et agir.
Ce critère de réussite a pour but de s’assurer que les utilisateurs en situation de handicap disposent, chaque fois que possible, du temps nécessaire pour interagir avec le contenu web. Les personnes atteintes de déficiences visuelles (cécité, malvoyance, troubles de la dextérité) et de limitations cognitives peuvent avoir besoin d’un temps supplémentaire pour lire le contenu ou pour mettre en œuvre certaines fonctions, comme compléter des formulaires en ligne. Si les fonctions web dépendent du temps, il sera difficile pour certains utilisateurs d’effectuer l’action requise avant qu’une limite de temps soit atteinte. Dans ce cas, le service leur est inaccessible. La conception de fonctions indépendantes du temps aidera les personnes en situation de handicap à accomplir ces fonctions. La disponibilité d’options permettant de désactiver les limites de temps, de personnaliser la durée ou de demander du temps supplémentaire avant d’atteindre une limite de temps aide les utilisateurs qui en ont besoin à accomplir leurs tâches avec succès. Ces options sont répertoriées dans l’ordre le plus pratique pour l’utilisateur. Désactiver les limites de temps est préférable à la personnalisation de la durée, elle-même préférable à l’octroi d’un temps supplémentaire avant d’atteindre une limite de temps.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 2.2.1.
Remarques :
Certains utilisateurs peuvent trouver les contenus mobiles gênants, voire douloureux physiquement, ce qui crée pour eux des difficultés à se concentrer sur d’autres parties de la page. De plus, un tel contenu peut s’avérer difficile à lire pour les personnes qui ont des difficultés à suivre un texte mobile.
Selon la nature du contenu, appliquez une ou plusieurs des suggestions ci-après lorsque vous créez des pages web qui contiennent du mouvement, flashant ou clignotant :
Puisque tout contenu ne satisfaisant pas ce critère de réussite peut interférer avec la capacité de l’utilisateur à exploiter la page entière, tout le contenu présent dans la page web (qu’il soit utilisé pour satisfaire d’autres critères de réussite ou non) doit satisfaire ce critère de réussite. Voir Exigence de conformité 5 : Non-interférence.
Il arrive que le contenu qui flashe provoque des crises de photosensibilité. En appliquant ce critère de réussite, les utilisateurs concernés peuvent accéder au contenu et en prendre connaissance sans inquiétude quant au contenu qui flashe.
Veillez à ce que les techniques ci-après soient appliquées :
Cette règle permet de s’assurer que la navigation pour accéder au contenu soit simple et facile pour les utilisateurs.
Ce critère de réussite a pour but de permettre aux personnes qui naviguent de manière séquentielle dans le contenu d’accéder plus directement au contenu principal de la page web. Les pages web et les applications contiennent souvent du contenu qui s’affiche sur d’autres pages ou écrans. Parmi les exemples de blocs de contenu répétés, citons, entre autres, les liens de navigation, les graphiques de titres et les encadrés publicitaires. Concernant cette disposition, les petites sections répétées (mots individuels, expressions, liens uniques) ne sont pas considérées comme des blocs.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 2.4.1.
Ce critère de réussite aide quiconque, en situation de handicap ou non, à identifier rapidement le contenu d’une page web sans avoir à lire la page entière. Cela s’avère particulièrement utile lorsque plusieurs pages web sont ouvertes dans des onglets de navigateur, puisque le titre de la page s’affiche dans l’onglet et est donc facile à trouver.
Lorsqu’une nouvelle page HTML est créée dans AEM, vous pouvez spécifier son titre. Assurez-vous que le titre décrit le contenu et l’objectif de la page de manière adéquate, en particulier les aspects uniques, afin que les visiteurs puissent rapidement déterminer si le contenu correspond réellement à leurs besoins.
Vous pouvez également changer le titre d’une page que vous modifiez en sélectionnant : Informations sur la page - Propriétés.
Ce critère de réussite a pour but de s’assurer que, lorsque les utilisateurs naviguent de manière séquentielle dans le contenu, ils rencontrent des informations dans un ordre compatible avec la signification de ce contenu et qu’il puisse être utilisé à l’aide du clavier. Ce critère diminue la confusion en permettant aux utilisateurs de former un modèle mental cohérent du contenu. Différents ordres correspondant aux relations logiques au sein du contenu peuvent coexister. Il peut s’agir, par exemple, de parcourir des composants dans un formulaire en ligne composé de différents champs et/ou étapes, en correspondance avec les relations logiques au sein du contenu.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 2.4.3.
Pour tous les utilisateurs, en situation de handicap ou non, il est essentiel d’indiquer clairement la destination d’un lien par l’intermédiaire d’un texte de lien approprié. Les utilisateurs peuvent ainsi décider s’ils souhaitent suivre ce lien. Pour les utilisateurs voyants, un texte de lien significatif est extrêmement utile s’il existe plusieurs liens sur une page (en particulier si la page contient énormément de texte), car il indique clairement la fonctionnalité de la page cible. D’un autre côté, les utilisateurs de technologies d’assistance peuvent générer une liste de tous les liens sur une seule page, et ainsi comprendre plus facilement le texte du lien hors contexte, s’il est à la fois unique et informatif. Cependant, les personnes voyantes souffrant d’un handicap cognitif peuvent être perturbées si un lien ne donne pas suffisamment d’informations pour décrire précisément où il mène.
Avant tout, veillez à ce que l’objectif d’un lien soit clairement décrit dans le texte du lien.
Les liens doivent être formulés de manière cohérente sur toutes les pages, en particulier pour les barres de navigation. Si, par exemple, un lien vers une page spécifique est nommé Publications sur une page, il doit être nommé de la même façon sur toutes les autres pages.
Au moment de la rédaction de cet article, l’utilisation des attributs de titre pose certains problèmes. Ils ne permettent pas de s’assurer que des liens similaires présentés sur une page donnent des informations uniques sur la destination (par exemple, la mention « en savoir plus » se rapporte souvent à un ensemble de destinations différentes) :
Par conséquent, même si vous pouvez utiliser l’attribut de titre pour fournir plus de contexte sur un lien, vous devez connaître ses limites et ne pas l’utiliser comme alternative à un texte de lien approprié.
Si le lien est composé d’une image, veillez à ce que le texte secondaire de l’image décrive la destination du lien. Si, par exemple, une image de bibliothèque est définie comme lien vers les publications d’une personne, le texte secondaire doit indiquer Publications de Jean Dupont et non Bibliothèque.
Par ailleurs, si l’ancre du lien contient du texte qui décrit l’objet du lien en sus de l’image (et par conséquent que le texte apparaît le long de l’image), utilisez un attribut alt vide pour l’image :
<a href="publications.html">
<img src = "bookshelf.jpg" alt = "" />
John Smith’s publications
</a>
L’extrait de code ci-dessus est une illustration ; il est recommandé d’utiliser le composant Image.
Bien qu’il soit conseillé de fournir un texte de lien qui identifie l’objectif du lien sans avoir besoin de contexte supplémentaire, il est admis que ce n’est pas toujours possible. Il est possible d’utiliser des liens dépourvus de contexte dans les cas suivants. Un certain nombre d’exemples HTML figurent dans la section Comment remplir le critère de réussite 2.4.4.
Dans certains cas, s’il existe plusieurs liens sur une page (chacun d’eux fournit la destination d’un lien avec des détails complexes mais nécessaires), il peut être nécessaire de fournir une version alternative de la page web qui affiche exactement le même contenu, mais où le texte du lien n’est pas aussi détaillé.
Toutefois, il est possible d’utiliser des scripts de sorte qu’un texte minimal soit fourni avec le lien lui-même, mais, à l’activation d’une commande appropriée placée vers le haut de la page, que le texte du lien soit développé afin d’afficher davantage de détails. Une approche similaire consiste à utiliser une feuille de style CSS afin de masquer le lien complet pour les utilisateurs voyants, tout en l’affichant dans son intégralité pour les utilisateurs d’un lecteur d’écran. Cela ne fait pas partie du sujet de ce document ; toutefois, vous en apprendrez davantage dans la section En savoir plus – Fonction du lien (selon le contexte) (2.4.4).
Ce critère de réussite a pour but de permettre aux utilisateurs de localiser le contenu de la manière la mieux adaptée à leurs besoins. Ils peuvent considérer qu’une technique est plus facile à utiliser ou plus compréhensible qu’une autre.
Même les petits sites devraient offrir aux utilisateurs un moyen de s’orienter. Pour un site comportant trois ou quatre pages, toutes liées à la page d’accueil, il peut suffire d’indiquer des liens depuis et vers la page d’accueil. Ces liens peuvent ainsi servir de carte du site.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 2.4.5.
Ce critère de réussite a pour but d’aider les utilisateurs à comprendre les informations contenues dans les pages web et leur organisation. Si les titres sont clairs et descriptifs, les utilisateurs peuvent trouver plus facilement les informations qu’ils recherchent et comprendre plus aisément les relations entre les différentes parties du contenu. Les libellés descriptifs aident les utilisateurs à identifier des composants spécifiques dans le contenu.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 2.4.6.
Ce critère de réussite a pour but d’aider une personne à identifier l’élément auquel correspond le focus au clavier.
Il doit être possible pour une personne d’identifier, parmi plusieurs, l’élément ayant reçu le focus au clavier. S’il n’apparaît à l’écran qu’un seul contrôle activable au clavier, le critère de réussite est satisfait, car la conception visuelle ne présente qu’un seul élément activable à l’aide du clavier.
L’indication « mode de fonctionnement » du critère de réussite concerne la prise en compte des plates-formes qui n’affichent pas toujours un indicateur de focus. Ce critère de réussite s’applique, car, dans la plupart des cas, il n’existe qu’un seul mode de fonctionnement.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 2.4.7.
Règle 3.1 – Lisible : rendre le contenu textuel lisible et compréhensible
Ce critère de réussite garantit que ce texte et tout autre contenu linguistique est correctement restitué. Pour les utilisateurs de lecteur d’écran, il garantit que le contenu est correctement prononcé, tandis que les navigateurs visuels sont plus susceptibles d’afficher correctement certains jeux de caractères.
Pour que ce critère de réussite soit satisfait, la langue par défaut d’une page web peut être identifiée à l’aide de l’attribut lang
dans l’élément <html>
en haut de la page. Par exemple :
Si une page est écrite en anglais, l’élément <html>
doit être :
<html lang = “en”>
En revanche, pour une page à restituer en espagnol, l’attribut doit être défini comme suit :
<html lang = “es”>
Dans AEM, la langue par défaut de la page est définie lors de la création de la page. Elle peut aussi être redéfinie en modifiant les propriétés de la page.
AEM offre des fonctions de réglage supplémentaires pour les variations d’une langue racine ; par exemple, l’anglais américain (en-us), l’anglais britannique (en-gb) et l’anglais canadien (en-ca). Ce niveau de détail est souvent superflu pour les technologies d’assistance, même s’il est utile pour les variantes régionales du contenu des pages.
Ce critère de réussite vise le même objectif que le critère de réussite Langue de la page, mais il s’applique aux pages web avec du contenu en plusieurs langues sur une seule page (par exemple, en raison de citations ou de mots empruntés peu courants).
Si une page applique ce critère de réussite, alors :
L’attribut lang
peut être utilisé pour identifier les modifications dans la langue du contenu. Par exemple, une citation en allemand (code ISO 639-1 "de") peut s’afficher comme suit :
<blockquote cite = "John F. Kennedy" lang = "de">
<p>Ich bin ein Berliner</p>
</blockquote>
Les attributs blockquote ne sont pas pris en charge dans une instance prête à l’emploi. Il est toutefois possible de développer un composant personnalisé pour prendre cette fonction en charge.
De même, le navigateur peut restituer correctement un mot ou une expression emprunté peu courant si l’élément span
est utilisé comme suit :
<p>The only French phrase I know is <span lang = “fr”>je ne sais quoi</code>.</p>
Il n’est pas nécessaire d’adhérer à ce critère de réussite pour les noms ou villes dans différentes langues ou lors de l’utilisation de mots ou d’expressions empruntés qui sont devenus courants dans la langue par défaut (tel que diktat en français).
Pour ajouter l’élément span, avec un langage approprié, vous pouvez modifier manuellement votre balisage HTML en mode d’édition source de l’éditeur de texte enrichi afin qu’il se lise comme ci-dessus. Vous pouvez également inclure l’attribut lang
dans l’éditeur de texte enrichi par un administrateur système (voir Ajout de la prise en charge d’éléments et d’attributs HTML supplémentaires).
Règle 3.2 – Prévisible : faire apparaître les pages web et les exploiter de manière prévisible.
Il s’agit de s’assurer que les pages web sont cohérentes en termes d’aspect et de fonctionnement.
Ce critère de réussite a pour but de s’assurer que les fonctionnalités sont prévisibles lorsque les visiteurs parcourent un document. Un composant capable de déclencher un événement lorsqu’il reçoit le focus ne doit pas modifier le contexte. Voici quelques exemples, non limitatifs, de changements de contextes lorsqu’un composant reçoit le focus :
Il est possible de déplacer le focus vers un contrôle à l’aide du clavier (par exemple, en accédant à un contrôle grâce à la touche de tabulation) ou à l’aide de la souris (par exemple, en cliquant sur un champ de texte). Le déplacement de la souris au-dessus d’un contrôle n’a aucun effet sur le focus, sauf si un script implémente ce comportement. Notez que pour certains types de contrôles, cliquer sur un contrôle revient à l’activer (par exemple, un bouton). Cette action peut, en retour, déclencher un changement de contexte.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 3.2.1.
Ce critère de réussite a pour but de s’assurer que la saisie de données ou la sélection d’un contrôle de formulaire a des effets prévisibles. La modification d’un paramètre de composant de l’interface utilisateur modifie l’un des aspects du contrôle, de manière persistante lorsque l’utilisateur n’interagit plus avec celui-ci. Ainsi, cocher une case, saisir du texte dans un champ ou modifier l’option sélectionnée dans un contrôle de liste modifie le paramétrage, alors que l’activation d’un lien ou d’un bouton le laisse inchangé. Les changements de contexte peuvent dérouter les utilisateurs s’ils ne les perçoivent pas aisément ou s’ils sont facilement déconcentrés par la modification. Un changement de contexte n’est approprié que s’il est évident qu’il se produit en réponse à l’action de l’utilisateur.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 3.2.2.
Ce critère de réussite a pour but d’encourager l’utilisation d’une présentation et d’une disposition cohérentes pour les utilisateurs qui interagissent avec du contenu répété dans un ensemble de pages web et qui ont besoin de trouver à plusieurs reprises des informations ou des fonctionnalités spécifiques. Les personnes malvoyantes qui utilisent la loupe pour agrandir une petite partie de l’écran utilisent souvent des repères visuels et des limites de pages pour localiser rapidement un contenu répété. De même, la présentation d’un contenu répété dans le même ordre est importante pour les utilisateurs visuels qui font appel à leur mémoire spatiale ou à des repères visuels dans la représentation graphique pour localiser ce contenu.
Il est important de noter que l’expression « dans le même ordre » de cette section ne signifie pas l’impossibilité d’utiliser des menus connexes, des blocs de navigation secondaires ou une structure de page complémentaire. Ce critère de réussite vise plutôt à aider les utilisateurs qui interagissent avec du contenu répété sur plusieurs pages web à prévoir l’emplacement du contenu qu’ils recherchent et à le trouver plus rapidement lorsqu’ils y reviennent.
Les utilisateurs peuvent effectuer une modification de l’ordre en faisant appel à des agents utilisateur adaptatifs ou en définissant des préférences pour que les informations soient présentées de la manière la plus utile pour eux.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 3.2.3.
Ce critère de réussite a pour but d’assurer une identification cohérente des composants fonctionnels qui apparaissent à plusieurs reprises dans un ensemble de pages web. L’une des stratégies des utilisateurs de lecteurs d’écran pour parcourir un site web consiste à s’appuyer abondamment sur leur connaissance des fonctions présentées sur différentes pages. Si des fonctions identiques comportent des libellés différents (ou, plus généralement, un nom accessible différent) selon les pages web, le site sera beaucoup plus difficile à utiliser. La situation peut en outre dérouter les personnes atteintes de limitations cognitives et accroître la charge en la matière. La définition de libellés cohérents facilitera le processus,
Cette homogénéité s’applique aussi aux alternatives textuelles. Si des icônes ou d’autres éléments non textuels ont la même fonctionnalité, leurs alternatives textuelles doivent également être cohérentes.
Si deux composants d’une page web possèdent la même fonctionnalité qu’un troisième composant d’une autre page appartenant à un ensemble de pages, ces trois composants doivent être cohérents. Ainsi, les deux composants présents sur la même page seront cohérents.
Bien qu’il soit souhaitable et recommandé de toujours garantir la cohérence pour une page web spécifique, le critère 3.2.4 ne traite que la cohérence d’un ensemble de pages web où un élément est répété dans plusieurs pages.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 3.2.4.
Ce critère de réussite a pour but de s’assurer que les utilisateurs sont conscients qu’une erreur s’est produite et qu’ils peuvent déterminer ce qui ne va pas. Le message d’erreur doit être aussi précis que possible. Dans le cas d’un envoi de formulaire infructueux, le réaffichage du formulaire et l’indication des champs erronés ne suffisent pas, pour certains utilisateurs, à percevoir qu’une erreur s’est produite. Les utilisateurs de lecteurs d’écran, par exemple, ne savent pas qu’une erreur s’est produite tant qu’ils n’ont pas identifié l’un des indicateurs. Il est possible qu’ils abandonnent complètement le formulaire avant d’identifier l’indicateur d’erreur, en pensant que la page n’est tout simplement pas fonctionnelle. Selon la définition des règles WCAG, une erreur de saisie correspond à une information fournie par l’utilisateur et qui n’est pas acceptée. Cela inclut :
les informations requises par la page web, mais omises par l’utilisateur, ou les informations fournies par l’utilisateur, mais non conformes au format de données requis ou aux valeurs autorisées.
Par exemple :
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 3.3.1.
L’ajout d’instructions pour aider les utilisateurs à remplir des formulaires est l’un des éléments essentiels afin de rendre une interface conviviale. Cela s’avère particulièrement utile pour les personnes ayant des déficiences visuelles ou cognitives qui risquent autrement d’avoir du mal à comprendre la mise en page d’un formulaire et le type de données à fournir dans un champ particulier du formulaire.
Dans le projet de démonstration AEM WKND, une étiquette par défaut est ajoutée lorsque vous ajoutez un composant de formulaire à la page, par exemple un champ de texte. Ce titre par défaut dépend du type de composant. Vous pouvez ajouter votre propre titre dans l’onglet Titre et Texte de la boîte de dialogue de modification de ce champ. Il est important de s’assurer que les étiquettes aident les utilisateurs à comprendre les données associées à chaque composant de formulaire.
Utilisez ce champ Titre pour les éléments de champ, car il fournit une étiquette accessible par les technologies d’assistance. Le simple fait d’écrire une étiquette dans le texte en regard du champ ne suffit pas.
Pour certains composants, il est également possible de masquer visuellement les étiquettes en cochant la case Masquer le titre. Les étiquettes masquées de cette façon restent accessibles aux technologies d’assistance, mais ne s’affichent pas à l’écran. Si cette approche est adaptée à certaines situations, il est généralement préférable d’inclure une étiquette visuelle chaque fois que cela est possible, car certains utilisateurs qui ne regardent qu’une très petite portion de l’écran (un champ à la fois) ont besoin des étiquettes pour identifier correctement le champ.
Lorsque des boutons d’image sont utilisés (par exemple, le composant Bouton Image du projet WKND), le champ Titre de l’onglet Titre et texte de la boîte de dialogue Modifier fournit en fait le texte secondaire de l’image, plutôt que l’étiquette. Ainsi, dans l’exemple ci-dessous, l’image avec le texte Submit
comporte le texte secondaire Submit
, ajouté à l’aide du champ Titre dans la boîte de dialogue de modification.
Dans le projet WKND, où il existe un groupe de contrôles connexes, comme Groupe de cases d’option, un titre peut être nécessaire pour le groupe, ainsi que des contrôles individuels. Lors de l’ajout d’un ensemble de boutons radio dans AEM, le champ Titre fournit le titre de ce groupe, tandis que les titres individuels sont spécifiés lors de la création des boutons radio (Éléments).
Cependant, il n’existe aucune association par programmation entre le titre du groupe et les boutons radio eux-mêmes. Les éditeurs de modèles doivent placer le titre dans les balises fieldset
et legend
nécessaires afin de créer cette association. Pour ce faire, il suffit de modifier le code source de la page. Un administrateur système peut également ajouter la prise en charge de ces éléments afin qu’ils apparaissent dans la boîte de dialogue Propriétés du champ (voir Ajout de la prise en charge d’éléments et d’attributs HTML supplémentaires).
Si les données doivent être saisies dans un format spécifique, précisez-le dans le texte du libellé. Par exemple, si une date doit être saisie au format DD-MM-YYYY
, indiquez-le spécifiquement dans le libellé. Cela signifie que lorsque les utilisateurs de lecteurs d’écran rencontrent le champ, le libellé est automatiquement annoncé, ainsi que les informations supplémentaires sur le format.
Si la saisie d’un champ de formulaire est obligatoire, indiquez-le en utilisant le mot « obligatoire » dans le libellé. AEM ajoute un astérisque lorsqu’un champ est obligatoire, mais il serait idéal d’inclure le mot required
dans le libellé lui-même (dans le champ Titre de la boîte de dialogue de modification).
Le positionnement des libellés est également important, car ils permettent de localiser les champs appropriés. Cela est tout particulièrement important lorsque l’utilisateur est confronté à un formulaire complexe. Suivez les conventions ci-dessous :
Dans les formulaires simples avec des fonctionnalités très limitées, un bouton Submit
approprié peut servir de libellé pour le champ adjacent (par exemple Search
). Cela s’avère utile dans les cas où il peut être difficile de trouver de l’espace pour le texte du libellé.
Ce critère de réussite a pour but de s’assurer que les utilisateurs reçoivent des suggestions appropriées pour corriger, si possible, une erreur de saisie. Selon les règles WCAG, une erreur de saisie indique que « l’information fournie par l’utilisateur n’est pas acceptée » par le système. À titre d’exemples de saisies non acceptées, figurent les informations requises, mais omises par l’utilisateur, et celles fournies par l’utilisateur, mais non conformes au format de données requis ou aux valeurs autorisées.
Le critère de réussite 3.3.1 prévoit la notification des erreurs. Cependant, les personnes atteintes de limitations cognitives peuvent avoir du mal à comprendre comment corriger les erreurs. Celles atteintes de déficiences visuelles ne seront peut-être pas en mesure de déterminer exactement comment corriger l’erreur. Dans le cas d’un envoi de formulaire infructueux, les utilisateurs risquent d’abandonner faute de savoir comment corriger l’erreur, même s’ils savent qu’elle s’est produite.
L’auteur du contenu peut donner la description de l’erreur ou l’agent utilisateur peut fournir la description de l’erreur en fonction d’informations spécifiques à la technologie et déterminées par programmation.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 3.3.3.
Critère de réussite 3.3.4
Niveau AA
Prévention des erreurs (juridiques, financières, données) : concernant les pages web entraînant des engagements juridiques ou des transactions financières pour l’utilisateur, qui modifient ou suppriment des données contrôlables par l’utilisateur dans les systèmes de stockage de données ou qui envoient des réponses de test de l’utilisateur, au moins l’une des conditions suivantes est vraie :
Ce critère de réussite a pour but d’aider les utilisateurs en situation de handicap à éviter les conséquences graves d’une erreur lorsqu’ils effectuent une action qui ne peut pas être annulée. Par exemple, l’achat de billets d’avion non remboursables ou le lancement d’un ordre d’achat d’actions par le biais d’un compte de courtage sont des transactions financières assorties de graves conséquences. Si un utilisateur a commis une erreur de date pour un voyage en avion, il disposera d’un billet pour le mauvais jour, sans pouvoir l’échanger. Si l’erreur concerne un nombre d’actions à acheter, l’achat concernera davantage d’actions que prévu. Ces deux types d’erreurs impliquent des transactions immédiates, non modifiables par la suite, et qui peuvent être très coûteuses. De même, il peut s’agir d’une erreur irrémédiable si les utilisateurs modifient ou suppriment involontairement des données stockées dans une base de données, à laquelle ils auront par la suite besoin d’accéder (par exemple, leur profil de voyage complet sur un site web de voyagiste). En ce qui concerne la modification ou la suppression de données « contrôlables par l’utilisateur », l’objectif est d’empêcher la perte massive de données, par exemple la suppression d’un fichier ou d’un enregistrement. L’objectif ne consiste pas à exiger une confirmation pour chaque commande d’enregistrement ou les opérations de création ou de modification simple de documents, d’enregistrements ou d’autres données.
Les utilisateurs en situation de handicap sont plus enclins à commettre des erreurs. Les personnes atteintes de difficultés de lecture peuvent avoir tendance à transposer les chiffres et les lettres, et celles souffrant de troubles moteurs à actionner des touches par erreur. La possibilité d’annuler des actions permet aux utilisateurs de corriger une erreur pouvant avoir de graves conséquences. Pouvoir vérifier et corriger des informations donne à l’utilisateur la possibilité de détecter une erreur avant d’effectuer une action d’une portée considérable.
Les données contrôlables par l’utilisateur sont des données visibles pour lui, et qu’il peut modifier ou supprimer de manière intentionnelle. À titre d’exemple, le contrôle de ces données par un utilisateur peut consister à mettre à jour le numéro de téléphone et l’adresse indiqués dans son compte ou à supprimer d’anciennes factures enregistrées sur un site web. Il ne s’agit pas d’éléments comme les données relatives à la surveillance de moteurs de recherche et de journaux Internet que l’utilisateur ne peut pas voir ni utiliser directement.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 3.3.4.
Optimiser la compatibilité avec les agents utilisateur actuels et futurs, y compris les technologies d’assistance.
Ce critère de réussite a pour but de s’assurer que les agents utilisateurs, y compris les technologies d’assistance, peuvent interpréter et analyser le contenu avec précision. Si le contenu ne peut pas être analysé dans une structure de données, différents agents utilisateurs pourraient le présenter différemment ou être complètement incapables de l’analyser. Certains agents utilisateurs utilisent des « techniques de réparation » pour restituer un contenu mal codé.
Comme les techniques de réparation varient d’un agent utilisateur à l’autre, les auteurs ne peuvent pas présumer que le contenu sera analysé avec précision dans une structure de données ou qu’il sera restitué correctement par des agents utilisateurs spécialisés, y compris les technologies d’assistance, à moins que le contenu ne soit créé selon les règles définies dans la grammaire formelle de cette technologie. Dans les langages de balisage, les erreurs de syntaxe d’éléments et d’attributs, ainsi que l’impossibilité de fournir des balises de début et de fin correctement imbriquées, entraînent des erreurs qui empêchent les agents utilisateurs d’analyser le contenu de manière fiable. Ainsi, le critère de réussite impose que le contenu puisse être analysé en utilisant uniquement les règles de la grammaire formelle.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 4.1.1.
Ce critère de réussite a pour but de s’assurer que les technologies d’assistance peuvent recueillir des informations sur le contenu, l’activer (ou le définir) et actualiser l’état des contrôles de l’interface utilisateur.
Si l’interface utilise des contrôles standard issus de technologies d’accessibilité, ce processus est simple. Si l’utilisation des éléments de l’interface utilisateur est conforme aux spécifications, les conditions de cette disposition seront remplies. (Voir les exemples relatifs au critère de réussite 4.1.2 ci-dessous)
Cependant, si des contrôles personnalisés sont créés ou si des éléments d’interface sont programmés (dans le code ou le script) avec un rôle et/ou une fonction différents de leurs caractéristiques usuelles, des mesures supplémentaires doivent être prises pour garantir que les contrôles fournissent des informations importantes aux technologies d’assistance et autorisent eux-mêmes leur contrôle par ces technologies.
L’état du focus d’un contrôle d’interface utilisateur est particulièrement important. Il est possible de déterminer cet état par programmation, et des notifications concernant le changement de focus sont envoyées aux agents utilisateurs de même qu’aux dispositifs d’assistance. Savoir si une case à cocher ou un bouton radio a été sélectionné, ou si une arborescence ou un nœud de liste réductible a été développé ou réduit, constituent d’autres exemples d’état d’un contrôle de l’interface utilisateur.
Appliquez les règles indiquées dans la section Comment remplir le critère de réussite 4.1.2.