Pop-up vs div cachée

(reprise du message précédent)

yahrou a écrit :
Personnellement, je crée souvent le contenu à afficher directement en javascript au chargement de la page, pour ne pas "déranger" le flux et le contenu naturel de la page.

Il me semble cependant que les lecteurs d'écran interprètent plutôt bien le Javascript. Donc le flux sera dérangé.

Florent a écrit :
Si ça rend la lecture linéaire du contenu (visible et caché) difficile ou incohérente, il y a un problème.

... a priori si il y a incohérence ou difficulté de liaison entre le contenu de la page et celui de la pop-up ou de la div à afficher, c'est un problème de conception de contenu, pas un problème de développement web, problème que ni une solution ni une autre ne solutionnera...

Florent V. a écrit :

Il me semble cependant que les lecteurs d'écran interprètent plutôt bien le Javascript. Donc le flux sera dérangé.

Je ne savais, mais dans ce cas, il est toujours possible de ne créer le contenu que lors de l'appel javascript...

C'est ce que je fait dans le code de la page 1

Ben oui si le contenu est suffisamment léger.

C'est que j'avais testé ici :
http://clb56.fr/test_php_js/include_in_page/

L'important par rapport au flux c'est que la surcouche javascript reproduise le même ordre de déclaration que le dispositif coté serveur.

Contrairement à ce qui se passe dans les "pseudos pop up" la meilleure solution pour ce contenu généré est bien le tout début du flusx dans body.

par contre s'il s'agit d'une quantité de contenu importante et plus aléatoire alors c'est sans doute plus compliqué.
Modifié par Christian Le Bouler (28 Jun 2007 - 14:15)

J'avoue ne pas tout suivre avec les histoires de flux... Je suis encore novice dans ce genre de choses. Je ne sais en fait même pas du tout ce qu'est le flux.

Je suppose que c'est la hierarchisation de la page (ca se dit ?) mais je ne sais pas très bien...

Ma manière de faire est t'elle la bonne ?

Rude

Florent V. a écrit :

Pour ma part, je trouve qu'un lien ouvrant une popup ou une nouvelle fenêtre serait plus accessible, dès lors que l'on prévient l'usager de l'ouverture d'une nouvelle fenêtre...

Oui, mais non. Parce que ça suppose que l'agent utilisateur est fenêtré. Quid des UA qui ne sont capable de restituer qu'un document à la fois (navigateurs texte, mobiles, etc...) ? On perd alors complètement l'objectif qui est de rester dans le contexte du document source.

Ce topic sera sponsorisé toute la journée de vendredÿ par https://addons.mozilla.org/en-US/firefox/images/addon_preview/722/1

(une extension Firefox qui (dés-)active JS site par site)

ffwrude a écrit :
J'avoue ne pas tout suivre avec les histoires de flux... Je suis encore novice dans ce genre de choses. Je ne sais en fait même pas du tout ce qu'est le flux.

C'est l'ordre de l'affichage HTML sans CSS sans JS sans ... (donc pas de texte qui s'affiche dans une colonne à droite alors qu'il précède dans le code HTML ce qui s'affiche dans la colonne de gauche, pas de positionnement absolu, etc)
Modifié par Felipe (28 Jun 2007 - 15:29)

L'absolute c'est le mal !

Merci pour cet éclaircissement (si ca se dit. j'ai des lacunes de français en ce moment c'est fou);

Rude

ffwrude a écrit :
L'absolute c'est le mal !

Non, c'est excessivement pratique dans pas mal de cas.

Arsene a écrit :
a priori si il y a incohérence ou difficulté de liaison entre le contenu de la page et celui de la pop-up ou de la div à afficher, c'est un problème de conception de contenu, pas un problème de développement web, problème que ni une solution ni une autre ne solutionnera...

Euh... c'est un peu n'importe quoi là. Si on poursuit dans cette lancée, tout lien hypertexte vers un autre document est un problème de conception de contenu.

Il n'y a pas lieu de trancher à priori sur cette question de gestion rédactionnelle et d'agencement de l'information. L'information doit-elle être incluse au document, rejetée dans un document à part et accédée via un lien hypertexte, ou rejetée dans un document à part et accédée via une pop-up (en retombant sur un lien hypertexte si JS désactivé) ? Cela dépendra de la nature de l'information, des choix rédactionnels faits, des contraintes d'accessibilité, etc. Mais pas d'un principe général.

Franchement, il serait dommage de lancer de telles généralités[1]. On aura meilleur jeu à rester un peu concret.

Lanza a écrit :
Oui, mais non. Parce que ça suppose que l'agent utilisateur est fenêtré. Quid des UA qui ne sont capable de restituer qu'un document à la fois (navigateurs texte, mobiles, etc...) ?

