1178 sujets

Accessibilité du Web

Témoignage de jean-Philippe... Non Voyant

Pages :
Bonjour !

Avec son autorisation, je copie ici un mail de Jean-Philippe, non voyant, posté sur la liste de diffusion dont j'ai parlé dans cet échange.
a écrit :
Bonjour,

Je suppose que le site de l'ADAE a été construit en tenant compte du référentiel Accessiweb.

Cela me donne l'occasion de réouvrir le débat relatif à la notion d'accessibilité. Effectivement, il serait faux de prétendre que le site de l'ADAE n'est pas accessible. Il l'est complètement, puisqu'on peut accéder à toute l'information (enfin du moins je n'ai pas fait un audit complet, mais depuis le temps que je le parcoure, je n'ai rien relevé d'anormal). Eh! bien me croirez-vous si je vous dis que, pour ce qui me concerne, j'ai parfois moins de difficultés à récolter de l'information sur des sites certainement moins accessibles, au sens technique du terme, mais mieux organisés.

Par exemple, l'ADAE donne accès à de nombreux documents, dont la plupart sont à télécharger dans tel ou tel format. Pourquoi ne pas offrir également la possibilité, à l'instar par exemple de ce qu'on trouve à propos du dossier Braillenet sur les propositions en matière d'accessibilité évoqué dans un précédent message, de consulter les contenus en ligne via des pages et un contenu html?

S'agissant des contenus à télécharger, j'avais écrit en son temps au webmaster du site de la documentation Française, car tous les rapports édités sur ce site sont au format PDF, que je ne trouve pas d'une lecture très aisée. Il m'avait répondu que la documentation française mettrait tout en oeuvre pour que les documents soient également disponibles dans d'autres formats, comme word ou HTML. On attend toujours.

Je note encore que dans de très nombreux sites accessibles d'un point de vue technique, l'organisation des pages web laisse à désirer. Par exemple, vous vous trouvez sur une page d'accueil et vous cliquez sur un lien. Et bien dans la plupart des cas, le contenu qui vous intéresse, à partir du moment où vous avez cliqué sur le lien, sera lu par jaws en dernier, ou, du moins, après un rappel totalement inutile de menus dont vous avez déjà pris connaissance sur la page précédente. De ce point de vue, deux solutions sembleraient envisageables au néophite que je suis : la première serait d'organiser la page de telle manière que le contenu nouveau apparaisse au début de la page ouverte par le clic sur le lien considéré ; la seconde, déjà mise en oeuvre dans bon nombre de site, est de prévoir un lien ou un raccourci clavier "accès direct au contenu".
Est-ce que l'adoption du W3C ou du référentiel Accessiweb rendrait obligatoire la présence de tels aménagements?

Bien cordialement,

Jean-Philippe
Bonjour à tous,
je lis beaucoup ce forum et vous m'avez convaincu d'essayer de rendre la prochaine version de mon site accessible, le problème souligné par Jean philippe, est il gérable avec le tabindex (en numérotant le menu après une ancre sur le contenu), ou faut il écrire le menu après dans le code source ? Smiley ohwell
Les tabbindex n'ont aucun rapport dans ce cas ci.

Mais Jean-Philippe donne les deux solutions :

a écrit :
Et bien dans la plupart des cas, le contenu qui vous intéresse, à partir du moment où vous avez cliqué sur le lien, sera lu par jaws en dernier, ou, du moins, après un rappel totalement inutile de menus dont vous avez déjà pris connaissance sur la page précédente. De ce point de vue, deux solutions sembleraient envisageables au néophite que je suis : la première serait d'organiser la page de telle manière que le contenu nouveau apparaisse au début de la page ouverte par le clic sur le lien considéré ; la seconde, déjà mise en oeuvre dans bon nombre de site, est de prévoir un lien ou un raccourci clavier "accès direct au contenu".
Est-ce que l'adoption du W3C ou du référentiel Accessiweb rendrait obligatoire la présence de tels aménagements?


Il serait intéressant de savoir ce qui est le mieux.

En effet, c'est souvent un rien plus compliqué pour nous webmaster de mettre le contenu en premier.

Mais c'est vrai que les raccourcis "accès au xxx" requièrent un peu plus de la part des utilisateurs.

Mais en même temps, s'ils veulent le menu, ils l'ont directement aussi...

