Riktlinjer i kategori 1

20 augusti, 2018

Se till att allt innehåll presenteras rätt oavsett skärmens riktning

Alla människor har inte möjlighet att vrida på sin skärm. Vissa måste välja ett läge (stående eller liggande) och alltid använda detta, exempelvis med skärmen fast monterad på en rullstol. Skapa därför en design så att innehåll och funktioner är tillgängliga oavsett skärmens riktning. Då kan var och en välja det läge de föredrar.


Det finns inget som hindrar att presentationen av innehållet och funktionerna skiljer sig åt mellan de båda lägena så länge innehållet är tillgängligt och funktionerna är åtkomliga och har normal funktion.

I riktlinjen finns undantag för när funktionaliteten är beroende av att användaren har skärmen i en viss riktning, till exempel ett pianoprogram där liggande läge är nödvändigt för att alla tangenterna ska få plats. Informera användaren om när en viss riktning av skärmen är nödvändigt.

19 augusti, 2018

Se till att hjälpmedel kan presentera meddelanden som inte är i fokus

Se till att de som använder tekniska hjälpmedel som som exempelvis skärmläsare och förstoringsprogram kan göras uppmärksamma på viktiga meddelanden även om de presenteras utanför det område på sidan som användaren har i fokus.
Ange med hjälp av attributen role eller aria-live var viktiga meddelanden kan förekomma, så får hjälpmedel kännedom om dessa och kan presentera dem för användaren vid ett lämpligt tillfälle.
Berörda användare riskerar annars att missa varningar, upplysningar och felmeddelanden.

19 augusti, 2018

Erbjud alternativ till rörelsestyrning

Se till att funktioner som aktiveras genom att användaren till exempel skakar, vrider, rör vid eller viftar framför enheten kan stängas av. Funktionerna ska även kunna aktiveras på något annat sätt.

Ovan: vridning av mobil medför förändring från läge 1 till läge 2. Nedan: Klick på knapp ger samma förändring.

Detta hjälper personer som till exempel har enheten fastsatt vid en permobil eller som av någon annan anledning inte har fysisk möjlighet att utföra liknande rörelser. Det finns också användare som oavsiktligt kan aktivera den här typen av kontroller på grund av ofrivilliga skakningar (så kallad essentiell tremor) eller andra motoriska störningar.

19 augusti, 2018

Se till att text på knappar och kontroller överensstämmer med maskinläsbara etiketter

Se till att text som är synlig på knappar och andra gränssnittskontroller också finns i, och överensstämmer med, den maskinläsbara etikett som representerar kontrollen i exempelvis program för röststyrning.

Den som använder röststyrning säger vanligtvis det som står på en knapp för att använda knappen. Detta fungerar om det som står på knappen motsvarar den maskinläsbara texten. Upplevelsen för seende som använder skärmläsare blir också bättre om uppläst text matchar det som visas på skärmen.

19 augusti, 2018

Gör det möjligt att ångra klick

Den som använder pekskärm eller pekdon som exempelvis mus behöver kunna ångra sig om knappen eller trycket skedde av misstag. Erbjud därför minst en sådan möjlighet.

Möjligheten att ångra ett påbörjat klick är värdefull därför att den minskar risken för att aktivera funktioner av misstag. Vem som helst kan råka trycka vid fel plats eller tillfälle, och det är extra lätt hänt för personer med vissa funktionsnedsättningar (exempelvis begränsad motorisk kontroll eller synnedsättning).

Denna riktlinje berör dig som programmerar användargränssnitt (“front-end”) med exempelvis Javascript, men inte dig som enbart jobbar med text, bild och formgivning.

19 augusti, 2018

Erbjud alternativ till komplexa fingerrörelser

Alla personer kan inte hantera komplexa rörelser på en pekskärm, så kallade fingergester. Detta gäller till exempel att svajpa (swipe) och gester som kräver flera fingrar (multi-touch) såsom dra isär och nyp ihop. Det kan bero på motoriska eller kognitiva begränsningar, vilket hjälpmedel en användare har eller användarens brist på kunskap om gränssnittet. Komplettera därför alltid sådana med enklare interaktion såsom klick, dubbelklick eller tryck, såvida inte rörelsen är avgörande för funktionaliteten.

