Wikipédia:Atelier accessibilité/Bonnes pratiques

Un article de Wikipédia, l'encyclopédie libre.

Les bonnes pratiques ci-dessous n'ont pas valeur de règles ou de recommandations au sein de Wikipédia. Etablies au sens de l'atelier accessibilité, elles sont proposées aux contributeurs comme un guide pour :

  • la rédaction au quotidien de contenus plus accessibles.
  • les contributeurs intervenants sur les modèles, les portails.
  • les administrateurs intervenants notamment sur common.css, common.js, voires certains Messages système.


Ces bonnes pratiques sont en cours d'élaboration. N'hésitez pas à les améliorer ni à les commenter en page de discussion


Atelier accessibilité
Coordination de l'atelier

Sommaire

[modifier] Structure des articles

[modifier] Infobox, bandeaux, etc.

[modifier] Titres de section

  • Niveau de priorité: moyen.
  • Faisabilité: facile.

Les titres de section améliorent l'accessibilité du contenu[WCAG 1] : ils permettent à tous les utilisateurs de recevoir et de comprendre la structure globale de la page. Les utilisateurs de lecteurs d'écran ou de loupe d'écran les utilisent pour explorer celle-ci et y naviguer rapidement.

Ils doivent résumer rapidement le contenu de la section. Il est déconseillé pour l'accessibilité de remplacer un niveau de titrage par un paragraphe mis en gras ou par une liste de définition.

Bons et mauvais exemples de titrage de section
Non accessible Accessible
=== titre ===
;Sous titre
:Contenu
=== titre ===
==== sous-titre ====
Contenu
=== titre ===
''' Sous-titre''' Contenu

[modifier] Texte

[modifier] Changements de langue

Niveau de priorité: élevée. faisabilité: facile.

Les lecteurs d'écran ont besoin d'être renseignés sur la langue du contenu pour adopter une prononciation adaptée[WCAG 2].

Il est conseillé d'indiquer les changements de langue à l'aide du modèle {{lang}}.

Bons et mauvais exemples de changements de langue
Non accessible Accessible
Les Directives pour l'accessibilité du contenu web
(Web Content Accessibility Guidelines)
ont été publiées en 1999 par la 
[[Web accessibility Initiative]]
du [[W3C]].
Les Directives pour l'accessibilité du contenu web
({{lang|en|Web Content Accessibility Guidelines}})
ont été publiées en 1999 par la
[[Web accessibility Initiative|
{{lang|en|Web accessibility Initiative}}]]
du [[W3C]].

[modifier] Acronymes et abréviations

Niveau de priorité: moyen. faisabilité: moyenne.

Les directives pour l'accessibilité des contenus recommandent d'expliciter le sens des sigles et d'apporter plus généralement les informations facilitant le compréhension des contenus. Cependant:

  • Mediawiki n'implémente cependant pas les éléments HTML abbr et acronym utilisés pour baliser et expliciter abréviations et acronymes
  • Ces éléments ne sont pas le seul moyen disponible pour expliciter les sigles, du point de l'accessibilité.
  • Il n'est pas nécessaire, pour l'accessibilité, d'expliciter chaque occurence d'un même sigle quand il est présent plusieurs fois dans une même page: seule la première occurence est recommandée.

