Formulär och felmeddelanden i kassan, del 2

20 oktober 2026

Så gör du kassans formulär begripliga: etiketter, felmeddelanden med förslag, autocomplete och kontroll före köp, med kodexempel och WCAG-kriterier.

Det här är teknisk vägledning och inte juridisk rådgivning. För tolkningsfrågor om Lag (2023:254) om vissa produkters och tjänsters tillgänglighet, vänd dig till Post- och telestyrelsen (PTS).

Det här är del 2 om kassan. Del 1 går igenom sju vanliga fel i korthet. Här tar vi bara formulären, eftersom det är där en kund oftast fastnar: vad fälten heter, vad som händer när något blir fel och hur webbläsaren kan hjälpa till att fylla i.

Varför formulären i kassan är kritiska

En kund som inte förstår vad ett fält vill ha, eller inte hittar vad som är fel när formuläret nekas, köper inte. För den som använder skärmläsare, bara tangentbord eller autofyll är risken större, eftersom ett fel som syns som en röd ruta längre upp på sidan inte behöver märkas alls. Kriterierna nedan handlar om att fältet säger vad det är, att felet sägs i text och att kunden får chans att rätta innan köpet går igenom.

Etiketter som sitter ihop med fältet (3.3.2)

Kriteriet Ledtexter/etiketter eller instruktioner kräver att det finns en etikett eller instruktion när kunden ska fylla i något. En platshållartext (placeholder) räcker inte: den försvinner när man börjar skriva, och den som har svårt att minnas vad fältet gällde får inget stöd.

Fel, med bara platshållare:

<input type="text" name="postnr" placeholder="Postnummer">

Så här blir det rätt, med synlig etikett kopplad med for och id:

<label for="postnr">Postnummer</label>
<input type="text" id="postnr" name="postnr" autocomplete="postal-code">

Behöver fältet ett särskilt format, skriv det före fältet och koppla det med aria-describedby, så att det läses upp tillsammans med etiketten:

<label for="tel">Telefon</label>
<p id="tel-hjalp">Med riktnummer, till exempel 070 123 45 67.</p>
<input type="tel" id="tel" name="tel" autocomplete="tel" aria-describedby="tel-hjalp">

Markera också tydligt vilka fält som är obligatoriska, med text och inte bara en stjärna eller färg.

Felmeddelanden som säger vad som är fel (3.3.1)

Enligt Identifiering av fel ska ett fel som upptäcks automatiskt pekas ut och beskrivas i text. W3C påpekar att det inte räcker att visa formuläret igen utan någon antydan om att inskickningen misslyckades.

I praktiken betyder det:

Meddelandet står vid fältet och nämner fältets namn, till exempel ”Postnummer: fyll i fem siffror.” Ett rött streck eller en röd ikon räcker inte.
Meddelandet är kopplat till fältet med aria-describedby, och fältet har aria-invalid="true" när det är fel.
Om flera fält är fel finns en sammanfattning högst upp i formuläret, och fokus flyttas dit när kunden skickat in. Då hör den som använder skärmläsare direkt att något gick fel, och sammanfattningen kan länka till varje fält.

<div role="alert" tabindex="-1" id="fel-sammanfattning">
  <h2>2 fält behöver rättas</h2>
  <ul>
    <li><a href="#postnr">Postnummer: fyll i fem siffror</a></li>
    <li><a href="#epost">E-postadress: lägg till @ och domän</a></li>
  </ul>
</div>

Ett dåligt meddelande är ”Ogiltigt värde” eller en rödmarkerad ruta utan text. Ett bra säger vilket fält det gäller och vad som saknas.

Förslag vid fel (3.3.3)

Förslag vid felhantering går ett steg längre: när butiken vet hur felet kan rättas ska den säga det. Ett exempel: ett meddelande som ”E-postadressen är inte giltig” klarar 3.3.1. Skriver butiken i stället ”Ange en giltig e-postadress i formatet namn@domän.se” klarar den både 3.3.1 och 3.3.3. Kriteriet gäller inte om förslaget skulle äventyra säkerheten.

Dåligt	Bättre
Fel postnummer	Postnumret ska ha fem siffror, till exempel 111 22.
Ogiltig e-post	E-postadressen saknar @. Skriv den som `namn@exempel.se`.
Obligatoriskt fält	Fyll i vilken gata varan ska skickas till.

Autocomplete för kundens egna uppgifter (1.3.5)

