Typo3 et l'accessibilité
L'accessibilité et les CMS
L'accessibilité des sites Web est une thématique assez ancienne, le premier standard ayant vu le jour en 1999. Elle demeure cependant une préoccupation récente. Autant dire que les outils de gestion de contenu n'ont pas anticipé sa prise en compte et beaucoup peinent désormais à s'aligner sur un socle d'accessibilité minimum.
Typo3 n'échappe pas à ce constat, même si un effort particulier est mené pour corriger cet état de fait : en effet cet outil est en constante évolution et nous avons pu remarquer au fur et à mesure des projets et des versions que de plus en plus le code généré par défaut respecte les standards.
Notre démarche de conception est la suivante :
- Prise en compte de l'accessibilité dès la phase d'analyse et conception d'une architecture de l'information appropriée
- Réalisation de gabarits de page accessibles
- Utilisation d'un éditeur WYSIWYG modifié pour permettre la saisie de types de contenus accessibles
- La mise en conformité des extensions de Typo3 utilisées par l'extension de classes et de méthodes permises par l 'architecture objet du CMS
- La formation de l'équipe éditoriale, seule garante à long terme d'un niveau d'accessibilité optimal
Réalisation de gabarits de page accessibles
Lors de la découpe de la maquette en HTML, nous apportons un effort particulier quant au code généré :
Utilisation d'un doctype XHTML ( ou selon les besoins)
- Conformité W3C du code
- Choix des balises HTML conformément à leur contexte d'utilisation dans la page
- Tableaux : différenciation des tableaux de données / tableaux de mise en forme ; ces derniers s'ils sont utilisés sont mis en forme de façon à être correctement linéarisés.
- Gabarits le plus souvent en « Full CSS »
- Contrastes et des couleurs : nous nous efforçons au maximum de sensibiliser les graphistes aux problèmes de vue éventuels que peut rencontrer un utilisateur
- Test de la compatibilité du rendu avec le plus de navigateurs et plateformes possible
RTE (Rich Text Editor)
Typo3 utilise depuis la version 4 l'éditeur de texte HTMLArea, adapté spécialement pour les besoins de ce CMS.
HTMLArea est entièrement configurable via le backend : on a par exemple la possibilité d'ajouter ou d'enlever des fonctions, selon des groupes ou des utilisateurs Backend
Il existe de plus un plugin pour HTMLArea avec lequel on peut créer des balises personnalisées (Custom Tags) ; ce plugin, configuré correctement permet par exemple d'ajouter la possibilité d'insérer une balise telle que <span lang="language"> ce que ne propose pas le HTMLArea standard.
Acronymes et abbréviations
Par défaut il n'est pas aisé de saisir ces balises via le RTE HTMLArea.
Après plusieurs tests nous avons trouvé que pour la génération des ces balises une extension s'en sort fort bien : Accessibility Glossary.
Cette extension, destinée à la base à une gestion de glossaire, peut être utilisée pour la gestion des tags abbr et acronym ; en stockant en base des entités elle intègre en plus une gestion des langues et au final peut rendre une balise telle que : <abbr title="Content Management System" lang="en">CMS</abbr>
Maîtrise du code généré
L'API de Typo3 possède une couche dédiée aux transformations RTE to DB / DB to RTE, qui permet, via une configuration en backend d'autoriser ou non certains tags HTML, voire de les transformer à la volée ; exemple : un texte en gras dans le HTMLArea sera stocké en base et restitué dans le RTE avec une balise b (dépréciée), tandis qu'il sera restitué dans la page du site avec la balise strong.
Gestion des scripts
La gestion des scripts est une des problématiques récurrentes dans le domaine de l'accessibilité ; c'est le cas le plus souvent avec le JavaScript, les animations Flash...
Nous nous efforçons lors de l'intégration d'éviter au maximum l'utilisation du JavaScript, et de tout au moins proposer une alternative lorsque l'on ne peut éviter celui-ci.
Une partie est gérée en standard par Typo3, comme le « clic-enlarge » :
c'est la possibilité de cliquer sur une vignette image pour voir l'image en taille plus grande. La nouvelle fenêtre est appelée via JavaScript afin d'être retaillée et sans barres d'outils : le code est généré de telle façon qu'un utilisateur sans JavaScript se verra proposer une nouvelle fenêtre via le code HTML classique.
Nos extensions
Nous avons poussé un peu plus loin la gestion de l'accessibilité des scripts pour des éléments très souvent utilisés : le générateur de formulaires d'envoi de mail et le moteur de recherche.
Générateur de formulaires d'envoi de mail
La vérification des champs requis se fait malheureusement via JavaScript, c'est pourquoi nous avons créé l'extension « accessible_form_validation » : cette extension modifie l'outil standard de Typo3 en gérant la validation des champs requis via serveur et renvoie une liste d'erreurs modifiable via template directement dans la page et non via une alerte JavaScript.
Moteur de recherche
Dans le moteur de recherche de Typo3 (indexed_search), lors d'une recherche aboutissant à un grand nombre de résultats ceux-ci sont répartis en plusieurs pages, or la gestion des liens du « tourne pages » encore une fois est réalisée via JavaScript.
Nous avons pour cela créé l'extension « accessible_is_browse_results »
Cette extension génère un code sans JavaScript pour la gestion du tourne pages via des liens explicites ; de plus elle permet de modifier les titres de pages de résultat à la volée :
(exemple : Résultats de la recherche pour Typo3 – page 2)
Par Christophe Deleury expert AccessiWeb en évaluation des sites web
Voir aussi :
Extension typo3 : "Vérification du code et l'accessibilité"
