UU workshop 2023

HÞsten 2023 gjennomfÞrte Team Designsystem workshop i universell utforming for tre av produktteamene i Origo. Hovedfokuset var Ä Þke kunnskapen hos teamene pÄ hvordan man kan teste nettsider selv basert pÄ WCAG prinsippene. Workshopen ble ogsÄ en fin arena for oss Ä diskutere og lÊre underveis, derfor tenkte vi at en oppsummering av workshopen er nyttig for flere enn bare oss. SÄ her kommer en tekstlig versjon av vÄr UU-workshop med funn og lÊringspunkter.

Introduksjon

Det er naturlig at vi som lager designsystemet har domenekunnskap pÄ universell utforming. Vi jobber hardt for Ä sikre at komponentene vÄre oppfyller kravene i WCAG. Likevel er det noen ting vi ikke kan teste, spesielt med tanke pÄ hvordan komponentene fungerer i forskjellige situasjoner. Derfor Þnsker vi Ä dele vÄr kunnskap om hvordan du og ditt team kan teste egne lÞsninger.

Men hva er WCAG? spĂžr du kanskje. Kort fortalt er WCAG en veiledning for oss til Ă„ skape et mer inkluderende digitalt miljĂž. Les mer om WCAG her.

WCAG er delt inn i fire prinsipper som legger vekt pÄ at digitale tjenester skal:

  • vĂŠre mulig Ă„ oppfatte
  • vĂŠre mulig Ă„ betjene
  • vĂŠre mulig Ă„ forstĂ„
  • vĂŠre kompatible med ulike teknologier
Har du oppdaget feil i vÄre komponenter?

Hvis du oppdager noe som ikke er riktig med vÄre komponenter ta kontakt med oss! Vi setter pris pÄ din hjelp med Ä gjÞre designsystemet vÄrt bedre!

Test selv

SÄ hvordan teste at en nettside fÞlger WCAG-prinsippene? Vi Þnsket Ä lage en workshop som skulle passe for et tverrfaglig team og optimalisere for at alle skal klare Ä teste sin nettside eller tjeneste. Derfor valgte vi enkle verktÞy som man raskt kan ta i bruk direkte i nettleseren. De er ikke nÞdvendigvis de beste, og av erfaring er det lurt Ä teste med ulike verktÞy fordi testverktÞyene kan finne ulike feil. Vi hadde ogsÄ en liste over nettsider vi visste hadde feil som deltakerne kunne teste pÄ.

Start her

Installer nettleser extension:

Finn en nettside du mistenker kan ha feil. Gjerne en side du mÄ bruke et skjema, bestille billett, eller booke et rom.

NĂ„ skal du teste nettsiden fra ulike brukerperspektiv. Dette kan innebĂŠre brukere som har vanskeligheter med:

  • syn - svaksynt, blind, tĂ„kesyn, fargeblind
  • motorikk - skjelving, smerter i hĂ„nd eller bruk av Ă©n hĂ„nd.
  • eplepsi/migrene
  • kognitive - ukonsentrert, dysleksi, stresset, redd, usikker
Visste du at?

1 av 5 av oss har en form for funksjonsnedsettelse? I tillegg kan alle bli utsatt for en midlertidig funksjonsnedsettelse, kanskje har du operert en hÄnd? Eller kanskje du er i en situasjon hvor du ikke klarer Ä hÞre, lese eller trykke? Kanskje du ofte holder et barn i den ene armen, men trenger Ä bruke en digital lÞsning samtidig? Vi kan alle fÞle pÄ frustrasjoner og lite mestring i mÞte med digitale lÞsninger og vi har en tendens til Ä skylde pÄ oss selv, men det handler oftest om at lÞsningen ikke er tilgjengelig for alle.

Oppgave 1 - Mulig Ă„ oppfatte

Selv om testverktĂžyet finner feil under alle prinsippene i WCAG, er de vanligste feilene man finner knyttet til vanskelig Ă„ oppfatte. Derfor starter vi oppgavene med testverkĂžyet Wave.

  1. NÄr du er pÄ din valgte nettside trykk pÄ Wave-ikonet i listen over dine nettleser-extensions. Wave tester en og en side av gangen. Bli kjent med verktÞyet og resultatene. Hva sier verktÞyet om feilene?
  2. Se pÄ din valgte nettside pÄ 400% zoom. Er det mulig Ä oppfatte innholdet pÄ nettsiden?
  3. Se pÄ din valgte nettside med mobil og i landskapsmodus. Er det mulig Ä oppfatte innholdet pÄ nettsiden?

