QualiBooth

development

Kan alla verkligen använda din chatbot?

Chatbottar är nu en primär kundtjänstkanal — men de flesta är otillgängliga. Här är de vanligaste bristerna, varför de spelar roll och vad tillgängliga chatbottar kräver.

6 min read QualiBooth
Chattbubblor på en smartphoneskärm som representerar digital kundtjänstkommunikation.

Chatbottar har ett tillgänglighetsproblem

Kundtjänstchatbottar har blivit det primära — och ofta enda — kontaktalternativet för många digitala produkter. Förväntan är tydlig: om du behöver hjälp, öppna chatten. Om chatten inte fungerar för dig finns det ofta inget annat.

För användare med funktionsnedsättning är denna situation ofta ohållbar. De flesta kommersiella chatbottar uppfyller inte grundläggande tillgänglighetskrav. Skärmläsaranvändare kan inte höra meddelanden när de anländer. Tangentbordsanvändare fastnar inuti chattwidgeten och kan inte ta sig ut. Användare med motoriska funktionsnedsättningar möter tryckytor som är för små för att träffa tillförlitligt. Användare med kognitiva funktionsnedsättningar möter väggar av text och inget tydligt sätt att återhämta sig från en missförstådd fråga.

Detta spelar roll både etiskt och juridiskt. Europeiska tillgänglighetslagen, i kraft sedan juni 2025, omfattar de digitala kundtjänstkanalerna hos företag som ingår i tillämpningsområdet — vilket inkluderar chatbotgränssnitt. ADA i USA har tillämpats på chatbottar i rättstvister om webbtillgänglighet. Om en chatbot är en primär servicekanal är en otillgänglig chatbot en uteslutning från tjänsten.

De sju vanligaste tillgänglighetsbristerna hos chatbottar

1. Saknade ARIA live-regioner

När ett nytt meddelande anländer i ett chattfönster behöver en skärmläsaranvändare höra det. Men skärmläsare läser bara upp innehåll som de fått veta är viktigt och dynamiskt. Utan en ARIA live-region som omsluter behållaren för chattmeddelanden visas meddelanden visuellt men är helt tysta för skärmläsaranvändare.

<!-- Utan live-region: nya meddelanden aviseras inte -->
<div class="chat-messages">
  <!-- Meddelanden läggs till här dynamiskt -->
</div>

<!-- Med live-region: nya meddelanden aviseras när de anländer -->
<div
  class="chat-messages"
  role="log"
  aria-live="polite"
  aria-label="Chattkonversation"
>
  <!-- Meddelanden läggs till här dynamiskt -->
</div>

role="log" är specifikt definierat i ARIA för chattkonversationer och meddelandeflöden. aria-live="polite" aviserar nytt innehåll efter att användaren pausat — mindre störande än assertive i ett samtalssammanhang.

2. Tangentbordsfällor

En tangentbordsfälla uppstår när en användare tabbar in i en komponent och inte längre kan tabba ut — de sitter fast. Chatbotwidgetar hör till de vanligaste ställena där tangentbordsfällor uppträder.

Åtgärden kräver att man implementerar korrekt fokushantering: Tab och Shift+Tab måste navigera genom interaktiva element inuti chatten, och Escape måste stänga chatten och återföra fokus till elementet som utlöste den. WCAG 2.1.2 No Keyboard Trap (nivå A) omfattar detta krav.

Att testa detta är enkelt: öppna din chatbot med enbart tangentbordet, tabba genom alla interaktiva element inuti den och bekräfta att du kan ta dig ut med Escape eller en tydligt synlig stängningsknapp.

3. Otillräcklig färgkontrast

Chatbottar återges ofta i varumärkesfärger, och varumärkesfärger testas ofta inte mot WCAG:s kontrastkrav. Vanliga brister:

  • Text i chattbubblor som inte uppfyller 4,5:1 kontrast mot bubblans bakgrund
  • Platshållartext i inmatningsfält under kontrasttrösklarna
  • Tidsstämpeltext i mycket ljusgrått

Kontrastkravet gäller chatbotgränssnittet precis som det gäller resten av din webbplats — det finns inget undantag för widgetar.

4. Omärkta inmatningsfält och knappar

Chattens inmatningsfält — “Skriv ditt meddelande…” — måste ha en programmatiskt associerad etikett, inte bara platshållartext. Platshållartext försvinner så snart användaren börjar skriva och är inte en tillförlitlig ersättning för en etikett.

Skicka-knappen, minimera-knappen, stäng-knappen och alla andra interaktiva kontroller måste ha tillgängliga namn. En “skicka”-knapp med enbart en ikon utan text och utan aria-label läses upp av skärmläsare som “knapp” utan någon beskrivning av dess syfte.

<!-- Saknad etikett: underkänns -->
<input type="text" placeholder="Skriv ett meddelande...">
<button><svg><!-- skicka-ikon --></svg></button>

