Cookierutan och tillgänglighet: tangentbord, kontrast, zoom
Så testar du cookierutan i webbutiken med tangentbord och zoom på två minuter, och rättar fokusfällor, knappar utan namn och för låg kontrast.
Det här är teknisk vägledning och inte juridisk rådgivning. Frågor om vad en cookieruta får eller måste innehålla hänvisas till Post- och telestyrelsen (PTS). Guiden handlar bara om hur rutan fungerar för den som använder den.
Cookierutan är det första en besökare möter i din webbutik, och den ligger ovanpå allt. Fungerar den inte med tangentbord, skärmläsare eller förstoring kommer besökaren aldrig förbi den.
Varför rutan är extra känslig
De flesta tillgänglighetsfel gör en sida sämre att använda. Ett fel i en cookieruta kan göra hela butiken oanvändbar, eftersom rutan ofta blockerar sidan tills man har svarat. Kriterierna som berörs är i första hand 2.1.1 Tangentbord, 2.1.2 Ingen tangentbordsfälla, 2.4.3 Fokusordning, 2.4.7 Synligt fokus, 1.4.3 Kontrast (minimum), 1.4.11 för kontrast i knappar och ramar, och 4.1.2 Namn, roll, värde. Namnen är hämtade från W3C:s svenska översättning av WCAG 2.0. Kriterierna har samma nummer och namn i 2.1. Kriterium 1.4.11 finns bara i 2.1 och saknar därför svensk översättning från W3C.
Mer om tangentbord i allmänhet finns i guiden Tangentbord och synligt fokus i webbutiken, och om kassan i De vanligaste tillgänglighetsfelen i kassan.
Testet på två minuter
Öppna butiken i ett fönster där du inte har svarat på cookierutan tidigare, till exempel ett privat fönster. Lägg undan musen.
- Tryck Tab en gång. Hamnar fokus i rutan, på en knapp eller en länk i den? Eller försvinner det bakom rutan, in i menyn på sidan under?
- Fortsätt trycka Tab. Fokus ska gå igenom alla knappar i rutan, i en ordning som följer läsningen, och synas hela tiden.
- Tryck Skift+Tab för att gå bakåt. Det ska fungera lika bra som framåt.
- Tryck Enter på en knapp. Rutan ska försvinna och fokus hamna på en plats i sidan där du kan fortsätta.
- Ladda om och tryck Esc när rutan är öppen. Om rutan är en dialog som blockerar sidan ska Esc stänga den, eller så ska det finnas en knapp som går att nå med Tab.
- Zooma webbläsaren till 200 procent. Ser du fortfarande knapparna? Går det att rulla i rutan? Täcker rutan hela skärmen så att inget annat går att nå?
- Gör samma sak i en mobil. Rutan är ofta som svårast att hantera där, eftersom den tar nästan hela skärmen.
Går något av detta fel drabbar det alla som använder tangentbord, och troligen fler än så.
De vanliga felen och hur de rättas
Fokus hamnar inte i rutan
Rutan läggs sist i sidans kod och visas överst med CSS. För den som tabbar ligger den då sist i ordningen, efter hela menyn och sidfoten. Rutan syns, men det första Tab-trycket tar dig till logotypen. Lösningen är att flytta fokus till rutan när den visas, med ett anrop till focus() på dess rubrik eller första knapp:
const ruta = document.querySelector("#cookieruta");
ruta.querySelector("h2").setAttribute("tabindex", "-1");
ruta.querySelector("h2").focus();
Eller bygg rutan som en dialog (se nedan), som sköter det åt dig.
Fokus läcker ut till sidan bakom
Rutan täcker sidan, men Tab fortsätter ändå in bland länkarna under den. Besökaren kan stå på en länk i menyn som ligger gömd bakom en mörk skärm. Elementet dialog med anropet showModal() gör resten av sidan overksam medan dialogen är öppen:
<dialog id="cookieruta" aria-labelledby="cookie-rubrik">
<h2 id="cookie-rubrik">Cookies på webbplatsen</h2>
<p>Vi använder cookies för att ...</p>
<button type="button" id="neka">Endast nödvändiga</button>
<button type="button" id="godkann">Godkänn alla</button>
</dialog>
<script>
document.querySelector("#cookieruta").showModal();
</script>
Webbläsaren flyttar fokus in i dialogen, håller kvar det där och stänger dialogen med Esc. Om du använder attributet aria-modal="true" på en egen konstruktion i stället för dialog-elementet måste du själv se till att sidan bakom inte går att nå, eftersom attributet bara berättar för skärmläsaren att den ska ignorera resten. Det stoppar inte Tab. MDN beskriver skillnaden i sina sidor om elementet dialog och om aria-modal.
Rutan går inte att stänga med tangentbord
Det här är det allvarligaste felet, för då är besökaren fast. Kriterium 2.1.2 säger att om fokus kan flyttas in i en komponent med tangentbord ska det också gå att flytta ut igen. En ruta får gärna hålla kvar fokus medan den är öppen, men den måste gå att besvara med Enter eller mellanslag och försvinna när man har gjort det. Esc som stänger rutan är ett bra komplement.
Knappar som inte är knappar
Vissa rutor byggs med div-element och klickkommandon:
<div class="cookie-knapp" onclick="godkann()">Godkänn</div>
Det går inte att nå med Tab och inte att aktivera med Enter, och en skärmläsare vet inte att det är en knapp (kriterierna 2.1.1 och 4.1.2). Byt till en riktig knapp:
<button type="button" class="cookie-knapp" onclick="godkann()">Godkänn</button>
Samma sak gäller ikoner. En stängningsknapp med bara ett kryss i behöver ett namn som en skärmläsare kan läsa:
<button type="button" aria-label="Stäng cookierutan">
<svg aria-hidden="true" ...></svg>
</button>
För låg kontrast
Cookierutor har ofta grå text på ljusgrå bakgrund, eller en knapp i samma färg som rutan. Text behöver minst 4,5:1 mot bakgrunden (kriterium 1.4.3) och knappens kant eller fyllning minst 3:1 (kriterium 1.4.11). Kontrollera knappen i vilande läge, med fokus och med muspekaren över.
Rutan täcker allt vid förstoring eller på mobil
På en liten skärm eller vid 200 procents zoom kan en ruta med fast höjd ta hela fönstret. Då går varken knapparna längst ned eller innehållet bakom att nå. Låt rutan växa med innehållet, begränsa höjden och låt den rulla inom sig:
#cookieruta {
max-height: 90vh;
overflow-y: auto;
}
Använd inte fasta pixelhöjder på rutan. Kontrollera att knappen för att svara alltid går att nå, även om texten ovanför är lång.
Rutan kommer tillbaka på varje sida
Om valet inte sparas visas rutan igen på nästa sida, och tangentbordsanvändaren börjar om varje gång. Kontrollera att valet finns kvar efter en omladdning. Ge också dialogen ett namn med aria-labelledby, som i exemplet ovan, så att skärmläsaren säger vad det är för ruta.
När rutan kommer från en tjänst eller en app
De flesta butiker har inte byggt sin cookieruta själva. Den kommer från ett tema, en Shopify-app, ett tillägg i WordPress eller en samtyckestjänst. Du kan då inte rätta HTML-koden direkt, men du kan göra tre saker.
- Leta i inställningarna. Många tjänster har ett alternativ för utseende och placering, där du kan välja en mindre ruta, en annan plats eller en tydligare kontrast. Ibland finns ett läge som kallas modal eller dialog, som är bättre för tangentbord än en banner som flyter på sidan.
- Fråga leverantören. Skriv till supporten vad du har sett, till exempel att fokus inte hamnar i rutan eller att den inte går att stänga med tangentbord, och fråga om det finns en inställning eller en nyare version. Spara svaret.
- Testa igen efter varje uppdatering. En ruta som fungerade för en månad sedan kan ha ändrats av leverantören. Gör testet på två minuter när tjänsten eller temat har uppdaterats.
Kan du lägga till egen CSS i temat kan du rätta kontrast och storlek själv. Rör inte tredjepartstjänstens JavaScript, eftersom det kan skrivas över vid nästa uppdatering.
Vad AccessAudit ser
AccessAudits gratis test läser källkoden på upp till fem sidor. En ruta som läggs in av skript efter att sidan laddats finns inte i källkoden, så gratistestet ser den inte och säger därför lite om just cookierutan. Månadsgranskningen kör butiken i en riktig webbläsare, och det ser mer. På de sidor där tangentbordstestet körs gör granskningen följande:
- Den trycker sig igenom sidan med Tab och kontrollerar att varje element som får fokus visar en markering (kriterium 2.4.7).
- Den letar efter en fokusfälla: om fokus under de första 40 tabbtrycken går runt bland samma element utan att komma vidare räknas det som ett kritiskt fel (kriterium 2.1.2).
- Om fällan ligger i något som ser ut som en dialog eller en cookieruta (en dialogroll, aria-modal eller ett id eller en klass med ordet cookie eller consent) accepteras den, förutsatt att det går att komma ur den med Esc eller genom att trycka Enter på rutans första knapp. Då är det ingen fälla.
- Den letar efter element som går att klicka på med mus men inte nås med tangentbord, till exempel ett div-element med klickkommando eller en roll som knapp utan tabindex (kriterium 2.1.1).
- Axe-core kontrollerar bland annat kontrast och knappar utan namn.
- Efter startsidan försöker granskningen stänga cookierutan med en nekande knapp hos några vanliga leverantörer, så att rutan inte täcker resten av sajten. Bara webbläsarens egna cookies påverkas.
Det granskningen inte avgör är om ordningen i rutan känns rimlig, om en ruta med flera steg fungerar eller om texten är begriplig. Den testar inte heller om rutan täcker hela skärmen vid förstoring, utöver att den mäter sidledsscroll vid smal bredd. Det avgör ditt eget test bättre. Granskningen ersätter inte det.
Börja här
Gör testet på två minuter, på dator och i mobil. Rätta först det som får besökaren att fastna, sedan kontrast och storlek. Ligger rutan i en tjänst: skriv till leverantören med en kort beskrivning.
Om samtycke och cookies finns vägledning hos PTS och Integritetsskyddsmyndigheten (IMY). Samtycke till cookies regleras i lagen om elektronisk kommunikation, och det är de myndigheterna som ger vägledning om vad som gäller. Den här guiden gör det inte.
AccessAudits gratis test på butik.nightwave.se/tillganglighet kontrollerar upp till fem sidor i källkoden. I checklistan finns kontroller du kan göra själv. Vill du ha löpande kontroll av tangentbord, fokus och resten av butiken finns ett abonnemang. Det är teknisk granskning mot WCAG, inte juridisk rådgivning.
Källor
- WCAG 2.0 på svenska, W3C
- Understanding 2.1.2 No Keyboard Trap, W3C
- Understanding 2.4.3 Focus Order, W3C
- Understanding 2.4.7 Focus Visible, W3C
- Understanding 4.1.2 Name, Role, Value, W3C
- dialog-elementet, MDN Web Docs
- aria-modal, MDN Web Docs
- Lag (2023:254) om vissa produkters och tjänsters tillgänglighet, riksdagen.se