“Inclusivité et bienveillance”, “Care”, “Best in class for inclusivity”, “Openness is our motto”, “Diversité et inclusion”, “Célébrons nos différences”: tous ces slogans restent lettres mortes s’ils ne sont pas suivi d’effet.
Pour conduire à bien un projet d’accessibilité numérique, il faut être ferme et clair sur les objectifs de l’organisation que vous servez, au risque de beaucoup travailler pour ne pas beaucoup livrer.
Balayons rapidement les raisons qui vous amènent à vous lancer dans un projet d’accessibilité.
Conformité vs Inclusion
La volonté de se conformer à la législation ou tout au moins d’atteindre un standard clair est souvent la première impulsion vers l’accessibilité.
L’autre raison est une volonté d’aller plus loin et de penser ses services ou ses produits pour le plus grand nombre.
Conformité aux standards
La conformité est la contrainte normative qui s’impose de manière plus ou moins forte. Elle ne s’oppose pas à une démarche inclusive mais est souvent le préalable à celle-ci.
L’objectif le plus partagé est celui qui consiste à couvrir les obligations légales issues de la directive européenne de 2016 et sa transposition ou celles induites par la loi de 2005 pour les institutions publiques.
Les entreprises cherchent souvent à être conformes à un standard. Les deux plus courants sont le WCAG (2.2 dans sa dernière version) qui est publié par le groupe de travail WAI (Web Access Initiative) lequel est une émanation du W3C (World Wide Web Consortium) et le RGAA (4.1.2 dans sa dernière version) qui est publié par la DINUM (Direction interministérielle du numérique) .
Si dans leur esprit, ces deux standards sont proches, un choix doit s’imposer pour clarifier la direction du projet.
RGAA 4.1.2
→ Référentiel général d’amélioration de l’accessibilité (RGAA)
Le règlement général d’accessibilité des administrations est le standard des organismes publics. Il a pour lui d’être très contextualisé par rapport aux normes du service public.
Avantages
- Conformité et continuité dans l’accessibilité avec les sites et applications publics,
- Propose plus de critères que le WCAG 2.2, notamment pour l’accessibilité des documents,
- Exigences des tests : ils doivent être conduits avec et sans technologie d’assistance.
Inconvénients
- Pas international,
- Binaire : conforme ou non conforme.
WCAG 2.2
→ Web Content Accessibility Guidelines (WCAG) 2.2
C’est le standard international édicté par le WAI (Web Accessibility Initiative) qui se regroupe en 5 chapitres principaux:
- Critères “perceptibles”,
- Critères “opérables”,
- Critères “compréhensibles”,
- Critères de “robustesse”,
- Critères de “conformité”.
Avantages
- Standard international,
- Critères plus progressifs (par niveaux).
Inconvénients
- Moins exigeant,
- Moins de discernement dans les cas d’application (la distinction entre l’intégration pour sites, applications ou documents se fait au niveau des techniques d’implémentation).
Opquast
→ Checklist Opquast – assurance qualité web
Avantages
- Une approche différente et plus large de la qualité web (prise en compte de fonctionnalités et de contenus spécifiques : modération, cgv …),
- Organisme formateur.
Inconvénients
- Un référentiel moins visible des acteurs légaux,
- Un référentiel qui ne se spécialise pas dans l’accessibilité.
Les limites des standards
La principale critique que l’on peut faire à l’encontre des standards est que leur application ne garantit pas l’accessibilité.
Un premier biais est dû à l’effort d’interprétation des solutions pour atteindre la conformité aux standards. Prenons l’exemple des contrastes. Le WCAG 2.2 stipule que pour atteindre le niveau AA, il faut au minimum respecter des contrastes de 4,5:1 entre, par exemple, un fond de couleur et un texte. Mais si, pour des contraintes de branding, vous prenez le parti-pris d’afficher des illustrations dans votre fond et que celles-ci contrastent mal avec le texte, il vous sera difficile de garantir que dans aucune des résolutions d’écran de vos utilisateurs cette illustration ne se trouvera derrière le texte et impactera négativement le contraste.
Un deuxième biais des standards est qu’ils s’adressent de façon générale aux personnes en situation de handicap. En mettant en œuvre ces standards, on favorise la lecture avec des technologies d’assistance (lecteur JAWS, VoiceOver, etc.), mais chaque cas peut requérir une solution différente selon que l’outil est une aide pour les aveugles ou pour les personnes qui sont atteintes d’une dyspraxie.
Pour cette raison, outre des technologies d’assistance, de nombreuses solutions logicielles qui agissent comme des “surcouches” des navigateurs (widgets) permettent aux utilisateurs de configurer la présentation des informations de manière plus fine en fonction de leur handicap : Facil’iti, Equalweb, Userway, etc. Nous verrons plus loin que ces outils ne vous exonèrent pas de rendre votre code plus accessible.
Enfin, un standard n’a pas de contenu sémantique. Il requière que dans les applications numériques la langue employée soit la plus simple et claire possible, mais il ne dit rien des marqueurs sémantiques dans le code : depuis les labels des liens qui reprennent des enchaînements de séquences de lecture jusqu’au titre des boutons et à l’importance des taxonomies dans l’organisation. Selon le contexte et l’enchaînement des séquences, on choisit des labels différents, et on peut donc remplir certains critères standards sans que cet enchaînement n’ait de sens (ou très peu, on a tous déjà cliqué sur un “en savoir plus” sans comprendre quelle information on trouvera derrière ce label vague).
L’inclusion
La volonté d’inclusion est une démarche plus profonde avec l’idée que chaque individu est une ressource pour notre société. L’opposé serait une société sélective qui ne verrait de bénéfice qu’à privilégier les éléments les plus “aptes” de notre société, tout en passant à côté des qualités de tout ce qui la compose.
Dans une démarche sincère d’inclusion, l’accessibilité est un outil de productivité pour tous et nous soulage quand nous en avons le plus besoin.
Dans une démarche inclusive, pousser les projets d’accessibilité jusqu’aux tests utilisateurs réalisés par des personnes en situation de handicap est une garantie de résultat plus forte.
Ces tests sont souvent réalisés sous la forme de tests d’utilisabilité qui détectent des cas utilisateurs auxquels ni les designers, ni les intégrateurs, ni les standards n’ont pensé et de gommer la plupart des angles morts.
L’efficacité numérique
L’accessibilité a tout intérêt à s’inscrire dans une démarche d’efficacité numérique globale. Avec un ensemble de bonnes pratiques, elle contribue à faire des sites et des applications plus robustes et plus faciles à utiliser.
Développement Front end
La première chose à retenir, c’est qu’une bonne pratique du code “front end” (codage d’interface, par différence d’un codage d’algorithme par exemple) inspirée par une bonne connaissance des standards d’intégration est une première étape nécessaire pour l’accessibilité. Par exemple, il faut que vos sites web soient maintenus par des développeurs qui maîtrisent HTML et CSS tout en respectant les normes W3C (normes de base de l’HTML). Certains critères du WCAG reprennent des standards de l’intégration HTML (exemple, selon WCAG 2, des éléments <li> doivent être inclus dans des éléments <ul> ou <ol>) et c’est un préalable à la conformité.
Utilisabilité
On pourrait parler d’une utilisabilité “étendue” pour l’accessibilité. Les exigences de la démarche sont telles, qu’une fois arrivé au bout, il y aura moins de sujets à traiter dans l’utilisabilité d’interface. Il reste alors de grandes questions liées à l’utilisabilité et l’UX design en général mais qui s’inscrivent dans une perspective globale de l’application ou du site que vous concevez et qui normalement ont été traitées dans une réflexion en amont sur votre stratégie.
Les considérations d’accessibilité peuvent être complétées par une démarche d’UX design globale : exploration des besoins, architecture de l’information, prototypage, test et amélioration continue.
Robustesse
L’accessibilité d’une application ou d’un site web lui fait gagner en robustesse dans la mesure où celle-ci générera moins d’erreurs à l’usage, évoluera plus facilement grâce à des jeux d’interfaces simples et faciles à déployer, et offrira un plus grand niveau de compatibilité avec les différents clients (navigateurs) ou appareils de consultation.
En résumé
- Il faut évaluer en début de projet quel est le degré de motivation en fonction de votre objectif (Compliance vs Inclusion).
- Vous devez choisir le standard à appliquer selon votre entreprise/organisme pour lequel vous travaillez et le type d’application que vous développez.
- Si vous souhaitez aller plus loin, pensez aux tests d’utilisabilité en impliquant vos futurs utilisateurs.
- La démarche d’accessibilité est bénéfique pour l’ensemble des performances du système (technique et design).