jpv a écrit :
Bonjour,
A l'heure actuelle, ma seule source de formation sont des livres et Internet, même si je songe à une formation unversitaire.
Oui, ce que nous essayons de t'expliquer c'est que cela nous parait très largement insuffisant.
a écrit :
Je sais que la loi ne concerne pas les sites privés, et est en tous cas très louche au sesn qu'elle ne précise aucun référenciel sur lequel se baser pour évaluer l'accessibilité d'un site.
Il y aura bien un référentiel dont on devrait avoir bientôt des nouvelles...
a écrit :
Concernant l'éditeur, c'est la raison pour laquelle je viens ici : ne pas me lancer dans une entreprise que je risque de regretter et obtenir tant qu'à faire l'"aval" des spécialistes du domaine.
Je ne sais pas si tu le regretteras, en revanche, je sais que n'importe quel spécialiste sérieux te feras le même genre de réponse...
Pour illustrer mon propos tu trouveras ci-dessous quelques remarques sur le début de ton document.
Je ne pense pas trouver le temps de continuer à le décortiquer, c'est juste pour essayer de te faire ressentir nos (en tout cas ce sont les miennes) interrogations.
a écrit :
Définition. Qu'est-ce que l'accessibilité ?
L'accessibilité, c'est la capacité d'un document à être utilisable et navigable par n'importe qui, en toutes conditions. Ce pourquoi on parle aussi d'utilisabilité (capacité / facilité à être utilisé ou non) ou d'ergonomie (confort d'utilisation).
Accessibilité tout seul ne veux rien dire, on parle plutôt d'accessibilité du web et on devrait surtout parler d'accessibilité des contenus web.
Pourquoi ne pas reprendre la définition officielle qui à l'avantage d'être consacrée et beaucoup plus précise et n'a nul besoin d'être vulgarisée...
C'est une erreur de mélanger accessibilité et ergonomie/utilisabilité.
Certes il y à des points de jonction mais ce sont des choses différentes qui ne poursuivent pas les mêmes objectifs.
On peut même avoir des conflits entre les exigences de l'accessibilité et les objectifs des ergonomes, au hasard : les menus déroulants et les interfaces Ajax.
Je n'ai pas repris la définition officielle car elle est reprise un peu peu partout et je toruve que cela manque cruellement d'originalité de citer toujours la même source, aussi officielle soit-elle. Une formulation un peu différente ne fait pas de mal si elle reste correcte.
jpv a écrit :
Initiatives et documents
Si tu commences à citer des labels ou assimilés pourquoi se contenter d'accessiweb et d'anysurfer (à moins que tu ai voulu restreindre aux francophones).
Quoiqu'il en soit, tu à oublié le plus important : UWEM 1.0 dans lequel sont engagés la plupart des labels européens
Je n'ai pas restreint aux francophones, j'ai simplement oublié UWEM, encre que je ne l'ai connu que par AccessiWeb.
jpv a écrit :
Chaque recommandation se voit attribuer un niveau de priorité en fonction de son impact sur l'accessibilité : les recommandations de priorité 1 sont les plus élémentaires et garantissent un niveau d'accessibilité minimal ; les recommandations de troisième priorité sont celles qui permettent une accessibilité optimale, mais elles sont plus délicates à mettre en éxécution.
Là aussi, je suis très surpris de la réécriture de quelque chose qui est très clair chez WAI :
Priorité 1, niveau A : Ce que l'on doit toujours faire (Qui se définit non pas comme un niveau "minimal" mais comme la condition de l'accès à l'information pour tous les groupes).
Priorité 2, niveau AA : Ce que l'on devrait faire (Qui se définit comme la prise en charge des difficultés habituelles à certains groupes).
Priorité 3, niveau AAA : Ce que l'on peut faire (Qui se définit comme la prise en charge de problématiques particulières à certains groupes).
Par ailleurs, contrairement à une idée reçue, les niveaux de priorité ne sont pas pensés (et heureusement) en terme de difficultés d'implémentations.
Le niveau de priorité 1 concentre les items parmis les plus difficiles comme les traitements alternatifs des images ou des objets multimédia (vidéo, flash) pour ne prendre que cet exemple.
Les items de niveau de priorité 3 (AAA) ne sont ni plus ni moins difficiles ou délicats à implémenter que les autres...
En revanche, parce qu'ils s'intéressent à des aspects particuliers des contenus, ils peuvent engendrer des problématiques plus lourdes, notamment en terme de maintenance.
Encore une fois : il n'y a pas d'intérêt à recopier les WCAG. Elles se suffisent à elles-mêmes, mais il peut y avoir un intérêt si on reformule cela de façon plus simple.
jpv a écrit :
En général
A propos des cadres :
a écrit :
Dans ce cas, la structure est bafouée... la navigation entre les cadres hasardeuse (même en l'absence de handicap)
La problématique liée au cadre concerne essentiellement les utilisateurs de lecteurs d'écrans.
Pour les autres utilisateurs, handicapés ou non, je ne vois pas où la navigation serait "hasardeuse", au contraire, à l'image des interfaces Ajax, c'est plutôt un système de navigation "confortable" car il évite le rechargement de la page...
Pour les utilisateurs de lecteur d'écrans il y à deux problèmes majeurs :
Un jeu de cadre créé un niveau supplémentaire de navigation qui ne me permet pas d'avoir un accès direct au contenu.
La page se présente donc comme une succession de "liens" qu'il me faut visiter l'un après l'autre pour avoir une idée de la structure générale du document et de ses contenus.
Un jeu de cadre, et c'est là une problématique identique aux interfaces ajax, ne me permet pas de savoir lorsque j'agis sur un contenu (par exemple un lien) qu'elle partie de la page est mise à jour.
A propos des tables
a écrit :
Ne pas utiliser de tableau (<table>) pour la mise en page, sauf si le tableau garde un sens lorsqu'il est linéarisé.
On s'en fout que le tableau garde un sens... Ce qui nous intéresse c'est que le contenu garde un sens lorsque le tableau est linéarisé.
a écrit :
Quand un tableau est linéarisé, chaque cellule (<td> ou <th>) devient un paragraphe
Pas du tout, plus simplement chaque cellule s'affiche l'une en dessous de l'autre.
a écrit :
Les cellules doivent garder du sens lorqu'elles sont lues de la sorte.
On s'en fout que les cellules gardent du sens, ce qui nous intéresse c'est que le contenu garde du sens...
Ah ouais, nuance, okay.
[quot=jpv]
A propos de la validation et de la sémantique
a écrit :
Rédiger les codes structurels...
Des codes structurels ? tu veux sans doute parler du code Html (qui est beaucoup plus connu)
a écrit :
Utiliser chaque balise en fonction de son sens
Heu... ce serait plutôt : " dans le sens de sa fonction"....
Blague à part, là aussi, mais c'est une critique permanente sur ce document, on à des expressions consacrées, précises et me semble-t-il beaucoup plus claires comme "utiliser le balisage de manière appropriée", ou "à bon escient" pour ne prendre que les deux les plus habituelles.
Oui, du HTML.
jpv a écrit :
L'usage de tableaux de mise en page ne peut en aucun cas être une exception au respect de la sémantique.
Faut savoir ce qu'on veut, il y à deux paragraphes tu m'autorisais à utiliser des tableaux de mise en forme, là tu me l'interdis, que fais-je ?
Ben... c'est pas par hasard qu'on dit "sauf...". Mais les WCAG ne stipulent pas explicitement "repecter la sémantique", il y a donc une évident contradiction, puisque les WCAG sont assez permissifs je trouve notamment sur cet emploi de tableau à contre-emploi.
jpv a écrit :
Spécifier la langue principale du document. Permet aux lecteurs d'écran de prendre les bonnes intonations. Par exemple, utilser l'attribut lang de l'élément html.
Non, il ne s'agit pas de la langue "principale" mais de la langue de "traitement".
Par exemple sur une page de cours d'anglais destinée à un public français et qui contient plus d'anglais que de français qu'elle déclaration de langue dois-je utiliser ?
Par ailleurs l'attribut lang n'est pas un exemple, c'est l'unique moyen sur la page de le faire...
a écrit :
Lorqu'une information est apportée par la couleur, doubler cet apport d'une autre façon.
Pourquoi réécrire cet item qui est remarquablement clair dans sa version originale : "S’assurer que toute information convoyée par des couleurs est également accessible sans couleur".
Par ailleurs je trouve l'expression "doubler" particulièrement ambigue.
a écrit :
Attribuer un équivalent textuel à tout élément non textuel.
Si il y à, comme tu le dis, un niveau "minimal" de l'accessibilité c'est bien celui là.
Dans ton document c'est le moins clair, ce n'est qu'un relevé purement technique et assez maladroit.
Où sont mes images, mes vidéos, mes images-maps, mes animations flash ?...
Si je suis un débutant, je ne sais vraiment pas de quoi tu parles...
a écrit :
Ne donner qu'une seule alternative textuelle à l'élément img !
Par quel moyen puis-je donner deux altarnative textuelle à une image ?
Et pour ma culture personnelle : où as tu trouvé cette référence à la balise acronym pour l'art ASCII, ce qui de mon point de vue est un cas flagrant de détournement de balisage...
En utilisant à la fois alt et longdesc (je ne sais pas si c'est valdie...).
Pour l'art ASCII :
WCAG, techniques a écrit :
UNe autre option pour de l'art ascci plus petit est d'utiliser un élément ABBR avec un "title".
http://www.la-grange.net/w3c/WAI-WEBCONTENT-TECHS/#ascii-art
jpv a écrit :
A propos de CSS
Les images uniquement décoratives ne devraient pas être présentes dans le code structurel mais insérées en fond (propriété background-image)
Code structurel ?, tu veux parler du code Html (qui est beaucoup plus connu)
Je ne suis pas certain, par ailleurs, que cette "bonne pratique" soit pertinente dans le cadre d'un document de cette nature.
Ce point ne sera jamais évalué par une expertise.
Par ailleurs c'est quand même dommage de trouver cette "bonne pratique" et aucune indication de la nécessité d'une alternative nulle pour les images de décoration...
La difficulté est justement de faire passer le message quant au choix balise img ou css pour les images de décoration.
[quote=jpv]
Utiliser les technologies du W3C quand elles sont disponibles et adaptées à une tâche, et préférer les dernières versions dès qu'elles sont supportées. Ne pas se priver soi ou les utilisateurs des normes établies, à partir du moment où les agents-utilisateurs peuvent les interpréter correctement. Par exemple, baliser en XHTML 1.0 plutôt que XHTML 1.1.
Oui mais alors l'exemple est particulièrement mal choisis, tu aurais dis "utiliser xhtml 1.0 au lieu de Html" passe encore mais là que veux tu dire exactement ? Xhtml 1.1 est réservé à des usages très précis, notamment la possibilité d'utiliser des dialectes Xml, je ne vois aucun rapport avec Xhtml 1.0
Ne pas utiliser de technologies obsolètes. Par exemple, ne pas employer de balises de présentation telles <center>, <font> ou <strike> ou d'attributs de présentation tels align, bgcolor ou valign. Cette pratique ne se limite pas aux technologies du W3C.
<center>,<font>,<strike>, ne sont pas des technologies !
Peut-être voulais tu parler des "options des technologies du W3C qui ne sont plus supportées", bon je t'accorde que les "éléments des technologies" est plus heureux...
J'ai considéré ces balises comme des technlogies car elles en sont des éléments. En tous cas, je parle de tout ce que est obsolète.
[quote=jpv]
Créer un contraste optimal entre la couleur d'arrière-plan et celle du premier plan. Le contenu (dont les images) doit pour pouvoir être lu par une personne daltonienne ou sur un écran monochrome (noir et blanc).
Pas du tout ! Il ne s'agit pas de créer un contraste "optimal", surtout pas, mais "suffisant" et c'est déjà assez difficile comme ça !
Par ailleurs, le contraste ne concerne pas les daltoniens qui sont eux concernés par les associations de couleurs ou l'utilisation de gamme chromatique inappropriée.
Les contrastes concernent tout le monde : les mal-voyants, les quinquagénaires, ma grand-mère, les enfants...
OK.
[quote=jpv]
Baliser correctement les listes et citations. Ne pas utiliser de balises telles <ul> ou <blockquote> pour créer un retrait à partir de la gauche.
Tu prends le problème à l'envers, cet item ne concerne pas l'utilisation abusive de balises pour créer des effets de mise en forme.
Si je dois valider cet item je vais contrôler que je ne détourne pas de balises ul et blockquote et en déduire que mes listes et citations sont balisées correctement.
C'est un contre sens flagrant !!
Là, j'ai pas tout saisi...
[quote=jpv]
Assurer l'accessibilité des contenus dynamiques ou en proposer une version accessible. Par exemple, proposer une version linéaire accessible.
WAI ne parles pas de "version accessible" mais de "version alternative", par ailleurs en quoi cette version alternative devrait-elle être "linéaire" ?
Ca n'a rien à voir...
Fournir des méta-données concernant les documents en eux-même et au sein d'un site. Des méta-données sont des informations sur des données. Elles permettent de donner des précisions. Plusieurs possibilités existent, complémentaires, dont les suivantes :
* donner une valeur à l'attribut title (s'applique à presque tous les éléments) ;
Wai parle "des informations d'ordre sémantique aux pages et aux sites" ce qui me semble, là encore, plus clair.
Tu fais une redoutable confusion entre l'attribut title et la balise <title>
unique qui titre la fenêtre et qui doit être présente, pertinente et différente pour chaque page.
Cet item fait référence à la balise title et à rien d'autre.
Par ailleurs tu à oublié une métadonnée particulièrement importante qui est la déclaration du jeux de caractère.
Beaucoup plus important que les liens relationnels de navigation, système qui est actuellement en état de mort clinique.
Je sous-entend que le rédacteur inclus la méta-donné d'encodage, ça me parait évident.
[quote=jpv]
Fournir un moteur de recherche interne ou un index par mot-clé, accessible depuis chaque page du site. Laisser à l'utilisateur la possibilité de chercher par ses propres choix et idées.
Cadres (<frameset>, <frame> et <iframe>)
Rappel : les cadres nuisent considérablement à la crédibilité du développeur.
Pour être parfaitement honnête, la crédibilité du développeur, en matière d'accessibilité pour le problème des jeux de cadres heu... je m'en contrefous !
Jean-Pierre Si tu veux, mais c'est tellement vieux comme méthode...
Edited by accessibilisation (25 Mar 2007 - 19:30)
