Places we want do and dont in our docs

[Barsnes]

The first part of this task is about identifying which component should include do and don’t examples. We will then create example images in Figma and add them to the Guidelines "do and don’t sections" on the relevant component pages.

We should create "do and dont"-examples for:

• [ ] Switch
• [ ] ?
• [ ] ?

[ghost]

I will be working with do's and don'ts. First, I will identify the components that should be included, then make example images in Figma.

[ghost]

Do's and Don'ts

Switch (Utkast, gjerne kom med forslag til teksten under bildet eller andre innspill)

Retningslinjer

(Teksten er hentet fra designsystemet: https://storybook.designsystemet.no/?path=/docs/komponenter-switch--docs)

Switch skal være et valg mellom to alternativer. Vi bruker Switch til innstillinger, ikke i skjema. Passer til å aktivere eller deaktivere funksjoner/tilstander med en gang slå varsler av og på

Passer ikke til å bruke i stedet for Checkbox eller Radio i et skjema situasjoner der brukerne må lagre informasjon før en endring får effekt endre visning av innhold mellom to kategorier, bruk heller ToggleGroup

Bruk heller Checkbox hvis du skal tilby brukerne flere valg, der de skal velge ett eller flere alternativer Radio hvis brukerne skal få flere valg, men bare skal velge ett Chip til å filtrere innhold

Tekst Teksten til en Switch må være kort og presis, ofte betyr det bare ett eller to ord. Det skal gi mening når du sier ledeteksten høyt og legger til av/på etterpå. Unngå tekst med flere ord og mellomrom. Hvis du har flere Switch i en gruppe, må du passe på at du er konsekvent med hvordan du formulerer tekstene til hver av dem også, ikke formulerer dem forskjellig. Teksten skal beskrive hva funksjonen gjelder, ikke om den er på eller av. Hvis statusen skrives inn i labelen, kan det bli forvirrende og vanskelig å vite hvilken tilstand switchen faktisk er i.

Plassering av tekst Som regel er det høyre som er den beste plasseringen for tekst, unntaket er når Switch er fast plassert på høyre side i grensesnittet er det best at teksten er på venstre side. Slik at alle knappene blir justert etter samme vertikale linje. Tilgjengelighet Vi bruker role="switch" for å fortelle skjermlesere at dette er en vippebryter. Dette gjør at skjermlesere kan gi brukeren informasjon om at dette er en vippebryter og at den kan skrus av og på. Det er ikke lagt på aria-checkedsiden dette er ikke nødvendig når bryteren er en input med type="checkbox". 1 Tastaturnavigasjon Space slår av/på

Link til Figma: https://www.figma.com/design/XXGDiXAcBptAgu8bMEAOSr/Arbeidsomr%C3%A5de---M%C3%B8nstre?node-id=704-2381&t=D8yOCGeMNvJdC3CA-1

[ghost]

##Textfield (Utkast)

Retningslinjer Input er egnet til korte tekster og svar. Textarea er egnet til mer utfyllende og lengre svar.

Unngå plassholdertekster Plassholdertekster (placeholder) forsvinner når brukerne skriver i feltet. Det er derfor bedre å inkludere hint og viktig informasjon i selve ledeteksten eller den tilhørende beskrivelsen. Kontrastkravene i WCAG gjelder for placeholder også, og da blir teksten så mørk at brukerne kan oppfatte textfield som utfylt.

Tilpass bredden på tekstfeltet Tilpass bredden etter hva brukerne skal skrive inn, kort bredde for telefonnummer og bredere for stedsnavn. Ulik bredde på feltene gjør det lettere å navigere i skjemaer med mange felt.

Tillat kopier og lim inn Brukere som skal fylle ut et tekstområde, trenger ofte å kopiere og lime inn informasjon, så denne funksjonen må ikke deaktiveres. Dette gjør det enkelt for brukerne å fylle inn nødvendige opplysninger uten begrensninger. Inndata For å sikre en god brukeropplevelse er det viktig å bruke en kombinasjon av riktig input-type og autocomplete-attributter. Les mer om autocomplete på MDN Webdocs. Tillat variasjoner i hvordan data skrives inn, så lenge informasjonen er forståelig. For eksempel bør telefonnumre kunne inneholde mellomrom, personnumre punktum, og e-postadresser aksepteres selv om de har et mellomrom til slutt. Velg inputtyper som samsvarer med informasjonen du ber om, for eksempel tel, search eller email. Dette gir mobilbrukere et tilpasset tastatur, men vær oppmerksom på at enkelte inputtyper kan aktivere klientsidevalidering. autocomplete brukes i felter som mottar personlig informasjon. Hvis feltet skal be om personopplysninger om en annen person enn brukeren, må du sette autocomplete="off". Pass på at brukerne ser inndata som formateres automatisk, men uten at det forstyrrer dem mens de fyller ut.

Tekst Det skal alltid være ledetekst på Textfield. Hold ledeteksten kort, unngå at den går over to linjer Unngå å legge til beskrivelse som ikke er relevant eller meningsfull for brukeren Unngå å bruke kolon etter label

Tilgjengelighet Ikke bruk deaktiverte felt Ikke bruk deaktivert tilstand (disabled) på tekstfelt. Tenk heller over om du trenger å vise feltet i det hele tatt, eller om du heller kan skrive informasjonen ut i ren tekst eller bruke readonly.

Prefiks og suffiks Prefiks og suffiks er et ekstra visuelt hjelpemiddel, som blir ignorert av skjermlesere. Vi må alltid ha en beskrivende ledetekst. Prefiks og suffiks er plassert utenfor inndatafeltene de tilhører. Da unngår vi at de ikke skaper trøbbel i noen nettlesere, som kan sette inn et ikon i inndatafeltet (for eksempel ikoner for å vise eller lage passord).

[mrosvik]

I have included some of these examples in https://github.com/digdir/designsystemet/pull/4211