Kravbanken

Print krav

Krav til Sprog

Det er et krav, at alle tekster i selvbetjeningsløsninger skal være skrevet i et enkelt, klart og forståeligt sprog, der er tilpasset løsningens målgruppe.

Tekster og sprog i digitale selvbetjeningsløsninger skal leve op til følgende krav:

1.1 Følg gældende skrivevejledninger: Når din løsning skal bo på portaler som borger.dk, virk.dk eller sundhed.dk, skal du følge de gældende skrivevejledninger. Læs mere
Læs mere om '1.1 Følg gældende skrivevejledninger'
Du opfylder kravet, når:
  • 1.1.a Teksterne følger skrivevejledningen for den side/portal, løsningen skal ligge på. 
  • 1.1.b Teksterne er målrettet din målgruppe.
Tag udgangspunkt i de fællesoffentlige portalers skriveguides, eksempelvis skriveguiden for borger.dk. De fællesoffentlige skriveguides er udviklet på baggrund af portalernes respektive målgrupper, fx borgere og virksomheder. Der findes også andre guides, som kan være gode til inspiration. Blandt andet har Europa-Kommissionen udarbejdet brochuren ‘Skriv klart’, som indeholder mange konkrete råd. 
1.2 Brug et enkelt og klart sprog: Skriv letforståeligt og forklar alle fagudtryk. Læs mere
Læs mere om '1.2 Brug et enkelt og klart sprog'
Du opfylder kravet, når: 
  • 1.2.a Løsningens tekster er korte og præcise, uden kancellisprog, og fagudtryk er forklaret.
For at sikre at sproget er letlæseligt for en bred målgruppe, bør du undgå at bruge myndighedssprog og lange sætninger. Hvis der er særlige fagudtryk, som er nødvendige at få med, skal de forklares. Undgå paragrafreferencer eller tungt lovsprog. Forklar loven i stedet for at citere den og link evt. til relevant information, hvis der er brug for mere uddybning.
Du kan med fordel bruge personas i dit arbejde. Det er vigtigt, at professionelle kommunikationsfolk udarbejder dine tekster.
1.3 Vejled brugerne: Skriv handlingsanvisende og hjælp brugerne trin for trin og forklar brugerne, hvad de skal gøre for at komme videre. Læs mere
Læs mere om '1.3 Vejled brugerne'
Du opfylder kravet, når: 
  • 1.3.a Teksterne er handlingsorienterede og hjælper brugeren videre gennem løsningen.
  • 1.3.b Brugeren har adgang til uddybende information undervejs i løsningen (hjælpetekster). 
Du skal hjælpe brugerne, hvis de ikke udfylder et felt helt korrekt eller har glemt at oplyse nødvendige informationer i en formular. Hjælpeteksterne skal være specifikke og handlingsanvisende. Fortæl hvad og hvor, der skal rettes for at komme videre i forløbet. Du kan fx tilføje en instruktion og en visuel markering af det felt, som brugeren skal opdatere.
1.4 Giv meningsfuld feedback på fejl: Fejlmeddelelser skal være til at forstå for brugerne, så de ved, hvad de skal ændre for at komme videre. Læs mere
Læs mere om '1.4 Giv meningsfuld feedback på fejl'
Du opfylder kravet, når:
  • 1.4.a Det tydeligt fremgår for brugeren, hvad der skal rettes ved fejlindtastninger. 
Fejlbeskeder skal være til at forstå og have færrest muligt tekniske udtryk. Hvis brugeren klikker på et dødt link, eller hvis serveren er overbelastet, skal du forklare, hvad der er sket. En fejlbesked eller fejlside skal derfor så klart som muligt beskrive, hvad der er galt, hvordan brugeren kan komme videre, eller hvornår fejlene forventes rettet. 
1.5 Fejlmeddelelser skal være skrevet på dansk: Sørg for, at brugeren får danske fejlmeddelelser, herunder system- og tekniske fejl, der ofte er på engelsk. Læs mere
Læs mere om '1.5 Fejlmeddelelser skal være skrevet på dansk'

Du opfylder kravet, når: 

  • 1.5.a Fejlmeddelelser er skrevet på dansk.

Alle fejlmeddelelser og feedback skal være skrevet på dansk og i et letforståeligt sprog med færrest mulige tekniske udtryk. Det gælder både meddelelser om manglende udfyldelse af påkrævede indtastningsfelter i løsningen samt system- og tekniske fejl som fx ”Fejl 404”.

