Dossier2012 aria-delamer-menant-vergnol

WAI-ARIA et l'expérience Web page 1 sur 30

DELAMER Céline Master CPEAM
MENANT Benjamin
VERGNOL Morgan

Normes et Standards
Clément Dussarps

> Dans quelles mesures les spécifications ARIA étendent-elles
l’expérience web des utilisateurs en situation de handicap ?

Université Michel de Montaigne – Bordeaux 3 | Master CPEAM


Sommaire
WAI-ARIA......................................................................................................................................... 4
Introduction à ARIA...................................................................................................................... 4
Qu’est-ce qu’ARIA ?................................................................................................................ 4
Un peu d’histoire… ................................................................................................................. 4
Les objectifs d’ARIA................................................................................................................ 5
Les contenus dynamiques sont partout : quelques exemples….............................................. 8
Les implémentations d’ARIA................................................................................................. 10
L’action des logiciels d’assistances ...................................................................................... 12
« Vers l’infini et au-delà… ! »................................................................................................. 13
ARIA par l’exemple......................................................................................................................... 13
Au menu : Google !.................................................................................................................... 14
Les Attentes fonctionnelles.................................................................................................... 15
Qu’a fait Google (Docs) ?...................................................................................................... 16
Qu’ont fait Mozilla, Google, Microsoft et consorts ?...............................................................19
Qu’ont fait les développeurs de JAWS, VoiceOver et consorts ?...........................................20
ARIA et l’expérience utilisateur....................................................................................................... 21
À qui les spécifications ARIA profitent-elles ?........................................................................ 21
Un outil dont il faut pouvoir et savoir se servir....................................................................... 22
Implémenter… mais pas que !............................................................................................... 25
ARIA peut-il devenir une gêne ? ........................................................................................... 26
ARIA en quelques points....................................................................................................... 27
Conclusion..................................................................................................................................... 28
Glossaire........................................................................................................................................ 29



WAI-ARIA
Depuis l’avènement des nouvelles technologies et du web, Internet s’est introduit dans le
quotidien de tous, peu importe le contexte d’utilisation ou le lieu d’usage : bureaux, salons,
gares, jardins publics, troquets, etc. Au fur et à mesure que les technologies ont évolué, les
usages se sont diversifiés et le web a changé, s’adaptant tantôt aux usages, aux
technologies, ou en proposant des innovations. Les contenus des pages web et des
interactions avec elles se sont alors étendus et complexifiés.

Ces évolutions posent une question essentielle : comment continuer à rendre accessible
tous les contenus du web et ce indépendamment de leurs modalités d’usage (matériels et
logiciels de navigation, mode de perception des contenus…) ? Nous nous sommes donc
intéressés à cette problématique, mais plus précisément aux dispositifs techniques utiles à
certains types d’utilisateurs pour qui une navigation classique sur Internet représente déjà
une difficulté.

Les spécifications Accessible Rich Interactive Applications (ARIA) sont l’exemple même
d’une tentative de réponse à cette problématique. Ainsi, dans quelles mesures les
spécifications ARIA étendent-elles l’expérience web des utilisateurs concernés ? C’est ce à
quoi nous tacherons de répondre en vous présentant ARIA, ses objectifs et son
fonctionnement et, pour finir, ses limites en termes d’utilisation.

Introduction à ARIA
Qu’est-ce qu’ARIA ?

ARIA, littéralement « Accessible Rich Interactive Applications », est une spécification
technique du W3C encore en cours de rédaction qui permet de rendre certaines
applications et sites web plus accessibles, particulièrement aux personnes souffrant d’un
handicap nécessitant un lecteur d’écran ou ne pouvant utiliser un périphérique de type
souris pour naviguer sur Internet.

Un peu d’histoire…

Le développement des spécifications ARIA est intégré dans le projet centré sur
l’accessibilité web du W3C : le « WAI », Web Accessibility Initiative.

Le premier document initialisant le projet ARIA date de 2006 mais on imagine que le
problème a été soulevé quelques années auparavant. S’en est suivi depuis une dizaine
d’autres documents de travail relatant l’avancée des recherches sur les précisions et la mise
en œuvre d’ARIA.



Historique de publication des documents sur ARIA : du brouillon de travail
(« working draft ») au dernier appel (« last call working draft »)

Le « Protocols and Formats Working group », le groupe de travail qui produit les
documents relatif à ARIA, est composé de personnes venant de tous secteurs :
professionnels du milieu, enseignants, chercheurs…

En janvier 2011, ARIA est enfin candidate pour devenir une recommandation officielle du
W3C. Elle reste cependant, comme toutes les recommandations, en constante discussion.

Les objectifs d’ARIA.

