JCMS et l'accessibilité

Tim Berners Lee définit l'accessibilité Web ainsi :

Mettre le Web et ses services à la disposition de tous les individus, quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales.

Dans la pratique, l'accessibilité numérique (ou l'accessibilité Web) concerne la prise en compte de :

• Certaines formes de handicap (auditif, visuel, cognitif) ;
• Certaines formes de maladie (telle l'épilepsie) ;
• Des différences culturelles (langues, sens de lecture, ...) ;

Ou autre :

• Matériels différents (plus vieux, mauvaise bande passante, ...) ;
• Configurations logicielles différentes ;
• Configurations des logiciels clients différentes ;
• Requêtes automatiques ;
• Moteurs de recherche ;
• Syndication ;
• ...

La prise en compte de l'accessibilité offre un certain nombre d'avantages reconnus :

• elle permet l'élargissement de l'audience d'un site (l'INSEE a recensé 12 millions de personnes handicapées en 1999 en France) ;
• elle est en de nombreux cas une disposition légale (essentiellement aujourd'hui pour les administrations et collectivités territoriales, mais permet également de se protéger contre des recours en justice en discrimination) ;
• elle améliore l'image d'une entreprise ou institution aux yeux de son public ;
• elle améliore l'ergonomie pour tous les utilisateurs ;
• elle assure une meilleure prise en compte des paramétrages spécifiques des utilisateurs ;
• elle améliore la prise en compte d'un site par les moteurs de recherche (appelé référencement ou SEO : Search Engine Optimization) ;
• elle peut permettre une baisse des coûts de maintenance, ainsi que de la bande passante ;
• elle peut également permettre un gain de productivité fonctionnel, en faisant en sorte par exemple que les formulaires soit statistiquement remplis avec nettement moins d'erreurs, ce qui diminue significativement la charge de traitement des formulaires par les collaborateurs ;
• elle améliore l'interopérabilité.

Un certain nombre de fonctionnalités sont faites spécifiquement dans l'optique d'améliorer l'accessibilité, dans la version 6.0 de JCMS.

1. Tenir compte de l'accessibilité

1.1 Référentiels

Pour faire un site accessible, la démarche habituelle consiste à se conformer à une liste de contraintes. On utilise habituellement des référentiels comme les WCAG, le RGAA, ou AccessiWeb.

Les WCAG (Web Content Accessibility Guidelines, ou Recommandations d'accessibilité pour les contenus web) sont les recommandations standards internationales. Le RGAA (Référentiel Général d'Accessibilité pour les Administrations) est un référentiel officiel produit par la DGME. AccessiWeb est un label de qualité d'initiative privée. Le RGAA et AccessiWeb précise une manière de respecter les WCAG.

Nous faisons essentiellement référence dans la suite aux critères du RGAA, que nous avons étudié en détail. Il avons également fait référence à des critères d'un autre référentiel (en l'occurrence AccessiWeb), quand il n'y avait pas de critère correspondant dans le RGAA.

Dans WCAG 1.0 et AccessiWeb, les items sont répartis en trois niveaux de priorité (respectivement niveaux A, AA, AAA WCAG, ou Bronze, Argent et Or AccessiWeb). Le RGAA se distingue, dans la mesure où il s'agit d'un référentiel légal, il y a donc des critères obligatoires et facultatifs, et, en ce qui concerne les points obligatoires, il y a un échéancier.

Nous parlons plus précisément des différents référentiels ultérieurement.

1.2 Objectifs de Jalios

Jalios s'est fixé comme objectif de permettre la réalisation de sites dont le front-office de consultation soit le plus conforme possible aux critères obligatoires du RGAA, WCAG AA ou AccessiWeb Argent.

Cela implique encore des évolutions que nous comptons réaliser au fur et à mesure des nouvelles versions de JCMS. Jalios tiendra compte de l'évolution des référentiels, des contraintes et des techniques pour améliorer encore la prise en compte de l'accessibilité. Nous ferons en sorte également d'accompagner les clients et les partenaires dans leur démarche.

