Kontroll före köp i kassan: 3.3.4 och 3.2.2

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).

Den här guiden handlar om det sista steget före betalning: kan kunden se och ändra beställningen innan den går iväg, och händer det något oväntat medan kunden fyller i formuläret? Två kriterier styr det, Förebyggande av fel (juridiskt, ekonomiskt, data) (3.3.4, nivå AA) och Vid inmatning (3.2.2, nivå A). Fälten, etiketterna och felmeddelandena tas upp i formulärguiden, som också går igenom 3.3.1 Identifiering av fel och 3.3.3 Förslag vid felhantering. De sju vanligaste kassafelen i korthet finns i den första kassaguiden.

Vad 3.3.4 kräver

Kriteriet gäller sidor som leder till ett juridiskt åtagande eller en ekonomisk transaktion, som ändrar eller raderar uppgifter användaren själv styr över, eller som skickar in provsvar. Ett köp i en webbutik är en ekonomisk transaktion, och den här guiden håller sig till det fallet. W3C:s lydelse kräver att minst ett av tre villkor är sant:

• Inskickningen går att ångra.
• Det som kunden har skrivit in kontrolleras för inmatningsfel, och kunden får möjlighet att rätta dem.
• Det finns en funktion för att granska, bekräfta och rätta uppgifterna innan köpet slutförs.

Du behöver alltså inte uppfylla alla tre. W3C:s eget exempel för en webbhandlare är det tredje villkoret: när beställningen skickas visas varor, antal, leveransadress och betalsätt så att kunden kan kontrollera dem, och kunden kan antingen bekräfta eller göra ändringar. W3C nämner också att en angiven tid då beställningen kan ändras eller avbrytas efter att den lagts (teknik G164) och en kryssruta utöver skicka-knappen (G155) räknas som tillräckliga tekniker för köp.

För en butik är det tredje villkoret oftast det enklaste. En sammanfattning före knappen ”Slutför köp” bör innehålla:

• varorna, antal och pris per rad
• frakt och totalbelopp
• leveransadress och faktureringsadress
• valt leveranssätt och betalsätt
• en länk eller knapp vid varje del som tar kunden direkt till rätt steg för att ändra
• en knapp med text som säger vad som händer, till exempel ”Lägg beställning och betala”, inte bara ”Fortsätt”

Efter köpet hör en bekräftelse hemma som berättar att beställningen gått igenom. W3C listar det som en rådgivande teknik (G199, framgångsmeddelande), inte som ett krav för 3.3.4. Regler om ångerrätt och orderbekräftelse finns, men de hör till andra regler än WCAG och behandlas inte här.

Vad 3.2.2 kräver

Lydelsen: att ändra inställningen i en komponent i gränssnittet får inte automatiskt leda till ett byte av sammanhang, om inte användaren har fått veta det i förväg. W3C räknar att kryssa i en ruta, skriva i ett textfält eller välja ett annat alternativ i en lista som att ändra en inställning. Att klicka på en länk eller en knapp som skickar formuläret är inte en inställning, utan en aktivering, och omfattas inte.

Det betyder att du får skicka kunden vidare när kunden trycker på ”Fortsätt till betalning”. Du får inte göra det när kunden bara valt något. W3C har två fall som räknas som fel: att ett formulär skickas in automatiskt när ett fält fått ett värde (F36), och att ett nytt fönster öppnas utan förvarning när en radioknapp, kryssruta eller lista ändras (F37).

Om en ändring ändå ska få effekt direkt, finns två vägar som W3C anger som tillräckliga: en knapp som utför ändringen (G80), eller en text som beskriver vad som händer innan kunden gör valet (G13). W3C anmärker också att ändrat innehåll inte alltid är ändrat sammanhang. Om bara en del av sidan uppdateras och sidans struktur består, till exempel att ett fält dyker upp när man valt ett alternativ, är kriteriet uppfyllt.

Samma regel gäller valen på produktsidan, som storlek, färg och antal. Det tar vi upp i Produktsidan i webbutiken: varianter, galleri och knappar.

Vanliga fel i webbutiker

Det här är mönster som är lätta att råka bygga, och som en kontroll mot kriterierna fångar:

