Sådan bygger du diagrammer, der fungerer for alle

Diagramproblemet

Diagrammer og grafer er i sagens natur visuelle objekter. De koder information gennem form, position og farve — tre kanaler, der enten er meningsløse eller forvrængede for en betydelig del af dit publikum.

Omkring 8% af alle mænd har en form for nedsat farvesyn. Skærmlæserbrugere får ingen meningsfuld information fra et SVG-søjlediagram, medmindre udvikleren eksplicit har leveret den. Og tastaturbrugere oplever ofte, at interaktive diagrammer er helt uden for rækkevidde.

Resultatet: datavisualisering er formentlig det område af webdesign, hvor kløften mellem det, seende brugere oplever, og det, alle andre oplever, er størst. Og det er en kløft, som organisationer sjældent bemærker, fordi tilgængelighedsrevisioner fokuserer på formularer og navigation, før de når til diagrammerne på rapportsiden.

Denne guide dækker, hvad tilgængelig datavisualisering faktisk kræver — ikke en tjekliste, men en forståelse af, hvorfor diagrammer fejler, og hvad man kan gøre ved det.

Hvorfor diagrammer er særligt svære

De fleste HTML-elementer har en indbygget rolle, et navn og en tilstand, som hjælpeteknologi forstår. En <button> er en knap. En <table> er en tabel med rækker og kolonner. Et formularfelt har en etiket.

Et diagram gengivet som SVG eller canvas har intet af dette. Det er en tegning. Skærmlæsere ser et billede (hvis du er heldig) eller slet ingenting. Udvikleren skal genopbygge det semantiske lag fra bunden.

Samtidig er diagrammer ofte det vigtigste indhold på en side. Et søjlediagram, der viser månedlig omsætning, en kurvegraf, der følger brugervækst, et cirkeldiagram, der opdeler kategorifordeling — det er ofte grunden til, at brugeren er på siden. At udelukke en betydelig del af de besøgende fra dem er et alvorligt problem, ikke en mindre ulempe.

Farveproblemet: stol aldrig på farve alene

Den mest almindelige tilgængelighedsfejl i diagrammer er at bruge farve som den eneste måde at skelne dataserier eller kategorier på.

Et kurvediagram med fire linjer, der kun adskilles ved farve — rød, blå, grøn, orange — er ulæseligt for mange brugere med nedsat farvesyn og fuldstændig meningsløst for alle, der bruger en højkontrasttilstand eller en gråtoneskærm.

Løsningen er redundant kodning: brug farve plus mindst én anden visuel egenskab.

Kurvediagrammer: brug forskellige stregmønstre sammen med farverne (fuldt optrukket, stiplet, punkteret, streg-punkt)
Søjlediagrammer: brug teksturer eller mønstre sammen med farverne, eller tilføj dataetiketter direkte på søjlerne
Punktdiagrammer: brug forskellige markørformer (cirkel, firkant, trekant, rombe) sammen med farverne
Cirkeldiagrammer: tilføj tekstetiketter inde i eller ved siden af hvert udsnit — stol aldrig på en signaturforklaring alene

Dette hører under WCAG 2.2 1.4.1 Brug af farve (niveau A): farve må ikke være det eneste middel til at formidle information.

Kontrast i diagrammer

Ikke-tekstlige visuelle elementer som diagramsøjler, linjestreger og datapunkter skal opfylde 3:1 kontrast mod deres baggrund under 1.4.11 Kontrast for ikke-tekstligt indhold (niveau AA). Test din diagrampalet med et kontrastværktøj — mange brandpaletter, der ser fine ud i store flader, fejler dette krav i mindre størrelser.

Tekst i diagrammer — akseetiketter, dataetiketter, signaturforklaringer — skal opfylde de samme kontrastkrav som brødtekst: 4,5:1 for normal tekst, 3:1 for stor tekst under 1.4.3 Kontrast (minimum).

Sørg for tekstalternativer

Hvert diagram har brug for et tekstalternativ, der formidler de data, det viser. Præcis hvilken form det tager, afhænger af, hvor komplekse dataene er.

Simple diagrammer: beskrivende alt-tekst

