Chapitre 14

Dans Joomla!, vous pouvez faire apparaître seulement le début des articles, c’est-à-dire les chapeaux
ou les accroches. Dans les précédentes versions de Joomla!, chaque début d’article était suivi d’un
lien indiquant Lire la suite (ou Read more). Le texte de ce lien était le même partout jusqu’à la
version 1.5.

Les appareillages d’aide tel que les lecteurs d’écran ne permettent de traiter que les liens d’une seule
page. Par conséquent, il devient nécessaire de reformuler les textes des liens pour identifier la cible
avant de décider de s’y rendre.

Cette démarche concerne également le libellé de type Lire la suite, qui doit être personnalisé pour
chaque article. Si vous ne conformez pas le site à cette contrainte, il sera rejeté dès le premier test de
conformité.

Dans Joomla! 1.5, le libellé du lien de suite est positionné de façon standard, ce qui aide à le distinguer
de la cible du lien.

Cette approche n’est cependant pas viable à long terme. Elle provoque l’apparition d’une information
en double et c’est une donnée qui est difficilement accessible aux rédacteurs.

Nous avions vu au Chapitre 8 (section 8.2.1) comment accéder aux paramètres avancés d’un article,
afin de décider de son aspect et du contenu à rendre visible sur chaque page. Dans Joomla! 1.5, un
nouveau paramètre est apparu. Il s’intitule Texte alternatif Lire la suite. Vous pouvez le distinguer
dans le bas de la liste montré à la Figure 14.12.

Figure 14.12 Le paramètre de saisie du texte alternatif pour les liens Lire la suite.

Il est envisageable de faire de la saisie d’un contenu suggestif dans ce paramètre un impératif rédactionnel. En effet, il ne sert pas qu’à personnaliser les textes des liens. Il permet également d’attirer la curiosité du lecteur afin de l’inviter à lire la suite.

Il ne faut pas bannir totalement les tableaux. Lorsqu’ils servent à représenter des structures de
données, ils restent le mode de présentation le plus pertinent.

Joomla! utilise dans de nombreuses occasions des tableaux de données peu complexes. C’est notamment le cas dans la liste des liens Web ou celle des contacts.

Les tableaux de données restent des éléments accessibles lorsqu’ils sont utilisés pour représenter des données tabulaires.

L’attribut nommé headers établit la liaison entre chaque cellule de données (balise td) et son titre
(balise th) via l’identificateur ID du titre ou, lorsqu’il y a plusieurs titres, par identificateurs ID
numériques croissants. Cette approche est utilisée pour les tableaux de données internes de
Joomla!.

Rappelons par ailleurs que la configuration de la liste des liens Web ou celle des contacts contient un paramètre pour masquer la ligne des en-têtes de tableaux.

Vous savez que Beez abandonne définitivement les tableaux de mise en page, notamment au niveau des formulaires.

J’ai décidé, en conformité avec les standards, d’établir les liaisons logiques entre les éléments des
formulaires et leurs légendes en utilisant l’élément label. Les champs de saisie sont identifi és grâce à l’attribut universel ID, et nous faisons référence à ce numéro dans l’attribut for de l’élément label. Tous les éléments de formulaire ont été repensés en conséquence dans le template Beez. À chaque endroit où il me semblait logique de procéder ainsi, j’ai regroupé les contenus par un élément fieldset et je lui ai associé un élément legend (par exemple pour le formulaire d’édition de contenu)

Joomla! est livré dès le départ avec toute une série de modules apportant des enrichissements fonctionnels au noyau. Certains permettent d’utiliser du code HTML en rédaction libre. D’autres, très spécialisés, permettent par exemple d’afficher la liste des articles les plus lus. Dans la partie administrative de Joomla!, vous pouvez décider de la position exacte des différents modules au sein du template dans la partie publique. Les identifi ants des différentes positions possibles pour les modules sont définis dans le fichier XML interne au template. L’intervention dans ce fichier permet de personnaliser la structure de la page en fonction des besoins particuliers de chaque projet.

L’exemple de code suivant implante un module dans la zone de position left :

<jdoc:include type="module" name="left" />

Le template Beez dispose d’une méthode particulière pour associer les modules à une position. C’est ce qui permet de contrôler l’élément header-level, c’est-à-dire la représentation sémantique des titres du module.

