Feedback
Toast-notifikationer
En toast er en lille, ikke-modal besked, der dukker kortvarigt op — typisk i et hjørne eller nederst — for at bekræfte en handling og så forsvinder af sig selv. Den er god til passive bekræftelser, men et dårligt sted til noget vigtigt. Her er, hvornår den passer, og hvordan den gøres tilgængelig.
Definition
En toast er en lille besked, der dukker op kortvarigt og forsvinder af sig selv — typisk til bekræftelser.
Hvorfor det virker
En toast bekræfter systemstatus uden at afbryde: brugeren ved, at systemet reagerede. Det er kernen i Nielsens heuristik #1, synlighed af systemstatus.2
Fordi den er ikke-modal og forsvinder af sig selv, egner den sig til passive notifikationer, der ikke kræver handling — men netop derfor bør den kun bruges til lav-prioritets, ikke-kritisk information.6
Den kan gøres tilgængelig for skærmlæsere ved at injicere indholdet i et live-område (role="status", som er polite), så den annonceres uden at flytte fokus.3
Hvornår du bruger det — og hvornår ikke
Hvornår du bruger det
- Du skal kvittere for en handling uden at afbryde flowet.
- Beskeden er ikke kritisk og kræver ikke handling.
- Der kan tilbydes en fortryd-knap i toasten.
Hvornår du bør undgå det
- Beskeden er kritisk og skal bekræftes aktivt.
- Indholdet er for langt til at nå at læse, før det forsvinder.
Best practices
Brug kun toasts til ikke-kritiske bekræftelser
Passive, ikke-hastende beskeder egner sig (»Kladde gemt«). Kritisk info og fejl gør ikke — NN/g kalder en toast en dårlig måde at vise en fejlbesked på.1
Auto-forsvind aldrig kritisk information
Er indholdet vigtigt, skal det blive, til brugeren aktivt lukker det — ellers går det tabt.5
Giv nok tid til at læse
Auto-forsvindende indhold indfører en tidsgrænse; WCAG 2.2.1 (niveau A) kræver, at tidsgrænser kan slås fra, justeres eller forlænges.4
Tilbyd fortryd, hvor det giver mening
En toast kan rumme højst én handling — en »Fortryd« er et oplagt valg.6
Gør den tilgængelig via en live region
Brug role="status" (polite) til ikke-hastende bekræftelser, så skærmlæsere annoncerer dem uden at flytte fokus. Reservér role="alert" (assertive) til faktiske fejl.3
Stak ikke mange toasts
Vis kun én ad gangen — hyppige alerts skaber barrierer for brugere med syns- og kognitive udfordringer.6
Overvej et alternativ ved vigtig info
Er informationen vigtig, så brug et banner (vedvarende), en dialog (kræver handling) eller inline-validering i stedet for en toast.5
Typiske fejl
At auto-forsvinde vigtig info eller fejl
NN/g’s eksempel: en bruger ventede unødigt, fordi en fejlbesked forsvandt efter få sekunder. Fejl hører ikke i en toast.
For kort visningstid
Forsvinder toasten, før brugeren kan læse den, indføres en ikke-justerbar tidsgrænse i strid med WCAG 2.2.1.
Utilgængelig implementering
En toast uden live-område annonceres ikke af skærmlæsere; knapper i den skal desuden være tastaturbetjenbare.
Overforbrug og stabling
Mange samtidige eller hyppige toasts afbryder og overvælder.
Eksempler i praksis
GitHub Primer (fraråder toasts)
GitHubs designsystem skriver ligefrem, at toasts udgør betydelige tilgængelighedsbekymringer og ikke anbefales — de peger på banners, dialoger og inline-validering i stedet.
Material Design (snackbar)
Googles designsystem definerer mønstret som kortvarige, ikke-afbrydende opdateringer med højst én handling, kun én ad gangen, til lav-prioritets info.
Ofte stillede spørgsmål
Hvad er en toast-notifikation?
En lille, ikke-modal besked, der dukker kortvarigt op — typisk i et hjørne eller nederst — for at bekræfte en handling og så forsvinder af sig selv, uden at afbryde det, du er i gang med.
Hvornår bør jeg bruge en toast?
Til passive, ikke-kritiske bekræftelser som »Kladde gemt« eller »Besked sendt«, hvor brugeren ikke behøver at gøre noget.
Kan jeg vise fejlbeskeder i en toast?
Nej. NN/g fraråder det direkte — en toast er en dårlig måde at vise en fejlbesked på. Brug i stedet inline-validering, et banner eller en dialog.
Er toasts et problem for tilgængelighed?
De kan være det. Forsvinder de for hurtigt, kan de bryde WCAG 2.2.1 (Timing Adjustable, niveau A), og uden et live-område (role="status") bliver de ikke annonceret af skærmlæsere.
Hvor længe bør en toast være synlig?
Længe nok til, at man kan nå at læse den, og tidsgrænsen bør kunne forlænges eller slås fra. Er indholdet vigtigt, bør toasten blive, til brugeren selv lukker den.
Hvad er forskellen på role="status" og role="alert"?
role="status" er en polite live region til ikke-hastende beskeder og afbryder ikke skærmlæseren; role="alert" (assertive) annonceres straks — brug den kun til vigtige eller hastende beskeder som fejl.
Kilder
Relaterede mønstre
Udforsk videre
Optimistisk UI
Vis resultatet med det samme og rul tilbage ved fejl.
Se mønster →Fortryd-handling
Tilbyd undo i stedet for en bekræftelses-dialog.
Se mønster →Mikrointeraktioner & animation
Små, afgrænsede animationer der bekræfter en handling, viser en tilstandsændring og hjælper brugeren med at orientere sig — funktionelt, ikke dekorativt.
Se mønster →