Print krav

Krav til Design, flow og funktionalitet

Det er et krav, at brugerfladens design, funktionalitet og forløbet igennem selvbetjeningen skal være logisk, konsistent og enkelt at gennemføre for brugerne.

Opbygning og design i digitale selvbetjeningsløsninger skal leve op til følgende krav:

2.1 Overhold designmanualer: Der findes designmanualer for de fællesoffentlige portaler. Hvilken manual, der er gældende, afhænger af, om din løsning er målrettet borgere eller erhvervsliv. Læs mere
Læs mere om '2.1 Overhold designmanualer'
Kravet er opfyldt, når:
  • 2.1.a De gældende designmanualer er overholdt, dvs. borger.dk's HTML-guide og Virk.dk's Designmanual.
  • 2.1.b Løsningen er integreret på den eller de relevante fællesoffentlige portaler, dvs. borger.dk, Virk.dk og sundhed.dk.
Du skal overholde designmanualen, hvis din løsning skal på Virk.dk og/eller borger.dk. Manualerne indeholder principper for og metoder til, hvordan du skal designe din selvbetjeningsløsning. Det kan fx være:
  • hvilke farver og ikoner, du skal bruge
  • hvordan html-koden skal opbygges
  • hvordan en topmenu skal se ud og opføre sig
2.2 Forbered brugerne, inden de går i gang: Brugeren skal vide, hvor omfattende løsningen er, og hvad der skal til, for at de kan gennemføre den. Læs mere
Læs mere om '2.2 Forbered brugerne, inden de går i gang'
Kravet er opfyldt, når: 
  • 2.2.a Opgavens omfang er klart for brugeren (eks. antal trin i en løsning) inden løsningens start.
  • 2.2.b Allerede ved løsningens start bliver brugerne oplyst om, hvilke oplysninger brugeren skal anvende for at gennemføre løsningen, fx indtægtsoplysninger, betalingsmuligheder, lejekontrakt ved ansøgning om boligstøtte, eller at der ved flytning også skal tages stilling til lægeskift.
Du skal afstemme brugernes forventninger til selvbetjeningsforløbet, fx fortælle hvor mange trin brugeren skal igennem, hvor lang tid det vil tage, om løsningen ikke kan bruges på bestemte platforme (fx mobile platforme) osv.
 
Inden brugerne går i gang, skal de desuden have at vide, hvad de skal have fundet frem eller taget stilling til for at gennemføre processen. Det kan fx være NemID, indtægtsoplysninger, lejekontrakt ved ansøgning om boligstøtte eller en oplysning om, at løsningen kræver fuldmagt, eller at man ved flytning også skal tage stilling til lægeskift.
2.3 Opbyg et logisk og konsekvent forløb: Sørg for, at løsningen opbrydes i et - for brugerne - logisk forløb og i et meningsfuldt og konsekvent design. Læs mere
Læs mere om '2.3 Opbyg et logisk og konsekvent forløb'
Kravet er opfyldt, når:
  • 2.3.a Brugeren bliver oplyst om, hvor i løsningen han/hun befinder sig (fx hvor mange trin, der er tilbage).
  • 2.3.b Løsningens brug af navigationselementer (fx brug af piletaster og knapper) er logisk og konsekvent.
Løsningen skal inddeles i trin, som er logiske og giver brugerne et overblik. Målet er at gøre komplekse ansøgninger og forespørgsler overskuelige for brugerne. 
 
Du skal hjælpe brugeren ved at lave et konsekvent design. Det kan du fx gøre ved altid at placere en ‘frem’- eller ‘næste’-knap det samme sted på siden, så brugerne ikke skal lede efter den samme knap flere gange. Du skal tydeligt vise, hvilke knapper der er positive og negative - fx ja- og nej-knapper eller bekræft- og annuller-knap. Bevar den samme placering af navigationselementer, så brugeren ikke bliver forvirret eller vælger en forkert knap.
2.4 Giv brugeren et resumé: Indtastede oplysninger skal opsummeres for brugeren, inden løsningen afsluttes (dvs. inden en ansøgning indsendes). Læs mere
Læs mere om '2.4 Giv brugeren et resumé'
Kravet er opfyldt, når:
  • 2.4.a Brugeren får en opsummering af de indtastede oplysninger, inden løsningen afsluttes (dvs. inden en ansøgning indsendes).
