Wikini

WikiNiAccessible

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-44-220-251-236.compute-1.amazonaws.com
On discute ici de l'accessibilité de WikiNi au sens de l'interface et non de la facilité de prise en main (cf. SiteAccessible).

L'accessibilité des sites web fait notamment l'objet de recommandations du W3C.

Références


Outils

Constat

Le validateur spécialisé du site acces-pour-tous.net, permet de donner une idée de l'accessibilité de WikiNi : http://www.acces-pour-tous.net/validateur/validateur.php?urlAVerif=http%3A%2F%2Fwebsemantique.org%2FPagePrincipale&Submit=Soumettre
On voit que les résultats ne sont pas mauvais du tout et que les rares erreurs sont faciles à corriger.

Besoin

Je propose de modifier WikiNi afin d'obtenir le meilleurs résultat possible en matière d'accessibilité. Il semble que les modifications à mettre en oeuvre ne soit pas très complexes et profitent non seulement aux handicapés visuels, mais également au bon référencement d'un site.
-- CharlesNepote

Il faut notamment remplacer les barres de lien en haut et en bas des pages par des listes <ul> en complétant la feuille de style. Voir http://www.pompage.net/pompe/portescoulissantes/ et aussi http://listapart.com/ : les articles et le source de la page pour un exemple.
J'ai un patch en cours de développement.
Tout ceci est fortement lié à WikiNiEnHTMLStrict. -- OlivierMengu?é

Solutions


Ajouter un label aux champs de formulaire

Ajouter un attribut label à tous les champs de formulaire (http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.9) :
Référence :

Pré-renseigner les champs de formulaires

