[Résolu] Carrousel accessible

cilou a écrit :
Il me faut un lancement automatique

Est-ce vraiment indispensable ?
Il est recommandé, en accessibilité, de ne pas faire démarrer d'animation de façon automatique.

Surtout que dans le cas d'un carrousel, en général, lorsque celui-ci est chargé et que les yeux du visiteurs se portent dessus, celui-ci en est déjà au moins à la deuxième vignette. Taux de visibilité de la première : proche de zéro.

Autrement pour la question de base sur l'autoplay, les animations disposent d'une propriété permettant la lecture automatique. Mais je dois avouer que je n'ai pas regardé l'exemple de Nico donc pas sûr que ma réponse soit appropriée.
Modifié par Greg_Lumiere (21 Jun 2016 - 15:25)

J'ai retrouvé ceci à propos de la lecture automatique :
Atalan - Faire fonctionner la technologie pour tous... (Astuce n°6).

Je dis ça, c'est juste pour aider.

cilou a écrit :
Merci Greg_Lumiere, je suis foncièrement d'accord avec toi sur le défilement automatique mais les contraintes client sont parfois incontournables...

Je connais ça... Dans ce cas, effectivement, tu n'as pas le choix.
Qui plus est s'il a pour vocation à n'être que décoratif, le taux de visionnage et leur impact importe peu (disons dans une mesure moindre).

Pour la suite, Nico devrait pouvoir t'éclairer afin d'éviter la duplication des mécaniques associées. (moi j'y connais rien en JS et j'ai vus que son exemple en est truffé)

Les contenus qui apparaissent/disparaissent automatiquement sans interaction explicite comme les carousels peuvent rapidement être un problème pour les lecteurs d'écran; surtout ceux qui disparaissent pour être remplacés par d'autres.

L'exemple symtômatique est le suivant: je commence à lire le contenu de la diapositive 1. 30 secondes après, la diapositive 2 apparaît et la 1 disparaît.
Certains lecteurs d'écran vont se mettre à lire la diapositive 2 en plein milieu en interrompant la lecture de la 1; d'autres vont continuer la lecture de la 1 mais vont devenir complètement fou dès qu'on décide d'arrêter de lire ou d'appuyer sur tab à cause de la désynchronisation entre le contenu réellement présent sur la page au temps T et le contenu du tampon interne du lecteur d'écran.
Dans les deux cas c'est un problème, et il n'y a pas vraiment de solution satisfaisante. On ne fait pas disparaître un contenu qui a le focus ou qui est en cours de lecture.

J'ai choisi 30s, je suis assez sympa, la plupart du temps c'est beaucoup plus rapide; mais augmenter le temps ne règle même pas le problème, car on ne peut pas vraiment savoir ce que le lecteur d'écran est en train de lire au temps T. ET ceux qui ont déjà côtoyé des vrais utilisateurs de lecteur d'écran savent à quelle point la vitesse de lecture peut aller de esgargot (débutant/personne âgée) à supraluminique (que même moi avec +10 ans de pratique je ne pige rien).

Partir sur un lancement automatique par défaut et permettre à l'utilisateur d'arrêter le défilement après coup n'est pas non plus une solution très satisfaisante, car peut-être que le mal est déjà fait au moment où il trouve le moyen d'arrêt mis à disposition et ce n'est pas forcément facile ni de le trouver effectivement, ni de revenir à un contenu qu'on voulait lire et qu'on a raté; d'autant plus si le contenu change assez souvent (10-15s ou moins) et bouscule à chaque fois un peu le focus ou le curseur virtuel de lecture.

Donc pas de défilement automatique, sauf si
1 - Soit le temps a une importance cruciale et l'utilisateur est conscient / a été prévenu de ce fait (p.ex. suivi d'une vidéo ou d'un évènement en direct, jeu, etc.). Donc ne convient clairement pas aux carousels qui se lancent immédiatement dès la page d'accueil.
2 - Soit le truc est totalement décoratif et n'a absolument aucun intérêt, auquel cas il peut être utile de masquer compplètement la zone au lecteur d'écran avec aria-hidden=true. Attention au fait que c'est rarement une bonne solution car c'est peu probable que le contenu soit réellement sans utilité autre que purement artistique; il y a forcément presque toujours au moins une petite once d'information utile.

