+48 690 748 544
Język:

Artykuł

Historia dostępności cyfrowej: czyli jak to było, kiedy nie każdy mógł korzystać z cyfryzacji

Poznaj historię dostępności cyfrowej: od IBM Screen Reader i narodzin WWW przez WCAG, WAI-ARIA i EN 301 549 aż po European Accessibility Act.

22 września 202611 min czytania
  • Dostępność cyfrowa
  • WCAG
  • Historia internetu
  • Historia dostępności
  • Humor

Dzisiaj internet jest trochę jak prąd.

Dopóki działa, niespecjalnie się nad nim zastanawiamy. Robimy przelew, zamawiamy jedzenie, kupujemy bilet, podpisujemy umowę, umawiamy wizytę u lekarza, wypisujemy się z newslettera - choć tutaj to jeszcze różnie bywa 🙂

Ale nie zawsze tak było. A już szczególnie nie dla wszystkich.

Przez sporą część historii cyfryzacji obowiązywało bowiem niepisane założenie, że użytkownik:

  • widzi,
  • słyszy,
  • korzysta z myszki,
  • precyzyjnie trafia kursorem w element wielkości 12 pikseli,
  • rozróżnia kolory,
  • czyta drobny tekst,
  • i najlepiej jeszcze wie, że szary napis na szarym tle jest linkiem.

Jeżeli nie spełniałeś któregoś z tych wymagań? Cóż. Mogłeś sobie pograć w Sapera.

To oczywiście żart. Też nie mogłeś. Ta gra to już całkiem łamała zasady dostępności 🙂

Zanim internet nauczył się mówić

Historia digital accessibility zaczyna się jeszcze przed Webem. W latach 80. komputery stawały się coraz bardziej użyteczne, ale interfejsy nie były projektowane z myślą o wszystkich. Jeśli informacja znajdowała się na ekranie, należało ją… zobaczyć. Dość istotny szczegół, jeśli akurat nie widzisz.

W IBM nad tym problemem pracował między innymi niewidomy programista Jim Thatcher. W 1984 roku powstał IBM Screen Reader – jedno z pionierskich rozwiązań pozwalających osobom niewidomym korzystać z komputera za pomocą syntezy mowy.

I nagle komputer mógł nie tylko pokazywać informacje. Mógł je również powiedzieć. Brzmi jak oczywistość? Dzisiaj tak. Wtedy? Mała odyseja kosmiczna.

Tyle że pojawił się kolejny problem, który znamy doskonale również współcześnie: screen reader może przeczytać tylko to, co interfejs pozwala mu zrozumieć.

Jeżeli developer stworzy przycisk jako <div> z click eventem, nie doda mu odpowiedniej semantyki i uzna sprawę za zakończoną, technologia asystująca nie dostaje magicznie zdolności telepatycznych.

ARIA też nie jest telepatią. Chociaż patrząc na niektóre komponenty frontendowe, czasami właśnie tego od niej oczekujemy.

1990 – problemem nie zawsze jest użytkownik

26 lipca 1990 roku w Stanach Zjednoczonych podpisano Americans with Disabilities Act – ADA.

To jeszcze nie był akt prawny napisany pod dostępność stron internetowych. Web praktycznie dopiero miał się narodzić. Ale wydarzyło się coś ważniejszego. Zmieniało się podejście do niepełnosprawności.

Jeżeli osoba poruszająca się na wózku nie może wejść do budynku, można powiedzieć:

„Nie może wejść, bo porusza się na wózku”.

Można też spojrzeć na dokładnie tę samą sytuację i powiedzieć:

„Nie może wejść, bo zaprojektowaliśmy wejście wyłącznie ze schodami”.

Niby drobna różnica. A jednak zmienia wszystko.

Dokładnie ten sam sposób myślenia zaczęliśmy później przenosić do świata cyfrowego. Jeżeli użytkownik nie może obsłużyć formularza klawiaturą, być może problemem nie jest użytkownik. Być może problemem jest formularz. Plot twist: bardzo często jest nim formularz.

1991 – nadchodzi World Wide Web

