Error message: Brukerutløste feil

[Febakke]

Feilmeldinger er en viktig, men ofte oversett del av løsningene våre. Hvor ofte har vi ikke vært på en nettside hvor noe har gått galt og vi får ingen hjelp til hvordan komme oss videre. Feilmeldinger kommer i flere ulike former. Som egne nettsider med feilmelding, i en modal, som en statusmelding/alert/toast eller som en validering i skjema. Dette mønsteret skal ta for seg når de forskjellige metodene kan brukes, hvordan man henvender seg til brukeren (språk) og hvordan man konsistent kan gi brukeren veiledning enten til å løse problemet selv der det er mulig eller hvor de kan henvende seg for hjelp.

Første oppgave blir å definere scope for Error messages. Jeg har inkludert alle aspekter jeg kom på her, om noe mangler gjerne legg igjen en kommentar under her.

Relevante områder

Feilmeldinger i skjema

Feilmeldinger er en viktig del av det å bygge gode skjema. Når feilmeldinger skal vises, hva de skal inneholde og hvordan de oppsummeres er relevante aspekter av hvordan lage gode feilmeldinger.

Relevant innsikt:
Kryptiske feilmeldinger

Universell utforming
WCAG: 3.3.3 Forslag ved feil
WCAG: 3.3.1 Identifikasjon av feil
WCAG 2.2: Consistent help (Ikke en del av norsk lov enda)

Annet
Skatteetaten: Feilmeldinger
Gov.uk: Help users to recover from validation errors
designsystem.arbetsformedlingen.se: Validering i formular
NAV Aksel: Skjemavalidering og feilmeldinger
Designsystemet: feilmeldinger

[Ildest]

Ta med denne lenkensom grunnlag også @Febakke? Siden informasjonen er relativt ny: https://storefront-pr-1614.dev.designsystemet.no/monstre/feilmeldinger

[Febakke]

Takk 👍 Har lagt til link til i listen. Linken du sendte er et midlertidig bygg tror jeg. Riktig link er her: https://www.designsystemet.no/monstre/obligatoriske-og-valgfrie-felt

[solhell]

Noen tanker rundt oppsummering av feil.

• Den bør stå øverst i skjemaet, og etter feilet forsøk på innsending plasser både visuelt og semantisk fokus på denne oppsummeringen. Da slipper brukeren å "rygge" i grensesnittet for å korrigere.
• Oppsummeringen må ikke nødvendigvis fortelle alle detaljer, det er normalt sett nok at oppsummeringen forteller hvilke felt / grupper som må korrigeres, og så kan detaljene spares til den lokale feilbeskrivelsen ved feltet / gruppen.

[Febakke]

Ja, det er et godt argument for å ha oppsummering på toppen. I Altinn hadde vi oppsummering på toppen, men vi hadde utfordring med at løsningen var en single page application hvor flytting av fokus opplevdes voldsomt for mange da siden ikke ble lastet inn på nytt når man trykket "neste". For store skjema var det ekstremt. På bakgrunn av tilbakemeldinger endte vi opp med å flytte oppsummering til bunnen av skjema for unngå dette. Det begynner å bli noen år siden så finnes forhåpentligvis nye måter å løse det på hvor ikke fokus blir flyttet opp, men at det heller oppleves som siden lastes inn på nytt.

[eivindland]

Vi i Skatt har nylig lagt ut et mønster for feilmeldinger: https://www.skatteetaten.no/stilogtone/designsystemet/monstre/feilmeldinger/

[astroeline]

Jeg er nysgjerrig på hvorfor dere har valgt å legge "store" feil som at tjenesten er utilgjengelig inn i en modal. Kan du forklare bakgrunnen for det? Og hvorfor dere har valgt å gjøre det sånn kontra å ha det på en egen side uten modal?

[eivindland]

Hos oss er mange av løsningene som bruker designsystemet innloggede tjenester - og typisk litt avanserte single-page-applications. Da tenker vi at slike «store» feil kan oppstå underveis/dynamisk, og da gir det mening for oss å vise dem i modaler - slik at skjermlesere enklere kan fange opp meldingen + at vi på en måte tvinger brukeren til å aktivt ta stilling til innholdet i meldingen.

Dette skiller seg litt fra feks. "404: siden kke funnet". Slike feil pleier vi ikke å anbefale at ligger i en modal, men heller «rett på siden» slik at header og footer fortsatt er tilgjengelig. Innser samtidig at at dette ikke kommer så godt frem i mønsteret - så det kan vi helt sikkert gjøre tydeligere!

[astroeline]

