[spip-dev] Accessibilité des formulaires dans Spip

Bonjour à tous,

Je suis nouvelle sur la liste. Je m’appelle Armony et suis consultante et formatrice spécialisée dans l’accessibilité du Web. Je viens vous soumettre ici un problème important et précis concernant l’accessibilité de Spip, sur le conseil de Jacques Pyrat.

J’ai travaillé avec Jacques à la mise en conformité du site provaltis.net, sous Spip 3, afin qu’il obtienne la labellisation AccessiWeb Argent. Je me suis occupée de l’audit et de la création des gabarits, et Jacques a réalisé les boucles et développements Spip.

Je tiens à préciser que je ne suis pas développeuse, votre aide pour comprendre et corriger le problème me sera d’autant plus précieuse…

Le site a obtenu le label Argent, sous réserve de corriger un point concernant les formulaires qui semble compliqué à régler.

Voici d’abord la règle : quand un contrôle de saisie est prévu sur un formulaire, toute erreur doit être signalée de façon accessible, notamment en modifiant le titre de page. Pour AccessiWeb 2.2, il s’agit du test 11.10.2 : “Pour chaque formulaire, les erreurs de saisie sont-elles indiquées de manière pertinente ?”. Pour RGAA, cela renvoie en particulier au test 3.1.1 : “Possibilité d’identifier les erreurs de saisie”.

Or, à la labellisation, il a été reproché (à juste titre) que si on faisait une erreur dans le formulaire de connexion à l’extranet, aucune information n’était renvoyée, notamment dans le titre de la page (la balise title dans le head devrait contenir la mention : Erreur dans le formulaire).

L’extranet étant dépendant du module formulaire de Spip, Jacques m’a expliqué qu’il ne pouvait pas s’appuyer sur #env pour modifier le title de page.

Auriez-vous une idée ou des conseils à partager pour corriger ce problème ? Je sèche…

Merci d’avance pour votre aide !
Armony

P.S. : évidemment, quand le problème sera corrigé, je ferai une note pour partager les développements faits pour rendre le site accessible, en mettant le squelette à disposition pour ceux que ça intéresse.

Bonjour Armony,

Bonjour à tous,

Je suis nouvelle sur la liste. Je m’appelle Armony et suis consultante et formatrice spécialisée dans l’accessibilité du Web. Je viens vous soumettre ici un problème important et précis concernant l’accessibilité de Spip, sur le conseil de Jacques Pyrat.

J’ai travaillé avec Jacques à la mise en conformité du site provaltis.net, sous Spip 3, afin qu’il obtienne la labellisation AccessiWeb Argent. Je me suis occupée de l’audit et de la création des gabarits, et Jacques a réalisé les boucles et développements Spip.

Je tiens à préciser que je ne suis pas développeuse, votre aide pour comprendre et corriger le problème me sera d’autant plus précieuse…

Le site a obtenu le label Argent, sous réserve de corriger un point concernant les formulaires qui semble compliqué à régler.

Voici d’abord la règle : quand un contrôle de saisie est prévu sur un formulaire, toute erreur doit être signalée de façon accessible, notamment en modifiant le titre de page. Pour AccessiWeb 2.2, il s’agit du test 11.10.2 : « Pour chaque formulaire, les erreurs de saisie sont-elles indiquées de manière pertinente ? ». Pour RGAA, cela renvoie en particulier au test 3.1.1 : « Possibilité d’identifier les erreurs de saisie ».

Or, à la labellisation, il a été reproché (à juste titre) que si on faisait une erreur dans le formulaire de connexion à l’extranet, aucune information n’était renvoyée, notamment dans le titre de la page (la balise title dans le head devrait contenir la mention : Erreur dans le formulaire).

