Hoppa till innehållet
Nightwave
Alla guider

Tidsgränser i webbutiken: varukorg och betalsession

Så gör du tidsgränser i kassan rättvisa: varna, låt kunden förlänga eller ta bort gränsen. Reserverad varukorg, betalsession och utloggning. WCAG 2.2.1.

Det här är teknisk vägledning och inte juridisk rådgivning. Tillgänglighetskraven för webbutiker följer av Lag (2023:254) om vissa produkters och tjänsters tillgänglighet. PTS skriver att man kan ta ledning av standarden EN 301 549, och den hänvisar för webbinnehåll till WCAG 2.1 nivå AA. För tolkningsfrågor, vänd dig till Post- och telestyrelsen (PTS).

Tidsgränser finns på fler ställen i en köpresa än man tror. Varukorgen reserverar varorna en stund. Betalsidan hos leverantören går ut. Kundkontot loggar ut kunden efter en tids stillhet. En rabattkod gäller bara under sessionen. För den som läser långsamt, använder skärmläsare, skriver med en enda hand eller behöver stanna upp och tänka är det just i kassan som tiden tar slut. Kriteriet som gäller heter Justerbar tidsgräns (2.2.1, nivå A).

Vad kriteriet kräver

Kriteriet gäller varje tidsgräns som innehållet självt sätter. Minst ett av följande ska vara sant för varje gräns:

  • Stänga av. Kunden kan stänga av tidsgränsen innan hen når den.
  • Ändra. Kunden kan ändra tidsgränsen innan hen når den, över ett brett intervall som är minst tio gånger längre än standardinställningen.
  • Förlänga. Kunden varnas innan tiden går ut och får minst 20 sekunder på sig att förlänga med en enkel handling (W3C nämner att trycka på mellanslag), och kan förlänga minst tio gånger.

Dessutom finns tre undantag. Tidsgränsen är en nödvändig del av en händelse i realtid, till exempel en auktion, och det går inte att ordna något alternativ. Tidsgränsen är nödvändig och en förlängning skulle göra aktiviteten meningslös. Eller tidsgränsen är längre än 20 timmar.

W3C skriver att en tidsgräns som en webbplats sätter av säkerhetsskäl ändå räknas som satt av innehållet, eftersom den är en del av hur sidan fungerar. Gränser som sätts av webbläsaren eller av själva internet omfattas inte. Gränser som sätts av webbservern omfattas, eftersom de ligger inom verksamhetens kontroll. Det betyder att du inte kan svara att tiden är leverantörens sak utan att först ta reda på vad som faktiskt gäller i din butik.

W3C sorterar alternativen så att det som hjälper mest står först: att stänga av är bättre än att ändra, och att ändra är bättre än att begära mer tid precis innan den går ut. Kan du, ta hellre bort tidsgränsen än att förlänga den.

Reserverad varukorg

Många butiker håller kvar varor i varukorgen en viss tid, särskilt när lagret är litet. Går reservationen ut utan förvarning står kunden med en tom varukorg mitt i köpet. Frågan är först om reservationen behövs. Räcker lagret behövs den kanske inte alls, och då är det enklaste att ta bort den.

Behövs den ska kunden varnas i god tid och kunna förlänga. W3C:s teknik SCR16 beskriver mönstret: skriptet visar en varning minst 20 sekunder före utgång och frågar om kunden behöver mer tid. Svarar kunden ja startar tiden om. Svarar kunden nej eller inte alls går tiden ut. I W3C:s exempel används en dialogruta av typen confirm. I en butik är det vanligare att visa en ruta på sidan, och då behöver varningen också nå den som använder skärmläsare. Det handlar Statusmeddelanden (4.1.3) om: ett meddelande som inte tar fokus ska ändå kunna förmedlas till hjälpmedel. Rollen status har enligt WAI-ARIA 1.2 ett underförstått aria-live-värde polite, så skärmläsaren läser upp texten när den är ledig, utan att avbryta det kunden håller på med.

Så här kan det se ut. Varningen kommer 60 sekunder före utgång, alltså långt över W3C:s 20 sekunder, och knappen förlänger med tio minuter:

<div id="tid-varning" role="status" hidden>
  <p>Varorna är reserverade i 1 minut till.</p>
  <button type="button" id="tid-forleng">
    Förläng reservationen med 10 minuter
  </button>
</div>
<p id="tid-slut" role="status"></p>

<script>
  const RESERVATION_MS = 10 * 60 * 1000;
  const VARNING_FORE_MS = 60 * 1000;
  let varnaTimer, slutTimer;
  const varning = document.getElementById("tid-varning");
  const slut = document.getElementById("tid-slut");

  function starta() {
    clearTimeout(varnaTimer);
    clearTimeout(slutTimer);
    varning.hidden = true;
    varnaTimer = setTimeout(() => {
      varning.hidden = false;
    }, RESERVATION_MS - VARNING_FORE_MS);
    slutTimer = setTimeout(() => {
      varning.hidden = true;
      slut.textContent =
        "Reservationen har gått ut. Varorna ligger kvar i varukorgen.";
    }, RESERVATION_MS);
  }

  document.getElementById("tid-forleng")
    .addEventListener("click", starta);
  starta();
</script>

Vi har provkört den här koden i Chromium med kortare tider. Varningen visas på utsatt tid. Esc stänger inte varningen, vilket är avsikten, eftersom kunden annars kan mista knappen. Knappen går att nå och trycka på med tangentbordet, och ett tryck startar om tiden. Efter tolv förlängningar i rad fanns knappen kvar varje gång, så koden sätter ingen övre gräns, och kriteriet kräver minst tio. Provet kontrollerade inte hur en skärmläsare läser upp texten, så det måste du testa själv.

