[Résolu] Un site accessible en une ou deux interfaces ?

Bonjour à toutes et tous.

Première question

Dans le cadre d'un site qui ferait à tout casser 10 pages (un simple site de gastro-entérologue avec les pages, consultation, type d'examens, adresse & plan, etc….), trouvez-vous judicieux (ou idiot) de créer un site du type "Classique" c'est à dire en XHTML strict + CSS (fait entièrement en CSS comme ZEN), fatalement avec validation pour l'HXTML, les CSS, y compris l'accessibilité, ...

Proposition 1

... Mais avec un gros bouton bien voyant sur chacune des 10 pages qui renverrait vers une page équivalente sur le fond mais en version texte sans éléments graphiques qui permettrait à un surfeur accablé d’un handicap visuel ou moteur de choisir les couleurs & tailles des éléments textes, voire également de la couleur du fond pour le contraste (via un script en javascript) comme ce site :

Site : http://www.irrp.asso.fr/accessibilite.html

Proposition 2

... Ou bien réaliser une seule interface du site qui permettrait d'agrandir le texte sur chaque pages, mais en conservant les images etc ....... comme le site si dessous (voir le menu "Caractère du texte" situé en haut à gauche) :

Site : http://www.pwd-online.ca/pwdcontent.jsp?&lang=fr&contentid=10&fontsize=0

De mon point de vue la conservation des éléments graphiques ne facilite pas du tout la lecture (bien qu’il y en ait peu dans ce cas-ci, ce qui pourrait ne pas s’avérer le cas dans d’autres sites plus chargés graphiquement), mais c’est un avis personnel.

Ma question sera probablement considérée comme idiote mais je me lance dans l'aventure de l'accessibilité et ..... Ce n’est pas évident !

Seconde question

L'utilisation d'un tel script comme sur cette page ci-dessous pose-t-il un problème dans le cadre de l'accessibilité ?

http://developpeur.journaldunet.com/tutoriel/dht/060605-js-choisir-taille-texte.shtml

Je vous remercie d'avance pour les éventuelles réponses.

Passez une bonne journée.
Modifié par Cinecriture (17 Dec 2006 - 18:38)

Bonjour,

a écrit :
Dans le cadre d'un site qui ferait à tout casser 10 pages (un simple site de gastro-entérologue avec les pages, consultation, type d'examens, adresse & plan, etc….), trouvez-vous judicieux (ou idiot) de créer un site du type "Classique" c'est à dire en XHTML strict + CSS (fait entièrement en CSS comme ZEN), fatalement avec validation pour l'HXTML, les CSS, y compris l'accessibilité, ...

Quelle différence entre un site classique et pas classique?

En fait je ne comprends pas trop la question, en fonction du type de site, il peut être idiot de vouloir le faire en respectant les standards c'est ça?

Je ne ne vois rien d'idiot à vouloir créer un site ou les standards et l'accessibilité sont pris en compte bien au contraire quelquesoit le site d'ailleurs (tout au moins respectant les standards, l'accessibilité cela peut éventuellement se discuter en fonction du public visé et la nécéssité ou pas de s'investir ou d'investir).

a écrit :
Mais avec un gros bouton bien voyant sur chacune des 10 pages qui renverrait vers une page équivalente sur le fond mais en version texte sans éléments graphiques qui permettrait à un surfeur accablé d’un handicap visuel ou moteur de choisir les couleurs & tailles des éléments textes, voire également de la couleur du fond pour le contraste (via un script en javascript) comme ce site :

Site : http://www.irrp.asso.fr/accessibilite.html

Créer 2 sites distincts non je ne suis pas sur que ce soit une bonne idée(double maintenance, oublis éventuels de MAJ...)

Un internaute différent = une version différente

Ca vas finir par faire beaucoup de versions alors

Par contre mettre en place des feuilles de styles alternatives (taille de texte différentes, contraste différent) pour le même site oui mais via un style switcher en php ce qui permet d'être sur que si javascript est désactivé, cela fonctionne.

pourquoi-certains-nactivent-pas-javascript

Voir par exemple le site d'Openweb pour le switcher

a écrit :
De mon point de vue la conservation des éléments graphiques ne facilite pas du tout la lecture (bien qu’il y en ait peu dans ce cas-ci, ce qui pourrait ne pas s’avérer le cas dans d’autres sites plus chargés graphiquement), mais c’est un avis personnel.

