Commençons par déblayer le terrain
Améliorer en continu l'accessibilité d'un projet, répondre à une obligation réglementaire ou encore tenter une labellisation vous conduit fréquemment à rencontrer un obstacle bien particulier. Une série de contenus spécifiques ressort brutalement lors de l'évaluation des erreurs à corriger : ce sont tous ces contenus que vous intégrez immédiatement sans les produire (régies publicitaires) ou qui relèvent de services tiers avec code HTML-CSS clé en main (météo, cours de la bourse) ou encore de solutions externes (captchas).
A l'usage, ce sont des cas d'échecs en accessibilité très fréquents. Les raisons de l'échec sont le plus souvent complètement triviales : il suffirait par exemple d'ajuster le code d'un simple iframe, d'ajouter une mention de changement de langue ou une alternative textuelle par défaut, ou encore de remédier à une erreur classique d'accessibilité clavier… Bref, la technique est triviale, le souci n'est pas technique, loin de là.
Le souci est que ce n'est en fait pas si évident quand il faut qu'un prestataire tiers ou un service dont on est client prenne en compte une démarche d'accessibilité. Il n'est pas non plus si évident d'anticiper après coup, si on peut dire, le choix du service en question en fonction de sa prise en compte de l'accessibilité. Il peut être difficile, voire impossible, de chercher d'autres services ou d'autres prestataires. Ces difficultés évidentes sont bien-sûr connues. Mais ce n'est pas ce qui nous occupe ici.
Notre souci, dans l'élaboration de la démarche accessibilité du projet (ou dans l'assistance que nous apportons), est d'éviter un autre écueil plus immédiat à la suite de l'audit : celui du choix de la dérogation et d'un mauvais calcul du bénéfice qualité.
À présent, revenons aux bases
Le RGAA prévoit un régime de dérogation pour les "contenus tierce partie" :
- un "contenu tierce partie" apparaît lorsque "le propriétaire du service de communication publique n’est pas l’auteur des contenus et ne peut donc pas avoir la garantie qu’il est et reste accessible en permanence."
- dans ce cas, "le responsable du service de communication publique en ligne peut être dans l’incapacité de mettre en oeuvre tout ou partie du RGAA. Il est alors nécessaire de définir les choix et priorités de mise en œuvre et de les consigner dans un document de politique d’accessibilité." Il peut alors "déroger au principe d’accessibilité total du site".
La cause peut donc sembler immédiatement entendue, d'un point de vue "décideur": pour tout contenu tiers, LA bonne décision lors d'une mise en conformité RGAA serait de déroger, puisque le cas est prévu.
C'est irréprochable. Mais ce sera un bien mauvais calcul, s'il est aussi hâtif et massif.
A ce stade de la prise en compte de l'accessibilité dans un projet Web, il faut en effet prendre du recul et se souvenir que le respect formel du RGAA doit être géré dans une démarche qualité globale.
Si notre décideur confronté à cette tentation de la dérogation par défaut pour cause de contenu tierce partie prend ce recul, il lui devient alors évident, par exemple (la liste est extensible) :
- que chaque correction obtenue sur chaque service tiers sera une plus-value réelle pour l'expérience utilisateur au sens le plus large. Une alternative textuelle corrigée est une meilleure indexation des contenus. Un gain d'accessibilité clavier profite au confort d'un large public, etc.
- que chacune de ces améliorations négociée avec un service tiers s'accompagnera d'une meilleure maîtrise des solutions tierces en interne, d'une montée en compétence et d'une gouvernance plus précise.
Pour conclure au moins provisoirement
Bref, et nous en avions conclu là lors de cette mission : face à des services tiers à l'accessibilité améliorable, ne dérogez qu'en dernier ressort et ne négligez pas les occasions de détecter et de corriger des défauts plus larges de qualité interne et externe. C'est l'amélioration de l'écosystème et sa maturation d'ensemble qui aura finalement le plus de valeur ajoutée pour chacun.
1 De Elie - 31/01/2013, 14:05
Tout à fait d'accord avec le contenu de votre article. Pour compléter avec une vision de qualiticien, dans un système de certification qualité bien fichu et digne de ce nom (!), la dérogation est par nature une action de dernier ressort. Une dérogation doit être non seulement justifiée, mais acceptée par un tiers. Dans le cas du RGAA, il n'y a pas d'entité capable de dire si les raisons d'une dérogations sont justifiées. Si c'était le cas, cela permettrait de lister proprement un maximum de justifications valables et non valables. J'espère que certains systèmes le feront. Pour l'instant, c'est sans doute un peu lourd pour notre secteur, mais bon, nous verrons de quoi l'avenir sera fait.
2 De Laurent Denis - 31/01/2013, 16:35
L'idée de cet article est à vrai dire que la dérogation est une décision de dernier ressort dans tous les cas. C'est à dire aussi bien dans un système flou ou ouvert caractérisé par l'absence de tiers de confiance et de processus de certification, comme actuellement. Parce que c'est avant tout l'intérêt des projets concernés. Mais ce serait certes plus évident dans le cas que tu décris, entre-autres bénéfices qu'il apporterait.
3 De Nico - 31/01/2013, 21:26
Il m'arrive, quand c'est possible bien sûr, de carrément nettoyer le code d'un service tiers, et de leur re-soumettre au service en question. Là où c'est malheureux, c'est quand ce sont des erreurs extrêmement basiques, même un inté débutant serait capable de le gérer. Par contre, des fois j'ai de bonnes surprises, je me souviens d'un service de transports qui a été enchanté de l'initiative.
J'ai l'impression que la culture front a du mal à rentrer dans certains services, dommage.
4 De Olivier Nourry (@OlivierNourry) - 04/02/2013, 10:23
Salut les amis,
Je suis bien évidemment tout-à-fait d'accord avec votre message de fond: ne dérogeons que si c'est tout ce qu'il reste à faire. C'est ce que nous devons à l'utilisateur, et c'est ce qu'il faut rendre appétissant pour nos clients.
Si votre article pose de façon claire le dilemme et apporte une réponse satisfaisante, je me permets d'y apporter un complément d'information, qui j'espère éclairera vos lecteurs sur la difficulté de certains choix. Et sur certaines des raisons qui font que, même profondément attaché aux besoins des internautes, on est parfois amené à céder et reculer.
Je vois au moins trois autres raisons pour lesquelles on sera susceptible de déroger, si l'on veut trouver la juste balance entre la satisfaction des utilisateurs, et les contraintes d'un projet. Et pour finir sur une note positive, une quatrième raison pour laquelle on sera heureux de déroger (si si).
La première raison: l'argument juridique. Par nature, certains contenus (tiers mais pas seulement) ne sont pas "accessibilisables" car ils ne sont disponibles que sous une forme non accessible, et protégés par une clause juridique, commerciale ou contractuelle. C'est par exemple le cas de rapports financiers de sociétés cotées, de paroles de chansons protégées par le droit d'auteur, ou de tout type de document pour lesquelles une copie modifiée (comme une transcription, une version HTML ou des sous-titres) ne peut être fournie sans l'accord des ayant-droits. C'est triste, mais le droit français, pour le moment, ne nous permet pas de contourner ce type de barrière pour l'accessibilité. On peut en débattre des heures; toujours est-il qu'en pratique nous ne forçons jamais un client à se mettre en danger sur ce terrain-là.
La seconde, qui y ressemble, mais juste un peu: l'éventuelle infraction aux conditions d'utilisation. Si on altère ne serait-ce qu'une couleur ou un alt d'image, reste-t-on dans les conditions d'utilisation du service? Et préserve-t-on, notamment, l'obligation de maintien de service ou de support qui y est associée? A vérifier avant toute manipulation intempestive.
La troisième, cette fois liée à une problématique projet: on n'a aucune espèce de garantie, en général, qu'un service tiers restera compatible avec les évolutions qu'on y a apportées pour ses propres besoins. Prenons l'exemple d'une interface personnalisée pour un lecteur youtube: qui dit qu'elle continuera à fonctionner à la prochaine version majeure du lecteur? De fait il y a une décision projet à prendre, et elle n'est pas forcément anodine.
Enfin, et ça c'est le coté positif: certains services vont s'avérer en avance sur le référentiel, notamment ceux développés en HTML5. Ils pourront tout-à-fait être accessibles, mais pas au sens où l'entend le RGAA, qui n'a pas encore intégré cette éventualité. Du coup, la possibilité de déroger permet de s'affranchir de ce frein, pour le plus grand bien des utilisateurs (et merci Elie pour m'avoir fait prendre conscience de ceci, à une certaine présentation commune ;)...).
5 De JPV - 04/02/2013, 11:17
Elie écrit :
"Dans le cas du RGAA, il n'y a pas d'entité capable de dire si les raisons d'une dérogations sont justifiées. Si c'était le cas, cela permettrait de lister proprement un maximum de justifications valables et non valables. J'espère que certains systèmes le feront."
Juste pour préciser que la certification AccessiWeb implémente un système de ce type via le process de déclaration de conformité partielle dont chaque cas, déclaré préalablement à l'inspection, est "instruit" par BrailleNet. A l'usage on s'aperçoit que les dérogations si elles sont régulièrement demandées le sont majoritairement pour de bonnes raisons et que le rejet par BrailleNet est assez exceptionnel.
Quant à lister les cas de dérogations possibles, en dehors des définitions données par WCAG et adaptée par RGAA et AccessiWeb cela me parait difficile car éminemment contextuel.
Je me joint également à une des remarques d'Olivier sur la pérénité des adaptations effectuée sur un service fournis par un tiers : il est quasiment impossible de s'assurer de la pérénité d'une adaptation demandé ou fournie lors d'un versionnage.
Du coup la prise de risque est importante pour le commanditaire qui peut se retrouver avec une partie du job anéantis en quelques secondes. C'est un peu la même chose sur les surcouches applicatives pour certains CMS qui ne survivent pas à une mise à jour.
Cela ne retire rien à l'article qui, sur le fond, est juste, mais sur le terrain le choix est assez vite fait : on déroge et on se concentre sur ce qu'il est possible de faire et de contrôler en interne.
6 De Laurent Denis - 05/02/2013, 11:14
Le rappel explicite des obligations juridiques est très bien vu, cela manquait en effet dans ce billet assez rapide où c'était sous-entendu. Merci :-)