Vous êtes ici : Accueil » Base de connaissances » Les règles d’accessibilité » Principe 4 : Robuste » Robuste : Règle 4.1 Compatible » Compatibilité avec les outils d’adaptation

Compatibilité avec les outils d’adaptation

Table des matières

Le problème

Certains types d'erreur d'encodage HTML peuvent créer des problèmes aux lecteurs d'écran.

De plus, les mécanismes permettant l'interactivité ne sont pas toujours perceptibles ou utilisables avec les technologies d'adaptation informatique. Toutes les fonctionnalités d'interactivité doivent donc être soigneusement testées avec ces outils. Lorsqu'il n'est pas possible d'assurer la compatibilité, il faut s'assurer que les contenus sont utilisables sans ces fonctionnalités, même si elles contribuent à l'enrichissement de l'expérience de l'utilisateur.

Retour en haut de page

La solution

Validation du code

  • Dans WCAG 1.0, on exigeait une validation complète du code en priorité de niveau 2.
  • Dans WCAG 2.0, cette exigence a été réduite aux types d'erreurs qui peuvent poser problème du point de vue de l'accessibilité.
  • Il faut aussi noter qu'il s'agit maintenant d'une exigence de niveau A.
  • SGQRI a adopté la même orientation en y ajoutant deux précisions : il faut un <doctype> et une utilisation sémantiquement correcte des balises.

Utilisation de JavaScript

À propos de l'utilisation de JavaScript, WCAG 1.0 est beaucoup plus sévère que WCAG 2.0 ou SGQRI-008, ce qui s'explique en partie par le fait qu'en 1999, le support de JavaScript dans les outils d'adaptation informatique était très déficient.
Dans WCAG 2.0 et dans SGQRI 008, on n'exige plus que la page demeure utilisable sans JavaScript, mais plutôt que l'utilisation de JavaScript soit compatible avec les technologies d'adaptation informatique (donc conforme au Document Object Model (DOM) du W3C). - Voir les techniques de programmation proposées par le W3C (en anglais).

Si vous utilisez des scripts :

  • Vous pouvez inscrire dans la section <noscript> un contenu équivalent à celui qui devient inaccessible sans les scripts (y compris tous les liens inutilisables sans Javascript), mais cela n'est plus obligatoire avec WCAG 2.0.
  • Il n'est pas nécessaire de placer autant de section <noscript> qu'il y a de scripts, car une seule peut suffire. Vous y regrouperez tout le contenu équivalent aux scripts.
  • Cette balise peut être placée en début ou en fin de page, selon l'utilité de son contenu, et n'apparaîtra à l'écran que lorsque JavaScript est désactivé.
  • Si les scripts n'ont qu'un effet décoratif (ex. illumination de boutons de navigation), le contenu équivalent peut n'être qu'une simple mention de cette fonction.
  • Malgré ce que l'on pourrait croire, JAWS ne donne pas accès au contenu de l'élément <noscript>, et ce, parce qu'il supporte JavaScript, même si ce support a ses limites.

Si vous utilisez des menus déroulants :

  • Si le système de navigation comporte des menus déroulants ou extensibles, mais que l'en-tête de chacun des menus conduit à une page intermédiaire où l'on trouve tous les liens contenus dans le menu déroulant, ce menu est tout de même jugé accessible, puisque l'utilisateur dispose d'un autre moyen pour accéder au même contenu.
  • Pour créer un menu déroulant ou extensible dont le contenu sera visible pour JAWS, ce contenu doit être déclaré visible au moment du chargement de la page, quitte à être masqué dans la fraction de seconde qui suit.
  • Voir les techniques SCR26 : Insérer du contenu dynamique (en anglais) et SCR37 : Créer des dialogues personnalisés.

Si vous utilisez AJAX :

Le contenu modifié de façon dynamique en utilisant la technologie AJAX doit répondre aux trois conditions suivantes :

  • Le contenu généré doit être accessible.
  • Le concepteur doit prévoir une façon d'avertir l'utilisateur de toute mise à jour du contenu.
  • L'utilisateur doit disposer d'un moyen simple de se déplacer à ce nouveau contenu.

Notes :

  1. Ce type d'information doit être transmis via une API d'accessibilité.
  2. Compte tenu de la nouveauté de ces techniques, il faudra quelques années pour qu'elles deviennent utilisables par tous les utilisateurs de technologies d'adaptation informatique, étant donné l'étalement dans le temps du processus de mise à jour des logiciels adaptés.
    Il faut donc toujours prévoir une position de repli qui permette l'accès à tout le contenu pour lequel ces fonctionnalités pourraient être considérées comme des enrichissements de l'expérience de l'utilisateur.
    Il est évidemment toujours possible de proposer une version de remplacement de ce contenu, version qui ne ferait pas appel à ce type de fonctionnalités.

Si vous utilisez des objets programmes :

  • Si vous incorporez des objets programmes à vos pages, ceux-ci doivent être accessibles avec les logiciels d'adaptation, et vous devez donc les tester pour vous en assurer.
  • La compagnie SUN a investi beaucoup d'effort pour permettre la réalisation d'applet ou d'applications Java accessibles : http://java.sun.com/products/jfc/accessibility/

