SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano

278 Plugins, 195 contribs sur SPIP-Zone, 23 visiteurs en ce moment

Accueil > Documentation > Supports de formations à SPIP > Accessibilité > Accessibilité pour les rédacteurs

Accessibilité pour les rédacteurs

17 août 2010 – par goetsu, RealET – 16 commentaires

29 votes

SPIP est un CMS largement répandu dans la sphère publique. Tout les jours des centaines de webmestres gérant des services de communication publique en ligne utilisent SPIP pour mettre leur contenu en ligne que ce soit dans de petites communes ou de très grand Ministère.

Depuis le 29 octobre 2009, les services de communication publique en ligne doivent se mettre en conformité par rapport au Référentiel Général d’Accessibilité pour les Administrations (RGAA) qui demande à ce que les sites web publics soient accessibles au plus grand nombre, notamment les personnes en situations de handicaps.

L’objectif de cet article n’est pas de présenter le contenu du RGAA ou l’intérêt d’une démarche d’accessibilité mais de voir thématique par thématique en quoi SPIP permet, nativement ou avec quelques ajouts, de produire du contenu accessible pour un rédacteur.

Images

Les règles :

Lors de l’inclusion d’image dans un article le rédacteur doit pouvoir :

  • spécifier l’alternative courte des images
  • spécifier une description dite longue reprenant l’ensemble des informations apportés par l’image (par exemple : toutes les informations récupérables sur un graphique statistiques).
  • spécifier la langue de l’alternative si elle est différente de la langue de la page

Ces alternatives doivent être adaptées au contexte d’utilisation de l’image en fonction de la façon dont elle est utilisée (alt=’’ si décorative, alt=’fonction du lien’ si image lien, alt=’information apportée par l’image’ si l’image est porteuse d’information).

Les images dans SPIP :

Pour l’heure, il est possible d’insérer une image dans un article à l’aide des modèles <imgXX>, <imageXX>, <docXX> ou <embXX>. Le fonctionnement par défaut des modèles prévoit :

  • un attribut alt=’’ si l’utilisateur ne spécifie rien
  • un alt=’titre’ si le rédacteur spécifie un titre à l’image.
  • un alt=’format de l’image ou du document – poids de l’image ou du document’ si c’est un lien vers un document avec icône du format (raccourci doc).

Ces comportements sont bons mais ils présentent néanmoins quelques problèmes.

Les problèmes :

  • Aucune gestion des descriptions longues
  • Un titre = Une alternative, il est donc impossible d’avoir des alternatives adaptés aux différents contextes d’utilisation d’une même image.
  • Aucune gestion des changements de langue

Les solutions :

Utiliser le plugin accessibilité qui modifie les modèles <imgXX>, <imageXX>, <docXX> et <embXX> afin de pouvoir par défaut :

  • spécifier une description longue. Pour cela il suffit de renseigner une description dans la base de données. Si vous souhaitez avoir une description et un titre visible différent de ceux enregistrés dans la base de donnée (raccourci <docXX>) il est possible d’utiliser des paramètres supplémentaires sur les modèles sous la forme : <docXX|titre=titre de votre document/image|legende=legende de votre document/image>
  • spécifier une alternative différente du titre de l’image lorsqu’il y en a un enregistré dans la base de donnée en utilisant un paramètre supplémentaire sur les modèles sous la forme : <imgXX|alt=votre alternative>
  • spécifier une langue pour votre alternative en utilisant un paramètre supplémentaire sur les modèles sous la forme : <imgXX|lang=le code de la langue utilisé>

Ce qui donnerait pour une image avec une alternative en anglais

<imgXX|alt=your text alternative even if there is already a title to the image defined in the database|lang=en>

Multimédia

Les règles :

Le rédacteur insérant un contenu multimédia dans son contenu devra porter attention à :

  • fournir une alternative/un transcript aux éléments multimédia (exemple si l’utilisateur n’a pas le plugin flash il aura l’alternative) ;
  • proposer des sous-titres et une piste d’audio description si nécessaire ;
  • laisser le contrôle à l’utilisateur de la lecture, du son, des éléments clignotants, flashant et mouvant ;
  • produire du code HTML valide dans la méthode d’insertion de l’élément multimédia.

Le multimédia dans SPIP :

