Bonsoir à tous,
Comme l'avait décidé le CA dans sa précédente réunion, voici un document où j'expose les modalités d'accessibilité qui me paraissent minimales pour le site réaménagé. L'idée serait de voir quel outil s'en accomoderait le plus facilement, le débat portant entre un wiki, cms, html. Etant peu expert dans ces considérations, je vous laisse prendre le relais. À ce titre, je vous propose de concevoir une "maquette" (wiki, html, Joël ayant accepté de se charger de la maquette html) pour qu'on voit le plus pratique. Cela nous permettra en mâme temps de savoir qui maîtrise les autres outils que le html et peut/veut les utiliser pour cette opération. Ce serait bien que quelque chose émerge pour la prochaine réunion du 15 février, si possible.
"Pour une parfaite accessibilité, le site doit contenir le plus possible de repères html. Cela inclut notamment : -des cadres (frame) au titre le plus parlant possible ; -des liens étiquetés en cas de liens image. De manière générale, toute image doit avoir une étiquette permettant de la décrire. Contre-exemple : sur wikipedia, les liens vers images renvoient au nom du fichier, pas toujours explicite voire illisible car chemin vers un fichier, qu'une synthèse interprète mal. -des titres pour chaque blocs (ou en-tête)
Le javascript ne favorise pas un accès universel un texte pur (en console particulièrement). Les navigateurs web peuvent aussi enregistrer les liens déjà visités en les distinguant lisuellement, les synthèses sachant repérer ces marques visuelles. Cette fonctionnalité est utile et, si nécessaire, le site doit lui permettre de correctement fonctionner.
Le site pour traduc pourrait donc ressembler à: 3 titres : Notre asso, Les projets, Actu Chacun étant présentés avec un cadre taitré, un titre en haut du cadre, le contenu L'intérêt des cadres est qu'on peut les disposer sur un écran comme voulu pour les raisons esthétiques sans compromettre l'accessibilité. Si on veut mettre en avant le statut des projets avec des couleurs, il faut compléter ce dispositif en mettant un signe distinctif à côté des projets : par exemple + pour maintenu, - pour non maintenu. Sachant que le détail (pourcentage de traduction) est dans un tableau et non en page d'accueil.
pour des sites accessibles, cf lfs.traduc.org, absolinux.net, avh.asso.fr, handicapzero.org. Une norme d'accessibilité existe par ailleurs."
Bonne soirée à tous,
Cordialement,
Jean-Philippe MENGUAL
Afficher les réponses par date
* Jean-Philippe MENGUAL mengualjeanphi@free.fr [2010-02-01 18:29:59 +0100] wrote :
Bonsoir à tous,
Bonsoir,
Comme l'avait décidé le CA dans sa précédente réunion, voici un document où j'expose les modalités d'accessibilité qui me paraissent minimales pour le site réaménagé. L'idée serait de voir quel outil s'en accomoderait le plus facilement, le débat portant entre un wiki, cms, html. Etant peu expert dans ces considérations, je vous laisse prendre le relais. À ce titre, je vous propose de concevoir une "maquette" (wiki, html, Joël ayant accepté de se charger de la maquette html) pour qu'on voit le plus pratique. Cela nous permettra en mâme temps de savoir qui maîtrise les autres outils que le html et peut/veut les utiliser pour cette opération. Ce serait bien que quelque chose émerge pour la prochaine réunion du 15 février, si possible.
Je connais assez bien le cms Drupal qui est relativement simple à mettre en place et on peut avoir une plateforme en ligne rapidement. J'ai déployé des sites sous drupal en très peu de temps.
"Pour une parfaite accessibilité, le site doit contenir le plus possible de repères html. Cela inclut notamment : -des cadres (frame) au titre le plus parlant possible ;
Frames ?! On utilise plus ceci depuis plus de 10 ans ... tout est faisable en css et devrait d'ailleurs être fait ainsi.
-des liens étiquetés en cas de liens image. De manière générale, toute image doit avoir une étiquette permettant de la décrire.
C'est ce qu'est censé apporter le XHTML :)
Contre-exemple : sur wikipedia, les liens vers images renvoient au nom du fichier, pas toujours explicite voire illisible car chemin vers un fichier, qu'une synthèse interprète mal.
Pas tout compris là :(
-des titres pour chaque blocs (ou en-tête)
Qu'appelles-tu blocs ?
Le javascript ne favorise pas un accès universel un texte pur (en console particulièrement). Les navigateurs web peuvent aussi enregistrer les liens déjà visités en les distinguant lisuellement, les synthèses sachant repérer ces marques visuelles. Cette fonctionnalité est utile et, si nécessaire, le site doit lui permettre de correctement fonctionner.
Encore une fois ceci est fait via les fichiers css :)
Le site pour traduc pourrait donc ressembler à: 3 titres : Notre asso, Les projets, Actu Chacun étant présentés avec un cadre taitré, un titre en haut du cadre, le contenu L'intérêt des cadres est qu'on peut les disposer sur un écran comme voulu pour les raisons esthétiques sans compromettre l'accessibilité. Si on veut mettre en avant le statut des projets avec des couleurs, il faut compléter ce dispositif en mettant un signe distinctif à côté des projets : par exemple + pour maintenu, - pour non maintenu. Sachant que le détail (pourcentage de traduction) est dans un tableau et non en page d'accueil.
Pas compris l'histoire des cadres ...
pour des sites accessibles, cf lfs.traduc.org, absolinux.net, avh.asso.fr, handicapzero.org. Une norme d'accessibilité existe par ailleurs."
Bonne soirée à tous,
Cordialement,
Jean-Philippe MENGUAL
Bonne soirée,
Salut,
Complexe de décrire sans termes techniques :) (que je ne connais pas).
Pour frames j'utilise l'appelation des synthèses vocales de Win, mais ça a peut-être un autre nom techniquement. L'idée c'est que ce sont des cadres en tout cas.
Pour le contre-exemple: wikipedia a des articles illustrés. Les images, niveau synthèse, sont interprétées et c'est leur étiquette qui est affichée. Quand c'est bien fait, sur wikipedia, ça peut donner par exemple: fichier:Ice_hockey_McGill_University_1884 Hockey sur glace à l'Université McGill de Montréal en 1884.
Certains articles ne mentionnent que Fichier:le_nom_du_fichier, sans étiquette. Là ce serait inaccessible.
Concernant le terme "blocs", je veux dire que les liens peuvent être regroupés au sein d'un cadre qui est étiquetable ou nommable, mais aussi, comme sur un wiki, sous des titres. Pour Traduc, un titre renverrait à un ensemble de liens. Par ex: Un cadre Association, contenant un titre L'association, (h1> </h1> ..., contenant un bloc (ensemble de liens tels que Le CA, Bulletin d'adhésion...).
J'espère avoir éclairé au passage la question des cadres, ne pas trop avoir été confus. Désolé de ce manque de clarté dû au manque de technique.
Bonne soirée,
Jean-Philippe MENGUAL
Le lundi 01 février 2010 à 23:35 +0100, Edi Stojicevic a écrit :
- Jean-Philippe MENGUAL mengualjeanphi@free.fr [2010-02-01 18:29:59 +0100] wrote :
Bonsoir à tous,
Bonsoir,
Comme l'avait décidé le CA dans sa précédente réunion, voici un document où j'expose les modalités d'accessibilité qui me paraissent minimales pour le site réaménagé. L'idée serait de voir quel outil s'en accomoderait le plus facilement, le débat portant entre un wiki, cms, html. Etant peu expert dans ces considérations, je vous laisse prendre le relais. À ce titre, je vous propose de concevoir une "maquette" (wiki, html, Joël ayant accepté de se charger de la maquette html) pour qu'on voit le plus pratique. Cela nous permettra en mâme temps de savoir qui maîtrise les autres outils que le html et peut/veut les utiliser pour cette opération. Ce serait bien que quelque chose émerge pour la prochaine réunion du 15 février, si possible.
Je connais assez bien le cms Drupal qui est relativement simple à mettre en place et on peut avoir une plateforme en ligne rapidement. J'ai déployé des sites sous drupal en très peu de temps.
"Pour une parfaite accessibilité, le site doit contenir le plus possible de repères html. Cela inclut notamment : -des cadres (frame) au titre le plus parlant possible ;
Frames ?! On utilise plus ceci depuis plus de 10 ans ... tout est faisable en css et devrait d'ailleurs être fait ainsi.
-des liens étiquetés en cas de liens image. De manière générale, toute image doit avoir une étiquette permettant de la décrire.
C'est ce qu'est censé apporter le XHTML :)
Contre-exemple : sur wikipedia, les liens vers images renvoient au nom du fichier, pas toujours explicite voire illisible car chemin vers un fichier, qu'une synthèse interprète mal.
Pas tout compris là :(
-des titres pour chaque blocs (ou en-tête)
Qu'appelles-tu blocs ?
Le javascript ne favorise pas un accès universel un texte pur (en console particulièrement). Les navigateurs web peuvent aussi enregistrer les liens déjà visités en les distinguant lisuellement, les synthèses sachant repérer ces marques visuelles. Cette fonctionnalité est utile et, si nécessaire, le site doit lui permettre de correctement fonctionner.
Encore une fois ceci est fait via les fichiers css :)
Le site pour traduc pourrait donc ressembler à: 3 titres : Notre asso, Les projets, Actu Chacun étant présentés avec un cadre taitré, un titre en haut du cadre, le contenu L'intérêt des cadres est qu'on peut les disposer sur un écran comme voulu pour les raisons esthétiques sans compromettre l'accessibilité. Si on veut mettre en avant le statut des projets avec des couleurs, il faut compléter ce dispositif en mettant un signe distinctif à côté des projets : par exemple + pour maintenu, - pour non maintenu. Sachant que le détail (pourcentage de traduction) est dans un tableau et non en page d'accueil.
Pas compris l'histoire des cadres ...
pour des sites accessibles, cf lfs.traduc.org, absolinux.net, avh.asso.fr, handicapzero.org. Une norme d'accessibilité existe par ailleurs."
Bonne soirée à tous,
Cordialement,
Jean-Philippe MENGUAL
Bonne soirée,
On 02/02/2010 00:02, Jean-Philippe MENGUAL wrote:
Salut,
Complexe de décrire sans termes techniques :) (que je ne connais pas).
Pour frames j'utilise l'appelation des synthèses vocales de Win, mais ça a peut-être un autre nom techniquement. L'idée c'est que ce sont des cadres en tout cas.
Je pense qu'on parle ici de "div", ces « cadres » pouvant avoir un ID et une classe, faisables en CSS (et même conseillés plutôt que tableaux ou frames))
Pour le contre-exemple: wikipedia a des articles illustrés. Les images, niveau synthèse, sont interprétées et c'est leur étiquette qui est affichée. Quand c'est bien fait, sur wikipedia, ça peut donner par exemple: fichier:Ice_hockey_McGill_University_1884 Hockey sur glace à l'Université McGill de Montréal en 1884.
Je pense qu'on parle ici de "alt" (et "title"), un texte alternatif pour les images et une info-bulle éventuelle. Wikipedia a un fonctionnement un peu bizarre en effet.
Certains articles ne mentionnent que Fichier:le_nom_du_fichier, sans étiquette. Là ce serait inaccessible.
Concernant le terme "blocs", je veux dire que les liens peuvent être regroupés au sein d'un cadre qui est étiquetable ou nommable, mais aussi, comme sur un wiki, sous des titres. Pour Traduc, un titre renverrait à un ensemble de liens. Par ex: Un cadre Association, contenant un titre L'association, (h1> </h1> ..., contenant un bloc (ensemble de liens tels que Le CA, Bulletin d'adhésion...).
J'espère avoir éclairé au passage la question des cadres, ne pas trop avoir été confus. Désolé de ce manque de clarté dû au manque de technique.
Bonne soirée,
Pour info, La norme WAI-jesaisplusquoi du W3C existe pour évaluer l'accessibilité d'un site Web pour les malentendants/malvoyants/personnes présentant un handicap et propose même un logo « WAItruc-valid » si le site passe le « validator ». Ce sont en outre des obligations en XHTML que d'apposer ces attributs sur les éléments HTML.
Je suis dans le vrai ?
appzer0
-
appzer0 -
Edi Stojicevic -
Jean-Philippe MENGUAL