Hos oss har vi også behov for feilmeldinger på gruppevalidering av inputfelter. Her er en foreløpig skisse på det:

[Febakke]

Fin løsning 🙌 Absolutt noe vi burde se på i sammenheng med dette mønsteret.
Vi hadde en relatert diskusjon på noe lignende tidligere. Ligger her: Altinn/app-frontend-react#912

[solhell]

Ref kommentar lenger ned, her er det enda viktigere at feilmeldingen står øverst i gruppen, slik at brukeren slipper å scanne forbi alle for å skjønne hva som er feil.
Feilmeldingen bør også være mer presis: hvilke felt er det som må fylles ut? Formuleringen i eksempelet støtter bare de som kan ta til seg visuell informasjon.

[Febakke]

@solhell
Vi har noen edgecaser hvor vi ikke nødvendigvis vet hvor feilen ligger. Dette skjer når en validering må gå på tvers av flere felter. Hvis vi ser bort fra plasseringen av feilmeldingen i eksempelet over. Har du noen gode tips til hvordan formulere en slik feilmelding på en god måte som gjør det tydelig at minst et av en gruppe felter må fylles ut. Vil det hjelpe om alle feltene er i samme fieldset? Burde man refere til alle ledetekstene i feilmeldingen?

Jeg tror i mange av disse edgecasene man først burde ta en runde på om skjema kan løses/vises på en annen måte for å unngå kompliserte feilmeldinger som går over flere felter. Men av erfaring så er det ikke alltid det går av ulike grunner. Jeg tror det kunne hjulpet disse casene om vi hadde med noen eksempler på hvordan gjøre det på best mulig måte.

[Camulos]

Elmer 4.3 handler om feilmeldinger:

4.3 Feil i besvarelse Ved feil i besvarelser skal feilmelding komme så raskt som mulig, men ikke før feltet forlates. Det aktuelle svarfeltet skal markeres, og brukeren skal få hjelp til å løse problemet. Brukeren skal ha adgang til å gå videre uten å rette feilen, der det er mulig. Hvis en feil skyldes kryssvalidering mellom felter skal dette forklares, begge felter skal merkes, og hvis feilen ligger på ulike skjemasider skal det lenkes til det andre feltet. I skjema som er lange, eller har flere trinn, skal feil som gjenstår på slutten vises som en liste med lenker til aktuelle felt.

Vi har hos oss (Brønnøysundregistrene) kombinerte essensen i WCAG 2.1 3.3.1 og 3.3.3 og Elmer kravet til dette:
Ved feil markeres det aktuelle feltet eller spørsmålet så snart som mulig, men ikke før feltet forlates. Brukeren får hjelp til å løse problemer som kan løses. Det gis en tekstlig beskrivelse av feilen og foreslått løsning. Brukeren kan gå videre uten å rette feilen, hvis det er mulig. Ved feil grunnet kryssvalidering mellom felter er dette tydelig forklart og merket.

og vi har supplert med et tilleggskrav som er formulert slik:
I skjema som er lange, eller har flere trinn, vises det på slutten en liste over gjenstående feil med lenker til aktuelle felt.

[Febakke]

Supert! 👏

Ved feil markeres det aktuelle feltet eller spørsmålet så snart som mulig, men ikke før feltet forlates.

Tror vi kan få til en litt tydeligere formulering på dette. Om man validerer når bruker forlater feltet kan det fort bli kaotisk. Spesielt om man bruker tastatur for å navigere seg. Man må i det minste legge inn en regel at man ikke validerer om det ikke er skrevet noe enda.

Generelt tror jeg det er bedre å kjøre validering på brukers "initativ". Når man er klar for å gå videre. Men det er selvfølgelig mange unntak her.

[mrosvik]

I dag (10.04.24) hadde vi første møte i arbeidsgruppen for feilmeldinger. I arbeidsgruppen deltar Digdir, Nav, Skatteetaten, Politiet, Brønnøysundregistrene og KS.

Vi ble enige om at scopet for denne runden blir "Brukerutløste feilmeldinger i selvbetjeningsløsninger".

Vi deler opp feilmelding-mønsteret i 2 deler:

1. Brukerutløste feilmeldinger i selvbetjeningsløsninger.
   • Veilede brukere i forkant for å hindre at feil oppstår
   • Veilede brukere når feil likevel har oppstått
2. Systemfeil (Inngår ikke i denne runden)

Vi vil jobbe videre fremover mot neste møte med å skaffe innsikt fra egen organisasjon rundt dette mønsteret. Neste arbeidsmøte (30.april) vil vi sammenlikne de ulike tilnærmingene vi i dag bruker, identifisere hva som er ulikt, vurdere innsikten og forsøke å velge en felles tilnærming.