Il est possible d’insérer une vidéo, un son ou une animation Flash dans un article Spip à l’aide des raccourci <embXX>,<audioXX>,<videoXX>,<audioXX>. Par défaut ce raccourci essai d’afficher l’élément multimédia avec le lecteur adapté et affiche si ils sont défini dans la base de donnée le titre et le descriptif en dessous.

Les problèmes :

  • Il est impossible de définir un contenu qui s’insérera dans la balise object et servira d’alternative.
  • Le code html produit n’est pas toujours conforme aux spécifications HTML à cause de l’utilisation de la balise <embed>

Les solutions :

  • Mettre un lien juste après l’élément multimédia pointant vers un autre article SPIP ou vers un fichier en téléchargement (dans un format accessible) contenant l’alternative.
  • Utiliser les modèles de documents accessible du plugin accessibilité pour éviter l’utilisation de balise <embed> et pouvoir également spécifier une alternative en utilisant un paramètre supplémentaire sur les modèles sous la forme : <embXX|alternative=votre texte alternatif pour votre élément multimédia>

Pour ce qui concerne le sous-titrage et l’audio-description : soit ces éléments sont incrustés nativement dans la vidéo, soit ils doivent être mis en pièce jointe à l’article et synchroniser au travers de l’utilisation d’un modèle spécifique de player vidéo supportant le sous-titrage et l’audio description (par exemple le Jwplayer ; à noter que portage du jwplayer plus complet dans le plugin accessibilité est également prévu)

Pour ce qui concerne le contrôle des animations / vidéos les éléments doivent eux-mêmes être contrôlable par l’utilisateur, SPIP ne pourra rien pour vous.

Mais le plugin Vidéo Accessible a été créé pour répondre explicitement aux problématiques d’accessibilité des vidéo !

Texte

Les règles :

Un texte peut parfois être difficile à comprendre pour un lecteur notamment à cause de passage dans une langue différente, de l’utilisation d’acronymes ou d’abréviation, ou de mot complexe. Il est alors nécessaire de :

  • signaler les changements de langue à l’aide de l’attribut lang=’code de langue’ pour les passages de textes, les mots et les attributs dans une langue différente de celle du contenu principale de la page. L’indication du changement de langue permet notamment aux utilisateurs de lecteur d’écrans qui restitue vocalement les textes de parler dans la bonne langue.
  • signaler les abréviations et les acronymes à l’aide de la balise <abbr> et <acronym>
  • mettre des liens vers un lexique/glossaire/dictionnaire/encyclopédie pour les mots complexes.

Le texte dans SPIP :

SPIP est nativement multilingue, il permet de déclarer la langue d’un article et de son site. Il est particulier de préciser qu’un contenu est en langue parlée complétée, langue des signes française ou français simplifié (à activer dans la page de gestion des langues). Néanmoins il n’est pas aussi performant quand il s’agit des changements de langue dans un texte. Il permet également d’insérer des liens vers Wikipédia à l’aide du raccourci [?xxx].

Les problèmes :

Il n’existe aucun raccourci pour déclarer les changements de langue au sein d’un article, pour déclarer les acronymes et les abréviations et pour faire facilement un glossaire interne.

Les solutions :

  • Pour les images utiliser les modèles de document accessible de plugin accessibilité permettant de définir la langue sur les balises images
  • Utiliser la lame décoration du plugin couteau suisse pour créer des raccourcis typographiques supplémentaires permettant de signaler les changements de langue dont vous avez besoin. Une configuration possible de cette lame est la suivante :

Vous disposerez alors des raccourcis suivant <en></en>,<de></de>,<es></es>,<it></it>,<bloc-en></bloc-en>,<bloc-de></bloc-de>,<bloc-es></bloc-es>,<bloc-it></bloc-it> à utiliser sur les mots ou bloc de texte en anglais, allemand, espagnol ou italien. Exemple :
Phrase en français avec <en>some words in english</en>.

<bloc-en>Block of text in english.

With some paragraphs inside</bloc-en>

Autre solution pour indiquer le changement de langue

Cette solution est meilleure que celle du Couteau Suisse.

Structuration

Les règles :

Le contenu textuel doit être correctement structuré afin de faciliter sa lectuer et sa restitution au sein des aides techniques. Cela passe notamment par :

  • l’utilisation d’intertitre dans vos textes
  • l’utilisation de liste ordonnées et non ordonnées
  • l’utilisation de citation

La structuration des textes dans SPIP :

SPIP permet nativement de créer des intertitres qui seront transformé en <h3> par l’intermédiaire du raccourci {{{votre intertitre}}}.

