Unobtrusive peut avoir deux sens. Technique et fonctionnel. Il y a le JS non-obtrusive qui est séparé du HTML, comme tu l'entends et la dessus je pense qu'on est tous d'accord :) Mais il peut être non-obtrusive au niveau fonctionnel lorsqu'il n'entrave pas le fonctionnement du site.
Dans le cas de github, justement j'en parlais pour montrer que tu peux avoir un fonctionnement agrémenté de JS qui aide mais que tout le site reste fonctionnel et c'est là où je voulais en venir. Pour facebook, sans JS tu n'as pas le chat en bas mais ça n'empêche pas le système de conversation de fonctionner puisque les discutions sont reportées dans l'espace de messagerie. Sauf si ça a changé depuis. En tout cas dans la version dont je me souviens, on trouve bien cet aspect accessibilité étendue par le JS. Une couche fonctionnelle basique et en bonus une version chat quand on a le JS. Bonne pratique selon moi :) En ce qui concerne le coût de développement pour rendre accessible, clairement oui ça a un impact mais il peut être réduit en intégrant ça au process de développement. C'est un peu comme faire du HTML valide. Corriger tout après c'est long et chiant, tout écrire correctement depuis le début c'est pas si dur. Après on est d'accord c'est pas le même niveau de complexité mais c'est faisable et si on réfléchit son site en connaissant les règles, ça aide beaucoup. Par contre je trouve la formation accessiweb hors de prix et c'est vraiment dommage parce que c'est un sujet très important et la faire payer ce prix là c'est se faire de l'argent sur le dos des personnes qui veulent aider leurs congénères handicapés… triste. Simon Courtois On 29 janv. 2013, at 11:41, Florian Dutey <[email protected]> wrote: > 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 > . > > -- -- 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 .