De vanligste feilene og hva de betyr:

Nedenfor kan du lese om de vanligste feilene deltakerne i workshopen fant pÄ oppgave 1.

1. Missing alternative text

Den vanligste feilen er missing alternative text. Dette innebÊrer at bildene ikke har en alternativ tekst i img-taggen i kode. Om et bilde illustrerer noe som er viktig for Ä forstÄ innhold eller funksjon pÄ nettsiden vil de som bruker skjermleser ikke oppfatte denne informasjonen.

NÄr man skal skrive alternative tekster sÄ tenk brukeropplevelse for skjermleserbrukere, hva er det man Þnsker Ä formidle? Er det stemning, viktig informasjon eller veiledning? NRK har skrevet en god beskrivelse av hvordan skrive alternative tekster.

Om bildet bare er rent dekorativt, sÄ kan man vurdere om det er nÞdvendig Ä beskrive bildet med alternativ tekst slik at skjermleseren ikke leser opp unÞdvendig eller irrelevant informasjon. Men om du velger Ä ikke ha en alt-tekst sÄ mÄ du huske Ä ha med alt-attributten, men la den vÊre tom ellers vil src="" bli lest opp av skjermleseren. Tenk brukeropplevelsen ved beskrivelse av bildet/bildene.

<img alt="" class="dekor" src="bildeavdekoren-2-copy.jpg" />

Alternativ tekst til bilder er ogsÄ slik sÞkemotorer forstÄr innholdet pÄ nettsiden din, sÄ det kan hjelpe nettsiden din med SEO. Alternativ tekst pÄ bildet er ogsÄ det som dukker opp nÄr bildet ikke lastes opp, som kan vÊre til hjelp ved feilsÞking.

2. Missing form label

Missing form label betyr at et skjemaelement ikke har et korrekt tilknyttet label. Dette gjÞr at funksjonen eller formÄlet til skjemaelementet ikke blir oppfattet av skjermleserbrukere. Label gir ogsÄ synlig veiledning/beskrivelse og stÞrre klikkbare omrÄder for skjemaelementet.

For Ä unngÄ manglende label, bÞr man alltid sÞrge for at hvert skjemaelement har et tilknyttet label.

For eksempel, hvis du har en tekstboks for brukernavn, kan du legge til en tilknyttet label ved Ă„ inkludere fĂžlgende HTML-kode:

<label for="username">Brukernavn:</label>
<input type="text" id="username" name="username" />

Her matcher for-attributtet i <label> med id-attributtet til det tilsvarende skjemaelementet (<input>). Dette sikrer en klar og forstÄelig tilknytning mellom label og input, og hjelper skjermlesere med Ä riktig presentere informasjon om formÄl og funksjon til brukeren.

Om du ikke Þnsker Ä ha et synlig label over ditt skjemaelement kan du fortsatt ha en label men legge til en pkt-sr-only klasse, altsÄ en CSS klasse som visuelt skjuler label men blir lest opp av skjermleser.

3. Empty link / Linked image missing alternative text

”Empty link” er en lenke som ikke har noe tekstinnhold eller alternativ tekst. Dette kan skape forvirring for brukere, spesielt de som bruker skjermlesere som ikke fĂ„r tilstrekkelig informasjon om lenkens formĂ„l. Men ogsĂ„ forvirrende for andre brukere hvis det ikke er synlig at dette er en lenke eller man ikke forstĂ„r dens formĂ„l. Ofte er dette en feil som dukker opp nĂ„r man bruker bilder som lenke.

For Ă„ lĂžse disse problemene, bĂžr du legge til relevant tekst eller alternativ tekst til linken eller bildet. Her er noen eksempler:

Lenke:

<!--Feil: Lenken har ingen tekst-->
<a href="https://eksempel.com"> </a>

<!--Riktig: Legg til tekst inni lenken-->
<a href="https://eksempel.com">GĂ„ til eksempel.com</a>

Bilde i en lenke:

<!--Ikke sÄ bra: Mangler alternativ tekst for bildet-->
<a href="https://eksempel.com"><img src="ikon.png" alt="Ikon" /></a>

