samedi 17 septembre 2011

L'accessibilité est-elle l'amie du développeur ?


Depuis quelques années, le nombre de navigateurs se multiplient avec les plateformes (PC, Netbook, Smart Phone, Tablet, ....) et de plus en plus de personnes de tous âges et de toutes conditions ont accès à Internet.
Nous développeurs serons-nous capable de répondre aux attentes de tous nos utilisateurs ?
Les applications webs sont-elles réservées à une élite dotée des meilleures capacités physiques et cognitives ?
L'accessibilité peut nous aider à construire des applications ouvertes au plus grand nombre tout en ayant des effets de bords positifs sur les performances, la maintenance et la qualité des applications.
En effet, dans le contexte d'une refonte de notre cadriciel web maison, j'ai du mener une étude pour mesurer les impacts de l'application de règles d'accessibilité. Les résultats de mon étude montre que l'accessibilité doit être au coeur du processus de développement.

WCAG 2.0 : l'accessibilité appliquée au web


Le consortium W3C propose la norme WCAG pour l'accessibilité des contenus webs aux personnes en situation de handicap.
Un handicap est selon Wikipedia :
la limitation des possibilités d'interaction d'un individu avec son environnement, causée par une déficience qui provoque une incapacité, permanente ou non et qui mène à un stress et à des difficultés morales, intellectuelles, sociales ou (et) physiques.
Nous baserons nos réflexions sur cette norme qui définit 4 grands principes à respecter :
  • Perceptible : l'information et les composants de l'IHM doivent être présentés à l'utilisateur de façon à ce qu'il puisse les percevoir.
  • Utilisable : les composants de l'IHM et de navigation doivent être utilisables.
  • Compréhensible : rendre le contenu textuel lisible et compréhensible.
  • Robuste : optimiser la compatibilité avec les agents utilisateurs actuels et futurs, y compris les technologies d'assistance.
Chaque principe est décliné en plusieurs règles d'accessibilité à respecter. Chaque règle est associée à un niveau d'accessibilité : A, AA ou AAA.
Plus le niveau est élevé plus la règle est complexe et coûteuse à implémenter.
Evidemment, l'utilisation d'un cadriciel web supportant WCAG et un niveau d'accessibilité donné (AA par exemple) est un atout déterminant pour la mise en oeuvre du référentiel WCAG dans vos applications webs. Le cadriciel permet alors d'absorber une grande partie des coûts.

Mise en oeuvre du WCAG


Il est important de comprendre qu'il ne faut pas appliquer bêtement ce référentiel.
Tout d'abord, il convient de choisir un niveau d'accessibilité pour vos contenus webs. D'ailleurs, plusieurs niveaux d'accessibilité peuvent coexister au sein d'une application web qui regroupe des contenus différents.
En effet, il peut être plus judicieux de proposer un niveau AA pour les contenus les plus populaires, un AAA sur les quelques contenus critiques puis un niveau A sur la majorité des contenus , plutôt que de se fixer un niveau AA sur tous les contenus.
Le référentiel WCAG est accompagné d'un guide technique qui propose des solutions pour la mise en oeuvre de chaque règle.
Il est aussi crucial de comprendre que la mise en oeuvre du WCAG doit se faire dès la conception de l'application.
Quelque exemples de règle :
  • Règle 1.4.3 (AA) : la présentation visuelle du texte et du texte sous forme d'image a un rapport de contraste d'au moins 4,5:1
  • Règle 1.4.4 (AA) : à l'exception des sous-titres et du texte sous forme d'image, le texte peut être redimensionné jusqu'à 200 pour cent sans l'aide d'une technologie d'assistance et sans perte de contenu ou de fonctionnalité.
  • Règle 3.3.1 (A) : si une erreur de saisie est détectée automatiquement, l'élément en erreur est identifié et l'erreur est décrite à l'utilisateur sous forme de texte.
  • Règle 4.1.1 (A) : à moins que les spécifications ne le permettent, dans un contenu implémenté via un langage de balisage, les éléments ont des balises de début et de fin complètes, ils sont imbriqués conformément à leurs spécifications, ils ne contiennent pas d'attributs dupliqués et chaque ID est unique.
Si tous les développements sont faits quand vous essayez d'appliquer le référentiel alors vous serez contraints de revoir la totalité des contenus webs .
Ceci implique que l'équipe de développement, du chef de projet au développeur doivent connaître les règles à appliquer avant de commencer à développer l'application.
Comme on vient de le voir, l'accessibilité a un impact important sur l'équipe de développement.
Mais quels sont les bénéfices que vous pouvez en tirez ?

Les coûts de développement et de maintenance


Certaines règles (1.3.1, 1.4.5, ...) vous contraignent à séparer la présentation de l'information, de l'information elle même. Cela se traduit par une utilisation de feuilles CSS et de XHTML.
Très vite on en vient à envisager la mise en place de thèmes basés sur CSS car si l'on veut présenter de l'information pour des publics différents au moindre coût (daltonien, mal voyant, normal, smartphone, tablet, ...), c'est la bonne pratique à mettre en oeuvre.
Cette factorisation des éléments de présentation dans les CSS permet d'avoir un code XHTML plus clair et de cibler les changements sur quelques CSSs plutôt que de revoir chaque contenu HTML ou XHTML de l'application.
Certaines règles mettent en avant le respect de la syntaxe XHTML (4.1.1) ou l'ajout de méta données (4.1.2), ceci permet l'utilisation d'outils de validation ou transformation.
En effet, imaginez que votre application contient des composants de type "Calendrier" traduit en XHTML sous la forme d'un amas de DIV.
En utilisant l'attribut role vous allez indiquer que cette zone avant informe correspond à un composant graphique de type calendrier :
  <div id="cal1"  role="calendar" ...>
     <!Code XHTML >
  </div>
Ce faisant vous ouvrez la voie à des applications intéressantes comme la transformation de contenu XHTML.
Imaginez que votre client vous demande de revoir la charte graphique et ergonomique de l'application, vous pourrez ainsi utiliser une transformation des composants XHTML par une technologie quelconque qui supporte XHTML et XSLT.

Les performances


Certaines règles poussent à privilégier l'utilisation de texte plutôt que d'images ce qui réduit le nombre de requêtes HTTP et diminuent l'utilisation de la bande passante :
  • l'information véhiculée par du texte est nettement plus compressible que les images.
  • avec la diminution du nombre de requêtes HTTP, vos serveurs seront moins sollicités.
D'autres règles promeuvent une navigation claire ainsi que des mécanismes de navigation et d'interactivité maîtrisés par l'utilisateur. En effet, nombre de site web proposent des contenus qui multiplient les requêtes via des composants qu'IHM que l'utilisateur subit.
Quelques règles impliquées dans l'amélioration des performances : 1.4.5, 3.2.5, ....

Conclusion


L'accessibilité est un élément fondamental des applications webs. Pour être sans douleur, elle doit être prise en compte dès la conception et doit structurer la réalisation ou la maintenance de tous les éléments d'IHM.
Quelques références :



Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

Aucun commentaire:

Enregistrer un commentaire