Dans le cas d'une navigation à l'aide d'un lecteur d'écran et d'une synthèse vocale les éléments graphiques ne véhiculant aucune information ne sont pas lues car en principe l'attribut alt est volontairement laissé vide, par contre si c'est le contraire, que l'image véhicule une information là l'attribut alt est nécéssaire et se doit d'être le plus pertinent possible, donc éviter les alt="monimage35.jpg" qui n'apporte rien, à part eventuellement déranger les personnes dont la synthèse vocale lira "monimage35.jpg" avec l'accent de JAWS c'est particulier.

<img src="mon_image.jpg"  alt="" />

a écrit :
L'utilisation d'un tel script comme sur cette page ci-dessous pose-t-il un problème dans le cadre de l'accessibilité ?

http://developpeur.journaldunet.com/tutoriel/dht/060605-js-choisir-taille-texte.shtml

Tous ce qui est à base de javascript est susceptible d'être inutilisable (en cas de désactivation) si aucune solution alternative n'est prévue.

Après viens la question de savoir si c'est utile de doubler une fonctionnalité du navigateur ou pas.

Un internaute confirmé n'en aura normalement pas besoin puisqu'il connaitra la manip via le navigateur, mais voilà, il n'existe pas que des internautes confirmés.

Donc à ce moment là oui pourquoi pas pour guider l'utilisateur novice si cela est utilisé avec un lien texte explicite.

Il est également possible d'utiliser une ou plusieurs icônes plus ou moins explicites, mais à ce moment là attention à plusieurs choses.

Voir le
récent billet de Jean-Pierre sur blog d'alsacréationS et en particulier la section 6.


Volà ce que je peux dire, mais faut quand même attendre les pros du truc qui me corrigerons au cas où parce que l'accessibilié c'est pas si facile que ça


Cordialement Knarf

a écrit :
Cela nous permet de viser uniquement certains textes, et donc de ne pas voir par exemple un menu mis en page avec CSS s'effondrer par un changement inopportun de taille de police. (JDN, lien donné par Cinecriture)

Voilà typiquement le genre de conseil à éviter : si un utilisateur agrandit les tailles c'est probablement qu'il en a besoin pour lire les textes, alors si le menu ne s'agrandit pas à quoi sert-il ? On ne devrait pas considérer l'agrandissement comme "inopportun" mais comme répondant à un besoin parfaitement légitime. Donc la réponse à la question 2 est oui, ça pose un gros problème.

en ce qui concerne le script je n'en vois pas l'utilité, tous les navgateurs(graphique) sont équipés d'un outil d'agrandisseur de texte. A toi de laissé faire en sorte de ne pas restreindre cet outil en mettant des % et des em au lieu de px

