Non so se questo sia già noto o tracciato da qualche parte. Se lo è, gradirei ricevere dei link. Tuttavia, anche se la situazione sta migliorando, l’esperienza d’uso di Discourse con un lettore schermo presenta alcune sfide che vorrei documentare.
Sono un utente di lettori schermo e volevo configurare un’istanza auto-ospitata principalmente destinata a utenti non vedenti. Di solito non consiglio Discourse a causa di problemi di accessibilità, ma state rendendo molto semplice l’auto-ospitazione con le funzionalità che desidero, quindi mi dispiace che l’accessibilità non sia ancora al punto giusto. Ecco alcune delle sfide che sto affrontando:
I menu a tendina che il mio lettore schermo riconosce come elementi HTML <select> sono quasi completamente difettosi. Si espandono seguendo le convenzioni standard della tastiera, ma qui finisce l’accessibilità. I problemi sono iniziati quando ho dovuto selezionare una lingua durante la configurazione. Non sono immediatamente sicuro se “Inglese: Stati Uniti” fosse impostato come predefinito, ma quando ho deciso di indagare, avevo per errore impostato la lingua in spagnolo e ho avuto difficoltà a riportarla indietro. Alla fine ho trovato l’elenco con il mio lettore schermo e sono riuscito a correggerlo. Ma praticamente ogni menu a tendina è rotto. Non voglio dire “tutti” nel caso ce ne sia uno in qualche angolo remoto dell’interfaccia che funzioni, ma ognuno che ho provato non funziona affatto.
Non riesco a trovare un modo per accedere all’interfaccia di amministrazione senza navigare direttamente. Le schermate di configurazione mi hanno detto che si trova sotto l’icona dell’ingranaggio, ma non riesco a trovare una rappresentazione testuale di cosa possa essere l’icona dell’ingranaggio, né sembra che nessuno dei controlli accessibili da tastiera che ho trovato porti effettivamente all’interfaccia di amministrazione. Per ora mi limito ad accedere a /admin, ma questo mi fa chiedermi quali strumenti potrei non scoprire perché non riesco a trovare quell’ingranaggio.
In relazione al menu a tendina delle impostazioni, non riesco a utilizzare i menu a tendina/selector in alto nelle liste delle categorie per navigare verso gli elenchi delle categorie. So dell’elenco “Categorie”, che è ciò che uso generalmente. Ma sarebbe bello se quei selettori funzionassero.
Ogni volta che non mi iscrio a un Discourse, mi viene detto che dovre farlo anche perché il forum ricorda dove ho interrotto la lettura. Questo non ha mai funzionato per me con un lettore schermo. Come dovrebbe funzionare? Cliccare sul link dovrebbe spostare il focus sul post che ho letto per ultimo?
E non riguarda il mio sito, ma l’esperienza di iscrizione modale qui ha presentato alcune sfide. Ho provato a registrarmi via email, ma la vostra istanza ha rifiutato il mio indirizzo email .info che uso da quasi 17 anni e che ha funzionato perfettamente sul mio. Successivamente mi sono registrato tramite Google, ma la finestra modale che mi è stata proposta al ritorno ha presentato alcune difficoltà:
Non ha acquisito il focus della tastiera, quindi ho dovuto cercarlo e interagirci manualmente.
Mentre stavo cercando di farlo, l’elenco degli argomenti con scorrimento infinito stava aggiungendo nuovi argomenti, rendendo più difficile per il focus raggiungere effettivamente la finestra di dialogo. Non ricordo esattamente come sono riuscito a muovermi più velocemente della comparsa degli argomenti—non ho ancora preso il caffè—ma sono qui.
Quindi, alcune domande:
Vorrei davvero rimanere con Discourse se possibile. Quanto di tutto questo posso modificare sul mio sito? In particolare:
Posso eliminare i selettori dell’elenco delle categorie, in modo che gli utenti debbano interagire con il link dell’elenco delle categorie per ora?
Posso eliminare il selettore delle categorie nelle pagine per nuovi argomenti, in modo che gli utenti debbano prima inserire la categoria in cui vogliono pubblicare e non possano accidentalmente creare post senza categoria o confondersi?
Posso fare entrambe le cose in modo che l’aggiornamento sia semplice? Preferirei non modificare i template originali e fare un fork del progetto se non è necessario, né vorrei necessariamente un tema completamente nuovo.
Questo lavoro è tracciato da qualche parte e c’è qualcuno dedicato a occuparsene? I forum Discourse stanno mangiando internet. Ovunque mi volti, i progetti o le comunità in cui passo il mio tempo li stanno adottando. Dannazione, come utente non vedente, io voglio gestire Discourse perché, ancora una volta, lo rendete così semplice. Non voglio solo che l’accessibilità di uno strumento così cruciale sia un ripensamento o che debba perennemente correre dietro allo sviluppo di nuove funzionalità.
È un post molto attento, @nolan. Sono sicuro che altri membri del team risponderanno alle tue domande, ma potresti condividere la tua configurazione in modo che uno sviluppatore possa provare a riprodurre i problemi che stai riscontrando? Cioè, quale sistema operativo, quale lettore di schermo e così via.
Windows 10, screen reader NVDA. Tuttavia, per dirla con cautela, è così malfunzionante che probabilmente non funzionerà bene da nessuna parte; quindi, quasi ogni combinazione di sistema operativo e screen reader potrebbe riscontrare questo problema.
Grazie per il feedback! Sappiamo che non abbiamo ancora raggiunto l’obiettivo in termini di accessibilità e ci stiamo lavorando con più impegno recentemente. Alla fine del 2020 abbiamo commissionato un audit di accessibilità a una terza parte per le pagine non amministrative più importanti di Discourse e abbiamo iniziato a risolvere i problemi ad alta priorità nelle ultime settimane.
Ora che lo hai menzionato, capisco perché trovare il menu amministrativo possa essere difficile. Il link per il menu si trova all’interno di uno dei menu principali dell’intestazione… l’aria-label è “vai a un’altra lista di argomenti o categoria”… il che sicuramente non rende chiaro che ci sono alcuni link amministrativi all’interno.
Per quanto riguarda il messaggio che dice che Discourse ricorda dove ti sei fermato… il comportamento previsto è che, quando entri in un argomento, si salta direttamente al punto in cui avevi interrotto la lettura. Ho appena provato a navigare con la tastiera e posso confermare che il focus non viene posizionato nel punto corretto.
Molti dei nostri menu a tendina sono un’implementazione personalizzata, e questa è una delle aree che ci sono state indicate per il miglioramento dell’accessibilità. Siamo anche consapevoli del fatto che le nostre finestre modali non intrappolano il focus, il che rende difficile raggiungere certi contenuti, specialmente nelle pagine con scorrimento infinito come hai sperimentato tu.
Per quanto riguarda le tue domande sul rimanere su Discourse… tutto ciò che hai elencato è possibile; basterebbero poche righe di CSS per nascondere quegli elementi. Quel CSS dovrebbe essere inserito in un tema, ma potrebbe esistere all’interno di un componente del tema, che può essere aggiunto a qualsiasi tema esistente (quindi non dovresti cambiare il tuo tema principale). I temi sono molto migliori per il processo di aggiornamento, poiché si sovrappongono a Discourse… modificare i template o fare un fork, come hai menzionato, rende l’aggiornamento molto difficile.
Segniamo i report sui problemi di accessibilità qui su Meta con il tag accessibility in modo che siano più facili da trovare in un unico posto… detto questo, il rapporto di accessibilità della terza parte e il lavoro successivo che ho menzionato prima non sono tracciati pubblicamente.
Apprezziamo davvero il tuo feedback, soprattutto considerando che ci è voluto uno sforzo aggiuntivo per pubblicarlo. Speriamo che nel corso dei prossimi mesi Discourse diventi molto più facile da usare per te.
Ho ricevuto una domanda in una discussione su Fediverse da Robert Kingett, che ha una disabilità visiva e si definisce “accelerazionista dell’accessibilità” nel suo profilo. La domanda era:
Come rendete Social Hub accessibile ai lettori di schermo e ad altre persone con disabilità? Convulsioni, ecc.
Poiché SocialHub utilizza Discourse e la domanda riguardava problemi di accessibilità qui, ho offerto di copiare questo thread come documento Markdown in un Github Gist. Ecco quindi il link, che può essere utilizzato anche da altre persone con disabilità visiva: Accessibility: Discourse with a screen reader · GitHub
Inoltre, se non è già stato sollevato, vorrei segnalare questo come un modo per ottenere rapidamente alcuni vantaggi in termini di accessibilità:
I lettori di schermo sfruttano efficacemente molti dei tag semantici di HTML5. Non solo posso navigare tra di essi in modo efficiente, ma indicano anche il tipo di contenuto in cui mi trovo attualmente.
Sarebbe auspicabile che i post fossero contenuti in un elemento , con l’intestazione e il piè di pagina rispettivamente negli elementi e . Se la sostituzione degli elementi non è fattibile, l’uso appropriato degli attributi role trasmette lo stesso significato.
Attualmente è difficile leggere discussioni lunghe. Dopo il primo messaggio, devo scorrere la sezione con gli argomenti consigliati e altro. Poi leggo i messaggi successivi in modo lineare, senza possibilità di saltare le stesse intestazioni che ho sentito un milione di volte, identiche tranne per la data, o il piè di pagina con i controlli dei messaggi sempre uguali. Ci sono sicuramente modifiche avanzate ARIA che potrebbero migliorare ulteriormente la situazione, ma sostituire i tag o utilizzare i ruoli sarebbe una soluzione a basso sforzo con grandi benefici, a mio parere.
Ho ricevuto un aggiornamento nella nostra coda di revisione che aggiungerà alcuni elementi di markup ARIA alle pagine degli argomenti. Secondo le specifiche, sembra sensato contrassegnare i controlli sotto i post e nella parte inferiore della pagina con il ruolo toolbar.
Abbiamo anche un’area della barra degli strumenti della cronologia degli argomenti che funge da barra di scorrimento (le ho assegnato il ruolo scrollbar) e contiene anche i pulsanti “vai al primo post” e “vai all’ultimo post” (ai quali ho aggiunto delle descrizioni)…
Queste modifiche saranno disponibili con gli aggiornamenti di Discourse la prossima settimana.
Forse è scontato, ma lo dico lo stesso. Tieni presente che non basta semplicemente aggiungere ARIA a questi controlli e considerare la cosa conclusa. In altre parole, contrassegnare quelle aree come barre degli strumenti senza seguire il modello di toolbar è probabilmente peggio che omettere completamente il ruolo. Se mi trovo su una barra degli strumenti, mi aspetto che si comporti in modi che non deriva automaticamente dall’aggiunta del ruolo. Voglio solo essere chiaro su questo, dato che un errore comune che vedo quando si aggiunge l’accessibilità è l’aggiunta di questi ruoli senza includere i comportamenti da tastiera associati. In tal caso, mi trovo su un mucchio di controlli che non si comportano come mi aspetto, e lo sforzo costante nel gestire queste aspettative è peggio che non averle affatto.
Spero che abbia senso. Sono a disposizione per eventuali ulteriori domande.
Ciao Chris, il ruolo scrollbar potrebbe non essere esattamente ciò che desideri in questo caso. Dovremo vederlo in azione, ma finora non l’ho mai visto utilizzato in questo modo. È più simile a un elemento range in HTML5 che rappresenta una posizione di scorrimento relativa di un contenitore. Le voci “Vai al primo post” e “Vai all’ultimo post” sono semplici pulsanti che possono scorrere la vista, sì, ma non credo che questi pulsanti siano adatti come contenuto per un contenitore scrollbar, che è necessario per ottenere gli attributi aria-value*.
P.S. Nella community di VS Code sono noto come il guru dei ruoli ARIA. Non so esattamente cosa mi abbia fatto guadagnare questa reputazione, ma sono noto per essere molto esigente riguardo ai ruoli. Possono fare più danni che benefici, quindi questa modifica particolare potrebbe dover essere annullata. Sono quasi certo che accadrà.
Per pura curiosità, avete qualcuno nel team che si occupi di accessibilità? Sono entusiasta del recente audit sull’accessibilità e dei cambiamenti previsti, ma dato che Discourse alimenta una parte significativa di internet, sarebbe opportuno avere qualcuno con esperienza pratica che collabori e fornisca consulenza su questi cambiamenti. È estremamente facile commettere errori e, involontariamente, peggiorare le cose.
Ad esempio, Slack dichiara di dare priorità all’accessibilità e cerca di utilizzare ARIA, ma i loro tentativi sembrano aver reso l’area di chat completamente inaccessibile per il mio screen reader. O, se è accessibile, io con i miei decenni di esperienza non riesco a capire come funziona. Non vorrei vedere Discourse imboccare involontariamente quella strada.
Comunque, faccio questo e altro per lavoro e sono disponibile. Uso anche diversi forum basati su Discourse, quindi avere accesso garantito all’accessibilità rappresenterebbe per me un miglioramento tangibile della qualità della vita. Sono felice di parlare con chiunque sia interessato.
@MarcoZehe per il controllo della nostra timeline, ero un po’ indeciso se optare per il ruolo di barra di scorrimento o quello di cursore. Ho scelto il ruolo di barra di scorrimento perché il controllo effettivamente scorre la pagina e sembra corrispondere alla descrizione fornita dal W3C:
Un oggetto grafico che controlla lo scorrimento del contenuto all’interno di un’area di visualizzazione, indipendentemente dal fatto che il contenuto sia completamente visualizzato nell’area.
Detto questo, si tratta di un controllo piuttosto unico che abbiamo realizzato… scorre sia la pagina sia indica la tua posizione all’interno dell’intervallo corrente di post (ad esempio, mostra che ti trovi attualmente sul post 6 di 12). È possibile che non esista un modo ottimale per strutturarlo per gli screen reader e che sia meglio nasconderlo… poiché lo scorrimento normale della pagina funziona come previsto senza di esso. Vorrei provarlo e vedere cosa ne pensi in azione; se non funziona, possiamo tornare indietro.
Per rispondere alla tua domanda @nolan, ho assunto la responsabilità di organizzare le raccomandazioni sull’accessibilità e di far completare l’audit, ma la maggior parte della mia precedente esperienza in materia di accessibilità deriva dall’implementazione di specifiche definite da altri. Non abbiamo un esperto dedicato che lavori full-time sull’accessibilità, dato che siamo ancora diversi ordini di grandezza più piccoli di Slack… ma potrebbe essere necessario ingaggiare qualcuno per lavorare su questo aspetto nel frattempo, in modo da farlo bene e non peggiorare le cose…
Grazie a entrambi per le vostre risposte, le apprezzo davvero!
Facendo seguito al ruolo della barra degli strumenti, per chiarire… stai dicendo che il ruolo non ha alcun valore a meno che non segua questo modello come descritto dal W3C?
Implementa la gestione del focus in modo che la sequenza di tabulazione della tastiera includa un punto di arresto per la barra degli strumenti e i tasti freccia spostino il focus tra i controlli nella barra degli strumenti.
Se è così, allora non implementerò il ruolo finché non riusciremo a gestire correttamente il focus e i controlli con i tasti freccia.
Corretto: se usi il ruolo, prometti che implementerai anche il pattern di progettazione. Se non sei ancora pronto a fornire il pattern di progettazione, non usare ancora il roller.
Questo è il luogo appropriato per segnalare i risultati del mio audit di accessibilità su un’istanza di Discourse ospitata, o dovrei aprire un nuovo thread?
E:
il rapporto di accessibilità di terze parti e il lavoro successivo che ho menzionato in precedenza non sono tracciati pubblicamente.
C’è la possibilità che questa decisione possa essere riesaminata? Sarebbe utile avere una certa trasparenza su questo argomento che potrei condividere con i miei clienti.
Per evitare che qualcosa vada perso, ti consiglio di creare un nuovo argomento ux (contrassegnato con accessibility) per ogni risultato del tuo audit. Se i risultati sono strettamente correlati, potrebbe avere senso utilizzare lo stesso argomento per ciascuno. In sostanza, vogliamo raggruppare le cose in piccoli blocchi che possano essere tracciati in modo indipendente e segnati come “completati”, senza doversi preoccupare di aver perso un elemento da un elenco di 53 nel messaggio originale.
Utilizzare il ruolo senza implementare il pattern sarebbe un po’ come stilizzare un elemento per farlo sembrare un pulsante, per poi farlo rispondere solo se qualcuno passa il mouse sopra e scorre la rotellina del mouse. Se mi sposto con il tasto Tab o metto a fuoco una barra degli strumenti, e questa espone tutti i suoi pulsanti separatamente o non risponde alle frecce, allora sembra proprio quel bizzarro pulsante della rotellina del mouse. Dovresti pensare prima di ogni singola interazione, e il fatto che si comporti in modi in cui in realtà non lo fa è fuorviante.
Spero che questo chiarisca un po’ le cose. Sapere che qualcosa è una barra degli strumenti ha valore solo se si comporta come una barra degli strumenti. Altrimenti è solo di distrazione.
Ahimè, che delusione. Sono venuto qui per chiedere lo stato di tutti questi aggiornamenti che sembravano in corso quando ho pubblicato questo messaggio. Non ho ancora lanciato la nostra community, ma il vecchio forum PHP sta per essere dismesso, quindi è adesso o mai più. Pensavo che ci sarebbero stati dei cambiamenti straordinari fino ad ora.
Ma non sono riuscito a capire come raggiungere l’area di amministrazione del mio sito. Posso certamente accedere a /admin, ma il link al sito non è ancora accessibile tramite tastiera in alcun modo che abbia trovato. Questo rende tutto un po’ complicato quando chiedo agli utenti che utilizzano screen reader di aiutarmi nella moderazione.
Poi ho provato a scrivere questa risposta 5 minuti fa, ma per qualche motivo ho cliccato sul pulsante Modifica o Citazione. Mi ha portato a una versione modificabile di un messaggio precedente che avevo inviato. Ho provato a premere Invio su un link etichettato Annulla, ma non ha funzionato. Nemmeno ricaricare la pagina ha aiutato. Alla fine ho inviato la risposta, poi ho trovato e interagito con una finestra modale inaccessibile, simile a quella che ho segnalato inizialmente qui, per scartare il messaggio.
Qualcosa è cambiato in questo senso, o esiste già una roadmap pubblica? Come utente di screen reader che deve interagire con le community Discourse indipendentemente dal fatto che lo voglia o meno, posso farcela funzionare per me, ma non mi sento molto a mio agio nel chiedere a una community di persone non vedenti di usare questa piattaforma—o, almeno, nel chiedere loro di costruire una community che apprezzerebbero su Discourse.
Purtroppo è apparso un modale che chiedeva cosa volevi fare con la tua bozza (scartare/salvare/annullare), e sembra che la cattura del focus del modale sia rotta…
Discourse funziona per me, ma mi piacerebbe senz’altro vedere alcuni miglioramenti in termini di accessibilità. È passato un po’ di tempo dall’ultima volta che ho usato l’interfaccia di amministrazione o amministrato un forum Discourse, ma mi aspetterei di vedere molti progressi in tre mesi.
Capisco che ARIA possa essere impegnativo, ma questo non significa affatto che non si possano fare progressi. @nolan ho avuto lo stesso problema in passato — mi è voluto un po’ di tempo per capire perché la casella di modifica non fosse scomparsa dopo aver cliccato su ‘Annulla’. Mi farebbe davvero piacere usare Discourse come forum per la mia comunità in un futuro prossimo, ma potrei doverci ripensare se non verranno apportati miglioramenti all’accessibilità. E oderei dover tornare a PHP.
Voi praticamente avete qualcuno che si offre di aiutarvi con l’accessibilità. Scusate se sembro impaziente — so che è una cosa difficile e complicata per voi. Ma sia @nolan che io siamo assolutamente disposti a dare una mano, in ogni caso. Sarei felice di configurare un’istanza di test di Discourse.
