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 .
