Notre guide de contribution indique :

La priorité reste l'ergonomie, l'accessibilité et l'efficacité, en utilisant toujours des formats libres. Cela est valable tout autant pour les outils liés au mmorpg qu'au site web. La philosophie appliquée est celle d'Unix, et en particulier “Ne faire qu'une seule chose, et la faire bien”.

Renchéri dans la page dédiée à l'amélioration du site web :

Nous sommes conscients des problèmes que peuvent rencontrer certains utilisateurs dans leur navigation sur internet. Nous souhaitons que l'ensemble de nos services soit accessible, quelque soit le handicap physique ou technique de nos utilisateurs.

Un but de ce document est de donner une vue générale sur l'accessibilité dans le domaine du numérique. Cet ensemble est bien sûr loin d'être exhaustif mais il faut bien commencer par quelque chose… Un autre but est de faire le point sur l'accessibilité chez Khaganat et donner des pistes d'amélioration.

Autres liens internes relatifs à l'accessibilité :

• Dans les valeurs éthiques accompagnant le cahier des charges du MMORPG
• Dans le Yakalfr

: la rédaction est en cours

Commençons par le Larousse :

Droit, possibilité qu'a quelqu'un d'avoir accès à quelque chose

L’accessibilité est un terme bien souvent évoqué initialement relativement au monde du handicap, mais aussi des enfants ou des personnes âgées, puis étendu depuis à l'ensemble des citoyens partant du constat que dans de nombreux domaines, l'accessibilité n'est pas identique pour toutes.

L'article 9 de la Convention relative aux droits des personnes handicapées évoque l'accessibilité pour les personnes en situation de handicap en ces termes :

Afin de permettre aux personnes handicapées de vivre de façon indépendante et de participer pleinement à tous les aspects de la vie, les États Parties prennent des mesures appropriées pour leur assurer, sur la base de l'égalité avec les autres, l'accès à l'environnement physique, aux transports, à l'information et à la communication, y compris aux systèmes et technologies de l'information et de la communication, et aux autres équipements et services ouverts ou fournis au public, tant dans les zones urbaines que rurales.

L'introduction au Référentiel général d'accessibilité pour les administrations (RGAA) indique aussi sur le handicap :

Bien qu'il soit difficile de chiffrer précisément le nombre de personnes en situation de handicap, une enquête de l'INSEE1 estime qu'elles représenteraient entre 10 et 20 % de la population. Ce qui semble confirmé par le rapport mondial sur le handicap publié par l'OMS en 2010 et qui recense environ 15 % de la population mondiale ayant un handicap.

Hors du cadre de la CDPH, l'accessibilité revient donc, dans un domaine donné (et pour tous les domaines de la vie) a donner le même niveau d'accès pour tous. On rappelle à ce titre la Déclaration universelle des droits de l’homme de 1948 avec son Article 19 :

Tout individu a droit à la liberté d’opinion et d’expression, ce qui implique le droit de ne pas être inquiété pour ses opinions et celui de chercher, de recevoir et de répandre, sans considérations de frontières, les informations et les idées par quelque moyen d’expression que ce soit.

Pour relier enfin accessibilité et liberté d'expression.

Dans le cas de Khaganat, bien que l'on puisse penser accessibilité des lieux lors de nos quelques rassemblements (et hors de question de l'oublier !), il s'agira surtout ici de se concentrer sur le cadre principal de notre activité, c'est-à-dire côté numérique.

Traduit de l'anglais dans cette même introduction au RGAA évoquée plus haut, la WAI (Web Accessibility Initiative) définit l'accessibilité numérique comme suit :

L'accessibilité du Web signifie que les personnes en situation de handicap peuvent utiliser le Web. Plus précisément, qu'elles peuvent percevoir, comprendre, naviguer et interagir avec le Web, et qu'elles peuvent contribuer sur le Web. L'accessibilité du Web bénéficie aussi à d'autres, notamment les personnes âgées dont les capacités changent avec l'âge.

L'accessibilité du Web comprend tous les handicaps qui affectent l'accès au Web, ce qui inclut les handicaps visuels, auditifs, physiques, de parole, cognitifs et neurologiques.

En faisant le lien avec le mouvement du Libre au sens large, cette définition colle parfaitement et semble un prérequis à la première liberté (ou liberté 0) :

la liberté de faire fonctionner le programme comme vous voulez, pour n'importe quel usage

Néanmoins, c'est bien souvent l'inverse (si ce n'est presque systématiquement) que l'on constate, autant coté logiciel libre que propriétaire : l'accessibilité n'est pas considérée comme un fondement indissociable mais comme un ajout coûteux aisément éjectable.

Enfin accessibilité et ergonomie vont de pair mais sont bien des domaines séparés, le respect d'un niveau donné de conformité à un référentiel d'accessibilité ne garantit pas une bonne ergonomie pour les personnes en situation de handicap (et attention à ne pas confondre ergonomie et intuitivité !). Même chose pour l'utilisabilité (selon la norme ISO 9241-11 : “le degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte d’utilisation spécifié”), étant elle-même une dimension de l'ergonomie.

L'accessibilité se traduit le plus souvent à travers des référentiels faisant office de base légale selon le pays concerné au moins pour les structures publiques, ce n'est néanmoins pas systématiquement le cas. Il faut néanmoins retenir une chose : un site web peut obtenir la note de conformité maximum à un référentiel d'accessibilité donné et être parfaitement inutilisable.

Le focus est fait ici sur le WEB car c'est notre principal domaine d'action, moyen de travailler ensemble et point d'accueil et rassemblement des acteurs du projet.

Sans entrer dans les détails légaux, en termes d'obligation tous les services de communication publique en ligne de l'État, des collectivités territoriales et des établissements publics devraient respecter légalement un niveau double A (AA) du Référentiel général d'accessibilité pour les administrations (RGAA). Cela depuis la 1ère version publiée en 2009 (prévu par la loi française n°2005-102 du 11 février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées). Un délai de 18 mois est accordé pour se conformer à chaque nouvelle version du RGAA majeure du RGAA, la dernière étant la version 4.1, publiée le 16 février 2021 (version majeure 4 arrêtée le 20 septembre 2019).

Cette obligation, sans contrainte jusqu'alors, est assez peu respectée.

L'adoption récente de la directive UE 2016/2102 relative à l'accessibilité des sites internet et des applications mobiles des organismes du secteur public vient appuyer cette obligation déjà présente depuis 2005, la version 4.1 du RGAA a été élaborée pour se conformer à cette directive et au décret (décret n° 2019-768 du 24 juillet 2019) le transposant au sein du droit français. La directive étend son influence (infographie résumé de Koena sous CC-BY-SA 4.0) :

• Toute entreprise ayant un chiffre d'affaires supérieur ou égal à 250 millions d'euros) mais les conséquences du non respect sont néanmoins dérisoires : initialement 25000€ d'amende par an prévu diminué à 20000€ par un décret de juillet 2019…
• Personnes morales de droit public sauf médias audiovisuels
• Personnes morales de droit privé avec Délégation Service Public
• Personnes morales de droit privé à but non lucratif avec mission d'intérêt général + Services essentiels au public et/ou service pour personnes handicapées

Le RGAA se base lui-même sur un autre référentiel : le Web Content Accessibility Guidelines (WCAG) issu de l'initiative Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C). Il fait office de consensus technique sur l'accessibilité des contenus web aux personnes handicapées et a été transposé en tant que norme ISO depuis 2012. Le RGAA se base sur la version 2.1 traduit officiellement par l'association BrailleNet.

La nouvelle version du RGAA, la 4ème donc, semble, vis-à-vis des observateurs et défenseurs des personnes en situation de handicap, s'appauvrir (voir fil Touiteur d'Armony ALTINIER et l'article du blog de Koena) : là où bien qu'il y ait une obligation de conformité au niveau AA, la version 3 donnait à voir le niveau AAA permettant d'indiquer l'évolution possible et les manques tandis que la version 4 retire ces éléments, on peut citer par exemple la présence de Langue des Signes Française (LSF) dans les vidéos ou la présence de documents Facile A Lire et à Comprendre (FALC). Au lieu de tendre vers le mieux, la tendance semble se diriger vers l'application du minimum.