Ce serait bien de savoir clairement quoi faire dans ce cas... (qui s'applique à quasiment tous les sites)
bonsoir,

visiblement, l'histoire de Jean Philippe, que je suis sur la liste de diffusion de accessiweb, nous renvoi au probleme suivant:
- Mettre le contenu en premier ou le menu. En ces termes, je veux bien sur parler de la lecture qui se fera avec un lecteur d'ecran.

Ce qui nous renvoi également à parler des "liens d'evitements" qui sont sujets a forte critique dans certains cas. Les liens d'evitements peuvent effectivement permettre de sauter directement au contenu soit au menu soit a la recherche, etc... Mais, dans le cas d'un menu, est on obliger de parcourir tout le menu pour aller cliquez sur le dernier lien de celui ci, ou doit proposer des liens d'evitements qui permettent de sauter de rubrique en rubrique dans le menu?
Ne vas t on pas mettre trop de liens d'evitement dans ce cas la?
La navigation par TAB a t elle une limite en nombre de liens?

Cette discussion n'a pas fini de faire couler de l'encre. Y a t il une solution ideale ?
Sur www.web-pour-tous.org nous cherchons des reponses a ces questions. Nous emetons des solutions qui se traduises par des amenagements sur le site. Faites le test, et dites nous ce que vous en pensez Smiley cligne . Toutes les solutions sont envisageables et bonne a prendre. Et ensemble, nous trouverons la bonne.
Modifié par Philippe (02 Jul 2005 - 01:40)
Pour les liens d'évitement courant (menu, contenu, recherche), ça devrait théoriquement être le rôle des <link> non ?

Mais apparement leur prise en charge est extrèmement faible, pour ne pas dire nulle ?

Concernant les liens d'évitement au sein même d'un menu, il y a un site en rapport avec l'accessibilité qui avait appliqué ça "à fond" (je ne le retrouve plus).

Mais ça surcharge très fort les choses. En mode graphique, ça passe encore, mais en oral ça doit être pire qu'autre chose je pense.
a écrit :
Pour les liens d'évitement courant (menu, contenu, recherche), ça devrait théoriquement être le rôle des <link> non ?


Même en admettant que cela passe par les link rel on pourrais très bien essayé comme voulais le faire Eric depuis pas mal de temps, mais pour moi 2 problèmes se posent.

1) Comme tu le dit la prise en charge
2) La connaissance de l'utilisateur de cette fonctionnalité

a écrit :
Mais ça surcharge très fort les choses. En mode graphique, ça passe encore, mais en oral ça doit être pire qu'autre chose je pense.


Ce n'est pas notre objectif dans ce cas précis l'adequation avec le rendu d'une synthèse vocale ou d'un lecteur d'écran.

C'est de savoir si ce système peut permettre une meilleure navigabilité pour des personnes ayant des handicaps moteurs lourds, les accesskey leurs étant complètement inutile et la navigation par tabindex particulièrement difficile contrairement aux non-voyants.

Pourquoi l'accessibilité ne serait elle faites que pour les non-voyant ou mal voyants.

Après justement c'est ce que nous voulons savoir est-ce que cela gène enormément un utlisateur non_voyant ou alors est-ce que cela pourrais éventuellement cohabiter.

Après je ne sais pas mais si cela est vraiment catastrophique pour un rendu oral pourquoi ne pas passer ces liens directs par l'intermèdiaire des link rel si cela est possible.

Par contre après le risque est une surcharge des link rel ce qui pourrais donnez l'effet contraire à celui voulu.

On peux également jouer sur la visibilité du lien avec 2 feuilles de style différentes mais les agents utilisateurs n'intepreterons pas tous de la même façon en fonction de la propriéte utilisée (visibility, display).

Est ce que cela peux apporter un plus à la navigation pour une certaine catégorie de handicap on le suppose mais on ne sait pas.

Est-ce que cela peux détériorer la navigation de façon à être inutilisable par d'autres catègories de handicaps on le suppose mais on ne sait pas.

Est ce que, en ayant une page bien structuré un utilisateur de JAWS par exemple ou HPR n'as pas les moyens de choisir sa navigation(de titre en titre par exemple).