Il permet la création de liste ordonnée et non ordonnée par l’intermédiaire des raccourcis -# et -* (<ol> et <ul>).

Enfin, il permet de définir des passages de texte comme étant des citations courtes ou longues grâce au raccourci <quote>citation</quote>.

Les problèmes :

  • SPIP ne gère qu’un seul niveau d’intertitre et il peut parfois être nécessaire de structurer son texte de façon plus complète (comme dans cet article où j’ai dût artificiellement utiliser le gras pour matérialiser un 2e niveau d’intertitre)
  • l’utilisateur peut commencer une suite de paragraphes par un – ce qui aura pour effet de simuler visuellement une liste non ordonnées mais ne la balisera pas comme tel
  • On peut avoir besoin de faire une citation à l’intérieur d’un paragraphe.
  • Il faudrait pouvoir indiquer la langue, et la source de la citation

Les solutions :

  • Utiliser le plugin « Enluminures Typographiques V3 pour Porte Plume » afin de disposer de raccourcis typographiques permettant de gérer des niveaux d’intertitres supplémentaires à l’aide de {{{** intertitre de niveau deux }}} et {{{*** intertitre de niveau trois }}}
  • Activer dans la configuration du plugin l’option permettant de transformer les paragraphes commençant par ’-’ par de vraies listes à puces. Cela se fait grâce à la globale $GLOBALS['barre_typo_pas_de_fausses_puces'] = true; ou est réglable dans la page de configuration du plugin.
  • il peut également être utile d’ajouter dans votre fichier config/mes_options.php la configuration suivante :
    1. <?php
    2. $GLOBALS['barre_typo_pas_de_fork_typo'] = false; // Pour tenir compte de http://zone.spip.org/trac/spip-zone/changeset/22723 et disposer des raccourcis typo supplémentaires !
    3. $GLOBALS['debut_italique'] = "<em$class_spip>";
    4. $GLOBALS['fin_italique'] = '</em>';?>

    Télécharger

Pour les citations, le plugin Accessibilité rajoute un modèle pour gérer finement les citations.

Exemple :

Ceci est une citation : <citation|type=courte|texte=SPIP, la création du plaisir|langue=fr|cite=http://www.spip.net/>

<citation|cite=http://www.spip.net/|langue=fr|texte=100 fois sur le métier
_ tu boucleras ton ouvrage.|auteur=RealET|titre=Bouclage>

-  citation courte

  • |type=courte
  • texte=Texte de la citation
  • langue=code de la langue (fr, de, en, ...)
  • cite=URL de la source de la citation

-  citation sous forme de bloc

  • texte=Texte de la citation
  • langue=code de la langue (fr, de, en, ...)
  • cite=URL de la source de la citation
  • titre=Titre du lien affiché sous la citation
  • auteur=Nom de l’auteur affiché sous la citation

Tableau

Les règles :

  • donner un titre à vos tableaux de données pour décrire brièvement son contenu,
  • donner un résumé précisant l’organisation du contenu dans le tableau
  • Utiliser des entêtes dans vos tableaux afin de pouvoir y rattacher le contenu des cellules et faciliter la compréhension de son contenu.

Les tableaux dans SPIP :

SPIP gère nativement les tableaux de données simples organisés verticalement et permet de préciser un titre, un résumé et des entêtes au tableau. Cela ce fait à l’aide de la syntaxe suivante :

  1. ||Légende|Résumé||
  2. | {{Nom}} | {{Date de naissance}} | {{Ville}} |
  3. | Jacques | 5/10/1970 | Paris |
  4. | Claire | 12/2/1975 | Belfort |
  5. | Martin | 1/31/1957 | Nice |
  6. | Marie | 23/12/1948 | Perpignan |

Télécharger

Les problèmes :

SPIP ne permet pas de gérer les tableaux de données complexe organisés horizontalement ou verticalement et horizontalement.

Les solutions :

Il n’existe malheureusement pas à l’heure actuelle de solution à ce problème. La solution la plus simple consiste à faire son tableau au sein d’un éditeur HTML permettant de structurer un tableau de donnée de façon accessible et de coller le code au sein du champ texte de SPIP.

Navigation

Les règles :

  • avoir des intitulés de liens explicites
  • indiquer les ouvertures dans une nouvelle fenêtre, les formats/poids de fichier en téléchargement
  • avoir une table de matière quand l’article est long

