Tillgängliga kontaktformulär och tillgänglighetsdirektivet

Ett kontaktformulär är ofta den enda dörren mellan en besökare och ditt företag. Om den dörren bara kan öppnas med mus, god syn och tålamod att lösa ett suddigt bildpussel blir vissa människor helt enkelt stående utanför. Sedan mitten av 2025 är detta inte längre bara en fråga om användbarhet: för många företag som säljer till konsumenter i EU har det blivit en rättslig fråga.

Vad tillgänglighetsdirektivet omfattar

Tillgänglighetsdirektivet (direktiv (EU) 2019/882) tillämpas sedan den 28 juni 2025. Det ställer tillgänglighetskrav på vissa produkter och tjänster som erbjuds konsumenter – bland annat e-handel, banktjänster för konsumenter, e-böcker, elektronisk kommunikation och delar av persontransporter. För en webbplats innebär det nätbutiken eller banktjänsten som helhet, inklusive de formulär som kunder använder för att kontakta dig, ställa frågor eller klaga. Mikroföretag som tillhandahåller tjänster är undantagna: företag med färre än tio anställda och en årsomsättning eller balansomslutning på högst 2 miljoner euro. Erbjudanden som enbart riktar sig till andra företag faller i regel utanför tillämpningsområdet.

Varje medlemsstat har genomfört direktivet i nationell rätt. I Tyskland är det Barrierefreiheitsstärkungsgesetz (BFSG), i Polen en lag från 2024 om att säkerställa att vissa produkter och tjänster uppfyller tillgänglighetskrav. Tillsynsmyndigheter och sanktioner skiljer sig åt mellan länder, men den tekniska måttstocken är i stort sett densamma: i praktiken den europeiska standarden EN 301 549, som i sin tur bygger på Web Content Accessibility Guidelines (WCAG).

Varför det lönar sig även utan rättslig skyldighet

Kanske är ditt företag undantaget, eller så betjänar du bara andra företag. Tillgängliga formulär är ändå värda det, av en enkel anledning: varje person som ger upp halvvägs är en förfrågan du aldrig får. De förbättringar som hjälper en skärmläsaranvändare hjälper också någon som fyller i formuläret på mobilen på ett tåg, i starkt solljus, med en bruten handled eller på ett andraspråk. Tydliga etiketter och hjälpsamma felmeddelanden innebär färre avbrutna formulär för alla – och inget av det gör ditt spamskydd svagare.

En praktisk checklista med hänvisningar till WCAG 2.2

• Synliga etiketter kopplade till sina fält (1.3.1, 3.3.2): varje fält har en synlig etikett som är kopplad till det via for/id. En platshållare ensam är ingen etikett – den försvinner så snart någon börjar skriva.
• Felmeddelanden som förklarar lösningen (3.3.1, 3.3.3): ange fältet, säg vad som är fel och hur det rättas – i text, inte bara med en röd ram. ”Ange en e-postadress som namn@example.com” är bättre än ”Ogiltig inmatning”.
• Full tangentbordsstyrning (2.1.1, 2.1.2): varje fält, kryssruta, CAPTCHA och skicka-knappen kan nås och användas med Tab, mellanslag och Enter, utan tangentbordsfällor.
• Synligt fokus (2.4.7): du kan alltid se vilket fält som är aktivt. Att ta bort webbläsarens fokusmarkering utan ersättning uppfyller inte detta kriterium.
• Tillräcklig kontrast (1.4.3): text, etiketter och felmeddelanden har ett kontrastförhållande på minst 4,5:1 mot bakgrunden (3:1 för stor text).
• Målstorlek (2.5.8): knappar, kryssrutor och länkar är minst 24 × 24 CSS-pixlar, eller har tillräckligt med utrymme runt sig.
• CAPTCHA-alternativ (1.1.1) och tillgänglig autentisering (3.3.8): 1.1.1 kräver ett textalternativ och CAPTCHA:n i mer än en sinnesform; 3.3.8 gäller strikt taget inloggningssteg, men tanken går att överföra – ett pussel som att skriva av förvrängda bokstäver eller lösa en summa bör inte vara den enda vägen igenom. Erbjud ett alternativ eller använd en metod som inte kräver något pussel alls.
• Honeypots dolda för hjälpmedel: fällfältet får aria-hidden="true" på sitt omslutande element och tabindex="-1", så att skärmläsar- och tangentbordsanvändare aldrig hamnar i det.

CAPTCHA och honeypots: där spamskydd möter tillgänglighet

Strikt taget handlar kriterium 3.3.8 om inloggnings- och autentiseringssteg, inte om kontaktformulär. Tanken bakom det går dock bra att överföra: att skriva förvrängda bokstäver, lösa en summa eller välja trafikljus i ett rutnät av bilder stänger helt ute vissa människor. Alternativ som oftast fungerar utan något pussel – som Cloudflare Turnstile, Friendly Captcha, en honeypot i kombination med en tidskontroll eller filtrering på serversidan som Akismet – håller spam borta utan att be besökarna bevisa något. En honeypot är bara vänlig om den verkligen är osynlig, även för skärmläsar- och tangentbordsanvändare:

<div class="hp" aria-hidden="true">
  <label for="hp-website">Lämna detta fält tomt</label>
  <input type="text" id="hp-website" name="website"
         tabindex="-1" autocomplete="off">
</div>
<!-- CSS: .hp { position: absolute; left: -10000px; } -->

Testa ditt eget formulär på femton minuter

1. 1Lägg undan musen och fyll i hela formuläret bara med tangentbordet. Når du varje fält och skicka-knappen, och ser du alltid var du befinner dig?
2. 2Skicka formuläret tomt, sedan med en felaktig e-postadress. Visas felen som text bredvid rätt fält, och är det tydligt vad du ska göra?
3. 3Öppna sidan på en mobil eller zooma webbläsaren till 200 %. Är allt läsbart, är knapparna lätta att trycka på, och täcker en cookiebanner eller chattwidget skicka-knappen?
4. 4Slå på en skärmläsare (VoiceOver, NVDA eller TalkBack) och lyssna: läses varje fält upp med sin etikett, och förblir honeypoten tyst?
5. 5Kör en automatiserad kontroll som axe-core. Den hittar saknade etiketter och kontrastproblem snabbt, men inte allt – de manuella stegen ovan behövs fortfarande.

Om du hellre vill börja med en översikt tittar formexposed på dina offentliga formulär utifrån, utan att skicka något. Dess tillgänglighetskontroller kör axe-core på varje formulär, flaggar CAPTCHA utan tillgängligt alternativ och honeypots som skärmläsare läser upp, och tittar på formuläret på en mobil – tryckytor, överlägg som täcker skicka-knappen, horisontell rullning. Gratisgranskningen visar den övergripande nivån; detaljerna finns i den fullständiga rapporten. Det är en bra utgångspunkt för listan ovan, inte en ersättning för tester med riktiga människor.