Est-ce que je comprends bien que l’erreur doit absolument être indiquée dans le de la page en sus d’être affichée dans le formulaire, en regard du champ en erreur ?
Mais j’ai un doute car tu indique que « aucune information n’est renvoyée » alors que les formulaires de connexion de SPIP renvoient bien un message d’erreur en regard du login ou du mot de passe en cas d’erreur.
Donc est-ce que :

  • tu n’as pas ces messages d’erreur en regard des champs du formulaire de login ?
  • tu as ces messages d’erreur mais ils ne suffisent pas et doivent être complétés :
  • par un message d’erreur en début de formulaire ?
  • par un title dans la page ?

Cédric

Bonjour,

Du coté du RGAA on n'invalide pas cela comme un erreur dans la mesure où c'est explicitement indiqué dans la page (idéalement avec un hx) mais c'est un vieux débat d'expert sur lequel Accessiweb dans une procédure de labellisation va imposer sa vision des choses effectivement.

Par contre, il a déjà été signalé que l'usage des listes pour formater les formulaires n'est pas idéal sémantiquement et que les messages d'erreurs seraient mieux placés si ils étaient dans le label

Aurélien

OK. Le sachant on peut sans doute automatiser la modification du title à la volée quand un formulaire est en erreur dans la page, avec un message generique.