2.5 Tjek og validér oplysninger før indsendelse: Brugeren må først kunne indsende oplysninger, når alle obligatoriske felter i løsningen er udfyldt. Læs mere
Læs mere om '2.5 Tjek og validér oplysninger før indsendelse'
Kravet er opfyldt, når:
  • 2.5.a Brugeren kun kan indsende oplysninger, såfremt alle påkrævede oplysninger er indtastet i løsningen.
  • 2.5.b Indtastningsfelterne i videst mulige omfang validerer oplysninger, så risikoen for fejlindtastninger og formmæssige fejl minimeres.
Du skal fejlsikre din selvbetjeningsløsning, så brugeren aldrig kan få lov at gennemføre den, før alle oplysninger er givet. 
 
Din løsning skal så vidt muligt validere brugernes indtastede oplysninger. På den måde minimerer du risikoen for, at brugerne laver fejlindtastninger, som fx et ugyldigt telefonnummer på kun syv cifre.
 
Du kan med fordel bede brugeren om at tjekke og validere indtastet indhold i forbindelse med opsummeringen.
2.6 Afslut med en kvittering: Vis brugerne en kvitteringsside, når de har gennemført et forløb. Læs mere
Læs mere om '2.6 Afslut med en kvittering'

Kravet er opfyldt, når: 

  • 2.6.a Løsningen afsluttes med en tydelig kvittering (som minimum at den er modtaget, sags- eller reference nummer, hvornår brugeren kan forvente at få svar, hvor der kan stilles spørgsmål eller indsendes ændrede oplysninger).
  • 2.6.b Indtastet indhold i ansøgningen fremgår af kvitteringen og kan printes i et læsbart format.
  • 2.6.c Det videre forløb fremgår tydeligt for brugeren efter afslutning.

Vis altid brugerne en kvitteringsside, når de har gennemført et forløb. På den måde sikrer du dig, at brugerne ikke er i tvivl om, at deres oplysninger er sendt af sted, og er undervejs i systemet. En kvittering kan leveres på mange måder, fx pr. sms, NemSMS, til den Digitale Postkasse eller som en kvitteringsside sidst i løsningen - en side som skal kunne printes i et læsbart format og eventuelt videresendes som en e-mail, downloades og/eller gemmes. Kvitteringssiden skal indeholde:

  • ansvarlig myndighed
  • bekræftelse på at ansøgningen er modtaget
  • et referencenummer
  • hvornår der kan forventes et svar
  • hvor brugeren kan stille spørgsmål
  • opsummering af, hvad brugeren har indtastet
2.7 Vis din afsender: Lav et design, hvor den ansvarlige myndighed altid fremgår i brugerfladen. Læs mere
Læs mere om '2.7 Vis din afsender'
Kravet er opfyldt, når: 
  • Afsenderen, dvs. myndigheden, fremgår tydeligt af selvbetjeningsløsningen. 
Afsenderinformation er vigtigt for brugerne, fordi det giver dem mulighed for at vurdere sidens troværdighed. Det har også betydning for, om de har lyst til at opgive personlige oplysninger på siden. Vis hvem der står bag løsningen, og hvor de oplysninger, man indtaster, bliver sendt hen. Der er også vigtigt at du angiver, hvor brugeren kan få hjælp, hvortil ændrede oplysninger kan sendes etc.
 
Der er forskellige regler for, hvordan afsender skal fremgå, alt efter om din løsning er rettet mod borgere eller virksomheder.
2.8 Optimér til relevante platforme: Tænk interaktion, flow og funktionalitet igennem i forhold til forskellige skærmstørrelser og devices. Læs mere
Læs mere om '2.8 Optimér til relevante platforme'
Kravet er opfyldt, når:
  • 2.8.a Løsningen er optimeret visuelt og funktionelt, så den fremstår logisk på forskellige platforme og skærmstørrelser.
Det stiller særlige krav til din løsnings visuelle design, hvis den skal kunne besøges via mobile devices (fx med tablet eller smartphone) uden at forringe brugeroplevelsen. Sørg for at begrænse både dit indhold og funktionalitet til det absolut vigtigste, så brugeren ikke mister overblikket på en lille skærm.  Mindre skærme med touch-interaktion kræver en særligt tilpasset brugerflade - fx skal man kunne ramme links og knapper med fingeren uden at skulle zoome ud og ind hele tiden. Husk også, at der ikke kan uploades pdf-dokumenter fra en smartphone.
 