Det vi allerede identifiserte som ulikt er at noen kun bruker farge og tekst for å indikere feil, mens andre i tillegg bruker ikon og uthevet panel. Det er også ulikt hvor og hvordan vi oppsummerer flere feil.

Vi vil gjerne at andre som ikke er med i arbeidsgruppen også deler innsikt og påvirker arbeidet. Det kan du gjøre ved å legge inn dine tanker, forslag, erfaringer og innsikt i denne tråden.

PS. Om jeg har glemt noe i denne oppsummeringen, fyll gjerne på!

[frikkfelix]

Hei! Vi har i flere tilfeller regler som utløser advarsler, hvor det er ønskelig at bruker får tilbakemelding på at noe kanskje ikke er som det skal. Dette er dog feil som ikke skal hindre bruker i å gå videre.

Kunne det vært en idé å legge inn støtte for denne typen advarsler, for eksempel med gul border or hjelpetekst?

[solhell]

Et innspill på det med feilmeldinger i skjema. Med tanke på universell utforming bør feilmeldinger stå mellom ledetekst og det aktuelle feltet / gruppen, og ikke under feltet / gruppen.

Dette er særlig relevant for brukere med tunnelsyn eller som benytter forstørring på operativsystemnivå. De mest alvorlig rammede her ser kanskje bare én til to linjehøyder om gangen.

Med dagens løsning der feilmeldingene står under det aktuelle feltet/gruppen, må disse brukerne scanne forbi feltet for å finne hva som er feil, og deretter opp igjen for å rette feilen.

Det er også relevant med tanke på kognisjon - å plassere feilmeldingen under medfører risiko for at brukerne kan bli i tvil om varselet handler om det som står over eller under feilmeldingen.

Det handler også om logisk rekkefølge - først lese hva som skal fylles ut, deretter en tydeliggjøring av hva som mangler / er feil, og deretter rette opp. Når det er blitt feil, er det jo tydelig at brukeren ikke har fanget opp hva som kreves gjennom ledeteksten alene, så hen bør presenteres med ytterligere informasjon før hen kommer til utfyllingen.

Dette er utenfor WCAG-nivå, men en anbefaling som jeg håper dere kan ta til vurdering.

[Camulos]

Det kan være uheldig å plassere ny informasjon (i dette tilfellet feilmelding) tidligere i flyten, samme er med feks når valg i et felt trigger at et nytt spørsmål kommer i skjema, det bør alltid komme senere i flyten.
For å støtte gruppen med Retinitus pigmentosa (og annet som fører til kikkhullsyn/tunnelsyn) er det viktigste at ting står på fast sted, og deretter gjerne venstrestilt, å gi dem nyttig info om at en feil er skjedd kan sannsynligvis ivaretas med merking av felt kombinert med at feilmelding umiddelbart kommer rett etterpå.
I sum kan det da gi negativ opplevelse for andre.

Vi ønsker gjerne mer dokumentasjon på brukertest, undersøkelser og annen innsikt på dette.

[mrosvik]

Litt mer info om dette som vi bør ta i betraktning:
https://www.smashingmagazine.com/2022/08/error-messages-ux-design/

[solhell]

Bra å se at det ikke var bare meg som mener feilmelding over feltet er best :)
Samtidig fikk jeg en idé rundt det med feilmelding over sammen med live validering.
Er det gjennomførbart å kombinere live validering med scriptmetoden scrollBy() på en måte som gjør at det ikke er innholdet under feilmeldingen som skyves nedover, men heller innholdet over som skyves oppover?
Jeg tror det kunne vært interessant å inkludere i brukertesting.

[Camulos]

Denne ble delt for en stund siden fra UX-researcheren vår:
https://uxmovement.com/forms/the-best-place-for-error-messages-on-forms/
Til høyre var den beste overall plasseringen og under best for mobil og nest best for overall om jeg tolket artikkelen rett.

[mrosvik]

Første utkast kan ses her: https://storefront-pr-2096.dev.designsystemet.no/monstre/feilmeldinger

Vi setter pris på alle tilbakemeldinger og innspill.

[Camulos]

Jeg ville fulgt Mozilla sine anbefalinger (som teksten er basert på), vil en gjøre noe annet så sørg for å test at en ikke får lest dobbelt opp med en av skjermleserne slik de advarer om.

[Febakke]

