Matthieu Faure

Tout dépend de tes contraintes et objectifs. Tu peux placer la navigation en bas avec un lien "acceder au menu" en tout début de page. (Tu peux aussi placer un accesskey, mais si tu le fais, il faut que l'accesskey soit valable sur tout le site). Tu peux aussi placer la navigation en haut, avec un lien "accéder au contenu" en tout début. Dans le premier cas, il faudra jouer avec la mise en page CSS et veiller à respecter les critères 10.2 et 10.3. Dans le deuxième cas, si ta navigation est importante, tu risques de limiter l'indexation de ta page (limite de 100ko). Bref, à toi de définir tes priorités

Salut, Une petite précision qu'on ne répétera jamais assez: utiliser XHTML/CSS n'implique pas forcément que le site sera accessible, et ce pour plusieurs raisons. - l'accessibilté n'est pas binaire (à l'opposé de la conformité grammaticale d'un langage comme xhtml ou css, ou P3P...) - l'accessibilité est progressive: on a un [bon|mauvais|excellent|...] niveau d'accessibilité Ainsi utiliser le couple XHTML/CSS (css-p) améliore le niveau d'accessibilité, mais peu aussi le faire chuter d'un coup ! (Critères 10.2 et 10.3 pas forcément évidents à valider) C'est pour cette raison qu'il est délicat de conseiller systématiquement l'utilisation des CSS-P Matthieu

Salut, Le meilleur moyen est de vérifier les Critères AccessiWeb sur ton site, ou de demander à quelqu'un d'en faire un audit (Contrairement au couple XHTML/CSS, la validation de l'accessibilité ne concerne que quelques points. Il en reste pas mal à vérifier "humainement".) Matthieu

Tu dois déjà connaitre, mais sait-on jamais. Du point de vue code, tu trouveras certainement de quoi t'inspirer avec la toolbar "webdeveloper" http://www.chrispederick.com/work/firefox/webdeveloper/ Matthieu

Une nouvelle pareille, depuis le temps qu'on l'attendait, il faut en parler ! JAWS et firefox enfin réunis grace au libre Matthieu

Salut, Pour savoir par où commencer et être certain qu'on parle de la même chose (accessibilité n'est pas équivalent à xhtml/css) tu peux commencer par là: Accessibilite: pourquoi et comment l'ameliorer Ensuite, pour approfondir, il y a un bouquin incontournable: "Building accessible websites" de JoeClark http://www.joeclark.org/book/ Ta question est un peu vague à propos de "creuser le domaine". Du point de vue des aides techniques, ce n'est pas ce qui manque: reconnaissance vocale, synthèse vocale, trackball, clavier adapté, clavier virtuel (sur l'écran), plage braille, CSS personnalisées, dispositifs de pointage (avec caméra, par infra-rouge, par le nez, "nouse" pointer http://synapse.vit.iit.nrc.ca/Nouse/index2.html) En espérant que ça t'aide Matthieu

Merci Monique ! Oui, ce doc a entre autre but de favoriser l'accès à l'accessibilité L'idée est simple: certains critères d'accessibilité sont plus difficiles à respecter que d'autres. L'idée est donc d'indiquer par où commencer, et d'éviter de faire face à des difficultés quand on commence à implémenter l'accessibilié. En résumé, cela devrait permettre de bien mettre le pied à l'étrier. Pour télécharger le document c'est par là: http://www.open-s.com/Realisations/Accessi...ment-ameliorer/ La version HTML "copiable/collable" devrait arriver avant la fin du mois. Matthieu

Ce validateur est très pratique, mais il ne faut pas oublier que tous les critères ne sont pas automatisables (en gros, tous ceux qui contiennent le mot "pertinent", qui ne sont vérifiables que par un humain). A cela il faut ajouter que certains critères dépendent de l'auteur du billet et nom de l'outil utilisé. Si l'auteur fait un gros lien "cliquer ici" (invalide le critères Accessiweb 6.2 http://www.accessiweb.org/fr/Label_Accessi...siweb_lineaire/ ), l'outil n'y est pour rien. A propos de lien explicite, une modification des templates DotClear peut être faite pour éviter une partie de ces problèmes. Lorsque l'article possède un "chapo", le lien pour accéder à l'article s'intitule "lire la suite". Pour remplacer cet intitulé par "lire la suite de Mon Article", il faut remplacer dans template/list.php le bout de code <div class="post-content" <?php dcPostLang(); ?>> <?php dcPostAbstract('%s'); ?> </div> par ce bout de code <div class="post-content" <?php dcPostLang(); ?>> <?php dcPostAbstract('%s', '<p>Lire la suite de <a href="%s">' . $GLOBALS['news']->f('post_titre') . '</a></p>'); ?> </div> m2c Matthieu

La difficulté avec l'accessibilité, c'est de savoir ce qu'on entend en utilisant ce mot. Si on veut être strict, le point 1. signifie respecter les ATAG (Authoring Tools Accessibility guidelines http://www.w3.org/TR/WAI-AUTOOLS/ ) Les points 2. et 3. signifient produire des pages accessibles, i.e. qui respectent les normes d'accessibilité, ce qui est différent de produire du code conforme. Il est important de noter qu'il n'y a pas d'implication ni dans un sens, ni dans l'autre (ce serait trop facile sinon ). En résumé, avoir du code HTML conforme augmente l'accessibilité (valide de fait plusieurs critères) mais ce n'est pas suffisant: certaines personnes ne pourront pas encore accéder à l'information. Matthieu

C'est clairement la raison. Il faut mobiliser 3 profils différents ("utilisateur", "ergonome" et "technique"), et ce pendant plusieurs jours, pour réaliser un audit de site dans l'optique labélisation. Matthieu

Il est vrai que la première impression de FANGS est étrange. On ne sait pas trop où le placer. Mais au final, c'est, je pense, vraiment une bonne idée pour plusieurs raisons - bien que ça ne la remplace pas, ça permet d'avoir une bonne idée de ce rend une synthèse vocale - c'est multi-plateforme, et ce n'est pas rien (Jaws et WindowsEye ne tournent pas sous Linux) - c'est gratuit ! Quand on connait le prix d'un synthèse vocale (~1500) ce n'est pas rien. Matthieu

Pour compléter Monique, selon le critère AccessiWeb 5.1, l'attribut summary est toujours obligatoire, tandis que la balise caption n'est obligatoire que pour les tableaux de données (critère AccessiWeb 5.2). Maintenant qu'est qu'on appelle tableau de donnée et tableau de présentation ? Pour faire court, un tableau de donnée présentera des données "tabulaire" comme on le fait dans un tableur. Un tableau de mise en forme c'est ce qu'on utilisait avant les CSS-P Les critères AccessiWeb Matthieu

Eh oui, il nous reste du travail de communication à faire :-/ Le plus dur n'est pas tant de faire passer une nouvelle idée (accessibilité = accessibilité pour tous sans segmentation), mais plutôt d'en chasser une autre qui est tenace: on fait N versions d'un même site. Beaucoup de personnes ont eu cette idée martelée pendant quelques années, et la remise en cause n'est pas évidente, malgré les arguments qui ne manquent pas Matthieu

Salut, Il n'y a pas de prérequis sur les noms de fichiers dans les WCAG. Par contre s'il s'agit de fichiers "multimedia" (son, video...), il te faut prévoir un contenu textuel et une synchronisation des sous-titres et de l'image (cf critères AccessiWeb 4.1 et 4.2) http://www.accessiweb.org/fr/Label_Accessi...siweb_lineaire/ (pour mémoire le Référentiel AccessiWeb est une méthode d'application des WCAG) Matthieu

Préciser la langue au sein des balises est inutile du moment qu'elle déjà spéficifée dans la balise <html>. Et c'est ce qu'il convient de faire en premier lieu. Exemple: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html lang="fr"> <head><title>Exemple de changement de langue</title></head> <body> <p>logiciel libre à la <span lang="en">Free Software Foundation</span></p> </body> </html> Tu définis la langue par défaut de ta page dans la balise html (ici le français), donc ta page est en français. C'est seulement si tu changes de langue au sein de ton document (ici "Free Software Foundation") que tu le précises niveau des balises. <span lang="en">Hope this helps</span> Matthieu

Non, pas à ma connaissance. Matthieu

Salut, Braillenet a proposé / propose un concours de création de site accessible pour les étudiants. Mais ce n'est qu'une partie de leur activité. Ce qu'ils ont surtout mis en place c'est une méthode d'application des WCAG nommée référentiel AccessiWeb, et en parallèle de cela une démarche de certification, nommée Label AccessiWeb. En pratique, un site qui respecte les 55 critères Bronze (A) pourra recevoir le label Bronze. Ainsi de suite pour les niveau Argent (AA) et Or (AAA). Par rapport à des étiquettes "html compliant" ou "bobby compliant" que n'importe qui peut mettre sur son site, la différence est que le label AccessiWeb est un démarche de certification. Un groupe de 5 experts de profils différents (ergonome, technique, utitilisateur) se réunit et procède à l'audit du site en question. A la fin de l'audit des X critères du niveau demandé, si les X critères sont validés, le site reçoit le label en question. Le Label AccessiWeb a d'autant plus d'importance qu'il a été fait en collaboration avec le W3C et qu'il est reconnu par l'Administration française par la biais de l'ADAE (cf brève du 09/02/04 http://www.open-s.com/actualites-open-s-archives.php) Le site AccessiWeb: http://www.accessiweb.org Les critères du Référentiel AccessiWeb: http://www.accessiweb.org/fr/Label_Accessi...res_accessiweb/ Le processus de labelisation: http://www.accessiweb.org/fr/Label_Accessi.../labellisation/ Voila, en espérant que cela t'éclaire un peu plus :-) Matthieu

Et bien modestement Open-S Je ne me reconnais pas trop sous l'étiquette webagency, par contre pour "vendre de l'accesibilité", oui c'est moi ;-) Open-S fait aussi dans le respect des standards et dans le libre, mais c'est une problématique avant tout technique. L'accessibilité est plus englobante, plus "humaine" (tournée vers l'humain, l'utilisateur). Matthieu

Vu qu'il y a divergence d'avis: quand on parle de 100ko, qu'est-ce que vous considérez (Sebastien, Denis) ? Vous "pesez" uniquement le code HTML ? La / les CSS qui vont avec ? les images ? d'éventuels include ? Matthieu

Pourquoi pas, mais à un détail près: la séparation stricte du fond et de la forme en XHTML Strict. Cela offre un accès à l'information sans parasitage lié au graphisme ou à la mise en forme. En terme d'accessibilité ce n'est pas rien. Matthieu

Est-ce qu'il n'y aurait pas là une confusion possible entre la limite des 100 liens et celles (hypothétique ?) des 100ko ? Matthieu

Salut, Il faut que tu précises la langue en attribut de la balise <html>, soit : <html lang="fr"> (2° ligne de ton code) Matthieu

Salut, Une remarque concernant les Accesskey: ne PAS utiliser les lettres mais des chiffres. Toutes les lettres sont déjà prises par les combinaisons OS/navigateur. Il reste donc 10 possibilités. Ensuite, il existe des recommandations (non normatives) pour l'utilisation des raccourcis-clavier: - "1" : page d'accueil - "2" : page d'actualités - "3" : plan du site - "4" : moteur de recherche - "5" : FAQ - "6" : Page d'aide - "7" : contact - "8" : conditions d'utilisation - "9" : livre d'or - "0" : lien vers la liste des raccourcis clavier utilisés dans la page. En général, on place la liste des accesskeys quelquepart dans ou sous la page d'aide. Les accesskeys que j'utilise le plus souvent sont les 1, 3, 6, 7, 0 Enfin, pour revenir au tabindex, il sont particulièrement complexes à gérer. Ils dépendent intimement de la structure du site. Je n'ai pas (encore ?) trouvé de principes généraux sur les tabindex. Il vaut mieux ne pas en avoir que d'avoir de mauvais tabindex qui vont achever de désorienter l'utilisateur. Au final, vive les accesskeys ! Matthieu (avec 2 t )

Salut, Il sera question d'accessibilité aux Rencontres Mondiales du Logiciel Libre à Bordeaux. Un thème complet lui est consacré. Les trois jours de conférence s'annoncent riches et intéressants avec entre autres: - l'accessibilité des interfaces graphiques: application à Gnome et KDE - Gnopernicus: un lecteur d'écran libre. Quand on connait la position dominante de Jaws sur le marché, c'est un projet libre qu'on a particulièrement envie de soutenir. - les interfaces avec l'ordinateur: claviers, souris, reconnaissance vocale, terminaux brailles et autres variantes - la synthèse vocale - les distribution et l'accessibilité, avec un focus sur Oralux - enfin, l'accessibilité du web, présenté par votre serviteur. Tout le programme Accessibilité est disponible ici: http://prog.lsm2004.abul.org/program/view_...id=2&langnew=fr Au plaisir de se rencontrer à Bordeaux

Salut, Une remarque avant tout: accessibilité et ce qu'on apelle "respect de standards" (au sens respecter les balisages (X)HTML, CSS) sont deux domaines connexes mais bien distincts. Le premier n'implique pas le deuxième et le deuxième n'implique pas le premier. Maintenant, comment juger de l'accesibilité d'un outil ? Bonne question La réponse se situe au niveau des normes. Le nombre de critères validés (dans référentiel accessiweb) est un bon indicateur. http://www.accessiweb.org/fr/Label_Accessi...res_accessiweb/ A ma connaissance, deux CMS sortent du lot: Plone et Spip-Agora. Plone se prétend conforme AAA (ce qui me parait un peu exagéré), mais offre un bon niveau d'accessibilité. Spip-Agora avait l'accessibilité dans son cahier des charges et l'équipe de Braillenet a apporté ses compétences pour l'accessibilité. Enfin, il ne faut pas oublier que beaucoup de critères d'accessibilité concernent l'auteur du document (et non l'outil qui l'affiche). Ainsi une Ferrari n'a jamais empéché de prendre un sens interdit ! Matthieu