Ci proverò più tardi, tuttavia questa non è la soluzione poiché non stai eseguendo i passaggi che farebbe un lettore di schermo reale. Dato che mi sposto su un post specifico, si può presumere che io voglia leggere quel post. Tab non è un comando di lettura ma un modo per spostare il focus sull’elemento successivo che può acquisire il focus. Un comando di lettura sarebbe l’uso dei tasti freccia giù o il comando SayAll specifico per il lettore di schermo. Almeno la freccia giù, che è il mio comando di lettura preferito, fallisce, il focus non è affatto dove è visivamente ma di solito prima dell’elenco dei post.
Naturalmente, tab potrebbe essere il modo “sporco” per risolvere questo bug, ma non la soluzione del bug stesso.
Grazie @thoeg@nolan, molto apprezzato. Penso di aver capito qual è il problema. Attualmente stiamo utilizzando un elemento span vuoto per impostare il focus sul post. Questo elemento ha sia aria-hidden=true che tabindex=-1, e penso che questo renda l’elemento invisibile agli screen reader.
Penso che sarebbe meglio spostare il focus sul primo elemento focalizzabile nel post. Nella maggior parte dei casi si tratterà del link del nome utente, ovvero dell’autore del post.
Ha senso. Ariahidden dovrebbe nascondere l’elemento e -1 impedirgli di ottenere lo stato attivo. Se questo elemento acquisisse lo stato attivo sull’intestazione dell’oggetto, andrebbe bene. Sarebbe interessante vedere cosa succede se impostassi solo tabindex=0,
Sì, ti sento @anni_anni, risolveremo questo problema. Ho provato un primo tentativo la settimana scorsa, ma ho dovuto annullarlo perché aveva alcuni effetti collaterali indesiderati. Proverò con un approccio diverso molto presto.
Ok, finalmente un altro tentativo di correzione per questo è stato unito. L’implementazione attuale consiste nell’impostare il focus sul primo elemento focalizzabile in un post, che, nella maggior parte dei casi, sarà il nome utente dell’autore del post. Quando si naviga verso un post e si preme Tab, dovrebbe apparire così in Chrome:
Vedo ancora il vecchio comportamento errato su Meta e community.fly.io con Chrome, ma posso confermare che la correzione funziona sul nostro sito discourse.team. Stanno eseguendo versioni diverse di Discourse? Sto usando la stessa versione di Chrome con lo stesso profilo.
Hmm, tutti e tre i siti potrebbero essere in versioni leggermente diverse di Discourse, ma credo che tutti abbiano la modifica collegata sopra. Meta, in particolare, è sempre aggiornata con le ultime modifiche nel nostro ramo tests-passed, quindi sono un po’ preoccupato che questo non funzioni qui…
OK, ho qualche informazione in più per te su questo, osservato sul nostro sito discourse.team dove ho segnalato che funzionava.
Se clicco su un post nuovo di zecca che non ho mai letto, non ricevo alcun feedback vocale e l’attenzione sembra cadere casualmente su quella che presumo essere la prima pagina dei post.
Se clicco su un argomento visitato in precedenza, l’attenzione si posiziona correttamente e ricevo feedback vocale.
Questo comportamento sembra ora coerente tra Firefox e Chrome. Penso che prima Firefox posizionasse correttamente l’attenzione sul primo post quando si visualizzava un nuovo thread. Sarebbe bello riavere quel comportamento, se possibile, in modo che le esperienze di prima lettura e di ritorno siano le stesse. Sono contento che almeno ripristini la mia ultima posizione di lettura in Chrome ora, dato che è necessario per il lavoro.
È strano che questi comportamenti fossero così diversi tra Firefox e Chrome.
Sono felice di sentirlo! Ho effettivamente limitato le modifiche qui alla navigazione verso post che non sono il primo post di un argomento. Per gli utenti abituali, si tratterà spesso di navigare verso argomenti che hai già letto ma che ora hanno nuove risposte.
Questo è utile da sapere, penso che abbiamo una strada per iterare e risolvere questo problema. Se puoi condividere l’esatto ordine dei comandi che utilizzi, sarebbe anche d’aiuto.
Sul mio normale browser Chrome, se vado a un nuovo argomento che non ho letto e premo Tab, l’attenzione atterra sul titolo dell’argomento, il che mi sembra ragionevole, ma probabilmente non è sufficiente per il tuo caso d’uso.
Grazie ancora per il tuo continuo feedback, molto apprezzato!
Questo è strano con Jaws e Chrome e testando su un nuovo argomento su meta, ho visto un nuovo comportamento da Jaws. Dopo aver premuto Invio sul titolo dell’argomento, ottengo le solite informazioni sulla pagina appena caricata, comportamento standard di Jaws. Lo stesso accadrà quando tornerò all’elenco degli argomenti e premerò Invio sullo stesso argomento, il focus verrà semplicemente posto sull’ultimo post letto. Questo sembra aver risolto almeno 2 problemi qui. Non ho testato “vai all’ultimo post” nell’elenco degli argomenti, ma immagino che funzionerà.
Tuttavia, ovviamente non tutto va bene, ma questo potrebbe non essere correlato affatto. Quando uso il pulsante Indietro per tornare all’elenco degli argomenti, il focus viene perso, non vengo riportato all’argomento che ho aperto e stavo leggendo. Questo potrebbe essere un bug di Jaws/Chrome, ne abbiamo visti di simili in passato, ma potrebbe anche dipendere da voi. Dovrò verificare con NVDA.
Ho appena provato con NVDA e Chrome e qui non funziona nulla, cioè non posso più semplicemente premere Invio su nessuno dei titoli degli argomenti nella tabella. Sono sicuro che questo funzionasse. Ovviamente, dato che sono un utente JAWS, questo non mi disturberà, ma per gli utenti NVDA è un’altra storia.
Dato che NVDA non ha funzionato davvero, non posso testare il problema con il focus quando si torna da un argomento all’elenco degli argomenti.
JAWS è tuttavia affidabile qui, il focus è posizionato in cima alla pagina.
Nell’ultima versione di Chrome sul nostro sito discourse.team, fare clic su un argomento visitato in precedenza mi riporta a dove ho interrotto la lettura e NVDA annuncia correttamente l’intestazione del post in focus.
Sfortunatamente, fare clic su un nuovo argomento non sposta il focus sul primo post dell’argomento. Allo stesso modo, usare “h” per tentare di spostare il focus sul primo post non funziona. Devo trovarlo manualmente per iniziare a leggere.
Si noti che la posizione sembra essere impostata correttamente nei nuovi post su Firefox. Sembra che sia solo Chrome per qualche motivo.
Tutto sommato, sono contento che la posizione venga ripristinata nei thread precedenti, poiché questo è il mio più grande problema. Spero comunque che otterremo un comportamento coerente e corretto in entrambi i casi d’uso.
Anche questo è corretto. L’implementazione attuale salta specificamente l’impostazione del focus se il post di destinazione è il primo post. Ho provato ad aggiungere la stessa cosa al primo post, ma spesso si traduceva in uno scorrimento non necessario durante il caricamento di un URL di argomento ed era troppo dirompente per tutti gli utenti.
Questo dovrebbe funzionare. Farò alcuni test e vedremo se riusciamo a risolvere questo problema.
Volevo segnalare un altro “papercut” che mi infastidisce da un po’.
Quando si pubblica un nuovo argomento, il menu a discesa per aggiungere tag/categorie è un po’ strano. Innanzitutto, l’etichetta per me è “Filtra per”. Non so se sia visualizzato o meno, ma ci sono voluti letteralmente anni di pubblicazione su Discourse prima che mi rendessi conto che è così che si aggiungevano i tag. L’uso di “Filtra” per me implica qualcosa come “filtrare qualcosa dall’acqua”, non aggiungere una nuova cosa. Se questo viene visualizzato visivamente, allora fai quello che ritieni opportuno con quel feedback, ma se è solo ARIA, potrebbe beneficiare di qualche aggiustamento.
Successivamente, facendo clic sull’elenco dei tag mi compaiono quelli che sembrano pulsanti di opzione. Se premo Spazio su questi (cioè secondo il modello radio group ARIA), questo sembra attivare una ricerca. Sì, posso premere Invio qui invece, ma sono abituato a premere Spazio per attivare le interazioni dei pulsanti perché i miei pollici sono proprio lì.
Certamente non è un blocco, ma è decisamente più difficile da scoprire e devo pensare di più per ricordare/capire di nuovo come funziona ogni volta che faccio un post. Storicamente ho fatto clic su singole categorie, ma ciò ha limitato la mia capacità di utilizzare più tag.
Penso che un adattamento migliore per questa interazione potrebbe essere il modello combobox ARIA. Nello specifico, il combobox modificabile si comporta in modo molto meno confuso. Se digito “A”, posso spostarmi con le frecce fino ad “Alabama”. Non è presentato come un pulsante di opzione, quindi la mia risposta automatica non è quella di premere Spazio lì, ma se lo faccio, inserisce lo spazio come previsto. Potrebbe essere sufficiente rimuovere la presentazione del pulsante di opzione, ma probabilmente potrebbe anche essere meno prolisso sui conteggi dei risultati.
Grazie, Nolan. Questo è molto utile, abbiamo alcune cose da fare internamente per risolvere questi menu a discesa, mi assicurerò di includere il tuo feedback lì.
Se digito un emoji nella casella di modifica del post (ad esempio :)) e il focus si sposta su quell’emoji durante la modifica, non posso usare le frecce su/giù per passare alla riga precedente o successiva. Devo prima spostarmi a sinistra/destra fuori dall’emoji.
Indovino che questo sia dovuto al comportamento di completamento automatico? Mi chiedo se questo comportamento possa essere disabilitato sia nei casi in cui c’è una sola corrispondenza, sia a meno che non venga premuto Invio o un altro tasto? Capirei il comportamento di completamento automatico per l’inserimento iniziale e le modifiche, ma è stato decisamente complicato cercare di capire perché non riesco a spostare il focus in alcuni casi e questo sembra essere il motivo. Una sorta di menu a discesa attivato manualmente per le modifiche sembra la scelta giusta qui.