Om jeg leser disse riktig så virker det som at describedby har bedre støtte per nå. (om de er oppdatert) Det kan vi kanskje gjøre litt tester på 🤔

Aria-errormessage
Aria-describedby

[Camulos]

ca 1 år siden de kildene oppdaterte støtte, kan vi finne noe nyere tabell som viser støtte i ulike nettlesere?

Om jeg leser disse riktig så virker det som at describedby har bedre støtte per nå. (om de er oppdatert) Det kan vi kanskje gjøre litt tester på 🤔

Aria-errormessage Aria-describedby

[Febakke]

Fant ikke noe nyere tabell, så det blir eventuelt opp til oss å teste.
Denne er relevant: w3c/aria#2048

Noen ønsker å fjerne aria-errormessage, noen ønsker ikke. Kan også se der at NVDA snart kommer ut med støtte for aria-errormessage.

Mitt forslag:

1. Det tryggeste for en veiledning som dette er å bruke den mest stabile løsningen som per virker å være aria-describedby.
2. Vi kjører en test av aria-errormessage for å se om støtten har blitt bedre. Vi kan enten gjøre et forsøk på det nå eller vente til NVDA har publisert støtte for aria-errormessage. (Her trenger jeg hjelp av noen med JAWS lisenser 😄 )

[Febakke]

Blir også diskutert litt her: #2089 (comment)

Jeg er usikker på hvordan vi skal angripe dette i artikkelen. Men det beste hadde kanskje vært å opplyse om begge metoder og oppgi at aria-describedby har bedre støtte per nå og at vi anbefaler denne frem til støtten er god nok på aria-errormessage?

[anderssonsaja]

Jeg er enig i at vi bør bruke aria-describedby til støtten er god nok på aria-errormessage. Har nok blitt litt moment 22: Ingen bruker det fordi støtten er dårlig, og ingen bygger støtte for den, fordi den ikke brukes. Fra: Lasse Febakke Straum ***@***.***> Dato: onsdag, 19. juni 2024 kl. 11:17 Til: digdir/designsystemet ***@***.***> Kopi: Saja Andersson ***@***.***>, Comment ***@***.***> Emne: Re: [digdir/designsystemet] Error message: Brukerutløste feil (Discussion #1684) Blir også diskutert litt her: #2089 (comment)<#2089 (comment)> Jeg er usikker på hvordan vi skal angripe dette i artikkelen. Men det beste hadde kanskje vært å opplyse om begge metoder og oppgi at aria-describedby har bedre støtte per nå og at vi anbefaler denne frem til støtten er god nok på aria-errormessage? — Reply to this email directly, view it on GitHub<#1684 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BGRBKHCLQNXLZIBM6VVQHK3ZIFECDAVCNFSM6AAAAABETUKEH2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQMJVGI4TA>. You are receiving this because you commented.Message ID: ***@***.***>

[mortentollefsen]

Enig: Ingen bruker det fordi støtten er dårlig, og ingen bygger støtte for den, fordi den ikke brukes.
Selv er jeg veldig tilhenger av å bruke best mulig semantikk, inkludert ting som kanskje ikke fungerer i alle kombinasjoner av skjermleser/nettleser. Det å bruke "halvriktig" semantikk, feks. aria-describedby på feilmeldinger er en måte å få bedre støtte på tvers, men nå har aria vært der så lenge at jeg mener at vi bør forvente at oppdaterte skjermlesere støtter standarden. Gjør ikke skjermleserne det bør de få støtte, og da må vi være tøffe nok til å bruke aria slik aria er tenkt.
Jeg testet dette for en stund siden, og det er jo synd at ikke skjermlesere støtter aria-errormessage, dvs. kun Jaws gjør det foreløpig. Til gjengjeld funker det kjempefint med Jaws, og det gir jo veldig gode muligheter for mer effektiv navigering (hopp til neste feil etc, men dette er ikke implementert foreløpig).
Her er testen jeg brukte:
https://mortentollefsen.no/demo/aria-errormessage.html

[eirikbacker]

According to https://www.youtube.com/live/xEtKkLdAnvI?feature=shared&t=5075 we should consider if our pattern is below or above as they recommend label, description and validation should visible at the same time to help the user understand the context. If the validation message is below the input, the validation can be hidden by:

• Browser zoom / maginification
• Browser built in password manager
• Browser built in autocomplete
• Browser built in spellcheck
• Browser built in translation
• Browser built in autofill
• A virtual keyboard on mobile
• Combobox-dropdown
• Datepicker

Note also that validation above input means input moves when validation appears, meaning validation should not run on blur or or while typing, but instead run on submit or navigate to next form page.