5139 sujets

Le Bar du forum

Débat : Les Commerces électroniques, Javascript et l'Accessibilité

Pages :
(reprise du message précédent)

Pandore a écrit :
Si la personne en arrive à faire ses emplettes personnelles sur son lieu de travail, c'est qu'il y a un problème. J'irai même jusqu'à dire que dans ce cas là elle est payée "à rien foutre". Et je ne vais certainement pas la plaindre de ne pas pouvoir faire ses petites courses tranquillement au lieu de bosser comme elle le devrait.


Ca se trouve, des fois elle parle à sa femme au téléphone ou elle ouvre le démineur. Que fait la police ? Smiley fou
Pandore a écrit :

Je savais que quelqu'un allait me sortir ça ! Smiley pelle
Si la personne en arrive à faire ses emplettes personnelles sur son lieu de travail, c'est qu'il y a un problème. J'irai même jusqu'à dire que dans ce cas là elle est payée "à rien foutre". Smiley sweatdrop Et je ne vais certainement pas la plaindre de ne pas pouvoir faire ses petites courses tranquillement au lieu de bosser comme elle le devrait. Smiley rolleyes


Ça c'est un beau préjugé comme je les aime :
- Lieu de travail ne signifie pas horaires de travail. Y'a des pauses, et des gens qui font des heures supp, parfois même pas payées, et qui ne peuvent pas se permettre le luxe de passer faire leurs "petites courses" après le travail.
- Quid des achats qui concernent le travail ? Ouais, y'a des établissements publics et privés qui commandent en ligne. Surprenant, non ? Il existe même des gens dont le métier est "acheteur".
- Les gens payés à rien foutre sont payés, et restent une cible valable, quel que soit le mépris que le développeur de la boutique sur laquelle il passent leur temps à rien foutre leur porte.
- Y'a aussi des gens qui n'ont un accès internet qu'au travail.

Allez, encore plus trollesque :
- La quantité horaire de présence au travail est déterminée par un ensemble de compromis sociaux qui sont parfois (souvent ?) en décalage avec la quantité de tâches à effectuer. Des fois, y'a juste pas de travail, mais faut être là quand même.

J'aurais pourtant juré que Stakhanov était soviétique... Smiley lol
Modifié par Lanza (01 Mar 2010 - 21:33)
Lanza a écrit :
Les gens payés à rien foutre sont payés, et restent une cible valable, quel que soit le mépris que le développeur de la boutique sur laquelle il passent leur temps à rien foutre leur porte.


Ben justement, on dirait bien que non... C'est pas si manicchéen que ça...
Le problème n'est pas tant le js que ça. L'accessibilité des plateformes de shop online par contre est à mon avis assez mauvaise. Sans être complètement inutilisables (enfin quoique, chez certains), c'est franchement bof.... mais bon, c'est pas nouveau, 99% du web n'est pas optimum dans le domaine.

Je rappelle au passage (ça ne fait pas de mal) qu'il ne faut pas lier javascript et inaccessibilité : ça dépend de comment et pourquoi on s'en sert.
Je me doutais bien que le passage mis en citation allait faire grincer quelques dents. Smiley langue Je ne surenchérirai pas au risque de les faire grincer encore plus, même si ça me démange vraiment de répondre à certains passages ^^ Smiley lol
Pour éclaircir un point important: en posant la question de l'accessibilité uniquement dans le sens "que se passe-t-il sans javascript ?", comme dans les messages précédents, on passe en fait à côté du problème.

La question d'accessibilité est au contraire "est-ce accessible avec javascript ?" C'est à dire, est-ce que l'usage qui est fait de javascript est conforme aux critères d'accessibilité.
Laurent Denis a écrit :
La question d'accessibilité est au contraire "est-ce accessible avec javascript ?" C'est à dire, est-ce que l'usage qui est fait de javascript est conforme aux critères d'accessibilité.
En même temps la question initiale de ce sujet concerne le JavaScript intrusif de certaines solutions eCommerce et donc leur non fonctionnement (ainsi que leur inaccessibilité ?) en cas de JavaScript désactivé. Smiley murf