En bref :

• généralement aucune obligation légale existe vous imposant une conformité à un référentiel d'accessibilité en France et en Europe à moins de se trouver dans les cas indiqués (pas nous chez Khaganat en résumé)
• le référentiel pour lequel il existe une obligation légale en France pour certains organismes est le RGAA, il se base lui-même sur un référentiel international avec lequel il est indirectement compatible mais aujourd'hui incomplet. En fin de compte, le RGAA est très franco-français et se baser dessus représente peu d'intérêt par rapport aux référentiels internationaux.

Néanmoins, on explore ici qu'une facette du problème : le WCAG est l'une des initiative du WAI dans le cadre de l'accessibilité et bien que ce soit celle qui nous concerne le plus, on peut également évoquer les autres.

Là où le WCAG se concentre sur le contenu lui même, l'Authoring Tool Accessibility Guidelines (ATAG) se concentre sur les outils de production de ces contenus (authoring tools) utilisés par les développeurs, designer, auteurs, etc. On peut citer par exemple : un outil de gestion what-you-see-is-what-you-get (WYSIWYG) d'un CMS, un générateur de site statique, un outil de production de contenu multimédia, un wiki, etc. En ce sens, l'ATAG nous concerne en partie.

Enfin l'User Agent Accessibility Guidelines (UAAG) se concentre sur le “user agent”, c'est-à-dire l'outil rendant le contenu accessible : navigateur web, extensions de navigateur, media players, readers, etc. Cela nous concerne beaucoup moins dans notre production mais conseiller des outils reconnus dans ce cadre pourrait être intéressant.

Le standard européen EN301 549 V2.1.2 d'août 2018 traite non seulement l'accessibilité WEB en intégrant le WCAG mais aussi plus globalement sur tous les produits et services issus des technologies de l'information et de la communication (ICT) qui dépassent le seul WEB accessible depuis nos ordinateurs personnels pour traiter parmi bien d'autres exemples un appareil en accès libre (un distributeur de billet par exemple) tout autant que l'espace au sol nécessaire pour son accès en fauteuil roulant (section 8.3.2.2 Clear floor or ground space).

Vous l'avez compris, aucun référentiel ne s'impose à nous mais il nous est logique d'en suivre un (sans oublier que cela ne fait pas tout !). De même aucun niveau de conformité nous est imposé, il nous revient d'en choisir un ou bien de mixer un peu à notre convenance sans pour autant viser un respect total du niveau maximal si factuellement impossible à atteindre et maintenir.

Grand avantage pour un projet francophone : ZE norme internationale (sur le contenu), le WCAG, fait d'une part l'objet d'une traduction officielle en français par l'association BrailleNet et d'autre part cette même traduction est la source du RGAA. Cela nous permet de parler de la même chose avec n'importe qui dans le monde tout en ayant une ressource compréhensible dans notre langue.

Nous utiliserons de façon indifférenciée “le référentiel” ou “un référentiel” sans indiquer de référentiel précis étant donné leur compatibilité dans la suite du présent document.

Construire un programme en conformité à un référentiel demande une montée en compétence et une meilleure compréhension (très enrichissante !) des enjeux de l'accessibilité mais se réalise malgré tout assez bien une fois ces marques acquises (ne devrait-elle pas être la base de toute formation au développement ?).

En revanche, la mise en conformité de l'existant s'avère bien plus difficile et soulève de nombreux défis stratégiques, techniques et fonctionnels, étant généralement admis que si le programme n'est pas conçu pour être accessible dès le départ, le travail de mise en conformité s'apparente très probablement à une refonte de nombreux écrans.

On oubliera pas non plus le standard européen EN301 549 pour tout ce qui se situera autour et pensera à l'ATAG pour les cas spécifiques.

