1174 sujets

Accessibilité du Web

[Résolu] Carrousel accessible

Pages :
Bonsoir

En cherchant un carrousel accessible j'ai trouvé ce lien https://www.w3.org/WAI/tutorials/carousels/ et je l'ai essayé là _http://spip.comite-de-bassin-guadeloupe.fr/spip.php?page=diaporama en modifiant l'effet avec fade et j'aimerai savoir si je n'ai pas "cassé" l'accessibilité ?

J'ai également rajouté des éléments avec la class "visuallyhidden" car dans les pages internes j'aurai des carrousels avec des images porteuses d'informations (genre diagramme ou autre) mais je ne suis pas sure que ce soit la bonne méthode ? Vaut-il mieux utiliser longdesc ?

J'avais commencé par regarder http://www.accede-web.com/notices/interface-riche/carrousels/ mais les exemples dans composant m'ont semblé plus compliqués à modifier. Par contre j'ai lu qu'il fallait utiliser des roles et des tabindex, ce que mon carrousel n'a pas... (enfin, ils parlent des tabindex là https://www.w3.org/WAI/tutorials/carousels/functionality/#focus-change mais j'ai beau regarder leur exemple, je ne vois pas quand cela s'applique... je ne comprend pas leur explication : // Only if the slide was directly // picked from the list of slides).

Donc tabindex / role oui, non ?

Merci d'avance
Hello,

vu que j'ai créé un des scripts de carrousels mentionnés sur Accede, je me permets de te répondre, en espérant que cela t'aide ! Smiley cligne

Grosso merdo sur le principe : le carrousel est ni plus ni moins qu'un script d'onglets auquel on a ajouté un bouton précédent/suivant (et en général, les contrôles sont mis en bas, même s'ils doivent être avant dans la source, etc.).

Les onglets ont un design pattern bien cadré : il faut lier chaque contenu à chaque contrôle, ça se fait avec des attributs ARIA. Pour cela, je t'invite à regarder le DOM de http://a11y.nicolas-hoffmann.net/tabs/ (un script d'onglets accessibles) avec un Firebug ou un inspecteur équivalent. Tu verras des 
aria-controls
(pour dire "ce contrôle contrôle tel contenu"), et des 
aria-labelledby
(qui disent "ce contenu est lié à tel contrôle"). Plus des 
aria-selected
, etc.

Ensuite vient la gestion du clavier. Pour les tabindex, c'est pour rendre des éléments focusables (atteignables au clavier, 
tabindex="0"
) ou pas (
tabindex="-1"
). Si tu regardes la nav clavier, les contrôles ne sont pas tous atteignables avec la touche Tab.

Si tu atteins un contrôle avec Tab, tu pourras entre autres utiliser les touches Gauche et Droite de ton clavier, et ô miracle, ça va te permettre d'atteindre les autres onglets/contrôles (tu remarqueras que le script va mettre 
tabindex="0"
sur le contrôle que tu as atteint avec les flèches, il n'y a rien de magique, c'est JavaScript qui écoute ce qu'il se passe sur le clavier et qui met tout ça à jour Smiley cligne ).

Le mien de carrousel est ici : http://a11y.nicolas-hoffmann.net/carrousel/ peut-être cela pourra t'inspirer pour créer le tien.

En pratique, le script du carrousel est un peu plus compliqué, car il génère les contrôles (là où celui des tabs ne fait que les customiser, ils existent déjà), les boutons back/next, tout le maillage entre les contenus et les contrôles, etc.
Modifié par Nico3333fr (21 Jun 2016 - 11:20)
Bonjour et merci Nico pour toutes tes explications. Hier, avant de me lancer dans la construction du carrousel, j'avais déjà bien étudié le tien mais en fait, il me faut un lancement automatique avec un bouton play/stop et j'avoue que mes compétences sont insuffisantes pour coder ce genre de chose...
Modérateur
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)
Merci Greg_Lumiere, je suis foncièrement d'accord avec toi sur le défilement automatique mais les contraintes client sont parfois incontournables...
Je précise ma problématique : un carrousel d'images (je dirais à vocation décorative) en page d'accueil (en haut de site) et parfois un carrousel en page interne avec des images informatives, celui là, je pensais ne pas le mettre en automatique mais j'aurai bien aimé n'avoir qu'un code pour les 2 cas.
Modérateur
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é).
a écrit :
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 ?


Ce n'est pas forcément inaccessible, ils ont peut-être trouvé un moyen pour ne pas faire réellement disparaître du DOM les diapositives passées.
En tout cas je n'ai pas réussi à repérer de partie qui changeait automatiquement.
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;
}
Tu as un exemple fonctionel ? Ce serait sans doute plus simple pour te répondre.

Ce qui est sûr, c'est que longdesc n'est pas très populaire. Ca fait très longtemps que je n'en ai pas vu, et je me demande même si ça n'a pas été supprimé de HTML5; un moment donné en tout cas il en était question.
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.
ca me donne ça :

a écrit :

Titre du carousel qui explique ce qu'on va y trouver dedans
Titre de l'image
Titre de l'image sauf si ça fait double emploi avec le alt de l'image
Description détaillée de l'image si nécessaire

Previous Slide
Next Slide
Stop Animation ?



Ca dépend de ce que tu vas effectivement mettre, mais comme tu peux le constater :
Titre de l'image
Titre de l'image sauf si ça fait double emploi avec le alt de l'image
risque fort de faire doublon; dans ce cas un alt vide pourrait très bien convenir.

En outre, c'est quoi ce caractère 65517 après stop animation ? Ce symbole inconnu provoque une élévation de la voix comme s'il y avait un point d'interrogation. C'est un détail, mais ça fait bizarre...


Si tu ne fais pas de défilement automatique, je pense que ça peut aller comme ça.


Par contre question :
"Titre du carousel qui explique ce qu'on va y trouver dedans" est un texte normal, que jaws me rapporte comme étant en taille 23 donc à priori plutôt gros
"Description détaillée de l'image si nécessaire" est un H3

Ce n'est pas plutôt "Titre du carousel qui explique ce qu'on va y trouver dedans" qui devrait être un H3 ?
Un grand merci Quentin d'avoir étudié mon carousel.

Ce carrousel ne sera pas en défilement automatique vu qu'il affichera des diagrammes ou autres et qu'il faut laisser du temps pour les étudier...

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é

"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 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...
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,
Modérateur
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...
Bonjour Quentin

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


Oui j'ai découvert ça mais par contre je ne comprends pas trop pourquoi dans le tuto ils l'utilisent sur le titre du carousel alors que 2 pages avant ils disent que c'est important d'utiliser des heading... https://www.w3.org/WAI/tutorials/carousels/structure/#label-carousels


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


Peut être connais tu déjà ce site : http://www.codetable.net/Group/halfwidth-and-fullwidth-forms

Sinon, merci pour tes explications sur le DOM et le pourquoi laisser les éléments dans le flux.
Pages :
Sujet clos
Aller à