Identifiera syfte med inmatning gäller fält som samlar in uppgifter om kunden själv. Fältet ska ha ett autocomplete-värde ur den lista som WCAG och HTML-standarden anger, så att webbläsaren kan fylla i och hjälpmedel kan visa vad fältet gäller. Kravet gäller inte rabattkoden eller ett meddelande till butiken.

Fält	autocomplete-värde
Förnamn	given-name
Efternamn	family-name
E-postadress	email
Telefon	tel
Gatuadress (en rad per fält)	address-line1
Gatuadress (ett fält)	street-address
Postnummer	postal-code
Land	country (landskod) eller country-name (landets namn)
Namn på kortet	cc-name
Kortnummer	cc-number
Giltighetstid	cc-exp
Säkerhetskod	cc-csc

Ortsfältet har värdet address-level2 i HTML-standardens lista, som anger det som andra administrativa nivån i adressen. Kontrollera värdena mot listan i WCAG 2.1 innan du ändrar något. Kortfälten ligger ofta i en inbäddad ruta från betalleverantören, och då styr leverantören attributen, inte du.

Inga överraskningar när kunden fyller i (3.2.2)

Enligt Vid inmatning får ett ändrat värde i ett formulärfält inte automatiskt ändra sammanhanget, till exempel skicka in formuläret eller byta sida, om kunden inte har fått veta det i förväg. Typexemplet i en kassa är en rullista för land som laddar om sidan så fort man väljer något med tangentbordets piltangenter, så att man aldrig hinner ända ned till rätt land. Lösningen är en knapp bredvid listan (”Uppdatera”) eller att bara de delar av formuläret som behöver ändras uppdateras utan att fokus flyttas.

Kontroll före köp (3.3.4)

Ett köp är en ekonomisk transaktion, och Förebyggande av fel (juridiskt, ekonomiskt, data) kräver att minst ett av tre villkor är uppfyllt: köpet kan ångras, uppgifterna kontrolleras och kunden får chans att rätta, eller det finns en sammanställning där kunden kan granska, bekräfta och ändra innan köpet slutförs. De flesta butiker uppfyller det med en sista sammanställning: varor, pris, leveransadress och betalsätt, med en länk för att ändra varje del och en tydlig knapp för att lägga beställningen.

Vad du kan ändra på de vanliga plattformarna

Det mesta av kassans kod styrs av plattformen. Det här är vad hjälpsidorna anger.

Shopify: Under Inställningar och Kassa kan en del av fälten ställas som obligatoriska, valfria eller tas bort, men Shopify skriver att inte alla fält i kassan kan ändras. Utseendet kan ändras i redigeraren för kassa och konton, och appar som ändrar kassans informations-, leverans- och betalsidor är enligt Shopify bara tillgängliga med Shopify Plus. Källor: hjälpsidorna om kassans formulärval och om anpassning av kassan.
WooCommerce: Kassablocket har inställningar för om fältet för företag, adressrad 2 och telefon ska visas och om adress och telefon ska vara obligatoriska. Etiketter och ordning kan ändras i blockredigeraren. Källa: WooCommerces dokumentation om kassablocket.
Wix: Vi hittade ingen hjälpsida som beskriver hur man ändrar etiketter eller felmeddelanden i Wix kassa, så den uppgiften saknas här. Kontrollera i Wix hjälpcenter eller fråga Wix support.

På hostade plattformar går det alltså sällan att ändra själva HTML-koden i kassan. Då är åtgärden att välja inställningar som ger så få och tydliga fält som möjligt, och att kontakta plattformen om ett fel ligger i deras kod.

Vad AccessAudit kontrollerar

Det gratis testet på butik.nightwave.se/tillganglighet läser källkoden på upp till fem sidor. För formulär kontrollerar det att fält har en etikett och flaggar fält som bara har en platshållartext. Det kontrollerar inte autocomplete-attribut, felmeddelanden, fokus efter inskickning eller om en ändring i en rullista byter sida. Månadsgranskningen kör dessutom axe-core i en riktig webbläsare på sidorna, men även den ersätter inte en människas bedömning av om ett felmeddelande är begripligt.

Gör så här

Gå igenom kassan med bara tangentbordet och fyll i varje fält fel med flit: lämna det tomt, skriv ett postnummer med fyra siffror, skriv en e-postadress utan @.
Läs felen i en skärmläsare eller se om de står i text vid fältet.
Kontrollera att varje personuppgiftsfält har rätt autocomplete.
Testa rullistan för land med piltangenterna.
Kör det gratis testet och gå igenom den checklista som hör till.