Au passage, si vous voulez tester les différents niveaux WCAG sur vos pages, y a ce petit truc qu'est pas mal : http://squizlabs.github.com/HTML_CodeSniffer/
2013/1/29 Florian Dutey <[email protected]> > Oulah, j'ai l'impression qu'on confond 2 choses (ou alors c'est moi qui > sépare 2 concepts qui n'en sont qu'un). > > Pour le premier point, je te le donne. Car, triple oui, il faut faire un > site accessible si l'accessibilité est importante. > Pour le second, j'ai plus de mal: 90% du marché ce n'est pas 90% des > browser web. Il y a d'autres données à analyser. En particulier, si ça te > coûte 400% de temps supplémentaire pour passer le JS de ton site en > "unobtrusive", c'est peut-être le signe d'une dette technique qui > s'accumule (pas d'API? états cachés? etc.). > > Je fais toujours tout de manière unobtrusive. Ca ne veut malheureusement > pas dire que tout marche sans JS, bien au contraire. > Si pour vous, accessible = unobtrusive, ok, je fais que du full > accessible. Mais clairement, je ne l'entends pas de cette oreille. C'est > sur qu'un site entièrement codé avec du document.write, ca va pas être très > accessible. L'inverse n'est pas forcément vrai. > > Pour moi, accessible ca veut dire que: > > 1) le site / appli est "utilisable" sans JS > 2) le site / appli est visuellement "viable" sans css (sans trop exagérer > non plus) > 3) on peut naviguer "correctement" avec les tabulations > 4) ca peut être utilisé par un synthétiseur vocal > > Le fait que le code soit réalisé de manière unobtrusive, ca n'a juste rien > à voir, enfin je crois. Le fait que le js / css soit strictement séparé du > contenu, ca ne garantit ni n'empeche que ce soit accessible. Le fait de > faire de l'unobtrusive FACILITE l'accessibilité mais ca ne la garantit pas. > Après, dès lors qu'on fait de l'application un peu riche, le "utilisable" > devient très relatif. Quand vous citez github, même si c'est une > "application", le front n'est "que" du sliding de page. Le js est la pour > faire de l'esthétique mais le métier est celui d'un site web. > Le business de github n'est clairement pas le frontend. > > Utiliser facebook sans js, c'est deja se priver de pas mal de > fonctionnalités pourtant essentielles (messagerie par exemple). > > Pour moi, faire de l'accessibilité, c'est pas simplement faire en sorte > qu'un lien ait un href correct même si il y a un .click() dessus. Il y a > des normes d'accessibilité et ca représente un boulot énorme. D'ou le > "400%" (pris à titre d'exemple pour parler de rentabilité). > Quand on me parle d'accessibilité, je pense à ca: > http://www.accessiweb.org/ > Et ca, ca coute très très cher ^^. > > > Le 29 janvier 2013 10:54, Nicolas Mérouze <[email protected]> a > écrit : > > Vous oubliez quand même qu'on peut faire du Javascript accessible avec >> ARIA. Vouloir absolument faire du nojs, surtout pour des applications web, >> me paraît vraiment un frein au progrès. Bien sûr faire du client-side en JS >> c'est pas la chose la plus facile du monde car c'est un peu trop le chaos >> (avis personnel), mais quand on voit la fragmentation Android, c'est pas >> pire que la fragmentation des navigateurs. >> >> En France 1.7 million de personnes ont des handicaps visuels et 2.3 >> million des handicaps moteurs, on est donc environ à 5% si le site ou >> l'application web n'a pas d'audio. Et comme peu de sites sont accessibles, >> peu d'handicapés vont sur Internet, tu n'auras pas 5% d'handicapés sur ton >> site. >> >> Mais il faut aider les handicapés à aller plus sur Internet. Si on >> utilise jQuery UI (et mobile je pense) sont développés pour être compatible >> ARIA et donc accessibles aux handicapés, le problème vient des frameworks >> type backbone.js/ember/... qui ne font rien de ce côté. >> >> Et pour les geeks qui ne veulent pas être trackés, il y a autre chose que >> bloquer le JS (header Do Not Track par exemple), c'est pas parfait pour >> l'instant mais c'est mieux que de bloquer le progrès. >> >> Bref on peut contenter tout le monde sans faire du nojs, mais c'est pas >> encore parfait et quelque soit la solution il y aura du travail (duh!). >> >> -- >> Nicolas Mérouze / @nmerouze >> http://boldr.net >> >> 2013/1/29 Olivier El Mekki <[email protected]> >> >>> Hello, >>> >>> Pour moi, il est absolument indispensable de faire un support nojs si tu >>> veux avoir une application (ou un site) robuste. Ce n'est pas une >>> question d'accessibilité, ce n'est pas une question d'être sympas avec >>> ceux qui respectent les bonnes pratiques de sécurité, c'est une question >>> d'avoir bien conscience de la confiance que tu peux avoir en qui exécute >>> le code. >>> >>> Lorsqu'on bosse sur du server side, on écrit le code chez nous, on >>> vérifie qu'il fonctionne sur le ou les servers, et c'est tout bon : >>> quand bien même il y aurait 50k visiteurs par jour, c'est toujours les >>> mêmes machines qui exécutent le code, et on peut raisonnablement >>> imaginer qu'elles produiront encore et toujours le même résultat. >>> >>> Lorsqu'on bosse en client side, c'est radicalement différent. Chaque >>> browser de visiteur est un environement d'exécution différent. Il y a >>> des dizaines de problèmes qui peuvent survenir auxquels tu ne pourras >>> rien faire : vieux browser, problème de connexion, plugin qui fout la >>> merde, ram saturée d'une vieille machine, you name it. Le problème >>> n'est pas de savoir s'il y aura des erreurs, c'est de savoir quelle >>> quantité il va y en avoir et comment elles vont être gérées. >>> >>> Maintenant, que font la plupart des sites lorsqu'une erreur survient ? >>> Rien. Un lien clické devient soudainement inutilisable. Nous, >>> développeurs, aurons le réflexe de reload la page. Un utilisateur moyen >>> s'énervera et ira voir ailleurs. >>> >>> J'ai pris l'habitude de désactiver tous mes callbacks sur l'event >>> window.onerror (qui est triggered quand une erreur survient sur la >>> page). Une fois désactivé, la page html reprend son droit, étant faite >>> pour que le liens pointent vers de vraies urls et que les inputs soient >>> dans de vrais forms. De cette manière, à la moindre erreur, le nojs est >>> utilisé, exécute l'action et, reloadant la page, reload le js. Le >>> visiteur ne s'aperçoit même pas qu'il y a eu une erreur. >>> >>> Bien évidemment, ça demande beaucoup plus de temps de coder comme ça. Il >>> y a donc un choix pragmatique à faire pour décider, sur la base des >>> objectifs du projet, si tu veux une robustesse intransigeante ou si au >>> contraire il faut que l'app soit développée rapidement. >>> >>> On 17:12 Mon 28 Jan , Guirec Corbel wrote: >>> > Bonjour, >>> > >>> > Je suis en train de regarder mes logs et j'ai plusieurs erreur >>> > concernant une personne accédant à une page en HTML alors qu'en suivant >>> > les liens de mon site ça devrait être du javascript. La seule raison >>> que >>> > je vois c'est qu'elle à désactivée son javascript. Je ne sais pas si >>> > c'est un humain ou pas. >>> > >>> > Je me pose donc la question : Faut-il que je développe mon site dans le >>> > cas ou le javascript est désactivé? >>> > >>> > Bonne soirée, >>> > Guirec. >>> > >>> > -- >>> > -- >>> > Vous avez reçu ce message, car vous êtes abonné au groupe >>> "Railsfrance" de Google Groups. >>> > Pour transmettre des messages à ce groupe, envoyez un e-mail à >>> l'adresse [email protected] >>> > Pour résilier votre abonnement envoyez un e-mail à l'adresse >>> [email protected] >>> > --- >>> > Vous recevez ce message, car vous êtes abonné au groupe Google >>> Groupes Railsfrance. >>> > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse >>> [email protected]. >>> > Pour plus d'options, visitez le site >>> https://groups.google.com/groups/opt_out . >>> > >>> > >>> >>> >>> -- >>> Olivier El Mekki. >>> >>> -- >>> -- >>> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >>> de Google Groups. >>> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >>> [email protected] >>> Pour résilier votre abonnement envoyez un e-mail à l'adresse >>> [email protected] >>> --- >>> Vous recevez ce message, car vous êtes abonné au groupe Google >>> Groupes Railsfrance. >>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le >>> concernant, envoyez un e-mail à l'adresse >>> [email protected]. >>> Pour plus d'options, visitez le site >>> https://groups.google.com/groups/opt_out . >>> >>> >>> >> -- >> -- >> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >> de Google Groups. >> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >> [email protected] >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> [email protected] >> --- >> Vous recevez ce message, car vous êtes abonné au groupe Google >> Groupes Railsfrance. >> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le >> concernant, envoyez un e-mail à l'adresse >> [email protected]. >> Pour plus d'options, visitez le site >> https://groups.google.com/groups/opt_out . >> >> >> > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > --- > Vous recevez ce message, car vous êtes abonné au groupe Google > Groupes Railsfrance. > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse > [email protected]. > Pour plus d'options, visitez le site > https://groups.google.com/groups/opt_out . > > > -- Jean Paliès -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