Observera att riktlinjen bara gäller webbplatsens eller appens gränssnitt. Det gäller inte operativsystemets eller webbläsarens funktioner, såsom horisontell svepning för att navigera i sidhistoriken.

Riktlinjen undantar funktionalitet som naturligt kräver mer komplexa rörelser, till exempel att skriva sin signatur.

17 augusti, 2018

Popup-funktioner ska kunna hanteras och stängas av alla

Innehåll, till exempel popup-rutor, som dyker upp vid tangentbordsfokus eller när användaren för muspekaren (hovrar) över ett visst objekt ska kunna uppfattas och hanteras av alla – även av användare som har förstorat sidan eller tar längre tid på sig att komma till innehållet. Det är särskilt viktigt att innehållet enkelt kan tas bort eller stängas.

Det kan till exempel gälla undermenyer, inforutor (tooltips) och icke-modala popup-fönster.

Tyvärr skapar sådant innehåll annars ofta tillgänglighetsproblem, till exempel för att:

  • användaren inte har aktiverat funktionen med avsikt,
  • användaren inte blir medveten om att det har dykt upp nytt innehåll eller
  • det nya innehållet stör användarens förmåga att genomföra en uppgift.
17 augusti, 2018

Se till att det går att öka avstånd mellan tecken, rader, stycken och ord

Många användare, till exempel dyslektiker och personer med nedsatt syn, behöver kunna påverka avståndet mellan stycken, rader, ord och tecken för att lättare kunna läsa. Gör det därför möjligt för användaren att påverka avstånden utan att innehåll eller funktionalitet krockar eller gömmer sig bakom annat innehåll.

Denna riktlinje är närliggande riktlinjen Se till att text går att förstora utan problem (R127) men gäller alltså mellanrummen och inte själva tecknen.

Användaren ska ha möjlighet att öka avstånd åtminstone upp till följande relativa gränsvärden:

  • Radavstånd ska kunna ökas minst 1,5 gånger teckensnittets storlek.
  • Teckenavstånd ska kunna ökas minst 0,12 gånger teckensnittets storlek.
  • Avståndet mellan ord ska kunna ökas minst 0,16 gånger teckensnittets storlek.
  • Avståndet mellan stycken ska kunna ökas minst 2 gånger teckensnittets storlek.

Förstoring av mellanrum kan ske på olika sätt. Till exempel med hjälp av en bookmarklet som ökar avstånden, med ett förstoringshjälpmedel eller genom att ställa in webbläsaren att tillämpa användarens egen css-kod.

Riktlinjen gäller inte för öppna undertexter i video och inte heller för text som förekommer i bilder (vilket i och för sig ofta bör undvikas, se Använd text, inte bilder, för att visa text (R128)). För närvarande är även PDF undantaget.

17 augusti, 2018

Använd tillräckliga kontraster i komponenter och grafik

Personer med nedsatt syn har ofta svårt att urskilja visuella kontraster mellan exempelvis en symbol och dess bakgrund, och riskerar därför att missa information. Designa därför webbplatsen så att komponenter i gränssnittet och informationsbärande grafik har tillräckliga kontraster. Som komponenter räknas till exempel knappar och formulärfält. Som grafiska objekt räknas exempelvis ikoner och betydelsefulla delar av illustrationer och diagram (till exempel kurvor och pilar).

Denna riktlinje liknar Använd tillräcklig kontrast mellan text och bakgrund (R126) (som motsvarar WCAG-kriteriet 1.4.3). Men nu gäller alltså motsvarande krav även för innehåll som inte är text.

17 augusti, 2018

Märk upp vanliga formulärfält i koden

Hjälp dina användare att fylla i inmatningsfält genom att i koden ange vilken typ av innehåll som förväntas. Då kan webbläsare eller hjälpmedel ibland automatiskt föreslå inmatning (baserat på till exempel tidigare inmatning i fält av samma typ) i vanliga formulärfält (såsom gatu- och postadress). Systemet kan också ytterligare hjälpa användaren genom att presentera fältet på ett sätt (till exempel med en symbol) som användaren känner igen.

Det är bra för alla användare, men kanske framför allt för personer med vissa kognitiva och motoriska funktionsnedsättningar. Det underlättar också för användare som inte behärskar språket så bra.

2 juli, 2017

Orsaka inte epileptiska anfall genom blinkande

Personer med en viss kategori av epilepsi kan få krampanfall om de utsätts för snabbt blinkande “flimmer” som upptar en tillräckligt stor del av synfältet.

