3246 sujets

Critiques de vos sites: code et design

Que pensez-vous de l'accessibilité de mon site ?

Bonjour,

Je suis webmestre territorial et je développe actuellement la 3ème version de mon site web (c'est un gros pavé d'environ 400 pages). L'adresse de test est la suivante :
i.fautrat.free.fr

L'adresse de test de la version accessibilité est la suivante :
http://i.fautrat.free.fr/accessibilite.php

Je suis en train de créer un framework dédié à l'accessibilité. Je travail avec l'extension occawa toolbar et valide mes pages au niveau bronze de feu l'ADAE, ce qui correspond au niveau A de w3c/wai. le site est valide XHTML TRANSITIONNAL 1.0.

Le site est navigable complétement au clavier et la linéarité des pages (sauf peut-être l'accueil) est correcte lorsque css est désactivé.

J'ai vocalisé la majeure partie du contenu des pages, ajouté des liens javascripts pour lire le contenu du dewplayer au clavier et fait un lien podcast vers le fichiers mp3. Dois-je ajouter un lien en dur sur la page pour télécharger le fichier mp3 ?

La colorimétrie me gène encore un peu, je me demande par exemple si un background-image sur la page serait nécessaire...

L'accès à la version " accessible " est elle pertinente ? Je l'ai inséré comme le premier lien hypertexte de mes pages pour que l'internaute qui utilise un lecteur braille le voit aussitôt à la lecture de la page.

J'ai également mis en place un système de zoom, c'est un peu gadget mais bon...

J'imagine que cela est peut-être encore insuffisant en matière d'accessibilité, mais je commence à m'épuiser sur le sujet. Si vous avez des idées...

PS: Beaucoup de lien de ma page d'accueil sont cassés, c'est normal
Salut,

Je trouve que ta version "plus accessible", n'est pas forcément mieux.
Les liens du menu en blanc dans la version normale sont bien séparés, dans la version améliorée, ils sont en noir donc certes plus lisibles, mais tellement collés qu'il est peu aisé de les distinguer les uns des autres...
Que des petites choses dans ce genre.

Tu devrais penser ton site en une seule version, car il n'y a pas que les personnes à handicaps qui ont besoin de voir clairement l'information, c'est un peu le cas de tout le monde.
Dans la version normale, information très condensée, peu de marge ou d'espaces de respiration, etc.

Il devrait être possible de sauter les liens du menu et du calendrier, qui sont les premiers rencontrés pour aller plus rapidement au contenu. Quelqu'un qui navigue au clavier se doit de se taper tout les chiffres du mois avant de pouvoir aller plus bas dans le contenu.

Enfin ce ne sont que des remarques de base, je pense que des membres plus spécialistes pourront t'en dire d'avantage. Smiley cligne
Bonjour,

J'ai déplacé ton site vers la section dédiée aux critiques de sites, le forum Accessibilité n'étant pas dédié à cela.

Par contre j'ai le regret de t'annoncer que ton site ne passe pas le premier test d'accessibilité : Impossible d'augmenter la tailles de caractères sous IE6/7. Pour rendre cet agrandissement possible, il faut spécifier les tailles de textes en unités relatives (em / %) et non absolue (px).

Je ne vois pas trop l'intérêt d'une version "accessible aux handicaps" (quels handicapts d'ailleurs ?) qui se contente de grossir les caractères (d'ailleurs tellement légèrement qu'il n'y a aucune intérêt pour une personne malvoyante (-7 diopre avec correction). Si j'enlève mes lunettes je ne me retrouve même pas dans une situation de handicap, puisque j'ai une myopie de -4 dioptres, et je t'assure que ta version accessible m'est tout à fait innaccessible (enfin si je colle mon nez à l'écran j'arrive à lire, OK).

Pour les aveugles ton site ne sera pas non plus particulièrement accessible, les textes alternatifs de tes images n'étant pas particulièrement bien renseignés : 
<img src="Image/fond.jpg" alt="logo" width="990" height="150" border="0" />
alors que le texte de l'image est "La Hague - COmmunauté de communes".
<img src="Image/accueil/profil.gif" alt="picto" width="24" height="24" style="vertical-align:-40%;display: inline-block;" />
Ici, le alt devrait être vide, puisque l'image est décorative. Renseigner le alt en indiquant le genre de l'image ne fait que polluer la lecture de celle ci.


Je suis au regêt de t'annoncer que ton site n'est pas niveau A par rapport au WCAG.

Quelques remarques supplémentaires en vrac :
* Il est difficile de distinguer ce qui est cliquable de ce qui ne l'est pas sans passer la souris sur l'élément. Tu utilise du vert pour certains lien et du vers pour les textes non cliquables ; tous tes liens n'ont pas la même couleurs.

* il est préférable d'utiliser <p> pour baliser un paragraphe plutôt que <div>

* Les listes pour balises les menus les rendraient plus facilement identifiables.

* Ta hiérarchie de titres est incomplète (il manque, principalement un h1). Un grande majorité des utilisateurs de lecteurs d'écran naviguant à l'aide des hiérarchies de titres générées par les logiciels de lecture d'écran sur base des titres Hn (si la hiérarchie est complète), il est important que celle ci soit complète logique et continue (sans sauts).
Administrateur
Bonjour et bienvenue, Smiley smile

puisque tu es responsable d'un site public français, le RGAA (la version 2.2 est toute fraîche) te concerne à 100%. Bonne nouvelle il est bien fait et sa lecture est chaudement recommandée. Et après travaux pratiques. Smiley smile

Ocawa et autres validateurs automatiques> c'est bien (gain de temps) mais pas suffisant, loin s'en faut. La présence (ou non) d'alternatives textuelles gagne à être automatisée parce que c'est fastidieux mais aucune machine n'est et ne sera capable de juger de la pertinence de ces alternatives !
Et justement, comme l'a déjà souligné Laurie-Anne, ça pêche un peu de ce côté-là.
Un exemple avec la billetterie en haut à droite où il y a deux défauts cumulés avec l'intitulé du lien (l'ALT de l'image) et le titre de lien (attribut title du lien).
- l'alt devrait décrire la fonction du lien et non, comme dans le cas général des "images pas dans un lien", ce qui est écrit sur l'image.
- le title ne reprend pas l'intitulé, il dit complètement autre chose. Un lecteur d'écran (Jaws, NVDA, ...) ne lira qu'un seul des deux (alt ou title), très (très !) rarement les deux et donc le non-voyant qui lit "ouvrir dans une nouvelle fenêtre" va immédiatement se demander "ouvrir *quoi* dans une nouvelle fenêtre ?". La bonne pratique est d'utiliser le title pour compléter ce que dit le alt en reprenant ce que dit déjà le alt, pas en en rajoutant sans reprendre l'existant.
La bonne lecture sur le sujet : http://www.pompage.net/pompe/bien-utiliser-le-texte-alternatif/
Bon ben voilà des pistes qui vont me permettre de corriger pas mal de choses... Mon gros souci est de toucher le contenu html du site qui est encapsulé dans une bdd et généré via un wysiwig (fckeditor).

Je peux effectivement hiérarchiser ma version accessible. Pour les <p> et les <div> ça va être difficile. les list c'est jouable ainsi que les descriptions alt.

La vocalisation des textes vous parait elle toutefois utile ? Et l'accès à la ressource est il convenable ?

Auriez-vous une idée des tailles de polices à appliquer (pas l'unité mais la taille des titres, du texte du chapeau de l'article ) ?

La structure de mes pages sont elles bonnes en terme de logique de lecture du code source ?
cheucher2311 a écrit :
La vocalisation des textes vous parait elle toutefois utile ? Et l'accès à la ressource est il convenable ?
Je pense que non, mais je ne suis pas concernée étant voyante. Cependant, les utilisateurs qui ont besoin d'une sonorisation disposent généralement d'outils qui le font déjà. (sinon, à priori, il n'y a aucune chance qu'ils aient pu atteindre ton site). Il est donc innutile de dupliquer (maladroitement, puisqu'ils n'auront pas le même contrôle sur un player audio que sur un lecteur d'écran) cette fonction ; il est préférable de faire en sorte que le site soit correctement lu dans JAWS ou Windows Eyes (ou tout autre lecteur d'écran).

cheucher2311 a écrit :
Auriez-vous une idée des tailles de polices à appliquer (pas l'unité mais la taille des titres, du texte du chapeau de l'article ) ?
Peu importe tant que les textes sont agrandissables, donc la question repose plus sur l'unité que la mesure.

cheucher2311 a écrit :
La structure de mes pages sont elles bonnes en terme de logique de lecture du code source ?
Non, comme déjà dit, ton site n'a pas de hérarchie et quasi aucune structure (tout est dans des div qui n'ont aucun sens sémantique).

Étant donné que le contenu du site est généré via FCKeditor, tu va avoir du mal à corriger certains points. C'est le problème principal de ces éditeurs.
Concernant la vocalisation, il y a tout de même les personnes dyslexiques ou avec des difficultés de lecture qui pourraient être intéressés.

Concernant la taille des polices en pixel, je n'ai pas de souci avec (ctrl+ ou -) ou ctrl + la mollette pour zoomer avec chrome, firefox et ie8. Je vais tout de même changer l'unité.

Tu aurais un lien à me proposer sur la sémantique à respecter. Merci
cheucher2311 a écrit :
Concernant la taille des polices en pixel, je n'ai pas de souci avec (ctrl+ ou -) ou ctrl + la mollette pour zoomer avec chrome, firefox et ie8.


Il me semblait pourtant avoir précisé IE6 et 7...
La question a été posée plusieurs fois mais reste sans réponse :
"Pourquoi faire un site handicaps ?"

C'est quasiment le même site, la police est légèrement plus grande.

Il n'y aucun intérêt à faire ceci, autant modifier directement le site dit "standard" pour le rendre accessible.

Si vraiment tu le souhaites, tu peux ajouter une fonctionnalité de grossissement des caractères (sachant que la priorité est déjà que l'utilisateur puisse grossir les caractères avec les fonctions de son navigateur).
Pour te répondre sébastien d, je dirai que ma version handicap bien que proche de ma version standard, utilise nettement moins de javascript (comme les spry de dreamweaver...).

Le souci de l'accessibilité c'est de trouver des ressources (templates...) et un validateur automatique qui soit valable. On trouve des référentiels (rgaa) qui sont utiles, mais tout de même relativement indigestes.

Mais bon, je lâche pas l'affaire et me pencher sur la sémantique.
cheucher2311 a écrit :
Pour te répondre sébastien d, je dirai que ma version handicap bien que proche de ma version standard, utilise nettement moins de javascript (comme les spry de dreamweaver...).

Le JavaScript, lorsqu'il est bien implémenté n'est pas un frein à l'accessibilité (c'est un des mythes de l'accessibilité qu'un site accessible ne doit pas comporter de JS)

cheucher2311 a écrit :
Le souci de l'accessibilité c'est de trouver des ressources (templates...) et un validateur automatique qui soit valable. On trouve des référentiels (rgaa) qui sont utiles, mais tout de même relativement indigestes.
Des templates c'est difficile car l'accessibilité c'est quelque chose qui doit être pensé en fonction du site et de son public, non de manière standard. Pour le validateur, tu n'en trouvera jamais, car il y a trop de détails qui ne peuvent être vérifié que par un humain.
Les référenciels sont ce qu'ils sont, mais même eux ne sont pas "suffisants" dans le sens où ils ne prennent pas vraiment en compte certains handicaps (d'ailleurs il est impossible de rendre un site 100% accessible à tous le monde).


cheucher2311 a écrit :
Mais bon, je lâche pas l'affaire et me pencher sur la sémantique.
Si jamais tu n'as pas peur des couleurs qui piquent et que tu lis l'anglais (j'ai toujours pas eu le temps de le traduire) tu peux consulter ma thèse de master qui donne quelques pistes concernant l'accessibilité : http://web-accessibility-thesis.bourdain.name (mais ça pique vraiment les yeux ^^; )
Modifié par Laurie-Anne (17 May 2012 - 10:27)
Sujet clos
Aller à