Pierwszy serwer HTTP i pierwsza strona działały już pod koniec 1990 roku. W 1991 roku Tim Berners-Lee zaczął udostępniać Web szerzej — najpierw społeczności fizyków wysokich energii, a latem także społecznościom hipertekstu i komputerów NeXT. Tak opisuje to sam twórca w krótkiej historii World Wide Web.

Pierwszy Web był właściwie tekstem, linkami i dokumentami połączonymi ze sobą hiperłączami.

Bez autoplayujących filmów. Bez popupu z newsletterem. Bez „zaakceptuj wszystkie cookies”, który wizualnie zajmuje pół ekranu, podczas gdy „odrzuć” znajduje się gdzieś pomiędzy polityką prywatności a Narnią.

Pod wieloma względami wczesny Web był więc… całkiem dostępny. HTML posiadał semantykę. Były nagłówki, paragrafy, listy, linki.

A potem odkryliśmy, że strony mogą być ładne. I zaczęło się robić ciekawie.

Lata 90. – witamy w erze „Best viewed in…”

Kto pamięta internet lat 90., ten być może pamięta również małe plakietki:

Best viewed in Internet Explorer.

Albo:

Best viewed at 800×600.

Była to niezwykle elegancka metoda powiedzenia użytkownikowi:

„Strona działa. Tylko masz niewłaściwe narzędzia”.

Projektanci zaczęli eksperymentować z tabelami używanymi do layoutu, grafikami zawierającymi tekst, animowanymi GIF-ami, Flashem, JavaScriptem i wszystkim, co pozwalało sprawić, żeby logo się obracało.

Dlaczego logo miało się obracać? Ponieważ mogło.

Accessibility często przegrywało z najważniejszym pytaniem ówczesnego web designu: „Czy możemy zrobić ten napis jeszcze bardziej 3D?”

1997 – W3C mówi: może ustalmy jakieś zasady

Internet rósł błyskawicznie, więc problem dostępności stawał się coraz bardziej widoczny.

7 kwietnia 1997 roku World Wide Web Consortium oficjalnie uruchomiło Web Accessibility Initiative – WAI. Tim Berners-Lee podkreślał wtedy, że Web powinien być dostępny dla każdego, niezależnie od jego możliwości i niepełnosprawności.

Cel był ambitny: sprawić, aby Web był dostępny dla osób z niepełnosprawnościami. Trzeba było zacząć systematyzować wiedzę. Co z obrazkami? Co z formularzami? Co z klawiaturą? Co z osobami, które nie rozróżniają kolorów?

I przede wszystkim: jak przekonać developerów, żeby nie nazywali piętnastu elementów div1, div2, div-final i div-final-final?

1999 – pojawia się WCAG 1.0

5 maja 1999 roku opublikowano Web Content Accessibility Guidelines 1.0.

WCAG. Cztery litery, które kilkanaście lat później będą powodować u części developerów reakcję: „Czy to naprawdę konieczne?”. Tak. Ale jeszcze tam nie jesteśmy.

WCAG 1.0 zawierał 14 wytycznych i próbował uporządkować dostępność Webu.

Alternatywy tekstowe dla obrazów. Niezależność informacji od koloru. Poprawna struktura dokumentów. Czytelne tabele.

Dzisiaj wiele z tych rzeczy brzmi oczywiście. Ale przypomnijmy, że mówimy o epoce, w której całe menu strony potrafiło być jednym obrazkiem. Bez tekstu alternatywnego. Klikalnym. Powodzenia.

2000 – Flash. Dużo Flasha.

Jeśli internet przełomu wieków miał motto, mogło ono brzmieć:

„Skip intro”.

Flash pozwolił budować niesamowite jak na tamte czasy interfejsy: animacje, gry, interaktywne prezentacje, muzykę.

Bardzo dużo muzyki. Czasem uruchamiającej się automatycznie. W biurze. Przy głośnikach ustawionych na maksimum.

Dla accessibility dynamiczne, niestandardowe interfejsy były jednak poważnym wyzwaniem. Standardowe elementy HTML posiadały informacje, które technologie asystujące potrafiły interpretować. Własnoręcznie zbudowany kosmiczny przycisk obracający się wokół logo firmy już niekoniecznie.

