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

Pandore a écrit :

Je savais que quelqu'un allait me sortir ça !
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.

Ç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...
Modifié par Lanza (01 Mar 2010 - 21:33)

Je me doutais bien que le passage mis en citation allait faire grincer quelques dents. 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 ^^

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 !
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)

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 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)

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
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

Cocci_uk a écrit :
Merci Laurent pour tes lumières toujours aussi claires !

Merci aussi, c'est très clair

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" 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 ?

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