Reprise du message précédent :

Parce que c'est ajouté via CSS, on peut s'attendre à ce que ce soit pûrement décoratif, c'est pas censé faire partie du contenu du document.

 
Sauf que ca fait des années que, comme les sites deviennent de plus dépendants du CSS et du JS, les screen reader se sont adapté et ne lisent plus le DOM reçu, mais le DOM généré, et la plupart des modifications qui y sont apporté (merci ARIA). Et ils n'ont pas de moyen de faire la différence entre une génération via CSS ou via JS.

Sauf que comme dit machinne, à la base, le CSS c'est juste pour le design, l'aspect décoratif.
 
Si tu génères dans le CSS quelque chose d'essentiel à la compréhension de ton document, c'est qu'il y a un problème, ça n'a rien à foutre là. Un screen-reader devrait se contenter de la version HTML brute.

a quoi sert le javascript à la base ? a remplacer la balise marquee . Est ce que les screen reader lisent le javascript ? oui. Et pourtant le texte n'est pas dans le HTML brut.
 
Personnellement, je pense que si tu ajoutes un caractère dans une page html , quelle qu'en soit la source, il doit être lu.
 
Surtout qu'il existe des techniques simples pour ne pas qu'il soit lu, si c'est l'objectif.

Le content CSS n'est pas dans le DOM généré, inspecte ton DOM dans Webkit ou Firefox tu le verras pas. Au mieux il est dans le shadow DOM, auquel l'accès est soit impossible soit un détail d'implémentation du navigateur.

En l'occurence, tu peux pas modifier le DOM visible depuis CSS: http://jsfiddle.net/Tfu6g/

C'est complètement con. Et c'est pas le cas, en bonus.

Ouais, ajouter des couches de merde parce que les screen readers ont décidé de lire un truc qui n'a aucune raison valable pour être lu, s'vraiment trop bien.

toujours aussi ouvert d'esprit
tu ajoutes un caractère, avec une font de merde incapable de rendre un cadenas ouvert en moins de 48px, et après c'est la faute du screen reader de ne pas le planquer

Encore une fois, ça ne demande AUCUN EFFORT d'utiliser des caractères non affichables qui ne polluent pas les screen reader.

Feuille de style. Fait pour faire de la mise en page/du cosmétique.
Lecteur d'écran. Pour les aveugles.
Le second n'a aucun raison valable pour tenir compte du premier. Ca s'arrête là. Ce n'est pas au développeur d'imaginer que peut-être les concepteurs de lecteurs d'écran seront assez cons pour se dire qu'une feuille de style leur sert à quelque chose.

Ca doit etre bien de bosser avec vous : dès que ça ne marche pas comme vous le voudriez, il suffit de sortir un "célafautatruc "
 
Les feuilles de styles influent très largement le comportement des lecteur d'écran ( display:none  par exemple ) . Et encore heureux, la mise en page contient des information qu'il faut transmettre pour comprendre le contenu.

Je lui demande pas de planquer quoi que ce soit, je lui demande de pas lire des trucs qui n'ont aucune raison d'être lus

Et du grand n'importe quoi en bonus, tu te surpasses

1. Si la fonte est une fonte tierce — habituellement le cas — ça demande juste de la recoder en entier (ou de trouver une autre font avec des glyphes identiques mapée sur les bons caractères, trivial), c'est pas exactement AUCUN EFFORT.
2. Ça rend le picking des caractères notablement plus chiant, avec une fonte icônique mapée sur des caractères standards je peux charger la font dans n'importe quel logiciel de gestion de font (genre Font Book sous OSX) et il va gentiment m'afficher tous les caractères de base que j'ai plus qu'à copier/coller, j'ai pas à aller faire 3 lookups dans une page web. Prends "fontawesome" par exemple, comment tu récupères un caractère? Faut ouvrir la page web (ou la version locale), trouver l'icône que tu veux, cliquer sur le nom de l'icône pour ouvrir une version de laquelle tu peux copier son nom, et aller ajouter ça dans ton HTML. C'est bizarre, mais vu d'ici on est aussi assez loin de "AUCUN EFFORT" sur ce second point.

Et accessoirement:

Fontawesome utilise une plage privée (pas des caracères non-affichables). Rien n'empêche les screen readers d'utiliser ces caractères comme contrôle de leur côté, par exemple

Oh oui hein, il est vrai que dire qu'on est pas d'accord avec quelque-chose c'est mal.

Au fait, tu peux me rappeler pourquoi tu commentes là?

Ca doit être vachement bien de bosser avec toi : dès qu'on est pas d'accord avec toi, il te suffit de de sortir "t'es qu'un imbécile borné".

