1178 sujets
Accessibilité du Web
Comme Quentin, je pense qu'il est difficile de faire plus court que http://openweb.eu.org/articles/intro_accessibilite/ sans être vraiment très approximatif 
QuentinC a écrit :
Ca dépend de beaucoup de paramètres.
Je sais bien c'est pour cela qu'un résumer simple mais assez complet serait bien
Pour openweb j'ai déjà lu pas mal sur l'accessibilité et à côté du W3C ou de accessweb c'est trop vaste, à la rigueur un livre sur l'accessibilité serait mieux
Vous en avez en stock ? ( plus simple de mettre des marques pages )
Bonjour,
Le document pdf de Matthieu est un bon point de départ, avec des exemples pratiques :
Accessibilité: pourquoi et comment l'améliorer
Modifié par Monique (23 Sep 2005 - 19:01)
Le document pdf de Matthieu est un bon point de départ, avec des exemples pratiques :
Accessibilité: pourquoi et comment l'améliorer
Modifié par Monique (23 Sep 2005 - 19:01)
Je suis partie de ce document : il présente un tableau de 92 recommandations (p9 du document pdf). Après, il faut appronfondir les points que tu vas mettre en application.
Ce lien est intéressant aussi :
http://w3qc.org/docs/webstandards_checklist.html
http://w3qc.org/docs/webstandards_checklist.html
Monique a écrit :
Le document pdf de Matthieu est un bon point de départ
Merci Monique très détaillés et de bons liens en bas que j'avais pas vu encore
Vero a écrit :
Je suis partie de ce document : il présente un tableau de 92 recommandations
Merci beaucoup Vero, j'avais déjà vu ce site ( mais j'avais oublier de lire après avoir télécharger
), par contre une phrase m'intrigue :a écrit :
Ce référentiel est soumis à vos commentaires jusqu’au 27 juin 2005
Le référentiel donc est le final ou va-t-il changer à la rentrée ?
SuD a écrit :
Ce lien est intéressant aussi :
http://w3qc.org/docs/webstandards_checklist.html
Excellent aussi Merci, je crois que le WE va être long
Merci de vos réponses ça fait plaisir de voir qu'il y a du monde qui cherche à vouloir faire un web universel
Modifié par Madrileno (23 Sep 2005 - 19:23)
Madrileno a écrit :
Merci d'avance
ps : j'ai déjà lu accessiweb ou encore le W3C mais c'est long et pas résumer...
C'est court mais pas technique, il ne me semble pas possible en dix lignes de concentrer ce que tu souhaites
:- http://w3qc.org/docs/accessibilite.html
- http://www.w3qc.org/ressources/traductions/composantes-essentielles/
Bonjour,
A question impossible, réponse impossible...
Du point de vue conceptuel ça tiens en une ligne : "Rendre le web universel et accesible à tous"
Du point de vue des techniques à employer il faut 60 lignes (WCAG) ou 92 (Accessiweb).
Voici par exemple une liste, non exhaustive, de points importants établie par la société australienne
maxdesign en conclusion de son excellent slide-show consacré à l'accessibilité du web.
A quick and dirty introduction to accessibility (en) :
* Toutes les images descriptives possèdent-elles un attribut "alt"?
* Le site utilise-t-il des unités relatives pour la taille des caractères?
* Le design reste-t-il cohérent quand on augmente la taille des caractères?
* Le site utilise-t-il des liens d'évitement visibles?
* Les formulaires sont-ils accessibles?
* Les tableaux de données sont-ils accessibles?
* La luminosité et le contraste des couleurs est-il suffisant?
* Des informations importantes sont-elles notifiées uniquement par un code de couleur?
* Certaines fonctions du site requièrent-elles de bons yeux et de la dextérité?
* Tous les liens sont-ils suffisemment clairs ?
* La navigation dans les pages peut-elle s'effectuer uniquement avec le clavier (tabulation)?
* Le contenu est-il accessible quand les CSS sont désactivées ou non supportées?
* Le contenu est-il accessible quand les images sont désactivées ou non supportées?
* Le site est-il utilisable par un navigateur textuel comme Lynx?
* Le site est-il utilisable par la plus grande gamme de navigateurs et de taille d'écran?
Cette liste est "dirty" comme le précise l'auteur, appliqué à un mauvais travail de conception elle donnera une mauvaise accessibilité.
La demande de madrileno est intéressante parce qu'impossible à satisfaire, si l'accessibilité ne deviens qu'un ensemble de techniques spécifiques à respecter le combat est perdus d'avance.
Certes cette étape, liste de controle, méthode d'application, réferentiel est un passage obligé et nécessaire, mais ce qu'il faut changer ce sont les méthodes de développements et la perception qu'en ont les développeurs, webdesigners et webmasters.
Exactement comme l'intégration des handicapés dans la société ne passe pas par la multiplication des rampes d'accès mais par une modification des mentalités.
En revanche, peut-être serait-il possible en 10 lignes de définir des principes de conception et de développement à acquérir jusqu'à ce que cela deviennes naturel et habituel.
C'est de cette manière que j'ai interprété, de manière erronée, la demande de madrileno, du coup j'ai produit cette liste de 10 "principes", j'aimerais avoir vos réactions, démolitions, bookmarks de quelqu'un qui aurait fait ça beaucoup mieux que moi... :
1. Faire simple et clair , ce qui ne veut pas dire pauvre, dépouillé ou indigent.
2. Concevoir à partir du flux qui doit garantir une mise à disposition du contenu indépendante du média, intégrer le fait que le design web n'en est qu'une interprétation particulière et adopter définitivement le concept de séparation du contenu de la forme.
3. Assurer des alternatives pertinentes, crédibles et pérennes à tous les contenus multimédia et applicatifs : images, sons, dispositifs javascript, interfaces tiers (flash, java, 3D).
4. Assurer la cohérence de la navigation, eliminer les redondances, contextualiser les liens, limiter l'arborescence, fournir des aides pertinentes (carte du site, TOC, liens d'évitement, raccourcis clavier…).
5. Respecter scrupuleusement les recommandations d'utilisation et de formatage des tableaux de données, des formulaires, du contenu (titre, paragraphe, emphase, liste…) et des métadonnées.
6. Utiliser exclusivement les versions normalisées des langages, ne publier qu'après avoir validé et éliminé toutes les erreurs même celles sans conséquences apparentes.
8. Limiter les adaptations destinés à prendre en charge les défauts d'implémentations des langages, notamment de CSS ainsi que tout dispositif à destination de conditions particulières de consultation, intégrer que l'accessibilité est fondée sur des compromis.
9. Laisser à l'utilisateur le contrôle total de son interface, limiter aux cas documentés les alternatives applicatives aux fonctionnalités natives de son outil de consultation.
10. Valider par des tests en situation d'usage, appuyés techniquement sur des méthodologies documentées et éprouvées (bonne pratiques, référentiels, méthode de validation), l'utilisabilité de l'ensemble.
Jean-pierre
Modifié par jpv (24 Sep 2005 - 05:34)
A question impossible, réponse impossible...
Du point de vue conceptuel ça tiens en une ligne : "Rendre le web universel et accesible à tous"
Du point de vue des techniques à employer il faut 60 lignes (WCAG) ou 92 (Accessiweb).
Voici par exemple une liste, non exhaustive, de points importants établie par la société australienne
maxdesign en conclusion de son excellent slide-show consacré à l'accessibilité du web.
A quick and dirty introduction to accessibility (en) :
* Toutes les images descriptives possèdent-elles un attribut "alt"?
* Le site utilise-t-il des unités relatives pour la taille des caractères?
* Le design reste-t-il cohérent quand on augmente la taille des caractères?
* Le site utilise-t-il des liens d'évitement visibles?
* Les formulaires sont-ils accessibles?
* Les tableaux de données sont-ils accessibles?
* La luminosité et le contraste des couleurs est-il suffisant?
* Des informations importantes sont-elles notifiées uniquement par un code de couleur?
* Certaines fonctions du site requièrent-elles de bons yeux et de la dextérité?
* Tous les liens sont-ils suffisemment clairs ?
* La navigation dans les pages peut-elle s'effectuer uniquement avec le clavier (tabulation)?
* Le contenu est-il accessible quand les CSS sont désactivées ou non supportées?
* Le contenu est-il accessible quand les images sont désactivées ou non supportées?
* Le site est-il utilisable par un navigateur textuel comme Lynx?
* Le site est-il utilisable par la plus grande gamme de navigateurs et de taille d'écran?
Cette liste est "dirty" comme le précise l'auteur, appliqué à un mauvais travail de conception elle donnera une mauvaise accessibilité.
La demande de madrileno est intéressante parce qu'impossible à satisfaire, si l'accessibilité ne deviens qu'un ensemble de techniques spécifiques à respecter le combat est perdus d'avance.
Certes cette étape, liste de controle, méthode d'application, réferentiel est un passage obligé et nécessaire, mais ce qu'il faut changer ce sont les méthodes de développements et la perception qu'en ont les développeurs, webdesigners et webmasters.
Exactement comme l'intégration des handicapés dans la société ne passe pas par la multiplication des rampes d'accès mais par une modification des mentalités.
En revanche, peut-être serait-il possible en 10 lignes de définir des principes de conception et de développement à acquérir jusqu'à ce que cela deviennes naturel et habituel.
C'est de cette manière que j'ai interprété, de manière erronée, la demande de madrileno, du coup j'ai produit cette liste de 10 "principes", j'aimerais avoir vos réactions, démolitions, bookmarks de quelqu'un qui aurait fait ça beaucoup mieux que moi... :
1. Faire simple et clair , ce qui ne veut pas dire pauvre, dépouillé ou indigent.
2. Concevoir à partir du flux qui doit garantir une mise à disposition du contenu indépendante du média, intégrer le fait que le design web n'en est qu'une interprétation particulière et adopter définitivement le concept de séparation du contenu de la forme.
3. Assurer des alternatives pertinentes, crédibles et pérennes à tous les contenus multimédia et applicatifs : images, sons, dispositifs javascript, interfaces tiers (flash, java, 3D).
4. Assurer la cohérence de la navigation, eliminer les redondances, contextualiser les liens, limiter l'arborescence, fournir des aides pertinentes (carte du site, TOC, liens d'évitement, raccourcis clavier…).
5. Respecter scrupuleusement les recommandations d'utilisation et de formatage des tableaux de données, des formulaires, du contenu (titre, paragraphe, emphase, liste…) et des métadonnées.
6. Utiliser exclusivement les versions normalisées des langages, ne publier qu'après avoir validé et éliminé toutes les erreurs même celles sans conséquences apparentes.
8. Limiter les adaptations destinés à prendre en charge les défauts d'implémentations des langages, notamment de CSS ainsi que tout dispositif à destination de conditions particulières de consultation, intégrer que l'accessibilité est fondée sur des compromis.
9. Laisser à l'utilisateur le contrôle total de son interface, limiter aux cas documentés les alternatives applicatives aux fonctionnalités natives de son outil de consultation.
10. Valider par des tests en situation d'usage, appuyés techniquement sur des méthodologies documentées et éprouvées (bonne pratiques, référentiels, méthode de validation), l'utilisabilité de l'ensemble.
Jean-pierre
Modifié par jpv (24 Sep 2005 - 05:34)
a écrit :
C'est de cette manière que j'ai interprété, de manière erronée, la demande de madrileno, du coup j'ai produit cette liste de 10 "principes", j'aimerais avoir vos réactions, démolitions, bookmarks de quelqu'un qui aurait fait ça beaucoup mieux que moi
Je crois que acces-pour-tous travail sur quelque chose qui s'en rapproche.
message de stephkup sur Alsacréations
Bonjour,
Je ferais une remarque "immédiate" sur l'excellente liste de principes de Jean-Pierre, que je m'empresse de bookmarquer :
HTML et XHTML1.0 ne permettent qu'une séparation partielle de la forme et du contenu, car :
- ce sont des langages encore très concrets (un tableau définit moins un type de relation entre données qu'un type de restitution lié aux medias visuels, un titre définit plus une mise en valeur formelle qu'un intitulé de section hiérachisée, etc.)
- les mécanismes d'alternatives aux contenus multimédias y sont très limités (Comparer avec XHTML2.0). Ils sont inexistants pour CSS2.x.
- les implémentations problématiques de CSS2.x conduisent à des contournements risqués.
Dans ces conditions, les solutions privilégiant systématiquement cette séparation ne sont pas nécessairement les plus accessibles.
Le cas type est celui du contenu textuel "masqué" en CSS et remplacé à l'écran par une image d'arrière-plan CSS : c'est apparemment très satisfaisant, mais en fait inaccessible à l'utilisateur d'IE qui a coché l'option "Ignorer les couleurs d'arrière-plan" dans ses options d'accessibilité. En revanche, l'image <img alt="..."> se révèle bien plus fiable.
Un autre cas-type: la gestion des hauteurs et des centrages verticaux, où la solution tableaux est finalement souvent plus accessible que la solution CSS.
Il faut donc peser, au cas par cas, l'accessibilité d'une solution séparant la présentation et le contenu, et celle d'une solution intégrant la présentation dans le contenu. Et privilégier la solution la plus "robuste" au sens des 4 principes d'accessibilité cités dans mon message suivant.
Ce qui montre bien, d'ailleurs, l'impossibilité de "résumer" techniquement l'accessibilité, et la difficulté de la résumer en choisissant l'approche "principes de conception" qui me semble effectivement la meilleure (ou la moins mauvaise)
Modifié par Laurent Denis (24 Sep 2005 - 07:40)
Je ferais une remarque "immédiate" sur l'excellente liste de principes de Jean-Pierre, que je m'empresse de bookmarquer :
HTML et XHTML1.0 ne permettent qu'une séparation partielle de la forme et du contenu, car :
- ce sont des langages encore très concrets (un tableau définit moins un type de relation entre données qu'un type de restitution lié aux medias visuels, un titre définit plus une mise en valeur formelle qu'un intitulé de section hiérachisée, etc.)
- les mécanismes d'alternatives aux contenus multimédias y sont très limités (Comparer avec XHTML2.0). Ils sont inexistants pour CSS2.x.
- les implémentations problématiques de CSS2.x conduisent à des contournements risqués.
Dans ces conditions, les solutions privilégiant systématiquement cette séparation ne sont pas nécessairement les plus accessibles.
Le cas type est celui du contenu textuel "masqué" en CSS et remplacé à l'écran par une image d'arrière-plan CSS : c'est apparemment très satisfaisant, mais en fait inaccessible à l'utilisateur d'IE qui a coché l'option "Ignorer les couleurs d'arrière-plan" dans ses options d'accessibilité. En revanche, l'image <img alt="..."> se révèle bien plus fiable.
Un autre cas-type: la gestion des hauteurs et des centrages verticaux, où la solution tableaux est finalement souvent plus accessible que la solution CSS.
Il faut donc peser, au cas par cas, l'accessibilité d'une solution séparant la présentation et le contenu, et celle d'une solution intégrant la présentation dans le contenu. Et privilégier la solution la plus "robuste" au sens des 4 principes d'accessibilité cités dans mon message suivant.
Ce qui montre bien, d'ailleurs, l'impossibilité de "résumer" techniquement l'accessibilité, et la difficulté de la résumer en choisissant l'approche "principes de conception" qui me semble effectivement la meilleure (ou la moins mauvaise)
Modifié par Laurent Denis (24 Sep 2005 - 07:40)
knarf a écrit :
Je crois que acces-pour-tous travail sur quelque chose qui s'en rapproche.
message de stephkup sur Alsacréations
Ah... Justement non.
La liste en cours d'élaboration sur http://www.acces-pour-tous.net/validateur/index.php n'offre pas des principes de conception. C'est au contraire, explicitement d'ailleurs, une Procédure afin de valider l'accessibilité d'une page. C'est une version étoffée des listes de points techniques comme celle de maxdesign citée par Jean-Pierre. Elle ne corrigera pas l'accessibilité d'un site dont la conception n'a pas intégrée l'accessibilité comme composante qualitative dès le départ.
Je précise, bien-sûr, que ces listes sont utiles, nécessaires, etc. Mais elles n'offrent qu'une approche très restrictive du problème. Du coup :
- elles perdent une grande partie de leur utilité si elles conduisent à ramener l'accessibilité à une série de points à valider in fine.
- elles ne devraient surtout pas être le moyen par lequel on se forme à l'accessibilité, comme c'est très souvent (toujours ?) le cas.
L'accessibilité est bien plus une manière d'aborder la conception Web qu'une somme de techniques. Le projet WCAG2.0 la définit... en 4 principes :
a écrit :
1.Le contenu doit être perceptible ;
2.Les éléments d'interaction doivent être utilisables ;
3.Le contenu et les commandes doivent être compréhensibles ;
4.Le contenu doit être assez robuste pour fonctionner avec les technologies actuelles et celles à venir.
J'ai mis en gras les 4 mots clés
Pour définir une liste plus détaillée, l'un des documents de fond du W3C sur la conception Web (non traduit, désolé) donne une très bonne illustration de ce que pourrait être une approche de l'accessibilité en tant que principes et non en tant que techniques : Device Independence Principles. Ce serait une piste à exploiter pour affiner et structurer la liste de Jean-Pierre, en prenant comme référent les 4 principes fondamentaux ci-dessus.
Modifié par Laurent Denis (24 Sep 2005 - 07:20)
C'est encore moi
Petit essai suite au message précédent :
1.Le contenu doit être perceptible ;
1.1 Concevoir le contenu indépendamment de ses représentations selon les medias et leurs capacités.
1.2 Assurer des alternatives pertinentes, crédibles et pérennes à tous les contenus multimédia et applicatifs : images, sons, dispositifs javascript, interfaces tiers (flash, java, 3D).
2.Les éléments d'interaction doivent être utilisables ;
2.1 Permettre une expérience fonctionnelle quelque-soit le media ou les capacités du client.
2.2 Assurer la cohérence de la navigation, eliminer les redondances, contextualiser les liens, fournir des aides pertinentes (carte du site, TOC, liens d'évitement, raccourcis clavier).
2.3 Laisser à l'utilisateur le contrôle total de son interface.
3.Le contenu et les commandes doivent être compréhensibles ;
3.1 Faire simple et clair , ce qui ne veut pas dire pauvre, dépouillé ou indigent. Limiter l'arborescence.
3.2 Concevoir un contenu cohérent et compréhensible sur la seule base du flux.
3.3 Privilégier les interfaces légers et extensibles selon les préférences de l'utilisateur.
4.Le contenu doit être assez robuste pour fonctionner avec les technologies actuelles et celles à venir.
4.1 Utiliser exclusivement les versions normalisées des langages, ne publier qu'après avoir validé et éliminé toutes les erreurs même celles sans conséquences apparentes.
4.2 Respecter scrupuleusement les recommandations d'utilisation et de formatage des tableaux de données, des formulaires, du contenu (titre, paragraphe, emphase, liste…) et des métadonnées.
4.3 Limiter les adaptations destinés à prendre en charge les défauts d'implémentations des langages, notamment de CSS ainsi que tout dispositif à destination de conditions particulières de consultation. , Limiter aux cas documentés les alternatives applicatives aux fonctionnalités natives des outils de consultation.
4.4 Privilégier par ordre les solutions de présentation les plus robustes, puis celles séparant forme et contenu.
Livré en pâture à vos avis féroces
Modifié par Laurent Denis (24 Sep 2005 - 08:29)
Petit essai suite au message précédent :
1.Le contenu doit être perceptible ;
1.1 Concevoir le contenu indépendamment de ses représentations selon les medias et leurs capacités.
1.2 Assurer des alternatives pertinentes, crédibles et pérennes à tous les contenus multimédia et applicatifs : images, sons, dispositifs javascript, interfaces tiers (flash, java, 3D).
2.Les éléments d'interaction doivent être utilisables ;
2.1 Permettre une expérience fonctionnelle quelque-soit le media ou les capacités du client.
2.2 Assurer la cohérence de la navigation, eliminer les redondances, contextualiser les liens, fournir des aides pertinentes (carte du site, TOC, liens d'évitement, raccourcis clavier).
2.3 Laisser à l'utilisateur le contrôle total de son interface.
3.Le contenu et les commandes doivent être compréhensibles ;
3.1 Faire simple et clair , ce qui ne veut pas dire pauvre, dépouillé ou indigent. Limiter l'arborescence.
3.2 Concevoir un contenu cohérent et compréhensible sur la seule base du flux.
3.3 Privilégier les interfaces légers et extensibles selon les préférences de l'utilisateur.
4.Le contenu doit être assez robuste pour fonctionner avec les technologies actuelles et celles à venir.
4.1 Utiliser exclusivement les versions normalisées des langages, ne publier qu'après avoir validé et éliminé toutes les erreurs même celles sans conséquences apparentes.
4.2 Respecter scrupuleusement les recommandations d'utilisation et de formatage des tableaux de données, des formulaires, du contenu (titre, paragraphe, emphase, liste…) et des métadonnées.
4.3 Limiter les adaptations destinés à prendre en charge les défauts d'implémentations des langages, notamment de CSS ainsi que tout dispositif à destination de conditions particulières de consultation. , Limiter aux cas documentés les alternatives applicatives aux fonctionnalités natives des outils de consultation.
4.4 Privilégier par ordre les solutions de présentation les plus robustes, puis celles séparant forme et contenu.
Livré en pâture à vos avis féroces
Modifié par Laurent Denis (24 Sep 2005 - 08:29)
Les points 3.2 et 1.1 sont très proches et pourraient donner lieu à une synthèse.
je rajouterais en position d'antériorité logique un point 0
0. apprendre à concevoir un site comme un pur contenu consultable et auto-suffisant avant mise en oeuvre de quelque modalité de présentation que ce soit.
Dit autrement apprendre à faire du html sans css.
Modifié par clb56 (25 Sep 2005 - 09:37)
je rajouterais en position d'antériorité logique un point 0
0. apprendre à concevoir un site comme un pur contenu consultable et auto-suffisant avant mise en oeuvre de quelque modalité de présentation que ce soit.
Dit autrement apprendre à faire du html sans css.
Modifié par clb56 (25 Sep 2005 - 09:37)
jpv a écrit :
Du point de vue des techniques à employer il faut 60 lignes (WCAG) ou 92 (Accessiweb).
La demande de madrileno est intéressante parce qu'impossible à satisfaire, si l'accessibilité ne deviens qu'un ensemble de techniques spécifiques à respecter le combat est perdus d'avance.
Merci beaucoup pour votre réponse et détails
Maintenant si l'ensemble des techniques seraient plus simples, l'accessibilité de plus de site serait une réalité non ?
La deuxième liste est pas mal déjà et le point 10 une chose à toujours faire
knarf a écrit :
Je crois que acces-pour-tous travail sur quelque chose qui s'en rapproche.
Merci pour le lien, j'ai fait une recherche sur jaws mais il semble être un logiciel payant ?
Merci Laurent Denis en fait je ne sais quoi dire face au nombre de points
a écrit :
Le cas type est celui du contenu textuel "masqué" en CSS et remplacé à l'écran par une image d'arrière-plan CSS : c'est apparemment très satisfaisant, mais en fait inaccessible à l'utilisateur d'IE qui a coché l'option "Ignorer les couleurs d'arrière-plan" dans ses options d'accessibilité. En revanche, l'image <img alt="..."> se révèle bien plus fiable.
Je n'ai pas trop compris, avez-vous un exemple ?
a écrit :
L'accessibilité est bien plus une manière d'aborder la conception Web qu'une somme de techniques. Le projet WCAG2.0 la définit... en 4 principes :
Un bon résumer
Pour le dernier message avec les détails ça s'approche bien de la première question excellent, maintenant je vais tacher d'allez chercher de l'encre et imprimer toutes les pages à lire précédentes
Merci à clb56 pour l'ajout de points
Laurent Denis a écrit :
La liste en cours d'élaboration sur http://www.acces-pour-tous.net/validateur/index.php n'offre pas des principes de conception. C'est au contraire, explicitement d'ailleurs, une Procédure afin de valider l'accessibilité d'une page. C'est une version étoffée des listes de points techniques comme celle de maxdesign citée par Jean-Pierre. Elle ne corrigera pas l'accessibilité d'un site dont la conception n'a pas intégrée l'accessibilité comme composante qualitative dès le départ.
je trouve ta dernière phrase un peu abrupte, je suis d'accord qu'un contrôle à posteriori aura du mal à compenser une mauvaise conception à l'origine mais je pense que ce type de checklist permet tout de même de lever de nombreux obstacles, d'apréhender les différents problèmes d'accessibilité et qu'elle aide a mettre le pied à l'étrier.
a écrit :
Je précise, bien-sûr, que ces listes sont utiles, nécessaires, etc. Mais elles n'offrent qu'une approche très restrictive du problème. Du coup :
- elles perdent une grande partie de leur utilité si elles conduisent à ramener l'accessibilité à une série de points à valider in fine.
- elles ne devraient surtout pas être le moyen par lequel on se forme à l'accessibilité, comme c'est très souvent (toujours ?) le cas.
Je crois que nous ne nous adressons pas au même public, il me semble que tu t'adresses plus à des professionnels (concepteur de site web) et qu'inconsciemment accès pour tous est plus destiné à un public amateur qui désire améliorer ses pages persos.
Le but premier de la page sur laquelle je travaille est de ramener la validation automatique à un simple contrôle parmi d'autres afin de pouvoir insister plus sur les point non techniques comme l'intitulé des liens, les aides à la navigation, l'architecture d'un site... Rien que ce dernier point mériterait l'écriture d'un livre entier, une page accessible techniquement mais que le visiteur est incapable de trouver au millieu d'un fouillis inommable ne sert à rien. Mais expliquer cela en quelques phrases est difficile et demande du temps que je n'ai pas.
Laurent Denis a écrit :
C'est encore moi
Petit essai suite au message précédent :
Pareil
a écrit :
Livré en pâture à vos avis féroces
Comment on fait avec Dreamweaver ?
Non ce n'est pas une boutade et encore moins un troll, je pense sincèrement que l'accessibilité présentée comme cela peut faire fuir immédiatement un grand nombre d'auteurs de pages web.
J'espère que la rubrique "exemples" des WCAG 2 va s'étoffer car sans cela j'ai peur de leur inéfficacité. La recherche de pérennité et l'orientation "généraliste" me laisse un peu sceptique.
Pour reprendre ton message afin d'illustrer ma pensée :
a écrit :
"2.1 Permettre une expérience fonctionnelle quelque-soit le media ou les capacités du client."
C'est concis, efficace, juste et compréhensible quand on sait de quoi on parle. Est-ce que cela sera compris par l'ensemble des gens concevant des pages web et est-ce qu'ils percevront l'étendue de la portée de cette phrase ? J'ai énormément de doutes.
Je reviendrais sur les dernières déclarations de Stepkup car je pense que l'on est au coeur du problème.
D'une manière générale, les personnes défendants les standards (accessibilité en l'occurence) soutiennent mordicus que l'on ne parle pas qu'aux professionels et que les standards sont accessibles à tous le monde.
Dans l'état actuel des choses je soutiens aussi mordicus que c'est faux, vous ne vous mettez pas à la portée de tous les niveaux.
le niveau d'implication
le niveau technique
le niveaux sociaux culturels.
Il n'est plus question maintenant de faire un site web mais de comprendre un site web.
En général, êtes vous sur que vos discours le permettent.
Je trouve que ce que fait acces-pour-tous avec sa cheklist est très bien, et comme le dit stephkup:
Ne faut il pas passer par là pour permettre une démocratisation et se donner les moyens de cette démocratisation.
Quand quelqu'un sur le forum demande de tester l'accessibilité de son site les réponses de test ne sont elles pas plus basées sur la liste de stephkup que sur celle de Laurent Denis sans enlever la qualité de celle-ci mais qui s'adresse à une personne ayant un autre niveau d'implication et une approche beaucoup plus technique de l'accessibilité.
Une fois vero m'as demandé si j'avais une cheklist de vérifications de bases ou quelque chose dans le genre quand je réponds sur le forum je lui est dit que non mais que c'était une bonne idée je m'en suis donc créer une, moins importante que celle de Stephkup mais qui permet déjà d'avoir une bonne idée de l'accessibilité d'un site dans les grandes lignes.
Cela fera d'ailleurs l'objet d'un tuto sur le nouveau web-pour-tous.
Je reste persuadé que c'est le problème majeur des standards en général, se mettre au niveau de tout le monde.
Vous compliquez des choses relativement faciles pour rien, alors quand il s'agit d'un sujet plus complexe...
Quand jpv, Laurent Denis entre autres parle d'accessibilité c'est beau, c'est technique,c'est interessant, cela fait chanter la langue française, mais est-ce assimilable par n'importe qui.
Est ce que vous dialoguez comme cela dans la vie de tous le jours?
J'ai lu sur ergologie.com je crois un début d'article je dit début car l'article entier était en anglais que l'on pouvait trés bien "écrire" un billet ou un article comme "l'on parle" en prenant d'après ce que j'ai compris certaines précautions.
Je pense que là il yas un point important à prendre en compte.
cordialement Frank .
EDIT:
Je viens de relire et c'est vrai que mon discours est peut être un peu simpliste dans le sens ou effectivement balancer une liste comme cela sans une prise de conscience au préalable n'est pas la meilleure solution.
Mais je pense que la solution se trouve entre les deux aprés, est-ce facile à faire ça je veux bien admettre que non.
Modifié par knarf (27 Sep 2005 - 18:17)
D'une manière générale, les personnes défendants les standards (accessibilité en l'occurence) soutiennent mordicus que l'on ne parle pas qu'aux professionels et que les standards sont accessibles à tous le monde.
Dans l'état actuel des choses je soutiens aussi mordicus que c'est faux, vous ne vous mettez pas à la portée de tous les niveaux.
le niveau d'implication
le niveau technique
le niveaux sociaux culturels.
Il n'est plus question maintenant de faire un site web mais de comprendre un site web.
En général, êtes vous sur que vos discours le permettent.
Je trouve que ce que fait acces-pour-tous avec sa cheklist est très bien, et comme le dit stephkup:
a écrit :
Je crois que nous ne nous adressons pas au même public, il me semble que tu t'adresses plus à des professionnels (concepteur de site web) et qu'inconsciemment accès pour tous est plus destiné à un public amateur qui désire améliorer ses pages persos.
Ne faut il pas passer par là pour permettre une démocratisation et se donner les moyens de cette démocratisation.
Quand quelqu'un sur le forum demande de tester l'accessibilité de son site les réponses de test ne sont elles pas plus basées sur la liste de stephkup que sur celle de Laurent Denis sans enlever la qualité de celle-ci mais qui s'adresse à une personne ayant un autre niveau d'implication et une approche beaucoup plus technique de l'accessibilité.
Une fois vero m'as demandé si j'avais une cheklist de vérifications de bases ou quelque chose dans le genre quand je réponds sur le forum je lui est dit que non mais que c'était une bonne idée je m'en suis donc créer une, moins importante que celle de Stephkup mais qui permet déjà d'avoir une bonne idée de l'accessibilité d'un site dans les grandes lignes.
Cela fera d'ailleurs l'objet d'un tuto sur le nouveau web-pour-tous.
Je reste persuadé que c'est le problème majeur des standards en général, se mettre au niveau de tout le monde.
Vous compliquez des choses relativement faciles pour rien, alors quand il s'agit d'un sujet plus complexe...
Quand jpv, Laurent Denis entre autres parle d'accessibilité c'est beau, c'est technique,c'est interessant, cela fait chanter la langue française, mais est-ce assimilable par n'importe qui.
Est ce que vous dialoguez comme cela dans la vie de tous le jours?
J'ai lu sur ergologie.com je crois un début d'article je dit début car l'article entier était en anglais
que l'on pouvait trés bien "écrire" un billet ou un article comme "l'on parle" en prenant d'après ce que j'ai compris certaines précautions.Je pense que là il yas un point important à prendre en compte.
cordialement Frank .
EDIT:
a écrit :
Cette liste est "dirty" comme le précise l'auteur, appliqué à un mauvais travail de conception elle donnera une mauvaise accessibilité.
La demande de madrileno est intéressante parce qu'impossible à satisfaire, si l'accessibilité ne deviens qu'un ensemble de techniques spécifiques à respecter le combat est perdus d'avance.
Certes cette étape, liste de controle, méthode d'application, réferentiel est un passage obligé et nécessaire, mais ce qu'il faut changer ce sont les méthodes de développements et la perception qu'en ont les développeurs, webdesigners et webmasters.
Je viens de relire et c'est vrai que mon discours est peut être un peu simpliste dans le sens ou effectivement balancer une liste comme cela sans une prise de conscience au préalable n'est pas la meilleure solution.
Mais je pense que la solution se trouve entre les deux aprés, est-ce facile à faire ça je veux bien admettre que non.
Modifié par knarf (27 Sep 2005 - 18:17)
Bonjour a tous,
Je trouve cette opposition amateur vs professionnels un peut stérile.
Que l'amorce de liste que j'ai produis et l'excellent travail qu'en à tiré Laurent
s'adressent à des profils relativement compétents c'est une évidence, et alors ?
En quoi est-ce un problème ?
C'est amusant parce que je dirais exactement l'inverse, l'approche purement technique est justement celle qui s'appuie sur une checklist.
L'approche de Laurent et de moi-même au sujet de cette liste, est tout sauf technique, il n'y à aucun rapport de près ou de loin entre cette liste et une liste de contrôle.
Les opposer n'à aucun sens.
Ce que je voulais relever avec cette tentative de liste et quà excellement bien compris Laurent, c'est que si l'on dispose d'un corpus technique suffisant et généralement satisfaisant au travers des listes de contrôles, des référentiels et des méthodes d'application, il est important de ne pas laisser l'accessibilité s'enfermer dans cette seule perspective.
"Se mettre au niveau de tout le monde", oui parfaitement d'accord si tout le monde va de l'amateur au professionnel de haut niveau.
Ce qui est facile c'est de s'en tenir à de la technique pure, autrement dit cocher une checklist, mais cette approche ne garantis rien quand à l'accessibilité, cela garantis qu'un processus de vérification à été mené mais absolument pas que l'application des recommendations est pertinente.
A ce premier niveau on peut valider absolument n'importe quoi.
Tu n'imagines pas le nombre de fois où je me suis trouvé devant des images de logo dont le concepteur était très fier de ne pas avoir oublier de mettre un alt="logo de la société".
D'un point de vue strictement technique, rien à dire, c'est valide.
Du point de vue de l'accessibilité par contre...
C'est un exemple simplissime, quand il s'agit de redéfinir un flux, de travailler sur les hierachies de titres, sur la pertinence et les alternatives, la check-list, le référentiel, la méthode d'application ne sont d'aucuns secours.
Ce travail est à faire en amont en modifiant en profondeur les méthodologies de conception et la perception qu'on les auteurs de leur travail.
Encore une fois, rien à voir avec le contrôle de quoi que ce soit.
Je penses exactement l'inverse, cette approche sera simplement ignorée par ceux qui ne la comprendront pas au profit d'une approche plus fonctionnelle, jusqu'au jour où ils seront capable d'y revenir et de l'assimiler.
C'est le cycle normal de l'apprentissage.
Tu a raison d'avoir des doutes, cette liste est exactement l'inverse d'une vulgarisation.
Le propos est simplement de présenter les concepts et les pistes méthodologiques nécessaires pour intégrer l'accessibilité en amont de la conception, c'est à dire exactement là où elle doit être pour assurer au mieux son efficacité et sa pertinence.
Cela s'adresse effectivement à ceux qui peuvent le comprendre, mais pour eux c'est vital de disposer de ce genre de discours, faute de quoi ils n'auront de l'accessibilité que l'approche purement technique, ce qui serait catastrophique.
Jean-pierre
Ps: @Laurent : excellent !!! je prends le temps d'y réflechir...
Modifié par jpv (25 Sep 2005 - 01:42)
Je trouve cette opposition amateur vs professionnels un peut stérile.
Que l'amorce de liste que j'ai produis et l'excellent travail qu'en à tiré Laurent
s'adressent à des profils relativement compétents c'est une évidence, et alors ?
En quoi est-ce un problème ?
a écrit :
Quand quelqu'un sur le forum demande de tester l'accessibilité de son site les réponses de test ne sont elles pas plus basées sur la liste de stephkup que sur celle de Laurent Denis sans enlever la qualité de celle-ci mais qui s'adresse à une personne ayant un autre niveau d'implication et une approche beaucoup plus technique de l'accessibilité.
C'est amusant parce que je dirais exactement l'inverse, l'approche purement technique est justement celle qui s'appuie sur une checklist.
L'approche de Laurent et de moi-même au sujet de cette liste, est tout sauf technique, il n'y à aucun rapport de près ou de loin entre cette liste et une liste de contrôle.
Les opposer n'à aucun sens.
Ce que je voulais relever avec cette tentative de liste et quà excellement bien compris Laurent, c'est que si l'on dispose d'un corpus technique suffisant et généralement satisfaisant au travers des listes de contrôles, des référentiels et des méthodes d'application, il est important de ne pas laisser l'accessibilité s'enfermer dans cette seule perspective.
a écrit :
Je reste persuadé que c'est le problème majeur des standards en général, se mettre au niveau de tout le monde.
Vous compliquez des choses relativement faciles pour rien alors quand il s'agit d'un sujet plus complexe...
"Se mettre au niveau de tout le monde", oui parfaitement d'accord si tout le monde va de l'amateur au professionnel de haut niveau.
Ce qui est facile c'est de s'en tenir à de la technique pure, autrement dit cocher une checklist, mais cette approche ne garantis rien quand à l'accessibilité, cela garantis qu'un processus de vérification à été mené mais absolument pas que l'application des recommendations est pertinente.
A ce premier niveau on peut valider absolument n'importe quoi.
Tu n'imagines pas le nombre de fois où je me suis trouvé devant des images de logo dont le concepteur était très fier de ne pas avoir oublier de mettre un alt="logo de la société".
D'un point de vue strictement technique, rien à dire, c'est valide.
Du point de vue de l'accessibilité par contre...
C'est un exemple simplissime, quand il s'agit de redéfinir un flux, de travailler sur les hierachies de titres, sur la pertinence et les alternatives, la check-list, le référentiel, la méthode d'application ne sont d'aucuns secours.
Ce travail est à faire en amont en modifiant en profondeur les méthodologies de conception et la perception qu'on les auteurs de leur travail.
Encore une fois, rien à voir avec le contrôle de quoi que ce soit.
a écrit :
Non ce n'est pas une boutade et encore moins un troll, je pense sincèrement que l'accessibilité présentée comme cela peut faire fuir immédiatement un grand nombre d'auteurs de pages web.
Je penses exactement l'inverse, cette approche sera simplement ignorée par ceux qui ne la comprendront pas au profit d'une approche plus fonctionnelle, jusqu'au jour où ils seront capable d'y revenir et de l'assimiler.
C'est le cycle normal de l'apprentissage.
a écrit :
Est-ce que cela sera compris par l'ensemble des gens concevant des pages web et est-ce qu'ils percevront l'étendue de la portée de cette phrase ? J'ai énormément de doutes.
Tu a raison d'avoir des doutes, cette liste est exactement l'inverse d'une vulgarisation.
Le propos est simplement de présenter les concepts et les pistes méthodologiques nécessaires pour intégrer l'accessibilité en amont de la conception, c'est à dire exactement là où elle doit être pour assurer au mieux son efficacité et sa pertinence.
Cela s'adresse effectivement à ceux qui peuvent le comprendre, mais pour eux c'est vital de disposer de ce genre de discours, faute de quoi ils n'auront de l'accessibilité que l'approche purement technique, ce qui serait catastrophique.
Jean-pierre
Ps: @Laurent : excellent !!! je prends le temps d'y réflechir...
Modifié par jpv (25 Sep 2005 - 01:42)