1160 sujets

Accessibilité du Web

Pages :
Smiley biggrin En fait je recherches surtout un concentrer en 10 lignes de ce qu'il faut pour qu'un site soit accessible Smiley decu
Merci d'avance Smiley cligne

ps : j'ai déjà lu accessiweb ou encore le W3C mais c'est long et pas résumer... Smiley lol
Modifié par Madrileno (23 Sep 2005 - 17:43)
Bonsoir,
A mon avis savoir comment rendre un site accessible ne s'explique justement pas en quelques lignes.
Ca dépend de beaucoup de paramètres.
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 Smiley cligne
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 Smiley lol
Vous en avez en stock ? ( plus simple de mettre des marques pages ) Smiley confused
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.
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 Smiley biggrin



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 Smiley lol ), 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 ? Smiley confus



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 Smiley biggrin

Merci de vos réponses ça fait plaisir de voir qu'il y a du monde qui cherche à vouloir faire un web universel Smiley cligne
Modifié par Madrileno (23 Sep 2005 - 19:23)
Bonjour,

A question impossible, réponse impossible... Smiley smile

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) Smiley cligne
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 Smiley cligne

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 Smiley cligne

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&#8230;) 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 Smiley smile
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)
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 Smiley biggrin
Maintenant si l'ensemble des techniques seraient plus simples, l'accessibilité de plus de site serait une réalité non ? Smiley confus

La deuxième liste est pas mal déjà et le point 10 une chose à toujours faire Smiley cligne




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 ? Smiley decu




Merci Laurent Denis en fait je ne sais quoi dire face au nombre de points Smiley lol
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 ? Smiley decu

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 Smiley biggrin
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 Smiley lol


Merci à clb56 pour l'ajout de points Smiley cligne
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 Smiley cligne
Petit essai suite au message précédent :

Pareil
a écrit :

Livré en pâture à vos avis féroces Smiley smile


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:

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 Smiley decu 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 ?


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. Smiley smile

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... Smiley cligne
Modifié par jpv (25 Sep 2005 - 01:42)
Pages :