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

Je me souviens d'un post de notre koala qui disait qu'il centralisait la vérification des formulaires dans les fonctions php, peu importe qu'on y accède en js ou en php. C'était plus facile pour la maintenance.
Modifié par Patidou (03 Mar 2010 - 23:21)

Laurent Denis a écrit :
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 ?

Effectivement mon flou venait bien de là... cela dit je continue d'être perplexe :

* Tout d'abord à cause de cette phrase :

Laurent Denis a écrit :
javascript est réputé aujourd'hui être une technologie compatible avec l'accessibilité.

En relisant la définition de "compatible avec l'accessibilité" je me dis que c'est OK pour l'aspect "technologie largement distribuée" mais je ne pensais pas que la première condition ("La façon dont la technologie Web est utilisée doit être compatible avec les technologies d'assistance des utilisateurs") était respectée.
Au passage je m'interroge aussi sur le CSS qui est cité : celui-ci est-il également "compatible avec l'accessibilité" ? Et si oui est-ce que cela signifie que, par exemple, le contenu généré par la propriété content est considéré comme étant accessible du point de vue WCAG ?

* D'autre part j'ai toujours entendu dire que JavaScript (tout comme les CSS) devait être considéré comme une surcouche "facultative" et que le contenu html ainsi que le bon fonctionnement ne devaient pas reposer sur son activation (je ne parle pas ici des applications web). On parlait même (encore récemment !) de JavaScript intrusif. Mais si je comprends bien ce n'est pas (ou plus) une question d'accessibilité mais de qualité Web !?

* Pour finir je ne comprends pas bien l'intérêt de ce "[...] passage à la première approche (accessibilité stricte)" : est-ce par souci de "pragmatisme" au vu des sites existants ? est-ce simplement pour des questions de coût prohibitif lié à un passage à l'accessibilité dite universelle ? est-ce pour différencier plus clairement les notions d'accessibilité et de qualité ? Autre chose ?


En fait ce qui me chagrine le plus c'est que je ne vais plus pouvoir embêter personne à cause de JavaScript intrusif et ça c'est moche !
Modifié par Heyoan (04 Mar 2010 - 03:04)

HammHetfield a écrit :
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

C'est vrai que ce n'est pas très clair !

Comme c'est expliqué dans le premier premier point de Laurent il suffit que ce qui est généré via JavaScript respecte les règles du WCAG pour être considéré comme étant accessible. Dans ce cas il n'est pas nécessaire de prévoir une alternative "JavaScript désactivé" et par conséquent de se poser la question de l'accessibilité en cas de JavaScript désactivé.

HammHetfield a écrit :
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!

A bon? Que les fonctions php soit propres ou pas, ou bien que l'on commence par javascript ou non ça change pas grand chose. Si ton application finale utilise ajax pour chaque action ou presque de l'utilisateur, ce n'est plus une "sur couche js". Tu fait comment toi pour gérer du html et du json/js/dom avec les même fonctions php bien propres?

matmat a écrit :


A bon? Que les fonctions php soit propres ou pas, ou bien que l'on commence par javascript ou non ça change pas grand chose. Si ton application finale utilise ajax pour chaque action ou presque de l'utilisateur, ce n'est plus une "sur couche js". Tu fait comment toi pour gérer du html et du json/js/dom avec les même fonctions php bien propres?

Nan ce que je voulais dire, c'est qu'à partir du moment ou le site est totalement fonctionnel sans Javascript, donc qu'il fonctionnen uniquement avec du Php, il ne suffit que d'ajouter la surcouche...

Ensuite ouai j'avais pas pensé Json, là je vois pas quelle alternative il existe.

Heyoan a écrit :
En relisant la définition de "compatible avec l'accessibilité" je me dis que c'est OK pour l'aspect "technologie largement distribuée" mais je ne pensais pas que la première condition ("La façon dont la technologie Web est utilisée doit être compatible avec les technologies d'assistance des utilisateurs") était respectée.

A chacun ses responsabilité:
* à la technologie la responsabilité d'être compatible avec l'accessibilité : la compatibilité avec les technologies d'assistance est assurée (au moins formellement) via la nouvelle couche ARIA pour les cas "lourds")
* à toi la responsabilité d'en faire un un usage compatible avec l'accessibilité, c'est à dire notamment avec les technologies d'assistances (donc de respecter WCAG dans le code et les fonctionnalités générées via javascript, et de recourir à ARIA si nécessaire)

Bon, la limite de l'exercice à court terme, c'est que le support d'ARIA n'étant évidemment pas rétroactif, seuls les utilisateurs d'aides techniques très récentes en bénéficient. Le passage de WCAG1.0 à WCAG2.0 laisse donc pour le moment sur le carreau un certain nombre de gens. C'est l'une des raisons pour lesquelles l'obligation de conserver l'alternative à javascript est pour l'instant maintenue dans RGAA et Accessiweb, malgré les problèmes que cela pose.

