form-fields: After a first failed submission, if user submits again before resolving all errors, no live announcement gets made
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- javascript
- Ambito
- accessibility, frontend
Direzione di ricerca
Inizia dalla demo dei campi del modulo all’indirizzo https://bbc.github.io/gel/components/demos/form-fields/ e riproduci il problema usando macOS Safari e VoiceOver. Esamina il comportamento della live-region del modulo dopo una correzione incompleta e ripetuti tentativi di Submit; il lavoro è completato quando l’annuncio dell’errore viene effettuato nuovamente a ogni invio pertinente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
How to reproduce
- Go to https://bbc.github.io/gel/components/demos/form-fields/
- Turn on screen reader
- Activate the 'Submit' button (without filling in any of the fields)
- Correct one of the errors (but not all of them)
- Activate the 'Submit' button again
Expected behaviour
I expected the "Error: Please fix the errors in the form before continuing" live announcement to be made again.
Actual behaviour
No live announcement happens.
Tested in
macOS 10.15.5 Safari + VoiceOver
Likely cause
If the user doesn't correct all the errors, the content of the live region is unchanged.
So no new live announcement gets made when the user attempts Submit again.
Why that's a UX issue
We can't assume that a user would solve all errors before attempting submission again.
Potential solutions
Option A: Empty the content of the live region when users press 'Submit', before populating it again if there's an error
Example: https://www.kooth.com/login
(Note: I realise that this example has other problems – e.g. HTML5 validation when fields are empty).
Downsides of Option A
- Small layout shift
- I imagine that the live region will need to stay empty for some time (I think it's 100ms, if I remember well from the DequeUniversity courses, but it might be longer).
Other ideas
There are probably other ways to solve this issue.
Note
I've taking the time to report and think of solutions, because I like your work and I'd need to figure out a way to solve that issue as I implement that pattern on kooth.com too.
- Lingua principale
- JavaScript
- Stelle
- 50
- Fork
- 19
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di bbc/gel
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 38/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 52/100
-
Information panels - WCAG 2.1 2. Keyboard TrapForse di nuovo libera @mathalete l’ha presa 997 giorni fa e non c’è nessuna pull request aperta. Aperta
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
pedroapfilho/localveil#120 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
ImpactMojo/ImpactMojo#1385 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno