Normes et spécifications

Cyber apprentissage et accessibilité
Normes et spécifications
JUIN 2014
Table des matières
Web Content Accessibility Guidelines 2.0 .................................................................................. 3
Authoring Tool Accessibility Guidelines 2.0 ................................................................................ 4
Accessible Rich Internet Applications 1.0 ................................................................................... 5
AccessForAll d’IMS/ ISO 24751.............................................................................................. 6
Loi sur l’accessibilité pour les personnes handicapées de l’Ontario (LAPHO) ............................ 8
Section 508 (É.-U.) .................................................................................................................... 9
Bibliographie .............................................................................................................................. 9
2
Web Content Accessibility Guidelines 2.0
La deuxième version des Web Content Accessibility Guidelines (WCAG) ou lignes directrices
concernant l’accessibilité du contenu Web du W3C a été diffusée en 2008 [1]. On considère
qu’il s’agit de la norme mondialement acceptée pour ce qui est de l’accessibilité des sites Web.
De nombreux pays y recourent pour formuler leurs propres directives en la matière. Les WCAG
ont été présentées comme un jeu de consignes générales ayant pour but de rendre le contenu
Web accessible à tous ceux qui souhaiteraient en prendre connaissance, handicap ou pas.
Les WCAG 2.0 consistent en quatre principes, chacun assorti de trois degrés d’importance.
Ces principes stipulent ce qui suit :
1. le contenu Web doit être perceptible (on doit pouvoir en prendre connaissance avec
plusieurs sens);
2. il doit être utilisable (fonctionnel avec la souris et le clavier);
3. il doit être intelligible (cohérent, prévisible, lisible, réfractaire aux erreurs);
4. il doit être robuste (exploitable, peu importe la technologie).
Les lignes directrices sont présentées par ordre de priorité, selon leur importance relative, et
l’impact relatif des obstacles qui surviennent quand on ne les respecte pas.
1. Niveau A : la ligne directrice doit être respectée, sans quoi certaines personnes ne
pourront accéder au contenu.
2. Niveau AA : elle devrait être respectée, faute de quoi certaines personnes auront du
mal à accéder au contenu.
3. Niveau AAA : elle pourrait être respectée afin de rendre le contenu plus accessible et
utile.
Aux spécifications des WCAG 2.0 s’ajoutent des documents d’appoint énumérant et précisant
les critères de réussite (ou exigences) liés à l’accessibilité du Web, ainsi que des techniques
facilitant la création de contenu qui épousera ces critères.
À titre d’illustration, voici un critère de réussite pour la ligne directrice 1.1.1 :
● associer du texte optionnel au contenu non textuel pour que celui-ci puisse être
transposé autrement, par exemple en gros caractères d’imprimerie, en braille, en
paroles, en symboles ou dans un langage plus simple.
Et une technique qui y correspond :
● H37 – à l’élément img, ajouter une courte explication avec l’attribut alt.
Lorsqu’il est question de HTML, on entend souvent les termes « élément » et « attribut ». Pour
plus de clarté, disons que le premier se rapporte fréquemment à une balise HTML et le second,
à une propriété de la balise. Dans l’exemple qui suit, la balise image est représentée par
l’élément <img> qui a pour propriétés les attributs « src », indiquant le chemin jusqu’à
l’illustration ou au fichier d’origine (source), et « alt », qui renferme le texte décrivant l’image.
3
Éléments et attributs HTML
// Les éléments HTML sont souvent appelés balises.
// L’élément <img> ci-dessous a un attribut “src” indiquant où se trouve l’image
// et un attribut “alt” contenant le texte qui la décrit.
<img src="images/big_cat.jpg" alt="un gros chat noir" />
Authoring Tool Accessibility Guidelines 2.0
En 2000, le W3C a dévoilé la première version de ses Authoring Tool Accessibility Guidelines
(ATAG), contrepartie des précédentes. (La deuxième mouture des ATAG [2] n’est pas terminée,
mais elle approche d’une version solide qui, une fois diffusée, remplacera vite les ATAG 1.0.)
Les ATAG guident les développeurs qui mettent au point les outils servant à créer du contenu
accessible, conforme aux normes des WCAG; ces outils doivent eux-mêmes respecter les
WCAG, donc être accessibles. Pour savoir quels types d’outils employer pour créer du contenu
Web, on lira la partie « Outils de création » du document Cyber apprentissage et accessibilité :
Ce qu’il faut savoir.
À l’instar des WCAG, les ATAG sont structurées par principes, lignes directrices, critères de
réussite et niveau de conformité. La partie A reflète la contrainte des WCAG voulant que l’outil
soit accessible, tandis que la partie B décrit les principes associés à la création de contenu
accessible.
Principes des ATAG – Partie A (interface accessible pour l’utilisateur)
• A1 : L’interface utilisateur de l’outil respecte les lignes directrices sur l’accessibilité.
• A2 : Le mode édition est perceptible.
• A3 : Le mode édition est utilisable.
• A4 : Le mode édition est intelligible.
Principes des ATAG – Partie B (création de contenu accessible)
• B1 : Les processus entièrement automatisés produisent du contenu accessible.
• B2 : L’auteur obtient de l’aide quand il crée du contenu accessible.
• B3 : L’auteur obtient de l’aide quand il rehausse l’accessibilité du contenu existant.
• B4 : L’outil de création promeut et intègre ses fonctions d’accessibilité.
En ce qui concerne le principe B1, l’outil qui produit automatiquement des balises HTML sans
intervention de l’auteur, ou très peu, doit engendrer des balises accessibles par défaut. Ainsi,
s’il génère un tableau, les éléments du tableau seront imbriqués correctement, il y aura
ouverture et fermeture de tous les éléments dans le tableau, et les balises obtenues seront
valides.
4
Pour le principe B2, l’outil permet d’ajouter des fonctions d’accessibilité au contenu d’une
manière quelconque. À titre d’illustration, l’outil qui crée un tableau permettra à l’auteur d’y
ajouter un sommaire et de donner un titre aux rangées afin que le contenu soit étiqueté par
colonne et par rangée.
Le principe B3 indique que l’outil doit laisser l’auteur modifier un tableau existant ou y ajouter
des fonctions d’accessibilité.
Enfin, le principe B4 stipule que les fonctions d’accessibilité doivent être intégrées aux autres
fonctions et ne pas en être dissociées. On devrait donc pouvoir ajouter du texte à une image
dans la partie de l’outil qui intègre l’image au contenu et pas ailleurs, soit dans un endroit
réunissant toutes les fonctions d’accessibilité.
Accessible Rich Internet Applications 1.0
La spécification ARIA (Accessible Rich Internet Applications) [3] est sans doute la plus
importante se rapportant à l’accessibilité du Web à avoir vu le jour ces dernières années.
Rédigée parallèlement au HTML5, elle permet au développeur de décrire le but ou l’interactivité
de fonctions Web particulières – surtout quand on les utilise avec un langage script comme
Javascript – de façon à en accroître l’utilité pour ceux qui recourent à une technologie
d’assistance.
Avant ARIA, les personnes se servant de telles technologies pouvaient utiliser très peu des
fonctions interactives liées à un site Web. Bien que relativement récente, la plupart des
navigateurs et des technologies d’assistance acceptent la spécification ARIA, et il est de plus en
plus courant d’y recourir quand on élabore des applications et des sites Web accessibles.
Voici une liste simplifiée des principaux aspects de cette spécification technique, susceptibles
de faciliter l’accès aux fonctions dynamiques, spéciales et interactives d’un site.
Zones actives (Live Regions). Par là, on entend une zone d’un site Web qui actualise
l’information de façon dynamique, sans réinitialisation de la page. Naguère, une personne
utilisant une technologie d’assistance n’aurait pour ainsi dire pu accéder à des fonctions comme
l’actualisation d’un fil de nouvelles, l’Insertion dynamique de messages de rétroaction dans une
page lorsque survient une erreur ou la mise à jour du clavardage en direct. Les zones actives
mettent désormais les informations « en direct » de ce genre à la portée de tous.
Sections (Landmarks). Une section est une particularité ajoutée à divers éléments de
l’interface du site permettant de définir les principaux points de navigation grâce à l’attribut
« role ». Quand elle accède à une page Web structurée de la sorte, la personne qui recourt à
une technologie d’assistance comme un lecteur d’écran obtient la liste des sections et peut se
déplacer de l’une à l’autre. Il est possible d’ajouter des sections à la barre de navigation
(role=“navigation”), à un champ de recherche (role=“search”) ou à la zone de contenu principale
(role=“main”), en associant, par exemple, l’attribut « role » d’ARIA aux balises HTML existantes.
5
Étiquettes et relations. ARIA propose plusieurs attributs avec lesquels le développeur
associera directement des fonctionnalités spéciales à leur description. Autrefois, quand une
technologie d’assistance accédait à de telles fonctions (en supposant qu’on pouvait le faire par
le clavier), l’utilisateur n’entendait habituellement rien, la façon de décrire ces fonctions n’étant
pas normalisée. Avec des attributs comme « aria-labelledby » et « aria-describedby », le
développeur décrit les éléments de la fonction qu’il crée pour le Web d’une manière utile pour
ceux qui utilisent une technologie d’assistance.
AccessForAll d’IMS/ ISO 24751
En juillet 2004, l’IMS Global Learning Consortium dévoilait la norme AccessForAll 1.0,
actualisée par la suite, en 2008, pour donner AccessForAll 2.0 [4], lorsque l’ISO/IEC en a fait sa
norme ISO 24751.
AccessForAll est une norme en trois volets qui fait essentiellement concorder les besoins et les
préférences de l’utilisateur aux adaptations du contenu et de l’interface.
• Le premier volet correspond au cadre et au modèle de référence servant de guide au
développement d’applications qui utilisent et produisent le contenu, ainsi que les profils
de préférences AccessForAll.
• Le deuxième est la DRD (Digital Resource Description ou description de la ressource
numérique), qui décrit les adaptations apportées au contenu, comme le sous-titrage de
la piste sonore ou la description textuelle des illustrations.
• La troisième partie concerne les exigences et les préférences individuelles applicables à
la prestation du contenu numérique ou PNP (pour Personal Needs and Preferences).
Elle permet à l’apprenant d’exposer ses besoins, comme le sous-titrage dans le cas
d’une personne incapable d’entendre la piste sonore d’une vidéo.
La norme AccessForAll n’est pas encore très appliquée aux systèmes de cyber apprentissage,
bien qu’elle constitue un important composant de la future Global Public Inclusive Infrastructure
(GPII), exposée plus en détail à la partie « L’accessibilité dans l’avenir » du document Cyber
apprentissage et accessibilité : Ce qu’il faut savoir.
Le système de gestion de l’apprentissage (SGA) ATutor [5] a épousé la norme AccessForAll 2
(ISO 24751) aux fins de démonstration. L’apprenant définit le format dans lequel il préfère
obtenir le contenu pédagogique. La figure 1, qui suit, montre le panneau de préférence
« Content Alternative » permettant à l’apprenant de choisir les adaptations qui, soit
remplaceront le contenu original, soit y seront associées. Par exemple, la section « Alternative
to Text » permet d’ajouter la version sonore du contenu (s’il y en a une) au texte existant, peutêtre écrit dans une autre langue, de sorte qu’on pourra lire celui-ci tout en écoutant la bande
son. On pourrait aussi décider de remplacer le texte original par sa version audio.
6
La figure 2 illustre l’écran de création AccessForAll de l’éditeur de contenu ATutor. La première
colonne énumère les fichiers servant de ressource à la page de contenu en train d’être
modifiée. Dans la deuxième, l’auteur définit la nature du contenu de chaque ressource (auditive,
textuelle, visuelle, ou leur combinaison). Les quatre colonnes suivantes permettent à l’auteur de
télécharger une adaptation textuelle, sonore, visuelle ou en langage gestuel du contenu original.
Figure 1 : Écran des préférences illustrant les possibilités d’adaptation du contenu du SGA
ATutor. (Illustration disponible uniquement en anglais.)
7
Figure 2 : L’outil de création AccessForAll de ATutor permet de définir la nature des ressources
et d’ajouter une adaptation textuelle, sonore, visuelle ou en langage gestuel de chaque
ressource pour le contenu en train d’être modifié. (Illustration disponible uniquement en
anglais.)
Loi sur l’accessibilité pour les personnes handicapées de l’Ontario
(LAPHO)
Les exigences de la Loi sur l’accessibilité pour les personnes handicapées de l’Ontario sont
entrées en vigueur le 1er janvier 2012, lorsque tous les sites Web du gouvernement ontarien ont
été tenus de se conformer aux lignes directrices de niveau A des WCAG 2.0. Depuis le
1er janvier 2014, les organisations désignées du secteur public et d’autres grandes
organisations comptant au moins 50 employés, dont les collèges et les universités, doivent elles
aussi se conformer aux lignes directrices de niveau A pour les nouveaux sites Web, tout comme
les sites qui ont été sensiblement modifiés (50 % ou davantage) depuis le 1er janvier 2012. Ces
organisations devront se conformer aux lignes directrices de niveau AA des WCAG d’ici le
1er janvier 2021.
Les exigences relatives à l’accessibilité du Web de la LAPHO font écho à celles des WCAG 2.0,
à deux exceptions près. Les WCAG exigent que le contenu diffusé en direct soit sous-titré
(directive 1.2.4) et accompagné d’une description sonore, préenregistrée, pour être conforme
au niveau AA (directive 1.2.5). La LAPHO n’impose pas ces contraintes au secteur public ni aux
grandes organisations, même si le gouvernement sera tenu de fournir des vidéo descriptions
d’ici 2020. On trouvera plus de détails sur le sous-titrage et la description sonore à la partie
« Contenu multimédia » du document Cyber apprentissage et accessibilité : Ce qu’il faut savoir.
8
Section 508 (É.-U.)
Le gouvernement américain a ajouté à sa Rehabilitation Act l’article 508, qui est entré en
application en 2000. Cet article touche les technologies électroniques et de l’information
fournies au gouvernement américain, y compris le matériel informatique et les logiciels, les sites
Web, les systèmes téléphoniques et les photocopieuses. L’article 1194.22 de la même loi
énumère 16 exigences en matière d’accessibilité applicables aux sites Web et à l’information
électronique présentée autrement, mais ces exigences s’appuient sur les WCAG 1.0, pas les
WCAG 2.0. Souvenez-vous en si jamais votre institution achète un logiciel de cyber
apprentissage ou du matériel pédagogique de sources américaines soutenant se conformer à
l’article 508 ou qui ont produit un VPAT (Voluntary Product Accessibility Template ou application
volontaire de l’accessibilité à un produit). Ne présumez pas que la technologie américaine
respectera les exigences de la LAPHO ou des WCAG 2.0 sur le plan de l’accessibilité.
Bibliographie
(En anglais seulement, sauf indication contraire)
1. Web Content Accessibility Guidelines 2.0 du W3C http://www.w3.org/TR/WCAG20/
2. Authoring Tool Accessibility Guidelines 2.0 du W3C http://www.w3.org/TR/ATAG20/
3. ARIA 1.0 (Accessible Rich Internet Applications) http://www.w3.org/TR/wai-aria/
4. Norme AccessForAll sur l’accessibilité de l’IMS Global Learning Consortium
http://www.imsglobal.org/accessibility/
5. Système de gestion de l’apprentissage ATutor http://www.atutor.ca
9