Oui, j’ai pris note. On pourrait sans doute basculer les

  • en
    pour tous les formulaires du core en v3.1 sans trop casser de chose, et les plugins suivront au fur et à mesure.

    hmmm OK, mais là il faut que l’on regarde comment cela se passe en terme d’affichage quand le label est à gauche et la saisie à droite. Cela nécessite sans doute des aménagements plus qu’à la marge pour ces cas là…

    Cédric

  • Tout à fait. Si, si, mais c’est insuffisant. Pourquoi pas, ce serait une bonne pratique, mais ce n’est pas obligatoire. C’est exactement ça. Et c’est ce qui invalide la labellisation actuellement. Par ailleurs, pour réagir au mail d’Aurélien quand il écrit : Cette vision des choses est en effet “imposée” par BrailleNet, de la même manière que le RGAA impose sa vision via son interprétation des WCAG, tout le monde pensant faire au mieux pour les utilisateurs. Je voudrais juste expliquer pourquoi c’est important, du point de vue de BrailleNet (et de mon point de vue également). En validant un formulaire, on est en droit de penser qu’on a réussi à se connecter. En l’occurrence, quand on est aveugle, il est difficile de le savoir à moins de parcourir la page. Or, quand il y a une erreur, la page est rechargée. La première chose qui sera lue par un lecteur d’écran, c’est le titre de la page. En informant qu’il y a une erreur dès le titre de la page, l’utilisateur sait qu’il va devoir recommencer l’opération et se déplacer jusqu’à la zone de formulaire, et à cet endroit, les erreurs sont bien mentionnées. Aurélien écrit aussi : Pour le coup, c’est sûr que ce serait mieux, mais c’est moins pénalisant (et donc moins urgent) pour l’utilisateur que l’absence d’information au rechargement de la page… Et il serait dommage de considérer que Spip ne permet pas une labellisation AccessiWeb… Cédric, aurais-tu un conseil pour corriger le formulaire et lui ajouter la mention “erreur” dans le title de page ? Merci encore pour ton aide. Armony

    bonjour,
    votre fil est très intéressant.
    de mémoire on retrouve ce type de problème avec les blocs ajax qui modifient le contenu d'une page sans avertir la personne en situation de handicap visuel.

    oh je ne crois pas que SPIP empêche quoi que ce soit :))

    Ce qui me vient tout de suite à l’esprit c’est un javascript sous le formulaire, qui regarde si il y a des messages d’erreur affichés sur les champs des formulaires et modifie le en conséquence. C’est techniquement assez simple à réaliser et ça n’oblige pas a modifier quoi que ce soit de SPIP. Mais c’est imparfait car cela repose sur javascript.

    La seconde option, un petit peu plus compliquée, consiste à analyser la page côté serveur pour faire la même chose, dans le pipeline affichage_final, cela peut se faire en plugin sans modifier SPIP non plus. Mais c’est sans doute plus dispendieux en ressources machines que la première option.

    La troisième option, peut être optimale, consiste à se brancher sur la gestion d’erreur des formulaires et à lever un flag en cas d’erreur, puis à l’utiliser pour modifier le à la volée comme dans le second cas, côté serveur. C’est la meilleure solution car peu couteuse en ressources machines, mais si on la généralise comme ça d’un coup on risque d’avoir des faux positifs car les formulaires génèrent parfois de « fausses » erreurs internes pour des besoins fonctionnels. On ne peut pas introduire cela sur une version mineure, mais en 3.1 je pense que ce doit être possible.

    Cédric

    Bonjour

    Cette vision des choses est en effet « imposée » par BrailleNet, de la même manière que le RGAA impose sa vision via son interprétation des WCAG, tout le monde pensant faire au mieux pour les utilisateurs.

    Oui quoi le degré de flexibilité de la mise en oeuvre de RGAA est tout de même plus grand de part son aspect autodéclaration (avec ses avantages et ses inconvénients je te l’accorde) mais là n’est pas le débat je ne vais donc pas insister là dessus

    Je voudrais juste expliquer pourquoi c’est important, du point de vue de BrailleNet (et de mon point de vue également). En validant un formulaire, on est en droit de penser qu’on a réussi à se connecter. En l’occurrence, quand on est aveugle, il est difficile de le savoir à moins de parcourir la page. Or, quand il y a une erreur, la page est rechargée. La première chose qui sera lue par un lecteur d’écran, c’est le titre de la page. En informant qu’il y a une erreur dès le titre de la page, l’utilisateur sait qu’il va devoir recommencer l’opération et se déplacer jusqu’à la zone de formulaire, et à cet endroit, les erreurs sont bien mentionnées.

    C’est bien pour cela que j’ai précisé que cela devait à minima être présent dans la page notamment via un Hx.

    Aurélien écrit aussi :

    Par contre, il a déjà été signalé que l’usage des listes pour formater les formulaires n’est pas idéal sémantiquement et que les messages d’erreurs seraient mieux placés si ils étaient dans le label

    Pour le coup, c’est sûr que ce serait mieux, mais c’est moins pénalisant (et donc moins urgent) pour l’utilisateur que l’absence d’information au rechargement de la page…

    l’information n’est pas absente… et pour le coup pour l’utilisateur voyant elle n’est pas très visible non plus.
    Je ne suis pas entrain de dire qu’il ne faut pas le faire et si Cedric (ou qqun d’autre) veut le faire ou le rendre possible il est évidemment le bienvenue mais entre ça et la restitution correcte des messages d’erreurs mon choix est vite fait et il ne va pas du coté de la modif du titre de page qui pour moi un goût de surqualité
    ( je vous invite à lire cela d’ailleurs : ) Aurélien

    Bonjour,

    Je suis BoOz de BoOz Consulting International ™, une entreprise proactive qui travaille régulièrement pour aider Accenture et Cap Gemini sur leur dossier les plus complexes.

    Je pense que vous auriez obtenu le label Or avec un tel Projet, en vous adressant à moi.

    Bonne journée.

    BoOz

    Visit my website : http://BoOz.international-consulting.com

    Label Microsoft Excellence

    Google Dev Partner

    PS : cette petite blague pour signaler qu’on peut très bien communiquer avec la liste sans faire de “promo” pour des structures commerciales. Un peu comme dans les émissions de télévisions sur le service public quand ils s’efforcent de ne pas citer les marques. “Une entreprise de conseil” etc…

    ce site c'est du pipô. il n'y a même pas de formulaire pour
    avoir un devis.
    à déconseiller donc.

    Salut,

    Un solution perfectible à la suite.

    * Denis Chenu tapuscrivait, le 30/03/2013 14:29:

    Salut,

    Un solution perfectible à la suite.

    Or, à la labellisation, il a été reproché (à juste titre) que si on
    faisait une erreur dans le formulaire de connexion à l'extranet, aucune
    information n'était renvoyée, notamment dans le titre de la page (la
    balise title dans le head devrait contenir la mention : Erreur dans le
    formulaire).

    Dans squelettes/login.html

    <title>[(#ENV**{formulaire_action_args}|oui)Une erreur est survenue -
    ]Connexion à l'espace privé[ de (#NOM_SITE_SPIP|textebrut)]</title>

    Merci, ça marche !
    En l’occurrence, comme le title était dans un INCLURE, j'ai dû rajouter des ,env dans les appels.

    Bonsoir à tous,

    Désolée de répondre avec retard.

    Je réponds dans le désordre.

    D’abord, un GRAND merci à Denis Chenu pour ta solution !!!

    Concernant la remarque de BoOz :

    cette petite blague pour signaler qu’on peut très bien communiquer avec la liste sans faire de « promo » pour des structures commerciales. Un peu comme dans les émissions de télévisions sur le service public quand ils s’efforcent de ne pas citer les marques. « Une entreprise de conseil » etc…

    j’imagine que j’ai dû égratigné un code de communication connu des seuls initiés dans ma présentation. Je n’ai pas cherché à faire de « promo » mais juste à situer le contexte de la manière la plus précise. Et il m’a semblé utile et pertinent de donner le lien du site dont on parle, histoire de voir le code. Toutes mes excuses si certains d’entre vous ont été « choqués », ça ne m’a pas effleuré l’esprit. Il serait pertinent à l’avenir de faire signer une charte avec des mentions indiquant très clairement ce qu’il est admis ou non, histoire de ne pas se faire « rappeler à l’ordre » à la moindre écartade… et de faire ainsi passer la communauté pour des gens peu accueillants pour les nouveaux. Mes deux centimes.

    Pour répondre à Cédric : D’abord un grand merci pour tes réponses et tes pistes.

    Cédric écrit :

    oh je ne crois pas que SPIP empêche quoi que ce soit :)) [en réponse à ma citation disant que Spip pourrait empêcher une labellisation]

    C’est vrai, et c’est le cas de tout logiciel libre. À partir du moment où on a accès aux sources, il est toujours possible de le modifier. Cette liste concentre sans doute le top des développeurs spipiens, et il est vrai que je ne suis qu’une pauvre intégratrice (issue d’une formation littéraire, malheureuse !) sans connaissances en développement. Mais je crains que comme moi, de nombreuses personnes utilisent Spip sans plus de connaissances. Se dire que l’accessibilité est prise en compte dès le départ, sans avoir à faire de développement spécifique, est un atout et me permet de le recommander les yeux fermés.

    Je suis d’ailleurs heureuse (et pas du tout surprise) de savoir que la modification sera prise en compte lors d’une prochaine version 3.1. Bref, merci Cédric ! :slight_smile:

    Pour répondre à Aurélien :

    Oui quoi le degré de flexibilité de la mise en oeuvre de RGAA est tout de même plus grand de part son aspect autodéclaration (avec ses avantages et ses inconvénients je te l’accorde) mais là n’est pas le débat je ne vais donc pas insister là dessus

    C’est vrai, la flexibilité du RGAA est telle qu’on peut faire un site inaccessible et conforme RGAA, il suffit de déclarer des exceptions. Ceci dit, c’est la même chose avec AccessiWeb tant qu’on n’est pas dans une procédure de labellisation.

    Tant qu’on s’en sert comme d’un outil, WCAG, RGAA ou AccessiWeb peuvent être utilisés avec toute la souplesse requise conformément aux contraintes du projet. Bref, nous sommes d’accord à ceci près que le RGAA n’est pas le seul à le permettre.

    Aurélien écrit encore :

    entre ça et la restitution correcte des messages d’erreurs mon choix est vite fait et il ne va pas du coté de la modif du titre de page qui pour moi un goût de surqualité

    Ah, la surqualité ! Je suis en train de lire un livre très intéressant qui définit la surqualité comme suit : « bonnes pratiques […] dont la valeur pour l’utilisateur final serait réduite dans le contexte particulier du site et […] dont le coût pourrait pénaliser la production de nouveaux contenus ou l’enrichissement des services proposés » (Livre Qualité web, p.216).

    Or, le contexte particulier du site est celui d’une labellisation. Peut-on faire de l’accessibilité sans être labellisable ? Oui, et heureusement ! Pourquoi certains souhaitent-ils se faire labelliser ?

    1. pour s’assurer du niveau d’accessibilité réel par un organisme indépendant (on ne compte plus les charlatans. Cf billet de blog d’Olivier Nourry « 5 bonnes raisons de coller une droite à un expert en accessibilité »

    2. pour communiquer et valoriser leurs efforts (à des fins vilement commerciales penseront certains)

    Et qui dit labellisation, dit respect strict du référentiel pour l’obtenir (les certifications ISO ne sont pas mieux loties avec leur paperasserie dont on cherche parfois l’utilité réelle).

    Alors, à moins de dire que tout processus de labellisation EST de la surqualité, je ne vois vraiment pas ce que cet « argument » vient faire là. Sans compter que l’intérêt pour l’utilisateur aveugle d’un titre de page mentionnant l’erreur dans un formulaire est réel.

    Désolée de répondre avec retard.l serait pertinent à l'avenir de faire signer une charte avec des mentions indiquant très clairement ce qu'il est admis ou non, histoire de ne pas se faire "rappeler à l'ordre" à la moindre écartade... et de faire ainsi passer la communauté pour des gens peu accueillants pour les nouveaux. Mes deux centimes.

    Justement je me demander s'il exister quelque part des chartes pour ecrire, participer, communiquer dans la galaxie Spip

    je croie savoir que pour spipzone il y a quelque chose
    que Jluc a ecrit un truc quelque part sur l'ecriture , mais je remet plus la main dessus

    donc toute amélioration, proposition pour que le lien de "Je veux contribuer" sur contrib arrive sur autre chose qu'un lien d'inscription
    http://contrib.spip.net/spip.php?page=inscription

    mais sur un véritable article explicatif sur les différents possibilité ... pour "Contribuer, Participer, Aider"

    Héhé, ok j’ai peut-être dégainé un peu vite.

    Bienvenue.

    BoOz

    Bonjour

    C’est vrai, la flexibilité du RGAA est telle qu’on peut faire un site inaccessible et conforme RGAA, il suffit de déclarer des exceptions.

    oui tout comme tu peux faire un site conforme WCAG et également inaccessible voit un site conforme ce que tu veux vu que personne ne peut garantir l’accessibilité d’un site à tous.

    Ceci dit, c’est la même chose avec AccessiWeb tant qu’on n’est pas dans une procédure de labellisation.

    c’est tout à fait exact

    Alors, à moins de dire que tout processus de labellisation EST de la surqualité, je ne vois vraiment pas ce que cet « argument » vient faire là. Sans compter que l’intérêt pour l’utilisateur aveugle d’un titre de page mentionnant l’erreur dans un formulaire est réel.

    oui sauf que TON contexte projet N’EST PAS LE CONTEXTE projet de spip dans son ensemble et de tous les gens qui utilise spip. En cas de choix sur des correctifs accessibilité à intégrer dans le core, le bénéfice d’avoir des messages d’erreurs correctement restitués me parait largement plus profitable à l’ensemble de utilisateurs que de répondre à ton contexte de labellisation spécifique. C’est dans ce sens que je parle de surqualité.
    Maintenant je suis heureux de voir qu’encore une fois la communauté Spip a su répondre rapidement avec une solution simple et efficace qui satisfera ton contexte et sera comme tu l’as dit un élément facilitant la vie de l’utilisateur.

    A bientôt

    Aurélien

    Cela reste bancale, et utilisable uniquement pour le login. En effet sur
    la page de message ou commentaire: il doit y avoir des
    #ENV**{formulaire_action_args} au moment de la confirmation de l'envoi.
    On ne sait donc pas si il y a eu erreur ou si c'est juste le message de
    confirmation.

    Il reste, AMHA, intéressant d'avoir dans le ENV les erreurs éventuelles.

    Denis
    Denis