Mais peut-être que ce que tu dis à un rapport avec ta signature (que j'ai un peu de mal à interpréter) ?
la signature de Laurent a écrit :
Les alternatives à flash ou javascript sont des idées reçues.
+1 Laurent.

Reste aussi à voir si désactiver Javascript sur le site le rend totalement non fonctionnel : j'entends par là que le site n'est pas DU TOUT consultable sans : par exemple via du Jquery très mal utilisé.
Ou si certaines parties ne peuvent être crawlées par un moteur de recherche parce que générées en Javascript, là, dans ces cas, effectivement, il y a un problème ou du moins une limite dans la solution proposée. (le deuxième me parait même encore plus grave que le premier, d'un point de vue "réalité économique", même si ce sont selon moi des erreurs graves)

Après, il faut être honnête intellectuellement : on va dire qu'on ne développe plus des CSS pour IE 6 quand il sera en-dessous de 5% (parce que ça nous arrange bien), et il faudrait prendre en compte 1% des utilisateurs qui désactivent Javascript ? Je ne dis pas que c'est bien de penser ainsi (loin de là), mais il y a la réalité économique.


Si le site sans Javascript est un peu moins pratique (plus d'animation, code HTML non Jquery-isé qui apparaît totalement, etc...) mais consultable, il n'y a pas erreur des développeurs àmha.

ça serait intéressant de savoir exactement la proportion des utilisateurs qui désactivent Javascript sciemment et des utilisateurs qui ont Javascript désactivé sans qu'on leur demande leur avis.
Pour ma part, c'est assez rare, je crois que la seule fois que j'ai vu ça, c'étaient soit des geeks utilisateurs de noscript, soit des solutions de sécurité style Norton qui bloquent le Javascript... et j'ai dû voir ça à peine 2 ou 3 fois.

Des retours d'expérience ? (ça m'intéresse beaucoup)
Modifié par Nico3333fr (03 Mar 2010 - 12:14)
Nico3333fr a écrit :
Reste aussi à voir si désactiver Javascript sur le site le rend totalement non fonctionnel
C'est bien de cela qu'il était question ici : le cas de "liens" n'utilisant pas href mais un vilain onclick ou des éléments SELECT déclenchés sur le onchange...

Nico3333fr a écrit :
mais il y a la réalité économique.
A moins d'être un bisounours il n'y a rien à redire à ça ! Smiley lol
Mais quand même les développeurs "devraient" depuis plusieurs années déjà commencer par faire des sites fonctionnant sans JavaScript puis seulement rajouter cette surcouche ensuite.

Nico3333fr a écrit :
Si le site sans Javascript est un peu moins pratique (plus d'animation, code HTML non Jquery-isé qui apparaît totalement, etc...) mais consultable, il n'y a pas erreur des développeurs àmha.
+1

Nico3333fr a écrit :
ça serait intéressant de savoir exactement la proportion des utilisateurs qui désactivent Javascript sciemment et des utilisateurs qui ont Javascript désactivé sans qu'on leur demande leur avis.
Je pense que cet article est toujours d'actualité pour ce qui est des raisons. Concernant les stats celles de w3schools semblent (comme d'habitude) ne pas refléter la plus grande partie des internautes et d'ailleurs s'arrêtent en 2008.

Personnellement j'utilise Noscript mais effectivement je le désactive si j'ai besoin d'utiliser un site mal ficelé. Par contre j'ai vu dans plusieurs grandes entreprises que la désactivation était toujours d'actualité même si ça n'est pas systématique.
Modifié par Heyoan (03 Mar 2010 - 12:29)
Mon petit débat fait des émois ! Smiley murf

Sinon au départ le sujet était comme la signalé Heyoan :

Heyoan a écrit :
En même temps la question initiale de ce sujet concerne le JavaScript intrusif de certaines solutions eCommerce et donc leur non fonctionnement (ainsi que leur inaccessibilité ?) en cas de JavaScript désactivé


mais rien n'empeche d'étendre le sujet de facon plus vaste et à l'accessibilité avec le Javascript comme le sugérrait Laurent Denis

Laurent Denis a écrit :
La question d'accessibilité est au contraire "est-ce accessible avec javascript ?" C'est à dire, est-ce que l'usage qui est fait de javascript est conforme aux critères d'accessibilité.


Il serait peut etre bon de rappeler quelques liens à ce sujet, car personnelement, y'a comme un flou ! Smiley biggol
Cocci_uk a écrit :
mais rien n'empeche d'étendre le sujet de facon plus vaste et à l'accessibilité avec le Javascript comme le sugérrait Laurent Denis
Tout à fait et d'ailleurs je le titillais essprès dans ce sens ! Smiley gangsta (<-smiley du type qui aime bien se faire rembarrer quand ça finit par "qui aime bien châtie bien")

Cocci_uk a écrit :
Il serait peut etre bon de rappeler quelques liens à ce sujet, car personnelement, y'a comme un flou !
C'est également mon cas.
Modifié par Heyoan (03 Mar 2010 - 14:00)
Heyoan a écrit :
C'est également mon cas.


De même, mais il doit bien y avoir quelques règles simple à suivre.
La question est : que mettez-vous derrière le terme accessibilité ?
* l'accessibilité au sens propre (Web accessibility Initiative) ?
* l'accessibilité dite universelle ?
* la qualité Web ?

En effet :

* du point de vue strict de l'accessibilité, javascript est réputé aujourd'hui être une technologie compatible avec l'accessibilité. Ce qui signifie que si l'ensemble de vos fonctionnalités, contenus et interactions générés via javascript respectent l'ensemble des critères WCAG, ce javascript n'a pas besoin d'alternative : les utilisateurs en situation de handicap pourront utiliser votre site. Concrètement, vos scripts doivent être utilisables au clavier, ils doivent générer des alternatives textuelles pertinentes pour les images concernées, ils doivent générer un code HTML approprié (titres, listes, changements de langue, etc.) , ils ne doivent pas provoquer d'ouverture de nouvelles fenêtres sans en avertir l'utilisateur, ils doivent générer des liens explicites au moins en contexte, etc.

* du point de vue de l'accessibilité dite universelle, même si le point précédent est satisfait, la question de l'alternative systématique à javascript se pose. Prendre en compte les utilisateurs n'ayant pas le support javascript (ou un support partiel) est un gain d'interopérabilité et de robustesse.

* du point de la qualité, sachant que l'on s'est efforcé de satisfaire le premier point, on se posera la question de la pertinence de cette alternative à javascript, au cas par cas, fonctionnalité par fonctionnalité : quel est son coût et fait-elle basculer dans la sur-qualité ? Est-elle pertinente quand il s'agit d'interfaces dont le niveau d'utilisabilité sans javascript peut être extrêmement réduit ?

Le premier point de vue a le mérite de la facilité. Le second est un gouffre potentiel. Le dernier est plus intéressant Smiley cligne
Modifié par Laurent Denis (03 Mar 2010 - 14:43)
Une remarque: chronologiquement, ces trois approches ne se sont pas succédées tout à fait dans cet ordre :
* On a commencé du temps de WCAG1.0 et de la découverte des Standards Web par l'accessibilité universelle. On peine d'ailleurs à s'en sortir aujourd'hui, comme en témoignent les méthodes d'application de WCAG qui n'ont pas encore franchi le pas (elles continuent à exiger des alternatives systématiques).
* C'est le passage à la première approche (accessibilité stricte) qui constitue ce pas et l'étape qu'on aborde aujourd'hui.
* Pour la qualité web, disons qu'il faut avoir un pied dans l'innovation Smiley cligne
Cocci_uk a écrit :
Merci Laurent pour tes lumières toujours aussi claires ! Smiley ravi

Merci aussi, c'est très clair Smiley ravi

Quand un site utilise des fonctionnalités avancés en javascript/ajax, c'est souvent très long de refaire ces fonctions sans javascript.

Il manque a ce niveau des outils, qui prennent en compte ce paramètre, c'est a dire la possibilité de faire un même code qui fonctionnerais avec et sans javascript.

Pennons l'exemple d'un panier d'achat qui s'actualise quand l'utilisateur choisi un produit via javascript.

Si on part du modèle MVC, sans javascript il nous faut soit un contrôleur supplémentaire, soit envoyer une variable supplémentaire. Ce paramètre ou ce contrôleur va appeler un module qui rajouteras le produit dans le panier. Si ce module est exactement le même que le module appelé via javascript le développeur gagne un temps précieux.

Le problème c'est que cette méthodologie n'existe pas, en effet il n'existe pas de framework capable de générer un vue pour un template html et pour des données json ou xml en même temps et en garantissant que le code html générer sera le même.

Il est difficile d'envisager de créer des contrôleurs supplémentaires pour chaque action javascript, envoyer des paramètres qui appèle des modules semble donc un bonne solution, mais cela implique dans le contrôleur de rajouter les modules selon ces paramètres, donc de rajouter du code supplémentaire. Là aussi a ma connaissance il n'existe pas de mécanisme permettant au développeur d'appeler ces modèles et ces vues avec les même instructions que se soit avec ou sans javascript.

Bon j'espère que vous ne vous êtes pas endormi après ce texte soporifique et tordu...

Pour faire plus court, avec les outils actuel le surcout en temps développement pour rendre accessible un site "full ajax" Smiley biggol sans javascript est tel que ce n'est souvent pas possible.
matmat a écrit :
Il manque a ce niveau des outils, qui prennent en compte ce paramètre, c'est a dire la possibilité de faire un même code qui fonctionnerais avec et sans javascript.


C'est tout à fait possible, il faut juste procéder dans l'ordre inverse : sans JS d'abord puis ajouter la couche JS. Si on a fait des fonctions propres en Php, ou qu'on utilise un modèle (voire framework) MVC, en quelques lignes de code supplémentaire, c'est fait !

Sinon, une petite question pour Laurent (merci pour l'éclaircissement). Un site qui est entièrement utilisable avec JS désactivé répond-il forcément aux critères pour les 3 types d'accessibilités que tu as décris ?
HammHetfield a écrit :
Un site qui est entièrement utilisable avec JS désactivé répond-il forcément aux critères pour les 3 types d'accessibilités que tu as décris ?

S'il n'est pas accessible avec JS activé (navigation au clavier impossible, par exemple), il n'est pas accessible au sens «propre» (celui de la WAI).
Je parlais seulement du JS pour ça en fait... J'avais jamais trop entendu parler d'accéssibilité de JS, pour moi ça consistait juste à ce que les fonctionnalités soient fonctionnelles avec JS désactivé. Mais je voudrais savoir si ça (fonctionne sans JS) correspondait à du JS accessible, ou si par exemple c'était possible de faire du JS qui ne soit pas accessible, alors que le site peut fonctionner sans JS... Dur de m'exprimer là :s
Pages :
Sujet clos
Aller à