donc display:none est pris en compte et c'est normal
mais les caractères ajoutés ne devraient pas l'être  
 
J'ai du mal à voir la logique.

Nan ça c'est effectivement pas logique. Ça a foutu la merde depuis longtemps déjà à l'époque pour tout ce qui est image replacement, on pouvait pas utiliser display none

La logique c'est que display:none peut être compris comme un changement d'état logique, des zones sont cachées et montrées avec une base sémantique (pas que ça ne puisse pas être très chiant également, comme florentg le note il arrive que ça force à mettre en place des hacks à la con, mais au moins ça reste une interprétation avec du sens: le display:none pourrait probablement être ignoré dans pas mal de cas, mais généralement ça rendrait les documents plus longs et plus difficiles à comprendre pour le liseur).

J'ai jamais vu :before { content } et :after { content } utilisés pour du contenu sémantique, et ça n'a pas de sens dans la mesure où on peut trivialement fait la même chose (en terme d'affichage) en mettant directement le dit contenu dans un enfant de l'élément visé, et en le faisant vivre dans le DOM réel (beaucoup plus tendu pour display:none, ça implique extraire et insérer de grosses sections de DOM en JS, ce qui est lent et pas beau à voir).

Le rôle de :before et :after est très spécifiquement d'ajouter des éléments décoratifs autour d'un élément logique sans altérer le document même (et donc sans altérer le contenu sémantique, ou le DOM). Si il est impossible de les utiliser de cette manière ils ne servent fondamentalement à rien, puisqu'il n'y a aucun moyen de les utiliser qui ait du sens.

En même temps le truc s'appelle "content"  

Et le truc est dans "stylesheets", et inaccessible via le DOM

Non mais laissez les lecteurs de contenu lire ce qu'ils on envie, c'est pas votre probleme.

Bah si un peu, envoyer du bordel incompréhensible aux screen readers c'est pourri, en tant que dev web mon but c'est quand même que le contenu du bordel puisse être consommé, quel que soit le médium d'accès

 
Soit c'est dans la spec, soit c'est pas defini et vous allez pouvoir encore jouer a ping-pong longtemnps.

Historiquement il y a des centaines de trucs pas/mal définis dans le dev web, ça fait 10 ans qu'on gère ça en testant ce que les implémentations font, c'est pas comme si ça changeait grand chose

 
Ben si ca change qque chose pourtant.

Tu nous as pas quitté justement pour faire des langages exotiques que personne ne veut faire ?
Revient ici immédiatement dans ce cas !!!
Et je rends à la belgique leur chinois belge

Je fais un échange standard, un masklinn contre un belge, on en possède un dans l'équipe. quoi que, c'est un bon élément.

Indentation obligatoire or not?

C'est vraiment une question qu'il y a besoin de poser

On sort d'un débat à la con, donc je relance

non obligatoire, ton code doit ressembler à ce que les mecs font ici : http://js1k.com/

Mauvaise relance
Je te donne une piste :

L'un de vous connaît ou a déjà utilisé les scripts de ce fou ?
 
http://www.netzgesta.de/cvi/
 
Ca me paraît assez bourrin o_O

C'est quoi, le Anfy du JS

bah son site est kitsh mais c'est surtout edge.js qui m'intéressait

Ça m'a l'air bien CanJS
 
Quelqu'un utilise ? Pour moi ce serait avec Zend et Jquery.

 
Premier exemple dans chrome:  
 

tu t'es chié ddessus, il faut avoir à la fois une lib de base et canJS

Non, sur leur site.

'lu
On est en train de chiffrer la version mobile d'un site d'e-commerce, j'ai 2/3 questions que je me pose et en bon pd2pauv j'ai pas de smartphone sous la main, donc :
- la version normale du site est complètement en SSL (certif Gandi/Comodo), y'a une contre-indication à faire pareil sur mobile ?
- on utilise sogenactif ou paypal au choix pour le paiement, est-ce que ces 2 sites passent comme il faut sur IOS/Chrome ? (bon sogenactif est déjà bien moche sur desktop donc ça devrait le faire)
- niveau mise en place on pensait mettre un sous domaine genre mobile.machin.com, et à la première visite sur www.machin.com on propose la redirection (puis on redirige ou pas et on garde le choix dans un cookie). Ça le fait ou il y a mieux ?

 
Pour un site vitrine d'agence immobilière, avec une administration pour pouvoir publier de nouveaux bien, en supprimer, etc...
 
Qu'est-ce qui vous semble le plus adapté comme solution?

 

 
Je ne pensais pas partir là dessus à la base mais après y avoir bien réfléchit ça me semble de plus en plus évident...
 
Voyons si les autres sont du même avis, merci à toi