Après un autre problème se pose est ce que les personnes qui utilisent JAWS ou HPR ou WindowEyes connaissent vraiment les fonctionnalités leur permettant de relativement controler leur navigation sur un site relativement bien conçu ce qui permettrait d'introduire et de tester d'autres solutions pour d'autres publics qui jusqu'a maintenant ne sont pas suffisemment pris en compte dans les divers mécanismes recommandés.
Modifié par knarf (02 Jul 2005 - 05:50)
Philippe a écrit :
visiblement, l'histoire de Jean Philippe, que je suis sur la liste de diffusion de accessiweb, nous renvoi au probleme suivant:
- Mettre le contenu en premier ou le menu. En ces termes, je veux bien sur parler de la lecture qui se fera avec un lecteur d'ecran.


Utilisant personnellement un lecteur d'écran :
- la présence du contenu en premier est effectivement plus confortable, quand il s'agit vraiment du contenu: titre de site, blabla de sous-titre répétés de pages en pages, etc. sont aussi agaçant qu'un long menu, même s'il sont plus courts.
- mais cela n'a aucune importance si la structure des pages est constante et me permet d'accéder au contenu via la navigation par les titres (ma préférée), la navigation de tableau en tableau (très agréable aussi s'il n'y a aucune imbrication), ou encore, effectivement, via un lien d'accès direct en tête de page.

La question est en effet, je crois, beaucoup moins tranchée que cela:
- une structure de titres parfaitement hiérarchisée selon une logique constante à travers tout le site permet d'explorer chaque page très rapidement
- une structure de tableaux successifs, ou un tableau unique, sans tableaux imbriqués et avec une linéarisation intelligible permet, moins facilement, la même exploration
- le menu d'accessibilité avec liens d'accès direct au contenu / menu est utile, en effet, mais ne suffit pas une fois qu'on se trouve dans le contenu ou le menu, si ceux-ci ont une structure où il est difficile de s'orienter et de se déplacer. En fait, j'apprécie surtout d'y trouver le lien vers le plan du site et le formulaire de cherche (ou le lien vers la page correspondante)

Donc, ni les liens d'accès direct en tête de page, ni la présence du contenu en tête de page ne sont une réponse unique ni suffisante. D'autant qu'ils posent des problèmes qui ont été bien expliqués ici par jpv en matière de focus.

Enfin, pour la clarté de la réflexion, et parce qu'ils ne jouent pas du tout le même rôle en pratique ni pour l'utilisateur, ni pour l'auteur, il faut distinguer :
- liens d'accès direct (aller au contenu, aller au menu) placés en tête de <body>
- liens d'évitement de liste de liens, placés dans le corps de la page, avant la liste, voire aussi par certains après celle-ci (lien de retour)

Pour ma part, les liens d'évitements sont utiles lorsqu'il y en a un minimum (et pas de lien retour) : chaque site ayant sa structure de page propre, les systèmes de liens d'évitement qui se veulent très complet nécessitent que je prenne le temps de saisir leur fonctionnement spécifique... ce que, franchement, je n'ai ni le temps ni l'envie de faire quand je parviens à une navigation beaucoup plus rapide et aisée par les autres moyens ci-dessus Smiley cligne D'autre part, ils entrent souvent en conflit avec la tabulation.

Finalement, ce qui me facilite le plus les choses, c'est:
- une structure de page constante sur tout le site
- un emploi rigoureux et systématique du titrage (les <dt> de listes de définitions remplaçant des titres me privent de cette facilité de navigation)
- l'absence de sguigui élaboré, supposé me faciliter la vie.
knarf a écrit :
Après un autre problème se pose est ce que les personnes qui utilisent JAWS ou HPR ou WindowEyes connaissent vraiment les fonctionnalités leur permettant de relativement controler leur navigation sur un site relativement bien conçu ce qui permettrait d'introduire et de tester d'autres solutions pour d'autres publics qui jusqu'a maintenant ne sont pas suffisemment pris en compte dans les divers mécanismes recommandés.


C'est en fait par là qu'il faut commencer : rendre le site accessible dans la configuration par défaut de Jaws et IBM HPR, en sachant que peu d'utilisateurs de lecteurs d'écran modifient leurs options (aide à peu près inintelligible, concepts complexes, etc.)

Un site "bien conçu" pour l'accessibilité, mais nécessitant que l'utilisateur ait un doctorat es config de Jaws ou une connaissance approfondie de l'aspect technique (notion de title, par exemple) est très beau, très satisfaisant pour son auteur, et totalement imbuvable pour le public visé Smiley cligne

