Typo3 et l'accessibilité
L'accessibilité et les CMS
Malgré l'apparition du premier standard en 1999, l'accessibilité demeure une préoccupation récente. La majorité des outils de gestion de contenu n’a pas anticipé sa prise en compte et peinent désormais à s’aligner sur un socle d’accessibilité minimum.
Typo3 est plutôt avancé dans ce domaine. Il comporte nativement divers outils (images accessibles, Insertion d'acronymes et abréviations, création de tableaux accessibles, correction du code XHTML, gestion des accesskey, tabindex ...).
En complément, Oblady a publié plusieurs extensions spécifiques à l'accessibilité :
- formulaire de contact accessible,
- présentation de résultats du moteur de recherche,
- tourne pages accessible + titre des pages de résultats,
- génération de rapports d'accessibilité,
- simulation d'affichage sous Lynx,
- validation de la conformité XHTML des pages).
Néamoins, comme dans toute démarche d'accessibilité, la saisie des contenus est aussi importante que les gabarits dans laquelle elle s'inscrit, c'est pourquoi nous avons mis en place la démarche de conception 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
- Mise en conformité des extensions de Typo3, réalisables 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 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 conçus 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 possibles
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, suivant le profil des administrateurs et des rédacteurs.
En complément, Il existe un plugin qui permet de créer des balises personnalisées (Custom Tags) , fonction non standard de HTMLArea.
Acronymes et abréviations
Par défaut il n'est pas aisé de saisir ces balises via le RTE HTMLArea.
Après divers tests, nous avons trouvé une extension facilitant la génération de ces balises : 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.
Parmi nos contributions
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, en standard, 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 le serveur, et renvoie une liste d'erreurs (modifiable via template) directement dans la page, au lieu de l'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 » est encore une fois réalisée via JavaScript.
Pour y remedier, nous avons 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)
