Le Web est en pérpetuelle évolution. En effet, les sites à contenu statique sont de plus en plus remplacés par des sites dynamiques à l'utilisation assez proche des applications de bureaux. Les sites Web dynamiques utilisent abondement JavaScript et AJAX. Les designers créent des widgets et des éléments d'interface grâce aux languages du Web notemment HTML, CSS et Javascript. Ce tournant dans l'histoire du Web permet d'améliorer grandement l'expérience utilisateur. Mais certains utilisateurs peuvent être exclus par manque d'accessibilité. En effet, JavaScript avait la réputation d'être inaccessible aux technologies d'assistance tel que les intérpreteurs d'écran. Or il existe maintenant des techniques pour rendre le Web accessible à une large palette d'utilisteurs.
Problématique
La plupart des libraries JavaScript proposent des composants côté client qui miment le comportement familier des interfaces de bureaux classiques. Carousels, barres de menu et d'autres composants peuvent être créée avec JavaScript, CSS et HTML. Mais du moment que les spécifications HTML 4 ne proposaient pas de tags pour décrire sémentiquement ce type de composants, les développeurs se contentaient d'éléments génériques tel que le tag <div> ou le tag <span>. Or, si d'apparence ces composants ressemblaient parfaitement à ceux spécifiques aux applications de bureau, on ne disposait pas d'infotmations sémantiques suffisantes pour les rendres accessibles aux technologies d'assistance. L'accès au contenu dynamique d'une page Web peut devenir problématique plus particulièrement pour les utilisateurs qui, pour une raison ou pour une autre ne peuvent pas voir l'écran. Les niveaux de stock, les indicateurs de progression,...modifient le DOM de telle sorte que les technologies d'assistance n'y ont pas accès. C'est dans ce contexte que ARIA entre en jeu.
Example 1: Code d'une tabulation sans informations ARIA. Il n'y a aucune information permettant de décrire la forme du widget et ses fonctions.
<!-- Ce widget représente des tabulations. Saurez-vous le deviner en ne regardant que les balises HTML ? -->
<ol>
<li id="ch1Tab">
<a href="#ch1Panel">Chapitre 1</a>
</li>
<li id="ch2Tab">
<a href="#ch2Panel">Chapitre 2</a>
</li>
<li id="quizTab">
<a href="#quizPanel">Quiz</a>
</li>
</ol>
<div>
<div id="ch1Panel">Contenu du Chapitre 1</div>
<div id="ch2Panel">Contenu du Chapitre 2</div>
<div id="quizPanel">Contenu du Quiz</div>
</div>Example 2: Telles qu'elles sont représentées çi-dessous, les tabulations peuvent être reconnues en tant que tel par les utilisateurs. Or aucune information sémantique exploitable par une technologie d'assistance n'est présente.
ARIA
Les spécifications concernant les applications internet "riches" et accessibles sont publiés par l'iniative du W3C sur l'accessibilité, et fournissent la sémantique essentielles au bon fonctionnement des lecteurs d'acran. ARIA permet aux développeurs de décrire en quelque sorte leurs widgets plus finement en ajoutant des attributs spéciaux à leurs balises. Ces spécifiquations remplissent le vide qui existait entre les spécifications du standard HTML et des widgets. ARIA spécifie des rôles et des états permettant de décrire en quelque sorte le fonctionnement des widgets d'interfaces utilisateurs les plus commnus.
Les spécifications ARIA distinguent 3 types d'attributs : rôles, états et propriétés. Les attributs de type "role" sont utilisés pour les widgets ne faisant pas partie des spécifications HTML 4. Les propriétés sont utilisées pour représenter les caractéristiques de ces widget. Les états, comme leurs noms l'indique servent à representer l'état acuel de ces éléments.
Les attributs ARIA ont été conçu de façon à être interprétés directement par les navigateurs Web et intéragir directement avec les APIs d'accessibilité natives des systèmes d'exploitation. Quand les spécifications ARIA sont implementées, les technologies d'assistance peuvent interagir avec les widgets JavaScript personnalisés de la même façon qu'ils interagissent avec leurs équivalents de bureau. Les technologies d'assistance peuvent ainsi fournir une expérience utilisateurs homogène.
Example 3: L'exemple çi-dessous ajoute des attributs ARIA aux balises déjà présentes.
<!-- Les tabulations sont bien définies --> <!-- Des attributs ARIA ont été ajoutés pour lister les différentes tabulations. --> <ol role="tablist"><li id="ch1Tab" role="tab"> <a href="#ch1Panel">Chapitre 1</a> </li> <li id="ch2Tab" role="tab"> <a href="#ch2Panel">Chapitre 2</a> </li> <li id="quizTab" role="tab"> <a href="#quizPanel">Quiz</a> </li> </ol> <div> <!-- Remarquez les attributs role and aria-labelledby servant à décrire les tabulations --> <div id="ch1Panel" role="tabpanel" aria-labelledby="ch1Tab">Contenu du Chapitre 1</div> <div id="ch2Panel" role="tabpanel" aria-labelledby="ch2Tab">Contenu du Chapitre 2</div> <div id="quizPanel" role="tabpanel" aria-labelledby="quizTab">Contenu du Quiz</div> </div>
Les versions récentes des navigateurs majeurs du marché fournissent un support ARIA Firefox, Chrome, Safari, Internet Explorer,...De nombreuses technologies d'assistance libres d'accès tel que NVDR et Ocra fournissent aussi un support ARIA. Le support de ces spécifications est aussi de plus en plus prénsent dans les balises des librairies JavaScript : JQuery UI, YUI, Google Closure et Dojo Dijit.
Les changement représentationnels
Les changements représentationnels incluent l'utilisation du CSS pour changer l'apparence du contenu (mettre bordure rouge autour de données invalides, changer la couleur de fond d'une case à cocher), le faire apparaître ou disparaître.
Les Changements d'états
Les attributs pour décrire l'état actuel d'un widget sont fournit, par exemple :
aria-checked: indique l'état d'une case à cocher ou d'un bouton radioaria-disabled: indique qu'un élément est visible, mais désactivéaria-expanded: indique qu'un élément est déroulé
(La liste n'est pas exhaustive, pour la liste complète consulter les spécifications des états et propriétés ARIA)
Developers should use ARIA states to indicate the state of UI widget elements and use CSS attribute selectors to alter the visual appearance based on the state changes (rather than using script to change a class name on the element).
Une bonne approche pour les développeurs afin d'implémenter ARIA serait de changer l'apparence des éléments en se basant sur l'état de ceux-çi. Utiliser les attributs ARIA permet de construire les sélécteurs CSS autour de leurs état au lieu de manipuler des classes avec des scripts.
The Open Ajax Alliance website provides an example of CSS attribute selectors based on ARIA states. The example shows a WYSIWYG editor interface with a dynamic menu system. Items currently selected in a menu, such as the font face, are visually distinguished from other items. The relevant parts of the example are explained below.
Exemple de selecteurs CSS basés sur les états ARIA (Site le site de l'OAA).
In this example, the HTML for a menu has the form shown in Example 1a. Note how, on lines 7 and 13, the aria-checked property is used to declare the selection state of the menu items.
Exemple 1a. Exemple d'un menu HTML (adapté depuis https://www.oaa-accessibility.org/example/25/).
<ul id="fontMenu" class="menu" role="menu" aria-hidden="true">
<li id="sans-serif"
class="menu-item"
role="menuitemradio"
tabindex="-1"
aria-controls="st1"
aria-checked="true">Sans-serif</li>
<li id="serif"
class="menu-item"
role="menuitemradio"
tabindex="-1"
aria-controls="st1"
aria-checked="false">Serif</li>
...
The CSS that is used to alter the visual appearance of the selected item is shown in Example 1b. Note that there is no custom classname used, only the status of the aria-checked attribute on line 1.
Example 1b. Sélécteur CSS basé sur l'état, representé par un attribut ARIA (adapté depuis https://www.oaa-accessibility.org/example/25/).
li[aria-checked="true"] {
font-weight: bold;
background-image: url('/images/dot.png');
background-repeat: no-repeat;
background-position: 5px 10px;
}
The JavaScript to update the aria-checked property has the form shown in Example 1c. Note that the script only updates the aria-checked attribute (lines 3 and 8); it does not need to also add or remove a custom classname.
Example 1c. JavaScript to update the aria-checked attribute (based on https://www.oaa-accessibility.org/example/25/).
var processMenuChoice = function(item) {
// 'check' the selected item
item.setAttribute('aria-checked', 'true');
// 'un-check' the other menu items
var sib = item.parentNode.firstChild;
for (; sib; sib = sib.nextSibling ) {
if ( sib.nodeType === 1 && sib !== item ) {
sib.setAttribute('aria-checked', 'false');
}
}
};
Les changements de visibilité
When content visibility is changed (i.e., an element is hidden or shown), developers should change the aria-hidden property value. The techniques described above should be used to declare CSS to visually hide an element using display:none.
The Open Ajax Alliance website provides an example of a tooltip that uses aria-hidden to control the visibility of the tooltip. The example shows a simple web form with tooltips containing instructions associated with the entry fields. The relevant parts of the example are explained below.
In this example, the HTML for the tooltip has the form shown in Example 2a. Line 9 sets the aria-hidden state to true.
Example 2a. HTML for a tooltip (adapted from https://www.oaa-accessibility.org/example/39/).
<div class="text">
<label id="tp1-label" for="first">First Name:</label>
<input type="text" id="first" name="first" size="20"
aria-labelledby="tp1-label"
aria-describedby="tp1"
aria-required="false" />
<div id="tp1" class="tooltip"
role="tooltip"
aria-hidden="true">Your first name is optional</div>
</div>
The CSS for this markup is shown in Example 2b. Note that there is no custom classname used, only the status of the aria-hidden attribute on line 1.
Example 2b. Attribute-based selector for indicating state (from https://www.oaa-accessibility.org/example/39/).
div.tooltip[aria-hidden="true"] {
display: none;
}
The JavaScript to update the aria-hidden property has the form shown in Example 2c. Note that the script only updates the aria-hidden attribute (line 2); it does not need to also add or remove a custom classname.
Example 2c. JavaScript to update the aria-checked attribute (based on https://www.oaa-accessibility.org/example/39/).
var showTip = function(el) {
el.setAttribute('aria-hidden', 'false');
}
Les changements de rôles
ARIA allows developers to declare a semantic role for an element that otherwise offers incorrect or no semantics. For example, when an unordered list is used to create a menu, the <ul> should be given a role of menubar and each <li> should be given a role of menuitem.
The role of an element should not change. Instead, remove the original element and replace it with an element with the new role.
For example, consider an "inline edit" widget: a component that allows users to edit a piece of text in place, without switching contexts. This component has a "view" mode, in which the text is not editable, but is activatable, and an "edit" mode, in which the text can be edited. A developer might be tempted to implement the "view" mode using a read-only text <input> element and setting its ARIA role to button, then switching to "edit" mode by making the element writable and removing the role attribute in "edit" mode (since <input> elements have their own role semantics).
Do not do this. Instead, implement the "view" mode using a different element altogether, such as a <div> or <span> with a role of button, and the « edit » mode using a text <input> element.
Mise à jour asynchrone de contenu
La navigation au clavier
Often times developers overlook support for the keyboard when they create custom widgets. To be accessible to a variety of users, all features of a web application or widget should also be controllable with the keyboard, without requiring a mouse. In practice, this usually involves following the conventions supported by similar widgets on the desktop, taking full advantage of the Tab, Enter, Spacebar, and arrow keys.
Traditionally, keyboard navigation on the web has been limited to the Tab key. A user presses Tab to focus each link, button, or form on the page in a linear order, using Shift-Tab to navigate backwards. It's a one-dimensional form of navigation—forward and back, one element at a time. On fairly dense pages, a keyboard-only user often has to press the Tab key dozens of times before accessing the needed section. Implementing desktop-style keyboard conventions on the web has the potential to significantly speed up navigation for many users.
Here's a summary of how keyboard navigation should work in an ARIA-enabled web application:
- The Tab key should provide focus to the widget as a whole. For example, tabbing to a menu bar should put focus on the menu's first elem.
- The arrow keys should allow for selection or navigation within the widget. For example, using the left and right arrow keys should move focus to the previous and next menu items.
- When the widget is not inside a form, both the Enter and Spacebar keys should select or activate the control.
- Within a form, the Spacebar key should select or activate the control, while the Enter key should submit the form's default action.
- If in doubt, mimic the standard desktop behavior of the control you are creating.
So, for the Tabs widget example above, the user should be able to navigate into and out of the widget's container (the <ol> in our markup) using the Tab and Shift-Tab keys. Once keyboard focus is inside the container, the arrow keys should allow the user to navigate between each tab (the <li> elements). From here, conventions vary from platform to platform. On Windows, the next tab should automatically be activated when the user presses the arrow keys. On Mac OS X, the user can press either Enter or the Spacebar to activate the next tab. An in-depth tutorial for creating Keyboard-navigable JavaScript widgets describes how to implement this behavior with JavaScript.
For more detail about desktop-style keyboard navigation conventions, a comprehensive DHTML style guide is available. It provides an overview of how keyboard navigation should work for each type of widget supported by ARIA. The W3C also offers a helpful ARIA Best Practices document that includes keyboard navigation and shortcut conventions for a variety of widgets.