1.3 Démarche projet

Acteurs de la démarche

Comme expliqué en introduction, pour qu'un site puisse être accessible, il faut que cela soit pris en compte à tous les niveaux :

• expression de besoin ;
• assistance à maîtrise d'ouvrage ;
• système de gestion de contenus ;
• prestation d'intégration ;
• administration ;
• contribution.

En ce qui concerne l'expression de besoin, par exemple, le fait de produire un site accessible est généralement incompatible avec le fait de vouloir un site conforme à un rendu particulier sur tous les navigateurs. En effet, le principe même des réalisations accessibles est de permettre aux utilisateurs de bénéficier d'un rendu conforme à leur préférences (en terme de contrastes de couleur, de taille de polices de caractère, en terme d'absence d'éléments dynamiques non sollicités).

De plus en plus d'intégrateurs développent une expertise en accessibilité, et sont à même d'offrir une prestation de conseil pour aider les AMOA à tenir compte des contraintes d'accessibilité, y compris dans les expressions de besoin.

Il est nécessaire également de tenir compte des contraintes d'accessibilité lors des phases d'accompagnement au changement. En effet, des contraintes sont imposées aux contributeurs. Il faut bien sûr mettre en relation ces contraintes avec les gains qui y sont attachés (en termes d'image de leur contribution et de meilleure prise en compte des utilisateurs).

Audit

Il est préférable de vérifier à posteriori l'effet de la prise en compte de l'accessibilité. Cela s'avère nécessaire en particulier si une labelisation (AccessiWeb par exemple, ou Euracert au niveau européen) est envisagée.

Des outils de tests unitaires automatiques sont disponibles, et leur usage est recommandé, mais ils ne permettent de tester que certain des critères les plus techniques.

La problématique des tests d'accessibilité est abordée plus en détail ultérieurement.

1.4 Exemples de sites JCMS accessibles

Plusieurs de nos clients ont dors et déjà adopté une démarche d'accessibilité lors de la réalisation de leur site. Les besoins que certain nous ont retournés nous ont permis, entre autre, de faire évoluer notre produit dans le bon sens.

On peut notamment citer :

• Natixis ;
• Conseil Général de la Loire-Atlantique ;
• Conseil Général de la Gironde ;
• Conseil Général de la Loire ;
• CARIF.

2. L'accessibilité avec JCMS

Nous allons maintenant analyser comment JCMS permet de répondre aux critères d'accessibilité.

2.1 Conformité aux standards

En ce qui concerne la conformité aux standards :

• La déclaration de la DTD est faite et est correctement positionnée (RGAA 3.2.1, RGAA 3.2.2, RGAA 3.2.3) ;
• La langue de traitement d'une page et le sens de lecture de la langue de la page sont indiqués (RGAA 4.3.1, RGAA 4.3.2) ;
• Les changements de langues et de sens de lecture dans la page sont indiqués (RGAA 4.1.1, 4.1.2, 4.1.3, 4.1.4). Ce critère est pris en compte dans le cas ou un contenu n'est pas dans la langue de la page ou un champ d'un contenu n'est pas dans la langue du contenu. Cela n'est pas géré à l'intérieur des champ (par exemple lors d'une citation à l'intérieur d'un champs Wiki) ;
• Les technologies préconisées par le W3C sont privilégiées (RGAA 11.1.1) ;
• Les dernières versions des technologies du W3C sont privilégiées (RGAA 11.1.2) ;
• La déclaration d'encodage de caractères est indiquée, de manière pertinente (RGAA 13.2.4, RGAA 13.2.5).

2.2 Bonnes pratiques

Sans que cela soit une conformité aux standards, par défaut, JCMS vérifie également les points suivants :