Il est conseillé de ne pas laisser "les zones de saisie de vos formulaires vides car ceux-ci risquent d'être mal interprétés par les navigateurs en mode texte." Un peu de JavaScript peut donner un petit effet intéressant : <input id="zzz" name="xxx" value="Mot-clé" onfocus="if (this.value == 'Mot-clé') {this.value=''}" />
Pour la boite de recherche on aurrait donc :
(Il faudrait également tester la possibilité de supprimer l'attribut "size".)
Références :

Mettre en place un menu de navigation

Ce menu n'est pas affiché dans les navigateurs graphiques modernes mais il permet aux navigateurs texte et surtout au non-voyants de voir leur navigation facilité.
On pourra voir des exemples d'une telle solution chez Tristan Nitot (http://www.standblog.org/) ou chez Olivier Meunier (http://www.neokraft.net/blog/). Cela pourrait donner le code HTML suivant, à inclure dans le /actions/header.php :
<p id="prelude">
 </p>
Naturellement, il faut modifier également quelque peu le code correspondant aux blocs référencés :

Mettre en place des raccourcis clavier

Ajouter des accesskey, très simples à mettre en place puisqu'il s'agit d'un simple attribut HTML ( http://www.acces-pour-tous.net/fichiers_communs/access.php?rub=aides_nav ).
Selon la source citée en référence, l'usage voudrait qu'on utilise les touches suivantes :
Références :

[ Il faudrait pour cela modifier le code de formattage de WikiNi. On peut envisager de mettre les raccourcis clavier "chiffres" pour la barre de liens en haut. C'est faisable, logique et générique (les liens chiffres seraient sur toutes les pages et pointeraient vers les mêmes pages). J'ai un patch en cous de développement. -- OlivierMengu?é ]

Chaque fonctionnalité de l'interface Wiki (navigation, édition) devrait avoir un raccourci d'accès (accesskey). Pour le contenu de la page, à part les titres, cela ne me paraît pas possible ni nécessaire. Il suffirait d'ajouter un lien tout en haut de la page (avant le titre) qui permette d'aller directement au début du contenu de la page en sautant la barre de navigation. -- OlivierMengu?é

Ajout d'attributs title

Il faut ajouter des attributs title là où cela peut donner de l'aide. Je pense en particulier aux liens "?" associés à un MotWiki et permettant de créer la page manquante.
Dans wakka.php, classe Wiki, méthode Link :
return ($this->LoadPage($tag) ? '<a href="'.$this->Href($method, $tag).'">'.$text.'</a>' : '<span class="missingpage">'.$text.'</span><a href="'.$this->Href("edit", $tag).'" title="Cr&eacute;ez la page '.$tag.'">?</a>');

-- OlivierMengu?é

Excellente idée ! Je ne vois que des avantages : meilleure accessibilité, profite à tous, simple à mettre en oeuvre, influence sur négligeable sur les performances. Sauf avis contraires, vendredi 5 mars. -- CharlesNepote


Supprimer les mises en page à base de tables

Il faut supprimer les mises en page utilisant <table> : /actions/usersettings.php, /setup/default.php... et utiliser plutôt <div> et les CSS.
Pas mal de boulot !
-- OlivierMengu?é

Attention ! Il y a des cas où les tables sont nécessaires. Je suis d'accord sur le fait de supprimer l'utilisation des tables à des fins de mise en page ; mais il y a peut-être des cas où les tables représentent des données tabulaires, comme par exemple dans les /revision.
Pages pour lesquelles on peut se poser la question :
Pages pour lesquelles on pourait simplement supprimer les tableaux :
-- CharlesNepote

Éliminer les tags non-sémantiques

Il faut éliminer <i>, <b>... au profit de <em>, <strong>...
Voir EnCoursDeDeveloppement.
-- OlivierMengu?é

Dans le même ordre d'idée, supprimer la balise <u> par un <span class="sou"> (comme <s> est <span class="bar">) ()
-- LawrencePritchardWaterhouse

Pour les <i> et <b> je suis OK. Pour les <u> et <s>, c'est une autre histoire...
Le problème, en utilisant <span class="sou"> et <span class="bar">, c'est que le code devient du coup "moins sémantique". Concrètement, je pense qu'un navigateur texte ou qu'un lecteur vocal pourrait rendre correctement <u> et <s> mais pas <span class="sou"> et <span class="bar">. L'idéal ça serait de pouvoir utiliser des balises sémantiques : <del> et <ins> mais qui posent d'autres problèmes : cf. mes recherches bloquées sur la page EnCoursDeDeveloppement : "Utilisation des balises xhtml INS et DEL pour le diff". Je serais content d'avoir vos avis sur la question. -- CharlesNepote


<u> et <s> ne sont pas plus sémantique qu'un <span>, dans les deux cas la balise n'est là que pour appliquer style au texte. C'est juste que <u> et <s> sont obsolètes en xhtml.
Remplacer <s> par <del> est une bonne idée qui apporte effectivement du sens. Cela signifie que le trait au milieu du texte n'est plus une décoration mais bien la marque d'un ancien texte supprimé et/ou corrigé.
En revanche, il est plus difficile de trouver une valeur sémantique à un texte souligné. Le seul exemple qui me vienne à l'esprit est lorsque qu'on cite les référence d'un livre (ex: Le Faucheur, Terry Pratchett). Je ne crois pas qu'il existe quoique ce soit de tel en xhtml.
-- LawrencePritchardWaterhouse

Lawrence: pour ton exemple de référence d'un livre, le tag sémantique approprié est <cite>.
Voir :

-- OlivierMengu?é

Utiliser les balises de paragraphe <p>...</p>

En regardant le html généré par WikiNi je me suis apperçu qu'il n'y avait pas de balise <p>...</p>. Ces balises permettent de délimiter un paragraphe ce qui me semble essentiel pour un utilisateur non/mal voyant (enfin il me semble car je n'ai pas d'experience dans ce domaine). La balise <br /> est utilisée pour mettre un saut de ligne, mais un saut de ligne n'est pas une limite de paragraphe! Je pense que la solution serait de rajouter qu'une ligne vide délimite un paragraphe comme le fait PhpWiki par exemple (je crois).
--GarfieldFr

Totalement d'accord. Mais la solution n'est pas évidente.
Il y a un très intérassant débat sur CraoWiki qui synthétise bien les problèmes : http://wiki.crao.net/index.php/WikiSyntaxeUniverselle/Draft/Discussions/Paragraphes
Admettons que la solution soit :
On obtient bien alors le principe de mise en forme visuelle qui guide WikiNi (le meilleur exemple étant l'indentation visuelle), qui me paraît assez intuitif.
Cependant, qu'est-ce qui empêche quelqu'un de ne jamais écrire avec des lignes vides ?
D'après ce que j'ai compris, la solution adoptée par PhpWiki est que :
J'avoue que je suis dubitatif.
-- CharlesNepote

Je pencherais plutôt pour la 1ere solution qui a l'avantage de la simplicitée et est très proche d'une mise en forme intuitive. Je modifierais quand même par:
Pour les [Autre bloc] je supose que tu ne parle que des titres car je ne vois pas d'autre type de bloc non suceptible d'être dans un paragraphe. Un exemple de code(balise %%) est dans un paragraphe(idem pour une liste ) et ne forme pas un paragraphe à lui tous seul.
--GarfieldFr

J'aime bien aussi cette dernière proposition. Toute la discussion sur cette page rejoint aussi WikiNiEnHTMLStrict comme le disait OlivierMengu?é plus haut. Pour moi ça me semble important de respecter la sémantique du XHTML, c'était à la base de l'invention de Tim Berners-Lee et il n'y a que des avantages il me semble (accessibilité, mise en page dans les CSS, moteurs de recherche, traduction vers d'autres formats, maintenabilité du code, etc.).
-- ToniN?
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]
2004-07-15 10:45:33 :: Propriétaire : CharlesNepote :: Rétro-liens :: Cartographie :: Recherche :
XHTML 1.0 valide ? :: CSS valide ? :: -- Fonctionne avec WikiNi 0.5.0 (interwiki)