Handy Flying : tentative d'accessibilité

Bonjour à toutes et à tous,

Certes, je suis inscrite au super concours de l'été que je n'espère pas gagner mais qui sera l'occasion de recevoir des avis sur le côté esthétique.

Mais je n'aurais pas la patience d'attendre la fin des votes pour demander vos avis sur le plan "technique" : accessibilité, codage, feuille de style, que manque t-il, cela marche t-il avec votre navigateur préféré, etc.

Mon objectif était de faire un site accessible et qualitatif, avant tout.
Et sur le plan graphique, mon penchant pour l'élastique ne m'a pas facilité les choses : nom d'une pipe, comme c'est difficile !

Sans parler des mystères de php que j'ai élucidé (en partie) de point-virgule en point-virgule pour essayer de faire "comme je voulais", sachant que je n'ai pas réussi , encore, à tout intégrer comme prévu.

Bref, il s'agit d'un site associatif propulsé par Dotclear, mon premier site conforme et dynamique ...

Je compte m'investir dans un cms, mais dans l'instant, il fallait que je "ponde" quelque chose et cette aventure "Dotclearienne" ne pourra que m'aider pour la suite ...

Allez-y, mordez, mais pas trop fort, le temps que je reprenne mon souffle !



Un très très grand merci à Dominique : mon troisième oeil !
Modifié par Vero (18 Sep 2005 - 11:38)

Dans le fil de ce message sur les enjeux des designs standards, un petit aperçu réconfortant :



(Le site vu dans opera.mini pour mobile... en supposant par exemple, que j'ai voulu, lors d'un trajet en voiture, relire l'itinéraire vers l'aérodrome d'Aix-Les-Milles depuis mon mobile)

Malgré le menu en liste <ul> en tête de contenu qui "mange" une partie de la faible hauteur d'affichage disponible, le résultat est tout à fait utilisable et agréable : en effet, bien qu'il n'ait pas de CSS handheld, le site a un contenu sobre et bien structuré qui le favorise son "accessibilité" dans ce media... comme dans d'autres.
Modifié par Laurent Denis (16 Aug 2005 - 11:01)

Aller je me lance

Je suis de plus en plus impressionné par ce cms, je n'y ai jamais encore touché mais ca ne saurait tardé , mais en tout cas chaque site que j'ai vu généré par ce cms est d'une très bonne qualité.

Je n'ai pas grand chose à dire, c'est propre et clair. Il y a un exellent choix de couleur et la manière d'ont tu as inséré la photo dans la page d'accueil pour accompagner le texte est très agréable. Un fondu bien fait, ca nous change des encadrement à bordure et c'est aps plus mal .

Bon ma seul déception, c'est le header sur le quel tu a fais un relief ( bisautage) et qui fait penser au site de nos papys. Je pense qu'un applat ou un très leger dégradé (de haut en bas) fera facilement l'affaire et restera dans l'esthétisme de ton site.

Voila si tout le monde pouvait sortir des sites comme celui-la ,le Web serait le paradis. Bonne continuation a toi.

Laurent Denis a écrit :

Malgré le menu en liste <ul> en tête de contenu qui "mange" une partie de la faible hauteur d'affichage disponible, le résultat est tout à fait utilisable et agréable : en effet, bien qu'il n'ait pas de CSS handheld, le site a un contenu sobre et bien structuré qui le favorise son "accessibilité" dans ce media... comme dans d'autres.

Bon, je suis "content" que cela plaise à opera.miniature que je suis enchantée de connaître, mais :

1/ Et pourquoi mon menu en liste que j'ai pourtant pris soin de faire floater en left ne flotte t-il pas sur opera.miniature ?

2/Je serais ravie de rajouter des handled à ma css ... si je savais ce que c'est !

Vlili30 a écrit :

Bon ma seul déception, c'est le header sur le quel tu a fais un relief ( bisautage) et qui fait penser au site de nos papys. ....

Tiens, je me doutais qu'on allait me la sortir, celle-là !
Je suis un peu mamys sur le bords, faut dire ...
Et l'idée, fort peu réussie je le concède, était d'imiter la carlinque d'un avion ...

Bon, il est peut-être encore temps de remedier à ce "has been effect" ...

Merci à toi pour ce commentaire !

Vero a écrit :
1/ Et pourquoi mon menu en liste que j'ai pourtant pris soin de faire floater en left ne flotte t-il pas sur opera.miniature ?

Parce que le contenu HTML et la CSS sont "retraités" pour être rendu sans accidents sur une machine qui a de très petites capacités de traitement et un écran miniature. Donc, beaucoup de choses sont simplifiées.

Ici, les flottants ne flottent plus car:
- l'écran fait à peine 250px de large, ce qui ne sera pas suffisant dans de nombreux cas pour que des éléments flottants soient rendus de manière lisible.
- le moteur de rendu allégé ne peut pas calculer de positionnement à l'écran, sauf pour le centrage le plus élémentaire ou éventuellement l'alignement à gauche.

Vero a écrit :

2/Je serais ravie de rajouter des handled à ma css ... si je savais ce que c'est !

Oh pardon ! Je suis donc ravi de te présenter les feuilles de styles CSS "handheld", c'est à dire destinées aux petits écrans des mobiles, assistants personnels et autres PDA, par opposition aux CSS "screen" destinées aux grands écrans des PC. Pour en savoir davantage sur ces petites bestioles : Les types de media CSS
Modifié par Laurent Denis (16 Aug 2005 - 11:59)

Merci Laurent pour ces précisons très utiles pour comprendre où on va et pourquoi ...

J'en déduis, que les menus en liste ne vont pas être être forcément très pratiques à aménager dans une feuille de style de ce type.

Parce que pour tout te dire, je n'ai pas fait de liste dans le menu accessibilité car je n'ai pas réussi à caler un ul à droite : je n'y arrive pas. J'ai encore un truc à essayer : fixer une largeur à ul (soit 100%) en priant que les histoires de box model ne s'en mêlent pas trop !

Mais aux lumières de cet exemple, je me fais la réflexion suivante : dans une css, je peux intervenir sur le style de mon menu, mais je vais avoir du mal à intervenir sur sa structure, n'est-ce-pas ! Et une liste occupera toujours pas mal l'écran ...
Modifié par Vero (16 Aug 2005 - 12:39)

En fait, c'est l'ordre dans lequel se présentent le contenu et les menus qui est important.

Sur un écran de PC, dans un navigateur graphique, avec les capacités d'une CSS screen, le fait que le HTML commence par un menu, et non par le contenu "propre" de la page, n'est pas un problème.

Mais pour d'autres medias, il peut être préférable de placer ce contenu "propre" en début de HTML, et de reléguer l'ensemble des menus en fin de HTML.
- A l'exception, bien-sûr, de l'éventuel menu d'accessibilité qui n'a de sens que si la page commence par lui. Et qui a tout intérêt à être structuré avec un <div> ou un <p> plutôt qu'un <ul>...
- A l'exception également des menus de navigation en <ul> très courts.

En effet:
- dans un mobile, avec un très petit écran et des mécanismes de scroll beaucoup moins confortables qu'une souris, on a ainsi accès dès le premier affichage au plus possible de contenu. On ira chercher le menu en bas, si nécessaire (encore une fois, sauf s'il est très court)
- dans un lecteur d'écran ou un navigateur vocal, la lecture de la page atteindra rapidement ce contenu, sans qu'il soit nécessaire d'intervenir.
- selon la légende urbaine, un certain moteur de recherche bien connu serait plus intéressé par ce qui se trouve en début de fichier HTML... Mais sans doute n'est-ce qu'une supposition invérifiable.
- lors de l'affichage dans un navigateur graphique avec une connection bas-débit, si le navigateur sait faire un affichage progressif (Opera), le contenu sera là encore immédiatement consultable avant que la totalité de la page ne soit affichée.

