Riktlinjer i kategori 1

8 december, 2020

Gör inte identifiering beroende av bara en biometrisk egenskap

Eftersom människors kroppar är lite olika (exempelvis har inte alla fingrar) måste identifiering kunna ske med mer än igenkänning av en enda biologisk egenskap.

8 december, 2020

Bevara tillgänglighet vid konverteringar

Om en webbsida gör om informationsinnehåll som innehåller tillgänglighetsdata måste dessa behållas i det nya formatet.

8 december, 2020

Se till att eventuella samtalsfunktioner är tillgängliga

När det finns funktioner för samtal med röst eller video ska dessa utformas på ett sätt som gör dem tillgängliga för så många som möjligt.

8 december, 2020

Respektera användarens inställningar

Inställningar som användaren gjort i webbläsaren ska om möjligt få genomslag vid presentation av färger, typsnitt, kontraster, textstorlek, och fokusmarkör.

8 december, 2020

Se till att redigeringsfunktioner ger stöd för tillgänglighet

Om den digitala servicen används för redigering ska det som redigeras kunna göras tillgängligt. Publiceringssystem bör följa standarden ATAG.

3 december, 2020

Dokumentera tillgänglighetsfunktioner

Funktionalitet och innehåll med syfte att öka tillgängligheten ska dokumenteras, vara tillgänglig och lätt att hitta.

3 december, 2020

Säkerställ tillgänglighet i kundtjänst

Kundtjänst och liknande funktioner ska vid behov kunna hjälpa användare med tillgänglighet i digitala tjänster. De bör till exempel känna till de rättigheter som följer av DOS-lagen.

3 december, 2020

Utforma eventuella reglage så att alla kan använda dem

Sidan är ett utkast

Denna sida är en av flera nya webbriktlinjer som förtydligar och exemplifierar innebörden i de kriterier som går utöver WCAG i standarden EN301549, och som har relevans för DOS-lagen.

Kom gärna med synpunkter!

Exempelvis genom e-post till info@webbriktlinjer.se eller genom kommentarsfunktionen i slutet av sidan.

 

Denna riktlinje gäller för knappar, spakar, vred och andra reglage – både i hård- och mjukvara – avsedda för slutanvändare för att aktivera, avaktivera eller ställa in en app.


Rekommendationer för tillgängliga reglageLänk hit

  • Ställ inte för höga krav på motorisk förmåga.
  • Gör det möjligt att avläsa aktuell inställning utan att ändra den.
  • Hjälp användaren att undvika oavsiktlig inmatning.


Ställ inte för höga krav på motorisk förmågaLänk hit


Om ett reglage kräver finmotorik såsom förmågan att nypa eller vrida, så måste det finnas alternativa sätt att utföra motsvarande interaktion för användare som saknar sådan förmåga. Alternativen kan vara exempelvis enkla knappar eller tangentbordskommandon.

Användaren ska inte heller tvingas göra flera saker samtidigt, såsom att trycka ner flera olika tangenter eller flera fingrar i kombination.

Detta krav överlappar både R160. Erbjud alternativ till komplexa fingerrörelser och ett kommande kriterium i WCAG 2.2 om drag och släpp, men gäller framförallt för appar, och har ett bredare tillämpningsområde. Till exempel berör inte dessa kriterier samtidig nedtryckning av flera tangenter.

I moderna operativsystem erbjuds alternativ till komplexa tangentkombinationer.


Gör det möjligt att avläsa aktuell inställning utan att ändra denLänk hit


Aktuell status för två- och treställiga reglage ska kunna urskiljas av alla utan att behöva ändra inställning. De måste även kunna avläsas utan syn.


Hjälp användaren att undvika oavsiktlig inmatningLänk hit


Om en tangent hålls intryckt ska det inte behöva leda till teckenrepetering förrän efter två sekunder och därefter maximalt varannan sekund. Se till att detta antingen går att justera med hjälp av inställningar eller att repetition aldrig sker snabbare än så.

Om samma tangenttryckning upprepas (snarare än hålls inne) ska den inte registreras förrän det gått minst en halv sekund, såvida inte användaren har möjlighet att justera tidsgränsen.

Detta berör exempelvis användare med ofrivilliga skakningar och nedsatt finmotorisk precision.

I allmänhet kan användaren genom inställningar för ”tangentrepetition” i operativsystemet påverka detta, men se till att eventuell programkod som lyssnar på tangenthändelser och som inte tar hänsyn till operativsystemets inställningar ändå respekterar dessa gränser. Vi tror inte att detta är vanligt förekommande i digital offentlig service, men det skulle kunna förekomma, till exempel i pedagogiska spel spel.


Vad säger standarder och lagar om denna riktlinje?Länk hit


Enligt DIGGs föreskrifter (§4) ska digital service som omfattas av lagen om tillgänglighet till digital offentlig service vara möjlig att uppfatta, vara hanterbar, begriplig och robust.

Eftersom dessa principer är svåra att utan vägledning tillämpa i enskilda detaljer erbjuds i §5 ett konkret sätt att uppfylla dem: Kriterierna i bilaga A i standarden EN301549 v2.1.2 (pdf). Denna webbriktlinje är ett försök att förklara och exemplifiera sju av dessa kriterier:

  • 5.5.1 Manövreringsmetod
  • 5.5.2 Särskiljande av manövrerbara delar
  • 5.6.1 Läge avkänns taktilt eller med ljud
  • 5.6.2 Visuellt läge
  • 5.7 Tangentrepetition
  • 5.8 Acceptans av dubbla tangentnedslag
  • 5.9 Samtidiga användaraktiviteter


TerminologiLänk hit


Inställningar för ”tangentrepetition” kallas ibland för ”tangentfilter” eller ”tröga tangenter”.

Termen ”reglage” används här för det som i standarden heter ”manövrerbar del” (operable part på engelska).

23 oktober, 2020

Gör tillgänglighetsfunktioner åtkomliga

Tänk efter och testa så att ni inte råkar göra funktioner för ökad tillgänglighet (exempelvis lyssnafunktion eller syntolkning) omöjliga att nå för målgruppen.

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 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änsningar 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

Komponenter behöver exponera namn, roll och värde till operativsystemets tillgänglighets-API för att fungera med vissa hjälpmedel.

30 juni, 2017

Benämn funktioner konsekvent

Konsekvent benämning av saker på hela webbplatsen underlättar för alla användare att känna igen sig och minskar onödig kognitiv belastning.

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å hänvisningar till navigation och instruktioner.