knarf a écrit :
Quelle différence entre un site classique et pas classique?En fait je ne comprends pas trop la question, en fonction du type de site, il peut être idiot de vouloir le faire en respectant les standards c'est ça?Je ne vois rien d'idiot à vouloir créer un site ou les standards et l'accessibilité sont pris en compte bien au contraire quelque soit le site d'ailleurs (tout au moins respectant les standards, l'accessibilité cela peut éventuellement se discuter en fonction du public visé et la nécessité ou pas de s'investir ou d'investir).

Je me suis mal exprimé avec le mot "Idiot". Il concernait mes deux propositions, site en une ou deux interface avec script (CSS ou Javascript) permettant le réglage de la taillle et la couleur du texte. Et certainement pas pour le respect des standarts.

knarf a écrit :
Créer 2 sites distincts non je ne suis pas sur que ce soit une bonne idée (double maintenance, oublis éventuels de MAJ...)

C'est pour cela que je dis que c'est un tout petit site de maximum 10 pages avec quasi aucune mise à jour sinon les congés, il s'agit d'un site de médecin et mise à part les congés, le contenu ne change pratiquement pas. En fait on peut carrément penser à un site en statique qui ne bougera qu'une ou deux fois par ans.

knarf a écrit :
Par contre mettre en place des feuilles de styles alternatives (taille de texte différentes, contraste différent) pour le même site oui mais via un style switcher en php ce qui permet d'être sur que si javascript est désactivé, cela fonctionne.

Bien voilà c'est là mon problème, je ne travaille malheureusement qu'en statique (je ne connais aucun language dynamique), une telle chose est-elle possible en statique ?

knarf a écrit :
Dans le cas d'une navigation à l'aide d'un lecteur d'écran et d'une synthèse vocale les éléments graphiques ne véhiculant aucune information ne sont pas lues car en principe l'attribut alt est volontairement laissé vide, par contre si c'est le contraire, que l'image véhicule une information là l'attribut alt est nécessaire et se doit d'être le plus pertinent possible, donc éviter les alt="monimage35.jpg" qui n'apporte rien, à part éventuellement déranger les personnes dont la synthèse vocale lira "monimage35.jpg" avec l'accent de JAWS c'est particulier.

Ce que je veux dire c'est que si la personne n'a pas accès à la synthèse vocale et qu'elle est obligée d'utiliser l'agrandissement des textes via une manip de son clavier comme pour exemple

Avec Firefox :

CTRL et + pour augmenter la taille ;
CTRL et - pour la diminuer;
CTRL et 0 pour revenir à la taille initiale.

Avec Explorer :

CTRL + Roulette de la souris

N'est-il pas préférable d'avoir accès à cette manip dans la page Web carrément via plusieurs propositions de boutons d'agrandissements ? Et lorsque l'on se trouve dans ce cas de figure n'est-il pas préférable que la page ne contienne pas d'éléments graphiques, d'ou la proposition de doubler chaque page avec une alternative uniquement texte ?

knarf a écrit :
Tous ce qui est à base de javascript est susceptible d'être inutilisable (en cas de désactivation) si aucune solution alternative n'est prévue.

Là c'est clair alors je n'utilise pas de javascript.

knarf a écrit :
Après viens la question de savoir si c'est utile de doubler une fonctionnalité du navigateur ou pas.Un internaute confirmé n'en aura normalement pas besoin puisqu'il connaitra la manip via le navigateur, mais voilà, il n'existe pas que des internautes confirmés.

Ben voilà c'est là le noeud du problème.

Car en fait j'essaie de me poser dans plusieurs cas de figures AVEC plusieurs types d'accès au Web. Ayant déjà travaillé avec des tétraplégiques (C.H.U. ERASME à Bruxelles), handicapés moteurs sévères (Institution Les Godets Belgique) et aveugles (C.H.U. ERASME à Bruxelles), je me demande s'il est possible de satisfaire tous ces handicaps via un site doté d'une, de deux, voire plus d'interfaces dans le cadre, encore une fois je me répète, d'un tout petit site de maximum 10 pages en statique (pas de language dynamique).

Handicapé moteur sévère

Navigation par TrackBall avec le menton, en général ils peuvent bouger la tête.

Tétraplégique

Navigation par TrackBall avec le menton quand c'est possible, c'est à dire que la rupture des vertèbres cervicales est telle qu'il peut encore bouger la tête.

Pour ce cas de figure, je construisis un casque style casque audio possédant plusieurs interrupteurs que la personne activait avec le gonflement des joues, ouverture de la bouche, déplacement latéral ou en biais de la machoire inférieure etc .... Chacune de ces actions avait une fonction comme le clic droit, gauche, enter etc .........

Aveugle & mal-voyant

Reconnaissance & synthèse vocale (Jaws, Elan Tempo, ....)

Conclusion

En fait j'essaie de trouver le compromis idéal pour que toute personne, quelque soit son handicap ait accès au Web.

Donc je dois penser en terme de manip de clavier (accesskey, ...), synthèse vocale, codage tel que Jaws puisse fonctionner, Lynx etc ...... mais surtout je dois penser que certains auront la synthèse vocale et d'autres pas, certains auront la capacité d'utiliser leur clavier d'autres pas, ...

En fait pour résumer, je voudrais profiter du fait que le site (un simple site de présentation) que je dois faire pour un gastro-entérologue, sera très petit pour justement maitriser toutes les techniques d'accessibilité dans un cadre pas trop fastideux au départ.

Bref pas évident de mettre cela en oeuvre
Modifié par Cinecriture (15 Dec 2006 - 20:13)

Arsene a écrit :
Voilà typiquement le genre de conseil à éviter : si un utilisateur agrandit les tailles c'est probablement qu'il en a besoin pour lire les textes, alors si le menu ne s'agrandit pas à quoi sert-il ? On ne devrait pas considérer l'agrandissement comme "inopportun" mais comme répondant à un besoin parfaitement légitime. Donc la réponse à la question 2 est oui, ça pose un gros problème.

Effectivement ca n'a aucun sens de pouvoir agrandir le contenu et pas les menus

masseuro a écrit :
en ce qui concerne le script je n'en vois pas l'utilité, tous les navgateurs(graphique) sont équipés d'un outil d'agrandisseur de texte. A toi de laissé faire en sorte de ne pas restreindre cet outil en mettant des % et des em au lieu de px

Ca par contre j'ai retenu la leçon

Merci infiniment pour vos réponses.

J'avais écrit une longue tartine pour te répondre mais finalement je te dirais en résumé :

Si vraiment tu n'as pas envie de te prendre la tête, installe dotclear 1.2x avec le plugin thème switcheur, le plugin page connexe et tu auras un site super accessible en un temps record. A toi de modifier les thèmes pour la mise en page...
Modifié par Patidou (15 Dec 2006 - 16:13)

Patidou a écrit :
J'avais écrit une longue tartine pour te répondre mais finalement je te dirais en résumé :Si vraiment tu n'as pas envie de te prendre la tête, installe dotclear 1.2x avec le plugin thème switcheur, le plugin page connexe et tu auras un site super accessible en un temps record. A toi de modifier les thèmes pour la mise en page...

Houlà !

Je ne connais absolument pas ce concept !

Merci Patidou

Bonjour,

@Patidou : Faut pas raconter n'importe quoi...

a écrit :

Patidou a écrit :
J'avais écrit une longue tartine pour te répondre mais finalement je te dirais en résumé :Si vraiment tu n'as pas envie de te prendre la tête, installe dotclear 1.2x avec le plugin thème switcheur, le plugin page connexe et tu auras un site super accessible en un temps record. A toi de modifier les thèmes pour la mise en page...

Dotclear est un bon produit, de là à dire qu'il permet d'avoir un site "super accessible" en un "temps record" ça fait un peut "Vous n'y connaissez rien, nous non plus".

Diffusez ce genre d'idée c'est une connerie, exactement comme si on disait : Achetez la voiture untel et vous conduirez bien...

Les auteurs de CMS font de gros efforts pour rendre leur produit meilleurs, dotclear en fait partie, ce n'est pas le seul.

Mais c'est à l'auteur de rendre son site accessible, il n'y à que lui qui peut le faire, et si il n'à pas envie de se prendre la tête, c'est pas grave, qu'il fasse autre chose...

Ceci dit étant très ouvert d'esprit, aurais-tu une url pour nous montrer un "site super accessible en un temps record sans se prendre la tête".

Je serais très curieux d'y jeter un coup d'oeil...

@cinecriture : Je reviendrais plus tard dans la soirée apporter quelques réponses aux questions que tu posent...

Jean-Pierre

jpv a écrit :
@cinecriture : Je reviendrais plus tard dans la soirée apporter quelques réponses aux questions que tu posent...Jean-Pierre

Justement JE VEUX maitriser l'accessibilité via un travail personnel dans le code, c'est là ou cela devient intéressant & passionnant.

Après avoir tenté de donner un accès au Web électroniquement dans un hopital pour des tétraplégiques, fatalement je voudrais tenter la même chose sur le Web pour tous ces handicaps.

Je ne suis pas un maître dans la conception de sites mais j’ai de bonnes connaissances de base pour m’y attaquer.

J’ai fait beaucoup de sites en HTML, XHTML (strict & transitionnel) avec CSS externe mais jamais dans un contexte d’accessibilité.

Voici trois de mes réalisations qui sont encore online pour te donner une idée de ce que je maitrise actuellement niveau Web (mais en statique), il y en eu d’autres mais elles n’existent plus.

http://www.ccec.be (bourré de tableaux, atroce et pas valide niveau W3C)
http://www.jfp.be (trop graphique, très très lent et pas valide niveau W3C)

Merci JLP

Punaise Webonorme c'est comme Alsacréations une vraie mine d'or

En fait mon problème est simple. Pour utiliser une phrase de Webonorme :

"Le premier problème à résoudre c'est : par où commencer ?"
Modifié par Cinecriture (24 May 2007 - 22:29)

jpv a écrit :
Bonjour,

@Patidou : Faut pas raconter n'importe quoi...
(…)

J'avoue dans mon enthousiasme et ma précipitation (j'allais raté mon train) avoir poussé un peu le bouchon un peu loin. En fait, je me rappelais un test de Frank Paul qui disait que de base dotclear avait un bon niveau d'accessibilité. Il est certain qu'il y a encore des choses à améliorer ou revoir en modifiant les fichiers templates. Toutes mes excuses.

