J’ai lu un autre sujet fermé concernant le fait qu’un utilisateur ne peut pas atteindre le pied de page en raison de la fonctionnalité de défilement infini. Cela n’a pas été résolu. Des préoccupations ont été soulevées quant à un problème d’expérience utilisateur (UX) – ce qui est tout à fait certain. Cependant, cela a été porté à mon attention car il s’agit d’un problème d’accessibilité.
Le problème :
Bien que l’utilisateur fournisse une entrée, c’est-à-dire qu’il défile, il ne souhaite pas nécessairement activer le défilement infini. Son intention pourrait plutôt être d’atteindre le pied de page pour obtenir des informations supplémentaires ou un support.
Toute communauté utilisant cette configuration ne respectera pas le niveau A des WCAG 2.1.
Le niveau A est considéré comme le niveau le plus fondamental et essentiel d’accessibilité web.
J’ai effectué un audit d’une communauté et je classerais ce problème comme un échec des critères de réussite suivants :
2.2.2 Pause, Arrêter, Masquer (Niveau A) Critique
Pour toute information mise à jour automatiquement qui (1) démarre automatiquement et (2) est présentée en parallèle avec d’autres contenus, un mécanisme doit permettre à l’utilisateur de mettre en pause, arrêter ou masquer cette information, ou de contrôler la fréquence des mises à jour, sauf si la mise à jour automatique fait partie d’une activité où elle est essentielle.
3.2.5 Changement à la demande (Niveau AAA) Grave
Les changements de contexte ne sont initiés que sur demande de l’utilisateur, ou un mécanisme est disponible pour désactiver de tels changements.
La solution :
Ajouter un bouton « Charger plus de publications » dans le flux pour redonner le contrôle aux utilisateurs.
Permettre aux utilisateurs de choisir le nombre de publications à afficher à la fois, afin que ceux qui recherchent une expérience plus « infinie » puissent le faire.
Il n’est vraiment pas acceptable de dire « si vous n’aimez pas cette configuration, choisissez-en une autre ». Celle-ci peut facilement être rendue plus utilisable et devrait l’être. C’est une exigence morale et légale pour beaucoup de nos clients.
J’espère que cela aidera à étayer le cas pour les changements nécessaires.
Bon, actuellement, combiner un flux infini et un pied de page crée une solution inaccessible.
Mais cela ne doit pas nécessairement être la réponse. Des contrôles pourraient être placés sur le flux pour offrir à l’utilisateur le choix entre charger plus de publications ou atteindre le pied de page. Y a-t-il une possibilité de le faire ?
Un pied de page est un modèle web très courant. Créer des expériences web cohérentes et reconnaissables est un principe fondamental pour rendre les expériences utilisables et compréhensibles.
Les pieds de page soutiennent les Critères de Succès (CS) : 2.4.5 Multiples moyens (AA)
Plus d’un moyen est disponible pour localiser une page Web au sein d’un ensemble de pages Web, sauf si la page Web est le résultat ou une étape d’un processus.
Ne pas désactiver les pieds de page sur des pages spécifiques soutient le CS 3.2.3 Navigation cohérente (AA)
Les mécanismes de navigation répétés sur plusieurs pages Web au sein d’un ensemble de pages Web apparaissent dans le même ordre relatif à chaque fois qu’ils sont répétés, sauf si un changement est initié par l’utilisateur.
La position de Discourse est-elle que si vous choisissez cette combinaison, c’est votre problème ?
Savez-vous si des conseils à ce sujet sont fournis dans la documentation quelque part, indiquant ce fait : « ajouter un pied de page sur un site avec défilement infini le rendrait inaccessible » ?
Je me trouve dans une situation délicate ; je devrai proposer des refontes pour certaines grandes communautés que nous gérons. Il s’agit donc de bien comprendre l’ensemble de ce problème.
Je ne connais pas d’études existantes dans ce domaine, mais c’est un fait bien connu que vous ne devriez pas placer de pied de page sur votre site à défilement infini. Il existe de nombreux exemples populaires ici : Facebook, Twitter, LinkedIn, Instagram, Gmail, etc. Aucun de ces sites n’a de pied de page, et toutes les fonctionnalités des applications web sont disponibles alors qu’ils sont utilisés par des milliards de personnes.
Cela ne fait pas partie de notre feuille de route, et je ne suis pas au courant qu’un de nos clients payants existants ait demandé quelque chose de tel.
Donc, si j’ai bien compris toute l’histoire, votre problème est le suivant :
Votre site principal immobilier possède un pied de page.
Vous souhaitez que votre site immobilier principal et votre instance Discourse aient un aspect similaire.
Discourse n’aura pas de pied de page proéminent sur certaines pages, car le défilement infini le fait disparaître.
Vous ne voulez pas avoir le pied de page uniquement sur certaines pages.
Je comprends que c’est une situation complexe, mais en adoptant une attitude stoïque, vous n’avez que deux options si vous souhaitez utiliser Discourse :
Ajouter le pied de page.
Utilisez une page sans défilement infini comme page d’accueil, par exemple Categories - Discourse Meta, afin qu’elle soit mise en avant, et ne vous inquiétez pas du fait qu’elle soit inaccessible via la route /latest.
Ne pas ajouter le pied de page.
Notre page discourse.org possède un pied de page, tout comme notre blog. Mais nous n’avons pas le même pied de page ici. De nombreuses entreprises font de même, et faire l’inverse revient peut-être simplement à essayer d’enfoncer un clou carré dans un trou rond.
Je représente un groupe de vos clients payants actuels. De plus, comme je l’ai mentionné dans mon premier message, il existe d’autres sujets discutant de cette combinaison et de cette préoccupation, qui ont été rejetés de manière similaire à votre récente réponse.
Ce n’est pas un problème personnel. C’est un échec en matière d’accessibilité que de nombreuses communautés rencontrent. J’espérais que l’équipe serait ouverte à le corriger.
Nous continuerons à utiliser Discourse et envisagerons de développer certaines de nos propres solutions personnalisées, car cela s’éloigne tellement de votre feuille de route.
Au risque de paraître un peu partial, je ne pense pas qu’il soit tout à fait juste de classer Discourse comme une simple page web.
C’est une application web et, en tant que telle, elle brouille la frontière entre pages web et applications.
Si je l’aborde comme une application, cela ne change-t-il pas considérablement les choses ?
L’ouvrir en tant que PWA et elle se comporte de manière assez convaincante comme une application.
Si j’ouvre l’application Mail sur iOS, où est le pied de page ?
(Bon, d’accord, il y a quelques contrôles de base sur un panneau flottant en bas, mais c’est aussi le cas de Discourse en mode hub.)
Apple est-il critiqué pour ne pas en avoir ?
Et qu’en est-il de Gmail ?
Comment se fait-il qu’il soit acceptable que Gmail et Mail utilisent le défilement infini pour les e-mails, mais que ce ne soit pas le cas pour les listes de sujets ? Ne sont-ils pas sémantiquement très similaires ?
Les utilisateurs seraient-ils ravis si les développeurs de Gmail ou de Mail sur iOS introduisaient un bouton pour afficher plus d’e-mails ?
Pourquoi leurs experts en accessibilité ont-ils conclu que le défilement infini était acceptable pour ces deux applications ?
Alors, ces directives sont-elles même applicables dans ce cas ?
Le forum situé sur https://thepavilion.io/ propose un pied de page supplémentaire que vous pourriez utiliser comme inspiration. Il fonctionne bien sur iOS Safari, mais moins bien (ou du moins différemment) sur l’application Discourse pour iOS.