À chaque module peut être associé un titre issu d’un niveau de hiérarchie. Le choix de l’aspect des titres et sous-titres revêt une grande importance dans les pages. La présentation doit paraître logique dans la mesure où les différents contenus ont des importances inégales.

<jdoc:include 
type="modules" 
name="left" 
style="beezDivision" 
headerLevel="3" />

Un module remarquable en relation avec la création de page accessible est le module Most Read. En présentant les articles les plus consultés, il facilite l’assimilation des données par le lecteur.

Dans Joomla!, les contenus étaient jusqu’à présent versés dans des tableaux de mise en page. Dans Joomla! 1.5, un nouveau système fait son apparition : les Template-Overwrites.

Il devient possible de positionner les données HTML dans le template sans avoir recours à une
multiplication de tableaux. Cela permet de se mettre en conformité avec les objectifs d’accessibilité. Il n’est pas très simple d’agir sur le code HTML en sortie, mais la structure des données reste logique et l’ensemble forment un tout. Il suffit de quelques connaissances en langage PHP pour réussir à ajouter des personnalisations.

Joomla! se base donc sur le système appelé Template-Overwrites. Son principe est le suivant : si
Joomla! trouve dans le dossier des templates un sous-dossier HTML avec du contenu, il en exploite les fichiers. Dans le cas contraire, il utilise le code standard qui se base sur des tableaux pour des raisons de compatibilité. Beez illustre très bien ce nouveau mécanisme. Voyez à ce sujet la section 13.3.8 du Chapitre 13.

Si l’on analyse la structure arborescente des dossiers de Beez, le nouveau sous-dossier HTML saute aux yeux (voir Figure 14.9).

Figure 14.9 Structure arborescente d’un modèle avec dossier HTML.

Ce dossier contient les noms de tous les modules et composants définis dans cette installation de
Joomla!. La génération des données HTML en sortie pour tous ces fichiers a été adaptée. Pour être conforme à l’objectif de séparation entre contenu et présentation, j’ai conçu une convention de marquage qui reproduit la structure des contenus. Elle suffit à la plupart des domaines d’emploi sans retouches supplémentaires.

Il en découle les points suivants :

• Tous les éléments d’un document sont rangés dans l’ordre logique, quelle que soit la position à laquelle ils seront présentés ensuite à l’écran (à côté ou dessous).
• Tous les éléments ont été conçus en conformité avec leur signifi cation dans le document (leur sémantique) : les titres sont des titres, les paragraphes sont des paragraphes, les citations aussi, etc. Cela permet de réexploiter le même document vers différents périphériques de sortie, y compris de façon optimale via un logiciel de lecture d’écran.

La Figure 14.10 donne un aperçu de la structure apparente des titres et sous-titres de Beez.

Figure 14.10 Structure des titres.

Figure 14.3 Le logo de Beez.

Joomla! est l’un des systèmes de gestion de contenus les plus répandus. En le dotant d’un template d’accessibilité tel que Beez, ce produit peut faire concrètement progresser le monde du Web en direction de l’accessibilité pour tous.

Beez est le fruit d’importants efforts de programmation, et encore plus de persuasion. Ce template permet aux professionnels d’accélérer la création de projets Web accessibles. C’est un gain de temps, un gain d’argent et une incitation à tenir compte des besoins des personnes handicapées. C’est une approche très intéressante pour les sites des mairies et autres structures étatiques qui doivent montrer l’exemple.

Mais Beez a également été structuré pour permettre à des individus peu versés dans la programmation de concevoir des pages complexes et très accessibles.

Ainsi, Joomla! combiné à Beez constitue un excellent outil de multiplication des sites Web compatibles avec les attentes du monde du handicap.

Le template Beez n’est qu’un exemple des possibilités nouvelles qui s’ouvrent dans Joomla! 1.5.
C’est un point de départ que vous pouvez facilement modifier et enrichir. Vous pouvez notamment intervenir sur son aspect visuel en modifi ant librement les fichiers CSS.

Les programmeurs peuvent créer de nouveaux templates à partir de Beez, en étant assurés de rester conformes aux recommandations d’accessibilité sans perdre en performance.

À l’heure actuelle, ce que l’on désigne comme template Joomla! est la partie qui gère l’aspect visuel. Au premier regard, Beez ne semble pas très attrayant. Il faut savoir que l’aspect visuel et le code CSS associé ne constituent qu’un épiderme que vous pouvez aisément modifier si vous connaissez la syntaxe du langage CSS.

