Aktualności

Aktywne projekty

Ostatnia aktualizacja: 31 października 2026 r.

W trakcie realizacji

v3: Kompletny pakiet do zapewniania jakości

27 września 2026 r.

Premiera na DrupalCon Europe 2026

Najważniejsze nowe funkcje

• Połączenie rdzenia testów z Sa11y. Nowy, wspólnie rozwijany zestaw reguł uzupełnia podstawowy zestaw testów treści o testy dla programistów, sprawdzanie kontrastu i ocenę czytelności.
• Obsługa wielu języków
• Kreator reguł niestandardowych
• Narzędzia do konserwacji panelu
• Narzędzie do przeszukiwania witryny, które dodaje nowe wyniki.
• W przypadku wybranych testów (czy ten plik PDF jest dostępny?) pozwala określonym rolom odrzucać alerty w całej witrynie.
• Podzielona konfiguracja: oddzielne testy i widoki raportów dla programistów i twórców treści, oparte na rolach.

A co być może najważniejsze dla przyszłości projektu:

• Uzyskanie grantu na uruchomienie tej organizacji sponsorującej, aby wspierać obecnych użytkowników i finansować prace nad przyszłymi pomysłami na projekt.

v2: Odrzucenia i raporty

2 marca 2023 r.

Dwa lata temu przedstawiliśmy narzędzie do sprawdzania dostępności Editoria11y jako gotową do użycia wtyczkę dla Drupal, która miała dawać autorom automatyczne, natychmiastowe informacje zwrotne z pomocnymi wskazówkami, jak ulepszyć treści.

Uznaliśmy, że odpowie to na niezaspokojoną potrzebę. Wszystkie dostępne rozwiązania wymagały szkoleń i sumiennego stosowania, by przynieść pożytek, a doświadczenie pokazało nam, że próba szkolenia i nadzorowania tysięcy autorów treści w dużej organizacji nie jest skutecznym sposobem radzenia sobie z tym problemem. Byliśmy przekonani, że aby program odniósł sukces, musi być w wysokim stopniu zautomatyzowany i po wykryciu typowych błędów oferować autorom treści uprzejme „szkolenie w odpowiednim momencie”.

Zadziałało.

W Princeton w dużej mierze odwróciło to kierunek mojej komunikacji. Na platformach, na których je zainstalowano, przeszliśmy od wysyłania autorom treści powtarzalnych e-maili z prośbą o teksty alternatywne i poprawę linków lub nagłówków do otrzymywania od nich pytań o to, jak ulepszyć swoje teksty, by nie były tak często oznaczane.

Poza uczelnią reakcją była euforia:

Pisanie samodzielnych podpowiedzi

W podpowiedziach v1 przyjęliśmy podejście „podsumowanie i szczegóły”: krótkie wyjaśnienie problemu oraz link do szczegółów.

Było to lepsze rozwiązanie niż narzędzia pisane dla programistów: podpowiedzi były krótkie i jasne. Problemem pozostawała jednak decyzja, dokąd linkować. Kilku użytkowników z administracji publicznej i szkolnictwa wyższego uznało za konieczne zmodyfikowanie podpowiedzi, by usunąć linki do dokumentacji Princeton, co przysparzało im dodatkowej pracy. Przepisaliśmy więc domyślne podpowiedzi tak, by były samodzielne i zawierały przykłady bezpośrednio w tekście.

Rozróżnienie między czerwonymi alertami (niewątpliwe problemy) a żółtymi ostrzeżeniami (możliwe problemy) okazało się mylące, a chwilami irytujące.

Zamieniliśmy więc żółte ostrzeżenia na „ręczne sprawdzenia”, by wyjaśnić ich znaczenie, i dodaliśmy przyciski pozwalające autorom odrzucać alerty. Alerty „zignorowane” są ukryte tylko dla osoby, która kliknęła przycisk; alerty „oznaczone jako OK” są ukryte dla wszystkich redaktorów witryny. Administratorzy witryny mogą decydować, kto ma uprawnienia do każdej z tych czynności.

Tworzenie panelu

Właściciele witryn często narzekali, że narzędzie świetnie znajduje problemy w całej witrynie, ale nie można wyświetlić raportu obejmującego całą witrynę.

