[SPIP Zone] Couteau suisse - suggestions pour l'accessibilité et anomalie

Archives Zone
1

Je suis en train de développer un site avec SPIP qui doit respecter assez strictement les critères d'accessibilité.

J'utilise quelques unes des fonctions de l'excellent plugin Couteau suisse, pour lequel j'ai quelques suggestions à faire et une anomalie à signaler, concernant le sommaire et le découpage en page.

Pour améliorer l'accessibilité du sommaire, il serait préférable d'intégrer le numéro de page au lien auquel il correspond.
Donc avoir
<a>Mon titre, page 1</a>
plutôt que
<a>Mon titre</a>, page 1
J'ai pour ma part intégré cette modif au CS installé sur mon site (dans le fichier outils/sommaire_fonctions.php, à la ligne 42, c'est très simple), mais je pense que ce serait bien qu'elle soit intégrée à la distribution standard.

Par ailleurs, il serait préférable d'avoir, par défaut, dans le fichier de langue, "page" plutôt que "p." comme préfixe du numéro de page du sommaire. C'est plus long, mais c'est mieux pour la synthèse vocale. Testé avec Jaws, "p.1" rend littéralement "pé point un"/"pi dot one". Alors que "page 1" est lu correctement. C'est un détail, mais je pense qu'il est préférable de distribuer les fonctions du plugin dans leur version accessible, quitte à ce que les utilisateurs qui ne se préoccupent pas de ces questions (les vilains) remodifient le fichier de langue.

Pour le découpage en pages d'un article, il serait préférable que le tag alt des liens vers les pages soit préfixé par "page #:" (# = numéro de page) pour que le lien soit explicite. Avec seulement le début du texte de la page en question, ce n'est pas très clair pour un non-voyant, par exemple. Ce préfixe devrait être localisé, via le fichier de langue, dans la mesure où le signe ":" prend un espace avant et après en Français, tandis qu'il n'en prend qu'un après en Anglais.

Enfin, je signale une petite anomalie qui apparaît chez moi sur le découpage en pages : lorsqu'un article comprend plusieurs pages, une balise <p class="spip"> est insérée juste avant <a name='decoupe_bas' id='decoupe_bas'></a> et n'est pas refermée. Du coup, le document n'est plus valide en XHTML. Sur un article sans découpage, cette anomalie ne se produit pas, même si le plugin est activé. Je suppose donc que ça provient de la fonction de découpage uniquement.
J'utilise la version 1.7.9.08 du plugin, et cette anomalie se produisait déjà avec la version 1.7.9.06.