Le fichier index.php ne s’écarte quasiment pas de celui des templates habituels. Nous n’en aborderons pas les détails.

Voici d’abord quelques exemples de sites qui ont été réalisés avec ce template sans effectuer de
personnalisation poussée.

Figure 14.4 http://www.lichtblick.ch/

Figure 14.5 http://jobs.pr-journal.de/

Figure 14.6 http://www.assfinet.de/

Figure 14.7 http://www.kommkonzept.de/

Figure 14.8 AWO.

14.3.1 Séparation du contenu et de la mise en page

La première règle est la plus importante à suivre pour les concepteurs de sites Web : la séparation la plus complète possible des contenus et de leur présentation :

• du code HTML propre et pur pour les contenus ;
• pas d'utilisation inutile des cadres de mise en page ;
• formatage uniquement par des styles CSS ;
• structuration logique et arborescente des contenus ;
• repères visuels de saut.

La présentation linéaire des contenus et le formatage uniquement basé sur CSS constituent l’une des principales décisions pour augmenter l’accessibilité.

Ainsi, les techniques et appareillages d’assistance au handicap préparent et exploitent les contenus sans infl uer sur la présentation visuelle. La définition de la présentation par des feuilles de style permet par exemple à un mal-voyant de mettre en place ses propres feuilles de style pour adapter l’affichage des pages à ses attentes. La présentation linéaire des contenus et une structuration en rapport avec le sens des contenus sont notamment indispensables pour les utilisateurs des lecteurs d’écran.

Un lecteur d’écran évalue le contenu d’une page Web de haut en bas, donc de façon linéaire. Si vous utilisez trop de tableaux pour la présentation, le flux linéaire est rompu.

La notion de sémantique des pages Web peut sembler difficile à saisir au départ. Vous pourriez
songer à une analyse linguistique. Sans aller si loin, le concept de sémantique joue un grand rôle
dans les contenus Web. Par exemple, un outil de lecture d’écran permet souvent à l’utilisateur de
passer en revue les grands titres ou seulement les listes, afin de se faire une idée générale du contenu. Si la page Web ne contient aucun titre, cela n’est plus possible.

La structure de présentation du document devrait dans la mesure du possible refl éter la structure
signifi ante de son contenu. D’ailleurs, de nombreux projets de publication Web doivent se conformer à une charte rédactionnelle quant à l’emploi des différents niveaux de titres.

Repères visuels

La présentation linéaire des contenus souffre d’un inconvénient sérieux : il faut parfois revenir
loin en arrière pour retrouver un contenu antérieur. En choisissant une présentation sur trois colonnes par exemple, il est possible de faire démarrer en haut plusieurs articles. Le regard embrasse plus d’informations, en utilisant éventuellement des aides visuelles. Ces aides sont représentées par des repères. Le but est d’obtenir une formulation différente de celle de la présentation graphique. Un équipement de lecture linéaire exploite ainsi un plus grand nombre de domaine d’informations dès le début de la page. Ensuite, le lecteur se rend directement au bloc d’informations qui l’intéresse.

En général, les repères visuels prennent la forme d’un menu pour naviguer dans chaque page. Ce
menu placé en début de page doit être masqué dans l’affichage graphique. Il est assez désagréable pour les valides de constater que rien ne se passe lorsqu’ils cliquent sur un lien, puisque la cible du lien est déjà présentée dans l’affichage. Le menu des repères visuels ne doit jamais être trop long et son contenu bien pensé. Il ne faut pas qu’il vienne ajouter à la complexité. Il est généralement conseillé de choisir comme premier repère visuel un lien pour revenir à la page d’accueil. Les visiteurs qui connaissent déjà le site et ont pris l’habitude de la navigation disposent ainsi d’un chemin rapide pour revenir au point de départ de leur navigation.

Ces observations vous ont sans doute permis de mieux comprendre que les pages, notamment les plus complexes, doivent offrir une présentation graphique étudiée et avoir fait l’objet d’une véritable conception des contenus. Le but est qu’elles ne constituent pas de barrières inutiles pour les logiciels d’exploitation linéaire.

14.3.2 Contraintes de conception et de contenu

Créer un site Web ne se limite pas à trouver une belle présentation. La conception doit aider les
visiteurs à assimiler les informations. Elle doit montrer les possibilités d’interaction tout en laissant
transparaître l’identité du propriétaire des pages, que ce soit une entreprise ou un particulier.