Règle 1: faire simple, avec des mécanismes immédiatement compréhensibles par l'action, basés sur le tout-venant des fonctions par défaut.
Je suis heureux que le sujet que j'ai lancé via le truchement de Dominique ait suscité autant de réactions de votre part. Cela change des innombrables mails restés sans réponses que j'ai pu adresser à certains webmasters...

Sur le fond du problème, je partage tout-à-fait l'avis de Laurent, relativement à la méconnaissance par les déficients visuels de l'ensembles des possibilités de navigations offertes par leurs logiciels de revue d'écran. Je ne prétends d'ailleurs pas les connaître toutes. Il faut bien se rappeler en effet que, pour un non voyant, l'apprentissage de l'informatique en général, se double de celui de logiciels re revue d'écran, censés remplacer l'oeil de la personne voyante, laquelle en a une utilisation innée. On ne peut donc pas demander à une personne non voyante d'être a priori plus douée en informatique que la moyenne des utilisateurs pour utiliser internet.

Quant au choix entre la mise du contenu de la page courante en haut ou la présence d'un lien "aller directement au contenu", un webmaster m'avait indiqué que la première option pouvait nuire à la charte graphique du site considéré, et qu'à tout prendre, il vallait mieux choisir le lien d'évitement. Je veux bien être d'accord avec ça, mais alors de grâce, évitez les liens d'évitement trop nombreux : l'utilisation d'internet doit être autant que possible intuitive. Certains confondent souvent, et comment leur en tenir rigueur, l'accessible et le "trop accessible"... Mais bon, je me permets de tenir de tels propos car à lire vos message, j'ai le sentiment d'être en face de webmasters scrupuleux et perfectionistes. Dans la plupart des cas, il vaudra mieux solliciter certains webmasters pour qu'ils rendent leurs sites un minimum accessibles (éviter autant que possible les pages flash, commenter les liens graphiques, etc), que de leur faire peur avec des exigences normatives trop strictes.

Bien cordialement,

Jean-Philippe
En voilà un débat qui avance Smiley smile

Donc pour résumer :

- liens d'accès direct en tête du body (aller au contenu, menu , recherche)
- le contenu en premier n'est pas une obligation mais c'est mieux
- pas ou très peu de liens d'évitement dans le menu
- structure de titre
- balise correct
Ah, en y réfléchissant bien,je ne crois pas que ce soit juste une question de préférence personnelle, donc, j'ajouterai dans le "menu d'accessibilité", avec les liens d'accès au contenu, au menu, et à la recherche, le lien vers le plan de site.

