Closed OAMPfed closed 1 month ago
Her er jeg litt usikker siden jeg ikke har masse erfaring med skjermlesere men jeg observerer samme oppførsel på demoen til a11y-dialog.
Det er mange forskjellige strategier man kan bruke for å velge hvor fokus skal lande når en dialog åpnes, men med begrenset kjennskap til innholdet kan vi ikke bli så veldig fancy for denne komponenten. Fokus settes på selve modalen (dette er defaulten for a11y-dialog) og man må med VoiceOver da bruke Ctrl+Option+Shift+Pil ned for å navigere inn i regionen.
I userland kan dette overstyres med feks autofocus
eller programmatisk med en eventhandler på instance
objektet man får ut av hooken (instance.on("show", () => myRef.current.focus()
). Jeg tror muligens det er det beste vi får til.
Etter å ha testet litt mer med skjermleser er jeg enig i at dette virker som forventet oppførsel. Hvis det er mulig for bruker av komponenten å sette autofocus
på elementene som bygger opp modalen tror jeg det er en god løsning. Men vi bør sikkert vurdere å dokumentere at man bør tenke på fokushåndtering i modaler ut fra bruk.
Når en åpner en modal (bruk gjerne komponenten her), så kan en fortsatt bruke spacebar for å navigere opp og ned en side, samtidig som tradisjonell CTRL + Option navigering ikke evner å bevege seg inn i modalen (tabbing fungerer og setter fokus på modalen slik at modalen må håndteres før en kommer tilbake til siden).
Steg for å gjenskape
Forventet oppførsel
Forventet å få navigert inne i modal på tradisjonelt vis med tastatur.