To problem, który znamy również dzisiaj. Tylko zamiast Flasha mamy frameworki. Postęp.

1998–2001 – dostępność zaczyna być wymaganiem

W Stanach Zjednoczonych ważną rolę odegrał Section 508 Rehabilitation Act.

Po zmianach z 1998 roku federalne instytucje zaczęły otrzymywać konkretne obowiązki związane z dostępnością technologii elektronicznych i informacyjnych.

I tu nastąpiła bardzo ważna zmiana.

Accessibility zmieniło argument z:

„Fajnie byłoby to zrobić”.

na:

„Musimy to zrobić, bo prawo”.

Jak pokazuje historia technologii, drugi argument ma zadziwiającą zdolność przyspieszania backlogu.

2008 – WCAG 2.0 i cztery zasady, które przetrwały próbę czasu

11 grudnia 2008 roku opublikowano WCAG 2.0.

Internet zdążył się przez dziewięć lat kompletnie zmienić, więc potrzebne było podejście mniej zależne od konkretnych technologii.

Pojawiły się cztery fundamentalne zasady znane jako POUR.

Treść musi być:

Perceivable – Postrzegalna

Jeżeli jedyną informacją o błędzie jest czerwony kolor pola, użytkownik nierozróżniający kolorów może mieć problem.

Operable – Funkcjonalna

Jeżeli wszystko działa myszką, ale nic klawiaturą, interfejs nie jest dostępny.

Understandable – Zrozumiała

Jeżeli komunikat błędu brzmi „Error 0x00239”, być może nawet osoba bez niepełnosprawności nie wie, co właśnie zrobiła źle.

Robust – Kompatybilna

Jeżeli interfejs działa tylko w jednej przeglądarce, na jednym urządzeniu i najlepiej podczas pełni księżyca, to jest to problem.

POUR okazało się wyjątkowo trwałym fundamentem.

Bo technologia się zmienia.

Ludzie trochę wolniej.

2014 – ARIA przybywa na ratunek

Web przestał być zbiorem dokumentów.

Stał się platformą aplikacyjną.

Zaczęliśmy tworzyć dropdowny, slidery, taby, drzewa, comboboksy, modale i komponenty, których twórcy pierwszego HTML prawdopodobnie nawet nie przewidywali.

20 marca 2014 roku WAI-ARIA 1.0 uzyskało status rekomendacji W3C.

ARIA pozwala przekazać technologiom asystującym informacje typu:

„To jest przycisk”.

„To menu jest rozwinięte”.

„Ten element jest zaznaczony”.

„Tutaj pojawił się komunikat”.

Problem?

Developerzy szybko odkryli ARIA.

A potem zaczęli dodawać ją wszędzie.

Dlatego jedna z najbardziej znanych zasad brzmi mniej więcej:

jeśli możesz użyć natywnego elementu HTML, użyj go.

Bo <button> będzie się zachowywał jak button.

A <div role="button">? To trochę jak człowiek z kartką „CZARODZIEJ” na czole w grze w Czółko.

W grze jest czarodziejem, ale w rzeczywistości przecież nie zna czarów 🙂

2014 – Europa też zaczyna standaryzować dostępność

W tym samym roku pojawiła się pierwsza wersja europejskiej normy EN 301 549 dotyczącej dostępności produktów i usług ICT.

To ważny etap, bo digital accessibility coraz wyraźniej wychodziło poza samą stronę WWW.

Komputery. Dokumenty. Oprogramowanie. Urządzenia. Usługi cyfrowe.

Cyfryzacja obejmowała coraz większą część życia.

A to oznaczało, że niedostępna technologia mogła już nie tylko utrudnić przeczytanie artykułu.

Mogła uniemożliwić wykonanie przelewu, złożenie dokumentu albo skorzystanie z usługi publicznej.

I tutaj żarty się kończą.

2018 – WCAG odkrywa, że mamy telefony

W 2008 roku iPhone miał około roku.

Dziesięć lat później smartfon był już jednym z podstawowych sposobów korzystania z internetu.

WCAG potrzebował aktualizacji.