2 juli, 2017

Gör en logisk tab-ordning

Testa tab-ordningen genom att granska en sida av varje sidtyp utan hjälp av tryckkänslig skärm, mus eller annat pekdon.

2 juli, 2017

Ange sidans språk i koden

För att öka sannolikheten att till exempel skärmläsare presenterar innehållet korrekt bör html-koden ange aktuellt språk med hjälp av lang-attribut.

2 juli, 2017

Ange språkförändringar i koden

För att öka sannolikheten att till exempel skärmläsare presenterar innehållet korrekt bör html-koden ange aktuellt språk med hjälp av lang-attribut.

30 juni, 2017

Skriv beskrivande sidtitlar

En bra beskrivande titel sammanfattar sidans ämne eller innehåll. Varje sida på en webbplats, liksom andra typer av dokument bör ha en unik titel.

30 juni, 2017

Ge användarna möjlighet att justera tidsbegränsningar

Användare behöver ibland möjlighet att justera tidsbegräsningar som finns inbyggda i systemet, till exempel i en beställningsfunktion. Ge dem det!

30 juni, 2017

Använd text, inte bilder, för att visa text

Användare behöver då och då anpassa texten bland annat genom att förstora eller välja ett annat teckensnitt, ändra förgrund- och bakgrundsfärger eller linjeavstånd. Om texten utgör en del av en bild saknas ofta de möjligheterna.

30 juni, 2017

Utför inga oväntade förändringar vid fokusering

Utför ändringar när användaren har anledning att förvänta sig dem.

30 juni, 2017

Utför inga oväntade förändringar vid inmatning

Utför ändringar när användaren har anledning att förvänta sig dem.

30 juni, 2017

Ge förslag på hur fel kan rättas till

När fel upptäcks automatiskt bör förslag på korrekt inmatning presenteras för användaren om det är möjligt.

30 juni, 2017

Se till att skräddarsydda komponenter fungerar i hjälpmedel

Många användare behöver hjälpmedel såsom skärmläsarprogram, förstoringsprogram punktdisplay med mera. Dessa hjälpmedel kommunicerar med operativsystemets tillgänglighets-API. För att det ska fungera behöver varje del av en webbsida eller applikation vid varje tillfälle exponera sitt namn, sin roll och sitt aktuella värde. Då kan hjälpmedlet presentera applikationen på ett korrekt sätt för användaren. En skärmläsare behöver till exempel kunna berätta för användaren när förändringar av sidans innehåll sker.


Rekommendationer för skräddarsydda komponenterLänk hit

  • Använd i första hand standardkomponenter som finns i html. Då uppfyller du automatiskt detta krav. Bara när det finns starka skäl och tillräckliga resurser för test och utveckling bör skräddarsydda komponenter utvecklas.
  • Vid val av tilläggsprogram eller kodplattformar (till exempel olika javascript-bibliotek) behöver ni undersöka om eventuella komponenter som bygger på dessa plattformar har ett bra stöd för tillgänglighet.

Utdrag från WCAG-standardenLänk hit

Riktlinje 4.1 Kompatibelt: Maximera kompatibiliteten med nuvarande och framtida användarprogram, inklusive hjälpmedel.

4.1.2 Namn, roll, värde: För alla komponenter i ett användargränssnitt (inklusive, men inte begränsat till formulärelement, länkar och komponenter skapade med script), kan namnet och rollen automatiskt tydliggöras. Status, egenskaper och värden som kan anges av användaren kan bli automatiskt tydliggjord, och meddelande om ändringar i dessa komponenter finns åtkomliga för användarprogram, inklusive hjälpmedel. (Nivå A)

Anmärkning: Detta framgångskriterium är främst till för utvecklare som utvecklar egna komponenter eller skapar egna script för komponenterna i användargränssnittet. Exempelvis uppfyller redan standardkontroller i HTML detta framgångskriterium när de används enligt specifikation.


TerminologiLänk hit


Hjälpmedel kallas på engelska för assistive technologies.

30 juni, 2017

Benämn funktioner konsekvent

Var konsekvent när du beskriver och namnger samma funktionalitet på olika sidor och skärmar.

30 juni, 2017

Erbjud alternativ om en inspelning enbart består av ljud eller video