En effet, un plan de site linéaire (titres <hn> et listes <ul> sera toujours plus accessiblé, même si c'est fastidieux, qu'un menu complexe, surtout à coulisse. Il peut donc être une excellente entrée dans un site.
lafo a écrit :
On ne peut donc pas demander à une personne non voyante d'être a priori plus douée en informatique que la moyenne des utilisateurs pour utiliser internet.


En ce qui concerne JAWS apperement il as une formation intégré.

Est ce que celle ci est également présente avec une version d'evaluation?

Est-ce que celle-ci est suffisement explicite et compréhensible pour un utilisateur novice.

Même un valide utilise des tutoriels pour se servir de l'outil informatique en existe t il beaucoup sur l'accessibilité et les logiciels ou matériel permettant cette accessibilité.

EDIT:
Donc concretement pour vous, lafo et Laurent-Denis le système de liens mis en place sur Web-pour-tous aurais plutôt tendance a vous rendre la compréhension du site plus difficile.

Testez le site et venez nous donner votre à avis sur le forum il interressera surement du monde, nous les premiers.


lafo a écrit :
Certains confondent souvent, et comment leur en tenir rigueur, l'accessible et le "trop accessible"


D'accord mais on fait quoi, on dit d'un site qu'il est accessible car il réponds aux besoins et aux recommandations pour un type de handicap, le visuel, en l'occurence, sans s'occuper des autres?

Est ce que vouloir travailler l'accessibilité d'un site pour un autre type de handicap c'est le rendre "trop accessible" ou justement commencer à le rendre accessible à un autre public que les non-voyants?
Modifié par knarf (02 Jul 2005 - 16:43)
knarf a écrit :
EDIT:
Donc concretement pour vous, lafo et Laurent-Denis le système de liens mis en place sur Web-pour-tous aurais plutôt tendance a vous rendre la compréhension du site plus difficile.


Cheminement à l'écoute pour accéder aux menus :
- Aller au menu -> simple et intuitif, j'y vais !
- Le projet -> il y a donc une page qui s'appelle "le projet". J'ai compris, j'y vais.
- Vers menu suivant (Vous avez la parole) -> ??? 1. Je suis toujours sur la même page. 2. Où est le contenu visé par le lien que je viens de suivre ? Comment suis-je supposé faire pour accéder à ce "projet" ? Ah... c'est le lien suivant, donc le libellé ne fait en rien référence au mot projet... Combien de personnes peuvent le deviner, à votre avis ?

C'est confusant, en effet. Il y aurait au lmoins un travail de fond à faire sur les intitulés de ces liens.

J'avoue que je suis sceptique sur l'utilité de ces liens d'évitement dans un menu aussi bref.
Modifié par Laurent Denis (02 Jul 2005 - 18:27)
Est ce qu'un handicapé moteur aura la même expertise que toi sur l'utilité de tels liens?

Aprés qu'un travail soit fait pour une meilleur compréhension d'accord.

par exemple sur le title de "aller au menu"

title="liste d'acces direct au differents menus fixes du site"

Et pourquoi ne pas l'expliquer clairement dans la page d'accessibilité à ce moment là.

Est ce que si nous arrivons à un consensus en ce qui concerne l'intitulé des liens ou l'explication du système et qu'une tel navigation peu s'avérer être utile pour un autre type de handicap, les non voyants ou mal voyant sont ils prêt à cette petite concession pour permettre à d'autre une meilleur accessibilité.

Pourquoi vous, non voyants et mal voyants ne travailleriez vous pas à améliorer la navigation pour un autre type de handicap en prenant comme base vos propres attentes.

La, manifestement cette navigation peu vous poser problème donc voir ensemble ce qui peut être fait pour garder la même idée mais réalisé d'une autre façon.
Modifié par knarf (02 Jul 2005 - 20:03)
Un handicapé moteur qui navigue comment ?

parce que en mode graphique, s'il sait cliquer sur un des liens, il sait naviguer complètement non ?
Prenons concretement la disposition de web-pour-tous dans le cas d'une personne utilisant uniquement la navigation par tabindex.

L'ordre de tabulation est celui-ci:

Barre d'accessibilité-->Recherche-->Contenu (sachant qu'un lien "aller au contenu" et prenant le focus exsite)-->Menus (idem)-->Footer.

Sans utiliser les différents liens directs et en ne les comptants pas dans le nombre d'action sur la touche tab en combien de fois peut on acceder au premier lien de la rubrique ressources en arrivant directement sur la page index.

le fait d'utiliser les liens fait gagner 5 tabulations et il n y as que 4 menus avec très peu de lien dans chaque.

Chaque lien supplémentaire dans un menu est une action supplémentaire sur le tabindex donc cela peux vite devenir un chiffre relativement important en fonction du nombre de menu et le nombre de liens les constituant.

Si des handicapés moteurs viennent nous dire abandonnez les gars cela ne sert strictement à rien de faire cela pour nous ok! on auras notre réponse et on pourras evetuellement travailler sur autres choses avec eux mais temps que nous aurons des réponses à ce sujet de valides ou de personnes non concernées par ce handicap , nous continuerons dans cette voie.

Par contre si la réponse est positive on peux à ce moment là se tourner vers les non voyants et mal voyants pour essayer de trouver un terrain d'entente ensemble et essayé de contenter un maximum de monde.


a écrit :
parce que en mode graphique, s'il sait cliquer sur un des liens, il sait naviguer complètement non ?


Oui peut être que cela ne lui sert à rien à lui de nous le dire mais toi peu tu nous apporter une réponse concrète de part ton vécu?
Modifié par knarf (02 Jul 2005 - 20:53)
Bonjour à tous,

Ce topic est très instructif ...

Juste une petite question :

Pour permettre la navigation de titre en titre, que faut-il rajouter de particulier, à part, bien sûr, les balises hn ?

Aller, encore une petite :

Quelle est cette histoire de focus qui revient souvent dans vos débats ?


Pour acceder directement au contenu à l'intérieur d'un site, ne suffit-il pas de rajouter une ancre à tous les liens internes, au fond !

