Inbäddad kassa och tredje part: vad du själv kan rätta

29 oktober 2026

Inbäddade betalfönster, leveransval och recensioner: fem saker på din egen sida som du kan kontrollera och rätta, med kodexempel och tester.

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

De flesta svenska webbutiker har något inbäddat från en annan leverantör: ett betalfönster, en leveransväljare, ett delbetalningsalternativ eller en recensionswidget. Ofta ligger det i en iframe, alltså en ruta på din sida som visar en annan webbplats. Du kan inte ändra koden inuti rutan, men du äger sidan runt den, och det finns fem saker där som du själv kan kontrollera och rätta. Den här guiden går igenom dem, med WCAG-kriterium, kodexempel och ett sätt att testa varje punkt. Den hör ihop med punkterna om inbäddat på produktsidan och tredje part i kassan i checklistan.

Vad som ligger i din kod och vad som ligger i rutan

Iframe-elementet, dess title och allt som sitter runt det på sidan är din kod. Innehållet i rutan kommer från leverantören och styrs av dennes kod. Den uppdelningen avgör vad du kan rätta själv.

Vi säger inget här om vem som juridiskt svarar för vad. Lagen gäller den tjänst kunden möter, och frågor om hur den ska tolkas i just ditt fall hänvisar vi till PTS. Det du kan göra är att se till att din del är i ordning och att ta reda på hur leverantörens del ser ut.

Rutan saknar namn (4.1.2 och 2.4.1)

Namn, roll, värde kräver att alla komponenter har ett namn som programvara kan läsa. För iframe pekar W3C på teknik H64, att använda title-attributet, och samma teknik står som tillräcklig för Hoppa över grupperat innehåll. Utan title saknar rutan ett namn, och den som använder skärmläsare kan inte avgöra vad den innehåller innan hen går in i den. W3C listar dessutom ett testfall som kräver att iframe har ett icke tomt tillgängligt namn.

Före:

<iframe src="https://betalning.example.com/kassa?id=123"></iframe>

Efter:

<iframe src="https://betalning.example.com/kassa?id=123" title="Betalning med kort"></iframe>

Titeln ska säga vad rutan innehåller eller gör. ”iframe” och ”inbäddning” säger ingenting. Har du flera rutor på samma sida ska titlarna skilja sig åt, till exempel ”Betalning med kort” och ”Välj leveranssätt”. Hur du skriver bra namn och vad testet kontrollerar står i avsnittet Iframe utan titel i guiden om länktexter, rubriker och struktur, så vi upprepar det inte här.

Så testar du: öppna sidans källkod och sök på iframe. Varje träff som syns för besökaren ska ha en title som beskriver innehållet.

Fokus in i rutan och ut igen (2.1.1 och 2.4.3)

Tangentbord kräver att allt går att använda utan mus. W3C listar ett testfall som är lätt att råka ut för: en iframe med interaktiva element får inte tas bort från tabbordningen. Ett tabindex=-1 på iframe-elementet, som någon lagt dit för att slippa ett extra tabbstopp, gör att tangentbordsanvändaren aldrig kommer in i betalfönstret.

Fokusordning kräver att tabbordningen följer innehållets mening. W3C ger exempel på icke modala dialoger där dialogens element läggs in i tabbordningen direkt efter knappen som öppnade den, och där ordningen går från knappen direkt till nästa element när dialogen är stängd. Samma tanke gäller en ruta som visas först när kunden klickar på Betala.

Kontrollera tre saker:

Att Tab når rutan på rätt ställe i flödet, alltså efter knappen eller fältet som hör till den.
Att du kan ta dig ut ur rutan med Tab och Skift+Tab. Fastnar fokus finns en tangentbordsfälla, och då behöver du ta det med leverantören.
Att fokus efter slutförd betalning hamnar på orderbekräftelsen och inte på sidans topp. Det är inte ett krav i någon W3C-sida vi läst, utan ett praktiskt råd: en kund som tabbar ska inte behöva leta efter beskedet om att köpet gick igenom.

Om din egen kod öppnar rutan med JavaScript kan du flytta fokus dit när den visas:

<button type="button" id="betala">Betala</button>
<div id="betalruta" hidden>
  <iframe id="betalram" src="about:blank" title="Betalning med kort" tabindex="0"></iframe>
</div>

document.getElementById("betala").addEventListener("click", () => {
  const ram = document.getElementById("betalram");
  ram.src = "https://betalning.example.com/kassa?id=123";
  document.getElementById("betalruta").hidden = false;
  ram.focus();
});

Så testar du: lägg undan musen och gå igenom kassan med Tab, Skift+Tab, Enter och Mellanslag från sidans början till orderbekräftelsen. Skriv ned var fokus hoppar eller fastnar.

Zoom och mobil (1.4.4 och 1.4.10)

Förändring av textstorlek kräver att innehållet går att förstora till 200 procent utan att information försvinner. W3C listar ett testfall där förstorad text klipps av med CSS overflow. Flexibel layout kräver att innehållet går att läsa i 320 CSS-pixlars bredd utan scroll i två riktningar. W3C räknar det som motsvarande en skärm på 1280 pixlar förstorad till 400 procent.

