Bonjour
Votre remarque relative au Rich Text est très pertinente et nous nous
réjouissons d'apprendre que Jahia5.0 disposera d'un module de "filtrage"
du Rich Text. C'est un vrai problème et pour des raisons de cohérence de
charte graphique, nous pensons que l'utilisateur ne devrait pouvoir
utiliser qu'un FCKEditor très "dépouillé".
Par contre il y a une dichotomie que je ne comprends pas.
Comment faire pour que la partie "restitution" soit WAI si la partie
"édition" ne peut l'être ? Il s'agit de la même page liée à un seul
template.
Cela veut-il dire que si l'on veut faire du WAI, il faut construire son
template de la façon suivante :
<%if (jData.gui().isEditMode())
{%>
// Je fais du code HTML non WAI
<%}
else
{%>
// Je fais du code HTML WAI
<%}%>
?
Merci
Cordialement
--
Arnaud RUPIN
Rectorat de Rennes
SERvice Informatique Académique(SERIA)
Département Etablissement, Bureau des études techniques (SERIA-E3)
Stéphane Croisier a écrit :
At 12:02 20.02.2006, you wrote:
Une de nos contraintes fortes est de mettre en place des sites
respectant les caractères d'accessibilité web (WAI, tableless, etc...).
Lorsque l'on ne songe qu'à la restitution pure, cela paraît simple à
mettre en oeuvre. Le souci est lorsque l'on passe en mode édition : le
template réalisé pour la restitution ne tient plus la route du fait
des widgets utilisés pour l'édition des containers (les widgets
n'apparaissent pas aux positions prévues).
Notre connaissance du développement XHTML/CSS2 est peut-être
insuffisante mais, ceci dit, la création de templates respectant les
normes d'accessibilité nous semble beaucoup plus compliquée
(impossible ?) à mettre en place.
Quelqu'un a-t-il rencontré ce type de problème ?
Y a-t-il une solution identifiée pour conserver la souplesse de
développement de template Jahia ?
Qu'en est-il de Jahia5.0 et des normes d'accessibilité web ?
Il faut distinguer plusieurs problèmes:
- la consultation d'un site web aux normes WAI. Comme vous l'avez
mentionné, il est très simple de modifier un jeu de template pour le
rendre compatible avec la norme. Du moins pour les éléments de templates
hardcodés dans le JSP. Ensuite il reste le problème des textes HTML
riches à traiter (bigtexts dans le langage Jahia).
- L'ajout de contenus riches html: comme mentionné, un éditeur peut
actuellement saisir n'importe que contenu HTML, y compris donc du
contenu non compatible WAI. Il faut donc limiter (= techniquement
parlant parser et supprimer) certains tags. Certaines détections peuvent
être réalisées automatiquement (la majorité), certaines autres (même
pour du WAI level 1) sont difficiles à automatiser puisqu'ils s'appuient
sur les CSS globale à la page (ex: les différences de couleurs pour
s'assurer qu'on écrit pas un titre jaune clair sur un fond blanc). Un
tel "module" a été intégré à Jahia 5.0.
- La naviguation/édition en mode Edit: là très clairement les choses se
compliquent. Quitte la naviguation en mode edit devrait pouvoir être
également "WAIfiable". Par contre les engine d'édition (les pop-ups)
seront clairement plus difficile à "WAIfier". Dans Jahia 5.0,les engines
d'édition ont été tous convertis en CSS. il n'en demeure pas moins qu'il
existe une pléthore de code Javascript et autres
formulaires/onglets,/tabulations qui sera difficile à intégrer.
Donc notre objectif est de rendre l'output de Jahia WAI compatible, pas
l'édition. Autrement dit garantir, à travers des vérifications lors de
l'édition ou lors des workflows qu'un contenu HTML riche (issu d'un
copier/coller MS Word par exemple ;-) ) soit rejeté tant qu'il n'est pas
WAI compatible. Pare contre pour les engines d'édition ceci n'est pas à
l'ordre du jour du moins pour Jahai 5.0.
Cordialement,
Stéphane Croisier
Merci beaucoup.
Cordialement
--
Arnaud RUPIN
Rectorat de Rennes
SERvice Informatique Académique(SERIA)
Département Etablissement, Bureau des études techniques (SERIA-E3)