Nowa wersja dodaje opcję synchronizowania wyników z bazą danych witryny. Właściciele witryn mogą teraz przeglądać wyniki według stron lub problemów oraz sprawdzać, które problemy zostały zignorowane lub oznaczone jako OK – i przywrócić problem, jeśli się z tym nie zgadzają!

Przegląd kodu v2 dla programistów

V2 to niemal całkowicie przepisany kod. Oto niektóre z nowych funkcji:

• Usunięcie zależności od jQuery pozwala instalować narzędzie na większej liczbie platform i zapewnia dwukrotny wzrost wydajności.
• Narzędzie można teraz skonfigurować tak, by sprawdzało wiele niezależnych części strony (np. treść artykułu i stopkę strony).
• Narzędzie może teraz testować elementy wewnątrz shadow DOM, z którego korzystają różne komponenty sieciowe i biblioteki JavaScript.
• Wiele nowych parametrów ułatwia integrację z platformami, np. automatyczne ignorowanie wszystkich problemów na określonych stronach dla określonych użytkowników, którzy nie odpowiadają za treść tych stron, ale mogą chcieć przeglądać wyniki na żądanie.
• Narzędzie zawiera teraz kilka motywów bazowych oraz parametry do dostosowywania kolorów.
• Testy automatyczne pomagają zapobiegać regresjom w kodzie.

A11yTalks 2024

11 czerwca 2024 r.

Drupal GovCon 2023

27 października 2023 r.

DrupalCamp NJ 2023

28 marca 2023 r.

v1: Pomoc śródtekstowa

11 marca 2021 r.

Tworzenie wysoce dostępnych treści internetowych jest skomplikowane i zwykle zaczyna się od wielu szkoleń.

Trzeba zniechęcać do znanych praktyk:

• Tabele nie powinny służyć do tworzenia pozornych kolumn
• Tekst ciągły nie powinien być wyśrodkowany ani wyjustowany
• Nie należy polegać na formatowaniu wyłącznie wizualnym (grubość i rozmiar czcionki) jako nośniku znaczenia dla użytkowników, którzy mogą słuchać treści lub przeglądać ją w „trybie czytania”

Trzeba zachęcać do nowych praktyk:

• Obrazy wymagają tekstu alternatywnego, który ma sens w danym kontekście
• Strony potrzebują prawdziwej struktury
• Linki powinny mieć zrozumiałe nazwy

Z pewnością część naszych szkoleń wynika z tego, że uczymy nowych pojęć, ale w pewnym momencie trzeba zadać pytanie: w jakim stopniu potrzeba nowych umiejętności bierze się z nowości tych pojęć, a w jakim z tego, że wprowadzamy nowe oczekiwania, nie aktualizując naszych narzędzi? To, że coś jest nowe, nie znaczy, że nie może być intuicyjne.

Lekcje z historii ortografii

Faza 1: Wina autora

Od zarania dziejów pisanych aż do początku lat 80. XX wieku za błąd ortograficzny winiliśmy autora. To na autorze spoczywał obowiązek nauczenia się poprawnej pisowni.

Jak można było poprawić swoją ortografię? Zabrzmi to znajomo:

1. Uczęszczano na szkolenia, u korepetytorów lub w klasie
2. Otrzymywano do przestudiowania listy, wytyczne i słowniki, których historia sięga starożytnych leksykonów klinowych wyrytych w glinie.

Faza 2: Wina słownika

Jednak w latach 80. coś się zmieniło: nazwijmy to „fazą 2 ortografii”. Najpopularniejsze edytory tekstu wprowadziły sprawdzanie pisowni.

A co się stało z szukaniem winnych? Niemal z dnia na dzień wina przeszła na narzędzie:

• Nie wiesz, jak napisać słowo? Zgadnij i miej nadzieję, że znajdzie się dopasowanie. Jeśli się nie znajdzie, winny jest słownik.
• Używasz prawdziwego słowa, które słownik oznacza, bo go nie zna? Ponarzekaj i zdecyduj, czy zignorować podkreślenie, czy kliknąć prawym przyciskiem i dodać słowo do słownika.

Czy sprawdzanie pisowni naprawiło całą naszą ortografię? Z pewnością nie. Ale pomogło. I przeniosło znaczną część ciężaru i odpowiedzialności z autora na maszynę.

To jednak nie był koniec…

Faza 3: Wina narzędzia do tworzenia treści