• La représentation visuelle des listes numérotées est correcte (RGAA 3.6.4) ;
• Il n'y a pas de génération de contenus via les feuilles de styles (RGAA 6.1.1) ;
• Il n'y a pas de redirection automatique (RGAA 7.5.1).

2.3 Fonctionnalités

Par ailleurs, les fonctionnalités suivantes, présentes dans JCMS ont un impact non négligeable sur l'accessibilité :

• Les boutons précédent / suivant des navigateurs sont correctement utilisables après une mise à jour du DOM par du javascript utilisant XMLHttpRequest (c'est-à-dire des requêtes AJAX, RGAA 6.5.7) ;
• Le contenu fourni à l'utilisateur est conforme à ses préférences de langue (RGAA 11.3.4) ;
• Il y a toujours un titre de page, non vide et approprié (RGAA 13.2.1, RGAA 13.2.2, RGAA 13.2.3) ;
• JCMS met par défaut à disposition un plan de site fonctionnel (RGAA 13.3.1, RGAA 13.3.2).

2.4 Éditeur WYSIWYG

D'après plusieurs tests comparatifs disponibles sur Internet, il n'existe pas à ce jour d'éditeur WYSIWYG qui produise un code entièrement accessible.

L'éditeur produisant aujourd'hui le code le plus accessible semble être Xstandard. Nous n'avons pas choisit cet éditeur car il s'agit d'un client lourd, non portable (c'est-à-dire qu'il s'installe sur le poste de l'utilisateur est n'est disponible que pour certaines versions de Windows et sur Mac OS X).

En étant configuré correctement, l'éditeur WYSIWYG utilisé dans JCMS, TinyMCE obtient quasiment les mêmes résultats.

Références :

• Evaluation des éditeurs WYSIWYG (en anglais);
• Evaluation des éditeurs WYSIWYG (seconde référence, en anglais);

2.5 Moteur de recherche

JCMS propose un moteur de recherche performant et offrant, en plus de la recherche textuelle :

• de nombreux axes de recherche alternatifs (catégories, dates, auteur, types de contenu : RGAA 13.7) ;
• du calcul de pertinence ;
• de la suggestion orthographique.

2.6 Support de la langue

Outre les informations de langue et de sens de lecture du texte, JCMS propose un support très complet du multilinguisme, avec :

• la localisation de l'ensemble des interfaces ;
• le support d'UTF-8 (pour encoder dans tous les jeux de caractères) ;
• la gestion des champs multilingues dans la structure même des contenus ;
• la prise en compte des préférences utilisateurs :
  • choix de la langue courante en session (par un bouton) ;
  • sinon, information persistée dans le profil de l'utilisateur ;
  • sinon, prise en compte de la langue indiquée par le navigateur ;
  • sinon, choix par défaut imposé par le serveur.

2.7 Barre et menu de navigation

JCMS propose des gabarits de portlets permettant de répondre à des besoins d'accessibilité, par exemple des gabarits réalisant des barres et menu de navigation (RGAA 13.5). Il est à la charge des intégrateurs de les utiliser à bon escient pour fournir des mécanismes de navigation cohérents à travers le ou les sites (RGAA 13.4).

2.8 Formulaires accessibles

JCMS propose en front-office des formulaires standards (login, recherche, avis, discussions de forum), et des formulaires générés (par exemple un formulaire de demande de création de compte).

JCMS 6.0 tient compte des contraintes d'accessibilité pour tous ces éléments de formulaires.

D'un point de vue technique, la plupart des éléments de formulaires sont générés dans JCMS à l'aide du tag <jalios:widget>. Le code HTML produit par ce tag a été rendu accessible, à l'exclusion de certain types de champs, qui n'ont pas vocation à être utilisés dans le front-office (texte riche, liens vers items de base de données, chemin vers fichiers, images). Cela implique que l'usage de ce tag permet aux développeurs d'obtenir des formulaires accessibles (RGAA 12.4).

2.9 Changement de contexte de navigation