En iframe med fast höjd och fast bredd är ett fel som är lätt att göra. Betalfönstret ser rätt ut på datorn, men när kunden förstorar sidan eller öppnar den på en smal mobil blir rutan för trång. Innehållet klipps, eller så får rutan en egen scrollist inuti sidans scroll.

W3C beskriver att ett undantag från flexibel layout, till exempel för en video, bara gäller den sektionen och inte övrigt innehåll på sidan. W3C visar också att en onödig sidledsscroll på hela sidan kan undvikas genom att begränsa mediets bredd till behållaren. Gör samma sak med rutan: sätt max-width.

Före:

<iframe src="https://betalning.example.com/kassa?id=123" width="600" height="400" title="Betalning med kort"></iframe>

Efter:

<iframe src="https://betalning.example.com/kassa?id=123" title="Betalning med kort" class="betalram"></iframe>

.betalram {
  width: 100%;
  max-width: 40rem;
  min-height: 28rem;
  border: 0;
}

Principen är att bredden följer sidan och att höjden är så stor att innehållet inte klipps. Kolla i leverantörens egen dokumentation om rutan kan meddela sin höjd till sidan, så att du kan sätta höjden efter innehållet. Finns inget sådant får du ställa en rejäl minimihöjd och pröva den i förstorat läge.

Så testar du: öppna kassan i webbläsaren och förstora till 200 procent, sedan till 400 procent (motsvarar 320 pixlars bredd på en dator med 1280 pixlars fönster). Se om något klipps, om rutan får egna scrollister och om sidan får scroll i sidled. Gör samma sak på en riktig telefon.

Språk i rutan (3.1.2)

Språk för del av sida säger att språket för delar av innehållet ska anges i koden, så att skärmläsare använder rätt uttal. W3C nämner tekniken H58, att ange språkbyte med språkattribut.

För en iframe betyder det en praktisk kontroll. Visas betalfönstret på engelska på en svensk sida, eller tvärtom, är det leverantörens kod som avgör vilket språk som anges inuti. Du kan inte lägga till ett lang-attribut i innehåll som du inte äger. Det du kan göra är att leta efter en inställning hos leverantören för språk eller region, ofta en parameter i adressen eller en inställning i leverantörens administration, och sätta den till svenska. Avsnittet Sidtitel och språk i webbutiken tar upp språket på din egen sida.

Så testar du: gå igenom kassan och notera vilket språk rutan visar. Lyssna med en skärmläsare och kontrollera att uttalet följer språket i texten.

Vad du ber leverantören om

Rutans innehåll kan du bara granska utifrån, så det du kan göra är att fråga och att prova själv.

Be om leverantörens tillgänglighetsredogörelse eller dokumentation om WCAG. Finns ingen publik, spara svaret du får.
Testa själv med tangentbord och skärmläsare i din egen kassa. Leverantörens dokument beskriver deras produkt, inte hur den uppför sig på din sida med din layout.
Skriv ned datumet för kontrollen, vad du testade och vad du hittade. Om något ändras hos leverantören vet du då vilken version som gällde.

Vi nämner ingen leverantör vid namn i den här guiden. Vi har inte granskat någon av dem, och det som står om vad en viss leverantör lovar ska du alltid kunna läsa i leverantörens egen publika dokumentation.

Vad gratistestet och månadsgranskningen ser

Det gratis testet på butik.nightwave.se/tillganglighet läser källkoden på upp till fem sidor. Det hittar iframe som saknar namn, alltså varken har title, aria-label eller aria-labelledby. Det är det första felet i den här guiden. Det ser inte innehållet i rutan.

Månadsgranskningen i AccessAudit kör axe-core i en riktig webbläsare. Den går också in i de rutor som finns på sidan när den laddas, även när innehållet kommer från en annan domän, så ett fel som en knapp utan namn i en recensionsruta kan komma med i rapporten. Ett betalfönster som visas först när kunden har fyllt i sina uppgifter når granskningen däremot inte, eftersom den aldrig fyller i något och aldrig betalar. Granskningen går dessutom igenom sidan med Tab och prövar sidledsscroll i 320 pixlars bredd och i 640 pixlar, som motsvarar 1280 pixlar vid 200 procent zoom. Den bedömer inte om fokus hamnar på orderbekräftelsen eller om språket i rutan stämmer med texten. Tabbordningen kontrolleras för fokusfällor, men en iframe där fokus ligger kvar räknas inte som fälla, eftersom besökaren då tabbar inne i rutan. De punkterna behöver du pröva själv. Gå igenom checklistan, som visar vilka punkter som testas automatiskt och vilka som kräver ett eget test.

Det här är teknisk vägledning och inte juridisk rådgivning. Frågor om hur lagen ska tolkas i ditt fall ställer du till PTS.

Källor

Alla källor lästa 2026-10-28.