Dostępne narzędzia do wizualizacji danych w 2026 roku:
działający zestaw
Pięć bibliotek dominuje we współczesnej dyskusji o wizualizacji danych, ale tylko część z nich traktuje czytnik ekranu jako pełnoprawnego odbiorcę. To arkusz ocen dla praktykującego inżyniera — napisany dla zespołów wdrażających wykresy produkcyjnie w 2026 roku.
1. Pięć osi decydujących o dostępności wykresu
Sformułowanie „dostępny wykres“ kryje stos cicho odmiennych wymagań. Wykres słupkowy może być renderowany jako SVG z perfekcyjnym kontrastem kolorów i jednocześnie być nieosiągalny dla użytkownika klawiatury. Może obsługiwać nawigację klawiaturą i wciąż nie ogłaszać nic przydatnego czytnikowi ekranu. Może czytelnie ogłaszać wartości i mimo to zawieść widzącego użytkownika z dysfunkcją wzroku przy pierwszej etykiecie podpowiedzi. Aby rzetelnie porównać biblioteki, każdą z nich ocenia się według pięciu niezależnych osi, które bezpośrednio odpowiadają temu, jak rzeczywisty użytkownik technologii wspomagającej doświadcza wizualizacji.
Te pięć osi to nie lista osobistych preferencji. To praktyczne przełożenie kryteriów sukcesu WCAG 2.2 (1.4.11 kontrast elementów niebędących tekstem, 2.1.1 klawiatura, 4.1.2 nazwa, rola, wartość), wytycznych ARIA Authoring Practices dotyczących wykresów i grafów oraz szkicu notatki grupy W3C Research Questions Task Force „Data Visualization Accessibility“, krążącego od 2023 roku. Każda biblioteka wykresów produkuje SVG; każda renderuje jakiś rodzaj legendy; każda ma pewne podejście do kolorów. To, co je odróżnia, to domyślne ustawienia — wykres, który otrzymuje się, pisząc najmniejszą sensowną ilość kodu.
1. SVG z semantycznym ARIA. Czy biblioteka generuje SVG (nie canvas) i czy ten SVG zawiera znaczące role, etykiety i strukturę grup, a nie anonimowe zagnieżdżenia <g>?
2. Palety bezpieczne dla daltonistów domyślnie. Czy palety kategoryczne i sekwencyjne są domyślnie przetestowane pod kątem CVD, czy trzeba wiedzieć, żeby je nadpisać?
3. Nawigacja klawiaturą po punktach danych. Czy widzący użytkownik korzystający wyłącznie z klawiatury może wejść w wykres tabulatorem, przechodzić między znacznikami strzałkami i odczytać wartość każdego z nich?
4. Hierarchia opisów dla czytnika ekranu. Czy dostępny jest tytuł, jednozdaniowe podsumowanie oraz ogłoszenia dla każdej serii/punktu — a nie tylko pojedynczy zrzut tekstu alternatywnego?
5. Widok alternatywny tabeli. Czy dane bazowe są dostępne jako tabela HTML połączona z wykresem lub wyrenderowana obok niego — dla użytkowników preferujących format tabelaryczny?
„Wykres, który trafia na produkcję z perfekcyjnym kontrastem i paletą bezpieczną dla daltonistów, ale bez modelu klawiatury, jest wykresem wyrenderowanym dla połowy odbiorców.“
2. Pięć bibliotek na stole
Pięć bibliotek obejmuje zdecydowaną większość nowych prac z wykresami w 2026 roku: Vega-Lite, Plotly, Observable Plot, Apache ECharts i D3 z kodem własnym. Zajmują różne miejsca na osi abstrakcji — Vega-Lite jest najbardziej deklaratywne, D3 najbardziej imperatywne — i każde z nich prezentuje inną postawę wobec dostępności. D3 traktuje się osobno, ponieważ „D3 + własny kod“ to zasadniczo odmienna propozycja inżynierska: dostępność, jaką się otrzymuje, to dostępność, którą się napisze.
Żadna z tych bibliotek nie jest wroga dostępności. Wszystkie produkują SVG (Plotly i ECharts mogą też emitować canvas; oceniany jest tryb SVG). Wszystkie akceptują dowolne palety kolorów. Pytanie brzmi, co otrzymuje się, pisząc najmniejszą sensowną ilość kodu i ile przepiętej instalacji elektrycznej potrzeba, żeby przejść od domyślnego stanu do wykresu, który faktycznie spełnia WCAG 2.2 AA.
Ocena „zero kropek“ dla D3 nie jest krytyką biblioteki — to uczciwy opis tego, co otrzymuje się z domyślnego buildu D3. D3 to prymitywy. Dostępność wykresu D3 to cokolwiek napisze autor. Wykres D3 napisany przez inżyniera znającego ARIA może być najbardziej dostępnym wykresem na stronie; wykres D3 napisany bez tej wiedzy jest niemal zawsze najmniej dostępnym wykresem na stronie.
3. Macierz ocen: biblioteka według funkcji dostępności
Pięć osi z sekcji pierwszej ocenionych wobec pięciu bibliotek z sekcji drugiej. „Tak“ oznacza, że domyślne zachowanie spełnia daną oś; „Częściowo“ — że biblioteka udostępnia właściwe punkty zaczepienia, ale domyślnie ich nie włącza; „Ręcznie“ — że inżynier musi napisać odpowiedni kod od podstaw.
| Vega-Lite | Plotly.js | Observable Plot | Apache ECharts | D3 + własny kod | |
|---|---|---|---|---|---|
| Wyjście SVG z semantycznym ARIA | Tak (SVG, grupy z tytułem) | Tak (SVG, etykiety ARIA) | Tak (SVG, role znaczników) | Częściowo (canvas domyślnie; renderer SVG opt-in) | Ręcznie |
| Palety bezpieczne dla daltonistów domyślnie | Tak (Tableau 10 + viridis) | Częściowo (domyślna paleta Plotly; paleta CVD opt-in) | Tak (Observable categorical10) | Częściowo (domyślny schemat nieprzetestowany pod CVD) | Ręcznie |
| Nawigacja klawiaturą po punktach danych | Częściowo (fokus na legendzie; znaczniki wymagają konfiguracji) | Tak (nawigacja strzałkami w wersji 2.x) | Częściowo (plugin tip daje fokus; znaczniki ręcznie) | Częściowo (moduł a11y opt-in) | Ręcznie |
| Hierarchia opisów dla czytnika ekranu | Tak (właściwość description spec) | Częściowo (pojedynczy tytuł; per-punkt opt-in) | Tak (znaczniki ariaLabel + ariaDescription) | Częściowo (moduł a11y emituje alt per-seria) | Ręcznie |
| Alternatywny widok tabeli | Częściowo (tabela danych łatwa do wyrenderowania) | Częściowo (eksport do CSV; brak tabeli w DOM) | Częściowo (helper data(), brak automatycznej tabeli) | Częściowo (toolbox obsługuje widok danych) | Ręcznie |
Vega-Lite i Observable Plot prowadzą w zakresie deklaratywnych domyślnych ustawień. Plotly wiedzie prym we wbudowanej nawigacji klawiaturą. ECharts ma najbardziej rozbudowany moduł dostępności opt-in spośród wszystkich bibliotek na liście — ale tylko wtedy, gdy się go włączy. D3 nie daje niczego i daje wszystko: każda komórka jest oznaczona jako „ręcznie“, ponieważ biblioteka nie ma opinii. Żadna z tych bibliotek nie jest rozwiązaniem jednolinijkowym; wszystkie są wykonalne przy odpowiedniej intencji.
4. Dobry wykres, zły wykres: te same dane, dwa podejścia
Macierz pokazuje, co każda biblioteka udostępnia; ta sekcja pokazuje, co praktykujący inżynier faktycznie pisze. Te same dane, dwie implementacje. Wersja „zła“ powstaje szybko i wygląda dobrze na 27-calowym monitorze. Wersja „dobra“ wymaga 12 dodatkowych linii kodu i spełnia każdą oś macierzy.
// Vega-Lite — tylko domyślne ustawienia
{
"data": { "url": "complaints.csv" },
"mark": "bar",
"encoding": {
"x": { "field": "category", "type": "nominal" },
"y": { "field": "count", "type": "quantitative" },
"color": { "field": "category" }
}
}Renderuje się. Wygląda dobrze. Brak tytułu wykresu dla czytnika ekranu. Brak opisu. Brak modelu klawiatury na znacznikach. Domyślny schemat kolorów nieprzetestowany pod CVD przy faktycznej liczbie kategorii. Brak tabeli zastępczej.
// Vega-Lite — dostępne ustawienia domyślne
{
"title": "Complaints by surface, 2024",
"description":
"Bar chart of 4,605 web-accessibility complaints, ranked by surface. Highest: forms (1,940).",
"data": { "url": "complaints.csv" },
"mark": { "type": "bar", "ariaRoleDescription": "bar" },
"encoding": {
"x": { "field": "category", "type": "nominal",
"axis": { "labelAngle": -30 } },
"y": { "field": "count", "type": "quantitative",
"title": "Complaints" },
"color": {
"field": "category",
"scale": { "scheme": "tableau10" },
"legend": { "title": "Surface" }
},
"tooltip": [
{ "field": "category", "title": "Surface" },
{ "field": "count", "title": "Complaints" }
]
},
"usermeta": { "embedOptions": { "ariaLabel": "Complaints chart" } }
}Tytuł, opis, paleta bezpieczna dla daltonistów, nazwana oś, nazwane pola podpowiedzi, opis roli ARIA na znaczniku. W parze z <table> wyrenderowaną z tego samego zbioru danych spełnia każdą oś macierzy bez opuszczania deklaratywnej gramatyki.
Dobry wykres to nie inny wykres. To ten sam wykres z domyślnymi ustawieniami uczynionymi jawnymi, tytułem zapisanym, paletą nazwaną, rolą per-znacznik wyartykułowaną i danymi udostępnionymi również jako tabela. Na tym polega cała sztuka.
Żadna z pięciu bibliotek nie dostarcza domyślnego trybu „wyrenderuj ten wykres jako tabelę“. Działający wzorzec polega na powiązaniu tych samych danych z dwoma komponentami — wykresem i tabelą HTML <table> poniżej niego, często ukrytą wizualnie, ale dostępną dla technologii wspomagającej za pomocą przełącznika „Pokaż tabelę danych“, który odwraca atrybut hidden. Wzorzec ten kosztuje ok. 20 linii kodu frameworka na wykres i zwraca się już podczas pierwszej sesji badań z użytkownikami.
5. Konkretne wybory według przypadku użycia
Wybór biblioteki w 2026 roku dotyczy przede wszystkim dopasowania do przepływu pracy. Pięć bibliotek na stole jest wykonalnych. Pytanie brzmi, która pasuje do rodzaju wykresów, które faktycznie się wdraża. Pięć typowych przypadków użycia, pięć wyborów, z nazwaną drugą najlepszą alternatywą.
Wykresy redakcyjne / data-journalism (jeden wykres, dopracowany)
Wybór: Observable Plot, z Vega-Lite jako bliskim drugim. API Observable Plot oparte na znacznikach daje etykiety ARIA per-znacznik bezpłatnie, paleta kategoryczna jest przetestowana pod CVD, a wyjście SVG czyta się czysto. Vega-Lite jest tu drugi, ponieważ właściwość description to najczystsze jednoskładnikowe podsumowanie dla czytnika ekranu w jakiejkolwiek bibliotece — ale Plot wygrywa pod względem domyślnej ergonomii dla jednorazowych materiałów redakcyjnych.
Pulpity tworzone przez analityków (wiele wykresów, deklaratywnie)
Wybór: Vega-Lite, z Observable Plot jako bliskim drugim. Gramatyka specyfikacji Vega-Lite pozwala analitykom skomponować 30 wykresów w jednym notebooku bez pisania JavaScript, a właściwości title + description schematu dają hierarchię dla czytnika ekranu bez dodatkowego okablowania. Każdy wykres należy sparować z tabelą danych wyrenderowaną przez Vega, aby spełnić oś alternatywnej tabeli.
Pulpity naukowe / BI (interaktywna eksploracja)
Wybór: Plotly.js, z ECharts jako bliskim drugim. Plotly to jedyna biblioteka na liście, która domyślnie dostarcza nawigację strzałkami klawiatury między znacznikami w linii 2.x. Jeśli odbiorcy oczekują możliwości hover, zoomu i drążenia danych, wbudowany model klawiatury Plotly jest czynnikiem decydującym. ECharts nadgania, gdy włączy się moduł aria — ale trzeba go włączyć.
Gęste operacyjne pulpity nawigacyjne (setki punktów, krytyczna wydajność)
Wybór: Apache ECharts z renderem SVG + modułem aria włączonym, z Plotly jako bliskim drugim. ECharts ma najsilniejszą wydajność w tej grupie przy bardzo gęstych wykresach, a moduł aria produkuje tekst alt per-seria, który czytniki ekranu obsługują kompetentnie. Należy wyłączyć renderer canvas; canvas jest szybszy, ale drzewo dostępności znika.
Wykresy bespoke, których żadna biblioteka nie renderuje (własne, unikalne)
Wybór: D3 z ręcznie napisaną warstwą dostępności. Ręcznie napisana warstwa jest obowiązkowa: <title> + <desc> w głównym SVG, role=“img” per-znacznik z aria-label, model fokusa na każdym skupialnym znaczniku i siostrzana <table> wyrenderowana z tego samego zbioru danych. D3 to właściwe narzędzie, gdy wykres naprawdę nie istnieje nigdzie indziej; to złe narzędzie, gdy wykres jest wykresem słupkowym, a ktoś sięgnął po D3 z przyzwyczajenia.
Wykres wewnątrz biblioteki wykresów rzadko jest jedynym elementem na stronie. Podpowiedzi dostępne tylko przy hover, które nigdy nie pojawiają się przy fokusie; legendy będące <div> zamiast <ul>; pierścienie fokusa nadpisane w arkuszu reset strony; próbniki kolorów o niewystarczającym kontraście niebędącym tekstem wobec tła strony — to są awarie na poziomie strony, których żadna biblioteka wykresów za nas nie naprawi. Biblioteka daje znaczniki; reszta pochodzi ze strony.
Podsumowanie: działający zestaw to ten, który się zapisuje
Żadna z pięciu bibliotek na stole nie jest złą odpowiedzią. Wszystkie spełniają większość osi przy niewielkiej ilości intencji. Jedynym najbardziej wiarygodnym predyktorem dostępnego wykresu w 2026 roku nie jest biblioteka w linii importu — to fakt, czy zespół zapisał w tym samym miejscu co system projektowy, co oznacza „dostępny wykres“ w tej organizacji. Tytuł. Opis. Paleta. Model klawiatury. Alternatywna tabela. Pięć linii w CONTRIBUTING.md; różnica między wykresem, który trafia na produkcję, a wykresem, który ląduje.
Należy wybrać bibliotekę pasującą do przepływu pracy, włączyć jej domyślne ustawienia dostępności, sparować każdy wykres z tabelą danych i audytować elementy strony otaczające wykres równie starannie jak sam wykres. Domyślny wykres w każdej z tych bibliotek można uczynić dostępnym. Domyślny wykres w żadnej z tych bibliotek nie jest dostępny bez intencji.
„Biblioteka daje znaczniki; reszta pochodzi ze strony.“