Ho letto un’altra discussione chiusa riguardo al fatto che un utente non riesce a raggiungere il piè di pagina a causa della funzione di scorrimento infinito. Non è stata risolta. Sono state sollevate preoccupazioni sul fatto che si tratti di un problema di UX – il che è assolutamente vero. Tuttavia, è stato portato alla mia attenzione perché si tratta anche di un problema di accessibilità.
Il problema:
Sebbene l’utente stia fornendo un input, ovvero scorrendo, non intende necessariamente attivare lo scorrimento infinito; l’intenzione potrebbe essere quella di raggiungere il piè di pagina per ottenere ulteriori informazioni o assistenza.
Qualsiasi comunità che utilizzi questa configurazione non supererà il livello A delle WCAG 2.1.
Il livello A è considerato il livello più basilare ed essenziale di accessibilità web.
Sto effettuando un audit su una comunità e classificherei questo problema come un fallimento dei criteri di successo:
2.2.2 Pausa, Arresta, Nascondi (Livello A) Critico
Per qualsiasi informazione che si aggiorna automaticamente e che (1) inizia automaticamente e (2) viene presentata in parallelo con altri contenuti, deve esistere un meccanismo che consenta all’utente di mettere in pausa, arrestare o nascondere l’aggiornamento, oppure di controllare la frequenza dell’aggiornamento, a meno che l’aggiornamento automatico non faccia parte di un’attività in cui è essenziale.
3.2.5 Cambiamento su richiesta (Livello AAA) Grave
I cambiamenti di contesto sono avviati solo su richiesta dell’utente o è disponibile un meccanismo per disattivare tali cambiamenti.
La soluzione:
Aggiungere un pulsante “Carica altri post” nel feed per restituire il controllo agli utenti.
Consentire agli utenti di scegliere quanti post visualizzare alla volta, in modo che coloro che desiderano un’esperienza più simile allo scorrimento infinito possano ottenerla.
Non è davvero accettabile dire “se non ti piace questa configurazione, scegline un’altra” – questa può essere facilmente resa più utilizzabile e dovrebbe esserlo. Per molti dei nostri clienti si tratta di un requisito morale e legale.
Spero che questo contribuisca a sostenere la necessità delle modifiche richieste.
Ok, quindi attualmente combinare un feed infinito e un footer crea una soluzione inaccessibile.
Ma non deve per forza essere la soluzione. I controlli potrebbero essere posizionati sul feed per offrire all’utente la scelta tra caricare altri post o raggiungere il footer. C’è spazio per questo?
Un footer è un pattern web molto comune. Creare esperienze web coerenti e riconoscibili è un principio fondamentale per realizzare esperienze utilizzabili e comprensibili.
I footer supportano i Criteri di Successo (SC): 2.4.5 Modi Multipli (AA)
Sono disponibili più di un modo per localizzare una pagina Web all’interno di un insieme di pagine Web, a meno che la pagina Web non sia il risultato o un passaggio di un processo.
Non disattivare i footer su pagine specifiche supporta lo SC 3.2.3 Navigazione Coerente (AA)
I meccanismi di navigazione ripetuti su più pagine Web all’interno di un insieme di pagine Web si presentano nello stesso ordine relativo ogni volta che vengono ripetuti, a meno che non venga avviata una modifica da parte dell’utente.
È la posizione di Discourse che, se si sceglie quella combinazione, il problema sia vostro?
Sapete se esiste qualche consiglio al riguardo nella documentazione che affermi questo fatto: “aggiungere un footer a un sito con scorrimento infinito lo renderebbe inaccessibile”?
Mi trovo in una situazione difficile; dovrò suggerire dei redesign per alcune grandi community che gestiamo. Sto cercando di capire il quadro completo di questo problema.
Non sono a conoscenza di studi esistenti in quest’area, ma è certamente un fatto ben noto che non dovresti inserire un footer sul tuo sito con scorrimento infinito. Ci sono molti esempi popolari qui: Facebook, Twitter, LinkedIn, Instagram, GMail, ecc. Nessuno di questi ha un footer e tutte le funzionalità delle applicazioni web sono disponibili, dato che sono utilizzate da miliardi di persone.
Questo non è previsto nella nostra roadmap e non sono a conoscenza di alcun nostro cliente pagante esistente che abbia richiesto qualcosa di simile.
Quindi, se ho capito bene tutta la storia, il tuo problema è che:
Il tuo sito web principale ha un footer
Vuoi che il tuo sito principale e la tua istanza Discourse abbiano un aspetto simile
Discourse non avrà un footer prominente su alcune pagine, poiché lo scorrimento infinito lo fa scomparire
Non vuoi avere il footer solo su alcune pagine
Capisco che sia una situazione complicata, ma se sei stoico al riguardo hai solo due opzioni se vuoi usare Discourse:
Inserisci il footer.
Usa una pagina senza scorrimento infinito come home page, ad esempio Categories - Discourse Meta, in modo che sia ben visibile e non preoccuparti del fatto che sia irraggiungibile nella rotta /latest.
Non inserire il footer.
La nostra pagina discourse.org ha un footer, così come il nostro blog. Ma qui non abbiamo lo stesso footer. Molte aziende fanno lo stesso, e fare il contrario potrebbe significare solo cercare di inserire un chiodo quadrato in un buco rotondo.
Rappresento una selezione dei vostri clienti paganti esistenti. Inoltre, come ho già menzionato nel mio post iniziale, ci sono altri thread che discutono di questa combinazione e preoccupazione, i quali sono stati liquidati in modo simile alla tua recente risposta.
Non è un problema personale. È un fallimento in termini di accessibilità che molte comunità stanno riscontrando. Speravo che il team fosse aperto a risolverlo.
Continueremo a utilizzare Discourse e valuteremo di sviluppare alcune delle nostre soluzioni personalizzate, dato che questa richiesta è così lontana dalla vostra roadmap.
Pensi forse che ti stai sbagliando, dato che non c’è alcun piè di pagina?
Forse potresti aggiungere del testo nella parte superiore della pagina per spiegare che si tratta di una pagina con scorrimento infinito e senza piè di pagina.
A rischio di sembrare un po’ di parte, non credo sia del tutto corretto classificare Discourse come una pagina web.
È un’applicazione web e, come tale, sfuma il confine tra pagine web e app.
Se lo approccio come un’app, ciò cambia sicuramente le cose in modo significativo?
Apriamolo come PWA e si comporta in modo abbastanza convincente come un’app.
Se apro l’app Mail su iOS, dov’è il footer?
(Ok, ok, ci sono alcuni controlli di base su un pannello flottante in basso, ma lo stesso vale per Discourse in modalità hub)
Apple viene criticata per non averne uno?
E Gmail?
Come mai è accettabile che Gmail e Mail utilizzino lo scroll infinito per le email, ma in qualche modo non lo sia per le liste degli argomenti? Non sono semanticamente molto simili?
Gli utenti sarebbero entusiasti se gli sviluppatori di Gmail o di Mail su iOS introducessero un pulsante per caricare altre email?
Come mai i loro esperti di accessibilità hanno concluso che lo scroll infinito è accettabile per queste due app?
Quindi, queste linee guida sono davvero applicabili in questo caso?
Il forum su https://thepavilion.io/ ha un footer aggiuntivo che potresti usare come ispirazione. Funziona bene su iOS Safari e meno bene (o almeno in modo diverso) sull’app Discourse per iOS.