La conception doit permettre de mener le visiteur dans un chemin logique à travers les contenus
essentiels, en sorte qu’il se sente guidé pour capter le concept global.

Voici les points à surveiller dans la conception d’un site accessible :

• une distribution logique des contenus ;
• un choix réfléchi des couleurs ;
• un contraste visuel suffisant ;
• des tailles de caractères variables ;
• des mises en page retaillables (mise à l’échelle) ;
• aucun texte sous forme graphique ;
• aucun arrière-plan transparent pour les graphiques ;
• des textes d'attente sensés pour les images ;
• des composants de navigation de dimensions suffisantes ;
• des précautions pour mettre en place des événements pilotés seulement via la souris.

14.3.3 Organisation visuelle et sémantique du contenu

Pour guider de façon logique le visiteur dans votre site, il faut obtenir une bonne séparation des
différentes zones des pages. Plus la structure est logique, mieux les visiteurs trouveront leur route.

La structuration des contenus a autant d’importance que celle de la présentation. D’ailleurs, il existe une règle importante au niveau de la structuration des contenus :

Vous devez structurer vos contenus conformément aux attentes de vos visiteurs.

Cet objectif n’est pas toujours simple à atteindre, et il faut parfois changer d’approche. Les auteurs des contenus connaissent leur projet ou leur entreprise. Ils ont donc tendance à structurer les choses d’une manière qui n’est pas celle que le visiteur choisirait.

Plusieurs conventions destinées à la structuration visuelle ont fini par s’établir : le haut de page
contient en général des informations concernant l’auteur du site. L’objectif de la page et les principaux composants de navigation (contact, mentions légales et aide à la navigation) sont présentées au même endroit avec parfois des liens vers un plan du site et une fonction de recherche. Cette position particulière permet de placer certaines informations directement devant le visiteur, ce qui fournit un point de référence en cas de souci d’accès.

Dans les langues occidentales, l’écriture se faisant de gauche à droite, l’oeil est entraîné naturellement à analyser le contenu d’un document dans le même sens, soit de gauche à droite et de haut en bas. Voilà pourquoi le logo est généralement placé dans le coin supérieur gauche. C’est à cet endroit que l’on s’attend à le voir.

La plupart des utilisateurs s’attendent à trouver les éléments de navigation du côté gauche. C’est un vaste sujet de débat, et les détracteurs prétendent que cela prouve un certain manque d’imagination. Mais les hommes aiment les habitudes, y compris sur le Web. Chacun a son expérience et agit en conséquence. En laissant à l’endroit habituel les éléments attendus, vous faites gagner du temps aux visiteurs. Ils trouvent plus facilement ses repères.

14.3.4 Choix des couleurs

Le choix des couleurs est essentiel pour limiter les obstacles à l’accès. Même les individus souffrant de handicaps visuels doivent profiter pleinement de votre site Web.

Testez votre site en le forçant en niveaux de gris, ce qui vous permet de le voir comme les personnes insensibles aux couleurs. La capacité de distinguer différentes nuances de gris dépend bien sûr de l’individu. Nombreux sont les handicapés qui ont appris à se repérer d’une autre manière, et parviennent à deviner à quelles couleurs correspondent les tons qu’ils voient. Ils savent que l’herbe est verte et peuvent ainsi repérer d’autres tons verts par rapprochement.

Figure 14.1 Aspect du modèle Beez après conversion en niveaux de gris.

Le daltonisme est plus répandu. Les daltoniens confondent le rouge et le vert ainsi que les mélanges de ces deux couleurs.

14.3.5 Contraste

L’optimisation du choix des couleurs permet également de faciliter la navigation aux personnes
souffrant d’autres problèmes visuels. En effet, ce n’est pas que la nuance de couleur qui a de l’importance, mais également le contraste suffisant entre plusieurs couleurs.

Dans les zones de texte, la couleur d’arrière-plan et d’avant-plan doivent offrir un contraste suffisant. Il n’est cependant pas possible de satisfaire tout le monde. Un texte noir sur fond blanc est ce qui offre le plus de contraste. Pour éviter un effet d’éblouissement, il peut être utile d’adoucir un peu la teinte du fond. Certains mal-voyants ont besoin d’un contraste très marqué pour distinguer les éléments d’une page. Les combinaisons du style texte en blanc sur fond orange leur seront inaccessibles. D’autres individus sont éblouis par un contraste trop fort.

