28172 sujets

CSS et mise en forme, CSS3

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

Ehplod a écrit :
visibility hidden, peut-être ?

Non. Même souci qu'avec display:none ou presque.

Ehplod a écrit :
On doit bien pouvoir mettre un texte image pour le design et le remplacer par du texte textuel pour les nav textuel...

Tu ne peux pas détecter l'utilisation d'un lecteur d'écran (et heureusement!). Les lecteurs d'écran sont des logiciels qui se «branchent» sur des navigateurs, donc le navigateur détecté sera Internet Explorer, Firefox ou encore Safari.

Ehplod a écrit :
Ou alors jouer avec les z-index ?

Une des solutions les plus accessibles (mais pas parfaite) consiste effectivement à placer un élément ou pseudo-élément en absolu par dessus le texte. Si l'image ne s'affiche pas, le texte en dessous est visible.
Mais Florian_R a raison: l'attribut alt remplit très bien sa fonction. Donc je n'utiliserais ce type de technique que dans le cas où je dois utiliser une image de type «sprite».
Ehplod a écrit :
Le fond de base est en background, pas les fond d'hover.

Si pour une raison ou une autre l'image de fond n'est pas chargée, le menu disparait complètement et il faut deviner que quelque chose se passe au survol.

C'est du bricolage parce que ça utilise un mécanisme non standard (mettre un contenu en background), et qu'en cas de souci (problème de chargement de l'image) le navigateur ne peut pas adapter le rendu.

Côté accessibilité les liens apparaitront sans libellé (car contenu en display:none) dans les lecteurs d'écran.

Par ailleurs, côté ergonomie c'est un exemple de Mystery Meat Navigation (navigation «viande mystère»), en l'absence de texte visible par défaut il faut deviner qu'il s'agit d'un menu de navigation et survoler chaque élément avec le pointeur. Sur une tablette tactile ça doit être drôle d'ailleurs, vu que le survol (:hover) n'existe pas sur ces machines.
fvsch a écrit :
Sur une tablette tactile ça doit être drôle d'ailleurs, vu que le survol (:hover) n'existe pas sur ces machines.

Tiens, va encore faloir coder alternativement pour elles ?
Moi qui pensais, a tord semble t-il, qu'avec IE9 ont allait enfin avoir un peu de répit... Smiley smile )
Ehplod a écrit :
Tiens, va encore faloir coder alternativement pour elles ?

On peut voir ça dans l'autre sens: sur un périphérique tactile on peut utiliser les touch events pour une partie des interactions, tandis que pour rendre ça compatible pour les périphériques avec pointeur il faut coder alternativement et utiliser le survol.

Ou bien: se reposer sur des éléments de design et des interactions de base qui ne sont pas dépendantes du périphérique. Ainsi on n'a pas besoin de coder spécifiquement pour un mode d'accès ou un autre. Et s'il on choisit de coder spécifiquement pour certains cas de figure, ça sera pour des optimisations et pas pour le fonctionnement de base.
Pages :