{"partition": "head_middle", "source_domain": "openweb.eu.org", "digest": "sha1:5MN5ZXWNNPCTLZSOIRDESEKO5F4XMQ7U", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00047.parquet"}
Voir ailleurs
See this site in English
Décideur
Gourou
Industrialisation
Mise en page
Méthodes
Pages dynamiques
Accessibilité du Web : les pièges les plus fréquents
Openweb.eu.org > Articles > Accessibilité du Web : les pièges les plus fréquents
L’accessibilité ne constitue pas un simple maillon supplémentaire que l’on peut ajouter à la chaîne de production Web. Elle doit plutôt s’intégrer à chacun des maillons de cette chaîne. La seule façon de relever avec succès le défi de l’accessibilité est de répartir la responsabilité et de partager les tâches pour produire un contenu accessible.
Bousculer les habitudes
Les standards en matière d’accessibilité pour les personnes handicapées et les populations vieillissantes bouleversent de nombreuses habitudes au sein des organisations qui entreprennent de les instaurer dans leurs pratiques de développement Web. Les exigences de ces standards remettent en question des pratiques souvent jugées jusque-là adéquates, éprouvées et optimales. La volonté d’intégrer ces nouvelles préoccupations de qualité au sein d’une équipe de production entraîne des changements soudains qui sont susceptibles de déstabiliser la rentabilité d’une production de site Web.
Bien que les principes appliqués dans la pratique d’accessibilité ne soient pas difficiles à mettre en œuvre, grands sont les risques de tomber dans certains pièges. Cet article vise à identifier ceux dans lesquels les organisations sont les plus susceptibles de tomber. Cette liste n’est certes pas exhaustive, mais pour le bien de cet article, nous avons retenu uniquement ceux qui sont les plus fréquemment identifiés dans notre pratique.
Intimement liés les uns aux autres, ces pièges entraînent souvent une cascade de conséquences déplorables pour le potentiel d’accessibilité des projets Web. En voici la liste :
Considérer l’accessibilité comme une étape de fin de parcours et ignorer le caractère transversal de la pratique d’accessibilité
Attribuer la responsabilité de l’accessibilité aux seuls intégrateurs Web
Limiter la validation de l’accessibilité aux seules exigences décrites dans les standards
Confondre les notions de conformité au standard d’accessibilité et de mise en accessibilité
Présumer que les outils de validation feront tout le travail
Sous-estimer l’impact des plateformes technologiques
Pour chaque piège identifié, nous tenterons d’analyser la nature et la cause du problème. Nous présenterons ensuite divers conseils pour rapidement intégrer des mécanismes de prévention qui favoriseront leur évitement.
Quelques pièges fréquentsConsidérer l’accessibilité comme une étape de fin de parcours et ignorer le caractère transversal de la pratique d’accessibilité
Le premier piège dans lequel tombent plusieurs gestionnaires et chargés de projet, lors de la planification des différentes étapes d’un projet Web, consiste à percevoir l’accessibilité comme un maillon supplémentaire qui s’ajoute en fin de parcours à la chaîne de production Web.
Dans cette perspective erronée, l’accessibilité apparaît comme une grille de validation supplémentaire à prévoir au moment de la phase de contrôle de la qualité du projet, tout juste avant la mise en ligne du résultat. La notion de grille de contrôle qui accompagne les standards d’accessibilité n’est certes pas étrangère à cette perception.
Dans le cas d’une mise en accessibilité en fin de parcours, les experts en accessibilité observent trop souvent que certaines décisions ont miné le potentiel d’accessibilité du projet. À titre d’exemple, mentionnons les situations suivantes :
des systèmes de navigation sur un site Web qui sont entièrement dépendants de la souris, et donc inutilisables pour quiconque navigue avec le clavier ;
des choix de technologies naturellement incompatibles avec les technologies d’adaptation informatiques ou exploitées de manière incompatibles avec celles-ci ;
des contenus mis en ligne dans des formats téléchargeables plutôt qu’en format HTML et qui s’avèrent impossibles à interpréter par les lecteurs d’écran ;
des textes de remplacement aux contenus non textuels qui n’ont pas été prévus par les développeurs alors que le rédacteur, ou même l’organisation, était disposé à les prévoir et y consacrer les efforts nécessaires ;
des maquettes graphiques aux contrastes de couleurs insuffisants, alors que cette signature visuelle est déjà placardée partout dans la ville et sur le Web.
En conséquence, l’organisation se retrouve souvent devant le constat qu’il est trop tard pour bien faire les choses. Soit parce que les budgets ou les échéanciers ne permettent plus de faire marche arrière, soit parce que les choix technologiques limitent la capacité d’une équipe à produire des contenus accessibles. Or, le simple fait de se poser les bonnes questions au bon moment permet d’éviter les échecs dans la très grande majorité des cas.
Contrairement aux dimensions « traditionnelles » du Web, telles que le design, l’analyse, l’ergonomie, l’utilisabilité, la rédaction, l’intégration et même la programmation, l’accessibilité ne s’inscrit pas comme une étape distincte et supplémentaire. Elle se répartit dans chacun des maillons d’une chaîne de production Web de manière à prévoir chaque intervention au moment opportun. Il s’agit d’une intégration transversale.
Certains choix faits en début et en milieu de parcours facilitent la mise en place de l’accessibilité ou, au contraire, génèrent des barrières. L’intégration transversale de l’accessibilité permet d’éviter des oublis importants, en particulier lors de choix techniques ou stratégiques. Ces oublis peuvent occasionner des délais et de coûteux efforts supplémentaires pour corriger la situation, lorsque des cor