<!--Bedre: Beskrivende alternativ tekst-->
<a href="https://eksempel.com"
  ><img src="ikon.png" alt="GĂ„ til hovedsiden"
/></a>

<!--Bedre: Beskrivende aria label-->
<a href="https://eksempel.com" aria-label="GĂ„ til hovedsiden"
  ><img src="ikon.png" alt=""
/></a>

Hvordan skrive gode lenketekster? Her er det viktig Ä tenke pÄ brukeropplevelsen for alle, for eksempel:

  • UnngĂ„ lenketekst som “Klikk her”, “Mer” og “Les mer”. Slike lenker kan vĂŠre forvirrende nĂ„r de leses av en skjermleser uten noe kontekst.
  • Bruk unik lenketekst der det er mulig. Brukere av hjelpeteknologi kan oppleve problemer med duplisert lenketekst.
  • Det er akseptabelt Ă„ lenke en hel setning, men unngĂ„ lengre enn det.
  • NĂ„r du har en lenketekst med full URL-adresse bĂžr du tenke pĂ„ brukere som mĂ„ uttale den hĂžyt og de som mĂ„ lytte til en skjermleser.
Visste du at?

Bruk ARIA-attributter med forsiktighet. Dette fordi tolkning, implementering og stĂžtte i de ulike hjelpeteknologiene kan variere. Og i flere tilfeller kan feil bruk av ARIA-attributter overstyre standard nettleser-funksjoner. Å skape meningsfulle lenketekster, bruke riktig HTML-elementer, og fĂžlge andre beste praksiser for tilgjengelighet er viktigere enn Ă„ inkludere ARIA-attributter.

4. Contrast errors

Contrast errors er knyttet til kontrasten mellom tekst og bakgrunn. Kontrasten er avgjÞrende for at teksten skal vÊre tydelig lesbar, spesielt for personer med nedsatt syn, fargeblindhet og andre visuelle utfordringer. DÄrlig kontrast gjÞr teksten mindre lesbar og brukere kan vÊre nÞdt til Ä anstrenge Þynene mer for Ä skille tekst fra bakgrunnen. Dette kan vÊre spesielt uheldig i lengre perioder med skjermbruk og kan fÞre til hodepine og tretthet. I tillegg til visuelle utfordringer kan dÄrlig kontrast ogsÄ pÄvirke brukere med for eksempel dysleksi eller kognitive utfordringer. Klart definerte kontraster kan forbedre lesbarheten og redusere risikoen for feiloppfatninger.

Hva kan man gjÞre med kontrastfeil? Retningslinjene i WCAG spesifiserer krav til minimum kontrastforhold mellom tekst og bakgrunn. Dette kan du sjekke med vÄr kontrastsjekker om du jobber i Oslo kommune. Ellers finnes det mange kontrastverktÞy der ute du kan bruke.

Du bÞr ogsÄ bruke farger med omhu. Det er viktig Ä tenke pÄ at dette ikke bare gjelder kontrasten mellom tekst og bakgrunn, men ogsÄ kontrasten mellom elementer. Forsikre deg om at fargekombinasjonene du velger Ä ha ved siden av hverandre ogsÄ oppfyller tilgjengelighetskravene, siden testverktÞy som Wave ikke sjekker dette.

Eksempel pÄ vanskelig Ä oppfatte for fargeblinde:

Ved Ä fokusere pÄ kontrasten pÄ tjenesten vi lager, bidrar vi til Ä gjÞre innholdet mer tilgjengelig for alle brukere. Dette oppfyller ikke bare WCAG-kravene, men det gir ogsÄ en bedre brukeropplevelse.

Hva testverktĂžyet ikke registrerte

Det var flere ting vi oppdaget under manuell testing av prinsippet mulig Ä oppfatte som testverkÞyet ikke gjorde oss oppmerksomme pÄ. Noen eksempler pÄ dette var:

RekkefÞlger. Viktig informasjon eller funksjon som kommer etter en liste eller inputfelt. Et eksempel var da en deltaker fant filtreringsfunksjon som kom etter en veldig lang liste. Dette kan fÞre til at en bruker ikke fÄr med seg at det finnes en filteringsfunksjon fordi den er utenfor synsfelt, eller de mÄ hÞre pÄ/navigere seg gjennom en hel liste fÞr den kan filtreres.