5 czerwca 2018 roku opublikowano WCAG 2.1, dodając 17 nowych kryteriów sukcesu.

Więcej uwagi poświęcono między innymi urządzeniom mobilnym, osobom słabowidzącym oraz użytkownikom z niepełnosprawnościami ruchowymi i poznawczymi.

Bo nagle okazało się, że element interfejsu o wymiarach 8×8 pikseli może być trudny do trafienia palcem.

Szok.

Pamiętam pierwsze Hamburger menu w telefonach… Nawet nie wiem, jak to skomentować 🙂

2019–2025 – European Accessibility Act

W 2019 roku Unia Europejska przyjęła European Accessibility Act – EAA.

A od 28 czerwca 2025 roku wymagania wynikające z implementacji dyrektywy zaczęły mieć zastosowanie do szeregu objętych nią produktów i usług.

Między innymi e-commerce, wybranych usług bankowych, e-booków, terminali płatniczych czy części usług transportowych.

Accessibility weszło więc do świata biznesu drzwiami z napisem:

COMPLIANCE.

A wiadomo, że jeśli nie udało się przekonać firmy argumentem:

„Dzięki temu więcej ludzi będzie mogło korzystać z produktu”,

Zawsze można spróbować:

„Dział prawny chciałby z wami porozmawiać”.

2023 – WCAG 2.2

5 października 2023 roku opublikowano WCAG 2.2.

Doszło dziewięć nowych kryteriów sukcesu dotyczących między innymi fokusu, przeciągania elementów, minimalnego rozmiaru targetów czy dostępnego uwierzytelniania.

Czyli na przykład logowania.

Bo jeżeli użytkownik musi:

  1. zapamiętać hasło składające się z 14 znaków,
  2. jednej wielkiej litery,
  3. hieroglifu,
  4. symbolu waluty nieistniejącego państwa,
  5. a następnie przepisać kod, którego nie może skopiować,

to być może stworzyliśmy nie tyle bezpieczny system logowania, co escape room.

Digital Accessibility – timeline

  • 1984 → IBM Screen Reader – komputer zaczyna mówić do użytkownika.
  • 1990 → Americans with Disabilities Act. Coraz mocniej przebija się idea, że barierą może być środowisko, a nie człowiek.
  • 1991 → startuje World Wide Web. Na razie głównie tekst i linki. Jest dobrze.
  • Lata 90. → tabele do layoutu, tekst w obrazkach, migające GIF-y i „Best viewed in Internet Explorer”. Jest trochę gorzej.
  • 1997 → W3C uruchamia Web Accessibility Initiative.
  • 1997 → HTML dostaje <label>. My przez następne trzy dekady zastanawiamy się, czy naprawdę trzeba go używać.
  • 1998 → Section 508 wzmacnia wymagania dotyczące dostępności technologii federalnych w USA.
  • 1999 → WCAG 1.0. Internet dostaje pierwszą dużą instrukcję: „jak nie wykluczać ludzi”.
  • Początek lat 2000. → Flash. Intro. Muzyka. Animacja. Skip intro. Dużo się dzieje.
  • 2008 → WCAG 2.0 i cztery zasady POUR.
  • 2014 → WAI-ARIA 1.0. <div> może udawać button. Nie oznacza to jeszcze, że powinien.
  • 2014 → pierwsza wersja EN 301 549.
  • 2018 → WCAG 2.1. Mobile oficjalnie wchodzi do accessibility na poważnie.
  • 2019 → European Accessibility Act.
  • 2023 → WCAG 2.2.
  • 28 czerwca 2025 → wymagania wynikające z EAA zaczynają mieć zastosowanie do objętych regulacją produktów i usług.

I co z tego wszystkiego wynika?

Historia accessibility jest trochę historią naprawiania problemów, które sami wcześniej stworzyliśmy.

HTML dał nam nagłówki.

Więc zrobiliśmy nagłówki z <div>.

HTML dał nam button.

Więc zrobiliśmy button z <span>.

Przeglądarka pozwoliła powiększać tekst.

Więc ustawiliśmy kontener na sztywne 600 pikseli wysokości i overflow: hidden.