L'idéal si vous voulez pouvoir faire un vrai carousel accessible qui garde sa fonctionnalité de carousel, ce serait de ne jamais ajouter ou supprimer de contenu, ni le déplacer dans le DOM. OU bien ne jamais déplacer ou supprimer un contenu une fois qu'il a été ajouté.
Dans ce cas il vous reste bien entendu CSS pour faire tout ce que vous voulez d'autre: changer l'ordre d'affichage des éléments sans toucher au DOM, les balancer hors écran, mettre leur opacité à 0, ... je suis sûr que certains ont déjà réussi à le faire.
Pendant qu'on y est, en bonus, dans ce cadre les boutons de navigation gauche/droite n'ont aucun intérêt pour un lecteur d'écran; alors autant les virer (aria-hidden=true), ça évite des questionnement stupides (tiens il ne se passe rien quand je clique là, le site est buggé).

Salut Quentin et merci pour cette remise en question... donc, si je comprend bien, le carrousel sur le site https://www.w3.org/WAI/tutorials/carousels/animations/#finalized-carousel n'est en rien accessible sauf si je désactive le lancement automatique ?

Bonjour Quentin et merci.

Sans vouloir abuser... j'aurai bien aimé savoir si mon idée de mettre les descriptions d'images (genre explications des diagrammes) dans leur class "visuallyhidden" (qu'ils utilisent sur les boutons pagination) était bonne ou si je dois absolument utiliser longdesc ?

.visuallyhidden{
    border: 0 none;
    clip: rect(0px, 0px, 0px, 0px);
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
}
.visuallyhidden.hasfocus, .visuallyhidden.focusable:active, .visuallyhidden.focusable:focus {
    clip: auto;
    height: auto;
    margin: 0;
    overflow: visible;
    position: static;
    width: auto;
}

Bonjour

Ma page de test :

_http://spip.comite-de-bassin-guadeloupe.fr/spip.php?page=diaporama#carousel

Je vais me renseigner pour le longdesc, merci.

Bonjour,

nouveau dans le milieu, j'avoue que ce topic m'intéresse également.
Je ne comprends pas trop comment on peut faire un carousel en suivant tes recommandations QuentinC. Lorsque tu parles de "ne pas faire disparaitre les éléments du DOM", le fait de simplement faire un ajout/suppression de class peut suffire ? Le tout serait géré par du CSS.

Autre chose, où as tu vu ces recommandations ? Je ne les mets pas en doute, mais faisant des audits je n'ai pas pu remarquer ces règles dans le RGAA 3. La seule règle que j'ai pu trouver et qui se rapproche de notre contexte est la 13.1.71 :

Dans chaque page Web, chaque contenu en mouvement, déclenché automatiquement, vérifie-t-il une de ces conditions ?
• La durée du mouvement est inférieure ou égale à 5 secondes
• L'utilisateur peut arrêter et relancer le mouvement
• L'utilisateur peut afficher et masquer le contenu en mouvement
• L'utilisateur peut afficher la totalité de l'information sans le mouvement.

Merci à vous,

Bonjour Hammer,

Hammer a écrit :

Lorsque tu parles de "ne pas faire disparaitre les éléments du DOM"

display: none; == faire disparaître du DOM
(par exemple car un élément pourrait très bien être inexistant puis créé en JS a postoriori ; l'effet serait le même

En accessibilité on préfèrera masquer un élément que de le sortir du flux (taille=0 + opacité=0 par exemple).
Masquer un élément en le maintenant dans le flux n'handicape pas son accessibilité.

Par un display: none; le navigateur "déconsidère" l'élément, celui-ci ne fait plus partie du flux et est donc rendu inaccessible.

Hammer a écrit :

Autre chose, où as tu vu ces recommandations ?

Perso, je ne saurais plus te dire mais si si Quentin a raison.

Oui, tout ceci peut intégralement être géré en Css. Dans un soucis de confort pour l'utilisateur, beaucoup n'hésitent pas néanmoins à coupler ces "techniques css" en intégrant d'autres technos (les labels ARIA par exemple).

L'accessibilité est un ensemble qui nécessite une gestion multi-partie. Il serait illusoire de croire que le Css est LA réponse à tout ; les autres langages contribuent tous en ce sens.

a écrit :
Pour l'image et le titre, je pense que je vais laisser plutôt le alt puisque l'on dit qu'une image porteuse d'information doit obligatoirement avoir un alt renseigné

Pas forcément, si tu décris l'image textuellement juste en-dessous et que ce texte est suffisant.
L'avantage que tu as avec du texte libre, c'est que tu peux y mettre du HTML; ce que tu ne peux pas faire dans le alt. Ca devient d'autant plus important si la description est longue et complexe comme pour des diagrammes.

a écrit :
"Titre du carousel qui explique ce qu'on va y trouver dedans" est dans un h2 mais avec un role presentational (ce que j'ai trouvé dans le tuto du w3.org mais en fait je n'ai encore jamais vu ce role là, je vais me renseigner)

Le rôle presentation a pour effet d'annuler le rôle sémantique habituel de l'élément. Concrètement ici, quand bien même ce serait un H2, il n'est pas indexé comme tel par le lecteur d'écran dans sa liste de titres.

a écrit :
Le caractère 65517 après stop animation c'est en fait un petit carré qui représente visuellement le bouton stop (pris dans le tuto aussi), je pourrai mettre à la place une icone fontawesome avec aria-hidden="true", je suppose que ce sera moins perturbant comme ça...

Personnellement, ça m'intéresse d'avoir les codes de ce genre de caractère, afin de pouvoir les enregistrer dans mon dictionnaire. J'essaye d'en dresser une liste mais ce n'est pas facile.

Mais sinon, effectivement, il vaut mieux le mettre en aria-hidden=true.

a écrit :
Je ne comprends pas trop comment on peut faire un carousel en suivant tes recommandations QuentinC. Lorsque tu parles de "ne pas faire disparaitre les éléments du DOM", le fait de simplement faire un ajout/suppression de class peut suffire ? Le tout serait géré par du CSS.

Oui, c'est bien l'objectif ultime à atteindre en fait: que JavaScript ne s'occupe que d'ajouter/supprimer des classes CSS.

Même au-delà des carousels, ça devrait être une recommandation générale pour JavaScript: ne pas faire du CSS en JavaScript, et ne pas faire de l'animation dont la logique est gérée par JavaScript. Avec CSS3 ont a tout ce qu'il faut pour faire des animations et des transitions entièrement gérées par CSS sans avoir besoin de JavaScript.
Dans ce contexte, JavaScript ne devrait être là que pour ajouter/supprimer des classes CSS (ce qui déclenche les transitions associées) et lancer/arrêter des animations CSS, aux bons moments et/ou selon les interactions utilisateur. C'est tout; il ne devrait certainement pas être utilisé pour modifier des propriétés CSS directement.

Par contre, comme le dit très bien Greg_lumiere, passer display à none, de même que visibility ou ajouter l'attribut hidden soit dit en passant, équivaut dans les faits à retirer purement et simplement l'élément du DOM.
IL y a suffisament de quoi jouer avec opacity:0, font:0, clip, width/height:1px, top/left+position:absolute pour rendre le contenu effectivement invisible ou l'envoyer hors écran sans pour autant le retirer du flux.

Attention, je n'ai pas dit qu'on n'avait pas le droit de supprimer un élément du DOM ou le cacher par display:none, mais on n'a pas le droit de le faire à n'importe quel moment, en l'occurence on ne doit pas le faire lorsqu'il est suceptible d'être parcouru par l'utilisateur.
ON peut le faire quand on est certain qu'il n'est pas parcouru par l'utilisateur. Par exemple on peut tout à fait modifier une zone de liste déroulante qui n'a pas le focus, ça ne pose aucun problème; il faut juste être certain qu'elle n'a effectivement pas le focus.

a écrit :
Autre chose, où as tu vu ces recommandations ?

En fait, très peu de monde en parle parce que ce que j'explique est très spécifique aux utilisateurs de lecteurs d'écran. Je parle par expérience, car ça fait 12 ans que je n'ai plus du tout de résidu visuel et que j'utilise Jaws.
Mais comme ceux qui pondent ces recommandations n'ont ni ce genre de retour aussi poussés, ni une expérience quotidienne à de très rares exceptions près, il ne peuvent pas aller aussi loin...