Video, animasjon og lyd. Video, animasjon og lyd skal kunne stoppes av brukeren selv for Ä imÞtekomme personer som kan oppleve epileptiske anfall eller har konsentrasjonsvansker. Et eksempel pÄ dette fra workshopen var en bildekarusell med viktig informasjon som ble borte etter 7 sekunder. Om animasjoner, video eller lyd inneholder viktig informasjon mÄ det gis en alternativ presentasjon av dette.

400% zoom, mobil og landskap. At nettsider er tilpasset ulike skjermstÞrrelser er viktig ikke bare for brukervennlighet, men ogsÄ for tilgjengelighet. Eksempler fra workshopen viste at ved 400% zoom, noe som er et krav i WCAG, hadde nettsiden masse tomrom, noe som kan fÞre til at brukeren ikke oppfatter innholdet eller mÄ scrolle mye. Det var ogsÄ eksempler pÄ at elementer overlapper hverandre slik at man ikke oppfatter innhold eller ikke fÄr brukt funksjoner som knapper eller inputfelt.

Oppgave 2 - Mulig Ă„ betjene

I oppgave 1 kunne man se at testverktÞyet Wave ikke fÄr med seg alle feil. Dette gjelder spesielt under prinsippet mulig Ä betjene og forstÄelig. Derfor er det viktig med manuelle tester av nettsiden. SÄ la oss teste med en skjermleser og tastatur!

  1. Silktide er et enkelt simuleringsverktĂžy som simulerer ulike funksjonsnedsettelser. GĂ„ til blindness-fanen og test nettsiden med skjermleseren.
  2. Test nettsiden ved Ă„ bare bruke tastatur.
    • Tab er fremover
    • Tab + shift er bakover
    • Space for Ă„ ta et valg
    • Enter for Ă„ aktivere funksjon
    • Bruk piltaster for Ă„ navigere

Klarer du Ă„ betjene nettsiden? FĂ„r du navigert deg frem til det du mener er hovedfunksjonen med nettsiden? FĂ„r du bestilt billett, fylt ut skjema eller booket rom?

Greit Ă„ vite

Skjermleseren til Silktide blir brukt for enkelhetens skyld i workshop, ellers ville vi brukt tiden pÄ opplÊring av skjermleser. Silktide fungerer ikke akkurat som de mest brukte skjermleserne JAWS, VoiceOver eller NVDA, og den viser seg Ä ha litt bugs. SÄ vi anbefaler Ä teste med tungvekterne nÄr man har blitt litt bedre kjent med konseptet.

De vanligste feilene og hva de betyr

Nedenfor kan du lese om de vanligste feilene deltakerne i workshopen fant pÄ oppgave 2.

Skjemaelementer

Utilgjengelige skjemaelementer gÄr igjen som feil ved Ä teste om nettsiden er mulig Ä betjene. Ikke tilgjengelige inputfelt som for eksempel select, kalender, eller dropdowns i menyer er ofte avgjÞrende for Ä kunne gjÞre det man skal pÄ en nettside.

I workshopen oppdaget vi gjentatte feil knyttet til kalendere. Ved nĂŠrmere titt pĂ„ koden kunne man se input type=”text” og egenprodusert JavaScript-kode. Denne tilnĂŠrmingen er imidlertid ofte utilstrekkelig for Ă„ stĂžtte skjermlesere eller tastaturnavigasjon, med mindre koden er spesifikt utformet med tanke pĂ„ Ă„ gjĂžre kalenderen tilgjengelig for disse verktĂžyene.

SĂ„ hva kan man gjĂžre for Ă„ lage tilgjengelige skjemaelementer? Det er alltid en god regel Ă„ bruke semantisk riktig HTML fĂžr andre lĂžsninger. Skjermlesere og andre hjelpeteknologier bruker HTML til Ă„ tolke og presentere innholdet, og moderne nettlesere gir deg innebygd funksjonaliteten for enkelte HTML-elementer. Som for eksempel input type=”date” for kalenderfunksjonalitet. Semantisk riktig HTML forbedrer derfor tilgjengeligheten. Men det aller viktigste man kan gjĂžre er selvfĂžlgelig Ă„ teste under utvikling og kjĂžre brukertester.

Fokusmarkering

Manglende eller lite tydelig fokusmarkering pÄ aktive elementer var en gjentakende feil ved Ä betjene med bare tastatur. Fokusmarkering er visuelle indikatorer som vises rundt et aktivt element pÄ en nettside nÄr det fÄr tastaturfokus.