Koden är en skiss för att visa principen. I en riktig butik ligger reservationen på servern, och skriptet måste anropa servern så att den förlänger reservationen på riktigt. En timer i webbläsaren som bara skjuter fram en text hjälper inte om servern ändå släpper varorna. Koden flyttar inte fokus, så en tangentbordsanvändare måste själv tabba till knappen inom varningstiden. Därför är en minut bättre än tjugo sekunder. Vill du att varningen tar fokus är W3C:s dialogruta ett alternativ, men då måste fokus flyttas tillbaka dit kunden var när rutan stängs.

Betalsession hos leverantören

Kassan eller betalsidan som hör till en betalleverantör har ofta en egen gräns. Efter en viss tid går sessionen ut och kunden måste börja om. Vi kan inte säga hur en viss leverantör gör, eftersom det beror på leverantören och på hur butiken har ställt in den. Det du kan ta reda på själv är tre saker:

  1. Hur länge gäller betalsessionen, enligt leverantörens dokumentation eller supportsvar?
  2. Varnas kunden innan den går ut, och finns det en knapp som förlänger?
  3. Vad händer efteråt: ligger varukorgen kvar, eller är allt borta?

Prova också själv. Starta ett testköp, lämna det orört tills tiden går ut och se vad som händer. Om leverantören styr gränsen och inte kan förlänga eller varna är det en fråga till leverantören, och ett skäl att väga mot hur stor del av dina kunder som använder just det betalsättet. Hur du gör med tredje parts delar av kassan går vi igenom i guiden om inbäddad kassa och tredje part.

Utloggning från kundkontot

Ett kundkonto som loggar ut efter en kort stund av stillhet är en tidsgräns i samma mening som reservationen. Här gäller samma tre vägar. Låt kunden välja att stanna inloggad, låt kunden ändra tiden, eller varna innan utloggningen och låt kunden förlänga. W3C:s exempel på en klientsidig gräns som skydd för den som lämnar datorn är precis det: efter en period av inaktivitet frågar sidan om kunden behöver mer tid, och svarar kunden inte går tiden ut.

W3C:s teknik G133 handlar om att minska risken att tappa det man gjort: en ruta på första sidan i ett flerstegsformulär där man kan be om längre tid. Tanken går att tillämpa på kassan. Om kunden ändå loggas ut är det värt mycket att varukorgen och det som redan fyllts i ligger kvar när kunden loggar in igen. Det är en rekommendation från oss och inget krav i kriteriet.

Realtid och nödvändig tid

Undantagen är snävare än de låter. Realtidsundantaget gäller en händelse som pågår samtidigt som den visas och som inte helt skapas av innehållet. W3C:s exempel är en auktion där alla budgivare har samma gräns. Ett erbjudande som löper ut en viss dag är inte samma sak som en händelse i realtid, och vi kan inte utifrån källan avgöra var gränsen går för en tidsbegränsad försäljning. Fråga PTS om du är osäker.

Undantaget för nödvändig tid gäller när en förlängning skulle göra aktiviteten meningslös. W3C:s exempel är en biljettsajt som ger två minuter att bekräfta ett köp, eftersom platserna annars inte kan säljas till någon annan. Men samma exempel visar vad som förväntas av en butik som åberopar undantaget: flytta så mycket som möjligt ur den tidskritiska delen, så att kunden hinner fylla i namn och betalningsuppgifter innan klockan börjar gå. Och W3C beskriver också en biljettsajt som i stället varnar och låter kunden förlänga flera gånger, vilket alltså är ett fullt möjligt val.

Meta refresh och omdirigering

Sidor som laddas om eller skickar kunden vidare av sig själva efter några sekunder är också en tidsgräns. W3C listar att använda meta refresh för tidsstyrd omdirigering eller omladdning som fel (F40 och F41), och att omdirigera sidor efter en tidsfrist med serverteknik som fel (F58). Ta bort meta refresh. Behöver kunden skickas vidare gör du det direkt på servern, utan väntan, eller med en länk som kunden väljer själv.

Så testar du

  1. Gå igenom ett köp med tangentbordet och skriv ned varje tidsgräns: nedräkning, reservation, betalsida, kundkonto.
  2. Vänta ut varje gräns och se vad som händer. Fick du en varning minst 20 sekunder före utgång, och gick det att förlänga med en enkel handling? Gick det att förlänga flera gånger?
  3. Starta en skärmläsare, eller lyssna med den inbyggda i din dator, och kontrollera att varningen läses upp utan att du behöver leta efter den.

Vad AccessAudit kontrollerar

Punkten Tidsgränser i checklistan är markerad Kontrollera själv. Gratistestet läser sidans källkod och kan hitta sidor som laddas om eller skickar vidare med meta refresh, men ser inte tidsgränser som sätts av skript, av servern eller av betalleverantören. Månadsgranskningen kör axe-core med regeln meta-refresh, som hittar fördröjd omladdning med meta refresh, och ger en åtgärd med kodexempel. Den bedömer inte heller reservationer, betalsessioner eller utloggning. De delarna behöver du pröva för hand enligt stegen ovan.

Nästa steg

  1. Lista alla tidsgränser i köpresan och fråga för varje om den behövs.
  2. Lägg på de som behövs in en varning och en knapp som förlänger.
  3. Fråga betalleverantören hur länge sessionen gäller och om den går att förlänga.
  4. Kör det gratis testet för att hitta meta refresh.

Källor

Läs också

Testa din webbutik gratis.

Skriv in adressen så granskar vi startsidan och upp till fyra sidor till och visar de viktigaste bristerna.

Vi hämtar startsidan och upp till fyra sidor till.

Gratis mall för tillgänglighetsinformation

Kriterier som guiden tar upp