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 StandardsClé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




SommaireWAI-ARIA......................................................................................................................................... 4

Introduction à ARIA...................................................................................................................... 4Qu’est-ce qu’ARIA ?................................................................................................................ 4Un peu d’histoire… ................................................................................................................. 4Les objectifs d’ARIA................................................................................................................ 5Les contenus dynamiques sont partout : quelques exemples….............................................. 8Les implémentations d’ARIA................................................................................................. 10L’action des logiciels d’assistances ...................................................................................... 12« Vers l’infini et au-delà… ! »................................................................................................. 13

ARIA par l’exemple......................................................................................................................... 13Au menu : Google !.................................................................................................................... 14

Les Attentes fonctionnelles.................................................................................................... 15Qu’a fait Google (Docs) ?...................................................................................................... 16Qu’ont fait Mozilla, Google, Microsoft et consorts ?...............................................................19Qu’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 ?........................................................................ 21Un outil dont il faut pouvoir et savoir se servir....................................................................... 22Implémenter… mais pas que !...............................................................................................25ARIA peut-il devenir une gêne ? ........................................................................................... 26ARIA en quelques points....................................................................................................... 27

Conclusion..................................................................................................................................... 28Glossaire........................................................................................................................................ 29



WAI-ARIADepuis 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 (JAWS2, 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’exempleLe 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 utilisateurs3 Web (navigateurs), comme Microsoft, Google, Mozilla, Apple, Opera Software… ;

3. les éditeurs (ou développeurs) des assistants utilisateurs4, 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.


https://docs.google.com/


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. »


http://www.w3.org/TR/wai-aria/roles#menuitem

http://www.w3.org/TR/wai-aria/roles#menuitem

http://www.w3.org/TR/wai-aria/roles#menubar




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 contenus5, 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/.


http://www.w3.org/TR/wai-aria-practices/


À ce titre, le guide d’implémentation pour les développeurs6 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/.


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.0Survey 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


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


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.


https://developer.mozilla.org/en/ARIA


Les compétences informatiques des utilisateurs de lecteurs d'écran.Survey of Preferences of Screen Readers Users (2009)

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



Survey of Preferences of Screen Readers Users (2010)

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.

ConclusionLes 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.


Technology

Dossier2012 aria-delamer-menant-vergnol