Comme leur nom l’indique, les spécifications ARIA permettent l’accessibilité à des
contenus dits « riches » et « interactifs » (les « Rich Interactives Application »), qui sont
aujourd’hui incontournables sur le Web.

Ces contenus dynamiques sont apparus avec l’avènement du web 2.0 et des nouvelles
possibilités d’interactions entre les sites Internet et leurs utilisateurs.

Développé la plupart du temps dans des langages de développement web tels que
Javascript (et AJAX) ou Flash, ils reposent sur une technologie essentielle du web : le
protocole XMLHttpRequest.



Histoire d’ARIA en fonction des autres grandes technologies du web.

C’est justement l’utilisation de ce protocole dans leur fonctionnement qui caractérise les
contenus dynamiques. En effet ils se définissent comme des contenus qui changent de
comportement indépendamment de la page web où ils se trouvent. Ce sont en fait des
zones d’une page web plus ou moins importante, qui adoptent différents comportements
sans amener à complètement rafraîchir celle-ci.



Comportement des contenus dynamiques au sein d’une page web classique (partie visible
par l’utilisateur) :

Ils peuvent afficher / masquer du contenu, permettre des actions aux utilisateurs sans que
les autres éléments de la page ne soient modifiés. Selon certains cas et selon l’objectif de
ces contenus, leur comportement changeant peut être contrôlé par l’utilisateur ou pas du
tout.



Fonctionnement réel des contenus dynamiques (partie invisible pour les utilisateurs) :

Les contenus dynamiques sont partout : quelques exemples…

Parmi les contenus dynamiques on trouve par exemple les menus déroulants, les
messageries instantanées, les encarts publicitaires en Flash, les diaporamas, la suggestion
de recherche en direct sur les moteurs de recherches etc.



Menu déroulant sur FNAC.com

Facebook, le premier des sites de réseaux sociaux (grands porteurs du Web 2.0) est,
comme la plupart de ses concurrents (Twitter, Google +), un des exemples les plus
probants de l’existence de ces contenus. Tous les modules du site sont développés en
utilisant massivement AJAX, technologies qui permettent donc une interactivité de
certaines zones d’une page sans la recharger complètement.

Page principale d’actualités Facebook.

Notifications et menu déroulant, mise à jour des actualités, messagerie instantanée, ajout /
compteur de commentaires, affichage / masquage d’informations… Le fonctionnement
même du site est entièrement basé sur ces mises à jour régulières et en direct des
informations.

Comme évoqué précédemment, ces changements de comportements peuvent survenir
grâce à l’action de l’utilisateur (affichage d’un contenu par exemple) ou sans (apparition
d’une notification).

Parce qu’ils peuvent changer d’états pendant la navigation, on comprend pourquoi ces
contenus ne sont pas « visibles »par les utilisateurs de lecteurs d’écrans par exemple, car
ceux-ci ne peuvent avoir une vision globale de la page. C’est en effet surtout visuellement
que la plupart des utilisateurs les repèrent.