Du skal gøre din løsning responsiv, og kan med fordele designe din løsning og dens flow til en lille skærm og herefter opskalere den til større skærmstørrelser.
Test altid din løsning på forskellige skærmstørrelser, så du kan se, hvordan sider og funktionalitet opfører sig.
2.9 Optimér til browsere: Du skal sikre dig, at design og flow fungerer på de mest udbredte browsere. Læs mere
Læs mere om '2.9 Optimér til browsere'
Kravet er opfyldt, når: 
  • 2.9.a Løsningen gennemføres uden særlige tekniske softwarekrav påkrævet af brugerens udstyr. 
  • 2.9.b Løsningen fungerer i følgende browsere: Explorer 9 og nyere, seneste version af Safari, Chrome og Firefox.
Selvbetjeningsløsninger skal kunne fungere på de mest brugte versioner af de mest gængse browsere. Det kan fx være Internet Explorer, Safari, Chrome og Firefox. Ligeledes skal du sikre, at brugerne ikke skal installere specifikke programmer, filer eller plug-ins for at bruge din løsning. Samme princip gælder også, når du skal teste for browsere på mobile devices.
 
 
2.10 Brugertest: Der skal udføres afsluttende brugertest Læs mere
Læs mere om '2.10 Brugertest'

Den standardiserede fællesoffentlige brugertest skal bestås

Som ansvarlig myndighed er det dit ansvar at sikre, at løsningen har bestået den standardiserede fællesoffentlige brugertest før den gøres tilgængelig for brugerne. Brugertesten skal vise, at de relevante målgrupper kan gennemføre en relevant opgave som løsningen leverer med et minimum af spild og på en tilfredsstillende måde ved hjælp af løsningen.

Kravet om brugertest skal ikke ses som erstatning for brugerinddragelse og test i udviklingsfasen. For at løsningen bliver bedst mulig anbefales det, at brugerne løbende inddrages under udviklingen af løsningen, og at brugerne tester løsningen i udviklingsfasen.

Kravet er opfyldt, når løsningen har bestået den standardiserede fællesoffentlige brugertest.

 

Minimumskrav til løsningen

 

Bemærkninger

 

Gennemførsel

80% af testpersonerne skal kunne gennemføre selvbetjeningsløsningen.

 

Minimum af spild

80% af testpersonerne må ikke opleve en kritisk fejl.

En kritisk fejl er en fejl, som1) testpersonen ikke selv kan rette, og skal søge hjælp uden for løsningen. Eller 2) en fejl der betyder, at formålet med løsningen ikke er opnået på trods af, at løsningen er gennemført.

 

Brugertilfredshed

Den samlede brugertilfredshed skal være minimum 4 på en skala fra 1-5, hvor 5 er det bedste. Tilfredsheden opgøres som et gennemsnit af alle testpersoners svar på samtlige spørgsmål.

Efter gennemførsel af selvbetjeningsløsningen bliver testpersonen stillet en række forhåndsdefinerede spørgsmål, der skal måle brugertilfredsheden med løsningen. Testpersonen svarer på en skala fra et til fem, hvor fem er det bedste. Brugertilfredshedsspørgsmålene er:

  • I hvilken grad oplevede du at kunne løse din opgave?
  • I hvilken grad følte du dig tryg i forløbet?
  • I hvilken grad indeholdt løsningen den relevante information?
  • I hvilken grad oplevede du sproget i løsningen som forståeligt?
  • I hvilken grad oplevede du løsningen som let at gennemføre?
  • I hvilken grad var den fornødne hjælp tilgængelig i løsningen?

Testpersonerne skal have mulighed for at svare ”Ved ikke/ikke relevant”.

 

 

Vejledninger og værktøjer

 

Print krav

Krav til Data, komponenter og standarder

Det er et krav, at data, komponenter og standarder skal indtænkes intelligent på tværs af brugerfladen i din selvbetjeningsløsning. Det er med til at øge effektiviteten internt i din organisation og til at forbedre brugernes oplevelse af det offentlige på nettet.

Digitale selvbetjeningsløsninger skal indtænke data og funktionalitet ud fra følgende krav:

3.1 Brug NemLog-in: NemLog-in skal bruges, hvis løsningen kræver et log-in. Læs mere
Læs mere om '3.1 Brug NemLog-in'
Kravet er opfyldt, når:
  • 3.1.a Løsninger, der kræver log-in, anvender NemLog-in.
  • 3.1.b For uddannelsesinstitutioner kan UniLogin og WAYF bruges som alternativ til NemLog-in.
NemLog-in er det fælles offentlige login. Du skal bruge NemLog-in, hvis din løsning kræver, at brugerne logger ind, fx. hvis løsningen indeholder eller behandler personlige eller personfølsomme oplysninger. Ét fælles login for alle de offentlige hjemmesider og selvbetjeningsløsninger sparer brugerne for besværet ved at skulle logge på flere gange. De slipper også for at skulle huske på flere forskellige passwords til alle de offentlige løsninger, de benytter. Uddannelses- og undervisningsinstitutioner må udover NemLog-in også bruge Uni-login eller WAYF (Where Are You From).
3.2 Genbrug data: Genbrug allerede eksisterende data i videst muligt omfang. Læs mere
Læs mere om '3.2 Genbrug data'
Kravet er opfyldt, når: 
  • 3.2.a. Løsningen så vidt muligt genbruger allerede eksisterende data, så brugeren ikke skal oplyse dette (genbrug af data).
Mange selvbetjeningsløsninger kræver, at en bruger skal udfylde personlige data om dem selv. Det kan fx være CPR-nummer, brugerens navn, adresse eller CVR-oplysninger. 
Hvis brugeren er logget ind, fx med NemID, skal sådanne oplysninger hentes, så felterne automatisk bliver udfyldt for brugeren. Autoudfyldning sparer tid og besvær for brugeren. Samtidig kan det give en mere effektiv sagsbehandling, fordi myndighederne får mulighed for at genbruge eksisterende viden om borgerne.
 
Du skal genbruge data, som du i forvejen har fået oplyst af brugeren, fx fra tidligere selvbetjening eller anden kontakt med din organisation. Eksempler på data, som kan genbruges, er information fra din myndigheds fagsystem eller fra grunddataprogrammet, som blandt andet stiller landkortdata til rådighed.
3.3 Genbrug komponenter: Genbrug allerede udviklede komponenter i videst muligt omfang. Læs mere
Læs mere om '3.3 Genbrug komponenter'
Kravet er opfyldt, når:
  • 3.3.a. Løsningen genbruger i videst muligt omfang allerede eksisterende komponenter, så du ikke behøver at udvikle dem, og de let kan integreres til andre fællesoffentlige løsninger (genbrug komponenter).
Du skal genbruge allerede udviklede komponenter i videst muligt omfang. Det kan fx være ‘Min side’ på borger.dk eller ‘Mit Virk’ på Virk.dk, Digital Post, Digital Fuldmagt, NemSMS etc. Det kan også være en række af de kortfunktionaliteter, som allerede eksisterer - eksempelvis borger.dk’s kort-funktion eller den digitale fuldmagtsløsning. Ved at genbruge komponenter og funktionalitet undgår du at bruge tid og penge på at udvikle noget, som findes i forvejen.
3.4 Brug fællesoffentlige, internationale og åbne standarder: Brug eksisterende standarder som fx OIO og åbne standarder. Læs mere
Læs mere om '3.4 Brug fællesoffentlige, internationale og åbne standarder'
Kravet er opfyldt, når:
  • 3.4.a Løsningen bruger fællesoffentlige, internationale og åbne standarder - fx korrekt datoformat.
Ved at bruge eksisterende standarder i din løsning sikrer du, at din selvbetjeningsløsning også kan fungere med eksisterende og fremtidige brugerflader, løsninger og fagsystemer. Åbne standarder og åbne arkitekturer er afgørende for, at din løsning kan videreudvikles og integreres med andre løsninger. For brugerfladen betyder det blandt andet, at du skal bruge korrekte formater fx for datoer og andre faste felter.
3.5 Tilpas efter besvarede spørgsmål: Løsningen skal i videst muligt omfang tilpasse spørgsmål efter allerede indtastede oplysninger. Læs mere
Læs mere om '3.5 Tilpas efter besvarede spørgsmål'
Kravet er opfyldt, når:
  • 3.5.a Løsningen tilpasser i videst muligt omfang spørgsmål på baggrund af tidligere svar (fx udelader spørgsmål om ægtefælle, hvis det tidligere er angivet, at man ikke er gift).
