Wikipédia:Atelier accessibilité/Bonnes pratiques

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

Vous êtes ici : Accueil > Contribuer à Wikipédia > Ateliers > Atelier accessibilité > Wikipédia:Atelier accessibilité/Bonnes pratiques

Les bonnes pratiques ci-dessous sont issues des Directives d'accessibilité des contenus Web du W3C, qui sont la norme internationale dans ce domaine (Leur référence est la norme Web Content Accessibility Guidelines (WCAG) 2.0).

Elles sont proposées 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, voire certains Messages système.

Chaque bonne pratique est marquée d'un degré de priorité en fonction du niveau d'accessibilité WCAG correspondant:

  • priorité élevée : le niveau A d'accessibilité, c'est à dire ce qui « doit être fait »
  • priorité moyenne : le niveau AA d'accessibilité, c'est à dire ce qui « devrait être fait ». C'est le niveau de référence de tout projet Web par défaut.
  • priorité faible : le niveau AAA d'accessibilité, c'est à dire ce qui « pourrait être fait » dans la mesure du possible, en fonction du type de contenu.
Atelier accessibilité
Coordination de l'atelier

Sommaire

[modifier] Structure des articles

[modifier] Titres de section

Bonne pratique : utiliser systématiquement les titres de section (== etc.) et ne pas créer de pseudos-titres à l'aide d'une mise en gras ('''), d'une liste de définition (;), d'un élément div mis en forme (<div style="font-weight: bold">), etc.

  • priorité : élevée
  • difficulté : facile

Les titres de section permettent à tous les utilisateurs de percevoir 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 avec concision le contenu de la section[WCAG-TECH 1].

Bons et mauvais exemples de titrage de section
Non accessible Accessible
=== titre ===
;Sous titre
:Contenu
=== titre ===
==== sous-titre ====
Contenu
=== titre ===
<h4 style="font-size:1em;border:0">sous-titre</h4>
Contenu
=== titre ===
''' Sous-titre''' Contenu


[modifier] Position des palettes de navigation

Bonne pratique : placer systématiquement les palettes de navigation à la même position dans tous les articles.

  • priorité : moyenne
  • difficulté : facile

La position des éléments de navigation doit être prévisible pour les utilisateurs : il faut donc éviter de placer les palettes de navigation à des endroits différents selon les articles (parfois en début de contenu, parfois en fin de contenu). Quelque-soit l'emplacement retenu (il est indifférent pour l'accessibilité), celui-ci doit être constant[WCAG-TECH 2].

Remarque: ce n'est pas la position à l'écran qui compte en matière d'accessibilité (à droite ou à gauche par exemple) mais la position dans l'ordre du code HTML (en début ou en fin du code de la zone de contenu de la page)

[modifier] Texte des articles

[modifier] Changements de langue

Bonne pratique : renseigner systématiquement les changements de langue du texte à l'aide des modèles {{lang}} ou {{Langue du titre}}, ou encore de l'attribut lang en syntaxe wiki HTML, excepté pour un nom propre, pour un terme technique ou pour un mot ou expression faisant partie du français courant.

  • priorité : moyenne.
  • difficulté : facile.

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

Attention: la langue doit être indiquée uniquement à l'aide d'un code valide, c'est à dire présent dans la liste des codes de langue établie par l'IANA. Par conséquent:

  • Il ne faut pas se fier aux éventuelles indications de code ISO-639 données dans les articles de Wikipédia sur les langues : seuls certains codes ISO-639 sont pertinents pour mentionner un changement de langue d'un contenu Web. Le code à utiliser peut être vérifié à l'aide de cet outil de recherche. Il permet, par exemple, de s'assurer que le code correct pour l'occitan est oc et non oci.
  • Pour les langues absentes de la liste de l'IANA (le normand ou le Monégasque par exemple), le changement de langue ne doit pas être indiqué.

Dans les modèles, utiliser l'attribut lang et non xml:lang : Mediawiki ignore ce dernier en syntaxe wiki, mais génère les deux attributs attendus dans le code final XHTML.

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] Termes techniques et usages rares d'un terme

Bonne pratique : expliciter la signification des termes techniques ou employés dans un sens rare, ou bien fournir un lien vers l'article correspondant.

  • priorité : faible
  • difficulté : facile

Les directives pour l'accessibilité des contenus recommandent d'expliciter le sens des « mots ou expressions utilisés de manière inhabituelle ou de façon limitée » et d'apporter plus généralement les informations facilitant le compréhension des contenus[WCAG-TECH 4].

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

  • Recourir à un lien interne qui donne accès à l'article consacré au terme concerné.
  • Fournir une définition du terme dans son contexte
Bons et mauvais exemples de termes techniques
Non accessible Accessible
Une base de données relationnelle ou objet...
une [[base de données]]
[[Base de données relationnelle|relationnelle]]
ou [[Base de données orientée objet|objet]]...
Un agrégateur de contenu...
Un agrégateur de contenu
(logiciel qui permet de suivre des
[[Syndication de contenu|fils de syndication]])...

[modifier] Acronymes et abréviations

Bonne pratique : expliciter la signification des sigles lors de leur première apparition dans le texte.

  • priorité : faible
  • difficulté : facile

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. Il n'est pas nécessaire d'expliciter chaque occurrence d'un même sigle quand il est présent plusieurs fois dans une même page : seule la première occurrence est nécessaire[WCAG-TECH 5].

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 occurrence est explicite
Bons et mauvais exemples de sigles
Non accessible Accessible
La SNCF
La SNCF (Société nationale des chemins de fer français)

La Société nationale des chemins de fer français (SNCF)
La [[SNCF]]
La [[Société nationale des chemins de fer français|SNCF]]

[modifier] Attribut HTML title

Bonne pratique : ne pas utiliser l'attribut HTML title d'un élément du type span ou div pour donner une information nécessaire à la compréhension du contenu.

  • priorité : faible
  • difficulté : facile

Mediawiki permet de créer des contenus du type <span title="en anglais">'''(en)'''</span> qui donnent (en). Mais l'information portée par un attribut HTML title n'est perceptible pour tous les utilisateurs que sur certains éléments tels que les liens a ou les champs de formulaires. Portée par un élément div ou span, cette information ne sera pas accessible par exemple aux utilisateurs de lecteurs d'écran, de navigateurs non graphiques, ou encore naviguant au clavier.

Les modèles d'icônes de langues ou d'extension de fichier ne sont donc pas pertinents du point de vue de l'accessibilité.

Bons et mauvais exemples de contenus explicités
Non accessible Accessible
<span title="en anglais">'''(en)'''</span>
'''(en anglais)'''

[modifier] Références à un contenu par sa position à l'écran

Bonne pratique : ne pas faire reposer la compréhension d'une information sur une référence à la position ou à la forme d'un contenu affiché à l'écran..


  • priorité : élevée
  • difficulté : facile

Il peut être nécessaire de faire référence dans le texte d'un article à une illustration, un tableau ou tout autre contenu affiché dans la même page. Dans ce cas, si cette référence s'appuie uniquement sur la position ou la forme de ce contenu, elle ne sera pas compréhensible pour des utilisateurs qui n'ont pas accès visuel à la page, ou qui ne la consultent pas dans son affichage prévu via CSS[WCAG-TECH 6].

Bons et mauvais exemples de référence à un contenu
Non accessible Accessible
Dans le cas de figure décrit par l'image de gauche...
Dans le cas de figure décrit par l'illustration numéro 1...

(La légende de l'illustration indique son numéro)

[modifier] Liens

[modifier] Libellés des liens

Bonne pratique : rédiger autant que possible des libellés de liens explicites qui permettent à eux seuls d'identifier la page cible, indépendamment des informations complémentaires apportées par leur contexte. A défaut, s'assurer que le paragraphe, la liste ou le tableau où se trouve le lien, ou encore le titre de section qui le précède, apportent les informations nécessaires pour expliciter son libellé.

  • priorité : élevée
  • difficulté : moyenne

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 fréquemment amenés à entendre ces libellés isolés de leur contexte[WCAG-TECH 7].

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és 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 toujours 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.

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

[[WP:AG|Cliquez ici]]

[[WP:AG|?]]

[[Paris|Lire la suite…]]
[[WP:AG|Atelier graphique]]

[[Paris|Lire la suite de l'article Paris]]
http://www.la-grange.net/w3c/

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

[http://www.la-grange.net/w3c/ Cliquez ici]
[http://www.la-grange.net/w3c/
Traduction en français des recommandations du W3C] 
[[Foo1|Détail]]… [[Foo2|Détail]]

[http://example.org/foo1.html Archive]
… 
[http://example.org/foo2.html Archive]
[[Foo1]]… [[Foo2]]

[http://example.org/foo1.html Archive de Lorem ipsum]
… 
[http://example.org/foo2.html Archive de Sic dolor amet]

[modifier] Alternative des liens sur image

Bonne pratique : rédiger systématiquement une alternative pour un lien sur image, désignant explicitement la cible du lien.

Atelier Accessibilité
Exemple de lien sur image
La cible est l'atelier accessibilité
L'alternative est « Atelier accessibilité »
  • priorité : élevée
  • difficulté : facile

Mediawiki permet de créer un lien interne ou externe sur une image, avec la syntaxe :
[[Image:Exemple.jpg|Alternative textuelle|link=page cible]]

Où :

  • page cible est le titre d'une page interne, ou l'url d'un lien externe ;
  • « Alternative textuelle » est le texte qui sera restitué lorsque l'image ne peut pas l'être (par exemple, par un navigateur non graphique, un lecteur d'écran, etc.)

L'alternative textuelle joue ici le même rôle que le libellé d'un lien texte : elle doit permettre d'identifier aisément la cible du lien. Elle ne doit en aucun cas décrire l'image elle-même, à la différence des autres cas d'alternatives textuelles d'images.

Lorsque l'alternative textuelle n'est pas renseignée par les contributeurs, mediawiki génère par défaut une image-lien dotée d'une alternative vide non accessible[WCAG-TECH 8].

Bons et mauvais exemples de liens sur image
Éviter Préférer
[[Image:Exemple.jpg|link=Wikipédia:Le Bistro]]

[[Image:Exemple.jpg|Une fleur|link=Wikipédia:Le Bistro]]

[[Image:Exemple.jpg|Le Bistro|link=Wikipédia:Le Bistro]]
[[Image:Exemple.jpg|link=http://www.google.fr]]

[[Image:Exemple.jpg|Icône de Google|link=http://www.google.fr]]
[[Image:Exemple.jpg|Google|link=http://www.google.fr]]

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

Bonne pratique : indiquer si possible le format des documents en téléchargement ou la langue du document cible dans le libellé des liens concernés. À défaut, faire figurer ces informations dans la phrase ou l'élément de liste où se trouve le lien.

  • priorité : élevée
  • difficulté : facile

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 mais à un document à télécharger
  • 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 peuvent être apportées dans le contexte immédiat du lien ou, mieux, dans son libellé lui-même[WCAG-TECH 9].

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. Dans la mesure du possible, il sera préférable que le format soit directement indiqué dans le libellé.

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. Dans la mesure du possible, il sera péférable que le libellé soit directement rédigé dans la langue concernée, en recourant au modèle {{lang}} pour préciser celle-ci.

Bons et mauvais exemples de liens externes nécessitant une information de langue ou de format
Non accessible Accessible
[http://example.org/foo.pdf Titre du document]
{{pdf}} [http://example.org/foo.pdf Titre du document]

Ou mieux :

[http://example.org/foo.pdf Titre du document (PDF)]
* [http://www.w3.org/TR/WAI-WEBCONTENT/
          Directives d'accessibilité des contenus Web 1.0]
* {{en}} [http://www.w3.org/TR/WAI-WEBCONTENT/
          Directives d'accessibilité des contenus Web 1.0]

Ou mieux :

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

[modifier] Couleurs

[modifier] Utilisation de la couleur

Bonne pratique : ne pas donner une information uniquement à l'aide d'une couleur ou d'une mention de couleur.

Exemple d'utilisation de la couleur et des styles CSS (en haut) non accessibles (en bas, rendu sans CSS), dans le modèle {{Élément}}
  • priorité : élevée
  • difficulté : 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, utilisateurs souhaitant consulter un article après son impression sur une imprimante monochrome, ou encore utilisateurs ayant coché l'option d'accessibilité « Ignorer les couleurs… » dans leur navigateur[WCAG-TECH 10].

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
<td style="background-color: yellow>&nbsp;</td>
<td><[[Image:yellow.png|Icône médaille d'or]]</td>

<td>Médaille d'or</td>
En rouge, les œuvres majeures de cet auteur :
* <span style="color:red">…
En rouge et en gras, les œuvres majeures de cet auteur :
* <strong style="color:red">…

[modifier] Choix de couleurs et contrastes

Bonne pratique : veiller à obtenir un niveau de contraste suffisant entre le texte et son arrière-plan.

  • priorité : moyenne
  • difficulté : 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. Il est recommandé de conserver un ratio de contraste de couleurs d'avant-plan et d'arrière-plan au moins supérieur à 4.5, 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.)[WCAG-TECH 11]

Bons et mauvais exemples d'utilisation de la couleur
Non accessible Accessible
La société <span style="color: #FCB415">Renault</span>

La société Renault

La société Renault

La société Renault

<div style="color: #fff;background:#ff8080;font-weight:bold;text-align: center;">
Pokemon
</div>
Pokémon
<div style="text-align: center;">
'''Pokemon'''
</div>

Pokemon

[modifier] Listes

[modifier] Listes à puces et listes numérotées

Bonne pratique : utiliser les éléments de liste ordonnées (ol, #) et non ordonnées (ul, *) pour les énumérations.

  • priorité : élevée
  • difficulté : 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-TECH 12].

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.

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.

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
[[lien 1]] • [[lien 2]] • [[lien 3]]
<ul class="inline">
<li>[[lien 1]]</li>
<li>[[lien 2]]</li>
<li>[[lien 3]]</li>
</ul>

La classe .inline devant être définie dans MediaWiki:Common.css

[modifier] Listes de définition

Bonne pratique : utiliser les éléments de liste de définition(dl, dt et dd, en wiki ; et :) de manière à ce qu'un terme soit systématiquement associé à sa définition ou à sa description.

  • priorité : élevée
  • difficulté : facile.

Les listes de définition (ou de description) permettent d'associer un ou plusieurs paragraphes à un terme qu'ils définissent ou décrivent. Le balisage dt (wiki: ;) est cependant fréquemment utilisé pour produire un pseudo-titre de section lorsqu'on ne souhaite pas que celui-ci apparaisse dans le sommaire de l'article. Dans ce cas, le contenu ainsi titré doit être précédé de l'élément dd (wiki: :).

Bons et mauvais exemples de listes de définition détournées pour produire des titres de section
Non accessible Accessible
;Titre de la section
Contenu de la section
;Titre de la section
:Contenu de la section
;Titre de la section
* Contenu de la section
* Contenu de la section
* Contenu de la section
;Titre de la section
:* Contenu de la section
:* Contenu de la section
:* Contenu de la section

[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. Étant 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

Bonne pratique : utiliser systématiquement des en-têtes de ligne et de colonne explicites (! scope=col, ! scope=row) dans les tableaux de données. Utiliser autant que possible l'élément caption pour indiquer le titre du tableau. Ne jamais imbriquer plusieurs niveaux de tableaux.

  • priorité : élevée.
  • difficulté : 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 identifiés par l'attribut scope=col, et les en-têtes de ligne par scope=row[WCAG-TECH 13], 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ées 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-TECH 14].

Le code d'un tableau de données à doubles entrées sera donc du type :

|+
! scope=col ! scope=col
! scope=row Contenu Contenu
! scope=row Contenu Contenu

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 proscrite.

[modifier] Tableaux complexes

Bonne pratique : utiliser les attributs id et headers dans les tableaux de données complexes, pour relier chaque cellule de contenu à son ou à ses en-têtes de lignes et de colonnes.

  • priorité : élevée.
  • difficulté : difficile.

Les tableaux complexes comportent des divisions par blocs de lignes ou de colonnes. Ce type de tableau peut et devrait le plus souvent être réécrit en le décomposant en plusieurs tableaux simples. Cependant, lorsque ce n'est pas possible, des mesures spécifiques doivent être prises pour leur accessibilité.

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[WCAG-TECH 15].

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.


Bonne pratique : utiliser l'attribut summary de l'élément table pour expliciter l'organisation des données dans un tableau complexe.

La compréhension d'un tableau de ce type est difficile pour des utilisateurs qui n'auront pas l'aide de sa représentation graphique. C'est pourquoi il peut être utile de fournir une explication de l'organisation des données, via l'attribut summary de l'élément table (code wiki {| summary="...")[WCAG-TECH 16].

[modifier] Tableaux de mise en forme

Bonne pratique : n'utiliser les éléments de tableau pour la mise en forme que si leur contenu se linéarise de manière compréhensible. Ne pas utiliser alors d'éléments propres aux tableaux de données (titres <caption> ou |+, en-têtes de ligne ou de colonne <th> ou !).

  • priorité : élevée.
  • difficulté : 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-TECH 17].
  • 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-TECH 18].
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
|}
Plan des voies de la ligne 4 du tramway d'Île-de-France Une image cliquable

[modifier] Tableaux triables

Bonne pratique : éviter autant que possible l'utilisation des tableaux triables.

L'utilisation des modèles {{Smn}} et {{Tri}} génère dans le tableau des données masquées fournissant des clés de tri différentes des données affichées dans le tableau. Ces clés de tri étant un contenu simplement masqué dans chaque cellule concernée, elles rendent incompréhensible leur contenu pour les utilisateurs chez qui les styles CSS ne sont pas pris en compte ou sont désactivés.

Les autres possibilité actuelles de rédiger un tableau triable accessible étant trop complèxes, il vaut mieux s'abstenir[1].


Exemple de tableau triable utilisant le modèle {{Smn}}
Rendu affiché avec CSS Contenu réel de la cellule de tableau
qui sera lu par les lecteurs d'écran
-47,15 € -4715 !-47,15 €

[modifier] Infobox et taxobox

[modifier] Images

Mettez-vous à la place d'un lecteur d'écran déchiffrant le code d'un article de ce type : Plongeon aux Jeux olympiques d'été de 1952, le rendu est incompréhensible et aucun texte n'est présent pour compenser l'usage surabondant des couleurs et des icones incluses dans ces tableaux.

[modifier] Images portant une information

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-TECH 19]. Cette alternative n'est pas affichée par défaut, et ne sera restituée que lorsque l'image elle-même ne peut pas l'être.

Mediawiki permet d'indiquer l'alternative textuelle d'une image mise en thumb, via le paramètre alt, ou de toute autre image sans que ce paramètre soit explicite :

[[Image:Nom de l'image|thumb|alt=alternative textuelle de l'image à compléter|légende affichée sous l'image]]

[[Image:Nom de l'image|alternative textuelle de l'image à compléter]]

Cette alternative textuelle doit impérativement être renseignée : si le paramètre alt est vide ou absent, MediaWiki génère en effet :

  • une image-lien avec alternative vide dans le cas d'un thumb
  • une image-lien avec la mention « Image: » suivie du nom de fichier comme alternative en cas d'image sans thumb

Cela aboutit dans les deux cas à un résultat très difficilement compréhensible : aucune information pertinente ne sera restituée si les images ne peuvent être affichées, et un lecteur d'écran énoncera au mieux le nom du fichier image en guise d'alternative.

L'alternative doit être rédigée en fonction du contexte où se trouve l'image, et de l'information utile qu'elle apporte dans celui-ci. Sa rédaction est rendue plus difficile par le fait que chaque image insérée à l'aide de la syntaxe [[Image:... est également un lien vers sa propre page wiki : l'alternative doit, autant que possible, éviter de donner à penser que ce lien vise un article de Wikipédia.

[modifier] Exemple d'une image illustrative, apportant une information mineure

Bonne pratique : renseigner systématiquement le paramètre alt des images avec une brève description de l'information donnée par l'image et permettant d'identifier sa nature.

Photographie montrant le second étage de la Tour Eiffel dominant le toit des immeubles environnant.
La tour Eiffel surplombant Paris de ses 300 mètres de hauteur
  • priorité : élevée
  • difficulté : difficile

La plupart des images ajoutées aux articles en thumb n'apportent pas d'information majeure, et ont un rôle essentiellement illustratif. D'autre part, une partie de cette information est souvent déjà donnée sous forme textuelle dans la légende de l'image. Le fait que l'image soit un lien interdit cependant de lui donner une alternative textuelle vide.

Dans ce cas, l'alternative, aussi concise que possible, devrait décrire factuellement l'image.

Bons et mauvais exemples d'alternative pour une image illustrative
Non accessible Accessible
[[Image:La Tour Eiffel surplombant Paris.jpg
  |thumb
  |La tour Eiffel surplombant [[Paris]] de ses 300 mètres de hauteur]]

[[Image:La Tour Eiffel surplombant Paris.jpg
  |thumb
  |alt=La tour Eiffel
  |La tour Eiffel surplombant [[Paris]] de ses 300 mètres de hauteur]]
[[Image:La Tour Eiffel surplombant Paris.jpg
  |thumb
  |alt=Photographie montrant le second étage de la Tour Eiffel
       dominant le toit des immeubles environnant.
  |La tour Eiffel surplombant [[Paris]] de ses 300 mètres de hauteur]]

[modifier] Exemple d'une image apportant une information majeure

Bonne pratique : privilégier une restitution textuelle de l'information dans le corps de l'article, mais renseigner systématiquement le paramètre alt des images avec un résumé de l'information majeure donnée par l'image, permettant également d'identifier sa nature.

Graphique de fréquentation : moins d'un million d'entrées annuelles jusqu'en 1945, puis une croissance presque continue jusqu'à 6 millions d'entrées annuelles après 2000
Évolution de la fréquentation de la tour Eiffel depuis 1889.
  • priorité : élevée
  • difficulté : difficile

Dans certains cas, le contexte sera difficilement compréhensible ou incomplet en l'absence de l'image. L'information apporté par l'image est alors alors le plus souvent complexe, et nécessite une description détaillée et longue. Mais l'alternative textuelle n'est pas destinée à donner cette description détaillée : c'est le rôle du longdesc qui n'est actuellement pas supporté par mediawiki.

Dans ce cas, il convient de compléter le texte de l'article afin d'y faire figurer l'information que l'image vient alors simplement illustrer ou reproduire sous forme graphique. L'alternative textuelle peut alors résumer brièvement cette information.

Bons et mauvais exemples d'alternative pour une image de contenu
Non accessible Accessible
[[Image:Fréquentation tour Eiffel.svg
  |thumb 
  |Évolution de la fréquentation de la tour Eiffel depuis 1889.]]

[[Image:Fréquentation tour Eiffel.svg
  |thumb 
  |alt=Statistiques de fréquentation
  |Évolution de la fréquentation de la tour Eiffel depuis 1889.]]
[[Image:Fréquentation tour Eiffel.svg
  |thumb 
  |alt=Graphique de fréquentation : moins d'un million
       d'entrées annuelles jusqu'en 1945,
       puis une croissance presque continue
       jusqu'à 6 millions d'entrées annuelles après 2000
  |Évolution de la fréquentation de la tour Eiffel depuis 1889.]]

Le texte de l'article décrit plus précisément l'évolution
de la fréquentation de la tour Eiffel.
Un tableau de données peut éventuellement
fournir la totalité de l'information.

Drapeau du 23e bataillon d'infanterie de marine
Les noms des batailles s'inscrivent en lettres d'or sur le drapeau (Ki-Hoa 1861, Publea 1863, Sontay 1883, Tien-Tsin 1900, Maroc 1908-1913, Champagne 1915-1918, L'Aisne 1917-1918, Reins 1918, Argonne 1940, Colmar 1945, Bade 1945, Indochine 1945-1954, AFN 1952-1962).

(L'alternative textuelle est « Drapeau du 23e bataillon d'infanterie de marine »)

[modifier] Images décoratives

Bonne pratique : limiter autant que possible l'utilisation de la syntaxe [[Image:...]] pour des icônes et autres images décoratives qui ne portent aucune information qui ne soit présente par ailleurs dans leur contexte. Privilégier l'utilisation des images d'arrière-plan CSS. À défaut, renseigner systématiquement le paramètre alt des images pour identifier la nature du lien généré par celle-ci.

Icône du Portail de la tour Eiffel Portail de la tour Eiffel

Icône de drapeau: France France

  • priorité : élevée.
  • difficulté : moyenne.

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-TECH 20].

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é[WCAG-TECH 21].

Bons et mauvais exemples d'images décoratives
Non accessible Accessible
[[Image:P Eiffel.png|48x24px|]]

[[Image:P Eiffel.png|48x24px|La tour Eiffel]]
[[Image:P Eiffel.png|48x24px|Icône du Portail de la tour Eiffel]]
<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;
}

Remarque : une autre technique existe, mais reste à confirmer. Actuellement, l'ajout d'un paramètre link= sans valeur après le signe égal produit une image qui n'est pas une image-lien et qui a une alternative vide. C'est-à-dire la solution optimale pour une image décorative qu'on ne gère pas en CSS. Cependant, ce comportement de mediawiki est susceptible de changer à l'avenir, car il n'obéit qu'à un choix arbitraire des développeurs. Il est donc risqué de s'y fier.

Utilisation de link= pour une image décorative
Code Résultat
[[Image:P Eiffel.png|48x24px|link=|]]

[modifier] Combinaisons d'images via CSS

Bonne pratique : ne pas utiliser les styles CSS pour combiner deux ou plusieurs images, ou un texte et une image, de manière à produire une pseudo-image combinée, ou une pseudo image cliquable. Privilégier les images réelles et si nécessaire les images cliquables.

  • priorité : élevée
  • difficulté : moyenne

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. Par ailleurs, l'image ne sera pas réutilisable ou copiable. Enfin, le rendu pourra être compromis en cas d'agrandissement de la taille des caractères via les options d'accessibilité du navigateur. Ces techniques de composition d'images sont un défaut d'accessibilité au niveau le plus grave[WCAG-TECH 22].

Exemple de combinaison d'images via CSS, non accessible
Rendu espéré Rendu sans CSS
ou avec couleurs désactivées
dans un navigateur graphique
Transcription du rendu
dans un lecteur d'écran
Contenu réel publié
Voir la carte administrative
Voir la carte administrative « Lien graphique Voir
la carte administrative »
« Voir la carte
administrative »
Exemple de combinaison d'images via CSS, non accessible
Rendu espéré Rendu sans CSS dans un navigateur graphique

[modifier] Images animées

Bonne pratique : utiliser des animations au format Ogg Theora et éviter les animations au format GIF. Ne pas utiliser une animation uniquement pour produire un clignotement ou des changements brusques de luminosité (effets de flash)

.
animation décrivant la pose d'un câble sous-marin
Exemple d'animation GIF qui devrait être fournie dans un autre format donnant le contrôle de son déroulement à l'utilisateur (utilisée dans l'article Câble sous-marin).
  • priorité : élevée.
  • difficulté : difficile.

Les animations (mouvement, clignotement, défilement) sont une source de difficulté pour les utilisateurs souffrants de trouble de la concentration, ou pour ceux ayant besoin de davantage de temps que prévu pour percevoir et comprendre les étapes successives de l'animation. Il est nécessaire de permettre d'interrompre une animation qui perturbe l'attention, ou plus généralement de fournir les contrôles nécessaires pour mettre celle-ci en pause puis passer à son étape suivante en la relançant.

A cet effet, les normes d'accessibilité prévoient que les animations lancées automatiquement au chargement de la page :

  • ou bien ne doivent pas excéder une durée de 5 secondes[WCAG-TECH 23] (ce qui revient à en faire un élément purement décoratif).
  • ou doivent être dotées de fonctionnalités de contrôle (arrêt, pause, démarrage)[WCAG-TECH 24].

Les images GIF animées ne peuvent pas être dotées de ces contrôles et sont donc considérées comme non accessibles si l'animation est en boucle ou si elle excède 5 secondes (elles ne peuvent qu'être stoppées via la touche escape sans possibilité de redémarrage et sans contrôle précis de l'étape sur laquelle s'effectue l'interruption). En revanche, une animation au format Ogg Theora ne démarre qu'à l'initiative de l'utilisateur et s'accompagne des contrôles utilisateurs nécessaires.

[modifier] Animations, vidéos, fichiers audios

Bonne pratique : utiliser les animations et documents multimédia (Ogg Vorbis, Ogg Theora ou GIF) comme complément et illustration d'une description textuelle d'un processus, et non comme unique moyen de relater celui-ci.

  • priorité : élevée.
  • difficulté : moyenne.

Les « media temporels », c'est à dire les animations, les contenus vidéo ou audio, nécessitent une transcription de l'information sous forme textuelle pour que celle-ci soit accessible à tous :

  • une animation ou une vidéo ne seront pas perceptibles pour un utilisateur n'ayant pas accès au rendu visuel (utilisateur aveugle par exemple, ou utilisateur dont le système n'a pas le support du format Ogg Theora), sauf si l'information visuelle et sonore est disponible dans la même page sous forme textuelle[WCAG-TECH 25].
  • un fichier sonore ne sera pas perceptible pour un utilisateur n'ayant pas accès au rendu sonore (utilisateur sourd, par exemple, utilisateur dont le système n'a pas le support du format Ogg Vorbis, ou utilisateur n'ayant pas la possibilité d'activer le son dans un contexte donné), sauf si l'information sonore est disponible dans la même page sous forme textuelle[WCAG-TECH 26].

Le moyen le plus direct de disposer de cette transcription est de privilégier, lors de la rédaction, le contenu textuel des articles. Autrement dit, il s'agit de décrire (d'abord) dans le texte les informations qui peuvent (ensuite) être illustrées par un document multimédia ou une animation.

[modifier] Images cliquables

Bonne pratique : renseigner systématiquement l'alternative textuelle globale des ImageMap. Privilégier l'utilisation des ImageMap et éviter la création d'effets graphiques similaire à l'aide de CSS.

  • priorité : élevée.
  • difficulté : 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.

Bons et mauvais exemples de cartes cliquables
Non accessible Accessible
<div style="position: relative;">
[[Image:foo.png|300px]]
<span style="position: absolute; top: ...px; left: ...px">[[Lien 1]]</span>
<span style="position: absolute; top: ...px; left: ...px">[[Lien 2]]</span>
</div>
<imagemap>
Image:foo.png|300px|Carte des principales villes de Syldavie
rect position-du-lien-1 [[lien-1]]
rect position-du-lien-2 [[lien-2]]
desc position-de-la-description
</imagemap>

[modifier] Frises chronologiques

Bonne pratique : à déterminer.

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.

À 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

Bonne pratique : à déterminer.

[modifier] Styles CSS

[modifier] Pseudo contenu CSS

Bonne pratique : réserver l'usage des styles CSS exclusivement à la mise en forme de l'information contenu dans l'article, et ne l'utiliser en aucun cas pour créer une information nouvelle.

  • priorité : élevée.
  • difficulté : moyenne.

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égendes 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
  • des images génériques colorées via CSS

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

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).

« La légende de graphique », exemple de pseudo-contenu CSS et de rendus non accessibles
Rendu espéré Rendu sans CSS
dans un navigateur graphique
Résultats à l'élection présidentielle française en 2007
Légende
     - Nicolas Sarkozy
     - Ségolène Royal
     - François Bayrou
     - Jean-Marie Le Pen
     - Olivier Besancenot
     - Philippe de Villiers
     - Marie-George Buffet
     - Dominique Voynet
     - Arlette Laguiller
     - José Bové
     - Frédéric Nihous
     - Gérard Schivardi
Résultats à l'élection présidentielle française en 2007
Légende
- Nicolas Sarkozy
- Ségolène Royal
- François Bayrou
- Jean-Marie Le Pen
- Olivier Besancenot
- Philippe de Villiers
- Marie-George Buffet
- Dominique Voynet
- Arlette Laguiller
- José Bové
- Frédéric Nihous
- Gérard Schivardi
« Le maillot », exemple de pseudo-contenu CSS et de rendus non accessibles
Rendu espéré Rendu sans CSS
dans un navigateur graphique
Transcription du rendu dans un lecteur d'écran Contenu réel publié
Team colours Team colours Team colours
Team colours
Team colours
De 1970 à 1973
Team colours Team colours Team colours
Team colours
Team colours
De 1970 à 1973
« Lien graphique Team colour
Lien graphique Team colour
Lien graphique Team colour
Lien graphique Team colour
Lien graphique Team colour
De 1970 à 1973 »
« Team colour Team colour Team colour
Team colour Team colour De 1970 à 1973 »

[modifier] Javascript

Javascript est utilisé sur Wikipédia :

Du point de vue de son accessibilité :

  • javascript doit être utilisé de manière compatible avec l'accessibilité : tout contenu ou élément d'interface modifié ou créé via javascript doit respecter l'ensemble des règles d'accessibilité ;
  • en revanche, un script respectant cette première condition n'a pas à être doté d'une alternative : contrairement à WCAG1.0, les normes d'accessibilité WCAG2.0 n'exige en effet pas d'alternative à javascript pour les utilisateurs n'ayant pas le support de cette technologie ou ayant désactivé celui-ci.

[modifier] Produire un code compatible avec l'accessibilité

Bonne pratique : s'assurer que chaque fonctionnalité ou information ajoutée via javascript respecte elle-même l'ensemble des bonnes pratiques d'accessibilité, notamment la présence de alternatives textuelles, les liens explicites, etc.

Les lecteurs de l'encyclopédie en situation de handicap personnel ou technique n'auront pas nécessairement désactivé le support de javascript dans leur navigateur. Il est donc nécessaire que tout contenu généré via javascript soit accessible en lui-même, c'est-à-dire qu'il comporte en particulier l'ensemble des éléments et attributs nécessaires indiqués dans les bonnes pratiques d'accessibilité[WCAG 1].

  • priorité : élevée.
  • difficulté : moyenne.
Bons et mauvais exemples de javascript
Non accessible Accessible
var image = document.createElement('img');
image.src = 'http://example.org/foo.png';
var image = document.createElement('img');
image.src = 'http://example.org/foo.png';
image.alt = 'Ici, alternative textuelle pertinente pour cette image';
var lien = document.createElement('a');
lien.href = 'http://example.org';
lien.appendChild(document.createTextNode('+');
var lien = document.createElement('a');
lien.href = 'http://example.org';
lien.appendChild(document.createTextNode('+');
lien.title = 'Ici, texte explicitant la cible du lien';

[modifier] Accessibilité au clavier

Bonne pratique : s'assurer que chaque interaction reposant sur javascript pourra être réalisée au clavier aussi bien qu'à la souris.

  • priorité : élevée.
  • difficulté : moyenne.

Tous les lecteurs de Wikipédia n'ont pas la possibilité d'utiliser une souris ou un dispositif de pointage équivalent. S'assurer que chaque interaction est également possible via la touche tabulation du clavier garantit que tous auront accès à cette interaction indépendamment de leur périphérique de saisie[WCAG-TECH 28].

[modifier] Redirections et rafraîchissements de page

Bonne pratique : ne pas utiliser javascript pour produire une redirection automatique ou un rafraîchissement que l'utilisateur ne peut pas désactiver.

  • priorité : faible.
  • difficulté : facile.

Les redirections automatiques via javascript affiche une page temporaire qui déclenche la redirection vers la page finale après un délai donné. De même, un script de rafraîchissement provoque le rechargement automatique de la page toutes les n secondes.

Quelque-soit la temporisation choisie, des utilisateurs d'aide technique auront des difficultés à consulter ces pages dans le délai fixé : l'accès peut être en effet beaucoup plus lent pour un utilisateur naviguant au clavier, recourant à une loupe ou encore à un lecteur d'écran. Ce type de script est donc à éviter autant que possible[WCAG-TECH 29].

Si nécessaire, il est possible cependant de rendre accessible les rafraîchissements et redirections via javascript :

  • en veillant à insérer en tout début de contenu de page, et de manière visible à l'affichage, un lien permettant à l'utilisateur de désactiver celles-ci.
  • ou encore en permettant à l'utilisateur de configurer la durée d'affichage avant la redirection ou le rafraîchissement.

[modifier] Notes et références

  1. Un tri javascript accessible et sémantique dans un tableau utilise l'attribut HTML id des cellules pour y placer les clés de tri. Le script pourrait être réécrit en ce sens, mais ce serait impraticable car les rédacteurs ne sauront pas respecter les contraintes particulières qui s'appliquent à cet attribut, en particulier l'unicité du contenu dans la page.

Les références suivantes mènent à la version originale en anglais des Règles pour l'accessibilité des contenus Web (WCAG) 2.0 :

  1. Conformance Requirements

Les références suivantes mènent à la version originale en anglais des Techniques pour WCAG2.0 :

  1. Using h1-h6 to identify headings, niveau d'accessibilité A
  2. Presenting repeated components in the same relative order each time they appear, niveau d'accessibilité AA
  3. Using language attributes to identify changes in the human language , niveau d'accessibilité AA
  4. Unusual Words, niveau d'accessibilité AAA
  5. Providing the expansion or explanation of an abbreviation, niveau d'accessibilité AAA
  6. Failure of Success Criterion 1.3.3 due to identifying content only by its shape or location, niveau d'accessibilité A
  7. Identifying the purpose of a link using link text combined with its enclosing list item, Identifying the purpose of a link using link text combined with its enclosing paragraph, Identifying the purpose of a link using link text combined with its enclosing table cell and associated table headings, Identifying the purpose of a link using link text combined with the preceding heading element, Identifying the purpose of a link in a nested list using link text combined with the parent list item under which the list is nested, niveau d'accessibilité A
  8. Failure of 2.4.4, 2.4.9 and 4.1.2 due to using null alt on an image where the image is the only content in a link, niveau d'accessibilité A
  9. Identifying the purpose of a link using link text combined with the text of the enclosing sentence, niveau d'accessibilité A ; Providing link text that describes the purpose of a link, niveau d'accessibilité AAA
  10. Ensuring that additional visual cues are available when text color differences are used to convey information, niveau d'accessibilité A
  11. Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text, niveau d'accessibilité AA
  12. Using ol, ul and dl for lists, niveau d'accessibilité A
  13. Using the scope attribute to associate header cells and data cells in data tables, niveau d'accessibilité A
  14. Using caption elements to associate data table captions with data tables, niveau d'accessibilité A
  15. Using id and headers attributes to associate data cells with header cells in data tables, niveau d'accessibilité A
  16. Using the summary attribute of the table element to give an overview of data tables, niveau d'accessibilité A
  17. Failure of Success Criterion 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables, niveau d'accessibilité A
  18. Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized, niveau d'accessibilité A
  19. Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content et Providing long description for non-text content that serves the same purpose and presents the same information niveau d'accessibilité A
  20. Using null alt text and no title attribute on img elements for images that AT should ignore, niveau d'accessibilité A
  21. Using CSS to include decorative images, niveau d'accessibilité A
  22. Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS, niveau d'accessibilité A
  23. Setting animated gif images to stop blinking after n cycles (within 5 seconds), niveau d'accessibilité A
  24. Allowing the content to be paused and restarted from where it was paused, niveau d'accessibilité A
  25. Providing an alternative for time based media, niveau d'accessibilité A
  26. Providing an alternative for time-based media for audio-only content, niveau d'accessibilité A
  27. Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS, niveau d'accessibilité A
  28. Providing keyboard-triggered event handlers, niveau d'accessibilité AA
  29. Failure of Success Criterion 2.2.1 due to using server-side techniques to automatically redirect pages after a time-out et Failure of Success Criterion 3.2.5 due to complete change of main content through an automatic update that the user cannot disable from within the content, niveau d'accessibilité AAA
Créer un livre