Accessibilité du web : Description et Enjeux [2/2]

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.

L’accessibilité des RIA

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 :

• Permettre la navigation au clavier : ARIA étend l’attribut HTML tabindex et permet son utilisation pour tout élément visible, cela permet de donner le focus dans un ordre déterminé à toutes les parties d’une application web.
• Attribuer un rôle à chaque élément de la page : Comme nous l’avons remarqué précédemment, on peut attribuer à toutes balises HTML un rôle (ex : h1 est un titre de niveau 1). ARIA définit de nouveaux rôles pouvant être attribué aux éléments d’une RIA, on pourra par exemple associer le rôle de « progressbar » à une barre de chargement visuelle.
• Attribuer un état à chaque élément de la page : L’exemple de la « progressbar » illustre également le besoin de connaître l’état des différents éléments. ARIA prévoit qu’une « progressbar » soit également décrite par sa valeur minimale (valuemin) et maximale (valuemax) ainsi que par sa valeur actuelle (valuenow). Ces valeurs devant être mise à jour dès que l’indicateur visuel de progression est mis à jour.
• Informer l’utilisateur des mises à jour asynchrones : En approfondissant l’exemple de la « progressbar », on remarque rapidement que sur une page contenant 200 éléments il est impossible pour les technologies d’assistance de connaître et de localiser les mises à jour informant l’utilisateur du chargement de l’application. ARIA définit pour se faire un attribut aria-live pouvant prendre 4 valeurs :

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

Labellisations

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:

• Niveau Bronze : Le site a pris en compte les recommandations essentielles de l’accessibilité. La consultation du site via des aides techniques (terminal Braille, logiciel lecteur d’écran, synthèse vocale,…) est possible ;
• Niveau Argent : En plus de satisfaire les critères du niveau bronze, le site a respecté des recommandations facilitant la navigation ;
• Niveau Or : Le site respecte toutes les recommandations d’accessibilité.

Après une certification Accessiweb il est possible de labelliser le service avec Euracert, les niveaux de ce label sont les suivants :

• Niveau A : Le site à obtenu le label AccessiWeb Bronze et respecte une liste de critères supplémentaires permettant de vérifier sa conformité au niveau A des WCAG 1.0
• Niveau Double-A : Le site a obtenu le label Accessiweb Argent ou Or et respecte une liste de critères supplémentaires permettant de vérifier sa conformité au niveau Double-A des WCAG 1.0

Il n’existe à ce jour aucune certification d’accessibilité pour les RIA.

Outils de test d’accessibilité

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 .

Enjeux d’accessibilité et impacts techniques

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 :

• Un grand nombre de frameworks (ex : RichFaces, GWT) génère le code HTML/JS, le code généré est-il compatible avec les normes d’accessibilité du W3C ? quels sont les leviers d’action disponibles?
• Les tests visant à différencier de manière automatisée un utilisateur humain d’un ordinateur (tests de Turing) tels que les Captcha et les claviers virtuels sont – par construction – inaccessibles pour les technologies d’assistance, comment peut-on concilier ces tests avec une accessibilité de plus en plus nécessaire ?