Användare som inte kan ta del av ljud- eller videoinspelningar ska ha en möjlighet att tillgodogöra sig innehållet med hjälp av en alternativ representation.

30 juni, 2017

Ange i kod vad sidans olika delar har för roll

Öka chansen att informationen presenteras korrekt oavsett mottagarens verktyg, genom att använda html-elementen på rätt sätt.

30 juni, 2017

Syntolka eller erbjud alternativ till videoinspelningar

Den som inte kan ta del av det visuella innehållet i videoinspelningar, till exempel på grund av synnedsättning, ska kunna få motsvarande information antingen i form av syntolkning (ljudbeskrivning) eller presenterad som text.

30 juni, 2017

Syntolka videoinspelningar

Ordna med syntolkning om det behövs för att personer med begränsad syn ska kunna ta del av videoinnehåll.

30 juni, 2017

Se till att markören inte fastnar vid tangentbordsnavigation

Markören ska inte fastna vid tangentbordsnavigation. Det kan hindra besökare att använda webbplatsen eller vissa funktioner.

30 juni, 2017

Ge användarna möjlighet att pausa eller stänga av rörelser

Personer som har svårt att fokusera, läsa eller behålla koncentration behöver kunna pausa rörelser eller stänga av visuella distraktioner.

30 juni, 2017

Se till att text går att förstora utan problem

Det ska vara möjligt att förstora texten till åtminstone dubbel höjd och bredd utan att problem uppstår (till exempel att text hamnar bakom en bild eller krockar med annan text).

30 juni, 2017

Texta direktsändningar

Digital video ska ha undertexter och för annat ljud bör en textversion erbjudas. Denna riktlinje gäller direktsändningar.

30 juni, 2017

Gör inte instruktioner beroende av sensoriska kännetecken

Även den som inte kan uppfatta form, storlek eller har möjlighet att relatera till höger eller vänster behöver kunna förstå till navigation och instruktioner.

30 juni, 2017

Använd inte enbart färg för att förmedla information

Använd gärna färger, men låt inte färgskillnader vara det enda sättet att urskilja information utan komplettera med exempelvis text, mönster eller någon annan visuell indikation.

30 juni, 2017

Presentera innehållet i en meningsfull ordning för alla

Alla användare tar inte del av informationen i samma ordning. En visuell presentation kan till exempel använda kolumner och rutnät för att fördela innehållet i två dimensioner, medan en skärmläsare presenterar innehållet sekventiellt.

Responsiv design, som anpassar presentationen baserat på skärmstorlek, kan påverka ordningen. Även när språk som läses från vänster till höger blandas med språk som läses från höger till vänster kan betydelsen påverkas av ordningen.

Utforma innehållet på ett sätt som bevarar den avsedda betydelsen för alla användare, alltså även om ordningen skulle förändras.

Schematisk bild av sortering av innehållet på denna sida. Vid smal skärm ska inte allt innehåll i högerspalten presenteras sist, utan det som hör till WCAG-utdraget måste presenteras direkt efter utdraget.

Ett exempel på när ordningen har betydelse finns faktiskt längre ned på den här webbsidan:

Intill utdraget från WCAG nedan finns en kort text med fakta om utdraget. För läsare med stor skärm presenteras faktatexten till höger om utdraget. För användare med liten skärm presenteras den nedanför utdraget, och för användare med skärmläsare direkt efter utdraget. Därmed är ordningen logisk för alla. Men för att åstadkomma detta kunde vi inte koda sidan på enklaste sätt med vänsterspalten i ett div-element och därefter högerspalten i ett annat. Då hade nämligen faktatexten hamnat efter hela vänsterspalten för användare med liten skärm eller skärmläsare. Det skulle kunna få läsaren att felaktigt tro att faktatexten gällde innehållet längre ner i vänsterspalten, och inte utdraget.

Oftast, men inte alltid, presenteras innehållet i rätt ordning om det förekommer i rätt ordning i html-koden.


Rekommendationer för läsordningLänk hit

  • Testa läsordningen genom att granska en sida av varje sidtyp med några skärmar i olika storlek och genom att lyssna igenom innehållet med en skärmläsare.
  • Se till och testa även att läsordningen är logisk i dokument som inte är html (pdf, word med mera) .

Utdrag från WCAG-standardenLänk hit

