1141 sujets

Accessibilité du Web

en validant un page rien qu au niveau W3C HTML j ai plusieurs remarques qui signifient en gros que l attribut role n'est pas "nécessaire " pour un l 'élement qui le contient !
<header id="header" role="banner">??
<footer id="footer" role="contentinfo">? <div
<nav id="main_nav" role="navigation">?
<main class="col medium" role="main" id="main">? ?
<aside class="col small" role="complementary">??

Est on encore dans le problème des validateurs qui trop strict manque de flexibilité . si c 'est le cas y a t il un validateur plus souple mais dans ce cas peu t on encore parler de validation ( applicable pour une version spécifique ) ou autant oublier header footer nav main et aside et remplacer la nouvelle norme par l'ancienne en utilisant div !!

sinon que penser des dérogations concernant la page service-publique ? Selon le même article il est etonnant de lire " changement bien que conforme au WCAG 2.0 n'est pas conforme RGAA" !! Les normes se contredisent elles encore ou cela est du passé ?

Existe t il un site de type caniuse pour JAWS ,voiceover , nvda , windows eyes , talkback ?
en gros savoir si quelles techniques fonctionnent selon les trio OS/lecteur d 'écran/ navigateur!!

Merci
Modifié par 75lionel (23 Apr 2016 - 00:27)
Pourrais-tu faire un peu plus attention à ta façon d'écrire ? ton post est écrit de manière bizarre, il manque des accents et des apostrophes.

Pour le validateur du W3C, je suis étonné d'apprendre qu'il tique toujours devant l'attribut role. Il tiquera aussi pour chaque attribut aria-* indiqué en dur.
Est-tu sûr d'utiliser le validateur HTML5 et non pas le validateur HTML4 ?

Ce n'est pas si grave que ça si le validateur t'indique des erreurs, tant que tu sais exactement ce que tu fais.
Le validateur n'est pas une fin en soi, c'est juste une aide.


a écrit :
Existe t il un site de type caniuse pour JAWS ,voiceover , nvda , windows eyes , talkback ?