La navigation dans SPIP :

SPIP permet dans un article de placer de liens par l’utilisation du raccourci [texte->url]. Il est également possible de définir des ancres [<-monancre] et des infos bulles sur les liens [texte| info bulle->url]. Spip ne permet pas par défaut d’ouvrir des liens dans une nouvelle fenêtre. Enfin Spip ajoute automatiquement le format et le poids dans l’alternative de l’icone des documents insérés dans un article à l’aide <docXX>

Les problèmes :

Pas de problème en particulier mais il existe néanmoins des solutions facilitant la tache du rédacteur.

Les solutions :

  • Utiliser la lame sommaire automatique du couteau suisse pour créer automatiquement des sommaires à vos articles
  • Utiliser le plugin accessibilité pour ajouter automatiquement les formats et les poids quand un lien vers un document est inséré (attention cela ne traite que les liens vers des fichiers docXX [xxx->docXX] et non les liens vers des urls directes [xxx->http://www.xxx.com/xxx.pdf]

Conclusion

Vous voilà désormais bien armé pour permettre à vos rédacteurs de produire du contenu accessible ou les aider à le faire.

Voir en ligne : http://plugins.spip.net/accessibilite

P.-S.

Un article complémentaire vous listant les éléments nécessaire coté squelette devrait suivre dès que goetsu aura un moment. D’ici là bonne production de contenu accessible.

Retour en haut de la page

Tout afficher

Vos commentaires

  • Le 6 avril 2011 à 12:30, par freebsnet En réponse à : Accessibilité pour les rédacteurs

    bonjour,
    concernant les sommaires automatiques le plug-in table des matières ne fait-il pas aussi l’affaire ?

    Répondre à ce message

  • Le 14 février 2011 à 12:54, par E-cosystems En réponse à : Accessibilité pour les rédacteurs

    Bonjour,

    Merci pour ce plugin ! (qui je pense devrait être de base dans Spip...)

    Bref, petite remarque.
    Quand on va vers « recherche » le plugin fait son boulot. Cependant, il n’est pas possible de taper quelque chose directement. N’est ce pas là un problème d’accessibilité ?

    Est ce possible à intégrer ?

    Merci à tous les contributeurs et contributrices !

    • Le 14 février 2011 à 13:04, par E-cosystems En réponse à : Accessibilité pour les rédacteurs

      Argh, autant pour moi, je voulais envoyer ce message à Skiplink ;)

      ENtre les différent plugin utilisé, je m’étais emmêlé les pinceaux !

    Répondre à ce message

  • Le 3 février 2011 à 21:27, par freebsnet En réponse à : Accessibilité pour les rédacteurs

    Merci beaucoup pour tout ce travail,
    je m’interroge tout de même sur plusieurs choix fait dans les modèles,
    Pour le modèle citation c’est les paramètres titre et langue qui sont utilisés

    1. <citation|cite|langue|texte|auteur|titre>

    alors que dans les modèles abréviations et acronymes c’est title et lang qui sont utilisés

    1. <abbr|title|lang|texte>
    1. <acronym|title|lang|texte>

    est ce volontaire ?
    1) ça va être dur de mémoriser title pour mes rédacteur(trice)s qui n’ont jamais pratiqué l’anglais, :’(
    2) une fois faut mettre title et lang et une autre titre et langue ça va pas être simple à retenir :’(
    3) un paramètre cite qui à comme valeur l’url d’un Site :-\
    3) je pourrai corriger mais à la prochaine mise à jour va falloir que j’y pense :-(
    Bref y a peu être une explication mais ça m’échappe.

    Répondre à ce message

  • Le 28 décembre 2010 à 15:17, par Patrice Vanneufville En réponse à : Accessibilité pour les rédacteurs

    Bravo pour cet article très détaillé.

    A propos des balises du Couteau Suisse et de ses lames « Décorer ou colorer vos textes », il existe aussi les balises automatiques qui adaptent un <div/> ou un <span/> en fonction du contexte :

    auto.en.lang = en
    auto.de.lang = de
    auto.it.lang = it
    auto.es.lang = es

    Répondre à ce message

  • Le 8 septembre 2010 à 20:58, par Vincent François En réponse à : Accessibilité pour les rédacteurs

    Bravo pour ces solutions pratiques d’accessibilité !

    Répondre à ce message

  • Le 19 août 2010 à 22:44, par tetue En réponse à : Accessibilité pour les rédacteurs

    Merci pour cet article ! Pour signaler des liens ouvrant une nouvelle fenêtre, un plugin fait ça bien : « Liens sortants ouvrants ».

    Répondre à ce message

  • Le 19 août 2010 à 01:22, par davux En réponse à : Accessibilité pour les rédacteurs

    C’est une super idée de se préoccuper des questions d’accessiblité. Notamment je trouve très pertinente l’idée de proposer un guide des bonnes pratiques et des options de configuration malines dans SPIP pour créer des sites plus accessibles.

    En revanche, je ne comprends pas l’approche « plugin » : ce que SPIP doit améliorer en termes d’accessibilité devrait se proposer dans le core directement (par exemple une amélioration directe des modèles, sous forme de paramètre optionnel au pire). Contrairement à OpenID ou aux grappes, l’accessibilité n’est pas un besoin qui concerne seulement certains sites et pas d’autres. Si une solution technique pour l’accessibilité a un coût qui pourrait faire qu’on y renonce, alors elle n’est pas bonne.

    À la limite, si plugin il doit y avoir, alors ça devrait être des plugins délimités et dénommés par fonctionnalité plutôt qu’un seul plugin « accessibilité », qui n’est pas une fonctionnalité en tant que telle.

    • Le 19 août 2010 à 10:27, par goetsu En réponse à : Accessibilité pour les rédacteurs

      Pour certaines des fonctionnalités c’est également ce pourquoi j’ai plaidé pendant un temps certains (ma première intervention en la matière date de 2005) mais à défaut de les voir intégrer au corps, il est tout de même utile qu’elles existent en dehors. Peut être certaines finiront elles par être intégrées.

      Si tu lis bien la contrib, il y a effectivement plusieurs plugins et celui contenant les modèles de document etait d’ailleurs au début un simple jeu de « modèle de document accessible ».

      L’idée à terme est donc plutôt de référencer tout les besoins/plugins/options existant, de combler les manques dans ce plugin accessibilité ou de façon indépendante.

    Répondre à ce message

  • Le 17 août 2010 à 14:02, par Loiseau2nuit En réponse à : Accessibilité pour les rédacteurs

    Bravo et Merci les gars ;)

    par contre :

    Pour une gestion centralisée des abréviations et des acronymes, utilisez les plugins Forms et Tables 2.0 et Acronymes il vous suffira alors de renseigner dans la base de donnée un acronyme ou une abréviation pour qu’il soit automatiquement balisé correctement

    En dehors du fait que f&t n’est plus développé depuis un moment, remplacé qu’il a été par Formidable qui fait le même boulot mais en vachement mieux et sans les bugs des versions forkées, j’avoue ne pas comprendre ce qu’un outil à créer du formulaire vient faire dans la gestion des accronymes en fait ?

    Un petit éclaircissement svp ???

    Répondre à ce message

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Nivo Slider

    2 mars 2011 – 354 commentaires

    Nivo Slider pour SPIP permet d’intégrer des diaporamas en JQuery dans vos articles et squelettes.

  • Mosaïque

    21 septembre 2012 – 33 commentaires

    Ce plugin permet d’organiser les images du portfolio par simple glisser-déposer des vignettes d’une mosaïque accessible depuis la page d’édition de l’article. Dépendances Ce plugin nécessite les plugins Champs extra et Saisies pour fonctionner. (...)

  • Plugin Analyclick - un compteur de téléchargements

    26 février 2011 – 102 commentaires

    Ce plugin permet de compter les téléchargements de documents sur son site. Il introduit une balise #URL_DOC_COMPTEUR qui va compter chaque clic fait sur ce lien. Il affiche une page de statistique. Avertissement Le passage en SPIP v.3 est en (...)

  • Agenda 2.0

    3 novembre 2008 – 923 commentaires

    Voici la version pour SPIP 2.0 du Plugin Agenda pour SPIP 1.9.2, avec une interface remaniée pour encore plus de plaisir. Pour une documentation concernant l’utilisation d’Agenda 3 pour SPIP 3, veuillez pour l’instant vous référer à SPIP 3, Agenda (...)

  • elFinder

    1er avril – commentaires

    Ce plugin permet de parcourir l’arborescence de son site SPIP grâce au gestionnaire de fichiers Elfinder. Principe Ce plugin permet aux administrateurs de parcourir l’arborescence d’un site SPIP à travers un outil ressemblant à un gestionnaire de (...)