Merci aux développeurs qui participent à l'amélioration de ces outils. Je ne suis pas certain d'avoir les capacités de donner un coup de main (je suis ultra-débutant en PHP, et, étant donné que ce n'est pas mon métier, je n'ai pas l'intention de me plonger plus avant dans ce langage), mais si des besoins hors développement existent pour l'amélioration de ces outils, je suis partant (du moins si mon emploi du temps me le permet, ce qui n'est pas le cas avant la fin de ce mois...).

2

Enfin, je signale une petite anomalie qui apparaît chez moi sur le
découpage en pages : lorsqu’un article comprend plusieurs pages, une
balise

est insérée juste avant et n’est pas refermée. Du coup, le document n’est
plus valide en XHTML. Sur un article sans découpage, cette anomalie ne
se produit pas, même si le plugin est activé. Je suppose donc que ça
provient de la fonction de découpage uniquement.
J’utilise la version 1.7.9.08 du plugin, et cette anomalie se produisait
déjà avec la version 1.7.9.06.

Je constate cette anomalie aussi.

–
Jean Philippe

3

mathbouq a écrit :

Pour améliorer l'accessibilité du sommaire, il serait préférable d'intégrer le numéro de page au lien auquel il correspond.
Donc avoir
<a>Mon titre, page 1</a>
plutôt que
<a>Mon titre</a>, page 1
J'ai pour ma part intégré cette modif au CS installé sur mon site (dans le fichier outils/sommaire_fonctions.php, à la ligne 42, c'est très simple), mais je pense que ce serait bien qu'elle soit intégrée à la distribution standard.

Pour quelle raison pratique ce choix-là est-il meilleur?

Par ailleurs, il serait préférable d'avoir, par défaut, dans le fichier de langue, "page" plutôt que "p." comme préfixe du numéro de page du sommaire. C'est plus long, mais c'est mieux pour la synthèse vocale. Testé avec Jaws, "p.1" rend littéralement "pé point un"/"pi dot one". Alors que "page 1" est lu correctement. C'est un détail, mais je pense qu'il est préférable de distribuer les fonctions du plugin dans leur version accessible, quitte à ce que les utilisateurs qui ne se préoccupent pas de ces questions (les vilains) remodifient le fichier de langue.

Il me semble que le fichier de langue spécifie : ',&nbsp;p@page@'. Il n'y a pas de point.
Tes deux propositions alourdissent en effet l'aspect visuel du sommaire que je voulais le plus 'light' possible au départ.
Ne serait-il pas suffisant par exemple de mettre "page" en entier dans le title du lien ?

Pour le découpage en pages d'un article, il serait préférable que le tag alt des liens vers les pages soit préfixé par "page #:" (# = numéro de page) pour que le lien soit explicite. Avec seulement le début du texte de la page en question, ce n'est pas très clair pour un non-voyant, par exemple. Ce préfixe devrait être localisé, via le fichier de langue, dans la mesure où le signe ":" prend un espace avant et après en Français, tandis qu'il n'en prend qu'un après en Anglais.

Ok pour ça, la modif est faite.
A propos des langues du Couteau Suisse, il y a du boulot... N'hésitez pas à faire part de vos propres traductions.

Enfin, je signale une petite anomalie qui apparaît chez moi sur le découpage en pages : lorsqu'un article comprend plusieurs pages, une balise <p class="spip"> est insérée juste avant <a name='decoupe_bas' id='decoupe_bas'></a> et n'est pas refermée. Du coup, le document n'est plus valide en XHTML. Sur un article sans découpage, cette anomalie ne se produit pas, même si le plugin est activé. Je suppose donc que ça provient de la fonction de découpage uniquement.
J'utilise la version 1.7.9.08 du plugin, et cette anomalie se produisait déjà avec la version 1.7.9.06.

Oui, je viens de retirer ces ancres inutiles au profit d'un id : <div id='decoupe_bas' class='pagination decoupe_bas'>

Merci de tes remarques et propositions.

Pat

4

Jean Philippe BLIEK a écrit :

Je constate cette anomalie aussi.

corrigé, merci.

5

Pat a écrit :

mathbouq a écrit :

Pour améliorer l'accessibilité du sommaire, il serait préférable d'intégrer le numéro de page au lien auquel il correspond.
Donc avoir
<a>Mon titre, page 1</a>
plutôt que
<a>Mon titre</a>, page 1
J'ai pour ma part intégré cette modif au CS installé sur mon site (dans le fichier outils/sommaire_fonctions.php, à la ligne 42, c'est très simple), mais je pense que ce serait bien qu'elle soit intégrée à la distribution standard.

Pour quelle raison pratique ce choix-là est-il meilleur?

Il me semble que l'accessibilité est améliorée quand l'ensemble des informations relatives à un lien sont intégrées dans le lien et ne se trouvent pas à côté. Les logiciels d'aide à la navigation permettent notamment de naviguer dans la page en utilisant seulement la liste de liens, sans passer par une lecture complète de la page. Dans ce cas, le logiciel loupe l'information du numéro de page. Ca pose problème pour les utilisateurs d'une synthèse vocale, notamment.

Je n'ai pas Jaws sous la main donc je ne peux pas vérifier, mais il est possible, comme tu le dis plus loin, que renseigner le title du lien avec la version accessible soit suffisant. Je vérifie et je confirme dès que possible.

Par ailleurs, il serait préférable d'avoir, par défaut, dans le fichier de langue, "page" plutôt que "p." comme préfixe du numéro de page du sommaire. C'est plus long, mais c'est mieux pour la synthèse vocale. Testé avec Jaws, "p.1" rend littéralement "pé point un"/"pi dot one". Alors que "page 1" est lu correctement. C'est un détail, mais je pense qu'il est préférable de distribuer les fonctions du plugin dans leur version accessible, quitte à ce que les utilisateurs qui ne se préoccupent pas de ces questions (les vilains) remodifient le fichier de langue.

Il me semble que le fichier de langue spécifie : ',&nbsp;p@page@'. Il n'y a pas de point.
Tes deux propositions alourdissent en effet l'aspect visuel du sommaire que je voulais le plus 'light' possible au départ.
Ne serait-il pas suffisant par exemple de mettre "page" en entier dans le title du lien ?

Effectivement, par défaut c'est ,&nbsp;p@page@, j'avais ajouté le point a posteriori. Mais avec p1, le problème se pose de la même façon qu'avec p.1.

Pour le découpage en pages d'un article, il serait préférable que le tag alt des liens vers les pages soit préfixé par "page #:" (# = numéro de page) pour que le lien soit explicite. Avec seulement le début du texte de la page en question, ce n'est pas très clair pour un non-voyant, par exemple. Ce préfixe devrait être localisé, via le fichier de langue, dans la mesure où le signe ":" prend un espace avant et après en Français, tandis qu'il n'en prend qu'un après en Anglais.