Riktlinje 1.3 Anpassningsbart: Skapa innehåll som kan presenteras på olika sätt (exempelvis med enklare layout) utan att information eller struktur går förlorad.

1.3.2 Meningsfull ordning: När meningen med innehållet påverkas av ordningen det presenteras i, kan en logisk läsordning bli automatiskt tydliggjord. (Nivå A)


30 juni, 2017

Ge användaren möjlighet att pausa, stänga av eller sänka ljud

Det ska alltid vara möjligt att pausa, stoppa eller sänka sådant ljud som spelas upp automatiskt.

30 juni, 2017

Ge möjlighet att ångra, korrigera eller bekräfta vid viktiga transaktioner

Den som råkar göra något fel kan slippa mycket besvär om felet kan upptäckas och åtgärdas direkt.

30 juni, 2017

Markera tydligt vilket fält eller element som är i fokus

Den som navigerar med t.ex. tab-tangenten behöver få veta var fokus ligger. Standardmarkeringen är ofta en tunn linje som är svår att se.
Gör markeringen tydlig, till exempel med en CSS-regel.

30 juni, 2017

Utveckla systemet så att det går att hantera med enbart tangentbordet

Den som bara kan eller vill använda tangentbordet (eller hjälpmedel som kopplas till tangentbords-kommandon) är beroende av att systemet inte förutsätter att användaren har till exempel mus eller pekskärm.

30 juni, 2017

Använd tillräcklig kontrast mellan text och bakgrund

Personer med nedsatt syn har ofta svårt att läsa text med bristande kontrast mot textens bakgrund. De flesta kan läsa brödtext på skärm om skillnaden i ljusintensitet mellan förgrund och bakgrund har förhållandet 4,5:1.

29 juni, 2017

Beskriv med text allt innehåll som inte är text

Användare som är beroende av till exempel skärmläsare och punktdisplay behöver beskrivningar av allt innehåll som inte är text. Det gäller till exempel:

  • Bilder (förutom sådana som endast används för dekoration)
  • Diagram
  • Animationer
  • Ljudsignaler

Se därför till att allt sådant innehåll beskrivs med hjälp av text, förutom i de undantagsfall som beskrivs i WCAG-kriteriet.  Undantagen gäller framförallt sådana situationer där en beskrivande text skulle motverka innehållets syfte (till exempel när syftet med ett ljud är att testa användarens hörsel).

Använd text som är synlig för alla om det passar, eller html-attribut som till exempel alt och aria-label för kortfattade beskrivningar. När en textbeskrivning ligger separat kan du knyta id-attributet för det element som innehåller beskrivningen till det som beskrivs till exempel med hjälp av aria-labelledby eller aria-describedby. En fördel med separat textbeskrivning är att den – till skillnad från alt-attribut – kan formateras och innehålla länkar.


Rekommendationer för textalternativLänk hit

  • Välj detaljnivå efter användarens behov
  • Undvik upprepningar genom att provlyssna

Välj detaljnivå efter användarens behovLänk hit

Beskriv innehållet tillräckligt detaljerat för den som enbart uppfattar textbeskrivningen. Det är ofta bättre att sakligt och kortfattat beskriva innehållet än att ta upp varje detalj eller att ge subjektiva omdömen. Men det finns undantag. Ibland är det viktigt att beskriva känslan i en bild för att användaren ska få en förståelse för innehållet. Utgå från användarens behov och innehållets syfte.

Pictobild som föreställer en blomma. Bredvid står några olika exempel på dåliga textbeskrivningar (dsc20345.jpg, Foto; Jan Persson, Ange bildtext här, och mellanslag) och ett bra exempel: En vit blomma

Ofta finns det möjlighet att kombinera en kort textbeskrivning genom att till exempel använda alt-attribut på en bild med en mer utförlig separat text för den som vill fördjupa sig. Använd då till exempel attributet aria-describedby för att relatera innehållet till en separat text.

Andra riktlinjer (R117 Texta inspelad rörlig media (video, ljud, animationer…) och R119. Texta direktsändningar) tar upp frågor om fullständig textversion av “tidsberoende media” det vill säga inspelningar och direktsändningar. Denna riktlinje innebär bara att det behöver finnas en sammanfattande text som beskriver sådant innehåll.


Undvik upprepningar genom att provlyssnaLänk hit

Om det finns en bildtext eller annan brödtext som beskriver bildens innehåll bör inte den alternativa textbeskrivningen upprepa textens innehåll. Ett bra sätt att bedöma hur bra alternativa textbeskrivningar fungerar är att lyssna på webbplatsen med hjälp av en skärmläsare.


Därför är textpresentationer viktigaLänk hit

Med hjälp av digital teknik kan de flesta användare ta till sig en text. Den som ser kan läsa texten, den som hör kan få den uppläst, den kan presenteras som punktskrift för den som läser med hjälp av känseln. Text kan förstoras och presenteras med olika teckensnitt och färgskalor. Uppläsning kan ske med olika hastighet och röst. I många fall kan text till och med översättas automatiskt innan den presenteras för användaren.


Utdrag från WCAG-standardenLänk hit

Riktlinje 1.1 Textalternativ: Tillhandahåll alternativ i form av text till allt icke-textbaserat innehåll så att det kan konverteras till format som användarna behöver, till exempel stor stil, punktskrift, tal, symboler eller enklare språk.

1.1.1 Innehåll som inte är text: Allt innehåll som inte är text, som presenteras för användaren har ett textalternativ med samma syfte, utom i de situationer som anges nedan. (Nivå A)

  • Navigeringsmetod/funktion, inmatning: Om innehåll som inte är text är en navigeringsmetod/funktion eller accepterar inmatning från användare så ska den ha ett namn som beskriver dess syfte. (Se Riktlinje 4.1 för ytterligare krav på navigeringsmetod/funktion och innehåll som accepterar inmatning från användare).
  • Tidsberoende media: Om innehåll som inte är text är tidsberoende media så ger ett textalternativ åtminstone en beskrivning av det innehåll som inte är text. (Se Riktlinje 1.2 för ytterligare krav på media).
  • Test: Om innehåll som inte är text är ett test eller en övning som inte skulle fungera om det visades som text, så ger ett textalternativ åtminstone en beskrivning av det innehåll som inte är text.
  • Sensorisk: Om innehåll som inte är text främst är avsett för att ge en specifik sensorisk upplevelse så ger ett textalternativ åtminstone en beskrivning av det innehåll som inte är text.
  • CAPTCHA: Om syftet med innehållet som inte är text är att bekräfta att en människa, snarare än en dator, försöker komma åt informationen så ska textalternativ som identifierar och beskriver syftet av innehållet tillhandahållas. Alternativa former av CAPTCHA, som använder sig av utmatningsmetoder för olika typer av sensorisk upplevelse, tillhandahålls för att tillgodose olika funktionsnedsättningar.
  • Dekoration, formatering, osynlig: Om innehåll som inte är text är rent dekorativt, bara används för visuell formatering eller inte presenteras för användare, så implementeras det på ett sätt så att det kan ignoreras av hjälpmedel.

TerminologiLänk hit

Formuleringarna alt-text, alt-texter, alt-attribut är vanliga när det gäller textbeskrivning av bilder på webben. Ibland förekommer attributet longdesc, som kan användas för att hänvisa till beskrivningar på annan plats i dokumentet, eller på någon annan sida. Stödet i webbläsare för longdesc är dock begränsat, och idag är det nog bättre att använda aria-describedby.

CAPTCHA är en förkortning av ”Completely Automated Public Turing test to tell Computers and Humans Apart” vilket innebär att det är ett sätt att avgöra om användaren är en människa eller ett datorprogram (ibland kallad ”bot” i detta sammanhang). Framförallt används CAPTCHAs för att förhindra skräppost och annat missbruk av digitala tjänster, som ofta sker med hjälp av program. Tyvärr finns risk för att även användare som faktiskt är människor har problem att ta sig förbi testet, eftersom det kan ställa mycket höga krav på syn, kognition eller hörsel. Erbjud sätt att komma förbi CAPTCHA som fungerar oavsett eventuell funktionsnedsättning. Ett inlägg (på engelska) på designbloggen Telepathy beskriver några alternativ till CAPTCHA.

27 juni, 2017

Grundläggande rekommendationer för appar

Komplettera gärna med en app när webben inte räcker till för att täcka målgruppens behov. Det kan till exempel handla om att viss ny funktionalitet som fungerar i en app inte går att erbjuda med en responsiv webbplats. Se till att appen följer riktlinjer för tillgänglighet. De flesta riktlinjer som gäller för webben är även tillämpbara på appar.