Tri accessible de tableaux

Par Laurent Denis, le 21 avril 2009, dans .

De temps en temps, je réponds à des questions posées sur des listes d’experts en accessibilité. Une récente question sur les tris de tableaux accessibles m’a conduit à poster la réponse suivante :

Rendre un tableau triable accessible nécessite le plus souvent de répondre à quatre exigences grossières:

  • avoir un tableau accessible au départ ;
  • ne pas gérer les clés de tri en tant que contenu caché, mais via des attributs dont le contenu n’est pas restituable (pas de display:none sur du contenu dans les cellules, pas de title. Plutôt des ID) ;
  • avoir des fonctionnalités javascript accessibles intrinsèquement (accès clavier, éventuelles alternatives textuelles pertinentes, etc.) et si possible non intrusives (c’est pareil mais c’est plus élégant) ;
  • décider au cas par cas si javascript est une technologie accessible une fois déployée de manière accessible, dans ce cadre précis. Si non, fournir une alternative client-serveur permettant d’effectuer le tri.

Le reste n’est que littérature, sauf si vous avez un commentaire permettant d’enrichir l’état de l’art. N’hésitez pas.

6 commentaire(s)

  1. Par Thanh, le 21 avril 2009 à 15 h 01 min :

    “ne pas gérer les clés de tri en tant que contenu caché, mais via des attributs dont le contenu n’est pas restituable (pas de display:none sur du contenu dans les cellules, pas de title. Plutôt des ID) ;”

    J’utilise des classes sur des éléments span pour gérer le tri sur des items afin de ne pas tenir compte de l’ordre alphabétique.

  2. Par Laurent denis, le 21 avril 2009 à 15 h 09 min :

    Oui, CLASS aussi : c’est le “non restituable” qui est important (tout ce qui n’est pas rendered content ou rendered text au sens de UAAG, c’est à dire ce qui ne produira rien qui soit susceptible d’être perçu: pas de title, pas de alt, pas de contenu, etc.)

  3. Par Benoît, le 21 avril 2009 à 15 h 38 min :

    @Thanh

    “J’utilise des classes sur des éléments span pour gérer le tri sur des items afin de ne pas tenir compte de l’ordre alphabétique.”

    Pourquoi ne pas vouloir tenir compte de l’ordre alphabétique ? Fonctionnellement, c’est bien ce que l’on veut : avoir un tri alphabétique sur les valeurs. En ajoutant une indirection (les classes), on ajoute un élément susceptible de causer des bugs lors des maintenances successives du code. Il vaut mieux, à mon sens conserver un code correspondant le plus possible à ce qui est voulu fonctionnellement.

  4. Par Mickael Hoareau, le 21 avril 2009 à 16 h 43 min :

    @Benoît

    Les tris peuvent être complexes à mettre en œuvre. Typiquement, sur Mon-Opquast pour la liste RGAA.
    Le problème d’un tri alphanumérique sur des numéros comme 1.1.1 1.1.2 … 1.1.10 sera problématique (1.1.10 sera placé avant 1.1.2 dans un tri alphanumérique).

    Idem si la “clé de tri” n’est pas au début du contenu de la cellule.
    Par exemple : “A. Règle machin truc (Type 1)” et “B. Règle truc machin (Type 2)”. Si on veut pouvoir trier sur les “(Type i)”. Un moyen simple de procéder et de mettre une classe “type_1” sur la cellule (td) ou sur un span englobant l’information concernée dans la cellule.

  5. Par Thanh, le 21 avril 2009 à 19 h 16 min :

    @Benoit,

    Comme dit précédemment, on a parfois besoin de trier sur la définition d’une valeur et non son orthographe.

    Exemple simple : Pour trier des éléments selon leur degré d’urgence : haute, moyenne, normale, basse.

    Une fois ces astuces en place, les librairies de tri JS (jQuery par ex) font très bien leur job avec même la possibilité de trier sur plusieurs colonnes.

  6. Par Benoît, le 22 avril 2009 à 10 h 19 min :

    @Mickael Hoareau et Thanh

    Tout à fait, ma remarque n’avait de sens que si le tri que l’on voulait faire était alphabétique. Mea un petit peu culpa.

    Cela dit, on peut aussi donner en paramètre d’une colonne l’équivalent d’un Comparator (puisqu’en javascript on peut mettre des fonctions en argument), c’est-à-dire donner l’algorithme.

    Avec l’approche que vous proposez, on aura effectivement un code javascript que l’on aura pas besoin de modifier, mais il faudra systématiquement donner les ordres dans les classes, ce qui signifie que pour chaque élément de chaque colonne, on fait un calcul préalable côté serveur, alors que en faisant le code côté client, on le fait “en lazy”, uniquement par rapport aux solicitations de l’utilisateur.

    De plus, avec l’approche que vous proposez (avec les classes), on complexifie (un tout petit peu d’accord, mais un peu quand même) le DOM.

    J’aurais tendance à penser (mais c’est subjectif) que les deux approches sont intéressantes, et qu’elles sont à choisir en fonction du contexte :
    – selon que les développeurs soient ou non à l’aise en javascript ou uniquement en langage côté serveur ;
    – selon que les tableaux soient rendus de manière identiques fréquemment (auquel cas, il doivent être mis en cache côté serveur et les calculs côté serveur seront faits une seule fois), ou non (auquel cas, il vaut mieux faire les tri en lazy).

    Je n’ai peut être pas pris en compte toutes les considérations.

Les commentaires sont fermés.