1. Betalsättet skickar iväg kunden. Valet av radioknapp eller kort laddar om sidan, eller går vidare till nästa steg, utan att kunden tryckt på något. Den som navigerar mellan alternativen med piltangenterna hamnar då i ett nytt steg innan kunden hunnit titta på alla.
2. Landslistan laddar om kassan. Varje piltryck i listan byter land och hämtar sidan på nytt, och fokus hamnar någon annanstans. Ofta försvinner det som redan skrivits i fälten.
3. Rabattkoden laddar om hela sidan. Kunden trycker Enter i kodfältet och formuläret skickas, i stället för att koden prövas. Det tappar ofta inmatningen i övriga fält.
4. Ingen sammanfattning före betalning. Kunden går från sista adressfältet direkt till betalning, och totalbeloppet visas bara i en ruta längre ned.
5. Adressen går inte att ändra utan att börja om. Kunden upptäcker ett felstavat gatunamn i sista steget och måste tömma varukorgen eller gå tillbaka till början.
6. Knappen säger inte vad den gör. ”Nästa” eller ”Klar” kan vara ett steg framåt eller själva köpet. Det ska framgå när betalningen sker.

Så kontrollerar du

Gå igenom ett riktigt köp, helst med en testprodukt och ett testkort om betalleverantören erbjuder det. Använd bara tangentbordet. Skriv ned varje ställe där något händer.

1. Notera varje sidbyte och varje omladdning. Hände det när du tryckte på en knapp, eller när du valde något?
2. Välj land, leveranssätt och betalsätt med piltangenterna. Ligger du kvar där du var, eller flyttas du?
3. Ange en rabattkod och tryck Enter. Skickas formuläret, eller prövas koden?
4. Hitta sammanfattningen före sista knappen. Står varor, pris, frakt, adress och betalsätt där? Går varje del att ändra utan att börja om?
5. Lämna ett fält tomt eller skriv fel format i ett fält, och kontrollera att du får felet i text och kan rätta det innan köpet går igenom.
6. Läs knapptexten på den sista knappen högt. Förstår en förstagångskund att köpet läggs när knappen trycks?

Det är ett bra jobb att göra med en skärmläsare också, men flera av kontrollerna ovan går att göra med bara tangentbordet och uppmärksamhet.

Så rättar du i princip

• Byt automatiska omladdningar vid val mot en uppdateringsknapp bredvid listan, eller uppdatera bara den del av sidan som ändras, så att fokus ligger kvar där kunden är.
• Låt valet av betalsätt bara markera valet. Själva betalningen startar först när kunden trycker på den sista knappen.
• Ge rabattkoden en egen knapp (”Använd kod”) som är kopplad till fältet, så att Enter i övriga fält inte skickar koden.
• Lägg en sammanfattning direkt före sista knappen, med en ”Ändra”-länk vid varje del. Länkens text bör säga vad den ändrar, till exempel ”Ändra leveransadress”.
• Ge den sista knappen en text som säger att köpet läggs, och skriv beloppet i närheten av den.
• Om något ändå måste ske direkt vid ett val, skriv det i förväg intill kontrollen, så att kunden vet vad som kommer att hända.

Vad AccessAudit kan och inte kan se

Gratistestet läser källkoden på upp till fem sidor, och månadsgranskningen kör axe-core i en riktig webbläsare. Båda hittar fält utan etikett, men inget av dem kan bedöma om en kassa har en sammanfattning före köp eller om ett val utlöser ett sidbyte. De frågorna kräver att en människa går igenom köpet, vilket är skälet till arbetsgången ovan. Se också checklistan.

Nästa steg

1. Gå igenom ett testköp enligt listan ovan och skriv ned varje oväntat sidbyte.
2. Läs formulärguiden för etiketter, felmeddelanden och autocomplete.
3. Kör det gratis testet på butiken. Det läser sidan du anger och upp till fyra sidor som den länkar till, med varukorg och kassa först. Kassan kommer bara med om sidan du anger länkar dit och kassan går att nå utan varor i varukorgen.
4. Ta med resultatet till den som underhåller teman eller kassamallen. Är kassan en del av plattformen kan det vara plattformens leverantör som behöver rätta felet.

Källor

• Understanding 3.3.4 Error Prevention (Legal, Financial, Data), W3C, läst 2026-10-25
• Understanding 3.2.2 On Input, W3C, läst 2026-10-25
• PTS: WCAG, tillgängligt webbinnehåll