Ostatnie lata przyniosły kolejny krok naprzód: komputery zaczęły pisać za nas:

• Algorytmy predykcyjne próbują odgadnąć następne słowo, następną frazę, a może nawet całą odpowiedź na SMS-a.
• Narzędzia do automatycznego formatowania próbują zamieniać gwiazdki, cyfry i litery na listy, a skróty na znaki specjalne i emoji itd.
• Narzędzia do dyktowania próbują rozpoznawać znaczenie wypowiedzi, by wybierać między homonimami.

A kogo się wini, gdy to zawodzi? Narzędzie!

Agregatory mediów społecznościowych uwielbiają kompromitujące zrzuty ekranu w stylu „Nie o to mi chodziło!”.

Editoria11y to krok w stronę fazy 2

Na naszych szkoleniach dużo mówimy o testowaniu i przedstawiamy kilka całkiem dobrych narzędzi testowych. Żadne z nich nie wychwyci wszystkiego: kwestie takie jak „unikanie objaśniania pojęć za pomocą odniesień do koloru lub położenia” musi sprawdzić człowiek; narzędzia wychwytują zwykle niespełna połowę rzeczywistych problemów, jakie może mieć witryna. Bardzo dobrze radzą sobie jednak z wychwytywaniem wielu typowych błędów w treściach redakcyjnych.

Są jednak trzy problemy:

1. Większość to narzędzia ręczne. Twórca treści musi zostać nauczony korzystania z nich, musi pamiętać o ich istnieniu podczas pisania i musi pamiętać, by uruchomić je po skończeniu pracy. Te trzy punkty awarii sprawiają, że znaczna część (większość?) treści pozostaje niesprawdzona.
2. Oznaczają zbyt wiele. Wskazują nie tylko błędy popełnione właśnie przez autora, ale też problemy z kolorami zawinione przez projektanta, problemy techniczne zawinione przez programistę, elementy strukturalne do celów informacyjnych itd. To podnosi poprzeczkę dla szkoleń: autorzy muszą nie tylko rozumieć narzędzie, ale też nauczyć się ignorować całą listę fałszywych alarmów lub jak najbardziej realnych problemów, których naprawa nie należy do nich dzisiaj, gdy piszą akurat ten artykuł.
3. Narzędzia automatyczne działają zwykle według schematu: przeszukaj witrynę, zajrzyj do panelu. Znów zakłada to, że autor został przeszkolony, by odwiedzać panel, i będzie o tym pamiętał.

Uniwersytet Princeton postanowił więc stworzyć coś nowego: zintegrowane z witryną, automatyczne narzędzie sprawdzające, które zajmowałoby się wyłącznie typowymi błędami redakcyjnymi.

Automatyzacja to… trudna sprawa.

1. Automatyczne narzędzia muszą być subtelne: jeśli są zbyt natarczywe, przerywają autorowi pracę i go frustrują. Jeśli są zbyt uprzejme, łatwo stają się ignorowanym szumem w tle.
2. Automatyczne narzędzia muszą być bardzo wydajne: jeśli strona drga lub się zacina podczas ich działania, autorzy zaczną ich nie znosić i je wyłączą.
3. Automatyczne narzędzia potrzebują podpowiedzi przyjaznych dla początkujących. Wielu autorów po raz pierwszy usłyszy o znacznikach, strukturze i języku, dzięki którym ich treści staną się bardziej dostępne. Alerty muszą być napisane prostym, nietechnicznym językiem i zawierać praktyczne wskazówki, jak poprawić treść.

Zaczęliśmy więc od narzędzia najbliższego tym celom, jakie udało nam się znaleźć: Sa11y z Toronto Metropolitan University. Przejęliśmy jego architekturę testów i przyjazne dla użytkownika podejście z panelem informacyjnym i podpowiedziami, a następnie przez pół roku dostosowywaliśmy narzędzie tak, by testy zawsze uruchamiały się automatycznie, optymalizowaliśmy jego wydajność, dopracowywaliśmy podpowiedzi i tworzyliśmy długą listę opcji konfiguracyjnych, dzięki którym programista mógł szybko dostosować je do dowolnej platformy.

Tak to wygląda dzisiaj:

Gdy autor jest zalogowany w swojej witrynie, przełącznik Editoria11y wskazuje liczbę i rodzaj problemów na każdej stronie (brak problemów, wymagane ręczne sprawdzenia, wykryte prawdopodobne problemy). Kliknięcie odsłania wyróżnienia i podpowiedzi bezpośrednio w treści. Jeśli błąd jest nowy, bo autor ogląda właśnie edytowaną stronę, panel otwiera się automatycznie.

Od marca 2021 r. oznacza to, że ponad 400 witryn Princeton automatycznie sprawdza następujące kwestie:

• Dobry konspekt dokumentu
  • Pominięte poziomy nagłówków
  • Puste nagłówki
  • Bardzo długie nagłówki
  • Podejrzanie krótkie cytaty blokowe, które w rzeczywistości mogą być nagłówkami.
• Alternatywy tekstowe
  • Obrazy bez tekstu alternatywnego
  • Obrazy z nazwą pliku jako tekstem alternatywnym
  • Obrazy z bardzo długim tekstem alternatywnym
  • Tekst alternatywny zawierający zbędne sformułowania, takie jak „obraz przedstawiający” lub „zdjęcie przedstawiające”
  • Obrazy w linkach z tekstem alternatywnym, który wydaje się opisywać obraz zamiast celu linku
  • Osadzone wizualizacje, które zazwyczaj wymagają alternatywy tekstowej
• Zrozumiałe linki
  • Linki bez tekstu
  • Linki z nazwą pliku jako tekstem
  • Linki zatytułowane wyłącznie ogólnym tekstem: „kliknij tutaj”, „dowiedz się więcej”, „pobierz” itp.
  • Linki otwierane w nowym oknie bez ikony linku zewnętrznego
• Ogólne zapewnianie jakości
  • Sprawdzanie, czy używane jest formatowanie list, a nie gwiazdki, cyfry i litery
  • DUŻE ILOŚCI TEKSTU Z WŁĄCZONYM CAPS LOCKIEM
  • Tabele bez nagłówków oraz tabele z nagłówkami dokumentu („Nagłówek 3”) zamiast nagłówków tabeli (<th>)
  • Linki do plików PDF i innych dokumentów z przypomnieniem, by sprawdzić dostępność pobieranego pliku lub udostępnić alternatywny, dostępny format
  • Osadzone filmy z przypomnieniem o dodaniu napisów
  • Osadzone nagrania audio z przypomnieniem o udostępnieniu transkrypcji
  • Osadzone treści z mediów społecznościowych z przypomnieniem o dodaniu elementów alt

Udostępniliśmy społeczności bibliotekę JavaScript, stworzyliśmy gotową do użycia integrację z Drupal i rozpoczęliśmy prace nad gotową do użycia integracją z WordPress.

W stronę fazy 3: Dostępność domyślnie

Pod wieloma względami Editoria11y jest rozwiązaniem tymczasowym. Większość wychwytywanych przez nie błędów wynika z tego, że postawiliśmy autorom treści nowe wymagania („oznaczaj treść za pomocą dobrej struktury”), ale daliśmy im narzędzia zachęcające do czegoś przeciwnego.

Droga naprzód polega na tym, by tworzenie dostępnych treści było łatwiejsze i jak najbardziej automatyczne. Jak to będzie wyglądać, jeszcze nie wiadomo, ale prawdopodobnie obejmie to między innymi:

• Ponowne przemyślenie, jakie opcje są dostępne. Na przykład: jeśli wciąż powtarzamy użytkownikom, by nie justowali tekstu w internecie, to może czas pozbyć się przycisku „wyjustuj tekst”?
• Ponowne przemyślenie opcji domyślnych. Na przykład: domyślna tabela w większości systemów zarządzania treścią nie ma nagłówków. To użytkownik musi wiedzieć, że trzeba kliknąć „właściwości” i dodać funkcje dostępności; może czas to odwrócić?
• Rozważenie formatowania predykcyjnego i „podpowiedzi w trakcie pracy”. Jeśli użytkownik pogrubi cały wiersz, czy możemy zasugerować, by zrobił z niego nagłówek? Jeśli użytkownik zamierza wybrać nagłówek, czy możemy odgadnąć, jakiego poziomu potrzebuje, zamiast dawać mu sześć opcji? Czy możemy zapewnić szkolenie w odpowiednim momencie w przypadku trudnych pojęć?