Back-office pour non voyant

Je recherche un cms qui aurait un back-office accessible au non voyant.
Je souhaite créer un site qui serait destiné aussi bien aux voyants qu'aux non-voyants, mais la personne qui serait en charge de le mettre à jour est non-voyante.

Étant intégrateur/webdesigner la partie front ne me fait pas trop peur, mais ne développant pas je ne peux pas créer la partie back-office.

Je me suis donc mise à la recherche d'un cms du type joomla, wordpress etc... qui pourraient me faciliter la vie et celle de mon amie ...

C'est pourquoi je viens vous solliciter pour savoir si vous connaissez un cms ayant un back-office accessible aux non-voyants.

merci

Bonjour et bienvenue,

quelques pistes : Contao un CMS qui fait tourner par exemple http://accessiweb.org , WordPress récent (je n'ai pas testé l'interface d'édition), Drupal. SPIP aussi (je me suis arrêté à SPIP 2.2, ça date beaucoup mais l'interface d'édition qui n'est par défaut pas graphique mais à base d'accolades et autres codes exprimant la sémantique à donner au contenu et non de la mise en forme peut être plus agréable... ou pas du tout, à tester)

J'ai testé wordpress il n'y a pas si longtemps. Aux dernières nouvelles, c'est utilisable avec un lecteur d'écran, mais ça reste quand même assez compliqué et largement usine à gaz. Niveau productivité et confort, on peut largement mieux faire.

IL y a des options d'accessibilité pour ne pas avoir à utiliser le drag&drop par exemple, mais rien que pour trouver ces options et les activer, c'est la croix et la bannière. Avec la version que j'avais essayé, j'ai dû tricher et faire croire que j'étais sur un vieux IE (et donc faire en sorte que le D&D soit impossible) pour les trouver et les activer... merci Microsoft d'avoir mis le mode compatibilité (oui, parfois, ça sert, vous voyez !)

ET ne parlons même pas des éditeurs WYSIWYG et des éditeurs in place, présent dans tous les gros CMS actuels... la plupart, pour ne pas dire quasiment tous, sont absolument horribles à utiliser. Pas forcément totalement inaccessibles, mais inutilement chiants et pas pratiques pour deux sous: des problèmes de focus et de sélection qui se perdent, de curseur qui ne suit pas, et de temps inutilement long dont on a besoin pour faire des allers-retours incessants entre la zone d'édition et les toolbars.

Pour les WYSIWYG, en règle générale, la configuration la plus favorable est clairement Jaws+IE; sous firefox c'est moins bien, avec NVDA je trouve que c'est plutôt aléatoire, et du côté de Chrome on ne peut tout simplement pas balader le curseur. A voir ce que fait VO+Safari, j'ai pas de mac donc je n'en sais rien, à tester.
J'en sais quelque chose pour les WYSIWYG, je suis actuellement en train de faire un projet qui devra nécessairement en contenir un.


C'est aussi très regrettable que des gestionnaires comme DotClear, qui ne marchait pas trop mal en v1, soit devenu pénibles à utiliser en v2. IL y a plusieurs autres CMS qui, selon moi, ont énormément rétrogradé en accessibilité et confort d'utilisation au lecteur d'écran à partir du moment où ils sont devenus conus et/ou où ils ont commencé d'utiliser du js n'importe comment/de l'AJAX/du HTML5/du WYSIWYG à fond. HTML5, AJAX et js ne riment pas automatiquement avec inaccessibilité, mais il faut quand même avouer que bien souvent, ils font des catastrophes. Quand bien même ils commencent à faire quelque chose du côté du code HTML produit par l'outil, ils oublient complètement que le rédacteur pourrait lui aussi être non-voyant.

En fait le mieux pour un non-voyant, c'est encore les wikis pas trop récents qui disposent encore d'une bonne vieille zone de texte pour écrire son oeuvre. Ca présuppose de connaître les codes de formatage, mais ça s'apprend vite. Prenez le système utilisé par wikipédia, par exemple.
Modifié par QuentinC (11 Oct 2014 - 16:32)