Un référentiel est lourd et difficilement digeste, c'est pourquoi l'on trouve des checklists ou extensions de navigateur pour faciliter l'audit et le test. Cela ne nous dispense néanmoins pas de parcourir le guide

Par exemple la checklist de la DILA ou encore l'extension de navigateur "Assistant RGAA" de la DINSIC.

A réviser avec la version 4 du RGAA (voire à éviter si mise à jour, la version 4 appauvrissant le référentiel)

Visiter le dépôt Github de la DINUM.

TODO : checklist, extensions navigateur et autres programmes tiers à ajouter

En terme de ressources, le principe de compatibilité d'un référentiel local comme le RGAA avec le WCAG permet de s'intéresser aussi à la documentation existante au niveau international et notamment la documentation administrative visant également une compatibilité avec le WCAG pour des référentiel locaux d'autres pays (le niveau de conformité étant généralement identique et la correspondance d'un critère du référentiel local à un critère WCAG étant indiquée). On trouve ainsi des ressources plus précises sur certaines points et d'une façon générale plus de ressources pratiques que le seul WCAG.

Par exemple :

• Accessibility for Teams, de l'US Government : https://accessibility.digital.gov/
• Section508.gov (Section 508 of the Rehabilitation Act of 1973 = loi accessibilité US) : https://www.section508.gov/
• Online Accessibility Toolkit, Government of South Australia : https://www.accessibility.sa.gov.au/

TODO : à compléter

Référentiel français sous forme de cheklist, pas si terrible à lire et adapter : https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/#1

Le but de cette partie est de donner quelques menus conseils permettant de changer peu à peu de point de vue au quotidien afin de prendre petit à petit en compte des éléments basiques d'accessibilité. De bonnes habitudes élaguent énormément le terrain à une vraie prise en compte de l'accessibilité

Il est couramment admis qu'une hauteur de ligne (line-height) de 1.5 permet d'obtenir une bonne lisibilité du texte.

Si l'utilisateur applique les réglages suivants, le texte doit rester lisible (pas de contenu tronqué, superposé):

• La hauteur des lignes doit pouvoir être ajustée à 1.5 fois minimum la taille de la police de caractères.
• L'espace situé entre deux paragraphes doit pouvoir être ajusté à 2 fois minimum la taille de la police de caractères.
• L'espacement entre les lettres doit pouvoir être ajusté à 0.12 fois minimum la taille de la police de caractères.
• L'espacement entre les mots doit pouvoir être ajusté à 0.16 fois minimum la taille de la police de caractères.

