diff --git a/apps/storefront/pages/monstre/feilmeldinger.mdx b/apps/storefront/pages/monstre/feilmeldinger.mdx
index f02575b165..1ed8fdae91 100644
--- a/apps/storefront/pages/monstre/feilmeldinger.mdx
+++ b/apps/storefront/pages/monstre/feilmeldinger.mdx
@@ -1,4 +1,12 @@
+import {
+ Card,
+ Heading,
+ Paragraph,
+ Accordion,
+} from '@digdir/designsystemet-react';
+
import { Meta, Image } from '@components';
+import { Contributors } from '@blog';
import { MenuPageLayout } from '@layouts';
(
);
-Det er best om vi klarer å hindre at det oppstår feil. Da må vi på forhånd oppgi tydelig hva brukeren må gjøre for å fylle ut feltene i skjemaet riktig. Vi må godta ulik formatering, for eksempel på felt med tall, som i telefonnummer eller datoer. Brukerne må alltid få mulighet til å redigere felter eller gå tilbake, og kunne pause utfyllingen eller avbryte.
+## Innledning
+
+Feilmeldinger kan komme fra systemet eller være utløst av noe brukerne har gjort. Denne artikkelen handler om brukerutløste feilmeldinger i selvbetjeningsløsninger og skjema. Hvordan kan vi unngå å gi feilmeldinger, og hvordan kan vi hjelpe brukerne å komme seg videre når det likevel har oppstått en feil?
+
+Når brukerne har gjort en feil som hindrer dem i å komme videre, skal vi varsle dem om feilen slik at de kan rette opp:
+
+- Beskriv problemet på en lettforståelig måte.
+- Forklar hva brukerne må gjøre for å komme videre.
+- Passe på at feilmeldingen er lett synlig.
+
+Feilmeldinger kan være knyttet til ett enkelt felt eller til flere. Vi viser en oppsummering av flere feil hvis brukeren forsøker å gå videre uten å ha fylt ut alt.
-Når det likevel har oppstått et problem som gjør at brukeren ikke kommer videre, skal vi vise en feilmelding som beskriver problemet og forklarer hva brukerne må gjøre.
+### Feilmeldinger på enkeltfelt
-Vi har ulike typer feilmeldinger
+Vi skal kunne vise feilmeldinger sammen med alle typer felt i et skjema. Meldingen skal stå nært feltet som feiler.
-- [Detaljerte feilmeldinger](#detaljerte-feilmeldinger), som tilhører et bestemt felt i et skjema.
-- [Oppsummerende feilmeldinger](#oppsummerende-feilmeldinger), som kan vise en eller flere feilmeldinger.
+
-For andre type feil som ikke tilhører et skjemaelement, og som ikke validerer brukerens inndata, kan du bruke [`alert`](/docs/komponenter-alert--docs)-komponenten. Det kan for eksempel være for systemfeil, eller til myke valideringer. Myke valideringer er meldinger som ikke stopper brukeren fra å sende inn eller gå videre til neste steg i prosessen, men som bare gir brukeren informasjon.
+### Oppsummering av flere feilmeldinger
-## Detaljerte feilmeldinger
+En oppsummering kan gjelde for én eller flere feil. Hvis brukerne prøver å gå videre uten å ha fylt ut alt, eller de har gjort feil, oppsummerer vi like over Neste/Send inn-knappen.
-Plasser feilmeldinger som tilhører et bestemt felt på siden så nært feilen som mulig. Pass på at du kobler den til feltet med `aria-describedby`.
+Vi anbefaler å vise oppsummeringen i nærheten av Neste-knappen for at brukerne skal forstå sammenhengen mellom feilen og hvorfor de blir hindret i å gå videre. I noen tilfeller kan det likevel være bedre å vise oppsummeringen i toppen, for eksempel hvis
-Feltet skal tydelig vise at noe er feil. Dette gjør vi med rød farge, [forklarende tekst](#tekst-i-feilmeldinger) og `aria-invalid`. Plasser teksten som viser hva som er feil og hva brukeren må gjøre, rett under selve feltet der feilen er.
+- den tekniske løsningen laster siden på nytt når brukerne velger Neste
+- brukerne har vært ute av et skjema og går inn igjen
+- løsningen ikke stopper brukerne fra å gå til neste side selv om de har feil på en side
+
+Pass på at
+
+- oppsummeringen viser alle feilmeldingene som gjelder for siden eller trinnet
+- brukerne kan gå direkte til feilene de må rette opp, og fokuset blir flyttet dit
+- lenkene i oppsummeringen stemmer med feilmeldingene de lenker til
+- du lenker til den første av flere feil
+- feilene forsvinner fra oppsummeringen etter hvert som brukerne fikser dem
+- feilmeldingen i oppsummeringen har med nøkkelord fra ledeteksten
-### Når skal feilmeldinger presenteres for brukeren?
+### Det er best om vi kan unngå å gi feilmeldinger
+
+Når vi planlegger en løsning, bør målet være å hindre at det oppstår feil. Disse punktene kan hjelpe i planleggingen:
+
+- Gi all relevant informasjon før brukerne starter, i klart og tydelig språk.
+- Bruk ledetekster og beskrivelser for å hjelpe brukerne underveis.
+- Unngå hjelpetekster bak spørsmålstegn om du kan, men bruk dem om nødvendig.
+- Gi brukerne mulighet til å endre svar i felt eller gå tilbake.
+- La brukerne ta en pause i utfyllingen eller avbryte den.
+- Sørg for at feltene godtar ulik formatering, for eksempel for datoer og telefonnummer.
+- Legg inn en bestemt rekkefølge på svaralternativene, for å hindre at brukeren tar valg som fører til feil.
+- Vis informasjon om maks. antall tegn under ledeteksten hvis feltet har tegnbegrensning.
+
+### Ulike typer feilmeldinger
-Vi kan presentere feilmeldinger for brukerne enten når
+#### Systemgenererte meldinger
-- Brukeren forlater feltet
-- Brukeren trykker "Gå videre" eller "Send inn"
+Vi bruker systemmeldinger, eller systemvarsler, for å varsle brukeren om feil i systemet eller gi dem viktig informasjon de bør få med seg. Vi har en [egen artikkel om systemvarsler](/monstre/systemvarsler).
-Vi skal ikke vise feilmeldinger mens brukeren fyller ut feltet. Mange bruker nemlig tastatur til å navigere i skjemaet. De vil ikke nødvendigvis starte på toppen og jobbe seg nedover og derfor vil det forstyrre hvis det dukker opp feilmeldinger på felter brukeren ikke har fylt ut enda.
+#### Infomeldinger til brukeren
-Hvis vi har feilmeldinger som skal vises når brukeren forlater feltet, må vi kode det slik at vi vet om brukeren faktisk har skrevet noe i feltet før vi viser feilmeldingen. Det tryggeste er å vise feilmeldingen når brukeren selv er klar til å gå videre.
+Infomeldinger som vises på grunn av noe brukerne gjør, stopper ikke brukerne fra å sende inn eller gå videre til neste steg.
-Det kan være irriterende for brukerne hvis feilmeldingen vises når de forlater feltet. Brukerne bør først få en feilmelding for et obligatorisk felt når de prøver å gå til neste side eller sende inn skjemaet. Vis tydelig at et felt må fylles ut. Her kan du lese mer om hvordan du markerer [obligatoriske og valgfrie skjemafelt](/monstre/obligatoriske-og-valgfrie-felt).
+Vi viser infomeldinger når vi skal informere om konsekvenser av et valg. Slike meldinger kan vi for eksempel presentere i en alert av typen "info" eller "success". Disse meldingene vises etter at brukeren har oppgitt informasjon i et skjemafelt, og oppfører seg på samme måte som feilmeldinger.
-## Oppsummerende feilmeldinger
+Eksempler:
-I noen tilfeller bør vi oppsummere alle feil øverst på siden eller like over "Gå videre" / "Send inn"-knappen. Oppsummeringen kan gjelde for én eller flere feil. Teksten i en oppsummerende feilmelding skal være lik det du ser i den detaljerte feilen (se eksempelet under).
+- Du starter en bedrift og skal registrere navnet. Du får beskjed om at bedriftsnavnet allerede er i bruk av noen andre. Du kan bruke navnet du har valgt, men du kan få problemer med domenenavn eller at foretaket ditt blir forvekslet med et annet.
+- Du gjør et valg i et søknadskjema som fører til lengre behandlingstid. Du får en infomelding om lengre ventetid.
+
+## Språk
+
+### Skriv gode feilmeldinger
+
+Den viktigste jobben til en feilmelding er å hjelpe brukerne videre:
+
+- Skriv vennlig, klart og tydelig.
+- Hold feilmeldingen så kort som mulig.
+- Vær konkret. Hvis vi skriver “Feltet er ikke fylt ut korrekt”, får brukeren ingen forklaring på hva som er feil.
+- Gjenta nøkkelord fra ledeteksten/feltnavnet så tidlig som mulig i feilmeldingen.
+
+Noen tekniske løsninger gjør at vi kan ta inn feltnavnet som en variabel i feilmeldinger, da blir feltnavnet i ubestemt form, som i disse eksemplene:
+
+- “Postnummer må ha 4 siffer”
+- "Fødselsnummer må ha 11 siffer"
+- “Velg minst ett leveringsalternativ”
+
+Hvis løsningen ikke tar inn feltnavnet som variabel i feilmeldinger, anbefaler vi å skrive substantivet med bestemt form: Postnummeret må ha fire siffer.
+
+## Design og opplevelse
+
+### Utseendet på feilmeldinger
+
+Når det oppstår feil i et felt er det viktig at feltet blir godt synlig, slik at det er lett for brukerne å se hvor de må fylle ut eller rette opp noe.
-Den løsningen eller tjenesten du lager, bestemmer om du bør plassere oppsummeringen øverst på siden eller lenger nede, før knappen som tar brukerne videre. Se eksempelet over. Det viktigste er at brukeren lett ser oppsummeringen.
+Når den tekniske løsningen sjekker for feil, det vi kaller validerer, ønsker vi å vise hvilke felt som har feil. Til det kan vi bruke flere virkemidler.
-Pass på at
+#### Visuelle endringer
-- oppsummeringen viser alle feilmeldingene som gjelder for siden eller trinnet
-- brukerne kan gå direkte til feilene de må rette og at fokuset blir flyttet dit
-- lenkene i oppsummeringen stemmer med feilmeldingen de lenker til
-- du skriver feilmeldingen slik at den er lett å forstå, at den gir mening for brukerne når de kun leser feilmeldingen i oppsummeringen
-- hvis det er flere feil, så lenker du til den første feilen i rekken
-- feilene forsvinner fra oppsummeringen etter hvert som brukerne fikser dem
+Vis feilmeldingsteksten nært feltet det gjelder. Vi anbefaler å ha med et ikon som en visuell indikator i tillegg til tekst. For skjemakomponenter som tillater det, kan vi også endre tykkelsen på rammen rundt, som vist i eksempelet over.
+
+#### Fargevalg
+
+Vi bruker rød som varselfarge for feil, det vi si at feltet og selve feilmeldingen blir røde. Dette er et godt etablert mønster, som hjelper med å skille feltet fra andre felt.
+Feltet må ha 3:1 kontrast til bakgrunnsfargen. Hvis vi også bruker rød tekst til feilmeldingen, må den minst ha kontrasten 4.5:1. [Les mer om kontraster hos Tilsynet for universell utforming av IKT.](https://www.uutilsynet.no/veiledning/kontrast/48)
+
+#### Slik plasserer vi en feilmelding
+
+Vi viser feilmeldingen under feltet med feil. Dette er det vanligste mønsteret, selv om det også diskuteres om den skal stå mellom ledeteksten og feltet.
-## Ikke deaktiver submit-knappen
+
+
+ Merk: Vi ønsker å holde oss oppdatert om andre anbefalinger om plassering, og har [pågående diskusjon om dette på Git](https://github.com/digdir/designsystemet/discussions/1684#discussioncomment-9339006).
-Vi bruker ikke deaktivert "Gå videre"/"Send inn"-knapp til å validere skjema. Noen brukere forstår ikke hvorfor knappen er deaktivert og kan bli forvirret. Brukere med nedsatt syn kan slite med å finne knappen og tro at skjemaet har tekniske problemer. Hvis brukeren prøver å velge knappen mens det er feil i skjemaet, kan vi heller vise en oppsummerende feilmelding over "Gå videre"/"Send inn"-knappen.
+
+
-## Tekst i feilmeldinger
+### Når skal vi vise en feilmelding?
-Den viktigste jobben til teksten i en feilmelding er å hjelpe brukerne videre:
+Vi kan vise feilmeldinger når brukerne forlater feltet, når de velger å gå videre, eller sender inn. Vi unngår å vise feilmeldinger mens brukeren fyller ut et felt.
-- Tenk på målgruppen og skriv vennlig, klart og tydelig. Unngå passivt eller teknisk språk. Meldingen skal være lett å forstå.
-- Unngå humor i feilmeldinger. Når folk møter på et problem, vil de heller ha effektive forslag til hvordan de løser det, enn humoristiske «Oops!»
-- Vær konkret. Når du skriver “Feltet er ikke fylt ut korrekt”, får ikke brukeren noen forklaring på hva som er feil. Gi konkret informasjon om hva som er problemet og gjenta gjerne nøkkelord fra ledeteksten.
-- Noen ganger må vi beskrive hva feilen er før vi beskriver hva brukerne skal gjøre, men det viktigste er å vise løsningen på problemet.
-- Tilpass feilmeldingene til ulike situasjoner. Jobben til teksten er å hjelpe brukeren videre.
-- Hold feilmeldingen kort, da sparer du brukerne for tid.
+Når brukerne har gjort en feil når de fyller ut et felt og de går videre, viser vi feilmeldinger når vi kan se at brukeren ikke har fylt ut det vi forventer. Et eksempel kan være at de har lagt inn bokstaver i et fødselsnummer, eller at en e-postadresse mangler krøllalfa (@).
-Eksempel på forklarende feilmeldinger:
+Brukerne bør ikke få feilmelding for et tomt obligatorisk felt før de går til neste side eller sender inn skjemaet. Vi vet ikke alltid når brukeren er ferdig med å fylle ut feltene, så da venter vi til brukeren selv er klar til å gå videre. Det er spesielt viktig når brukere benytter tastaturet til å navigere i løsningen.
-- “Postnummeret må ha 4 siffer”
-- "Fødselsnummeret må ha 11 siffer"
-- “Velg minst ett av leveringsalternativene”
-- “Kryss av i ruten for å bekrefte at navnet er riktig, før du sender inn skjemaet”
+### Kryssvalidering
+
+Noen ganger vil det brukeren velger i ett eller flere felt påvirke felt som kommer senere i skjemaet. For eksempel kan et valg brukerne gjør i en radiogruppe, gjøre at et frivillig felt lenger ut i skjemaet blir obligatorisk. Et valg på ett sted kan også gjøre at et valg et annet sted må være innenfor en viss verdi. I slike tilfeller snakker vi om kryssvalidering.
+
+Her må vi gjøre det så tydelig som mulig for brukeren at flere felt påvirker hverandre:
+
+- Merk alle feltene visuelt og med feilmelding.
+- Forklar hva som utløste feilen. Vær tydelig på at feilen skyldes kryssvalidering.
+- Fortell brukerne hva de kan gjøre for å rette feilen.
+
+#### Feilmeldinger som gjelder flere felt
+
+I dette eksempelet har vi en gruppe med felt, der brukeren ikke nødvendigvis har alle opplysningene, men må fylle ut minst ett felt.
+
+
+
+ Eksempel på feilmelding som gjelder flere felt
+
+
+Videoen under viser at brukeren forsøker å gå videre uten å ha fyllt ut minst ett felt, som er påkrevd. Alle feltene i gruppen blir da røde og en feilmelding vises i bunnen.
+
+
+
+Hadde det vært bare en feil i gruppen, ville feilmeldingen vist på vanlig måte under kun et av feltene, uten at hele gruppen ble rød.
+
+
+
+
+
+
+
+
+## Kode
+
+### Feilmeldinger og tilgjengelighet
+
+Det er flere WCAG-kriterier som gjelder for feilmeldinger. Vi har tatt hensyn til disse i arbeidet med denne artikkelen. Hvis du vil vite mer om det, kan du lese tolkningene av WCAG-kravene hos Tilsynet for universell utforming av IKT.
+
+**Relevante WCAG-krav:**
+
+- [3.3.1 Identifikasjon av feil](https://www.uutilsynet.no/wcag-standarden/331-identifikasjon-av-feil-niva/116)
+- [3.3.3 Forslag ved feil](https://www.uutilsynet.no/wcag-standarden/333-forslag-ved-feil-niva-aa/118)
+- [1.4.3 Kontrast (minimum)](https://www.uutilsynet.no/wcag-standarden/143-kontrast-minimum-niva-aa/95)
+- [1.4.11 kontrast for ikke-tekstlig innhold](https://www.uutilsynet.no/wcag-standarden/1411-kontrast-ikke-tekstlig-innhold-niva-aa/145)
+
+### Ikke deaktiver submit-knappen
+
+Vi bruker ikke deaktivert "Gå videre/Send inn"-knapp til å validere skjema. Noen brukere forstår ikke hvorfor knappen er deaktivert og blir forvirret. Brukere med nedsatt syn kan slite med å finne knappen og tro at skjemaet har tekniske problemer. Hvis brukerne prøver å gå videre mens det fortsatt er feil i skjemaet, kan vi heller vise en oppsummerende feilmelding over "Gå videre/Send inn"-knappen.
+
+### HTML og Aria
+
+For at alle brukere skal oppfatte feilmeldinger, er det viktig med et tydelig forhold mellom feilmeldingene og feltene de tilhører, også for dem som ser på innhold med ulike hjelpemidler.
+
+Vi kan bruke disse aria-attributtene og rollene:
+
+- Vi setter `aria-invalid="true"` på felt med feil, for å si fra om at det er en feil der.
+- Vi bruker `aria-describedby` for å koble feilmelding til feltet.
+
+
+
+ Vi unngår inntill videre å bruke `aria-errormessage` da den ikke har full støtte av hjelpemidler per nå. Men vi kommer til å oppdatere retningslinjene om støtten blir bedre i fremtiden. [Se diskusjon på github](https://github.com/digdir/designsystemet/discussions/1684)
+
+
+
+
+### Gi automatiske beskjeder
+
+Vi kan også gi automatiske beskjeder når vi vil at brukeren så snart som mulig skal få opplest viktig informasjon. Det kan for eksempel være når det blir en stor visuell endring, eller nytt innhold.
+
+For feilmeldinger som dukker opp dynamisk må vi bruke `aria-live` for at meldingen skal bli lest opp av skjermlesere. Pass godt på om du setter `aria-live` til å være `assertive` eller `polite`. I de fleste tilfeller er det best å bruke `polite`, for da venter skjermleseren med å lese opp feilmeldingen til den er ferdig med å lese opp innholdet.
## Kilder
@@ -107,3 +280,37 @@ Eksempel på forklarende feilmeldinger:
- [Suksesskriterium 3.3.3 Forslag ved feil](https://www.w3.org/Translations/WCAG21-no/#error-suggestion)
- [Skjemavalidering, Aksel](https://aksel.nav.no/god-praksis/artikler/skjemavalidering)
- [Fejlmeddelelser, Fælles designsystem](https://designsystem.dk/komponenter/fejlmeddelelser/)
+
+
+
+
+
+
+ Retningslinjene er utarbeidet i en tverretatlig arbeidsgruppe med deltakere fra Digdir, Nav, Skatt, Brreg, Politiet, KS DIF og Oslo kommune. Du kan påvirke arbeidet i [Github](https://github.com/digdir/designsystemet/discussions/1684) eller i [#Mønster-kanalen](https://designsystemet.slack.com/archives/C05RBGB92MC/p1712751837722749) på [Slack](https://join.slack.com/t/designsystemet/shared_invite/zt-2438eotl3-a4266Vd2IeqMWO8TBw5PrQ).
+
+
+
+
+
+
+
+---
diff --git a/apps/storefront/pages/monstre/obligatoriske-og-valgfrie-felt.mdx b/apps/storefront/pages/monstre/obligatoriske-og-valgfrie-felt.mdx
index d07062ea6e..5ca4c52971 100644
--- a/apps/storefront/pages/monstre/obligatoriske-og-valgfrie-felt.mdx
+++ b/apps/storefront/pages/monstre/obligatoriske-og-valgfrie-felt.mdx
@@ -1,3 +1,5 @@
+import { Card, Heading, Paragraph } from '@digdir/designsystemet-react';
+
import { MenuPageLayout } from '@layouts';
import { Meta, Image } from '@components';
@@ -18,6 +20,20 @@ export default ({ children }) => (
Det er flere måter å markere obligatoriske felt på som [oppfyller kravene til merking](https://www.uutilsynet.no/veiledning/skjema/38#ledetekster_og_instruksjoner). I dag gjør vi dette ulikt på tvers. Noen bruker asterisk (stjerne), noen bruker ord, andre informerer i forkant om hva som må fylles ut. Klarer vi å gjøre dette mer likt på tvers blir det lettere for innbygger å forstå og kjenne igjen mønsteret på tvers av løsningene våre. Det vil alltid være unntak og ulike kontekster som krever ulik merking.
+
+
+ *Retningslinjene er utarbeidet i en tverretatlig arbeidsgruppe med deltakere fra Digdir, Nav, Skatt, Brreg og Oslo Origo. Du kan påvirke arbeidet i [Github](https://github.com/digdir/designsystemet/issues/new) eller i [#Mønster-kanalen](https://designsystemet.slack.com/archives/C05RBGB92MC/p1712751837722749) på [Slack](https://join.slack.com/t/designsystemet/shared_invite/zt-2438eotl3-a4266Vd2IeqMWO8TBw5PrQ).
+
+
+
+
En generell retningslinje er at vi bør unngå å be om informasjon vi ikke trenger, altså unngå valgfrie felt.
Her tar vi for oss 3 eksempler.
diff --git a/apps/storefront/pages/monstre/systemvarsler.mdx b/apps/storefront/pages/monstre/systemvarsler.mdx
new file mode 100644
index 0000000000..dad00dc9ce
--- /dev/null
+++ b/apps/storefront/pages/monstre/systemvarsler.mdx
@@ -0,0 +1,46 @@
+import { Card, Heading, Paragraph } from '@digdir/designsystemet-react';
+
+import { Meta, Image } from '@components';
+import { MenuPageLayout } from '@layouts';
+
+
+
+export default ({ children }) => (
+
+);
+
+
+
+ *Retningslinjene er under arbeid fra 5. juni 2024 i en tverretatlig arbeidsgruppe med deltakere fra Digdir, Nav, Skatt, Brreg, Politiet, KS DIF og Oslo kommune. Alle er velkommen til å påvirke arbeidet i [Github](https://github.com/digdir/designsystemet/discussions/2083) eller i [#Mønster-kanalen](https://designsystemet.slack.com/archives/C05RBGB92MC/p1712751837722749) på [Slack](https://join.slack.com/t/designsystemet/shared_invite/zt-2438eotl3-a4266Vd2IeqMWO8TBw5PrQ).
+
+
+
+
+Systemvarsler brukes for å varsle brukeren enten om feil i systemet eller holde dem informert om viktige ting de bør få med seg. Vi bruker dem til feil som ikke tilhører et skjemaelement, og som ikke validerer brukerens inndata. De bør derfor ha et annet utseende enn [brukerutløste feil](/monstre/feilmeldinger).
+
+Systemvarsler kan for eksempel komme i form av [`alert`](https://storybook.designsystemet.no/?path=/docs/komponenter-alert--docs), `toast`, [`modal`](https://storybook.designsystemet.no/?path=/docs/komponenter-modal--docs) eller [`popover`](https://storybook.designsystemet.no/?path=/docs/komponenter-popover--docs).
+
+Eksempler på varsler:
+
+- Tjenesten vår er dessverre nede, men vi jobber med saken. Prøv igjen om litt. Hvis du fortsatt har problemer, kan du ta kontakt med oss.
+- Det kan se ut som du ikke er koblet til internett. Sjekk tilkoblingen din og prøv igjen.
+- Tjenesten vil være nede onsdag 24. juni 2029 mellom klokken 04-06.
+- Du har nå tatt i bruk den nyeste versjonen av tjenesten. Du kan bytte tilbake til den gamle versjonen ved å klikke her.
+- Du har ikke foretatt deg noe på en stund, og påloggingen er i ferd med å utløpe. Du vil bli logget ut om 5 minutter. Arbeidet ditt er lagret.
+- Er du sikker på at du vil avbryte nå? Du kan miste arbeidet du allerede har gjort.
diff --git a/apps/storefront/public/img/error-message-group-error.mp4 b/apps/storefront/public/img/error-message-group-error.mp4
new file mode 100644
index 0000000000..42e085c7a1
Binary files /dev/null and b/apps/storefront/public/img/error-message-group-error.mp4 differ
diff --git a/apps/storefront/public/img/errormessage-co-1.png b/apps/storefront/public/img/errormessage-co-1.png
new file mode 100644
index 0000000000..11c8d8cde2
Binary files /dev/null and b/apps/storefront/public/img/errormessage-co-1.png differ
diff --git a/apps/storefront/public/img/errormessage-co-2.png b/apps/storefront/public/img/errormessage-co-2.png
new file mode 100644
index 0000000000..f10a78d6a5
Binary files /dev/null and b/apps/storefront/public/img/errormessage-co-2.png differ
diff --git a/apps/storefront/public/img/errormessage-co-22b.png b/apps/storefront/public/img/errormessage-co-22b.png
new file mode 100644
index 0000000000..6d2028e130
Binary files /dev/null and b/apps/storefront/public/img/errormessage-co-22b.png differ
diff --git a/apps/storefront/public/img/errormessage-co-2b.png b/apps/storefront/public/img/errormessage-co-2b.png
new file mode 100644
index 0000000000..1ef47975a1
Binary files /dev/null and b/apps/storefront/public/img/errormessage-co-2b.png differ
diff --git a/apps/storefront/public/img/errormessage-co-3.png b/apps/storefront/public/img/errormessage-co-3.png
new file mode 100644
index 0000000000..4a6fd3022d
Binary files /dev/null and b/apps/storefront/public/img/errormessage-co-3.png differ
diff --git a/apps/storefront/public/img/errormessage-design.png b/apps/storefront/public/img/errormessage-design.png
new file mode 100644
index 0000000000..0e512509d9
Binary files /dev/null and b/apps/storefront/public/img/errormessage-design.png differ
diff --git a/apps/storefront/siteConfig.tsx b/apps/storefront/siteConfig.tsx
index 97dc39b8a6..797e655146 100644
--- a/apps/storefront/siteConfig.tsx
+++ b/apps/storefront/siteConfig.tsx
@@ -139,39 +139,43 @@ export const SiteConfig = {
url: 'monstre',
children: [
{
- name: 'Brukeroppgaver',
+ name: 'Ferdig',
url: 'monstre/brukeroppgaver',
children: [
{
- name: 'Innlogging',
- url: 'monstre/innlogging',
- },
- {
- name: 'Navigering',
- url: 'monstre/navigering',
+ name: 'Obligatoriske felt *',
+ url: 'monstre/obligatoriske-og-valgfrie-felt',
},
{
- name: 'Ofte brukte handlinger',
- url: 'monstre/handlinger',
+ name: 'Feilmeldinger *',
+ url: 'monstre/feilmeldinger',
},
],
},
{
- name: 'Skjema',
+ name: 'Kommende',
url: 'monstre/skjema',
children: [
{
- name: 'Obligatoriske og valgfrie skjemafelt',
- url: 'monstre/obligatoriske-og-valgfrie-felt',
- },
- {
- name: 'Feilmeldinger',
- url: 'monstre/feilmeldinger',
+ name: 'Systemvarsler *',
+ url: 'monstre/systemvarsler',
},
{
name: 'Dato',
url: 'monstre/dato',
},
+ {
+ name: 'Innlogging',
+ url: 'monstre/innlogging',
+ },
+ {
+ name: 'Navigering',
+ url: 'monstre/navigering',
+ },
+ {
+ name: 'Ofte brukte handlinger',
+ url: 'monstre/handlinger',
+ },
],
},
],