Skip to content

Latest commit

 

History

History
247 lines (200 loc) · 10.7 KB

4-tableaux.md

File metadata and controls

247 lines (200 loc) · 10.7 KB
Raw

Guide de l'intégrateur

Fiche 4 : Tableaux

Introduction - cas utilisateurs

Un tableau est toujours complexe à utiliser avec un lecteur d'écran. Une personne aveugle n'a pas une vision globale du tableau. Elle le parcourt de manière séquentielle : une case après l'autre et ligne à ligne. Afin d'améliorer son expérience, les lecteurs d'écran offrent des fonctionnalités de parcours étendues en utilisant les flèches de direction.

Pour adapter le tableau aux capacités de restitution et aux fonctionnalités de navigation étendues, il est important de définir des en-têtes de colonnes ou de lignes et de les relier explicitement aux cellules de données.

Synthèse

  • Implémenter le role="presentation" sur les tableaux de mise en forme.
  • Déclarer les cellules d'en-têtes dans des éléments <th>.
  • Implémenter un attribut scope="col" pour les en-têtes de colonnes.
  • Implémenter un attribut scope="row" pour les en-têtes de lignes.
  • Utiliser les relations id, headers pour relier les cellules de données à leurs en-têtes dans le cas de cellules fusionnées.

Tableaux de mise en forme

Le premier conseil serait simplement de ne pas utiliser de tableau (<table>) pour réaliser des mises en forme. Les tableaux sont utiles pour présenter des données tabulaires. C’est leur fonction principale.

Si malgré tout, vous êtes amenés à utiliser des éléments <table pour réaliser certaines mises en forme, alors vous devez :

  • Implémenter role="presentation" sur l'élément <table>.
  • Ne pas utiliser les éléments propres aux tableaux de données : <caption>, <th>, <thead>, <tfoot> ;
  • Ne pas utiliser les attributs propres aux tableaux de données : scope, headers.

Si vous utilisez un tableau de données, la structure doit ressembler à celle-ci :

	<table role="presentation">
	    <tr>
	        <td>[votre contenu]</td>
	        <td>[votre contenu]</td>
	    </tr>
	    <tr>
	        <td>[votre contenu]</td>
	        <td>[votre contenu]</td>
	    </tr>
	
	</table>

De plus, vous devez vous assurer que la linéarisation du tableau permet la compréhension du contenu : un tableau est lu de gauche à droite. Assurez-vous que le contenu reste compréhensible de cette manière.

Note : l’API ARIA propose un mécanisme permettant de surcharger le rôle natif d’un élément pour proposer des composants. Ainsi, il est possible d’utiliser des tableaux de mise en forme pour construire des listes, par exemple en implémentant les rôles list et listitem sur les éléments du tableau. Si cet usage est fortement déconseillé, il est néanmoins conforme. Le tableau étant restitué comme une liste et non plus comme un tableau, il n’est pas utile de signaler qu’il s’agit d’un tableau de présentation via le rôle presentation.

À propos du role="presentation"

Le role="presentation" permet d'annuler la sémantique native de l'élément qui la possède.

Dans notre cas, si le tableau possède le role="presentation", un lecteur d'écran ne restituera pas le tableau, mais uniquement les contenus dans l'ordre dans lequel ils sont insérés dans les cellules. L'utilisateur aura l'impression d'être sur du simple texte.

De plus, les comportements clavier disponibles sur ces éléments (par exemple flèche droite pour aller à la cellule suivante) ne sont plus actifs et retrouvent leur fonctionnalité d'origine (par exemple, flèche droite permet de se déplacer de caractère en caractère).

Voir l'explication du role="presentation" dans la spécification WAI-ARIA

Tableaux de données simples

Un tableau est considéré comme simple s'il ne possède pas de cellules fusionnées qui rendent la compréhension délicate et s'il ne présente pas une structure (notamment des sous-contextes) qui rend sa compréhension dépendante d'une mise en forme.