Hvis en bruger på et indledende trin fx har svaret, at han eller hun er ugift, så skal der ikke senere stilles spørgsmål om en eventuel ægtefælles indtjening. Din løsning skal altså designes fleksibelt og intelligent, så den tilpasser sig løbende efter de oplysninger, brugerne opgiver.
Du kan med fordel tænke i personas og brugersegmenter, når du udvikler din løsning, ligesom du kan genbruge data og viden ved fx NemID login.
3.6 Opbevar oplysninger sikkert: Du skal overholde persondatalovgivningen, cookielovgivningen og sørge for at opbevare følsomme oplysninger sikkert. Læs mere
Læs mere om '3.6 Opbevar oplysninger sikkert'
Kravet er opfyldt, når:
  • 3.6.a Personfølsomme oplysninger opbevares sikkert.
  • 3.6.b ISO 27001-stardarderne, DS 484, databeskyttelsesdirektivet/ cookielovgivning og persondatalovgivning efterleves.

Der skal være et ensartet højt niveau af informationssikkerhed i hele den offentlige sektor. Du skal være særligt opmærksom på sikkerheden, hvis din løsning behandler personfølsomme oplysninger. Det samme gælder fx for information om sundhed eller børn. Det er dit ansvar at sørge for sikkerhed og fortrolighed i din selvbetjeningsløsning, dvs. at du følger Persondataloven.

Du skal sikre, at dine løsninger følger Databeskyttelsesdirektivet. Statslige myndigheder skal følge den åbne standard for informationssikkerhed DS 484. Standarden sikrer, at alle aspekter vedrørende sikkerheden nøje overvejes med udgangspunkt i en risikovurdering. Alle øvrige offentlige myndigheder bør også efterleve standarden. ISO 27001-standarderne er også relevante.

Hvis din løsning også skal fungere på mobile platforme, skal du følge de samme retningslinjer som for øvrige løsninger. Dog er der en række særlige opmærksomhedspunkter i forhold til sikkerhed, som kan findes i det offentliges guide til mobiludvikling.

3.7 Brug tællerscript (OBS! Udfaset for nye løsninger): Indsaml statistik om brugen af din løsning ved hjælp af et tællerscript. Læs mere
Læs mere om '3.7 Brug tællerscript (OBS! Udfaset for nye løsninger)'

For løsninger på borger.dk

Per 26. maj 2017 er det ikke længere muligt at få udstedt tæller-id og dermed ikke muligt at installere tællerscript og opsamle statistik for nye borgerrettede selvbetjeningsløsninger. Det skyldes ændringer i borger.dk’s OPIS (system til administration og udstilling af selvbetjeningsløsninger på borger.dk). Læs evt. mere om ændringer i OPIS.

Udviklingsvejledningens krav om brug af tællerscript gælder fortsat for de obligatoriske selvbetjeningsløsninger, der allerede findes på borger.dk, men der kan ikke, som det ellers anbefales, installeres tællerscript på nye selvbetjeningsløsninger.

Der vil i regi af digitaliseringsstrategiens initiativ 1.2 blive udviklet nye metoder til opgørelse af brugen af selvbetjeningsløsninger.

Har du spørgsmål eller brug for yderligere information, er du velkommen til at rette henvendelse til admin@borger.dk

 
Print krav

Krav til Tilgængelighed

Det er et krav at offentlige myndigheders hjemmesider og selvbetjeningsløsninger skal overholde bestemte standarder for tilgængelighed. Det blev besluttet af Regeringen, KL og Danske Regioner i 2007. Standarden for tilgængelighed hedder på fagsprog WCAG 2.0 og sikrer, at løsningerne bliver brugbare for alle. Som myndighed er det dit ansvar, at din selvbetjeningsløsning bliver udviklet efter WCAG 2.0. Retningslinjerne findes i tre niveauer: A, AA og AAA. I Danmark skal vi ligge på niveau AA. Kravene er inddelt i fire overordnede principper, som hver indeholder en række retningslinjer. Selve principperne og retningslinjerne er faste, mens teknikkerne til at opfylde dem kan ændre sig over tid.

Her kan du se de overordnede krav til tilgængelighed. En fuldstændig gennemgang af principper og retningslinjer kan du finde hos W3C, som har udarbejdet standarderne. Tjek altid WCAG 2.0 for at se de præcise instrukser på området. Tilgængelighed i digitale selvbetjeningsløsninger skal leve op til følgende krav:

4.1 Gør din løsning opfattelig: Du skal præsentere og strukturere informationer i din brugergrænseflade på en måde, så det kan opfattes af brugerne og deres hjælpemidler. Læs mere
Læs mere om '4.1 Gør din løsning opfattelig'
Kravet er opfyldt, når:
  • 4.1.a Løsningen understøtter tekstbaserede alternativer (WCAG 2.0. 1.1).
  • 4.1.b Alt indhold med lyd og video er gengivet med tekst (WCAG 2.0 1.2).
  • 4.1.c Løsningens indhold kan tilpasses (WCAG 2.0. 1.3).
  • 4.1.d Brugerfladen understøtter kontrast/kontrastfarver (WCAG 2.0. 1.4).
At din selvbetjeningsløsning skal være opfattelig betyder, at informationer i din løsning skal præsenteres og struktureres på en måde, så de kan afkodes af brugerne og deres hjælpemidler - fx en skærmlæser. Der er flere krav til, hvordan du skal opfylde princippet om opfattelighed:

Tekst som alternativ

For det første skal du sørge for, at der altid findes et tekstbaseret alternativ til alt ikke-tekstbaseret indhold. Dette krav gælder både for billeder, video og lyd. Fordelen ved den digital tekst er, at den kan læses op og forstørres, så det bliver lettere for svagtseende og blinde at afkode indholdet. Se W3Cs præcise retningslinier for tekstalternativer til materiale, der ikke i sig selv er tekst.

Lyd og video

Du skal også sørge for, at indholdet i medier som lyd og video bliver gengivet med tekst. Det kan fx være i form af undertekster eller dokumenter til synstolkning. Se W3Cs præcise retningslinier for tekstalternativer til medier som video og lyd.

Struktur

Strukturen på dit indhold er vigtig for om din selvbetjeningsløsning bliver vist på en meningsfuld måde - også selvom en bruger ser den i et forenklet layout. Det betyder fx, at elementerne på din side skal vises i en logisk rækkefølge. En overskrift bør eksempelvis altid vises før selve brødteksten. Se W3Cs præcise retningslinier for at strukturere dit indhold på en meningsfuld måde.

Tydeligt indhold og struktur

For nogle brugere er det vigtigt, at man tydeligt kan se indhold og struktur. Det gælder især for svagtseende personer. Derfor er det vigtigt, at der er høj kontrast mellem teksten og baggrunden. Du skal også sørge for, at din tekst kan skalere, uden at det går ud over løsningens struktur. Se W3Cs præcise retningslinie for at gøre indhold og struktur tydeligt.
4.2 Gør din løsning anvendelig: Navigation og elementer i din brugerflade skal kunne bruges af de fleste. Det er ikke nok kun at tænke i interaktion med en mus. Læs mere
Læs mere om '4.2 Gør din løsning anvendelig'
Kravet er opfyldt, når:
  • 4.2.a Man navigere kan gennem hele løsningen ved at bruge tastaturet (WCAG 2.0. 2.1).
  • 4.2.b Eventuelle tidsbegrænsninger kan slås fra (WCAG 2.0. 2.2).
  • 4.2.c Hyppige blink er undgået (WCAG 2.0. 2.3).
  • 4.2.d Løsningen er navigerbar (WCAG 2.0. 2.4).
Brugerne skal ikke blot kunne opfatte information og brugerflade - de skal også kunne interagere med din selvbetjeningsløsning. Nogle personer er fx afhængige af at kunne navigere med tastatur. Derfor er det ikke nok kun at tænke i interaktion med en mus. Andre har brug for lidt mere tid end gennemsnittet til at gennemlæse en tekst. Der er en række krav til, hvordan du gør din løsning anvendelig for de fleste brugere:

Tilgængelighed via tastatur

Først og fremmest skal alle funktioner i din selvbetjeningsløsning kunne bruges med et tastatur - og ikke kun via en mus. En række hjælpemidler lige fra skærmlæsere til forskellige pegeredskaber kræver, at man kan bruge tastaturet til at navigere og interagere med. Søgerobotter, der indekserer hjemmesider til søgemaskinerne, kan heller ikke bruge mus. Se W3Cs præcise krav til, at din løsning skal være tilgængelig via tastatur.

Tidsbegrænsninger

