Så bygger du diagram som fungerar för alla

Diagramproblemet

Diagram och grafer är till sin natur visuella objekt. De kodar information genom form, position och färg — tre kanaler som antingen är meningslösa eller förvrängda för en betydande del av din publik.

Ungefär 8 % av alla män har någon form av defekt färgseende. Skärmläsaranvändare får ingen meningsfull information från ett SVG-stapeldiagram om inte utvecklaren uttryckligen har tillhandahållit den. Och tangentbordsanvändare upplever ofta att interaktiva diagram är helt onåbara.

Resultatet: datavisualisering är förmodligen det område inom webbdesign där klyftan mellan vad seende användare upplever och vad alla andra upplever är som störst. Och det är en klyfta som organisationer sällan lägger märke till, eftersom tillgänglighetsgranskningar fokuserar på formulär och navigering innan de kommer till diagrammen på rapportsidan.

Den här guiden går igenom vad tillgänglig datavisualisering faktiskt kräver — inte en checklista, utan en förståelse för varför diagram brister och vad man kan göra åt det.

Varför diagram är särskilt svåra

De flesta HTML-element har en inbyggd roll, ett namn och ett tillstånd som hjälpmedelsteknik förstår. En <button> är en knapp. En <table> är en tabell med rader och kolumner. Ett formulärfält har en etikett.

Ett diagram renderat som SVG eller canvas har inget av detta. Det är en teckning. Skärmläsare ser en bild (om du har tur) eller ingenting alls. Utvecklaren måste bygga upp det semantiska lagret från grunden.

Samtidigt är diagram ofta det viktigaste innehållet på en sida. Ett stapeldiagram som visar månadsintäkter, en linjegraf som följer användartillväxten, ett cirkeldiagram som bryter ned fördelningen per kategori — det är ofta därför användaren är på sidan. Att utestänga en betydande andel av besökarna från dem är ett allvarligt problem, inte en mindre olägenhet.

Färgproblemet: förlita dig aldrig på enbart färg

Det vanligaste tillgänglighetsfelet i diagram är att använda färg som enda sätt att skilja dataserier eller kategorier åt.

Ett linjediagram med fyra linjer som enbart skiljs åt genom färg — röd, blå, grön, orange — är oläsbart för många användare med defekt färgseende, och helt meningslöst för alla som använder ett högkontrastläge eller en gråskaleskärm.

Lösningen är redundant kodning: använd färg plus minst en annan visuell egenskap.

Linjediagram: använd olika streckmönster tillsammans med färgerna (heldragen, streckad, prickad, streck-prick)
Stapeldiagram: använd texturer eller mönster tillsammans med färgerna, eller lägg dataetiketter direkt på staplarna
Punktdiagram: använd olika markörformer (cirkel, kvadrat, triangel, romb) tillsammans med färgerna
Cirkeldiagram: lägg till textetiketter i eller intill varje sektor — förlita dig aldrig på enbart en teckenförklaring

Detta faller under WCAG 2.2 1.4.1 Användning av färger (nivå A): färg får inte vara det enda sättet att förmedla information.

Kontrast i diagram

Visuella element som inte är text — som staplar, linjer och datapunkter — måste uppnå 3:1 i kontrast mot sin bakgrund enligt 1.4.11 Kontrast för icke-textinnehåll (nivå AA). Testa din diagrampalett med ett kontrastverktyg — många varumärkespaletter som ser bra ut på stora ytor klarar inte kravet i mindre storlekar.

Text i diagram — axeletiketter, dataetiketter, teckenförklaringar — måste uppfylla samma kontrastkrav som brödtext: 4,5:1 för normal text, 3:1 för stor text enligt 1.4.3 Kontrast (minimum).

Att tillhandahålla textalternativ

Varje diagram behöver ett textalternativ som förmedlar de data det visar. Exakt vilken form det tar beror på hur komplexa data är.

Enkla diagram: beskrivande alt-text

För ett stapeldiagram som visar fem värden kan ett välskrivet alt-attribut sammanfatta den viktigaste slutsatsen:

<img
  src="monthly-revenue.png"
  alt="Monthly revenue Q1 2025: Jan £42k, Feb £38k, Mar £51k,
       Apr £49k, May £56k. Steady upward trend from February onwards."
>

Alt-texten här gör två saker: den anger datapunkterna och sammanfattar den centrala insikten. Beskriv inte bara diagrammet visuellt (“ett stapeldiagram som visar intäkter”). Beskriv vad diagrammet kommunicerar.

Komplexa diagram: kompletterande datatabeller

När ett diagram innehåller mer data än vad som ryms i ett alt-attribut, tillhandahåll en tillgänglig datatabell i närheten. Den hjälper också personer som föredrar tabelldata framför visuella format. Tabellen kan vara dold som standard men ändå nåbar:

<figure>
  <figcaption>Revenue by region, Q1 2025</figcaption>
  <svg aria-labelledby="chart-title" aria-describedby="chart-desc" role="img">
    <title id="chart-title">Revenue by region, Q1 2025</title>
    <desc id="chart-desc">Bar chart showing UK leading with £180k,
    followed by DE at £124k, FR at £98k, and NL at £71k.</desc>
    <!-- chart content -->
  </svg>
  <details>
    <summary>View as table</summary>
    <table>
      <caption>Revenue by region, Q1 2025</caption>
      <thead><tr><th>Region</th><th>Revenue</th></tr></thead>
      <tbody>
        <tr><td>UK</td><td>£180,000</td></tr>
        <tr><td>DE</td><td>£124,000</td></tr>
        <tr><td>FR</td><td>£98,000</td></tr>
        <tr><td>NL</td><td>£71,000</td></tr>
      </tbody>
    </table>
  </details>
</figure>

SVG-specifika mönster

SVG-diagram som renderas inline (i stället för som bildfiler) kan göras direkt tillgängliga med ARIA. Viktiga mönster:

Lägg till role="img" på <svg>-elementet
Tillhandahåll en <title> som första barn till <svg> och koppla den med aria-labelledby
Lägg till en <desc> för längre beskrivningar och koppla den med aria-describedby
Märk dekorativa element (rutnätslinjer, skalstreck) med aria-hidden="true" för att minska bruset

För interaktiva diagram där användare kan välja datapunkter behöver varje interaktivt element en korrekt roll, ett namn och tangentbordsstöd.

Tangentbordsnavigering i interaktiva diagram

Om dina diagram är interaktiva — verktygstips vid hovring, klickbara segment, markering och zoomning — måste de vara fullt hanterbara med tangentbord enligt 2.1.1 Tangentbord (nivå A).

För diagram med många datapunkter, implementera ett mönster med roterande tabindex: endast ett element i diagrammet ligger i tabbordningen åt gången, och piltangenterna flyttar mellan datapunkterna inom diagrammet.

<!-- Each bar is a button, navigable with arrow keys -->
<g role="group" aria-label="Monthly revenue bars">
  <rect
    role="button"
    tabindex="0"
    aria-label="January: £42,000"
    onkeydown="handleChartKey(event)"
    ...
  />
</g>

Verktygstips som bara visas vid hovring måste också visas vid tangentbordsfokus. Ett verktygstips som bara är synligt för musanvändare är ett tillgänglighetsfel.

Att välja rätt diagramtyp

Vissa diagramtyper är till sin natur mer tillgängliga än andra. När du har ett val:

Diagramtyp	Tillgänglighet	Kommentar
Stapeldiagram	Hög	Mängder är lätta att koda med etiketter; bra tangentbordsstöd är möjligt
Linjediagram	Hög	Använd olika streckmönster; kommentera viktiga punkter
Tabell	Högst	Lättast att göra tillgänglig; ofta rätt val för data
Punktdiagram	Medel	Kräver noggrann differentiering av markörer; komplex tangentbordsnavigering
Värmekarta	Låg	Färgberoende till sin natur; tillhandahåll alltid ett tabellalternativ
Cirkel/donut	Låg	Svårt att jämföra värden; undvik vid fler än 3–4 segment

När du är osäker är en välformaterad tabell nästan alltid mer tillgänglig än ett diagram — och ofta lättare att läsa oavsett funktionsnedsättning. Använd inte ett diagram för att det ser modernt ut; använd det när det genuint hjälper användare att förstå en trend eller jämförelse snabbare än tabelldata skulle göra.

Testa dina diagram

Automatiserade tillgänglighetsskannrar kan kontrollera saknade alt-attribut och vissa ARIA-mönster, men de kan inte verifiera att diagramdata är meningsfulla, att tangentbordsnavigeringen fungerar korrekt eller att diagrammet är begripligt för en skärmläsaranvändare. Testa med:

En skärmläsare (NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari): navigera till diagrammet och verifiera vad som läses upp
Enbart tangentbord: tabba till diagrammet och bekräfta att alla interaktiva element går att nå och hantera med tangentbordet
Simulering av färgblindhet: använd Chrome DevTools (Rendering > Emulate vision deficiency) för att se hur diagrammet ser ut vid olika typer av defekt färgseende
Zooma till 200 %: verifiera att etiketter och teckenförklaringar inte överlappar eller klipps av

Vår tjänst för skärmläsarutvärdering testar diagram med verkliga användare av hjälpmedelsteknik — det snabbaste sättet att ta reda på vad dina användare faktiskt upplever.