Si les choses sont faites correctement (lien hypertexte avec surcouche JS), il appartient à l'UA d'exploiter le lien hypertexte et donc de remplacer le document en cours par le document lié.

Lanza a écrit :
On perd alors complètement l'objectif qui est de rester dans le contexte du document source.

Certes. Mais pourquoi s'interdirait-on des améliorations ergonomiques facultatives ?
Avoir un mode d'accès minimal (lien hypertexte) et en surcouche optionnelle un mode d'accès «optimal»[2] (pop-up) me semble un très bon compromis, et une solution intéressante.

---
1. Dit le gars dont la signature proclame « les menus déroulants c'est le mal »
2. Ceci dit, ce mode d'accès est peut-être problématique pour certains utilisateurs. On peut penser aux loupes d'écran et à l'ouverture d'une pop-up hors du champ de la loupe d'écran, à la perturbation possible pour des personnes soufrant de handicaps cognitifs, etc. Je ne suis pas contre des précisions de nos experts ès accessibilité numérique.

Souvent quand je lance des discussions un peu "chelous" je ne comprend pas un traitre mot de ce qui se dit après la deuxième page....

Rude

Florent V. a écrit :

Certes. Mais pourquoi s'interdirait-on des améliorations ergonomiques facultatives ?
Avoir un mode d'accès minimal (lien hypertexte) et en surcouche optionnelle un mode d'accès «optimal»[2] (pop-up) me semble un très bon compromis, et une solution intéressante.

J'ai l'impression qu'on ne parle pas de la même chose.

Je tente un "use case" pour illustrer :
Je suis en train de remplir un formulaire et j'ai un doute. J'aimerais bien accéder à l'aide (que l'auteur n'a pas manqué de fournir ) sans perdre la saisie que j'ai commencée. Si l'aide est dans un document annexe, je vais devoir naviguer sans cesse entre les deux, et pour peu que j'utilise un UA qui ne mémorise pas ma saisie quand je reviens en arrière, je vais devoir me la retatper un certain nombre de fois.

Alors que si l'aide est dans le document lui même et que je peux l'afficher/masquer avec par une action javascript. Si javascript est indisponible, l'aide est affichée.

Quant à avoir un lien normal qui se transforme en popup... Pourquoi ? Dans quel cas ?

Lanza a écrit :
Quant à avoir un lien normal qui se transforme en popup... Pourquoi ? Dans quel cas ?

Heu... je dois parler un peu dans le vide, moi.

Pourquoi ? Pour fournir une information de manière à la fois ergonomique et accessible. Bien sûr, on peut discuter de l'efficacité de la solution au regard de ces deux critères. Mais de là à affirmer que cette solution est inintéressante...

Je pense que si on compare les différentes solutions, elles auront toutes leurs limites et leurs avantages.

Lanza a écrit :
Si l'aide est dans un document annexe, je vais devoir naviguer sans cesse entre les deux, et pour peu que j'utilise un UA qui ne mémorise pas ma saisie quand je reviens en arrière, je vais devoir me la retatper un certain nombre de fois.

À la rigueur, n'est-ce pas de la responsabilité de l'UA ?
Tu parlais des navigateurs pour le média handheld... je suppose que les développeurs de ces navigateurs ont dû se frotter régulièrement à ce genre de problèmes (« comment gérer le mono-fenêtre de visualisation ? »), et sans doute s'adapter, par exemple en implémentant une mémorisation des informations saisies dans les formulaires.

Ceci dit, dans la pratique, ça serait à vérifier par des tests.

Lanza a écrit :
Alors que si l'aide est dans le document lui même et que je peux l'afficher/masquer avec par une action javascript. Si javascript est indisponible, l'aide est affichée.

Si l'aide est courte, c'est effectivement une solution très intéressante. Et si l'aide fait 6 paragraphes de texte et une capture d'écran ?

En bref nous avons deux solutions qui ont leur pour et leur contre. A nous de choisir celle que nous préférons. Non ?

Rude

ffwrude a écrit :
En bref nous avons deux solutions qui ont leur pour et leur contre. A nous de choisir celle que nous préférons. Non ?

Oui. Mais j'aurais bien aimé avoir des précisions sur l'accessibilité des fausses pop-up (et les moyens de les rendre le plus accessible possible).

Florent V. a écrit :

À la rigueur, n'est-ce pas de la responsabilité de l'UA ?
Tu parlais des navigateurs pour le média handheld... je suppose que les développeurs de ces navigateurs ont dû se frotter régulièrement à ce genre de problèmes (« comment gérer le mono-fenêtre de visualisation ? »), et sans doute s'adapter, par exemple en implémentant une mémorisation des informations saisies dans les formulaires.

Ceci dit, dans la pratique, ça serait à vérifier par des tests.