D'un autre côté je pensais aussi à dotclear d'un point de vue technique pour la facilité de publication, etc…

Patidou a écrit :
J'avoue dans mon enthousiasme et ma précipitation (j'allais raté mon train) avoir poussé un peu le bouchon un peu loin. En fait, je me rappelais un test de Frank Paul qui disait que de base dotclear avait un bon niveau d'accessibilité. Il est certain qu'il y a encore des choses à améliorer ou revoir en modifiant les fichiers templates. Toutes mes excuses. D'un autre côté je pensais aussi à dotclear d'un point de vue technique pour la facilité de publication, etc…

Merci pour le lien vers le test de Frank Paul Patidou

Bonsoir,

a écrit :
Punaise Webonorme c'est comme Alsacréations une vraie mine d'or

Merci infiniment...

a écrit :
"Le premier problème à résoudre c'est : par où commencer ?"

Comme tu le fais... par le début : se renseigner

Plus sérieusement, je ne peut te donner, dans le cadre d'un post de ce genre que des pistes et des généralités.

La première des choses c'est comprendre une idée simple à exprimer, simple à comprendre et difficile à appliquer.

Laurent Denis avait parfaitement résumé cette idée en disant "L'accessibilité Web n'est pas une somme de réponses spécifiques à des handicaps".

