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 .