Dostaliśmy możliwość ustawienia dowolnego koloru.

Więc oczywiście wybraliśmy #aaa na #fff.

A potem powstała cała dziedzina wiedzy zajmująca się tłumaczeniem, dlaczego to może być problem. Ale accessibility dojrzewało razem z internetem.

Najpierw było traktowane jako specjalne rozwiązanie dla specjalnej grupy użytkowników. Później jako dobra praktyka. Następnie jako standard. Potem również jako wymaganie prawne. A dzisiaj coraz częściej traktujemy je po prostu jako element dobrze zaprojektowanego produktu.

Bo dostępny przycisk nadal jest przyciskiem. Dostępny formularz nadal jest formularzem. Dostępny sklep nadal jest sklepem. Tylko może z niego skorzystać więcej osób.

I być może właśnie to jest najważniejsza lekcja z ponad 40 lat historii digital accessibility:

Użytkownik nie powinien musieć dostosowywać się do naszych interfejsów. To nasze interfejsy powinny być projektowane dla wszystkich. Także tych, którzy nie widzą, nie słyszą, nie używają myszki, nie rozróżniają kolorów, mają drżenie rąk albo potrzebują więcej czasu.

Albo po prostu próbują kupić bilet jedną ręką w zatłoczonym autobusie, ze słońcem świecącym prosto w ekran.

Bo accessibility ostatecznie nie jest historią o WCAG. Jest historią o tym, że po drugiej stronie interfejsu siedzi człowiek. A czasami siedzi przed niedostępną aplikacją i reaguje dokładnie tak samo jak my wszyscy 🙂

Osobiste podsumowanie

Naprawdę miło było mi odbyć tę podróż do przeszłości, zrobić research i zebrać wszystkie te informacje. Wiele rzeczy udało mi się dzięki temu lepiej zrozumieć, a przy okazji wróciły wspomnienia sprzed lat. Mam nadzieję, że Wam również podobała się ta podróż.

Oficjalne źródła

FAQ

Kiedy zaczęła się historia dostępności cyfrowej?

Jej początki sięgają czasu sprzed powstania WWW. Jednym z przełomów był IBM Screen Reader z 1984 roku, rozwijany między innymi przez niewidomego programistę Jima Thatchera. Pozwalał osobom niewidomym odbierać informacje z komputera za pomocą syntezy mowy.

Kiedy opublikowano pierwsze wytyczne WCAG?

WCAG 1.0 opublikowano 5 maja 1999 roku jako rekomendację W3C. Dokument zawierał 14 wytycznych dotyczących między innymi alternatyw tekstowych, struktury dokumentu, koloru i tabel.

Czym różnią się WCAG 2.0, 2.1 i 2.2?

WCAG 2.0 wprowadziły cztery zasady POUR. WCAG 2.1 dodały 17 kryteriów, zwłaszcza dla urządzeń mobilnych oraz osób słabowidzących i z ograniczeniami ruchowymi. WCAG 2.2 dodały 9 kryteriów dotyczących między innymi fokusu, przeciągania, wielkości celu i dostępnego uwierzytelniania.

Co oznacza skrót POUR w dostępności cyfrowej?

POUR opisuje cztery zasady WCAG: postrzegalność, funkcjonalność, zrozumiałość i kompatybilność. Treść oraz interfejs powinny być możliwe do odebrania, obsługi i zrozumienia, a także współpracować z różnymi technologiami, w tym asystującymi.

Czy WAI-ARIA zastępuje semantyczny HTML?

Nie. WAI-ARIA uzupełnia semantykę złożonych komponentów, ale natywny HTML powinien być pierwszym wyborem. Element button ma zachowanie klawiaturowe i semantykę wbudowane w przeglądarkę, a div z role=button wymaga ich samodzielnego odtworzenia.

Dlaczego historia dostępności cyfrowej jest ważna dzisiaj?

Pokazuje, że bariery zwykle powstają w sposobie projektowania, a nie po stronie użytkownika. Dostępność jest dziś jednocześnie standardem jakości, elementem dobrego UX i — dla części produktów oraz usług — wymaganiem prawnym.