JCMS 6.0 offre une fonctionnalité de changement de CSS à la demande de l'utilisateur. Cela permet de proposer, en complément de la charte graphique par défaut, une charte alternative, avec des contrastes adaptés à certaines problématiques visuelles (comme certaines catégories de daltonisme, cf. RGAA 2.2, pour lesquelles il est possible de proposer des contrastes de couleur plus ou moins importants).

Fig. 1. Styles standards

Fig. 2. Interface de changement de styles

Fig. 3. Styles avec contrastes modifiés

2.10 Lien vers des fichiers

Les liens vers des fichiers fournissent dans JCMS 6.0 des informations sur :

• le poids du fichier à télécharger (avec l'indication du sens des unités) ;
• le format du fichier à télécharger.

Fig. 4. Liens vers des fichiers indication dans le title

Fig. 5. Lien vers des fichiers détail dans le lien

Références : RGAA 11.3.1, 11.3.2, 11.3.3

2.11 Traitement des fichiers

Si le module d'indexation est installé, la plupart des fichiers téléchargés sont indexés et la recherche textuelle a lieu également à l'intérieur des fichiers.

Si de plus, le module de conversion PDF est installé, une version alternative est disponible pour la plupart des fichiers téléchargés, dans le format PDF. De plus, les PDF générés respectent en général les recommandations d'accessibilité qui les concernent.

Les PDF étant générés automatiquement, il n'y a par contre pas de fonctionnalités d'accessibilité spécifiques au format PDF qui n'existent pas dans les formats bureautiques avant conversion.

Références:

• RGAA 13.7 pour la recherche dans les fichiers ;
• AccessiWeb 1.0, 13.6 pour la présence de formats alternatifs.

2.12 Affichage d'impression

Une CSS spécifique au medium print est disponible dans JCMS 6.0, permettant de cacher et de montrer des éléments spécifiquement pour l'impression. De plus, cette CSS affiche le détail des acronymes et des abréviations. (RGAA 11.3.5).

Fig. 6. Affichage détaillé d'un contenu

Fig. 7. Le même affichage détaillé, en apperçu d'impression

2.13 Zone de texte invisible

Il est possible dans JCMS 6.0 d'ajouter des zones de texte invisibles par défaut sur un navigateur graphique, mais interprété par un lecteur d'écran (utilisé par les non-voyants). En particulier, cela sert pour indiquer dans les liens un intitulé entièrement compréhensible (et non pas uniquement « cliquer ici »). Un bouton de l'éditeur WYSIWYG permet de sélectionner un morceau de texte et lui donner ce caractère invisible.

D'un point de vue technique, ces zones bénéficient de l'effet d'une classe CSS invisibleZone (RGAA 13.1.1 à 13.1.4).

Fig. 8. Zone invisible désactivée

Fig. 9. Interface WYSIWYG de positionnement du caractère zoneInvisible

Fig. 10. Zone invisible activée

3. Tester l'accessibilité

3.1 Taxonomie des tests

Les critères d'accessibilité peuvent être de natures très différentes.

Par rapport à une démarche de test, il y a trois grandes classes de critères :

• Les critères qui peuvent être testés automatiquement : tels la conformité du code HTML à la version de HTML déclarée, ou la présence de l'indication de la langue principale de la page courante ;
• Les critères pour lesquels on peut décrire un test unitaire précis et reproductible par un humain : tels la présence d'une alternative vide pour les éléments décoratifs (seul un humain est à même de distinguer un élément décoratif d'un élément non décoratif);
• Ceux dont la vérification est soumise à interprétation, comme la pertinence de tel ou tel texte, voire nécessite des compétences très pointues, comme celui qui consiste à imposer de privilégier les technologies du W3C.

3.2 Référentiels de tests

Le référentiel standard international est WCAG. Au niveau national, on a essentiellement le label AccessiWeb et le RGAA.

WCAG