Det er flere brukere som er avhengig av tastaturnavigering pÄ grunn av fysiske begrensninger. Fokusmarkering sikrer at disse brukerne tydelig kan se hvor de befinner seg pÄ nettsiden. Selv for personer uten funksjonshemminger kan tastaturnavigasjon vÊre mer effektiv i visse situasjoner. For eksempel, hvis musen ikke er tilgjengelig eller for brukere som foretrekker tastaturnavigasjon. Den nyeste versjonen av WCAG, WCAG 2.2, anbefales det en fokusindikator pÄ minst 2 piksler.

Dialog/Popups

Dialog og popups er ment for Ä vise midlertidig informasjon. En dialog kan for eksempel vÊre et vindu som du mÄ godkjenne/avvise informasjonskapsler, og en popup kan vÊre midlertidig informasjon eller reklame som du mÄ krysse vekk.

Disse kan vÊre irriterende for enhver, men for de som bruker skjermleser og tastatur kan disse vÊre med pÄ Ä hindre deg fra Ä kunne bruke nettsiden. Vi fant feil der man ble sittende fast i dialogboksen med skjermleser og det var ikke mulig Ä lukke eller trykke pÄ knapper. Men oftest dukket ikke dialogboksen opp i skjermleseren i det hele tatt, sÄ du aldri fikk mulighet til Ä fÄ viktig informasjon eller Ä godkjenne eller avvise informasjonskapsler.

For Ä minimere problemene knyttet til dialoger og popups, bÞr utviklere og designere ta hensyn til tilgjengelighetsstandarder, implementere responsiv design, sÞrge for riktig tastaturnavigasjon og fÞlge beste praksis for Ä informere brukere om dialogens formÄl. Test ogsÄ grundig pÄ tvers av ulike nettlesere og enheter for Ä sikre en konsistent opplevelse.

En “skiplink” er en navigasjonslenke som vanligvis er plassert Ăžverst pĂ„ en nettside og gir brukere muligheten til Ă„ hoppe over gjentatt navigasjon og gĂ„ direkte til hovedinnholdet pĂ„ siden. FormĂ„let med skiplink er Ă„ forbedre navigasjonen og brukeropplevelsen for de som er avhengige av tastaturnavigasjon eller andre alternative metoder. NĂ„r en bruker aktiverer skiplinken, hopper de over gjentatt navigasjon, for eksempel menyelementer eller andre strukturelle elementer, og gĂ„r rett til hovedinnholdet pĂ„ siden.

En gjentakende mangel pÄ nettsidene var denne skiplinken. Brukeren mÄ da navigere seg gjennom masse irrelevant informasjon fÞr man kommer til det man er pÄ nettsiden for. Og faren for Ä bli sittende fast i ulike elementer er stor fÞr du i det hele tatt har fÄtt gjort noe av det du skulle pÄ nettsiden.

Skiplinker bidrar til en mer effektiv og behagelig brukeropplevelse ved Ä gi brukere kontroll over hvordan de navigerer gjennom nettstedet. Dette gjelder ikke bare pÄ fÞrstesiden, i workshopen opplevde vi flere omrÄder man gjerne skulle hatt en skiplink.

Oppgave 3 - ForstÄelig

Prinsippet forstÄelig betyr at du skal kunne forstÄ hvordan lÞsningen skal brukes og forstÄ den informasjonen nettsiden formidler. Denne oppgaven kan vÊre gjentakende for hva du tidligere har funnet i de andre oppgavene. Men vi bruker denne oppgaven til Ä oppsummere litt og gi deg mulighet til Ä teste ut de andre simulatorene i Silktide. Finner du noe nytt ved bruk av fargeblind-simulatoren eller tunnelsyn? Hva med dysleksi? Test nettsiden med simulatorene i Silktide.

De vanligste feilene og hva de betyr:

Nedenfor kan du lese om de vanligste feilene deltakerne i workshopen fant pÄ oppgave 3.

UforstÄelig veiledning

De fleste nettsider deltakerne testet viste seg Ä ha uforstÄelig informasjon pÄ knapper, linker, checkboxer, inputfelt, feilmeldinger eller advarsler.

Vi fant ogsĂ„ uforstĂ„elige knapper med forkortelser som “ingen ank.” som betydde “ikke ledig rom”, “SĂžk etter rooms”, eller “Ikke noe problem” i tekst pĂ„ en knapp som egentlig betydde “done”.