Ikke alle brugere kan læse, skrive eller forstå lige hurtigt. Derfor skal du også sørge for, at brugerne har tid nok til at kunne forstå dit indhold eller selv kan tilpasse tiden til egne behov. Det betyder blandt andet, at hvis du har tidsbegrænsninger på noget af dit indhold, så skal brugerne have mulighed for slå begrænsningen fra. Hvis du har indhold, som bevæger sig, skal brugeren have mulighed for at sætte bevægelsen på pause, så de kan nå at opfatte indholdet. Se W3Cs præcise krav til, hvordan du sørger for at dine brugere kan nå at afkode dit indhold.

Må ikke være skyld i anfald

En anden vigtig ting i forhold til bevægelige elementer er, at indhold ikke må designes sådan, at det kan være skyld i (epileptiske) anfald. Undgå derfor hyppige blink i din løsning. Se W3Cs præcise krav til, hvordan du undgår at forårsage anfald.

Navigation

Din løsning skal være navigerbar. Det betyder, at du skal hjælpe din bruger med at navigere, finde indhold og afgøre, hvor på siden de befinder sig. Derfor skal du blandt andet give dine sider meningsfulde titler. Tekster som beskriver links skal være dækkende for linkets formål. Se W3Cs præcise krav til, hvordan du gør din løsning navigerbar.

4.3 Gør din løsning robust: Koden til løsningen skal laves sådan, at forskellige teknologier og programmer (fx browsere og skærmlæsere) kan aflæse indholdet nogenlunde pålideligt. Læs mere
Læs mere om '4.3 Gør din løsning robust'
Kravet er opfyldt, når:
  • 4.3.a Løsningen er kompatibel (WCAG 2.0. 4.1).
Koden til løsningen skal laves sådan, at forskellige teknologier og programmer kan aflæse indholdet nogenlunde pålideligt. Teknologier og programmer kan fx være en browser, det kan være en mobil enhed, men det kan også være hjælpemidler som fx en skærmlæser.

Korrekt kode

For at sikre at din løsning aflæses ensartet, skal koden leve op til en række ret specifikke krav. Se W3Cs krav til, hvordan du skal sørge for, at din er kode robust.

4.4 Gør din løsning forståelig: Både indholdet i din selvbetjeningsløsning og interaktionen med den skal være forståelig for brugeren. Læs mere
Læs mere om '4.4 Gør din løsning forståelig'
Kravet er opfyldt, når:
  • 4.4.a Løsningens sprog fremgår rent kodningsmæssigt (WCAG 2.0. 3.1).
  • 4.4.b Løsningen er gjort forudsigelig, dvs. uden overraskelser for brugeren (WCAG 2.0. 3.2).
  • 4.4.c Brugeren får hjælp til at udfylde formularer og rette fejl (WCAG 2.0. 3.3).
Information og betjening af brugergrænsefladen i din løsning skal være forståelig og brugbar for de fleste. Det betyder blandt andet, at siden skal opføre sig forudsigeligt, og der skal tilbydes hjælp, hvor det er nødvendigt. Der er flere krav til, hvordan du skal opfylde princippet om, at din løsning skal være forståelig:

Sprog skal kunne afkodes

Alt tekstindhold skal gøres læseligt og forståeligt. I WCAG på AA-niveau handler dette krav faktisk udelukkende om at sikre, at det anvendte sprog (fx engelsk, dansk, polsk) kan forstås rent programmeringsmæssigt. Se W3Cs præcise krav til sprog og afkodning.

Forudsigelighed

Din selvbetjeningsløsning skal fungere på en forudsigelig måde. Det betyder blandt andet, at der ikke pludselig må ske ændringer på siden, uden brugeren selv har bedt om det - fx ved at klikke på noget. Du skal også sørge for, at navigation og begreber bliver brugt på samme måder i hele løsningen. Se W3Cs præcise krav til, hvordan din løsning skal være forudsigelig.

Hjælp til at udfylde formularer

Brugere skal have hjælp til at undgå og rette fejl, når de udfylder felter og formularer. Denne retningslinje er vigtig i forhold til selvbetjening. Det betyder blandt andet, at du skal give instrukser til, hvordan man udfylder et felt korrekt. Og hvis brugerne alligevel indtaster ukorrekte oplysninger, skal du vejlede dem i, hvordan de retter fejlen. Se W3Cs præcise krav til, hvordan du hjælper brugerne med at udfylde formularer.