<!-- Med etikett och aria-label: godkänns -->
<label for="chat-input" class="sr-only">Skriv ditt meddelande</label>
<input type="text" id="chat-input" placeholder="Skriv ett meddelande...">
<button aria-label="Skicka meddelande">
  <svg aria-hidden="true"><!-- skicka-ikon --></svg>
</button>

5. Tryckytor för små för användare med motoriska nedsättningar

WCAG 2.2 introducerade 2.5.8 Target Size (Minimum) på nivå AA, som kräver att interaktiva element har en minsta tryckyta på 24×24 CSS-pixlar. Många chatbotgränssnitt placerar knappar för att stänga, minimera och skicka emoji på 16–20 pixlar — långt under denna tröskel.

För användare med motoriska funktionsnedsättningar, tremor eller nedsatt finmotorik är små tryckytor faktiskt oanvändbara. Chatbottens åtgärdsknappar hör till de UI-element som oftast drabbas.

6. Ingen varning om tidsgräns eller förlängning av session

Många chatbottar avslutar en inaktiv session efter en viss period. När detta sker utan varning kan användare som behöver längre tid att formulera eller läsa meddelanden — inklusive många användare med kognitiva eller motoriska funktionsnedsättningar — förlora sin konversation utan någon möjlighet att förlänga sessionen.

WCAG 2.2.1 Timing Adjustable (nivå A) kräver att när en tidsgräns är satt ska användare kunna stänga av den, förlänga den, eller så ska gränsen vara minst 20 timmar. En chatbot som avslutar sessioner efter 5 minuters inaktivitet utan varning är inte regelefterlevande.

7. Komplext språk och ingen återhämtning från fel

Chatbottar är bara användbara om användare kan kommunicera effektivt med dem. För användare med kognitiva funktionsnedsättningar, inlärningssvårigheter eller lägre läskunnighet är en chatbot som använder jargong, ger långa väggar av text utan struktur, eller misslyckas tyst när den inte förstår en fråga, funktionellt otillgänglig.

Tillgängligt chatbotinnehåll:

  • Använder enkelt språk (korta meningar, vanliga ord)
  • Delar upp svaren i skummbara enheter i stället för att presentera stycken
  • Erbjuder tydlig återhämtning från fel: när botten inte förstår säger den det uttryckligen och erbjuder specifika alternativ
  • Stödjer användare i att omformulera frågor i stället för att bara säga “Jag förstod inte det”

Nya WCAG 2.2-kriterier som är särskilt relevanta för chatbottar

WCAG 2.2 lade till flera framgångskriterier som gäller med särskild kraft för chattgränssnitt:

2.4.11 Focus Not Obscured (Minimum) — nivå AA. När en chattwidget är öppen får den inte helt dölja det fokuserade elementet bakom sig. Många chattwidgetar visas ovanpå sidinnehåll och skymmer det fokuserade elementet när användare tabbar genom sidan under.

2.4.12 Focus Not Obscured (Enhanced) — nivå AAA. Det fokuserade elementet bör vara helt synligt.

2.5.7 Dragging Movements — nivå AA. Om din chattwidget kan flyttas genom att dras måste ett alternativ med en enda pekare finnas.

2.5.8 Target Size (Minimum) — nivå AA, som beskrivits ovan.

Så testar du din chatbot

  1. Endast tangentbord: öppna chatten utan att använda mus. Tabba genom alla element. Verifiera att du kan skriva, skicka meddelanden och stänga widgeten med enbart tangentbordet. Bekräfta att du kan ta dig ut med Escape.

  2. Skärmläsare: öppna NVDA (Windows, gratis) eller VoiceOver (Mac/iOS, inbyggt) och interagera med chatten. Verifiera att meddelanden aviseras när de anländer. Verifiera att inmatningar och knappar är korrekt märkta.

  3. Zooma till 200 %: verifiera att chattgränssnittet inte svämmar över eller skymmer sidinnehåll när texten förstoras.

  4. Kontrastkontroll: använd ett webbläsartillägg som axe DevTools eller WAVE för att kontrollera kontrasten i chattgränssnittet.

  5. Mobil: testa tryckytornas storlek och verifiera att chatten fungerar med tillgänglighetsfunktioner i iOS/Android (VoiceOver, TalkBack).

Om du integrerar en tredjepartschatbot, bedöm leverantörens tillgänglighet innan du väljer. Be om deras VPAT (Voluntary Product Accessibility Template) för att förstå deras uppgivna konformitetsnivå. Testa widgeten själv — leverantörens påståenden ersätter inte direkt testning.

Att bygga in tillgänglighet i chatbottar från början är betydligt billigare än att bygga om det i efterhand. Om du utvärderar chatbotplattformar, kör varje kandidat genom denna checklista innan du bestämmer dig.

För en omfattande granskning av din chatbot och resten av din digitala kundtjänstupplevelse, prata med vårt team eller börja med en gratis skanning av dina publika sidor.

Testa din chatbot och hela din webbplats för tillgänglighetsproblem