Problemet med uforstÄelig informasjon pÄ disse elementene er en betydelig utfordring for tilgjengelighet, fordi konsekvensene er at for eksempel skjermleserbrukerne ikke har mulighet til Ä betjene nettsiden. For Ä lÞse disse problemene kan du huske pÄ Ä:

  • Bruke klare og beskrivende tekster for alle interaktive elementer.
  • Labels til inputfelt og checkboxer/radiobuttons.
  • UnngĂ„ bruk av vage, generiske eller duplikate formuleringer.
  • Gi konkrete instruksjoner og veiledning i feilmeldinger.

Her er noen flere eksempler pÄ problemer med uforstÄelig informasjon, og hva man kan gjÞre:

Knapper og linker

  • Problem: Knapper eller linker med tekster som bare sier “Klikk her” eller “Les mer” gir ikke tilstrekkelig informasjon om den forventede handlingen.

  • LĂžsning: Gi knapper og linker beskrivende tekster som klart formidler hva som skjer nĂ„r de trykkes, for eksempel “Send skjema”, “GĂ„ til handlekurven”, “Les detaljer om produktet.” Noen ganger kan det vĂŠre vanskelig Ă„ beskrive funksjonen med korte ord. Men dette kan du lĂžse med Ă„ ha tekst som bare er tilgjengelig for skjermleser:

<a href="/artikkel">
  Les mer
  <span class="pkt-sr-only">om vÄre nyeste produkter</span>
</a>

<button type="button">
  <span class="pkt-sr-only">Åpne meny</span>
  <svg aria-hidden="true" ...><!-- Ikon her --></svg>
</button>

Inputfelt

  • Problem: Checkboxer eller inputfelt uten klare labels eller med for generisk tekst gir ikke tilstrekkelig informasjon om hva de representerer.

  • LĂžsning: Legg til tydelige labels som beskriver formĂ„let med checkboxen eller inputfeltet. For eksempel, “Godta vilkĂ„rene og betingelsene” for en checkbox.

Feilmeldinger

  • Problem: Feilmeldinger som bare sier “Feil” eller “Ugyldig inndata” gir ikke brukeren nok informasjon om hva som gikk galt og hvordan det kan rettes opp.

  • LĂžsning: Gi detaljerte feilmeldinger som identifiserer problemet og gir veiledning om hvordan brukeren kan korrigere det. For eksempel, “Passordet mĂ„ vĂŠre minst 8 tegn og inneholde minst Ă©n stor bokstav og ett tall.”

Struktur

UforstÄelig eller vanskelig struktur var noe vi fant pÄ flere av nettsidene som ble testet. Spesielt ved navigering med skjermleser og tastatur. Dette var ogsÄ noe testverktÞyet Wave ga alerts om:

Empty heading: Tom overskrift (leses opp av skjermleser, usynlig for de som ser) En tom overskrift refererer til et HTML <h1>- til <h6>-element som ikke inneholder noen tekst. NÄr overskriften er tom, blir ikke informasjonen formidlet til skjermleserbrukerne, men de fÄr vite at den finnes noe som skaper forvirring.

Skipped heading level: Hoppet over overskriftsnivÄ - ikke riktig rekkefÞlge pÄ overskrifter.Dersom overskriftsnivÄene ikke fÞlger en logisk rekkefÞlge (for eksempel Ä hoppe fra <h2> til <h4> uten en <h3> imellom), kan det fÞre til forvirring for brukere av hjelpeteknologi. Dette kan pÄvirke den oppfattede strukturen og organiseringen av innholdet.

No heading structure: Ingen overskriftsstruktur Overskrifter (<h1>-<h6>) gir viktig dokumentstruktur, oversikter og navigasjonsfunksjonalitet for brukere av hjelpeteknologi. SĂžrg for en klar, konsistent overskriftsstruktur, vanligvis med Ă©n <h1> og underoverskrifter etter behov. Med unntak av svĂŠrt enkle sider, bĂžr de fleste nettsider ha en overskriftsstruktur.

For Ä ha en forstÄelig struktur pÄ nettsiden er det viktig Ä gi meningsfull tekst til overskrifter og organisere dem i en logisk rekkefÞlge. Dette gir en bedre opplevelse for brukere som er avhengige av hjelpeteknologi og for alle som samhandler med nettstedet ditt.