Bien-sûr, cela ne fera pas l'affaire de l'internaute qui veut atteindre rapidement plutôt le menu que le contenu... Disons que c'est la moins pire des solutions, plutôt que la réponse à tous les problèmes.

Dans ton cas, comme on le voit sur l'aperçu donné dans mon message ci-dessus, le fait que ton menu en liste ul soit avant le contenu n'est pas un problème bien gênant : ton menu est court.

L'utilisateur d'un mobile ne va s'attendre à disposer, sur son engin, du même confort que sur son PC : il appréciera qu'on ait fait les choses au mieux, comme tu l'as fait en suivant pour ta structure et pour ta CSS screen de bonnes règles générales de conception, mais il ne réclamera pas le Pérou. Il se résignera à scroller tant bien que mal pour passer un court menu en début de page, ou pour atteindre un long menu en fin de page

<edit>Une autre petite capture, d'un tout autre site, pour donner un contre-exemple. Ce qu'il ne faut pas faire (un interminable menu graphique qui ne respecte aucune règle d'accessibilité):



<edit>Url du site masquée : ne montrons pas du doigt </>
Modifié par Laurent Denis (16 Aug 2005 - 13:16)

Mais de rien

Sinon j'ai fais un test graphiquement pour voir si la bannière avec un léger dégradé pouvait mieux s'intégrer à ton design.

http://www.web-infographiste.be/essai.jpg

http://www.web-infographiste.be/essai.psd

Je ne sais pas si ca peut t'aider mais vu qu'il est fait, autant le partager.

J'ai aussi remarqué que tu a un léger décallage de couleur près de tes arrondis, autant essayé au possible de bien intégrer le header dans le dégradé de l'arrière plan.

Cordialement , Vlili30

le griboullit en edit

Merci Vlili30. Finalement, j'ai simplifié, ce qui m'a permis de réduire la hauteur de l'en-tête ...

Merci Laurent pour ce contre-exemple (url masquée mais logo rajouté ! )

Je suis impardonnable :

Je tiens à remercier toute la communauté du forum, bien sûr, et particulièrement Laurent, Knarf et JPV pour leurs réponses dans les quelques topics que j'ai créé à l'occasion de ma quête vers l'accessibilité.

Leurs réponses claires, intelligibles et appronfondies m'ont beaucoup aidé à comprendre tous les débats en cours sur ces questions.

Il me reste à régler quelques petits défauts d'affichage mineurs sur IE, dans les titres de la colonne de droite. J'ai retrouvé un petit lien (Merci Stephan, pour tes ressources de qualité !) trucs et astuces vues par le w3c ...

En fait, je renonce à ce qui est trop compliqué à faire marcher partout.
Pas de hacks, donc ...pour l'instant.

Et aussi, faire des feuilles de style pour d'autres médias ...

... Et le W.A.P (Wireless Application Protocol ou protocole d'applications aux téléphones sans fil).
... Et le W.M.L. (Wireless Markup Langage), html pour téléphone sans fil ?

Ce protocole et son langage sont-ils toujours d'actualité ?

Puisqu'il s'agit d'un site qui dispose d'une base de données, ne pourrait-on pas imaginer un template dédié au média téléphone ? Cette technologie est-elle mieux prise en compte par les téléphones que la feuille de style dédiée ?

Pour en savoir plus :
http://www.sowap.com/wap-faq.html

Le "WAP forum", qui regroupait les acteurs de cette première étape du Web mobile, et qui a définit et promu autrefois le format WML, est aujourd'hui devenu la "Mobile Alliance". Derrière ce changement de nom, il y a la renonciation à ce format comme outil d'avenir, au profit du XHTML basic tel que défini par le W3C, légèrement enrichi : la spécification XHTML mobile est totalement standard.

Le WML est un format beaucoup trop pauvre pour répondre aux besoins. D'autre part, il nécessite justement que le contenu Web soit spécifiquement reformatté. Le XHTML permet à l'inverse aux mobiles d'exploiter, dans une certaine mesure, le code générique des sites Web.

Le WML est toujours beaucoup pratiqué, surtout à destination des clients mobiles les plus légers (pas d'images, par exemple). Mais les solutions client-serveur comme le récent Opera.mini en Norvège, ou l'équivalent fournit par Danger aux USA, permettent aujourd'hui de tourner la page du WML, même dans cette partie du Web mobile.

Ok !

Merci pour ces précisions Laurent, et en fin c'est plutôt une bonne nouvelle Il ne reste plus qu'à attendre que les fabriquants de téléphones mobiles se mettent aux normes

dominique a écrit :
Il ne reste plus qu'à attendre que les fabriquants de téléphones mobiles se mettent aux normes

Un petit coup d'oeil sur la liste des membre de l'Open Mobile alliance devrait te rassurer sur ce point : http://www.openmobilealliance.org/membership/currentmembers.html

Le Web mobile est assez remarquable, parce que c'est un des rares secteurs du Web où la grande majorité de l'industrie a adopté une démarche appuyée sur les "standards".

Oupssssss ! ben y en a du monde... et du beau (chacun reconnaîtra les siens) hi hi !

En effet, c'est assez rare pour être souligné, mais je ne suis pas inquiet, je suis plutôt assez patient

Merci pour le lien !
Modifié par dominique (19 Aug 2005 - 14:10)

Je n'arrive pas à corriger le défaut d'affichage suivant sous IE :

Les titres de droites (en rouge) ne prennent pas la largeur du conteneur dans lequel ils sont. Pourtant, toutes les marges et les padding sont à 0.

J'ai fait plusieurs tentatives, sans résultats.

Si une âme charitable a une idée ...

Bonjour vero,

Je viens de visiter ton site avec Lynx et comme celui-ci prends en compte la balise <link> on se retrouve avec 21 liens avant la barre d'accessibilité est ce que cela ne risque pas de poser problème.

Comment un handicapé utilisant lynx ou JAWS(car je crois qu'il les prends egalement en compte) gére cela?

Est ce que juste donner un acces aux sections n'est pas suffisant plutot que d'inclure les chapitres pour réduire le nombre, si cela s'avère être génant.

D'ailleurs, comment doit on gérer ces balises <link> quelles sont les plus importantes et les plus pertinentes car leur fonctions sont multiples (summary, glossary, content, rel, rev...)?
Modifié par knarf (29 Aug 2005 - 01:53)

Bonjour,

Vous trouverez des éléments sur ce problème dans deux projets de bonnes pratiques en cours dans l'atelier Opquast (n'hésitez pas à y participer) :
- Un tentative de limiter arbitrairement le nombre de liens relatifs
- Une possibilité de mieux utiliser certains liens relatifs, ce qui en réduit le nombre

Voir également Lien d'auto-découverte de vos fils RSS et navigateurs textes: pensez à des intitulés accessibles
Modifié par Laurent Denis (29 Aug 2005 - 07:49)