Le but n'est pas de rendre le web "accessible aux handicapés" mais de rendre du contenu accessible ce qui est assez différent.

C'est la raison pour laquelle WCAG veut dire "Web Content Accessibility Guidelines" en français "Directives pour l'accessibilité aux contenus Web" ce qui n'est pas "Directives pour l'accessibilité du web aux handicapés".

Donc la première des choses c'est de se focaliser sur le contenu en s'appuyant de manière scrupuleuse et sans concession sur les spécifications des langages, notamment de Html et de CSS.

Sans cette matière première de "qualité" il y à du bricolage et du rafistolage, mais pas d'accessibilité.

La seconde étape c'est de ne pas se dire "qu'est ce que je fais pour untel ou untel" mais "Qu'attends t'on de moi ?".

On ne demande pas à un auteur d'être un spécialiste du handicap et des aides techniques, on lui demande un truc tout simple : comprendre et appliquer les recommandations WCAG, où les méthodes d'application qui en découlent.

Nous avons la chance d'avoir en france une méthode parmis les plus abouties (Accessiweb) mais tu peux en utiliser d'autres, peut importe, ce qui est fondamental c'est que l'accessibilité parle la même langue, et cette langue c'est WCAG et rien d'autre.

Si nous parlons tous la même langue, si les contenus que nous présentons sont toujours adapté de la même manière alors les éditeurs de solutions et d'aides techniques peuvent produirent des outils efficaces.

Prenons par exemple le sujet initial de ton post : le problème épineux de l'augmentation de la taille des caractères.

C'est une erreur de vouloir le résoudre par un "mécanisme", ce n'est pas ce qui est demandé, on demande un truc tout simple : utiliser des tailles de police relatives et laisser chaque outil, chaque aide et chaque utilisateur décider de la meilleure manière d'utiliser cette possibilité.

On va te demander également de faire au mieux pour leur faciliter la tâche, par exemple de t'assurer que l'augmentation des tailles de police ne provoquent pas de superposition.

C'est un problème souvent difficile, ça demande du temps et de l'énergie, notamment sur la maitrise de CSS et tu gagneras beaucoup à de pas perdre ce temps précieux à rechercher des mécanismes qui, au fond, sont souvent plus proches des gadgets que d'une réponse crédible.

Autre exemple, tu dis :

a écrit :
Proposition 1

... Mais avec un gros bouton bien voyant sur chacune des 10 pages qui renverrait vers une page équivalente sur le fond mais en version texte sans éléments graphiques...

...

De mon point de vue la conservation des éléments graphiques ne facilite pas du tout la lecture

C'est très bien, parce que tu te réponds tout seul : " de mon point de vue", ce qui n'est pas le point de vue du voisin donc...

Et c'est très bien aussi parce que personne, et surtout pas WCAG, ne demande de supprimer tel ou tel partie du contenu.

Ce n'est pas notre job, c'est celui des aides et c'est la décision de l'utilisateur.

Et si ton contenu est de qualité, donc en utilisant CSS pour la mise en forme, il n'aura besoin de personne, pas de site alternatif, pas de systèmes javascriptés, pas même de style switcher.