Notes :

  1. Une simple recherche en français sur les mots « java » et « accessibilité » peut également vous fournir une multitude de références en français.
  2. Pour plus d'information sur les travaux du W3C concernant l'accessibilité d'AJAX et WAI-ARIA, vous pouvez consulter :
Retour en haut de page

Les règles qui s'appliquent à la compatibilité avec les outils d'adaptation

SGQRI 008-01
(site Web)		 SGQRI 008-02
(doc. téléchargeable)		 SGQRI 008-03
(multimédia)		 WCAG 2.0

10. Toute page Web doit : a) être codée selon une déclaration de type de document du W3C quant aux aspects d’imbrication, d’ouverture et de fermeture des balises ainsi que d’unicité des attributs dans une balise et des valeurs d’un attribut d’identification dans une page Web;

10. Toute page Web doit : c) coder la déclaration de type de document conformément à l’annexe 1;

16. La structure d’une page Web doit comporter : b) une description de tout cadre par un titre permettant d'en comprendre la fonction, codée conformément à l’annexe 1;

19. Tout contenu interactif présenté dans une page Web doit : a) être conçu pour que tout élément de programmation soit utilisable avec les technologies d’adaptation informatiques et avec le clavier;

 4.1.1 Analyse syntaxique : à moins que les spécifications ne le permettent, dans un contenu implémenté via un langage de balisage, les éléments ont des balises de début et de fin complètes, ils sont imbriqués conformément à leurs spécifications, ils ne contiennent pas d'attributs dupliqués et chaque ID est unique. (Niveau A)
Note: les balises de début et de fin auxquelles il manque un caractère critique, comme un chevron fermant ou un guillemet pour une valeur d'attribut, sont considérées incomplètes.

19. Tout contenu interactif présenté dans une page Web doit : d) si l’information est mise à jour sans rechargement de la page :
i. l’afficher pour qu’elle soit détectable par les technologies d’adaptation informatiques sans obligation de rafraîchir la page;
ii. informer la personne, dès l’entrée dans la page Web, d’une possibilité de mise à jour;

19. Tout contenu interactif présenté dans une page Web doit : e) être conçu pour que le nom, le rôle, les états, les propriétés et les valeurs de tout composant d'interface utilisateur soient détectables par les technologies d’adaptation informatiques et que les états, les propriétés et les valeurs puissent être modifiés par la personne utilisant ces technologies.

14. Tout contenu interactif présenté dans un document téléchargeable doit être conçu pour que tout élément de programmation soit utilisable avec les technologies d’adaptation informatiques et avec le clavier.

13. Pour les exigences particulières applicables à la navigation, toute animation Web doit : d) permettre que les éléments de navigation puissent être utilisés à l’aide des technologies d’adaptation informatiques et permettre l’accès à tout le contenu informatif dans un ordre séquentiel logique;

17. Tout contenu interactif présenté dans une animation Web doit : a) être conçu pour que tout élément de programmation soit utilisable avec les technologies d’adaptation informatiques et avec le clavier;

17. Tout contenu interactif présenté dans une animation Web doit : d) si l’information dans l’animation Web est mise à jour sans rechargement de la page qui contient cette animation Web :
i. l’afficher pour qu’elle soit détectable par les technologies d’adaptation informatiques sans obligation de rafraîchir cette page;
ii. informer la personne, dès l’entrée dans l’animation Web, d’une possibilité de mise à jour.

 4.1.2 Nom, rôle et valeur : pour tout composant d'interface utilisateur (comprenant mais n'étant pas limité aux éléments de formulaire, liens et composants générés par des scripts), le nom et le rôle peuvent être déterminés par un programme informatique ; les états, les propriétés et les valeurs qui peuvent être paramétrés par l'utilisateur peuvent être définis par programmation ; et la notification des changements de ces éléments est disponible aux agents utilisateurs, incluant les technologies d'assistance. (Niveau A)

Note : ce critère de succès s'adresse d'abord aux auteurs qui développent ou programment leurs propres composants d'interface utilisateur. Toutefois, les contrôles HTML standards se conforment déjà à ce critère de succès lorsqu'ils sont utilisés conformément à la spécification.
Retour en haut de page

L'évaluation de conformité

SGQRI 008-01
(site Web)		 SGQRI 008-02
(doc. téléchargeable)		 SGQRI 008-03
(multimédia)		 WCAG 2.0
Grille AccessiWeb 2.1 de Braillenet
(suivre ce lien pour voir les tests rattachés à chaque critère)

Le code de la page Web est-il exempt d’erreurs d’imbrication de balises (SW-10a.1) ?

Le code de la page Web est-il exempt d’erreurs d’ouverture et de fermeture de balises (SW-10a.2) ?

Le code de la page Web est-il exempt d’erreurs d’unicité des attributs dans une balise (SW-10a.3) ?