Heyoan a écrit :

Au passage je m'interroge aussi sur le CSS qui est cité : celui-ci est-il également "compatible avec l'accessibilité" ? Et si oui est-ce que cela signifie que, par exemple, le contenu généré par la propriété content est considéré comme étant accessible du point de vue WCAG ?

C'est exactement la même démarche : c'est à toi de faire un usage compatible de CSS. Et notamment :
* de ne pas utiliser la propriété content pour générer une information absente par ailleurs du contenu HTML, ou de ne t'en servir que pour générer des éléments décoratifs. content n'a jamais été destiné à générer de l'information (le résultat n'est pas réintroduit dans l'arbre du document)
* de ne pas utiliser les images d'arrière plan CSS pour générer etc.
* de ne pas utiliser CSS inconsidérément pour avoir un affichage qui a du sens mais un ordre linéaire de l'information HTML brute qui n'en a pas
* de ne pas utiliser CSS inconsidérément pour se retrouver avec un ordre de tabulation clavier imprévisible pour l'utilisateur parce qu'il ne correspond pas à ce qu'il peut déduire de ta mise en page
* d'utiliser CSS de manière à permettre l'agrandissement à 200% de la taille des caractères (zoom texte) sans perte de lisibilité et d'information
* de ne pas supprimer le focus visuel (ne jamais toucher à la propriété outline)
* etc.

La compatibilité de CSS avec l'accessibilité est beaucoup plus ancienne et solide que celle de javascript (cette technologie a été conçue explicitement en ce sens). Mais tout est dans les usages...

Heyoan a écrit :

* D'autre part j'ai toujours entendu dire que JavaScript (tout comme les CSS) devait être considéré comme une surcouche "facultative" et que le contenu html ainsi que le bon fonctionnement ne devaient pas reposer sur son activation (je ne parle pas ici des applications web). On parlait même (encore récemment !) de JavaScript intrusif. Mais si je comprends bien ce n'est pas (ou plus) une question d'accessibilité mais de qualité Web !?

En effet. Cela reste la solution privilégiée pour répondre à des exigences de qualité ou d'accessibilité universelle. Mais elle peut n'avoir aucun sens ou être impraticable dans un interface riche, où les critères vont être évidemment différents.

Heyoan a écrit :

* Pour finir je ne comprends pas bien l'intérêt de ce "[...] passage à la première approche (accessibilité stricte)" : est-ce par souci de "pragmatisme" au vu des sites existants ? est-ce simplement pour des questions de coût prohibitif lié à un passage à l'accessibilité dite universelle ? est-ce pour différencier plus clairement les notions d'accessibilité et de qualité ? Autre chose ?

Disons que le rôle de l'accessibilité dans la qualité commence à vraiment se préciser après WCAG2.0, et que la notion de qualité elle-même s'affine en prenant conscience des risques de surqualité liés notamment à l'ambition d'une accessibilité universelle. Du coup, par exemple, on peut gérer la question des interfaces riches...

Heyoan a écrit :

En fait ce qui me chagrine le plus c'est que je ne vais plus pouvoir embêter personne à cause de JavaScript intrusif et ça c'est moche !

Mais bien-sûr que tu vas pouvoir continuer. Il faut juste te mettre à jour et changer de référentiel :

Opquast V2.0 a écrit :
CD-020 L'accès aux contenus est possible sans le support des scripts

Héhé
Modifié par Laurent Denis (04 Mar 2010 - 09:40)

Pour répondre à quelques-unes des questions posées, en vrac :