Pas à ma connaissance en tout cas. C'est vrai que ça pourrait être très utile, mais ce serait beaucoup plus difficile à gérer car on a deux dimensions d'évolutions à représenter (lecteur d'écran et navigateur).

En outre, avoir plusieurs versions d'un même lecteur d'écran pour pouvoir les tester toutes n'est pas toujours simple (surtout Jaws et Windows Eyes; pour NVDA aucun problème avec les versions portables). Sans parler qu'il faudrait probablement avoir autant de mac et d'iPhone qu'il n'y a de versions d'iOS et OS X...

Pour le format epub3, il y a epubtest.org qui essaye de faire quelque chose dans ce goût-là. Pour HTML5 et JavaScript j'en ai jamais vu. IL y a des gens qui ont fait des tests de fonctionnalités spécifiques, mais pas de truc très général comme caniuse.
Merci pour votre réponse ... je n 'ai plus qu'a tester tout ça ....
Modifié par 75lionel (23 Apr 2016 - 19:41)
Bien que je n 'ai pas été trop loin dans le code , après plusieurs lectures toujours en cours il me semble que la raison pour laquelle la ( LES) normes d accessibilité ne sont pas utilisé dans 98% des sites web n'est il pas du a :
-un manque d implémentations support au niveau des lecteurs d écrans
-un manque d implémentations support au niveau des navigateurs
-plusieurs normes d accessibilités qui se contredisent
-beaucoups de normes en double comme pour HTML
-Le manque d 'éditeur alors qu ils sont nombreux pour HTML et CSS JS
-Le manque de validateur ( syntaxique / logique ) qui prend la forme d une cheklist (opquast )
-des techniques qui comme tabindex ou acceskey sont difficiles à mettre et donc peu utilisées

Enfin de nombreux outils existent sous forme de plugin pour les navigateurs ou de snippet .


ARIA est comme un language medata comme RDF, CSS qui ajoute des informations pour un public ( handicap /valide moteur ou sensoriel) en utilisant de façons combinées et plus importantes certains outils selon le public ( liseur d 'écran / navigation clavier ) .

J'ai l'impression que le mot sémantique est de donner du sens ( intérragir) a un groupe particulier : voyant , entendant , manuel ( main) , navigateur , personne , moteurs de recherche. Qu un bouton soit coder en div ou button peut avoir un style identique pour un voyant mais des différences pour le dev javascript par les propriétés et les fonctionnalités implémentées au niveau des navigateurs .

Existe il des éditeurs html/css/js qui intègrent les notions d 'accessibilité/opquast ?

Existe il un livre payant et récent ( 2015/2016) qui dresse l'historique et l'état des lieux de l'accessibilité ?

Pour avoir testé nvda avec la voix électronique , la lecture se relance après arrêt ( touche ctrl) lors d'un clic et donc se relance rapidement sans arrêt et me donne rapidement le mal à la tête !!!

Si on parle d 'accessibilité , est ce que les touches de raccourcis claviers sont les mêmes entre les OS , navigateurs , liseurs de d'écran , fichier html et fichier pdf ?
Modifié par 75lionel (25 Apr 2016 - 23:28)
sion un peu de statistique pris sur la gallerie de site labelisé sur accessiweb : 24 sites avec label OR sur accessiweb et seulement 3 ont encore le label OR et encore le dernier site labélisé date de 2014 ....( on est en 2016 !!) . Le problème est qu'avec l'utilisation de plus en plus fréquente de Framework CSS ; ceux ci n' ont pas actuellement comme but l'amélioration de l'accessibilité ( bootstrap et voir plus haut mon commentaire ) ...... Enfin tous ces frameworks sont tous une bonne base pour apprendre les techniques CSS en lisant le code du noyaux ou des extensions !! .

La grande idée est que il faut facilité la navigation avec parfois plusieurs menus " identique" mais la norme en fait un principe clé ( voir la capture d image ) .
[ pas d' image problème avec le site d alsa a faire .....]
Modifié par 75lionel (26 Apr 2016 - 09:24)
75lionel a écrit :
Le problème est qu'avec le développement des Framework CSS n' ont l pas l'accessibilité pour sujet principal

Te serait-il possible de soigner un tantinet tes tournures de phrases et ta ponctuation car là, franchement, cela devient assez difficile de te suivre (comme te le signalait Quentin) Smiley confus .
Le passage ci-dessus flirte avec l'ésotérisme.
Modifié par sepecat (26 Apr 2016 - 00:48)
a écrit :
il me semble que la raison pour laquelle la ( LES) normes d accessibilité ne sont pas utilisé dans 98% des sites web n'est il pas du a :



98%, tu es sympa. La réalité est plutôt 99.9999%.

Les sites qui peuvent se targuer d'avoir une accessibilité et une utilisabilité correcte pour les différents groupes de handicaps sont très très rares.
Parce que plus encore que la simple accessibilité, il faut penser à l'utilisabilité et l'ergonomie pour les différents groupes; sinon le site ne sera au final pas vraiment perçu comme accessible pour les groupes cibles.

JE dis ça car un certain nombre de sites prétendent être accessibles, le sont plus ou moins d'un point de vue purement normatif, mais ne me donnent pas vraiment l'impression de l'être quand je suis dessus en tant qu'utilisateur, car leur utilisabilité/ergonomie spécifique ou leur structure n'est pas super bien construite.
Il y a par exemple des sites wordpress ou similaires qui ont tellement de titres de niveau et de widgets que ça devient juste incompréhensible quand bien même c'est tout à fait valide.


a écrit :
-un manque d implémentations support au niveau des lecteurs d écrans
-un manque d implémentations support au niveau des navigateurs


Comme partout ailleurs en informatique, les belles spécifications ont toujours un train d'avance par rapport aux implémentations réelles. Rien n'est parfait et rien ne pourra jamais l'être.

Par contre, je ne pense pas qu'on puisse encore aujourd'hui qualifier le support d'ARIA d'insuffisant, ni du côté des navigateurs, ni du côté des lecteurs d'écran.
Certaines combinaisons s'en sortent clairement mieux que d'autres, mais généralement ça se passe quand même plutôt bien maintenant. Le diable se cache toujours dans les détails !

Je ne vois pas pourquoi ça devrait être un critère contre la mise en place de l'accessibilité en tout cas.
Pour prendre un parralèle, JavaScript EcmaScript6 arrive dans les navigateurs, il y a des laissés pour compte, le support est encore un peu cahotique et ça ajoute souvent une dépendance supplémentaire à un transpileur, mais ça n'a pas empêché pourtant un grand nombre de sites de commencer à s'y mettre sérieusement.

Le seul gros bémol actuel, c'est Edge. Je ne sais pas ce qui est passé par la tête de Microsoft, mais le support des API d'accessibilité pour les lecteurs d'écran n'a pas été implémenté.


a écrit :
-plusieurs normes d accessibilités qui se contredisent


Il faut bien voir que la vraie seule norme de référence émane du WAI. Tous les autres organismes ne font que des interprétations et des simplifications dans le but de la rendre plus compréhensible et plus facilement appliquable dans leurs pays d'origine respectifs.

Chaque organisme se contredit un peu, certes, mais c'est surtout dans les détails de haut niveau. C'est comme la loi dans nos différents pays.
Cependant, les principes de base restent les mêmes et ce n'est pas ça qui devrait empêcher la prise en compte de l'accessibilité.


a écrit :
-beaucoups de normes en double comme pour HTML


Quelles normes en double ?

a écrit :
-Le manque de validateur ( syntaxique / logique ) qui prend la forme d une cheklist (opquast )


Ca, c'est tout simplement parce qu'au-delà des choses très très simples comme vérifier la présence des alt sur les images, il n'y a pas, et il ne peut pas y avoir, de vérificateur totalement automatisé.
Par exemple, seul un humain est capable de juger si le contenu d'un alt est réellement pertinent ou non. Au mieux un outil peut faire des suggestions, mais c'est tout.
Idem pour la hiérarchie des titres dans un document, un outil automatisé pourra te dire si la structure est correcte, mais l'humain est le seul à pouvoir juger si elle fait vraiment sens.

a écrit :
-des techniques qui comme tabindex ou acceskey sont difficiles à mettre et donc peu utilisées


Accesskey, en effet. Mais tabindex, non. C'est très simple: on ne doit admettre que trois possibilités: l'absence de tabindex, la valeur -1 et la valeur 0.
Toutes les valeurs supérieures à 0 sont effectivement à proscrire, car ils ne résolvent pas le système de façon simple, prévisible et durable.

a écrit :
-Le manque d 'éditeur alors qu ils sont nombreux pour HTML et CSS JS
Enfin de nombreux outils existent sous forme de plugin pour les navigateurs ou de snippet .
Existe il des éditeurs html/css/js qui intègrent les notions d 'accessibilité/opquast ?


Il faut arrêter de penser que vos clicodromes sont des outils magiques qui font tout à votre place sans que vous n'ayez à réfléchir.

Je trouve dommage qu'on en soit là aujourdh'ui. Qu'il y ait des mecs qui croient que les WYSIWYG est la solution à tous leurs problèmes; qu'il y ait des gens qui arrivent à croire que JQuery est un langage et qui en oublient complètement, ou pire, ne connaissent même pas le JavaScript de base; qu'il y ait des gens qui ne savent plus compiler leur code et qui n'ont même aucune idée de ce qui se passe exactement sitôt qu'ils ont quitté eclipse, et qu'ils se rendent compte qu'il ne suffit pas de regarder ce qui est souligné en rouge et de cliquer sur un bouton pour que ça marche.
Oui tous ces outils sont bien pratiques, mais personne ne devrait oublier que ce ne sont que des outils, pourquoi ils ont été conçus, quels sont leurs objectifs et quelles sont leurs limites. Personne ne devrait oublier qu'un marteau ne cloue pas tout seul à notre place, et qu'il ne peut nous permettre de faire du bon travail que si on sait, au-delà de simplement s'en servir, également tout le cheminement qui a permis d'aboutir à ce qu'il est.

Les vraies raisons du pourquoi la'ccessibilité est si peu prise en compte, pour moi c'est surtout un manque d'ignorance d'un côté, et de volonté de l'autre; mais je dirais surtout de volonté.
ATtention, ce qui suit est très personnel et donc subjectif, les avis sont très partagés sur le sujet et il n'existe pas de réponse unanime et définitive.

Le gros problème de l'accessibilité, d'une part, c'est qu'elle implique d'investir du temps, pour un retour bénéfique général déjà plusieurs fois démontré (et pas seulement pour certains groupes de personnes), mais non immédiat.
Dans un monde où on veut du fric tout de suite maintenant et surtout en se posant un minimum de questions existencielles, la philosophie de l'accessibilité est en décalage complet. On ne voit pas le bénéfice que ça peut nous apporter tout de suite et on est pas certain que c'est rentable, alors on se dit que c'est beaucoup de fric jeté par la fenêtre pour rien, que ça a l'air particulièrement compliqué, et qu'on pourra faire ça plus tard. Et puis finalement on ne le fait jamais, parce que ce n'est jamais le bon moment.
D'ailleurs il n'y a qu'à voir, au-delà du plan purement technique, les entreprises préfèrent payer des taxes plutôt que d'embaucher des handicapés.

L'autre gros problème, c'est l'ignorance.
Si on n'a pas dans son entourage quelqu'un qui est malvoyant, sourd, en chaise roulante ou autre et qu'on est pas sensibilisé, on peut ne pas du tout être au courant des outils de compensation qu'on utilise, certes; tout le monde ne peut pas tout savoir, et moi-même en-dehors de mon handicap qui est la vue, je ne sais que très peu de choses sur les sourds ou les handicapés moteur par exemple.
Mais en fait, c'est surtout qu'on dérange et qu'on fait peur. Personne n'a envie, et n'aime se poser ce genre de question: et si je devenais aveugle ? et si je me retrouvais en chaise roulante ? C'est tout à fait humain comme réaction, mais du coup on est en quelque sorte dans le déni.
Quand bien même on s'est tous déjà plaint au moins une fois d'une écriture trop petite, d'une luminosité insuffisante, d'un endroit trop bruyant pour se concentrer, ou d'une blessure passagère aux mains ou aux pieds qui nous empêche d'aller aussi vite qu'on l'aurait voulu; et quand bien même on sait que la population vieillit, que les problèmes dûs à l'age sont de plus en plus précoces et fréquents, qu'on circule de plus en plus, que les transports sont de plus en plus bourrés et qu'on est de plus en plus rivé sur son téléphone H24.

L'autre face de l'ignorance, c'est l'exemple type de la chaîne de télé qui a la réflexion « qu'est-ce qu'un aveugle peut bien avoir à f**tre de mes services ? », ou le journal qui dit « de toute façon un aveugle ne peut pas lire ».
Rien n'est plus faux, mais c'est quand même profondément ancré dans la tête de certaines personnes.
Certains n'imaginent même pas, ou n'ont même pas envie d'imaginer, qu'on soit et qu'on puisse vouloir faire comme tout le monde: avoir une vie sociale, un travail, des loisirs; le droit et l'envie de s'informer et de se divertir, ...

a écrit :
Existe il un livre payant et récent ( 2015/2016) qui dresse l'historique et l'état des lieux de l'accessibilité ?


Hum... pas à ma connaissance en tout cas. IL y a sans conteste plus de choses du côté anglophone, notamment du côté de chez l'oncle Sam, mais même là, je câle.
Si tu trouves quelque chose d'intéressant, n'hésite pas à partager, même si c'est en anglais. Ca pourrait probablement être utile à beaucoup de monde.

a écrit :
Si on parle d 'accessibilité , est ce que les touches de raccourcis claviers sont les mêmes entre les OS , navigateurs , liseurs de d'écran , fichier html et fichier pdf ?


Disons qu'il y a beaucoup de points communs mais aussi pas mal de différences.
NVDA a été fondé à l'origine par des frustrés de Jaws et de sa politique, il s'en inspire donc pas mal pour le fonctionnement de base.
Par contre sur les systèmes Apple avec VoiceOver, la façon de raisonner est radicalement différente.

Si ta question est, peut-on avoir un seul manuel qui regroupe tous les lecteurs d'écran sur tous les systèmes, la réponse évidente est non.
Chacun a ses particularités et ses différences; si tous les lecteurs d'écran étaient pareils, il n'y aurait pas de concurrence.

P.S. Par pitié, répart ta touche apostrophe et les lettres accentuées. Ca devient difficile de te suivre. Merci.
Modifié par QuentinC (26 Apr 2016 - 09:59)
En relisant ce post je réponds sur 3 parties et ajoute 2 autres parties (question) :

1- le savoir . Je partage votre avis sur le fait que le wysiwyg et autres clicodromes ne sont que des outils et qu 'il faut connaitre le bas niveau pour utiliser pleinement ces outils . Les deux raisons de leurs utilisations sont que c'est plus rapide à coder ( le temps c'est de l'argent ) et que l'utilisateur connait le bas niveau en cas de problème et donc peut modifier le code . Après que certains préfèrent des éditeurs en mode texte comme atom , visual code ....c'est affaire de goût . ... l'important est d avoir toujours en temps réel un rendu visuel dans un navigateur (on utilise pour cela l ' outil browsersync qui recharge la page lors du changement du contenu ( php css html ).

2- à la norme en double . En fait le fait d'avoir deux normes pour la même chose permet en fait d 'être sur que ce que l 'on souhaite faire marchera selon les navigateurs .
Ce lien compare ce qui est possible de faire en utilisant les tag HTML5 ou les attributs aria/rôle .
Ci dessous un exemple qui montre que pour la navigation on peut utiliser la syntaxe html5 ou ARIA /
- pour html 5 on utilise le tag nav : <nav>
- pour Aria on utilise l'attribut role avec la valeur navigation : role="navigation"

3 acces key est mal/pas implémenté mais tabindex si . En relisant l'article sur tabindex sur le site d'alsa ici , l auteur termine en disant en gros que tabindex est une création inutile ! tabindex est il beaucoups utilisé dans la navigation du DOM ?

4 Sinon , ayant désinstaller mon screenreader , est ce que l'information énoncée par la voix pour naviguer dans le dom ( on ne va pas dire page html plus destiné au voyant ) est traduite dans la langue de l'utilisateur ?
Pour role="button" le screenreader prononce t il le mot en anglais ( button ) ou en français (bouton )? En creusant la question suivante , j'affirme qu'il lit ce qui est écris dans la langue de la page .

5 ayant étudier fortement le tag HTML5 video , je suis étonné qu'il n'y ai pas de support par défaut de ARIA/WCAG dans la balise vidéo !! il faut donc modifier le composant par défaut !! En regardant le code de youtube tout est parfaitement gérer. Ci dessous la capture d 'écran montre le code source pour le bouton play et next . Tous les noms des classes commencent par les lettres ytp et le logo play est en svg alors que d'autres players payants utilisent un fichier de font !! Google sur youtube utilise aria-label="lire" ce qui me fait penser que ARIA est international . En changeant la langue du navigateur de français vers anglais ; je constate que cette valeur devient Play . Les CMS gèrent t ils facilement la langue pour la valeur des attributs dynamiques à l'intérieur d'un article ?

upload/48731-alsavideoA.png

Merci

NB j'ai ajouter des accents apostrophes pour être mieux prononcé par le moteur de rendu vocale . Ai vérifier ça après avoir visionner une video youtube ou le présentateur semble être aveugle mais expert chez google concernant le domaine de l'accessibilité. Sinon pense que mes sources d'informations proviendront d'expert w3c ou autres . Pour l' ARIA allez chercher le nom "léonie watson" sur le moteur de recherche de votre choix .
Modifié par 75lionel (02 Aug 2016 - 00:44)