14.3.6 Tailles de caractères configurables

Une autre règle importante consiste à laisser l’utilisateur augmenter le corps des caractères.

Les navigateurs actuels offrent tous la possibilité d’augmenter ou de réduire la taille des caractères à l’écran. Mais cela n’est possible que si les définitions des tailles de caractères ont été faites de façon relative, et non en nombre de pixels. Vous pouvez indiquer les valeurs en pourcentage ou dans l’unité em (largeur d’un M en capitale). Ces deux unités font référence à la hauteur des caractères lorsque vous les associez à la propriété nommée font-size.

14.3.7 Mises en page à géométrie variable

Dans le domaine de la conception Web, on peut distinguer les mises en page figées et les mises en page souples.

Une mise en page souple est capable de s’adapter aux dimensions variables de la fenêtre d’affichage. Les largeurs des colonnes doivent être spécifi ées en pourcentage ou en espace em pour exploiter toute la surface d’affichage disponible. Le contenu est automatiquement remis en page en fonction des dimensions de la fenêtre.

Il s’agit a priori d’une excellente manière de procéder. À mes yeux toutefois, la largeur ne devrait
pas dépasser 1000 pixels afin d’éviter que les lignes de texte deviennent trop longues, ce qui nuit à la lisibilité.

14.3.8 Graphiques et illustrations

Les objets graphiques peuvent être implantés dans les pages Web soit au niveau du template, soit au niveau des contenus.

En ce qui concerne les templates, il faut bien préparer le logo en évitant de le concevoir avec un fond transparent. Supposons un logo avec un texte en noir sur un fond transparent.

Les mal-voyants activent souvent le mode d’affichage inversé sous Windows. Dans ce cas, le texte est en clair sur un fond sombre.

Le logo de Beez possède un arrière-plan blanc, ce qui le rend lisible même sur un fond noir (voir
Figure 14.2).

Figure 14.2 Affichage inversé.

Il va sans dire que si le texte est noir sur un fond transparent, il deviendra invisible si le fond est noir.

Évitez dans la mesure du possible d’utiliser des textes sous forme de graphiques. Prévoyez au minimum un texte de remplacement. En effet, les textes graphiques ne peuvent pas être retaillés par l’utilisateur pour offrir des caractères plus lisibles.

Mais il arrive que le client du site demande une police particulière. Si vous devez générer des textes sous forme graphique, produisez une version en gros caractères puis réduisez la taille en pourcentage em afin de laisser l’utilisateur augmenter un peu la taille du texte.

Et n’oubliez pas de toujours prévoir un texte de rechange (alternatif) suggestif.

Réfléchissez bien aux contenus de ces textes de rechange pour les graphiques. Ceux qui ne peuvent pas lire le contenu de vos graphiques n’ont que ces textes pour comprendre votre message.

Vous pouvez aisément définir vos textes de rechange au moyen de l’attribut Alt de la balise IMG.
Il n’est pas toujours simple de trouver un texte bref mais informatif.

Vous ne pouvez notamment pas fournir de texte pour une image trop vague. C’est le cas de toutes les images de décor ou des simples agréments visuels. Il faut reconnaître qu’il n’est pas facile avec de telles images de se conformer à une des premières règles d’accessibilité des sites Web.

D’un autre côté, vous pouvez rencontrer des problèmes pour trouver des textes de rechange adéquats pour les graphiques très chargés en informations, comme c’est le cas pour une image rappelant le résultat des dernières élections. Dans ce cas il faut recourir à l’attribut nommé longdesc.

Cet attribut reçoit comme valeur un chemin d’accès à un fichier externe qui contient un texte complémentaire :

<img src="ResultatsVote.jpg" width="271" height="265" alt="Résultats des
 municipales 2008" longdesc="resultatsvote.html">

Sachez cependant que longdesc n’est pas correctement exploité par tous les logiciels de lecture
écran.

14.3.9 Des boutons de navigation confortables

Les handicapés pour utiliser une souris doivent exploiter d’autres méthodes, par exemple le
clavier. L’astrophysicien anglais Steven Hawking est un des plus célèbres handicapés moteur du
monde. Il souffre d’une forme rare de sclérose latérale amyotrophique (SLA) et pilote son
fauteuil roulant avec sa bouche. Les appareillages qui ont été inventés pour satisfaire les besoins
des handicapés sont de véritables bijoux technologiques qui permettent d’atteindre un résultat
incroyable.

