CRAW2013 : gestion de projet, méthodes et enjeux

Publié le · Modifié la dernière fois le

Après HTML5 et ARIA et la mobilité, voici la troisième partie de mon compte-rendu de la Conférence Romande sur l’Accessibilité du Web 2013.
Cette fois, nous parlons de gestion de projet avec la présentation d’Armony Altinier (lien externe) : « Gestion de projet : Intégrer l’accessibilité dans un projet web, méthodes et enjeux ».

Ayant commencé à bercer dans la gestion de projet dans mon précédent poste, c’est le genre de présentations qui m’intéressent particulièrement. J’étais donc assez impatient d’assister à cette-là.

Méthodes existantes

Avant de donner des réponses, Armony pose les bases et elle nous peint un état des lieux de l’accessibilité aujourd’hui.

La première question est de savoir s’il y une méthode de gestion de projet propre à l’accessibilité ou si l’accessibilité doit être intégrée dans les méthodes existantes.
Le constat qu’elle fait est que, généralement, la méthode de base de l’accessibilité est l’évaluation ou l’audit. Autrement dit on commence un projet à partir de l’évaluation ou l’audit du site ou service web. Elle évoque les principaux référentiels utilisés : les WCAG 2.0 (norme ISO depuis fin 2012), traduits en France par le référentiel Accessiweb ou le RGAA.

Conscient des limites des WCAG dans le cadre de projets web, le W3C a mis en place une méthode d’évaluation plus opérationnelle : WCAG-EM. On y retrouve d’ailleurs pas mal de ressemblances avec nos référentiels français.

La méthode WCAG-EM se découpe en 5 phases :

  1. Définition des objectifs et périmètre du projet
  2. Exploration du site
  3. Échantillonnage du site en fonction des objectifs et du périmètre
  4. Évaluation de l’échantillon
  5. Rapport d’évaluation

Il s’agit là d’une méthode classique dans le cadre d’un audit. Concernant les objectifs, elle précise cependant que « atteindre le niveau AAA » ne doit pas être un objectif.
La phase cruciale est la dernière : le rapport. Dans le cadre de la méthode WCAG-EM sont définis 3 types de rapports :

  • Le rapport basique listant les points en conformité et les échecs à l’échelle du site. C’est une vue macro, si un critère est en échec sur une page, il est considéré en échec pour le site.
  • Le rapport détaillé qui contient le rapport basique complété par le détail des points de conformité et des échecs, page par page.
  • Enfin le rapport en profondeur correspond au rapport détaillé complété par une partie destinée aux décideurs. 🙂

Elle fait le rapprochement avec le rapport selon Accessiweb où on retrouve un peu le même esprit mais formulé autrement : on un rapport décideur non technique et pédagogique, accompagné par une (imposante) annexe technique qui détaille page par page les erreurs et les suggestions d’amélioration.

Indicateurs de l’accessibilité

Parmi les informations qu’on peut trouver dans un rapport et particulièrement la partie à destination des décideurs, ce sont des chiffres.
Selon Armony, oui, il faut des chiffres, il faut des notes, il faut un score.

Sur le plan quantitatif, on compte notamment le nombre de points en conformité à l’échelle du site ainsi que page par page. Mais il faut aussi pouvoir donner la quantité de travail et le coût pour prendre en charge les corrections.

Mais il ne faut pas s’arrêter à ces indicateurs. Car un site qui répond à 80% des critères ne sera pas nécessairement accessible à 80%. Elle donne d’ailleurs un exemple imparable : un site peut répondre à 90% des critères, s’il y a un captcha dans son formulaire de connexion, il sera potentiellement totalement inaccessible.

Il convient donc de mesurer aussi des indicateurs qualitatifs. Ça peut être le niveau à atteindre (A, AA, AAA) ou une liste de points bloquants identifiés. Généralement, il s’agira « d’inventer » les indicateurs en fonction des objectifs du projet et des contenus ou fonctionnalités jugées critiques pour l’utilisation du site ou du service.