Ok pour ça, la modif est faite.
A propos des langues du Couteau Suisse, il y a du boulot... N'hésitez pas à faire part de vos propres traductions.

Merci pour la prise en compte.
Désolé, je suis un grand débutant... comment faire pour ajouter les fichiers de langue à la distribution par défaut ? Est-ce que moi, simple utilisateur, j'ai le droit de faire des modifications sur svn ?
J'ai un embryon de version anglaise (uniquement les aspects "frontend" du sommaire et du découpage en pages), mais étant donné que c'est à ma portée, dès que j'ai du temps à y consacrer, je complète la traduction et je la soumets (fin novembre au plus tôt).

Enfin, je signale une petite anomalie qui apparaît chez moi sur le découpage en pages : lorsqu'un article comprend plusieurs pages, une balise <p class="spip"> est insérée juste avant <a name='decoupe_bas' id='decoupe_bas'></a> et n'est pas refermée. Du coup, le document n'est plus valide en XHTML. Sur un article sans découpage, cette anomalie ne se produit pas, même si le plugin est activé. Je suppose donc que ça provient de la fonction de découpage uniquement.
J'utilise la version 1.7.9.08 du plugin, et cette anomalie se produisait déjà avec la version 1.7.9.06.

Oui, je viens de retirer ces ancres inutiles au profit d'un id : <div id='decoupe_bas' class='pagination decoupe_bas'>

Merci pour la correction et bravo pour la réactivité.

6

je confirme jaws ne lit jamais les titles sauf changement de la config d'origine ce qui arrive très rarement

Aurélien

Il me semble que l'accessibilité est améliorée quand l'ensemble des informations relatives à un lien sont intégrées dans le lien et ne se trouvent pas à côté. Les logiciels d'aide à la navigation permettent notamment de naviguer dans la page en utilisant seulement la liste de liens, sans passer par une lecture complète de la page. Dans ce cas, le logiciel loupe l'information du numéro de page. Ca pose problème pour les utilisateurs d'une synthèse vocale, notamment.

Je n'ai pas Jaws sous la main donc je ne peux pas vérifier, mais il est possible, comme tu le dis plus loin, que renseigner le title du lien avec la version accessible soit suffisant. Je vérifie et je confirme dès que possible.

7

aurélien levy a écrit :

je confirme jaws ne lit jamais les titles sauf changement de la config d'origine ce qui arrive très rarement

Aurélien

Il me semble que l'accessibilité est améliorée quand l'ensemble des informations relatives à un lien sont intégrées dans le lien et ne se trouvent pas à côté. Les logiciels d'aide à la navigation permettent notamment de naviguer dans la page en utilisant seulement la liste de liens, sans passer par une lecture complète de la page. Dans ce cas, le logiciel loupe l'information du numéro de page. Ca pose problème pour les utilisateurs d'une synthèse vocale, notamment.

Je n'ai pas Jaws sous la main donc je ne peux pas vérifier, mais il est possible, comme tu le dis plus loin, que renseigner le title du lien avec la version accessible soit suffisant. Je vérifie et je confirme dès que possible.

Merci pour la réponse, ça m'évite de chercher. :slight_smile:

Autre suggestion pour améliorer l'accessibilité : ajouter un tag 'accesskey' pour pouvoir accéder directement au sommaire de l'article sans avoir à passer par tout l'en-tête de la page ou de l'article. Quand on couple Sommaire et Découper en pages, ça peut être très utile. La touche correspondant à cet accesskey pourrait être paramétrée dans le fichier de langue.

8

mathbouq a écrit :

A propos des langues du Couteau Suisse, il y a du boulot... N'hésitez pas à faire part de vos propres traductions.

Merci pour la prise en compte.
Désolé, je suis un grand débutant... comment faire pour ajouter les fichiers de langue à la distribution par défaut ? Est-ce que moi, simple utilisateur, j'ai le droit de faire des modifications sur svn ?
J'ai un embryon de version anglaise (uniquement les aspects "frontend" du sommaire et du découpage en pages), mais étant donné que c'est à ma portée, dès que j'ai du temps à y consacrer, je complète la traduction et je la soumets (fin novembre au plus tôt).

Toute personne peut apporter sa contribution. Elle vivement conseillée d'ailleurs, même très modeste. C'est avec des ruisseaux que l'on alimente les fleuves.
Il suffit de demander ici-même l'attribution de codes et d'utiliser SVN, dans la réalisation, c'est très simple au final.
Donc, aucun soucis pour ajouter des fichiers de langue. Le répertoire consacré est 'lang/'. Le fichier à traduire est cout_fr.php, par exemple en cout_en.php ou cout_de.php.

Pat