Une manière d'identifier un tableau de donnée simple est de considérer les en-têtes : si les en-têtes concernent toute une ligne ou toute une colonne alors il s'agit d'un tableau de données simple.

Pour un tableau de données simple, vous devez :

  • Implémenter un élément <caption> qui est le titre du tableau, il permet aux utilisateurs de comprendre quelles données ils vont rencontrer.
  • Implémenter les en-têtes dans des éléments <th> ;
  • Pour les en-têtes de colonnes, l'élément <th> doit avoir l'attribut scope="col" ;
  • Pour les en-têtes de lignes, l'élément <th> doit avoir l'attribut scope="row".

Un tableau simple ressemble à ceci :

Accessibilité des lignes du réseau de surface RATP
Équipements Nombre de lignes Pourcentage du total de lignes
Rampe d'accès 260 70,46 %
Annonce sonore 318 86,17 %

La structure de notre tableau sera donc la suivante :

	<table>
	    <caption>Accessibilité des lignes du réseau de surface RATP</caption>
	    <tr>
	        <th scope="col">Équipements</th>
	        <th scope="col">Nombre de lignes</th>
	        <th scope="col">Pourcentage du total de lignes</th>
	    </tr>
	    <tr>
	        <td>Rampe d'accès</td>
	        <td>260</td>
	        <td>70,46&nbsp;%</td>
	    </tr>
	    <tr>
	        <td>Annonce sonore</td>
	        <td>318</td>
	        <td>86,17&nbsp;%</td>
	    </tr>
	</table>

Ces données sont issues du site data.gouv.fr. Leur exploitation dans ce contexte n'est faite qu'à titre d'illustration, elle ne relève en rien d'une statistique officielle.

Tableaux de données complexes

Les tableaux de données complexes sont généralement des tableaux qui possèdent des cellules fusionnées ou des sous-contextes.

Voici un exemple de tableau de données complexe :

Nombre de gares et points d'arrêts TER, en fonction du type de handicap et du type de dispositif par handicap
Malvoyants Aveugles
Obstacles contrastés Portes contrastées Obstacles détectables à la canne Guidage en braille
73 65 103 0
138 103

Dans ce tableau, on trouve des en-têtes et des cellules de données fusionnées. La réparation consiste à relier chaque cellule de données explicitement grâce à des identifiants sur les en-têtes et des attributs headers sur les cellules de données.

<table>
    <caption>Nombre de gares et points d'arrêts TER, en fonction du type de handicap et du type de dispositif par handicap</caption>
    <tr>
        <th id="malvoyant" colspan="2">Malvoyants</th>
        <th id="aveugle" colspan="2">Aveugles</th>
    </tr>
    <tr>
        <th id="data1" headers="malvoyant">Obstacles contrastés</th>
        <th id="data2" headers="malvoyant">Portes contrastées</th>
        <th id="data3" headers="aveugle">Obstacles détectables à la canne</th>
        <th id="data4" headers="aveugle">Guidage en braille</th>
    </tr>
    <tr>
        <td headers="malvoyant data1">73</td>
        <td headers="malvoyant data2">65</td>
        <td headers="aveugle data3">103</td>
        <td headers="aveugle data4">0</td>
    </tr>
    <tr>
        <td colspan="2" headers="malvoyant">138</td>
        <td colspan="2" headers="aveugle">103</td>
    </tr>
</table>

Ces données sont issues du site data.gouv.fr (Accessibilité des gares et points d'arrêt TER aux personnes à mobilité réduite en 2013). Leur exploitation dans ce contexte n'est faite qu'à titre d'illustration, elle ne relève en rien d'une statistique officielle.

Pour aller plus loin

Voir ailleurs / Ressources

Critères RGAA

  • 5.1 [A]
  • 5.2 [A]
  • 5.3 [A]
  • 5.4 [A]
  • 5.5 [A]
  • 5.6 [A]
  • 5.7 [A]
  • 5.8 [A]

Sommaire du guide de l'intégrateur