accessibility-fr

accessibilité

Cette page est destinée à garder une trace des discussions concernant les microformats et l'accessibilité, avec l'espoir que les problématiques d'accessibilité potentielles soient résolues rapidement, et pour documenter les techniques destinées à faire que les microformats soient plus accessibles.

Nous devrions tous nous battre pour faire en sorte que nos microformats publiés, nos implémentations de parseurs et au moins ce wiki, soient aussi accessibles que possible pour tous les utilisateurs, sans se soucier de leurs capacités physiques et besoins. Il est recommandé aux lecteurs de suivre le guide de conduite de l'accessibilité Web du W3C jusqu'au moins au niveau 2. Un conseil plus approfondi est disponible sur les Forums Accessify.

Bénéfices

Au dessus de toute la commodité accrue que cela apporte, quelques microformats ont des bénéfices potentiels d'accessibilité.

hCard

• tel dans hCard : utilisez style="speak-numeral:digits", de façon que les numéros de téléphone puissent être lus par des navigateurs oraux, par exemple, "five-five-five one-two-three-four" et non "five-hundred and fifty-five, one-thousand, two-hundred and thirty-two".

Problématiques

hCalendar

• Dans

  <abbr class="dtend" title="19970403">2 avril 1997</abbr></div>

  "19970403" n'est pas une abréviation, en quelque sens que ce soit de "2 avril 1997", mais de "3 avril 1997".

Discussions externes

Listes de discussion

• Microformats and Semantic Structure (part 2) - 2006-10-11 in w3c-wai-ig.
• hCard and hCalendar Formats - 2006-08-03 in w3c-wai-ig.

Forums

• Utilisation de 'abbr' dans les microformats - 2006-09-20. Problématiques : utilisation de 'abbr'

Accessibilité de ce wiki

• De grands blocs de texte sont inacessibles pour beaucoup de lecteurs, y compris les personnes avec des sortes d'handicap viduel, de dyslexie, etc.

[1], [2]. [3], [4], [5] Andy Mabbett 14:33, 26 Nov 2006 (PST)

• Utiliser le gras et l'italique pour différencier les types sur, disons les pages anti-sèche hCard-antisèche, n'aide pas les utilisateurs des assistants, des terminaux en mode texte, etc. Un nombre, une lettre ou un symbole devrait être utilisé en plus. Andy Mabbett 14:33, 26 Nov 2006 (PST)
  • Je pense que graisser est bien car cela marque les propriétés requises. Les italiques sont un peu problématiques mais gardons les simples pour le moment. Les caractères additionnels ne peuvent pas être utilisés car ils briseraient le gabarit class="property". Les couleurs seraient un moyen d'y parvenir mais elles sont inaccessibles pour quelques utilisateurs, ainis il n'existe pas de véritable solution à ce problème à cette heure. Julian Stahnke 22:55, 26 Nov 2006 (GMT)
    • "Je pense que graisser est bien" - comment comprendrais-tu la graisse dans un navigateur en mode texte comme Lynx ou dans un navigateur audio ? Andy Mabbett 15:17, 26 Nov 2006 (PST)
      • Ups, je supposais juste qu'on utiliserait les tags strong et em. Yeah, bon, pensons-y. Julian Stahnke 23:22, 26 Nov 2006 (GMT)
  • Bien sûr, on pourrait ajouter ce truc après la chose class="property". Cela pourrait sembler un peu chargé néanmoins. J'étudierai ça pour les prochaines révisons d'antissèches que je produirai. Julian Stahnke 22:57, 26 Nov 2006 (GMT)
    • Tout ce qui est demandé est :

* class="vcard" (1)

au lieu de :

* class="vcard"

Andy Mabbett 15:24, 26 Nov 2006 (PST)

• • Résolu maintenant. Merci à tous ceux qui ont aidé.

Andy Mabbett 10:30, 11 Dec 2006 (PST)

• Dupliquer le lien texte brise WAI-WCAG 1 la guideline 13.1 'Clearly identify the target of each link' et n'aide pas les utilisateurs de technologies assistives et d'autres agents, qui fournissent des liens dans une liste isolée et hors contexte. Andy Mabbett 10:29, 11 Dec 2006 (PST)

Voir aussi

microformats-problématiques