On pourra donc selon les cas, et dans la mesure du possible:

  • Adopter une formulation directement explicite, du type: « Les Directives pour l'accessibilité des contenus Web (WCAG)... » ou « WCAG (Directives pour l'accessibilité des contenus Web) »
  • Recourir à un lien interne qui donne accès à la signification détaillée du sigle: « la WAI du W3C... » (le fait d'utiliser un lien permet également de profiter du title de celui-ci, généralement pertinent pour les articles liés aux sigles).
  • Ne pas expliciter le sigle, s'il est répété et que sa première occurence est explicite

Il faut noter que les contournements à l'aide d'un élément span title="..." utilisés par exemple dans les modèles d'icônes de langues ou d'extension de fichier ne sont pas pertinents du point de vue WCAG.

[modifier] Liens

Niveau de priorité: élevé. faisabilité: faible.

Des liens accessibles ont des libellés sans ambiguïtés, qui permettent à tous les utilisateurs d'identifier leur cible et le résultat de leur action s'ils les suivent. Ceci prend une forme particulière pour les utilisateurs de lecteurs d'écran, qui sont amenés à entendre ces libellés isolés de leur contexte[WCAG 3].

Cependant, le rendu des liens est également soumis à la présence de l'attribut HTML title du lien: dans une configuration courante de lecteur d'écran, le contenu de cet attribut remplace celui du libellé de lien s'il est plus long. Or, mediawiki produit automatiquement cet attribut, de manière généralement non pertinente pour l'accessibilité. Les liens externes, par exemple, sont systématiquement doté d'un attribut title reproduisant l'url du lien, ce qui n'est pas une information aisément compréhensible. De même, les liens internes sont systématiquement dotés d'un attribut title reproduisant le titre de la page cible, ce qui ne donne pas un résultat toujorus compréhensible lorsque le lien est lu dans son contexte.

La maîtrise de l'accessibilité des liens dans Wikipédia est donc réduite. On s'efforcera cependant de rédiger des libellés explicites et complets, qui permettent à eux seuls d'identifier la page cible.

Bons et mauvais exemples de liens
Eviter Préférer
[[WP:AG]]

[[WP:AG|ici]]

[[WP:AG|Atelier graphique]]

[[Discussion Utilisateur:Lgd|<font size="3">✍</font>]]
http://www.la-grange.net/w3c/

[http://www.la-grange.net/w3c/]

[http://www.la-grange.net/w3c/ ici]
[http://www.la-grange.net/w3c/
Traduction en français des recommandations du W3C] 

On évitera également autant que possible les liens au libellé composé de caractères qui ne prennent leur sens que graphiquement, comme [[Discussion Utilisateur:Lgd|<font size="3">✍</font>]] (résultat: ).

[modifier] format de fichier et mention de la langue dans les liens externes

Pour les liens externes, deux informations supplémentaires peuvent être nécessaires dans certains cas:

  • la mention du format d'un document externe, lorsque le lien ne mène pas à une page HTML
  • la mention de la langue de la page cible quand le lien mène à une page qui n'est pas en français

Ces informations relèvent cependant d'un point de controle WCAG de niveau AAA, ce qui leur confère un niveau de priorité moyen à faible[WCAG 4]. D'autant que les usages en vigueur dans Wikipédia prévoient déjà la mention de ces informations dans le contexte des liens.

Les modèles d'extension de fichier sont fréquemment utilisés pour indiquer le format: {{pdf}} faire apparaître la mention [pdf] avant le lien. Mais cela ne suffit pas à rendre le lien explicite hors contexte. Idéalement, il serait nécessaire de préciser le format directement dans le libellé. Par exemple:

* [http://example.org/foo.pdf Titre du document (PDF)]

Qui donne:

De la même manière, les modèles d'icônes de langues sont utilisés pour indiquer la langue d'une page externe : {{en}} faire apparaître la mention (en) avant le lien. Du point de vue de l'accessibilité, cette mention n'est pas suffisante pour rendre le libellé explicite hors contexte. En revanche, il suffit que le libellé soit directement rédigé dans la langue concernée, et que le modèle {{lang}} soit utilisé dans le lien, pour que cette information soit parfaitement accessible:

* {{en}} [http://www.w3.org/TR/WAI-WEBCONTENT/ {{lang|en|Web Content Accessibility Guidelines 1.0}}]

Qui donne:

[modifier] Couleurs

[modifier] Utilisation de la couleur

Niveau de priorité: élevée. faisabilité: facile.

Lorsqu'une information n'est indiquée qu'à l'aide de changements de couleur, elle ne sera pas accessible à différents types d'utilisateurs : utilisateurs de lecteurs d'écran, de loupes d'écran modifiant les contrastes et les couleurs, ou encore utilisateurs ayant coché l'option d'accessibilité « Ignorer les couleurs... » dans leur navigateur[WCAG 5].

L'information doit toujours être portée également par un autre moyen, indépendant de la couleur: mise en gras ou en italique, soulignement, texte supplémentaire, symbole, etc.

Bons et mauvais exemples d'utilisation de la couleur
Non accessible Accessible
...
...

[modifier] Choix de couleurs et contrastes

Niveau de priorité: moyen faisabilité: facile.

Le niveau de contraste des couleurs d'avant-plan et d'arrière-plan peut également être une source de difficulté pour les utilisateurs handicapés visuels, daltoniens, etc[WCAG 6].

Il est recommandé de conserver un ratio de contraste de couleurs d'avant-plan et d'arrière-plan au moins supérieur à 4, tel qu'il peut être mesuré avec le Colour Contrast Analyser. Ceci ne s'applique pas aux éléments purement décoratifs (bordures, images ne portant pas à elles seules une information nécessaire à la compréhension de la page, etc.)

Bons et mauvais exemples d'utilisation de la couleur
Non accessible Accessible
...
...

[modifier] Listes

Niveau de priorité: moyen faisabilité: facile.

Les énumérations de contenus nécessitent une structure spécifique pour être identifiables et aisément manipulables par les logiciels d'aide aux utilisateurs handicapés[WCAG 7].

Il est recommandé d'utiliser la syntaxe wiki * pour les listes à puces et # pour les listes numérotés, et d'éviter dans tous les cas les listes faites à l'aide de tirets, d'icônes, de retours à la ligne, etc.

Bons et mauvais exemples de listes
Non accessible Accessible
- item 1<br>
- item 2<br>
- item 3<br>
* item 1
* item 2
* item 3
1. item<br>
2. item<br>
3. item<br>
# item 1
# item 2
# item 3
1998 item<br>
1999 item<br>
2000 item<br>
<ol start="1998">
<li>item
<li>item
<li>item
</ol>

Les listes non structurées faites au fil du texte à l'aide de séparateurs « | » (pipe) ou « • » (boulet) ne sont pas optimales, mais peuvent être admises quand le nombre d'élément est réduit (Une demi-douzaine au plus, par exemple). L'utilisation d'une liste structurée et mise en forme via CSS permet d'obtenir le même résultat visuel de manière plus accessible.

On évitera donc si possible:

[[lien 1]] • [[lien 2]] • [[lien 3]] • [[lien 4]] • [[lien 5]] • [[lien 6]] • [[lien 7]] • [[lien 8]] • [[lien 9]] • [[lien 10]]

[modifier] Tableaux

[modifier] Tableaux de données

Les tableaux de données organisent l'information en cellules logiquement rattachées à des en-têtes de ligne et/ou de colonnes qui permettent d'en comprendre le sens. Etant un mode d'organisation de l'information exclusivement visuel, ils nécessitent des mesures particulières pour pouvoir être compris quand ils sont restitués par un lecteur d'écran.

[modifier] Cas général

Niveau de priorité: élevée. faisabilité: facile.

Les en-têtes de ligne et de colonne doivent toujours être indiqués à l'aide de la syntaxe ! (ou <th>). Les en-têtes de colonne sont indentifiés par l'attribut scope=col, et les en-têtes de ligne par scope=row[WCAG 8], quand ils s'appliquent à la totalité d'une ligne ou d'une colonne. Voir l'aide sur les tableaux qui fournit des modèles-type à copier/coller

Bons et mauvais exemples d'utilisation des en-têtes
Non accessible Accessible
{| 
|
| '''En-tête colonne 2'''
| '''En-tête colonne 3'''
|-
| '''En-tête ligne 1'''
| Contenu
| Contenu
|}
{| 
|
! scope=col | En-tête colonne 2
! scope=col | En-tête colonne 3
|-
! scope=row | En-tête ligne 1
| Contenu
| Contenu
|}

Il est également possible d'améliorer l'accessibilité d'un tableau de donnée en lui donnant un titre explicite, s'il n'est pas immédiatement précédé par un bref paragraphe ou un titre de section jouant le même rôle. Le titre de tableau est créé à l'aide de la syntaxe |+[WCAG 9] (niveau de priorité: moyen).

L'imbrication d'un tableau de données à l'intérieur d'un autre tableau de données peut créer un contenu qui sera très difficilement compréhensible dans un lecteur d'écran : elle doit être évitée autant que possible.

[modifier] Cas particulier

Niveau de priorité: élevée. faisabilité: difficile

Si des en-têtes de ligne ou de colonne ne s'appliquent qu'à une partie des cellules de la ligne ou de la colonne, l'attribut scope ne convient pas. Un code plus complexe est nécessaire, combinant:

  • l'attribut id de l'en-tête ! (ou <th>). Par exemple, id="foo1" pour celui du premier bloc de lignes.
  • l'attribut headers de chaque cellule de donnée à laquelle s'applique l'en-tête : headers="foo1" pour chaque cellule rattachée à l'en-tête id="foo1".

En effet, dans ce cas, chaque cellule doit être individuellement rattachée à l'en-tête de son bloc.

Exemple d'utilisation de id et headers, tableau à simple entrée
En-tête du premier bloc de lignes, codé ! id="entete_a"
contenu codé | headers="entete_a"
contenu codé | headers="entete_a"
contenu codé | headers="entete_a"
En-tête du deuxième bloc de lignes, codé ! id="entete_b"
contenu codé | headers="entete_b"
contenu codé | headers="entete_b"
contenu codé | headers="entete_b"

Cette syntaxe peut se combiner avec l'utilisation de scope pour d'autres en-têtes ne posant ce problème :

Exemple d'utilisation de id et headers, tableau à doubles entrées
En-tête du premier bloc de lignes, codé ! id="entete_1"
en-tête de ligne codé ! scope=row headers="entete_1" contenu codé | headers="entete_1"
en-tête de ligne codé ! scope=row headers="entete_1" contenu codé | headers="entete_1"
en-tête de ligne codé ! scope=row headers="entete_1" contenu codé | headers="entete_1"
En-tête du deuxième bloc de lignes, codé ! id="entete_2"
en-tête de ligne codé ! scope=row headers="entete_2" contenu codé | headers="entete_2"
en-tête de ligne codé ! scope=row headers="entete_2" contenu codé | headers="entete_2"
en-tête de ligne codé ! scope=row headers="entete_2" contenu codé | headers="entete_2"

Si on utilisait scope=col pour les deux en-têtes de bloc de ligne, un lecteur d'écran associerait les deux en-têtes en même temps à chaque cellule du deuxième bloc, ce qui ne correspond pas au sens du tableau.

Attention: chaque identifiant id doivent être unique dans une page Web. Il faut donc anticiper la présence éventuelle de plusieurs tableaux du même type dans la même page.

[modifier] Tableaux de mise en forme

Niveau de priorité: moyen faisabilité: facile.

Des tableaux peuvent aussi être utilisés de manière accessible pour mettre en forme le contenu. Ils doivent alors répondre à deux contraintes:

  • se différencier des tableaux de données en n'utilisant aucune syntaxe propre à ces derniers: pas d'en-tête de ligne ou de colonnes, pas de titre de tableau[WCAG 10].
  • permettre à leur contenu de conserver tout son sens quand il est perçu sans le support visuel et sans l'ordre de lecture fourni par les lignes et les colonnes (de manière linéaire)[WCAG 11].
Bons et mauvais exemples d'utilisation d'un tableau de mise en forme
Non accessible Accessible
{| 
! Ceci est en gras
| Suite du contenu
|}
{| 
|''' Ceci est en gras'''
| Suite du contenu
|}
{|
|-
|[[Image:...]]
|[[Image: ...]]
|-
|légende de l'image 1
|légende de l'image 2
|}
{|
|[[Image:...]]<br />légende de l'image 1
|[[Image: ...]]<br />légende de l'image 2
|}

[modifier] Images

[modifier] Images portant une information

Niveau de priorité: élevé. faisabilité: faible.

Une image peut porter une information qui n'est pas présente par ailleurs dans le contenu de la page. Pour être perceptible par les utilisateurs de lecteur d'écran, de navigateur ne restituant pas les images, etc. cette information doit être également indiquée de manière textuelle. C'est le rôle de l'alternative textuelle de l'image (attribut HTML alt) et de sa description étendue (attribut HTML longdesc)[WCAG 12].

Dans Wikipédia, l'alternative textuelle est produite automatiquement et reproduit la légende visible de l'image, avec la syntaxe [[Image:Nom de l'image|thumb|Légende]] : il n'est pas possible d'indiquer une alternative textuelle décrivant l'information apportée par l'image, qui puisse être différente de la légende affichée sous l'image. Les alternatives textuelles d'images ne peuvent donc pas être réellement utilisées pour l'accessibilité.

Mediawiki ne permet pas non plus de produire un attribut longdesc associé à l'image et indiquant où se trouve sa description textuelle complète.

L'accessibilité des images de Wikipédia est donc nécessairement réduite. Pour y remédier au moins partiellement:

  • on peut s'efforcer de reproduire l'information principale apportée par une image dans la légende, ou dans le texte de l'article.
  • on peut compléter la page de chaque image avec sa propre description détaillée.
Bons et mauvais exemples d'images de contenu
Eviter Préférer
[[Image:Croissance population Paris.PNG]]

[[Image:Croissance population Paris.PNG|]]

[[Image:Croissance population Paris.PNG|thumb|]]

[[Image:Croissance population Paris.PNG|thumb|
Croissance de la population parisienne
depuis le premier recensement en 1801]]
[[Image:Croissance population Paris.PNG|thumb|
La population parisienne intra-muros croît
de 500 000 habitants en 1801 à 2 142 800 en 2004]]

[[Image:Croissance population Paris.PNG|Page du graphique
Croissance population Paris.PNG]]

[modifier] Images décoratives

Niveau de priorité: élevé. faisabilité: faible.

Théoriquement, une image décorative, qui ne porte pas d'information nécessaire à la compréhension de la page, devrait avoir une légende (alternative textuelle) vide, afin d'être ignorée notamment par les synthèses vocales[WCAG 13].

Mais toute image placée dans une page Wikipédia à l'aide de la syntaxe wiki est en fait une image-lien (vers sa page commons en général). or, les lecteurs d'écran n'ignorent jamais les images liens, même si leur alternative textuelle est vide. Le plus souvent, ils lisent alors tout ou partie de l'URL de l'image, ce qui n'est pratiquement pas compréhensible pour l'utilisateur.

On ne peut donc pas mettre en pratique sur Wikipédia la règle habituelle d'accessibilité consistant à donner une alternative textuelle vide à une image décorative. On s'efforcera d'indiquer une alternative aussi explicite que possible, qui indique que le lien a pour cible la page de l'image.

Autant que possible, on privilégiera également le passage par une classe CSS ajoutée à common.css pour gérer ces images décoratives sous forme d'arrière-plan CSS (background-image) qui ne posent pas ce type de problèmes d'accessibilité.

Bons et mauvais exemples d'images décoratives
Non accessible Accessible
[[Image:Exemple.png|]]

[[Image:Exemple.png|thumb|]]
[[Image:Exemple.png|Page de l'image exemple.png]]
<div class"bandeau">
[[Image:icone1.png|]]
Contenu textuel du bandeau
</div>
<div class="bandeau icone1">
Contenu textuel du bandeau
</div>

Dans MediaWiki:Common.css :

.bandeau.icone1 {
background: url(...icone1.png) no-repeat left center;
padding-left: ...px;
}

[modifier] Combinaisons d'images via CSS

Niveau de priorité: élevé. faisabilité: ?

Pour économiser la création de séries d'images exploitant toutes un fond identique, il peut être tentant de recourir aux styles CSS et de superposer deux images (un fond de carte et un point de localisation, par exemple). L'information résultant de la combinaison de ces deux images ne sera cependant perceptible que pour une partie des utilisateurs, qui ont accès au rendu visuel CSS[WCAG 14].

Cette pratique est donc autant que possible déconseillée.

[modifier] Images cliquables

Niveau de priorité: élevé. faisabilité: facile.

L'extension ImageMap permet de créer des cartes et autres images cliquables respectant les contraintes d'accessibilité:

  • l'image peut avoir son alternative textuelle globale, qui devrait être rédigée sous la forme « carte de... » ou « organigramme de... » par exemple.
  • l'extension génère automatiquement les alternatives textuelles de chaque zone cliquable, à l'aide du lien vers la page concernée.

C'est également cette extension qui est utilisée par le modèle {{Lien sur icône}} pour créer une icône-lien accessible.

Il faut en revanche proscrire les pseudos-images MAP réalisées en positionnant des liens HTML sur un fond de carte, le résultat n'étant pas accessible sans le support de CSS.

[modifier] frise chronologiques

Niveau de priorité: élevé. faisabilité: faible.

L'extension permettant de créer des frises chronologiques ne tenant pas compte des contraintes d'accessibilité et ne permettant pas de donner une alternative textuelle à ces images, l'utilisation de <timeline> est déconseillée.

A réévaluer, le résultat dépend de la manière dont l'extension est utilisée :

  • le résultat est une image MAP potentiellement accessible si les légendes sont des liens.
  • mais l'extension ne génère aucune alternative textuelle lorsque les légendes sont du texte brut.

[modifier] formules mathématiques

Niveau de priorité: élevé. faisabilité: faible.

[modifier] Styles CSS

[modifier] Taille des caractères en pixels

Niveau de priorité: moyen. faisabilité: facile.

L'unité utilisée pour indiquer la taille du texte peut avoir des conséquences importantes pour l'accessibilité: certaines unités ne permettent en effet pas à l'utilisateur d'agrandir ou de réduire la taille des caractères affichés dans son navigateur, pour l'adapter à ses besoins. C'est le cas des unités dites absolues et, de manière plus particulière, du pixel pour Internet Explorer Windows[WCAG 15].

Les tailles de caractères ne doivent donc pas être indiquées dans les unités suivantes: pt (point), pc (pica), cm (centimètre), mm (millimètre), in (pouce) et px (pixel).

[modifier] Pseudo contenu CSS

Le rôle fondamental des styles CSS est de permettre la séparation du contenu structuré et de sa présentation : les styles CSS ne portent aucune information de contenu, et ne servent qu'à mettre en forme ce dernier.

Ceci contribue de manière essentielle à l'accessibilité : cette séparation permet en effet aux navigateurs et aux aides techniques d'adapter aisément la mise en forme du contenu aux besoins de l'utilisateur.

Cependant, il existe plusieurs dérives possibles de l'utilisation des styles CSS, qui vont totalement à l'encontre de ce principe de séparation, en générant via les styles CSS un « pseudo-contenu » dépendant en tout ou partie de la mise en forme. C'est le cas notamment:

  • des légences de cartes, de tableaux ou de diagrammes où les couleurs ou icônes sont des arrières-plans (background) CSS.
  • des cartes de géolocalisation où une image ou un point sont positionnés via CSS sur un fond de carte vierge

La consultation d'un article avec ou sans activation des styles CSS ne doit entraîner aucune perte d'information[WCAG 16].

Ces détournements de CSS devraient être remplacés par des contenus HTML indépendants de la mise en forme, c'est à dire dans la plupart des cas des images complètes. Le niveau de faisabilité est variable selon le nombre d'images concernées (il est par exemple faible dans le cas de la géolocalisation, en l'absence d'une extension dédiée permettant de générer automatiquement les très nombreuses images de remplacement nécessaires).

[modifier] Notes et références

Les références suivantes mènent à la version originale en anglais des Directives pour l'accessibilité des contenus Web, version 1.0:

  1. (en) WCAG1.0, point de contrôle 3.5, niveau d'accessibilité AA
  2. (en) WCAG1.0, point de contrôle 4.1, niveau d'accessibilité A
  3. (en) WCAG1.0, point de contrôle 13.1, niveau d'accessibilité AA
  4. (en) WCAG1.0, point de contrôle 11.3, niveau d'accessibilité AAA
  5. (en) WCAG1.0, point de contrôle 2.1, niveau d'accessibilité A
  6. (en) WCAG1.0, point de contrôle 2.2, niveau d'accessibilité AA pour les images, AAA pour le texte
  7. (en) WCAG1.0, point de contrôle 3.6, niveau d'accessibilité AA
  8. (en) WCAG1.0, point de contrôle 5.1, niveau d'accessibilité A
  9. (en) WCAG1.0, point de contrôle 5.5, niveau d'accessibilité AAA
  10. (en) WCAG1.0, point de contrôle 5.4, niveau d'accessibilité AA
  11. (en) WCAG1.0, point de contrôle 5.3, niveau d'accessibilité AA
  12. (en) WCAG1.0, point de contrôle 1.1, niveau d'accessibilité A
  13. (en) WCAG1.0, point de contrôle 1.1, niveau d'accessibilité A
  14. (en) WCAG1.0, point de contrôle 6.1, niveau d'accessibilité A
  15. (en) WCAG1.0, point de contrôle 3.4, niveau d'accessibilité AA
  16. (en) WCAG1.0, point de contrôle 6.1, niveau d'accessibilité A