Si c'est normalisé, ou Recommandé par les specs pourquoi pas. Si c'est laissé à l'appréciation du fabricant, c'est prendre un gros risque.

Florent V. a écrit :

Si l'aide est courte, c'est effectivement une solution très intéressante. Et si l'aide fait 6 paragraphes de texte et une capture d'écran ?

Je vois plusieurs solutions :
- regrouper le tout après le formulaire avec le lien interne qui va bien.
- dispatcher les infos avant les champs qu'elles concernent, sauf si vraiment chaque paragraphe est trop long.

Quant à la capture d'écran... on a l'écran devant les yeux.
Modifié par Lanza (28 Jun 2007 - 21:33)

a écrit :
Oui. Mais j'aurais bien aimé avoir des précisions sur l'accessibilité des fausses pop-up (et les moyens de les rendre le plus accessible possible).

+1. Oh que oui j'attends ça avec impatience . Cette technique est très utilisée et le sujet de son accessibilité n'est jamais abordé .

<edit>Merci à ffwrude pour cette question qui je l'espère va nous apporter du supplément d'information </edit>
Modifié par yodaswii (28 Jun 2007 - 21:52)

Bonjour

Déjà il ne s'agit pas de "fausse pop-up" mais d'une technique de gestion d'affichage de contenu : il est visible ou il ne l'est pas. Il n'y a pas plus de "fausse pop-up" que de "pseudo-frames"... Il y a des contenus séparés en documents distincts et des contenus regroupés en un seul document.

La pop-up c'est du contenu extérieur au document qui s'affiche dans une nouvelle fenêtre généralement de taille inférieure à la fenêtre courante. La div masquée c'est une partie du document lui-même où l'idée est de dire que si cette partie du document n'est pas directement utile à la compréhension ou à l'usage de la page en cours (assistance spécifique par ex.) on peut dans certains cas ne pas recourir à son affichage "par défaut" et proposer son apparition à la demande.
La div masquée peut prendre de nombreuses formes, y compris celle de ressembler à une pop-up mais pas seulement.
Au-delà des questions d'accessibilité se pose celle du statut de cette partie de contenu : si elle réfère à une partie du contenu visible l'une et l'autre devraient être jointes, c'est -à-dire former un bloc cohérent subdivisé en deux sous-blocs, l'un visible et l'autre masqué.

La pop-up raisonne autrement. Elle dit que cette partie cachée du contenu peut apparaître dans une autre page (pop-up.html). En utilisation non-screen, les deux contenus sont inconsultables simultanément, ce qui peut poser les problèmes que Lanza a évoqué. La pop-up est un artifice graphique (réduction de fenêtrage) qui équivaut à consulter deux pages distinctes l'une après l'autre, mais grâce à cette astuce de micro-fenêtrage l'utilisateur pense qu'il est toujours sur la même page, ce qui n'est pas le cas.

En revanche la div masquée propose le contenu intégral par défaut et une astuce technique permet à certains utilisateurs de choisir de consulter ou pas les parties masquées. Pourquoi et comment sont-elles masquées est un autre problème.

Compte-tenu du fait que certains navigateurs ne gèrent pas les pop-up par défaut, compte-tenu que nombre d'utilisateurs (notamment dotés d'UA non-screen) ne peuvent pas consulter deux pages différentes simultanément, compte-tenu que le contenu devrait être délivré intégralement pour son usabilité, la solution div masquée devrait être envisagée comme plus opérante que l'autre... (sans parler de certains utilisateurs utilisant des dispositifs particuliers (loupe-zoom) ou d'autres cas de figure parce qu'on ne doit pas trop se préoccuper de savoir comment untel ou untel décidera de consulter le document, non pas parce que ça n'a pas d'importance mais parce que demain d'autres fonctionnalités apparaîtront et qu'on ne peut ni préjuger lesquelles, ni l'usage qui en sera fait).

<edit> Cette discussion n'aurait-t'elle pas sa place ailleurs que dans le salon ????</edit>
Modifié par Arsene (29 Jun 2007 - 10:19)

Moi qui ne développe (en tout cas pour l'instant) que pour les personnes "valide" (ceci n'à rien de péjoratif) je me dis que c'est un boulot énorme que de rendre accèssible cela dans tous les cas de figure. Je pense m'y mettre un jour car c'est surement un plus indéniable.

Parce que dans tous les cas. Pop-up ou <div> cachée... Sans javascript ca risque d'etre compliqué .... Bien sur on peut toujours faire comme l'a si bien dit Yahrou et proposer l'alternative.

Dans le cas d'accèssibilité. Si la div est affiché par un onclick .... Peut on rendre cela accèssible pour une navigation au clavier ? Cela me parait un peu complexe mais je suppose que c'est possible... non ?

Rude