Il est parfaitement possible de faire une application qui soit accessible avec javascript désactivé mais complètement inaccessible avec javascript activé (tout comme il est possible de faire l'inverse). Personnellement, ça m'embêtera d'ailleurs beaucoup plus qu'une application avec javascript soit inaccessible que la même application soit accessible avec javascript désactivé. Je rappelle à toutes fins utiles que ce n'est pas parce que j'utilise un lecteur d'écran que j'ai forcément javascript désactivé et que je ne profite pas du tout de javascript. Le système est conçu de façon à ce que j'utilise les fonctionnalités javascript fournies par le navigateur adhoc, qui lui est tout à fait classique (soit IE8, soit firefox, installé et configuré de façon conventionnelle). On peut donc faire du javascript et de l'AJAX accessible, ou bien du javascript et de l'AJAX inaccessible. Pour moi, le javascript accessible combine deux choses :
1. Manipulabilité des éléments dynamiques possible uniquement au clavier
Ca implique que :
a. tous les éléments qui peuvent être manipulés doivent être focusables
b. L'édition et la saisie sont possibles au clavier
c. Le focus n'est pas déplacé inopinément si l'utilisateur ne s'y attend pas. En particulier, on ne fait pas n'importe quoi sur le onchange d'un select ou le onkeyup/down/press d'un champ texte.
d. L'édition ou la saisie ne sont pas modifiés inopinément si l'utilisateur ne s'y attend pas. En particulier, la saisie pseudo-automatique peuvent être gênante parfois.
e. Les changements de focus et les mises à jour de contenu sont signalés si nécessaire

2. L'état du DOM est en permanence dans un état sémantiquement cohérent, valide et accessible
Quelques exemples :
a. Ajouter des alt sur les images générés et mettre à jour les alt des images modifiées suite à une opération de l'utilisateur . P.ex. changer le alt de "déplier" à "replier" lorsqu'on clique sur une icône déroulant une arborescence. C'est relativement idiot à dire comme ça, mais j'ai encore vu aucune application le faire correctement.
b. Ne pas mettre de fausses popup orphelines à la fin du DOM et le positionner avec CSS uniquement. Il faut que les fausses popup contextuelles soient aussi placées correctement dans le DOM. Je clique sur "paramètres...", la div vient se placer juste après le lien au niveau du DOM et pas dans un endroit arbitraire (comme c'est d'usage malheureusement, là aussi j'ai rarement vu une application faire juste).
c. Baliser correctement les tableaux, listes, etc. générés dynamiquement. Avoir des intitulés de liens cohérents et si possible uniques en tout temps.
d. Baliser correctement les champs de formulaire générés. Modifier si nécessaire les labels, id, title en conséquence de façon à ce que, comme pour un formulaire statique, chaque label de champ soit présent et au maximum unique. Ajouter des numéros d'ordre si nécessaire. Ne pas oublier de changer les intitulés des boutons et pas seulement leur icône. ne pas mettre les messages d'erreur à des endroits arbitraires dans le DOM.
e. Utiliser les innovations proposées par ARIA si c'est nécessaire et pertinent. Les live region et les alertes ARIA fonctionnent déjà assez bien. D'autres comme les slider ou les checkbox 3 états sont déjà pas si mal si on fait les choses correctement.

Voilà ! En espérant avoir pondu un pavé utile.

Ca répond nickel à ma question tout ça

Merci

QuentinC a écrit :

b. Ne pas mettre de fausses popup orphelines à la fin du DOM et le positionner avec CSS uniquement. Il faut que les fausses popup contextuelles soient aussi placées correctement dans le DOM. Je clique sur "paramètres...", la div vient se placer juste après le lien au niveau du DOM et pas dans un endroit arbitraire (comme c'est d'usage malheureusement, là aussi j'ai rarement vu une application faire juste).

Ou bien le focus est transmis au bon endroit.

matmat a écrit :
Si ton application finale utilise ajax pour chaque action ou presque de l'utilisateur (...)

... c'est alors les conditions idéales pour envisager de faire du JavaScript intrusif (/obstructif?) accessible.
Modifié par Florent V. (04 Mar 2010 - 11:10)

Laurent Denis a écrit :
Mais bien-sûr que tu vas pouvoir continuer. Il faut juste te mettre à jour et changer de référentiel

Cool !

Cette fois-ci j'ai tout bien compris ! Merci pour les éclaircissements !

Florent V. a écrit :
... c'est alors les conditions idéales pour envisager de faire du JavaScript intrusif (/obstructif?) accessible.

Arf ! Il va quand même falloir un pitit moment pour s'y habituer !

Laurent Denis a écrit :

Ou bien le focus est transmis au bon endroit.

Oui, effectivement.

Florent V. a écrit :

... c'est alors les conditions idéales pour envisager de faire du JavaScript intrusif (/obstructif?) accessible.

Juste un bémol pour conclure cet échange: vous vous souvenez que ce ne sera pas suffisant si vous êtes sur un site entrant dans le cadre de la loi de 2005 en France (RGAA, sites publics, collectivités territoriales, etc) ni sur un site où votre client demande le respect d'Accessiweb. Dans ces cas, il faut vous résoudre à ne pas respecter le cahier des charges ou à y passer beaucoup plus de temps.

Laurent Denis a écrit :

Juste un bémol pour conclure cet échange: vous vous souvenez que ce ne sera pas suffisant si vous êtes sur un site entrant dans le cadre de la loi de 2005 en France (RGAA, sites publics, collectivités territoriales, etc) ni sur un site où votre client demande le respect d'Accessiweb. Dans ces cas, il faut vous résoudre à ne pas respecter le cahier des charges ou à y passer beaucoup plus de temps.

A mon sens, si on a ce genre de projet avec ce genre de contrainte posée d'entrée de jeu, il faut déjà réfléchir en amont aux problèmes posés par l'utilisation de Javascript et l'envisager comme une simple surcouche.