Pendant des années, on a considéré qu’il fallait éviter de définir des événements qui étaient contrôlables uniquement avec une souris. Ils n’étaient pas pilotables par les handicapés moteur ni par les utilisateurs d’un logiciel lecteur d’écran. Mais les choses ont évolué dans ce domaine et la simulation de la souris est devenue possible (http://assistiveware.com).

Cela dit, les personnes n’utilisant que le clavier n’ont toujours pas accès à certains événements
normalement réalisés à la souris.

Dans tous les cas, songez à concevoir des boutons de commande offrant une surface suffisante. Il
n’est pas facile de pointer sur un lien ou sur un bouton de trop petite taille, y compris pour les
personnes ne souffrant d’aucun handicap.

14.3.10 Formulaires

L’interactivité est devenue prépondérante sur le Web. Elle doit être conçue en sorte de simplifier
les communications entre le visiteur et l’éditeur du site. Le visiteur fournit souvent des données
personnelles qu’un programme recueille précieusement.

À l’heure actuelle, la technique favorite d’interaction reste le formulaire HTML.
C’est une bonne chose au niveau accessibilité. Le langage HTML fournit des possibilités minimales pour établir des interactions indépendantes de la plate-forme et de l’équipement du visiteur. Il n’y a pas à remettre en cause l’utilisation des formulaires lorsqu’ils permettent d’adapter la fonction à des handicapés qui se servent d’appareillages complémentaires.

Les principaux points à considérer lors de la conception d’un formulaire HTML accessible sont la linéarité du contenu et le regroupement.

Les éléments fieldset et label

Les concepteurs Web ont souvent tendance à implanter leurs formulaires dans des tableaux pour la mise en page. La conception des formulaires est simplifiée. Mais dans la structure qui en résulte, les relations logiques entre les contenus, notamment entre légendes et éléments de saisie, ne peuvent plus être suivies.

Pour établir une relation logique entre un élément de formulaire et sa légende, il suffit d’utiliser
l’élément nommé label du langage (X)HTML :

<label for="Prenom" title="Prenom">Prénom:</label><input id="Prenom"
 type="text" size="20" name="Prenom" value="" />

Le champ de saisie de l’exemple porte un nom unique en utilisant l’attribut universel ID. L’attribut
for de l’élément label peut ainsi y faire référence.

Lorsqu’un formulaire présente tout une série de champs de saisie similaires, comme par exemple le nom de l’époux et celui de l’épouse, groupez les sous-ensembles au moyen de fieldset, selon des frontières logiques :

<fieldset>
<legend> Données épouse</legend>
<label for="PrenomEpouse">Prénom de l’épouse :</label>
<input id="PrenomEpouse" type="text" size="20" name="Prenom" value="" />
...
</fieldset>
<fieldset>
<legend> Données époux</legend>
<label for="PrenomEpoux">Prénom de l’époux :</label>
<input id="PrenomEpoux" type="text" size="20" name="Prenom" value="" />
...

Les utilisateurs de lecteur écran Jaws peuvent profiter dans le cadre de legend d’une aide à la navigation. En effet, ils passent d’un groupe fieldset au suivant, et ainsi se font rapidement une idée globale des éléments du formulaire. Le logiciel WebFormator ne propose pas cette possibilité.

Les recommandations visant à rendre les ordinateurs utilisables par les personnes handicapées sont plus anciennes qu’Internet. Dès décembre 1982, les Nations Unies ont mis au point un programme d’action mondiale (WPA) visant à rendre accessibles les technologies modernes aux handicapés. Les multinationales telles que IBM, Microsoft et Sun ont dans les années suivantes atteint d’importants objectifs à ce niveau. En décembre 1993, à l’époque où le protocole du Web HTTP n’avait qu’à peine deux ans, l’Assemblée générale des Nations Unies a rédigé une résolution. Elle avait pour objectif de permettre un accès égal aux informations et à la communication pour les handicapés. Quelques pays ont pris en compte cette recommandation en publiant des lois et règlements appropriés. En France, c’est la Loi Handicap de février 2005 (http://www.handicap.gouv.fr/).

En 1994 a été créé le Consortium de normalisation W3C. Parmi ses nombreuses activités de standardisation, le Consortium a mis en place un comité pour établir des règles d’accessibilités du Web. Les travaux se sont terminés en 1998, ce qui a permis aux Nations Unies de les prendre en compte dans leur amendement de décembre 1998 (section 508). La publication de cette norme a rendu obligatoire pour le gouvernement des États-Unis et ses fournisseurs la mise en conformité de tous leurs produits. L’initiative d’accessibilité du Web du W3C a de son côté produit en mai 1999 un document appelé Règles d’accessibilité des contenus Web (WCAG 1.0). Ce document a été repris sans retouches importantes par le gouvernement allemand dans son décret BITV (Barrierefreie Informationstechnologie Verordnung). Il a suivi la loi sur l’égalité des personnes handicapées de 2002 et bien d’autres règlements parus entretemps dans d’autres pays. Après l’an 2000, d’autres règles ont été définies, par exemple en ce qui concerne la conception accessible des navigateurs Web et des autres logiciels d’agent utilisateur (UAAG) ou de création (Authoring, ATAG).

Certaines préconisations du document original WCAG1 de 1998 sont devenues obsolètes de nos jours, en raison des évolutions technologiques. Nous ne nous en servons plus dans nos travaux actuels.

Un document révisé WCAG2, qui aurait dû paraître dès 2001, est en cours de validation. Une version préliminaire en été publiée courant 2007 et son contenu est actuellement en débat.

L’expert en accessibilité canadien Joe Clark avait proposé en juin 2007 l’Errata Samurai de WCAG dans lequel il faisait des propositions de révision drastique du document original.

Malgré leurs faiblesses actuelles, les documents basés sur WCAG1 restent pour l’heure les seules bases stables pour guider la création des pages Web accessibles. Nous conseillons de ce fait à tous les intéressés de s’en tenir à ces règles, sauf exception justifi ée. Surveillez également les discussions souvent publiques qui vont mener à la publication de la version 2.

Le document WCAG1 réunit 14 recommandations, chacune articulée en plusieurs points. La conformité à ce document compte trois niveaux : objectifs obligatoires, objectifs conseillés et objectifs complémentaires. Selon le niveau de conformité d’un site Web, il obtient la note A, AA ou AAA respectivement (niveaux croissants). Le décret allemand BITV regroupe les deux premiers niveaux, ce qui ramène à deux les niveaux à distinguer : ce qui est obligatoire et ce qui est facultatif. Les sites ne peuvent être donc que de niveau AA ou AAA. Autrement dit, les objectifs du BITV sont en théorie plus rigoureux que ceux du document WCAG.

Pour beaucoup, Internet s’est intégré à la vie quotidienne. Au bout de la souris, se trouve une masse d’informations que l’on recueille facilement : promotions du supermarché du coin, heures d’ouverture de la mairie, pages jaunes, dictionnaires, etc. Tout est toujours disponible. Finies les fastidieuses recherches dans les bibliothèques ou les annuaires. Il suffit d’aller voir sur le Web.

Mais tout le monde ne profite pas de ce fantastique progrès. Les handicapés physiques ou mentaux ne participent pas totalement à la vie sociale. En théorie, ils devraient réduire cette mise à l’écart grâce aux techniques modernes de communication. Mais ils butent sur des barrières qui les empêchent d’accéder aux informations ou de profiter des offres. Pourtant la plupart de ces barrières peuvent être levées, à condition de structurer la présentation des informations en conséquence.

Les responsables de sites de commerce électronique et de sites bancaires devraient être les premiers à se soucier de ce pourcentage non négligeable de leur clientèle éventuelle. Presque 10 % de la population allemande (ou française) souffre d’un handicap physique qui leur rend plus difficile l’accès aux informations sur Internet.

La conception Web accessible a pour but d’organiser les contenus et l’interface utilisateur pour rendre les contenus accessibles à tous les groupes d’utilisateurs et sur tous les équipements.

On résume communément la conception Web accessible aux précautions qu’il faut prendre pour
rendre Internet accessible aux aveugles. Cette définition ne fait pas le tour de la question, loin de là.

Je me suis d’ailleurs souvent demandée d’où venait cette simplifi cation. Peut-être parce que l’écran informatique est devenu le symbole de l’ordinateur ? Celui qui ne voit pas, ne peut pas s’en servir. Je fais régulièrement ce constat : des non-voyants s’en sortent parfois mieux que d’autres handicapés devant une page Internet non conçue à leur égard.

On considère comme non-voyant ou mal-voyant une personne dont la vision se réduit à quelques
pourcentages de la valeur moyenne. Rien qu’en Allemagne, il y en a entre 150 000 et 200 000.
Certains utilisent un ordinateur en augmentant la taille des caractères et en accentuant les contrastes des couleurs des textes, mais cela reste un décryptage. D’autres doivent se rabattre sur une lecture vocale des données affichées ou un équipement de lecture en braille.

Le pourcentage de personnes ayant des difficultés de vision est encore plus important.

Environ un quart de la population en âge de travailler souffre d’un problème de vision, et le temps
n’arrange pas les choses. Certains problèmes se corrigent grâce à des verres, mais pas tous. Des
pathologies oculaires peuvent être réparées par la chirurgie, ou du moins réduites. D’autres, comme la rétinopathie pigmenteuse ou la rétinopathie diabétique, entraînent une perte progressive et totale de la vision. Le syndrome de vision en tunnel réduit énormément le champ de vision. Tenez une pièce d’un euro au bout du bras et imaginez que le diamètre de la pièce soit votre champ de vision.

Environ 10 % de la population masculine souffre d’une certaine insensibilité aux couleurs. Le daltonisme les empêche de distinguer les tons rouges des tons verts, en général. En revanche, la confusion des autres couleurs ou l’insensibilité totale aux couleurs sont très rares chez les femmes, le daltonisme les touche moins aussi.

Un autre groupe rassemble les utilisateurs qui ne peuvent saisir les objets. Tout le monde ne peut pas manipuler une souris ou un clavier normal.

Les causes sont multiples : bras et doigts paralysés, ou difficiles à contrôler, amputation ou paralysie de la totalité du tronc ou d’un côté suite à un infarctus. Mais tant qu’une personne reste capable de communiquer, même via un signal binaire constitué de 0 et de 1, si elle a de l’énergie, l’envie d’apprendre et un logiciel approprié, elle pourra piloter toutes les fonctions d’un ordinateur.

Il y a par ailleurs presque 100 000 personnes en Allemagne qui connaissent des difficultés d’audition. Quelques milliers d’entre elles en souffrent depuis l’enfance. À un point tel qu’elles ont eu beaucoup de difficultés à apprendre à lire et à écrire, et n’ont atteint qu’un niveau scolaire équivalent au CM2. Cela pour souligner l’importance de la formulation des textes dans les logiciels.

Pour communiquer entre elles, mais aussi pour trouver des informations dans le monde qui les
entourent, ces personnes utilisent la langue des signes française (LSF).

Plus Internet s’immisce dans tous les domaines de la vie, plus les handicaps de situation prennent de l’importance : accès ralentis à Internet depuis un hôtel, conditions d’éclairage insuffisantes dans un moyen de transport, impossibilité d’utiliser le son au travail, etc.

Tout le monde tirera profit de sites Web plus accessibles. Il ne s’agit pas pour autant de chercher à satisfaire à toutes les règles édictées, comme le font les sites offi ciels des établissements publics. Le moindre effort en direction de l’accessibilité renforce le confort d’utilisation des pages Web.

Le succès qu’a rencontré Joomla! en fait un vecteur sérieux pour propager ces concepts. Grâce au template standard Beez, il est devenu assez simple de créer des pages accessibles au plus grand nombre.

par Angie Radtke, conceptrice du modèle Beez

Quand Hagen Graf m’a demandé de rédiger ce chapitre, je me suis sentie un peu mal à l’aise au
départ, car il ne me restait environ qu’une semaine.

À dire vrai, je partais avec un peu d’avance. La plupart des sujets que j’aborde dans ce chapitre ont déjà été décrits en détail dans mon livre sur La conception Web et l’accessibilité cosigné avec Michael Charlier (pas encore traduit en français).

Mais ici, je dois me concentrer sur l’essentiel. Je vais donc présenter les principes de la conception Web accessible. Puis je passerai en revue la manière dont ces concepts ont été mis en pratique dans le template standard Beez, qui permet de créer des pages Web accessibles avec Joomla!.

Jusqu’à sa version 1.0.3, l’accessibilité était quasiment hors de portée de Joomla!. L’opération n’était vraiment pas simple. Avec la version 1.5 et le template Beez, il n’y a plus d’obstacle à la création d’un site Web dont les contenus sont accessibles à tous les individus.