Exemple d’une mise à jour de contenu dynamique non perçue par une personne utilisant un
lecteur d’écran. Source : diaporama de JP Vilain (http://qelios.net/demo_aria/index.php)

D’autres utilisateurs sont aussi concernés : tous ceux qui utilisent d’autres périphériques
que la souris pour leur navigation, tel que le clavier. Si ceux-ci peuvent percevoir les
changements qui s’opèrent sur la page, ils ne peuvent interagir avec les contenus car les
tabulations claviers sont par défaut inefficaces sur ces zones.

Heureusement les spécifications ARIA vont changer ça. Les contenus dynamiques se
démocratisant de plus en plus, rendre ces contenus visibles, accessibles et fonctionnels est
alors devenu un enjeu crucial.

Les implémentations d’ARIA

Les spécifications permettent justement aux navigateurs, et aux technologies d’assistance
de reconnaître ces contenus et de pouvoir communiquer avec elles afin de les rendre
utilisables. Pour cela, les spécifications ARIA sont à penser dès la conception de la page
web et à intégrer dans son code HTML, langage qui gère, comme nous l’avons vu
précédemment, la structure de la page. Le développeur de la page intègre dans son code
des propriétés et attributs qui vont permettre aux contenus dynamiques de se déclarer
comme des applications plutôt que de simples contenus statiques.

Mais afin que ces attributions dans le code puissent être reconnues, il faut aussi que les
agents utilisateur (les navigateurs) puissent les reconnaître. Dès ses premières phases de
développement les navigateurs ont commencé à les implémenter et ce jusqu’à 2012 : les



navigateurs les plus utilisés1 les reconnaissent désormais tous.

Frise : Utilisation d’ARIA en fonction de l’évolution des agents utilisateurs (et par rapport aux
recommandations web sur l’accessibilité)

De même que pour les navigateurs web, les logiciels d’assistance à la navigation (JAWS 2,
Voice Over) doivent connaître les propriétés des spécifications ARIA afin de pouvoir agir
en fonction de celles-ci.

A chaque rôle ou propriété ARIA, une action est associée qui permet de rendre « visible »
et manipulable les contenus dynamiques interactifs.

1 Opéra, Internet Explorer, Safari, Chrome et Firefox d’après un article du 6 mars d’Openlog.fr :
http://www.openlog.fr/blog/navigateurs-internet-plus-utilises

2 Un article de Techno-Science.net sur JAWS peut vous permettre de comprendre le fonctionnement de ces
logiciels en général : http://www.techno-science.net/?onglet=glossaire&definition=572



Intervention des Spécifications ARIA au sein du processus de navigation d’un utilisateur employant
un logiciel d’assistance.

L’action des logiciels d’assistances

Prenons l’exemple d’un utilisateur utilisant un lecteur d’écran. Lors d’une session de
navigation, s’il a passé un contenu dynamique et que celui-ci change de comportement à ce
moment, l’utilisateur ne peut le savoir (voir le schéma de JP Vilain page 6).

Cependant, grâce aux implémentations d’ARIA dans le code de la page, le lecteur d’écran a
reconnu le contenu et a perçu sa mise à jour. Grâce à cela, le logiciel peut agir pour
prévenir l’utilisateur et de différentes manières selon les préférences de ce dernier :

- soit il interrompt la navigation de l’utilisateur afin de le prévenir du changement
opéré

- soit il continue la navigation et revenir ensuite sur ce contenu

- soit il ne fait rien.

L’utilisateur est donc libre de décider de « voir » ces contenus ou non, de les utiliser ou
non, mais ils lui sont accessibles.



« Vers l’infini et au-delà… ! »

Pas encore recommandation officielle du W3C, ni standard, les spécifications ARIA
tendent à le devenir, grâce à la prise de conscience générale autour de l’accessibilité : elles
sont déjà implémentées par les agents utilisateurs et utilisées par des sites web
incontournables (sites gouvernementaux, grands groupes tels que Google...). Reste encore
à prouver leur efficacité technique et surtout leur efficience du côté des utilisateurs
concernés.

ARIA par l’exemple
Le propos de cette partie consiste à donner un aperçu concret de ce que suppose
l’implémentation d’ARIA. On a vu précédemment que ces spécifications s’adressaient à
trois « acteurs » importants lors de la médiation technique d’une information à un
utilisateur :

1. le producteur de contenu, comprenant les concepteurs de sites Web, les
développeurs et intégrateurs HTML ainsi que les éditeurs d’outils d’édition Web,
comme BlueGriffon ou Dreamweaver ;

2. les éditeurs (ou développeurs) des agents utilisateurs 3 Web (navigateurs), comme
Microsoft, Google, Mozilla, Apple, Opera Software… ;

3. les éditeurs (ou développeurs) des assistants utilisateurs 4, comme Freedom
Scientific (JAWS), Apple (VoiceOver)… ;

Nous allons donc, en premier lieu, identifier un élément précis des spécifications qui
correspondrait à une fonctionnalité ou à un composant concret d’une page Web. Ensuite,
nous observerons ce que l’implémentation d’ARIA suppose pour chacun des trois acteurs
précédemment cités. Nous procéderons à cette observation sur un cas réel, avec un site en
production.

Les outils utilisés pour réaliser cette observation sont : le navigateur Mozilla Firefox 12
(beta) et son inspecteur de code.

3 Le terme « agent utilisateur » est défini dans le glossaire.
4 Idem pour « assistant utilisateur ».



Au menu : Google !
La suite bureautique en ligne Google Docs est l’un des meilleurs exemples d’application
Web riches, dotée d’un haut degré d’interactivité et de nombreuses fonctionnalités
dynamiques. L’utilisation d’un tel outil par des personnes en situation de handicap peut
s’avérer catastrophique sans l’adjonction d’un panel de technologies assistantes, dont
ARIA.

La barre de menu de Google Docs

Nous nous proposons d’étudier la barre de menu du traitement de texte de Google, ici
représentée. Le principe de fonctionnement d’une barre de menu est connu ; c’est un
élément conventionnel des programmes informatiques, apparus très tôt après l’arrivée des
interfaces graphiques.

Barre de menu du système d’exploitation d’un Atari ST

Une barre de menu est ainsi constituée d’un certains nombre d’items de menu (le plus
souvent représenté par un mot : un nom substantif). Chacun de ces items peut-être
sélectionné puis actionné, pour exécuter l’opération que le concepteur du logiciel aura
définie.

Très souvent, chaque item d’une barre de menu, une fois actionné, ouvre un sous-menu.



Toutefois, si cela paraît évident en terme d’usage, il en va autrement en termes de
conception. Aussi, chacun de ces sous-menus doit être considéré comme un menu à part
entière, indépendant de la barre de menu.

Autrement dit, le composant (ou la fonctionnalité) « barre de menu » se cantonne à la
sélection et l’actionnement de ses items de menus. Au-delà, l’utilisateur utilise (en
l’ignorant) un autre composant.

Le sous-menu est un autre menu, indépendant de la barre de menu

Les Attentes fonctionnelles

La barre de menu Google, pour être utilisable et accessible à tous, doit répondre à quelques
critères simples :

1. L’utilisateur doit être informé qu’il s’agit d’une barre de menu (ou, à minima, d’un
menu). Cette information peut être visuelle (une suite de nom substantif, disposé à
sur une même ligne et régulièrement espacé indique, conventionnellement, une
barre de menu) mais doit aussi être indiquée lorsque la vue ne le permet pas
(annonce sonore, braille ou autres). Une telle annonce permet à l’utilisateur
d’interagir avec cet élément de manière conforme et identique avec d’autres menus
(celui de son explorateur de fichier, par exemple).

2. L’utilisateur doit pouvoir naviguer parmi les différents items de menu et tous les
sélectionner un à un. Avec la souris, les touches fléchées du clavier ou tout autre
dispositif de saisie.



3. L’utilisateur doit pouvoir actionner un item et poursuivre sa tâche, selon l’objectif
visé. Avec la souris, le clavier ou tout autre dispositif de saisie…

ARIA, pour peu qu’elle soit implémentée, répond à ces attentes.

Qu’a fait Google (Docs) ?

Ils ont implémenté ARIA dans leur application Web, bien sûr ! Ainsi, dans le code source
de la page HTML, on trouve un élément <div> avec l’attribut role défini à menubar. Cet
élément contient tous les items du menu : d’autres <div> avec l’attribut role défini à
menuitem. D’autres attributs ARIA ont été utilisé, pour compléter le fonctionnement du
menu, comme on le voit sur les captures d’écran.

L’équipe Google Docs a en réalité suivi les spécifications concernant le rôle d’une barre de
menu : http://www.w3.org/TR/wai-aria/roles#menubar et http://www.w3.org/TR/wai-
aria/roles#menuitem (ici, une citation pour la barre de menu, à titre d’illustration) :

« A presentation of menu that usually remains visible and is usually presented
horizontally. The menubar role is used to create a menu bar similar to those found in
Windows, Mac, and Gnome desktop applications.

A menu bar is used to create a consistent set of frequently used commands. Authors
SHOULD ensure that menubar interaction is similar to the typical menu bar interaction
in a desktop graphical user interface.

To be keyboard accessible, authors SHOULD manage focus of descendants for all
instances of this role, as described in Managing Focus. »



Une barre de menu ARIA



Un item de menu ARIA

En examinant le code source plus attentivement, on repère l’attribut tabindex. Cet
attribut n’est pas normalisé par les spécifications ARIA, mais fait partie du standard
HTML. Pourtant, bien conscients qu’une simple recommandation officielle ne suffira pas à
faire bouger les lignes, les rédacteurs d’ARIA ont écrit un ensemble de documentation à
l’intention des producteurs de contenus 5, en allant au-delà des spécifications ARIA :
une mauvaise structuration HTML ne sera pas plus accessible avec ARIA.

Qu’ont fait Mozilla, Google, Microsoft et consorts ?

Les navigateurs doivent être en mesure d’interpréter les attributs définis par le producteur
du contenu, puis d’envoyer les informations correspondantes aux API d’accessibilité
fournies par les systèmes d’exploitation.

Lors de l’élaboration des spécifications ARIA, tous les acteurs se sont accordés pour
réutiliser les éléments existants dans les différentes API (propres aux différentes
plateformes applicatives). C’est un choix important pour favoriser l’adoption rapide des
spécifications par les agents utilisateurs, et au bout du compte, améliorer l’accessibilité
générale du Web rapidement.

5 WAI-ARIA 1.0 Authoring Practices : http://www.w3.org/TR/wai-aria-practices/.



À ce titre, le guide d’implémentation pour les développeurs 6 fait explicitement référence
aux API accessibilités ; c’est même le fil conducteur du document :

« The WAI-ARIA User Agent Implementation Guide defines how implementations should
expose content to accessibility APIs, helping to ensure that this information appears in a
manner consistent with author intent. »

Plus spécifiquement, pour les barres de menu, les navigateurs doivent déclarer certains
rôles de façon très rigoureuse.

Qu’ont fait les développeurs de JAWS, VoiceOver et consorts ?

Les développeurs d’assistants utilisateurs ont travaillé bien avant la création d’ARIA pour
supporter quelques fonctionnalité du Web Applicatif. De fait, les éléments de formulaire
du langage HTML présentent de grandes similitudes avec les interfaces utilisateurs
traditionnelles (type desktop). Aussi, dès lors qu’un lecteur d’écran supportait les barres de
menu du système d’exploitation, il est virtuellement à même de supporter les
enrichissements ARIA des pages Web, via les API d’accessibilité.

Par conséquent, en pratique, une large part du support d’ARIA repose ici sur le navigateur
et sa qualité à communiquer le rôle de l’élément « menubar » à l’API. Pourtant, les
développeurs ont dû adapter leurs solutions logicielles pour prendre en compte les
informations rendues disponibles par le navigateur (notamment pour les contrôles claviers
des lecteurs d’écran). De nouvelles fonctionnalités d’aide à la navigation ont également été
ajoutées.

6 WAI-ARIA 1.0 User Agent Implementation Guide : http://www.w3.org/TR/wai-aria-implementation/.



Un bon exemple de documentation sur la prise en charge des spécifications ARIA a été
publié par Freedom Scientific, pour JAWS :

http://www.paciellogroup.com/blog/2010/10/jaws-support-for-aria/.

Au contraire des deux précédents acteurs, le groupe de travail WAI-ARIA n’a pas proposé
de document référence à l’intention exclusive des développeurs d’assistant utilisateur. On
peut en effet considérer la tâche moins cruciale, étant donné qu’il s’agit de leur cœur de
métier. Ils ont, de fait, tout intérêt à profiter au mieux de ces nouveaux apports en cours de
standardisation.

ARIA et l’expérience utilisateur

Le ressenti des utilisateurs - déficients ou non - face au web 2.0
Survey of Preferences of Screen Readers Users (2009)

A qui les spécifications ARIA profitent-elles ?

1. Aux personnes non-voyantes : ARIA permet d’offrir aux utilisateurs de lecteurs
d’écran une expérience de navigation similaire à la navigation visuelle dont
bénéficie toute personne valide. En donnant accès et vie à des applications Web
désormais communes qui, bien que dynamiques et interactives pour une personne
valide, restent statiques et bloquantes pour les personnes non-voyantes, ARIA met
les internautes sur un pied d’égalité.

2. Aux personnes déficientes de manière générale : ARIA permet aux utilisateurs ne
pouvant pas utiliser de souris, par exemple, une navigation au clavier plus aisée et
intuitive que celle que l’on trouve naturellement sur une page n’implémentant pas



les spécifications en question, notamment par la précision de l’attribut HTML
tabindex contrôlant le focus ou par la définition de zones sémantiques dans le
document.

3. Aux personnes non-déficientes : d’une manière générale, tout le monde aurait un
avantage à ce qu’ARIA soit implémenté, sous réserve bien sûr que les producteurs
de contenus qui alimentent le Web anticipent et prennent en compte les
recommandations du W3C. La navigation au clavier n'est pas réservée aux
personnes déficientes, de nombreuses personnes valides naviguent de cette façon
par souci de confort ou tout simplement car leur niveau d'expertise de l'application
ou de la machine qui la supporte leur permet d'avoir recours à ce mode de
navigation. Il en va de même pour les lecteurs d'écrans, certains utilisateurs valides
– même s'ils représentent une petite minorité – les utilisent pour des raisons
diverses (essentiellement pour effectuer des tests ou pour vérifier le niveau
d'accessibilité de certains sites).

ARIA ne pose aucun problème de rétrocompatibilité, c’est une amélioration pour tous
même si l’on en a pas un usage courant ou averti, il s’inscrit dans une démarche positive
voulue par le consortium. Bien au-delà des fonctionnalités et des widgets auxquels il
permet d'accéder, que ce soit des menus dynamiques, des sliders, ou bien encore des
lecteurs audio/video, ARIA permet avant tout à un public quasiment complet de pouvoir
profiter de tous les avantages du Web.

Cela passe notamment par un meilleur accès aux réseaux sociaux pour les personnes
déficientes – aujourd'hui devenus presque indispensables pour une vie sociale épanouie –
mais également par la libération des produits culturels auparavant enfermés dans des
capsules de type lecteur Flash. Cela s'inscrit donc bien dans la démarche du W3C visant à
faire du Web une place ouverte, l'open Web, où chacun aurait un accès équitable et
équivalent aux ressources, qu'elles soient culturelles ou non.

Un outil dont il faut pouvoir et savoir se servir

Avant même de se poser la question de la maîtrise techniques des outils d'assistance à la
navigation, il faut considérer l'accès même à ces ressources. En effet, tout comme l'on ne
peut exclure les utilisateurs de navigateurs obsolètes lors du processus de production d'un
site Web, il est nécessaire de toujours considérer les utilisateurs les moins bien dotés.

Les spécifications ARIA sont aujourd'hui largement compatibles avec l'ensemble des
navigateurs ainsi qu'avec la plupart des lecteurs d'écran modernes du marché (JAWS étant
encore majoritaire). Cependant, il existe de gros problèmes de compatibilité avec des outils
plus anciens et un certain nombre d'utilisateurs peuvent donc se trouver exclus – même si
ce n'est que temporaire. On trouve donc ça et là des recommandations mettant en avant ce
problème et préconisant une certaine prudence, Mozilla conseille en effet d'utiliser ARIA
en ayant conscience des utilisateurs minoritaires :

« Implementations vary and older technologies don't support it well (if at all). Use either



"safe" ARIA that degrades gracefully, or ask users to upgrade to newer technology. »
https://developer.mozilla.org/en/ARIA

Les limites d'ARIA ne se situent pas seulement au niveau matériel, la bonne utilisation de
ce système requiert en effet un certain nombre de connaissances tant des navigateurs que
des lecteurs d'écran et cela peut poser certains problèmes de navigation à des utilisateurs
peu expérimentés. En effet, il faut bien considérer qu'au-delà des simples contraintes liées
à la possession de l'outil, le niveau d'expertise de celui-ci peut rapidement remettre en
cause son usage.



Les compétences informatiques des utilisateurs de lecteurs d'écran.

Bien que peu récentes, ces statistiques montrent bien qu'un nombre non-négligeable
d'utilisateurs – qu'ils soient déficients ou non – manquent de compétences techniques tant
face aux outils de navigation qu'aux outils d'assistance.

Au-delà du niveau d'expertise, les utilisateurs n'ont pas tous le même usage de ces outils.
En effet, tout comme bon nombre d'utilisateurs valides se contentent d'un niveau de
maîtrise relativement faible des outils qu'ils utilisent quasi-quotidiennement, il n'est pas
surprenant de retrouver la même tendance chez les utilisateurs déficients.

Cela s'explique principalement par la qualité des outils disponibles sur le marché, qui ne
nécessitent pas de grandes compétences pour être utilisés de manière basique et répondre
à des besoins fondamentaux, mais également par simple méconnaissance des possibilités.
D'une manière générale, ce constat est plutôt positif, il témoigne de la volonté des
producteurs d'outils techniques de démocratiser leurs produits et d'en étendre l'usage à
une majorité d'utilisateurs. Cependant, dans le cas d'ARIA, certains éléments requièrent
une expertise certaine pour exploiter au mieux les fonctionnalités prévues par les
spécifications.

Usage des landmarks d'ARIA




ARIA est encore mal connu, on voit que plus de 30% des utilisateurs n'ont pas
connaissance d'une fonctionnalité pourtant centrale, les landmarks. Alors même qu'ARIA
est directement développé à l'égard des utilisateurs de lecteurs d'écrans par exemple, on
constate que beaucoup d'entre eux n'utilisent que peu ou pas ses avantages. Est-ce par
choix ou par simple méconnaissance ? Il est difficile de trancher.

Quoiqu'il en soit, les chiffres ne sont pas vraiment positifs : en tout et pour tout, seulement
14.5% des utilisateurs ont recours aux landmarks, on imagine que les chiffres ne sont guère
mieux concernant les autres fonctionnalités que propose ARIA, il existe donc un réel
problème d’acclimatation aux nouvelles technologies d'assistance. En effet, cette même
étude montre qu'en 2010 environ 37% des utilisateurs estimaient que le Web était
aujourd'hui plus accessible qu'avant, contre plus de 45% en 2009.

Ces données doivent malgré tout être nuancées, on constate en effet qu'une grande
majorité des utilisateurs concernés prévoient une nette amélioration de l'accessibilité
générale des sites Web dans un futur proche, notamment grâce à des technologies comme
ARIA, il ne faut donc pas juger le travail en cours sur ces quelques retours pessimistes.

Dans cette optique, on peut également noter qu'ARIA s'accompagne d'une communauté
active – qui rejoint celle, plus large, qui soutient et développe l'accessibilité Web au
quotidien – et qu'un grand nombre de ressources sont disponibles sur la toile de manière
ouverte et libre, provenant du W3C ou non. Alors que les utilisateurs pouvaient se trouver
confrontés à un silence contraignant en termes de feedback ou tout simplement
d'assistance, il existe aujourd'hui un réel support technique et éthique des questions
d'accessibilité et cela ne peut que favoriser l'essor de technologies telles qu'ARIA.

Il existe donc encore beaucoup de contraintes liées à l'utilisation de matériel inadapté, à
des mises à jour de logiciels trop peu fréquentes, ou tout simplement au manque de
connaissances précises pour personnaliser les logiciels d'assistance et donc les utiliser
efficacement, mais on peut assez aisément imaginer un futur optimiste dans ces domaines
car les conditions sont aujourd'hui bien plus favorables qu'avant.

Implémenter... mais pas que !

L'implémentation d'ARIA soulève, au delà de son simple fonctionnement technique, un
certain nombre de questions d'ergonomie, notamment pour les personnes voyantes. Même
si techniquement tout fonctionne, il faut prendre en compte les conventions et standards
de l’ergonomie Web pour offrir un usage optimal de l’outil.



Interface de Gmail, exemple d'implémentation d'ARIA dans une application riche (2012)

Si l'on prend l'exemple de l'interface principale de Gmail, on peut voir que certaines
fonctionnalités utilisent ARIA, notamment les menus déroulants qui apparaissent en haut
de page et qui donnent accès aux réglages et aux fonctions annexes. Il suffit donc de
naviguer jusqu'au lien « Paramètres » par exemple, grâce à la touche tabulation, pour
ensuite avoir accès au sous-menu déroulant correspondant, tout ceci en utilisant
uniquement le clavier. Une fois activé, on peut donc naviguer au sein du menu avec les
touches fléchées du clavier, ce qui est très agréable en termes de confort et qui permet
surtout d'accéder facilement aux liens d'ordinaire « masqués » aux lecteurs d'écrans.

Seulement, comme souvent dans les questions informatiques, le bon fonctionnement
technique d'un module est nécessaire mais pas suffisant, il est nécessaire de toujours
considérer l'utilisateur et donc des questions ergonomiques qui aideront à rendre ce
module utilisable. Dans le cas de ce menu déroulant de Gmail, on comprend donc que
donner l'accès aux « sous-informations » aux utilisateurs de lecteurs d'écrans est
important mais que cela implique de réfléchir à la manière de lui faire comprendre qu'il y a
désormais accès.

Ici, Google répond parfaitement à cette question en renforçant l'affordance du bouton
« Paramètres». Tant visuellement qu'auditivement (par un attribut), il est clair que ce
bouton donnera accès à du contenu secondaire, graphiquement symbolisé par la petite
flèche pointant vers le bas, un standard ergonomique. Il faut donc bien garder à l'esprit,
lors de l'implémentation d'ARIA, que c'est un travail de fond et de forme, il ne faut négliger
aucune de ces deux dimensions pour obtenir un résultat satisfaisant, qui n'est autre que la
réussite ou l'échec de l'accès à l'information.

ARIA peut-il devenir une gêne ?

Les attributs de régions actives, « live regions », permettent d'établir des zones se mettant
potentiellement à jour dans le document et d'avertir l'utilisateur d'éventuels ajouts ou
modifications de contenus. Il existe notamment une valeur rude qui va littéralement



stopper l'utilisateur dans sa navigation afin de le prévenir d'une mise à jour. Cette
pratique, plutôt brutale, peut facilement aller à l'encontre du but premier de
l'implémentation d'ARIA à savoir favoriser le repérage et la compréhension d'un document
tout en laissant l'utilisateur totalement libre de ses choix et de ses actions.

Il se peut également, en cas de mauvaise implémentation, que la sémantique d'HTML
entre en conflit avec la sémantique d'ARIA et porte ainsi atteinte à l'accessibilité d'une
page, c'est pourquoi l'utilisation des spécifications reste encore difficile ou du moins
laborieuse à mettre en place car elle requiert de nombreux tests et donc des coûts
supplémentaires qui, souvent, sont laissés de côté.

ARIA en quelques points

1. ARIA représente un progrès indéniable en matière d'accessibilité web de part son
ouverture et sa philosophie.

2. ARIA tend à devenir un standard, il s'inscrit pleinement dans la vision positive du
W3C.

3. ARIA permet d'accéder à des contenus riches et dynamiques sans contraintes, c'est
une porte sur le web 2.0 qui a longtemps été fermée aux personnes déficientes.

4. Il reste hasardeux et peu (ou mal) implémenté, mais sa progression est
encourageante.

La mise en avant de la structure sémantique des différentes zones d’un document dit
« riche » est souvent problématique en termes d’accessibilité, les spécifications ARIA y ont
d’ailleurs parfaitement répondu en introduisant le concept de « landmarks ». Seulement,
certains pans d’ARIA – et notamment les landmarks – semblent aujourd’hui perdre de leur
intérêt car l’arrivée d’HTML5 a permis une nette amélioration dans ce domaine. Les
landmarks spécifiés par ARIA (main, navigation, banner, etc...) sont en effet rendues
obsolètes ou du moins redondantes par les nouvelles balises intégrées dans HTML5.

On peut aujourd’hui contourner une écriture de type <div id="nav"
role="navigation">…</div> en s’appuyant sur des balises sémantiques comme
<nav>…</nav> tout en conservant les mêmes bénéfices et en simplifiant le code source.
Cependant, HTML 5 ne sera pleinement utilisé et utilisable que d’ici quelques années et
ARIA reste donc tout à fait pertinent sur bon nombre de points. On peut d'ailleurs espérer
qu'il sera un jour nativement intégrée au langage HTML et qu'il ne sera donc plus
nécessaire de « faire l'effort » de rendre un site accessible, il le sera par défaut, de manière



naturelle. Ce futur est encore lointain, de part la médiocrité trop souvent notable de la
majorité des sites actuellement en ligne sur le Web, mais le développement continu des
technologies d'assistance et des standards d'accessibilité laisse imaginer une progression
certaine et positive.

Conclusion
Les implémentations existent et se multiplient, tandis que les outils d’éditions les plus
répandus (Drupal, WordPress…) intègrent désormais ARIA. Cependant, qui, parmi les
producteurs de site Web, fait de réelles études auprès des utilisateurs concernés par ces
spécifications ?

Il est de fait très difficile d’en quantifier les bénéfices exclusifs. D’autant plus difficile que
de telles améliorations sont très souvent accompagnées de refontes plus profondes, qui
impactent un public trop hétérogène pour être analysé finement.

Nous pensons qu’une approche qualitative pour l’étude d’une expérience utilisateur dans
l’usage d’application Web riches offrirait un point de vue intéressant et indispensable pour
la compréhension et l’utilisation efficiente des spécifications ARIA.



Glossaire
A
Agent Utilisateur

En anglais, « user agent ». Logiciel interface de l’utilisateur. Dans une topologie client-
serveur d’un réseau informatique, l’agent utilisateur est le client, c’est la dernière brique
logicielle avant l’utilisateur du service. Pour le Web navigateur (Microsoft Internet
Explorer, Mozilla Firefox, Google Chrome, Safari, Opera…).

AJAX

Asynchronous Javascript and XML. Technologie de développement web basé sur le
JavaScript qui permet une communication entre différentes entités d’une page web et
différents langages : Javscript, CSS, XML… Cet ensemble de langage permet de construire
des contenus dynamiques.

API

Application Programming Interface. C’est une interface fournie par un programme
informatique. Les API permettent aux programmes d’interagir les uns avec les autres.

Assistant Utilisateur

En anglais, « assistive technology ». Dispositif d’aide technique aux utilisateurs déficients.
Les lecteurs d’écran (tels que JAWS, NVDA ou Voice Over) sont les plus connus, mais il y a
aussi des dispositifs d’aide à la saisie ou des systèmes de pointage alternatif, des loupes
d’écran… etc. Les possibilités sont infinies.

L
Landmarks

Zones définie d'un document. L'attribut role propose un ensemble de valeurs permettant
de définir les grandes structures de la page. Ces repères peuvent servir de point de
navigation (de manière similaire aux titres) dans la structure pour naviguer rapidement.



P
Protocols and Formats Working Group

C’est le nom du groupe de travail qui se réunit pour produire les documents du W3C et
plus précisément ceux des spécifications ARIA.

R
Rich Interactive Applications

Ce sont les applications dynamiques, les contenus dits « riches » ou encore les « contenus
dynamiques interactifs ». Ce sont des zones d’une page Web qui se mettent à jour
régulièrement et indépendamment du reste de la page.

W
WAI

“Web Accessibility Initiative” regroupe un ensemble de recommandations du W3C qui
concerne spécifiquement l’accessibilité du web.

W3C

World Wide Web Consortium. Le W3C est un organisme à but non lucratif, regroupant une
communauté internationale pour travailler autour des standards ouverts et assurer au Web
un développement pérenne.

X
XMLHttpRequest

C’est un objet du langage de développement JavaScript qui permet une communication
direct entre la page Web et le serveur. C’est cette technologie qui permet justement le
rafraîchissement d’une zone d’une page.


Dossier2012 aria-delamer-menant-vergnol

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (6)

Semelhante a Dossier2012 aria-delamer-menant-vergnol

Semelhante a Dossier2012 aria-delamer-menant-vergnol (20)

Dossier2012 aria-delamer-menant-vergnol