Cet article est le second d'une série de deux articles traitant de l'accessibilité du web et de ses enjeux. Nous nous attarderons ici à décrire les normes disponibles pour les RIA, les différents labels existants en Europe ainsi que les outils de validation permettant de confirmer l'accessibilité d'un site ou d'une application.
Les nouvelles techniques utilisées pour repousser les limites imposées par les technologies web « standard » nécessitent un investissement plus important pour les rendre accessible.
Les mises à jour asynchrones ne sont souvent pas perçues par les technologies d’assistance et, quand elles les identifient, elles n’ont aucun moyen de localiser la zone mise à jour.
De plus, bien que les widgets ressemblent à des applications classiques, des informations importantes ne sont souvent pas disponibles pour les technologies d’assistance (ex : quel est le rôle du widget ? les cases sont-elles cochées ?). Gez Lemon, dans son article d’introduction à WAI-ARIA (en anglais) fait le parallèle avec la stylisation d’un titre (grande police, souligné, gras…) faite sans utiliser les balises de titres HTML (h1 à h6) : Le texte ressemble à un titre mais n’est pas perçu comme tel par les technologies d’assistance.
C’est pour remédier à ces problèmes que le W3C a défini le WAI-ARIA, qui offre la possibilité de décrire les rôles, états et propriétés des widgets et d’informer les technologies d’assistance des mises à jour du contenu d’une page.
On pourra par exemple :
- Aria-live= « off » : Les mises à jour de l’élément ne doivent pas être annoncées à l’utilisateur
- Aria-live= « polite » : Les mises à jour de l’élément ne doivent être annoncées à l’utilisateur que si celui-ci n’est pas en train d’interagir avec d’autres éléments
- Aria-live= « assertive» : Les mises à jour de l’élément doivent être annoncées à l’utilisateur dès que possible, il n’est toutefois pas nécessaire d’interrompre l’utilisateur immédiatement.
- Aria-live= « rude» : Les mises à jour de l’élément doivent être annoncées à l’utilisateur immédiatement.
Les recommandations WAI-ARIA sont déjà prises en compte par un grand nombre de frameworks permettant la réalisation d’application internet riches. On citera par exemple la class Accessibility disponible dans GWT depuis la version 1.5 .
On remarquera en outre que l’application des WAI-ARIA devrait permettre de simplifier la testabilité des IHM (en rendant le code html plus accessible pour les technologies d'assistance) des applications riches ainsi que le référencement des sites web dynamiques.
Depuis 2007, le label européen Euracert permet – en complément de celui délivré par un organisme de labellisation de l’accessibilité du Web - de valider l’accessibilité des sites internet. En France, l’organisme habilité à décerner ce label est Accessiweb (association BrailleNet). En France, moins d’une centaine de sites ont été certifiés Accessiweb. Il s’agit de sites des services publics et de quelques grandes entreprises.
La certification Accessiweb peut être décernée à l’un des trois niveaux suivants, on trouvera plus de détails ainsi qu’une correspondance avec les normes W3C (A, double-A ou triple-A) sur le site d’Accessiweb:
Après une certification Accessiweb il est possible de labelliser le service avec Euracert, les niveaux de ce label sont les suivants :
Il n’existe à ce jour aucune certification d’accessibilité pour les RIA.
De tels outils ne peuvent être suffisants pour vérifier l’accessibilité d’un site ou d’une application, les tests « grandeur nature » sont nécessaires pour assurer l’accessibilité d’un site web. En particulier, aucun outil n’a pour l’instant obtenu suffisamment de visibilité en ce qui concerne l’accessibilité des RIAs. Des outils automatiques permettent néanmoins de vérifier la conformité d’un site web avec les spécifications WCAG 1.0, parmi eux, on peut citer OCAWA et Opquast, ce dernier étant le plus utilisé par les collectivités territoriales et les ministères .
Cet article d’introduction à l’accessibilité se termine, il reste cependant plusieurs sujets à aborder. En particulier nous aborderons dans un article à venir la complexité technique des solutions permettant la création d’applications riches accessibles :