For et søjlediagram med fem værdier kan en velskrevet alt-attribut opsummere den vigtigste pointe:

<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-teksten her gør to ting: den angiver datapunkterne og opsummerer den centrale indsigt. Beskriv ikke bare diagrammet visuelt (“et søjlediagram, der viser omsætning”). Beskriv, hvad diagrammet kommunikerer.

Komplekse diagrammer: supplerende datatabeller

Når et diagram indeholder flere data, end der kan være i en alt-attribut, skal du levere en tilgængelig datatabel i nærheden. Det gavner også personer, der foretrækker tabeldata frem for visuelle formater. Tabellen kan være skjult som standard, men skal kunne nås:

<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-specifikke mønstre

SVG-diagrammer, der gengives inline (frem for som billedfiler), kan gøres direkte tilgængelige med ARIA. Centrale mønstre:

Tilføj role="img" til <svg>-elementet
Angiv en <title> som det første barn af <svg>, og forbind den med aria-labelledby
Tilføj en <desc> til længere beskrivelser, og forbind den med aria-describedby
Markér dekorative elementer (gitterlinjer, aksemærker) med aria-hidden="true" for at reducere støj

For interaktive diagrammer, hvor brugerne kan vælge datapunkter, skal hvert interaktivt element have en korrekt rolle, et navn og tastaturunderstøttelse.

Tastaturnavigation i interaktive diagrammer

Hvis dine diagrammer er interaktive — hover-tooltips, klikbare segmenter, markering og zoom — skal de kunne betjenes fuldt ud med tastaturet under 2.1.1 Tastatur (niveau A).

For diagrammer med mange datapunkter bør du implementere et roving tabindex-mønster: kun ét element i diagrammet er i tabulatorsekvensen ad gangen, og piletasterne flytter mellem datapunkterne inde i 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>

Tooltips, der kun vises ved hover, skal også vises ved tastaturfokus. Et tooltip, der kun er synligt for musebrugere, er en tilgængelighedsfejl.

Vælg den rigtige diagramtype

Nogle diagramtyper er i sagens natur mere tilgængelige end andre. Når du har valget:

Diagramtype	Tilgængelighed	Bemærkninger
Søjlediagram	Høj	Mængder er nemme at kode med etiketter; god tastaturunderstøttelse er mulig
Kurvediagram	Høj	Brug forskellige stregmønstre; annotér nøglepunkter
Tabel	Højest	Nemmest at gøre tilgængelig; ofte det rigtige valg til data
Punktdiagram	Middel	Kræver omhyggelig differentiering af markører; kompleks tastaturnavigation
Heatmap	Lav	Farveafhængigt af natur; lever altid et tabelalternativ
Cirkel/donut	Lav	Svært at sammenligne værdier; undgå ved mere end 3-4 segmenter

Er du i tvivl, er en velformateret tabel næsten altid mere tilgængelig end et diagram — og ofte lettere at læse uanset handicap. Brug ikke et diagram, fordi det ser moderne ud; brug det, når det reelt hjælper brugerne med at forstå en tendens eller sammenligning hurtigere, end tabeldata ville.

Test dine diagrammer

Automatiserede tilgængelighedsscannere kan tjekke for manglende alt-attributter og visse ARIA-mønstre, men de kan ikke verificere, at diagramdata er meningsfulde, at tastaturnavigationen fungerer korrekt, eller at diagrammet giver mening for en skærmlæserbruger. Test med:

En skærmlæser (NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari): navigér til diagrammet, og verificér, hvad der bliver annonceret
Kun tastatur: tab dig frem til diagrammet, og bekræft, at alle interaktive elementer kan nås og betjenes med tastaturet
Simulering af farveblindhed: brug Chrome DevTools (Rendering > Emulate vision deficiency) for at se, hvordan diagrammet fremstår ved forskellige typer nedsat farvesyn
Zoom til 200%: verificér, at etiketter og signaturforklaringer ikke overlapper eller bliver skåret af

Vores skærmlæserevaluering tester diagrammer med rigtige brugere af hjælpeteknologi — den hurtigste måde at finde ud af, hvad dine brugere faktisk oplever.