Car, finalement, si on essaie d'imaginer, les utilisateurs non-voyants ont systématiquement une manipulation de plus à faire pour accéder à l'informaton qu'il cherche : en gros, un clic = 2 clics !
(Dans le cas où les liens d'évitements sont présents)

Smiley sweatdrop
Bonjour,

Comme l'explique très bien Laurent et lafo, la multiplication des aides à la navigation peut nuire, et la règle 1 de laurent est précieuse de clarté... Smiley smile

Je suis un fervent partisan des aides à la navigation clavier tant les réponses du WCAG pour la navigation clavier me semblent inadaptées.

En revanche il faut absolument prendre en compte les intérêts contradictoires entre les utilisateurs de lecteurs d'écrans et ceux qui naviguent au clavier.

Cela concerne deux problèmes : l'organisation de la tabulation qui peut générer un conflit entre la structure du plan graphique et la hiérarchie du flux et, justement, les aides à la navigation.

La question des liens d'évitement du menu de web-pour-tous est, à ce sujet, très intéressante.

Si on regarde en détail leur implémentation on s'aperçoit qu'il n'y en à qu'un qui soit vraiment utile: c'est celui qui permet d'éviter les 5 items du sous-menu des rubriques. Dans tous les autres cas il s'agit d'éviter deux ou trois items et le bénéfice, même si il existe n'est à mon sens pas suffisant pour justifier la gêne occasionné pour les non-voyants.

Par ailleurs on pourrait même discuter de leur pertinence par rapport au menu lui-même.
Le menu comporte 14 items, qui demandent 8 autres liens pour permettre leur utilisation "confortable" pour la navigation clavier.
Cela nous fait un lien "d'aide" pour deux liens de menu, cela me semble beaucoup et j'aurais une très nette tendance à revoir le menu lui-même plutôt que de le suréquiper de lien qui au final occupe la moitié de la liste.

On peut par exemple se poser la question de l'utilité réelle des liens "équipe éditoriale" et "forum" dans ce menu puisqu'ils sont doublés par les liens d'en-tête "forum" et "contacter l'équipe" (avec une violation de l'item WCAG 13.1 puisque équipe éditoriale et contacter l'équipe pointent vers la même page avec des intitulés différents).
On gagnerait donc simplement à les supprimer du menu, d'autant qu'on ne voit pas vraiment le rapport avec la notion de "projet".

Au final, débarassé de ces deux liens et des aides à la navigation le menu ne contiendrait plus que 12 items, ce qui ne pose à priori pas de soucis pour les parcourir en tabulant.
Resterait la possibilité de conserver les liens d'accès rapide en tête de ce menu qui peuvent être pertinents.

En tout état de cause, si il est démontré que la gêne occasionné par ces aides est réelle pour une catégorie d'utilisateurs et vu le peu de bénéfice qu'on en attends, puisqu'ils ne sont réellement utiles que pour éviter "ressource", on est dans le cas ou "le mieux est l'ennemi du bien".


JP
Modifié par jpv (02 Jul 2005 - 22:22)
a écrit :

En tout état de cause, si il est démontré que la gêne occasionné par ces aides est réelle pour une catégorie d'utilisateurs et vu le peu de bénéfice qu'on en attends, puisqu'ils ne sont réellement utiles que pour éviter "ressource", on est dans le cas ou "le mieux est l'ennemi du bien".


Dans ce cas précis le manque de liens des menus et et le nombre réduit de menus fait que effectivement la gène est beaucoup plus importante que le gain.

de plus c'est vrai que equipe editoriale et forum est à double emploie et donc permet un gain en le supprimant.


Plaçons nous maintenant dans une configuration ou les liens sont relativement nombreux d'une rubrique à l'autre.

Ressources handicaps.

Dans ce cas là de tels liens pourraient avoir leur utilités et un gain suffisant par rapport à l'eventuelle gène occasionnée non?

Dans ce cas là tout en sachant que les listes s'etofferons cela fait rajouter 4 liens pour 37 actuellement.


Si l'utilité et la pertinence dans le 2eme cas sont avérés ne pourrais t on pas par l'intermédiaire des personnes concernés savoir à partir de quel nombre de liens ou de menu une tel organisation peut être bénéfique et ou le gain sera supérieur à la gène.
Modifié par knarf (02 Jul 2005 - 23:23)
Pages :
Sujet clos
Aller à