Les WCAG (Web Content Accessibility Guidelines, ou Recommandations d'accessibilité pour les contenus web) sont les recommandations internationales émises par le W3C (organisme principal de standardisation pour Internet). Le WAI (Web Accessibility Initiative), qui est la branche du W3C en charge des recommandations relatives à l'accessibilité a également standardisé une recommandation appelée ATAG (Authoring Tool Accessibility Guidelines, ou Recommandation pour l'Accessibilité des Outils de production de Contenu). Cette recommandation est actuellement en version 1.0 et une version 2.0 est en chantier.

Le référentiel WCAG 1.0 (1999) est quelque peu obsolète, c'est pourquoi la version 2.0 est en cours de standardisation. WCAG 2.0 n'est pas la version officielle, et il est tout à fait possible qu'elle soit modifiée avant d'être adoptée. Néanmoins, il est possible de s'y référer pour voir les descriptions des critères et anticiper sur son adoption.

Les recommandations WCAG sont plus des principes que des critères précis. C'est d'ailleurs la raison pour laquelle un certain nombre d'autres référentiels indiquent qu'ils sont des implémentations pratiques des WCAG.

Plus précisément, les WCAG 1.0 fournissent un ensemble de recommandations. Chaque recommandation a un ensemble de checkpoints dont il est donné des exemples de code vérifiant ces checkpoints, mais pas de test unitaire exhaustif.

Les WCAG 2.0 sont une liste de recommandations, chaque recommandation étant associés à des critères de succès. Malheureusement, les WCAG 2.0 ont été rédigés en faisant abstraction des technologies utilisées. Chaque critère est donc soumis à interprétation.

RGAA

Le décret d'application de la loi n°2005-102 de février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées impose la prise en compte d'un référentiel, le RGAA (Référentiel Général d'Accessibilité pour les Administrations) pour tous les services de communication publique en ligne des services de l'État, les collectivités territoriales et les établissements publics (RGAA).

Ce référentiel a été élaboré également à partir du référentiel international WCAG 1.0. Il est accompagné de tests unitaires permettant d'évaluer très précisément si ses critères sont vérifiés.

Le RGAA propose un ensemble de critères, appelés points de contrôle. Il propose également, pour chacun de ces points de contrôle :

• sa pertinence ;
• un exemple de bonne utilisation (et parfois de mauvaise utilisation) ;
• une correspondance avec les autres référentiels officiels (WCAG 1.0, mais également la section 508 américaine et le référentiel officiel précédent produit par la DGME, mais pas avec les labels AccessiWeb ou Euracert) ;
• une description précise des tests unitaires à effectuer pour vérifier la bonne application de ce critère.

Accessiweb

Au niveau français, un label indépendant a été créé par un ensemble de professionnels. L'attribution de ce label est soumise à un audit réalisé par un des professionnels agréés. Une liste de critères à vérifier, élaborée à partir des WCAG 1.0, est publiée. Malheureusement ces critères manquent de précision, et il n'est parfois pas possible de savoir si les actions pour les mettre en œuvre sont pertinentes.

Cette liste de critères a été récemment mise à jour, avec une version 1.1. Les descriptions des critères sont plus précises. Le résultat manque néanmoins de rigueur. Il est dommage que les critères n'aient pas été soumis à discussion en dehors du groupe de travail AccessiWeb, qui est un groupe fermé (la formation BrailleNet est en particulier un prérequis pour en faire partie), et les discussions internes ne sont pas publiées de manière publique.

Le groupe de travail AccessiWeb est actuellement en cours de travail sur un référentiel d'accessibilité concernant les CMS (ce devrait être en quelque sorte à ATAG, ce que le référentiel AccessiWeb est aux WCAG). Le fonctionnement du groupe de travail AccessiWeb fait qu'il n'est possible ni de juger de sa pertinence, ni d'anticiper sur la prise en compte de ce référentiel. Il y aura par contre un appel à commentaire public en janvier 2009.

AccessiWeb 1.1 fournit une liste de critères (le référentiel), tout comme le RGAA. Il fournit également un Guide AccessiWeb qui, pour chaque critère offre :

• une description de sa pertinence ;
• une liste de tests unitaires dont les descriptions sont parfois trop succinctes ;
• des aides de mise en œuvre ;
• des indications pour aider à effectuer les tests, par exemple en donnant des références à des outils permettant de mettre en œuvre les tests.

Section 508

En théorie, cela ne devrait pas avoir d'impact sur des projets réalisés en France, nénamoins, il faut savoir (parce qu'il est fréquemment utilisé dans les outils de tests et la littérature sur le sujet) qu'il existe un référentiel américain, la Section 508 imposé par la loi fédérale et qui s'applique d'autorité aux sites internet des institutions publiques fédérales.

Les outils de tests existants reposent en général sur WCAG 1.0 et la Section 508. Il y a des projets actuellement en cours pour créer des outils reposant sur les référentiels RGAA et AccessiWeb, mais ils ne sont pas finalisés aujourd'hui.

3.3 Outils de test

Les outils de tests à disposition ne remplissent pas tous les mêmes objectifs.

Total Validator

Sur le modèle du service de validation en ligne du W3C, permettant de vérifier la validité du code HTML, il existe un service en ligne d'un outil appelé Total Validator. Cet outil permet de réaliser des tests automatiques sur une page.

Fig. 11. Total Validator, service en ligne

Le moteur de Total Validator n'est pas seulement accessible en ligne, il est aussi disponible sous la forme d'un utilitaire à installer sur un poste de développement. Il est par ailleurs possible d'installer une extension Firefox qui permet de lancer le moteur directement sur la page en cours de lecture dans Firefox.

Fig. 12. Icône Total Validator du plugin Firefox

Total Validator effectue également ses tests en tenant compte des référentiels Section 508 et WCAG 1.0.

Voici la liste des tests vérifiés automatiquement par TotalValidator.

Web Developer Toolbar

La Web Developer Toolbar propose un certain nombre de fonctionnalité de validation dont pour une ressource en ligne :

• de la conformité du HTML de la page (en appelant le valideur W3C);
• des critères automatisables d'accessibilité selon le référentiel Section 508 (en se basant sur le moteur Cynthia Says);
• des critères automatisables d'accessibilité selon le référentiel WCAG 1.0 (en se basant sur le moteur Cynthia Says).

Elle permet également, pour une ressource locale de tester la validité HTML. Cela est particulièrement intéressant lors d'une phase de développement.

Fig. 13. Menu Outils de la barre développeur de Firefox

Module DevTools

Pour mener des tests, l'usage est de prendre un panel de pages, que l'on essaie de choisir représentatif du site.

En ce qui concerne les tests automatisables, il est pertinent d'utiliser la fonctionnalité de tests des éléments du front-office disponible à partir de la version 2.1 du module DevTools.

Fig. 14. Accès à la page de test des éléments du front-office

Fig. 15. Générer des contenus de test

Fig. 16. Visualise la page de visualisation des éléments du front-office

Cette fonctionnalité permet de créer des données de tests pour visualiser dans une seule grande page le code HTML généré par tous les gabarits de tous les types de portlets et de tous les types de contenus, il affiche également un rendu de chaque type de widget (code HTML produit automatiquement pour une entrée de formulaire).

Il est donc pertinent régulièrement, pendant le développement, d'utiliser cette page et de lancer sur cette page d'une part le valideur W3C, d'autre part Total Validator.

Ceci s'apparente à une logique de tests d'intégration continue et est recommandé en plus de tests réalisés par un humain.

Autres outils

Le WAI référence une liste d'outils relatifs aux WCAG et à l'accessibilité.

Il y a également un Consortium d'outils d'accessibilités (Le WAT-C Web Accessibility Tools Consortium).

3.4 Tests nécessitant une interprétation

La barre développeurs de Firefox est encore une aide précieuse, en particulier l'onglet Information qui nous permet d'afficher :

• les abréviations;
• les AccesKeys;
• les ancres;
• les informations des tableaux (de données);
• le plan du document (par rapport à la hiérarchie des niveaux de titres HTML dit hn).

Fig. 17. Menu Information de la barre développeur de Firefox

Il y a également l'onglet Images qui nous offre entre autre :

• de désactiver les images, et donc les images sont remplacées par leurs alternatives;
• remplacer les images par leur attribut alt. (Il y quelques différences très mineures pour les deux actions, en particulier, dans le premier cas, la requête HTTP est renvoyée).;
• afficher les images qui n'ont pas d'attribut alt.

Fig. 18. Menu Images de la barre développeur de Firefox

Par ailleurs, il existe aussi la Barre d'outils Accessibilité du Web 2.0 pour Internet Explorer.

Cette barre permet à peu près de faire sous Internet Explorer ce que la barre développeurs permet, au niveau accessibilité de faire sous Firefox.

Il existe un outil d'analyse des contrastes de couleurs. Cet outil est utilisable également par l'intermédiaire de la barre d'outils accessibilité pour Internet Explorer.

Fig. 19. Outil d'analyse des contrastes

Il existe un outil en ligne dont la vocation est d'aider à un audit de lisibilité d'une page donnée. Il est néanmoins nécessaire d'avoir des valeurs de référence pour juger du résultat du test.

3.5 Démarche de tests

La démarche habituelle de tests d'accessibilité repose sur un audit a posteriori. Un tel audit, concernant un site ayant beaucoup de pages, nécessite de considérer un panel représentatif de pages et de réaliser les tests sur ces pages. En général on considère une dizaine de pages, mais cela varie beaucoup de la structure logique fonctionnelle du site.

La fonctionnalité de test des éléments du front-office offerte par le module DevTools de JCMS permet de faire un peu plus. Il est possible, comme indiqué ci-dessus, de prévoir dans la phase de développement, une tâche récurrente d'intégration continue, avec réalisation des tests automatiques à l'aide de cette fonctionnalité et des outils de tests automatiques pour un contenu local (validator W3C et TotalValidator).

Compte tenu des spécificités de JCMS, nous préconisons la démarche suivante :

• Pendant la phase de développement, prévoir une tâche récurrente d'intégration continue avec la fonctionnalité de test des éléments du front-office;
• Pendant la phase d'audit, effectuer les contrôles sur un panel représentatif de pages du site.

En ce qui concerne le panel représentatif de page, il est sans doute pertinent de prendre une page par portail utilisé dans le front-office. Cette démarche est à affiner selon les spécificités de l'application.

4. Aller plus loin

4.1 Évolutions à venir

Jalios accompagnera les intégrateurs pour leur faciliter la prise en compte de l'accessibilité dans les projets. Cela passera en particulier par des articles complémentaires.

Concernant JCMS, il est prévu entre autre :

• d'offrir un support des ressources multimédia synchronisées ;
• d'améliorer les interfaces de contribution WIKI/WYSIWYG pour guider les contributeurs pour les aider à respecter les contraintes de d'accessibilité lors de la contribution ;
• de faire des évolutions de manière opportune en fonction de l'évolution des technologies, des problématiques et des retours de nos clients et partenaires.

4.2 Références

Voici quelques ressources internet présentant d'une part la problématique et quelques solutions techniques relatives à l'accessibilité numérique.

• Dive into accessibility (en anglais) très bonne introduction à la problématique, avec des exemples concrets ;
• Section accessibilité du site « A list apart » (en anglais) : articles de très bonne qualité ;
• 10 astuces pour améliorer l'accessibilité de votre site web. Présentation un peu simpliste, mais syntétique (10 points) de ce dont il faut tenir compte pour faire de l'accessibilité numérique.