Les images le gêne, il peut les supprimer, les couleurs le pertubent, il peut les changer, la mise en page est trop difficile à lire, il peut l'adapter.

On te diras sans doute "oui c'est bien beau mais combien d'utilisateur le font réellement ?"

La réponse est simple : avec 1% de sites qui le permettent, personne, avec 10% un peut plus, avec 100%, tout le monde.

Donc par où commencer ?

Apprendre XHtml et CSS.

Lire WCAG, relire WCAG, re relire WCAG et les excellentes méthodes qui en découlent.

Appliquer les recommandations, celles qu'on peut, ne pas improviser, y aller doucement à son rythme.

Ne jamais hésiter à questionner, même si ça te parait idiot, en la matière il n'y à pas de questions idiotes et il n'y à pas de réponses simples.

Comprendre que, dés lors qu'il y à une exigence de qualité, notamment pour des sites professionnels, seul un expert qualifié peut accompagner un projet et répondre à une exigence de résultats.

Pour le reste tu à des endroits comme Alsacreation, Blog and Blues, Open Web, Pompage , W3Qc et bien d'autres sur lesquels tu trouveras de quoi alimenter les longues soirées d'hiver.

Des documents comme :

W3QC - Sept pas vers l'accessibilité (Normand lamoureux)

W3C - Premiers pas pour rendre un site Web accessible

Peuvent aussi représenter des premières approches intéressantes.

Il y en à d'autres qui ne sont pas difficiles à trouver.

<edit> Et Comme tu est apparemment belge, je ne résiste pas à t'indiquer le blog de Monique , la bonne fée du web du coté de chez vous</edit>

Jean-Pierre
Modifié par jpv (16 Dec 2006 - 01:00)

a écrit :
Patidou a écrit :
Toutes mes excuses.

Tu es tout pardonné...

Jean-Pierre

Merci pour cette belle synthèse jpv

Un tout grand merci Jean-Pierre pour ton intervention

Comme dit Benjamin D.C. une merveilleuse synthèse et des réponses précises à mes questions. Comment faire mieux

Une dernière question, la plus importante pour pour le moment

Avant de m'attaquer à la partie graphique du site il me reste une inconnue, réaliser le site pour quelle résolution ?

Dans la majorité des sites sur la conception d'un site Web, je lis que le standart mondial actuel est la résolution 1024 x 768.

Ma question est donc simple, dans le cadre de l'accessibilité dois-je oui ou non encore tenir compte de la résolution 800 x 600 qui semble pour beaucoup obsolète ?

De plus il semble que la résolution native de Firefox soit le 1024 x 768

Exemple d'argumentation pour/contre sur ce site

Mais bon c'est vrai aussi que c'est un site de marketing donc c'est peut-être pas le bon exemple

En tout cas mille mercis pour vos interventions qui m'ont mis plus que jamais sur la bonne voie.
Modifié par Cinecriture (16 Dec 2006 - 04:33)

Bonjour,

Ca m'à bien fait rire cet article, surtout la fin :

a écrit :
J''applique donc désormais cette devise : "1024 au minimum sauf exception dûement justifiée".
.

Sur un site en 800 centré... Il y en à qui n'ont peur de rien....

a écrit :
je lis que le standart mondial actuel est la résolution 1024 x 768.

Tu à lu ça ou ?, un conseil : ceux qui te disent ça sont au minimum des sots, ou plus probablement répète doctement les même iddées reçues entendeus ailleurs.

Depuis l'invasion des écrans plats et des portables, il n'y à plus de standadrs, il n'y à que des statistiques très diverses d'un site à l'autre.

a écrit :
Ma question est donc simple, dans le cadre de l'accessibilité dois-je oui ou non encore tenir compte de la résolution 800 x 600 qui semble pour beaucoup obsolète ?

Oui tu dois en tenir compte.

Jean-pierre

Cinecriture a écrit :
Ma question est donc simple, dans le cadre de l'accessibilité dois-je oui ou non encore tenir compte de la résolution 800 x 600 qui semble pour beaucoup obsolète ?

Si la question est de faire un site accessible au plus grand nombre, alors oui, bien évidemment.

Les Statistiques :

* 17% d'utilisateurs en 800x600 (25% en 2005)
* 58% en 1024x768 (55% en 2005)
* 19% en résolutions supérieures (14% en 2005)

(source : http://www.w3schools.com/browsers/browsers_stats.asp )