I’m working with web pages for more than 6 years now, and saw things evolving a lot, the so-called web 2.0, the shift from pages to applications, from static to dynamic, from centralized publication to global publication. If the way we are using this tool to not only gather information but really interact with our peers changed, the problem of being accessible to everyone remains. And will always be there.
And the situation is maybe worse than before since we are now relying on that f-word system. The accessibility has been an important point is remains as is. A web 2.0 (or call it like you want) service can use advanced accessibility tools. It can inject extra information to his markup in order to help assisting technologies (like screen readers). To the WCAGguidelines (and its errata depending of your opinion on that case), ARIA aims to target what has been left behind by HTML, the desktop widget that has be adapted to the web like tabs, drop down menu and many more.
ARIA implementation is still a work in progress but it’s already present in Firefox 2 (and especially 3), Opera and the upcoming MSIE 8. My previous tries of building a web chat, are the kind of rich Internet application that requires these new tools to offer a similar experience like Pidgin (formerly Gaim) from a screen-reader user point of view.
Using Pidgin with Orca (the GNOME screen reader), you’ll hear every new messages coming while your cursor is in the edit field and even while you’re typing. You can achieve the same behaviour using Firefox 3 and Orca by enriching the HTML with some ARIA attributes.
Basically, it could look like that:
<h1 id="chat-title">Chat room:</h1>
<ol id="chat" aria-describedby="chat-title">
</ol>
<form onsubmit="return chat(this);" method="post" action="">
<label for="m">
Your message:
<input type="text" id="m" name="m">
</label>
<input type="submit" value="send">
</form>
<!-- not sure about combining log and polite -->
<p id="log" role="log"aria-live="polite"aria-atomic="true">
</p<
#chat is the content of the chat room. The form to send the message, as it’s a rich application with no reloading of the page, the submit event must be caught and stopped. The chat function, will send the message over the network and maybe give the focus back to the input field. #log will be observed by the screen-reader as its a "live" element. And its content will be read if nothing else occurs (polite) and in an atomic way, by not cutting a message. This log have to be hidden to the normal users (of course). The new messages coming from the server (using Comet for example) will populate the #chat and also the #log. And it works (tested with Firefox 3 and Orca).
Find a demo here (that fakes server messages coming from time to time) or watch the video (make sure the sound is turned up).
My conclusion on this is that it’s not because your product has a very advanced feature that you cannot, in theory, offers it the maximum of users regarding their capabilities or disabilities. And in some cases isn’t a huge overhead. And ARIA will be applied to SVG has well, if you’re doing RIA using that technology.
Depuis mes débuts sérieux dans la conception de pages internet, le jour où j’ai abandonné Dreamweaver 3 et son lot de cracks pour HTMLkit (à l’époque), l’accessibilité fait partie des points inhérents aux web, des non pas contraintes, mais devoirs moraux qui imcombent au développeur. Ce petit truc qu’il ne doit pas oublier, cette dose d’empathie. Les sites comme A List Apart (donc Pompage faisait régulièrement l’écho), Digital Web et relayé par les bloggeurs ont depuis un peu changé de discours, le combat contre les frames et autres mésusage des tableaux HTML semblant de manière générale gagné. La mauvaise accessibilité des mises en forme à base de table était un argument fort, on a jeté les tables et pas forcément amélioré la dite accessibilité.
Les petits soucis d’autrefois ne sont-ils pas aujourd’hui plus important depuis qu’on se repose sur ce système fortement informatisé, de plus en plus. Ne pas créer de barrière artificielle, virtuelle à l’image d’un escalier que ne pourrait emprunter aisément une personne âgée; voire pas du tout pour quelqu’un n’ayant plus l’usage de ses jambes. Quand Internet passe d’une solution alternative, à une solution principale, essentielle ou parfois unique, le point d’être ouvert à toutes et à tous prend de l’importance et ne doit pas être relêgué aux “nice to have”.
ARIA vient s’ajouter aux recommandations du W3C pour répondre au flou qui entoure la complexisation de ce que nous faisons avec le web aujourd’hui. Il se destine aux applications riches (RIA en anglais) comme le dit si bien son acronyme. Par exemple, la métaphore visuelle de l’astérisque pour représenter un champ de formulaire obligatoire peut être fait avec un attribut ARIA: aria-required="true".
Et, le champ texte est remplacé par une image d’astérisque via CSS (avec un truc aussi laid que : display:-moz-inline-box;display:inline-block;). Et pour joindre les deux, il est possible de faire ceci :
Bref, ça devient tordu, mais si pas d’information est à éviter absolument, une duplication est également mauvaise. NB: Orca gère le aria-hidden mais pas aria-required par exemple, le résultat n’est pas celui désiré donc, dommage.
Dans la partie anglaise de ce post, trouvez un exemple plus avancé de l’usage des régions vivantes (live) dans le cadre d’un chat où il est possible d’approcher le comportement d’un application native telle que Pidgin (autrefois connue sous le nom de Gaim).
En conclusion, appliquer ARIA ne demande pas forcément un gros effort en terme de modifications. Ça demande un investissement certain en tests néanmoins. Et ajoute une quatrième composante aux : contenu, mise en forme et comportement, qui serait rôles ou responsabilité, pouvant être fait entièrement avec JavaScript.