Le code de la page Web est-il exempt d’erreur d’unicité des valeurs d’un attribut d’identification dans une balise (SW-10a.4) ?

La page Web utilise-t-elle une déclaration de type de document du W3C codée avec la balise <DOCTYPE> et respectant la syntaxe prévue par le W3C (SW-10c et  Annexe 1-2) ?

La page Web est-elle comporte-t-elle uniquement des balises utilisées pour les fins auxquelles elles ont été créées (SW-10b) ?

Tout cadre comporte-t-il un titre permettant d'en comprendre la fonction codé avec l'attribut title (SW-16b-b et Annexe 1-4b) ?

Critère 2.1 [Bronze] Chaque cadre et chaque cadre en ligne a-t-il un titre de cadre ?

Critère 2.2 [Bronze] Pour chaque cadre et chaque cadre en ligne ayant un titre de cadre, ce titre de cadre est-il pertinent ?

Critère 8.1 [Bronze] Chaque page Web est-elle définie par un type de document ?

Critère 8.2 [Bronze] Pour chaque page Web, le code source est-il valide selon le type de document spécifié ?

Tout élément de programmation est-il utilisable avec les technologies d’adaptation informatiques et avec le clavier (SW-19a) ?

Si l’information est mise à jour sans rechargement de la page, est-elle affichée pour qu'elle soit détectable par les technologies d’adaptation informatiques sans obligation de rafraîchir la page (SW-19d.1) ?

Si l’information est mise à jour sans rechargement de la page, la personne est-elle informée, dès l’entrée dans la page, d’une possibilité de mise à jour (SW-19d.2) ?

Le nom, le rôle, les états, les propriétés et les valeurs de tout composant d'interface utilisateur sont-ils détectables par les technologies d’adaptation informatiques et les états, les propriétés et les valeurs peuvent-ils être modifiés par la personne utilisant ces technologies (SW-19e) ?

Tout élément de programmation est-il utilisable avec les technologies d’adaptation informatiques et avec le clavier (DT-14) ?

Tous les éléments de navigation sont-ils utilisables avec les technologies d'adaptation informatiques (M-13d.1) ?

Peut-on accéder à tout le contenu informatif dans un ordre séquentiel logique (M-13d.2) ?

Tout élément de programmation est-il utilisable avec les technologies d’adaptation informatiques et avec le clavier (M-17a) ?

Si l’information dans l’animation Web est mise à jour sans rechargement de la page qui contient cette animation, est-elle affichée pour qu'elle soit détectable par les technologies d’adaptation informatiques sans obligation de rafraîchir la page contenant l'animation (M-17d.1) ?

Si l’information dans l’animation est mise à jour sans rechargement de la page qui contient cette animation, la personne est-elle informée, dès l’entrée dans l'animation, d’une possibilité de mise à jour (M-17d.2) ?

Critère 7.1 [Bronze] Chaque script a-t-il, si nécessaire, une alternative (hors cas particuliers) ?

Test 7.1.1 : Chaque script vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?
• Une alternative existe entre <noscript> et </noscript>
• Une alternative existe directement dans la page lorsque javascript est désactivé
• Un lien permet d'accéder à une version alternative de la page
• Une alternative existe via un langage de script côté serveur

Test 7.1.2 Chaque script déclenchant l'ouverture d'une nouvelle fenêtre a-t-il une alternative ?

Critère 7.2 [Bronze] Pour chaque script ayant une alternative, cette alternative est-elle pertinente ?

Critère 7.4 [Bronze] Chaque script est-il, si nécessaire, compatible avec les technologies d'assistance ?

Critère 10.13 [Bronze] Pour chaque page Web, les textes cachés sont-t-ils correctement restitués par les technologies d'assistance ?

Critère 11.9 [Bronze] Dans chaque formulaire, l'intitulé de chaque bouton est-il pertinent ?
Retour en haut de page

La comparaison entre les standards SGQRI et WCAG 2.0

Les standards SGQRI sont un peu plus détaillés que le critère de succès 4.1.1 des WCAG et reprenne sous forme d'exigence des techniques recommandées par le W3C. Quant au critère de succès 4.1.2 les standards SGQRI le traitent à la fois du point de vue de l'utilisateur et de celui, plus technique, du concepteur.

Un site Web qui applique les exigences des standards SGQRI est conformes aux critères de succès 4.1.1 et 4.1.2 des WCAG 2.0. Toutefois, un site Web qui applique les critères de succès 4.1.1 et 4.1.2 des WCAG 2.0 sera non conforme au standard SGQRI sur l'accessibilité d'un site Web à moins qu'il n'applique aussi les exigences 10c, 16b et 19a.

Voir aussi :

  1. Comprendre la règle 4.1 [Compatible]
  2. Comprendre le critère de succès 4.1.1 [Analyse syntaxique]
  3. Comprendre le critère de succès 4.1.2 [Nom, rôle et valeur]

Retour en haut de page

Répondre à cet article

Restez connecté !

Recevez des nouvelles de l’avancement du projet PCCAW dans votre boîte de courriels.


Liste de diffusion