Les méthodes d’évaluation et les indicateurs c’est bien joli, mais ce n’est pas évident à appliquer dans tous les projets. Et surtout, les méthodes d’évaluation s’appliquent forcément sur un site existant, c’est à dire après le projet de création ou refonte. Pour une meilleure prise en compte de l’accessibilité, il faut s’y prendre plus en amont.

Les méthodes opérationnelles

Fort de ce constat, différentes méthodologies ont été développées – ou sont en cours de développement – afin de prendre en compte l’accessibilité dès le départ. On y trouve notamment 3 initiatives françaises :

  • MIPAW est proposé par BrailleNet (lien externe) et Qelios. Sur la base du référentiel Accessiweb, une priorisation des critères a été faite en fonction de leur importance. Leur importance a été définie selon 4 niveaux :
    1. Sécuriser l’accès à l’information.
    2. Garantir l’accès l’information.
    3. Améliorer l’impact utilisateur.
    4. Améliorer l’expérience.
  • Accessibility Steps est proposé par Temesis (lien externe). Basé sur Opquast Reporting (lien externe), cette méthode permet d’évaluer facilement tous les critères qui peuvent être testés de manière automatisée. On y trouve 3 niveaux :
    1. First step permet de vérifier ce qui constitue une erreur d’accessibilité immédiate.
    2. Second step permet de vérifier ce qui crée un risque d’accessibilité.
    3. Third step permet de vérifier ce qui améliore l’accessibilité à travers les alternatives et contenus eux-mêmes.
  • AcceDe Web est proposé par Atalan (lien externe). Le projet vise à répartir la prise en charge de l’accessibilité en fonction du profil métier. Ils ont ainsi créé différentes notices par métier :
    1. Notice d’accessibilité pour la conception graphique.
    2. Notice d’accessibilité HTML/CSS.
    3. Notice d’accessibilité interfaces riches et Javascript.
    4. Notice d’accessibilité éditoriale.

Mise en pratique de l’accessibilité au sein d’un projet

Passée cette présentation exhaustive des outils et méthodologies à notre disposition, Armony présente des exemples concrets de projets web sur lesquels elle est intervenue.

Elle commence par un projet du groupe La Poste consistant à améliorer l’accessibilité d’un ensemble d’applications intranet pour la plupart. Le projet s’est déroulé en 4 temps :

  1. Audit des applications. Dans un environnement Intranet et utilisées avec Internet Explorer 6 essentiellement, il s’agit d’un environnement maîtrisé et l’échantillon audité comportait 3 pages seulement.
  2. Mise en place d’indicateurs selon 3 niveaux de priorité, permettant de faire le plus urgent en premier :
    1. Rendre accessible : actions faciles à mettre en place et indispensables.
    2. Trouver une solution alternative : actions indispensables mais difficiles à mettre en place.
    3. Plus tard : actions peu urgentes, fonctionnalités gadget…
  3. Sensibilisation des agents.
  4. Formations ciblées par profil.

En second exemple, elle présente le cas de Provaltis dont l’objectif était de valoriser sa démarche de labellisation argent (AA). Des formations des salariés ont été mises en place pour les sensibiliser et internaliser les compétences. S’en est suivi un audit réalisé en interne puis une mise en conformité du site et l’obtention finale de la labellisation du site.

Elle présentera 2 autres projets avec des objectifs différents et les réponses apportées à chaque fois.

Conclusion

Les leçons à retirer de ces exemples est que tout est une question de contexte. Il convient donc de bien définir les objectifs du projet pour apporter les réponses appropriées.
De plus, la formation et/ou la sensibilisation apparaît comme l’une des pierres angulaires d’un projet réussi.

Qu’importe les choix effectués dans le projet, il faut aussi prendre les différentes méthodes présentées pour ce qu’elles sont : des outils, à utiliser ou pas suivant le contexte. Et il faut surtout ne pas oublier que l’objectif de base est de rendre accessible à tous les utilisateurs !

Vous pouvez trouver la présentation d’Armony sur Slideshare (lien externe).