On peut utiliser un bookmarklet (faire un marque page comportant l'adresse suivante) pour tester cela :

  javascript:s%20=%20document.createElement(%22style%22)%3Bs.setAttribute(%22type%22%2C%22text%2Fcss%22)%3Bt%3Ddocument.createTextNode(%22*%20%7Bline-height%3A%201.5!important%3B%20letter-spacing%3A.12em!important%3B%20word-spacing%3A%20.16em%20!important%3B%7D%20p%7Bmargin-bottom%3A%202em!important%3B%20%7D%22)%3Bs.appendChild(t)%3Bh%20%3D%20document.getElementsByTagName(%22head%22)%5B0%5D%3Bh.appendChild(s)%3Bvoid(0)%3B

Le référentiel donne parfois des valeurs précises sur certains de ces éléments, parfois non. Souvent seul un niveau AAA donne des valeurs précises, ce qui peut être au final plus simple à mettre en place pour nous, par exemple le critère 10.12 [AAA] du RGAA demande une valeur d'interligne de au moins 1,5 fois la taille du texte et une valeur d'espacement entre deux paragraphes est égale à au moins 1,5 fois la valeur de l'interligne.

L'agrandissement/zoom de la page ou du texte seulement est courant en terme d'accessibilité, bien que le référentiel ne donne pas toujours de valeur exacte (il reste subjectif sur de nombreux points), il y a certains points assez communément admis. Il n'y a pas toujours une seule bonne solution subjectivement, il convient de s'inspirer des bonnes pratiques existantes comme base de suggestion.

Varier le zoom du site (CTRL + molette souris ou boutons “+” et “-”) doit pouvoir se faire en gardant les éléments lisibles malgré l'altération de la page.

La taille du texte doit pouvoir être multipliée par 2 par exemple (zoom à 200%, zoom du texte seulement à configurer dans le navigateur) tout en restant lisible.

Le design de la page peut être amené à être repensé sur ces points s'il ne le permet pas de base.

L'outil de loupe de l'OS peut également être utilisé et conditionne, comme pour les plages brailles, la largeur d'un texte ou d'une alternative textuelle par exemple.

Ici nous parlerons uniquement de lecteur d'écran sous licences libres. On peut ainsi citer NVDA (GPLv2) sous Windows et Orca sous GNU/Linux (LGPLv2.1).

Commandes clavier basiques facilitant la navigation :

• sous NVDA : https://www.nvda-fr.org/doc/keyCommands.html
• sous Orca : https://help.gnome.org/users/orca/stable/index.html.fr#quick_reference

Basiquement, et bien souvent de façon commune à tous les lecteurs d'écran, la tabulation permet de passer à l'élément suivant (shift + Tab pour l'élément précédent) et c'est par l'appui successif sur Tab que l'on aborde le parcours utilisateur dans l'écran.

Il est en effet attendu de concevoir une page permettant facilement la navigation au clavier sans imposer 20 appuis sur Tab et/ou un ordre illogique d'enchaînements pour atteindre telle ou telle partie qui serait accessible facilement à la souris.

Ainsi une page se naviguant au clavier peut comporter des éléments invisibles à l'œil mais parfaitement détectés par le lecteur d'écran pour faciliter la navigation au clavier : lien de retour à la ligne des menus, haut de page, bas de page, aller au contenu, etc. (mais c'est aussi à double tranchant : les éléments cachés ne le sont pas pour le lecteur d'écran ! Voir Inclusively Hidden by Scott O’Hara).

Il ne faut pas oublier non plus la visibilité du focus.

Quelques liens :

• http://www.infowebmaster.fr/128,news-accessibilite-web-navigation-clavier.html
• https://www.accede-web.com/notices/html-css-javascript/12-navigation-clavier/

La disponibilité et maintien sur appareil mobile d'une application n'est pas une chose aisée, d'autant plus pour une application accessible. Il faut définir une flotte type d'appareils et résolutions cibles (et probablement bien d'autres choses), tout en gardant en tête qu'il est impossible d'envisager de s'adapter à tous les appareils mobiles existants.

Chaque navigateur a une option dans sa console web pour s'adapter à une résolution donnée (avec des modèles de résolutions prédéfinis pour certains modèles d'ordiphone) mais cela ne vaut jamais un test sur un appareil réel.

Les documents édités/rendus disponibles (PDF, ODT ou EPUB par exemple) devraient également être accessibles. Il est assez simple de trouver des aides pour rendre des documents traitement de texte ou PDF accessibles, bien moins pour un tableur.

Quelques ressources :

• Guide de la DINSIC : https://disic.github.io/guides-documents_bureautiques_accessibles/html/
• Recommandation accessibilité Orange pour l'éditorial : https://a11y-guidelines.orange.com/others/index.html
• Feuilles de calcul accessibles par l'U.S. General Services Administration : https://www.section508.gov/create/spreadsheets

TODO : identifier les docs produits par Khaganat et apporter des indications générales et spécifiques. TODO : alcyone sur Dude

La question se pose de l'automatisation des critères préconisés par un référentiel donné. La plupart ne sont pas automatisables néanmoins il existe des outils qui peuvent se révéler intéressants.

La croyance qu'un bon score avec des outils automatisés rend son site/application accessible est malheureusement très répandue…Cependant on peut par exemple tester automatiquement le fait qu'il ne manque pas pour chaque image une alternative textuelle en revanche on ne peut pas automatiser l'évaluation de la pertinence de l'alternative textuelle, l'outil donnera pourtant une note maximale dans ce cas-ci (à lire par exemple avec Lighthouse, basé sur axe-core).

Ainsi, l'accessibilité reste largement…une affaire d'humains

L'automatisation est un excellent outil pour une 1ère étape, le vrai travail commence après.

“We don’t fully rely on automation when we’re designing and developing, and we shouldn't do it either when we’re testing.” - Manuel Matuzovic

Beaucoup des outils spécialisés que l'on croise en accessibilité ne sont plus maintenus. On peut néanmoins citer parmi ceux qui semblent maintenus : axe-core (dit “accessibility engine for automated Web UI testing”, sous licence MPL2.0) ou Enabler (dit “Accessibility analyzer”, sous licence MIT).

Il existe également divers plugin selon les framework utilisés en développement.

TODO : des plugins maintenus pour Django ?

Coté test fonctionnel, on peut (laborieusement) ajouter l'accessibilité aux tests automatisés d'interfaces utilisateurs.

TODO : étendre cette partie notamment sur dogtail

TODO : à remplir

Le but de cette partie est de donner une bonne introduction et compréhension globale de la structure et façon de procéder du WCAG permettant de l'utiliser plus facilement en tant que documentation au quotidien sur les thématiques de l'accessibilité.

TODO : ajouter des bookmarklets. Détailler les ressources : un texte descriptif pour guider

Pour Firefox :

• Extension Wave Accessibility pour Firefox : cliquez sur un bouton, la page est analysée et vous indique tout ce qui peut poser souci. Simple, claire et didactique, même si ça ne détectera pas tout. Licence non libre.
• Accessibility Inspector intégré dans Mozilla Firefox
• Web Developer de chrispederick.com sous GPLv3, facilitant le travail d'inspection (afficher les “alt”, retirer le style, voir la structuration hiérarchique de la page, etc.). Sous firefox, le module se trouve ici.
• Stylus sous GPLv3, facilitant certains tests de style
• Landmarks sous MIT/X11, permettant l'affichage et la navigation dans les WAI-ARIA landmarks d'une page web

Autre :

• Colour Contrast Analyser (CCA) de The Paciello Group sous licence GPLv3
• Contrast Finder de Asqatasun sous licence AGPLv3
• Axe-core, accessibility engine for automated Web UI testing, sous licence MPL2.0
• Enabler, Accessibility analyzer, sous licence MIT :
• Pa11y ; voir aussi le github du projet.

Il existe globalement diverses listes d'outils à travers le web plus ou moins à jour : ici sur frontendmasters.com ou encore sur cette liste github par exemple.

Certains outils sont plus pertinents côté développement, d'autres côté qualification bien qu'ils puissent se recouper parfois.

• Le RGAA lui-même et documents associés
• Le portail “Accessibilité Numérique” de la DINSIC (notamment avec divers guides dans la partie “Ressources”)
• AccessiWeb
• Les notices d'AcceDe Web
• Le guide d'Orange pour la conception et test d'applications et sites accessibles (plutôt orienté développement) mais aussi de documents :
• Checklist accessibilité pour une évaluation rapide du W3C
• EN301 549 V2.1.2 (2018-08) HARMONISED EUROPEAN STANDARD Accessibility requirements for ICT products and services
• Un article intéressant sur l'accessibilité d'un composant d'interface
• Facile à A Lire et à Comprendre (FALC)
• Accessibilité sur le MDN
• Reference for inclusive game design

• Nouveau site en construction à auditer : https://cipra.khaganat.net (basé sur Django)
• Auditer/chercher des informations sur l'accessibilité des briques composant l'existant :
  • Dokuwiki : de ce que j'avais lu, supérieur à de nombreux wiki, à voir pour notre thème en particulier
  • Simple Machines (forum)
  • Converse.js (chat XMPP)
  • GitLab (forge code et assets)
  • Etherpad + thème utilisé
  • NextCloud
• Ajouter la dimension de l'accessibilité au niveau de la puissance des machines des utilisatrices et de leur connexion Internet
• Compléter le présent document au grès des besoins

TODO : tags à compléter ? Expliquer FALC. Expliquer la composition du WCAG. Partie plus technique ? Evoquer ARIA