Dostępnik o zaufaniu do AI
Jako zagorzały fan sztucznej inteligencji mogę Ci powiedzieć wprost - nie ufaj! AI to taki uczynny doradca mówiący z wielkim przekonaniem zarówno prawdę, półprawdę, jak i całe kłamstwo.
Ostatnią prezentację podczas AutomaticA11y 2025 miała Paulina Wysakowska. Opisywała nam, co się może zdarzyć, jeżeli o dostępności chcesz się dowiedzieć od Chata GPT. Zmęczenie zamgliło mi mózg i nie uchwyciłem wtedy kontekstu i mam nadzieję, że mało kto to zauważył. Jednak ta prezentacja zmotywowała mnie do przeprowadzenia pewnego eksperymentu.
Eksperyment był prosty: zadać kilku modelom językowym to samo pytanie na temat cyfrowej dostępności, a potem porównać. Troszkę kodowania, pobranie kluczy API, walka z autoryzacją Gemini i poszło. Eksperyment jest tak świerzy, że użyłem najnowszego modelu OpenAI GPT OSS, który jest na otwartej licencji.
Przebieg eksperymentu
Każdy model miał dostać ten sam prompt systemowy i ten sam kawałek kodu. Reszta leciała na ustawieniach domyślnych, bo nie wiedziałem, jak ustawić choćby temperaturę. Za niska nie da pokombinować, a za wysoka może uwolnić nadmierną fantazję.
Prompt systemowy
Nie jest zbyt wyszukany, bo i taki miał być. Takie powszechnie znane reguły z rolą, zadaniem i formatem wyjściowym. A brzmiał tak:
Jesteś doświadczonym programistą webowym, znającym standardy dostępności w tym WCAG oraz specyfikacje HTML, WAI-ARIA. Otrzymujesz fragment kodu i oceniasz, czy jest poprawny z punktu widzenia cyfrowej dostępności. Odpowiadaj krótko i dodaj uzasadnienie.
Fragment kodu
Postanowiłem sprawdzić kawałek kodu, który ostatnio spotykam często i okropnie mnie wkurza. Wiąże się nawet z poprzednim Dostępnikiem, bo dotyczy ARIA i bezmyślnego stosowania. Jak się domyślasz - kod jest błędny, ale dlaczego? Możesz się nad tym zastanowić, zanim przejdziesz dalej. Oto kod:
<a href="/kontakt/" aria-label="Kliknij aby przejść do podstrony Kontakt">Kontakt</a>
Przyznasz, że bardzo krótki. Nie jest to bardzo łatwe zadanie, ale jednocześnie zupełnie oczywiste, jeżeli znasz odpowiedź.
Technologie
Dla swojej własnej wygody użyłem biblioteki Langchain i jej rozszerzeń. To pozwoliło mi ominąć konieczność rozkminiania poszczególnych bibliotek i API. Drugim ułatwieniem była biblioteka Ollama, która dostarczyła mi interfejsu do modeli lokalnych. Jeszcze ustawienie zmiennych środowiskowych i można jechać. Chociaż nie było to potrzebne, do dodałem do tego interfejs w Streamlit.
Do eksperymentu wybrałem po 2 zamknięte modele od OpenAI i Google. Poza tym kilka modeli lokalnych, w tym także te od OpenAI, Google, Bielik, Microsoft i chiński Qwen. Zresztą pełna lista będzie dalej.
Z tym wyborem miałem trochę dylematów, bo model modelowi nie jest równy. Potężny Gemini 2.5 Pro ma się nijak do modelilokalnych, z których największy ma 20 miliardów parametrów. No ale co zrobić?.. Nie odpalę na moim sprzęcie choćby modeli 70B, nie mówiąc już o większych. Zrobiłem jednak co się dało, żeby wyniki można było jakoś porównać.
Wyniki eksperymentu
Poniżej znajdziesz nazwę modelu i jego odpowiedź na zadane pytanie. 1 z modeli jest rozumujący, więc zostawiam ślady łańcucha dla ciekawości. No to jedziemy.
OpenAI: gpt-4
Tak, jest poprawny pod względem cyfrowej dostępności. Używa atrybutu 'aria-label', który upraszcza zrozumienie funkcji danego linku, szczególnie dla osób korzystających z technologii asystujących, takich jak czytniki ekranowe. Tekst, który jest widoczny, również wyraźnie komunikuje przeznaczenie linku.
OpenAI: gpt-4o
Kod jest poprawny z punktu widzenia dostępności, ale można go uprościć. Treść wewnątrz znacznika `<a>` ("Kontakt") wystarczająco opisuje cel linku, więc `aria-label` jest zbędny. Nadmiarowa etykieta nie jest konieczna i może powodować, że technologia asystująca przeczyta dwa razy to samo. Oto jak można poprawić ten kod:
<a href="/kontakt/">Kontakt</a>
Taka wersja jest bardziej zgodna z najlepszymi praktykami dostępności, zapewniając tym samym, że każdy użytkownik otrzyma jasne informacje o celu linku bez zbędnej redundancji.
Google: gemini-2.5-pro
Nie, ten kod nie jest poprawny z punktu widzenia dostępności.
Uzasadnienie:
Redundancja i "hałas informacyjny": Atrybut `aria-label` nadpisuje widoczną treść linku ("Kontakt"). Czytnik ekranu ogłosi "Kliknij aby przejść do podstrony Kontakt, link", zamiast prostego i wystarczającego "Kontakt, link". Słowa "Kliknij aby" są zbędne, ponieważ czytnik ekranu sam informuje użytkownika o typie elementu (że jest to link, na który można kliknąć).
Naruszenie WCAG 2.5.3 (Label in Name): To kryterium sukcesu wymaga, aby widoczna etykieta tekstowa była częścią dostępnej nazwy. Tutaj widoczna etykieta to "Kontakt", a dostępna nazwa to "Kliknij aby przejść do podstrony Kontakt". Może to powodować problemy dla użytkowników sterujących interfejsem za pomocą głosu, którzy powiedzą "Kliknij Kontakt", a oprogramowanie może nie znaleźć dopasowania.
Złamanie pierwszej zasady ARIA: "Nie używaj ARIA, jeśli możesz użyć natywnego HTML". W tym przypadku natywny HTML (`<a>Kontakt</a>`) jest w pełni wystarczający i semantyczny. Użycie `aria-label` jest niepotrzebne i szkodliwe.
Poprawny kod:
<a href="/kontakt/">Kontakt</a>
Google: gemini-2.0-flash
Kod jest poprawny, ale można go ulepszyć.
Uzasadnienie:
Użycie `aria-label`: Atrybut `aria-label` jest używany, co jest dobre, ponieważ dostarcza alternatywny tekst dla linku. Jest to szczególnie przydatne, gdy sam tekst linku ("Kontakt") może nie być wystarczająco opisowy dla użytkowników technologiigii wspomagających.
Redundancja: Tekst w `aria-label` powtarza informację zawartą w tekście linku ("Kontakt"). Lepszym rozwiązaniem byłoby usunięcie `aria-label` i poleganie na tekście linku, chyba że potrzebny jest dodatkowy kontekst.
Najlepsza praktyka: Jeśli tekst linku jest wystarczająco opisowy, nie ma potrzeby dodawania `aria-label'
Propozycja ulepszenia:
<a href="/kontakt/">Kontakt</a>
lub, jeśli potrzebny jest dodatkowy kontekst:
<a href="/kontakt/" aria-label="Skontaktuj się z nami">Kontakt</a>
gemma3n:e2b
Ocena: Dobra.
Uzasadnienie:
`aria-label`: Użycie `aria-label` jest dobre, ponieważ dostarcza opis dla czytnika ekranu, gdy użytkownik nie widzi lub nie może zobaczyć tekstu "Kontakt". Pomaga w zrozumieniu funkcji linku.
Czytelność: Tekst "Kontakt" jest czytelny i zrozumiały.
Dostępność: Link jest dostępny dla osób z niepełnosprawnościami wzrokowymi.
Sugestie (opcjonalne):
Rozważ użycie bardziej opisowego `aria-label`, jeśli link prowadzi do konkretnej sekcji na stronie kontaktowej (np. "Skontaktuj się z nami").
Upewnij się, że link jest wizualnie odróżniony od tekstu w treści strony, aby był łatwo zauważalny.
phi4:14b
Fragment kodu jest poprawny z punktu widzenia dostępności, ale może być możliwe ulepszenie dla bardziej spójnej obsługi:
<a href="/kontakt/" aria-label="Przejdź do strony Kontakt">Kontakt</a>
Uzasadnienie:
`aria-label`: Jest użyteczne, jeśli chcesz dostarczyć bardziej szczegółowe lub alternatywne informacje niż tekst w elemencie linku. Jednakże, zazwyczaj `aria-label` powinno być używane tylko wtedy, gdy nie ma wystarczającego tekstu opisowego w elemencie samej siebie. W tym przypadku, "Kontakt" wydaje się działać dobrze jako tekst oznaczony dla linku.
Spójność i jasność: Zmiana `aria-label` z "Kliknij aby przejść do podstrony Kontakt" na prostszy i bezpośrednią opis, takie jak "Przejdź do strony Kontakt", może poprawić spójność i jasność informacji. Użytkownicy technologii wspomagających zazwyczaj skorzystają z bardziej bezpośredniego opisu.
Redundancja: Aby uniknąć redundancji, `aria-label` nie powinno odzwierciedlać dokładnie tego samego tekstu co element linku, chyba że jest to celowe z kontekstem.
W tej formie tekst w elemencie oraz opis `aria-label` są jasne i wystarczające, zapewniając dostęp do strony Kontakt. Jeśli "Kontakt" samodzielnie nie oddaje zamierzonego działania lub funkcji linku, możesz rozważyć użycie bardziej opisowego tekstu w elemencie zamiast `aria-label`.
Qwen3:14b
<think>
Okay, let me look at this code. The user provided an anchor tag with an href to "/kontakt/" and an aria-label that says "Kliknij aby przejść do podstrony Kontakt". The text inside the link is "Kontakt".
First, I need to check if this meets WCAG guidelines. The main thing here is the use of aria-label. The aria-label is used to provide a text alternative for non-text content, but in this case, the link already has visible text. The WCAG success criteria say that if the text is visible, you shouldn't need an aria-label because the text itself is the label. Using aria-label here might be redundant.
Also, the aria-label text is a bit long and includes the action ("Kliknij aby") which is not necessary. The visible text "Kontakt" is sufficient. The aria-label should be concise and only provide additional context if needed. Since the visible text is already clear, the aria-label is redundant.
Another point is that the visible text is in Polish, and the aria-label is also in Polish. That's okay, but the main issue is the redundancy. The aria-label is not needed here because the visible text serves the same purpose. This might cause screen readers to read both the text and the aria-label, which could be confusing for users.
So, the conclusion is that the aria-label is unnecessary here. The correct approach would be to remove the aria-label and rely on the visible text "Kontakt" as the label. That would make the code more accessible by avoiding redundant information and following the WCAG guidelines.
</think>
Ocena: Niepoprawny z punktu widzenia dostępności.
Uzasadnienie:
`aria-label` jest zbędny, ponieważ link zawiera widoczny tekst "Kontakt", który sam w sobie stanowi wystarczające oznaczenie. WCAG zaleca unikanie nadmiarowego opisu przez `aria-label`, jeśli tekst jest już widoczny. Dodatkowo, `aria-label` powinien być stosowany tylko w przypadkach, gdy tekst nie może być widoczny (np. ikony). Użycie `aria-label` tutaj może prowadzić do powtarzania informacji dla użytkowników ekranowych, co pogarsza doświadczenie.
Poprawna wersja:
<a href="/kontakt/">Kontakt</a>
gemma3:12b
Kod jest prawidłowy.
Uzasadnienie:
Użyto atrybutu `aria-label` do zdefiniowania czytelnego dla czytników ekranowych etykiety linku.
Etykieta jest informatywna i opisuje cel linku ("Kliknij aby przejść do podstrony Kontakt").
Użyto standardowego znacznika `<a href="...">` dla linku.
SpeakLeash/bielik-11b-v2.0-instruct-imatrix:Q6_K
Tak, kod jest poprawny z punktu widzenia cyfrowej dostępności. Atrybut `aria-label` zawiera pełne i opisowe informacje dla użytkowników korzystających z technologii wspomagających, takich jak czytniki ekranu.
gemma3:1b
Poprawny. Kod spełnia standardy WCAG dla elementów interfejsu użytkownika, w tym:
Accessibility Statement: Układ elementów jest poprawny.
ARIA Attributes: Użycie `aria-label` jest poprawne dla użytkownika z niepełnosprawnością wzrokowo.
Link: `href="/kontakt"` to prawidłowy link, a `aria-label` jest poprawna.
Uzasadnienie: Element `<a>` jest poprawnie zdefiniowany, a jego właściwości `aria-label` są odpowiednie dla zapewnienia dostępności dla osób z niepełnosprawnością wzrokową. Wykorzystanie `href` jest zgodne z standardem.
OpenAI GPT OSS20b
Ocena: OK – nie narusza wymogów WCAG, ale `aria-label` nie jest potrzebny.
Uzasadnienie:
Tekst widoczny („Kontakt”) już samodzielnie opisuje link, więc dodatkowy aria‑label nie jest wymagany.
`aria-label` nadpisuje tekst linku dla czytników – w praktyce będzie odczytywane „Kliknij aby przejść do podstrony Kontakt”.
Taki opis jest niepotrzebny (słowo „Kliknij” jest redundantne) i może lekko zamazywać przekaz, ale nie powoduje błędu dostępności ani nie powoduje problemów z kontrastem czy orientacją.
Podsumowując, element jest dostępny, ale lepiej byłoby po prostu pozostawić tekst „Kontakt” bez dodatkowego a‑ria‑label.
Wnioski
Jedynym modelem, który odpowiedział w pełni poprawnie jest Gemini 2.5 Pro. Jako jedyny zwrócił uwagę na kryterium etykiety w nazwie. Dobrze wypadł też chiński model rozumujący Qwen 3 14B, chociaż w rozumowaniu popełnił błędy. Jako ćwiczenie możesz je znaleźć w angielskim łańcuchu myśli. Tak czy inaczej - całkiem nieźle.
Kilka modeli zaproponowało poprawny kod, chociaż jako coś dodatkowego. W zasadzie uznawały kod za prawidłowy, który należy tylko udoskonalić.
Były też modele, przede wszystkim te najmniejsze, które chwaliły kod bezkrytycznie. Wszystko jest w porządku, bo jest ARIA! Zupełnie jak niektórzy deweloperzy:)
Modele od jednego producenta, na przykład Google, mają czasem zupełnie odmienne zdanie na temat przykładowego kodu. Modele Gemini i Gemma są od Google i tak radzą sobie nieźle, zwłaszcza w porównaniu z Phi od Microsoft. Zerknij jeszcze raz, ile jest sprzeczności w jego uzasadnieniu.
Zuepłnie jak w życiu… Im model mądrzejszy przez wielkość, rozumowanie lub z innego powodu, tym lepsze odpowiedzi. Najmniejsze modele poległy po całości. One jednak mogą być dobrym materiałem do trenowania.
Jeżeli zastanawiasz się, dlaczego nie ma tu modeli Claude, Deepseek i innych, to tylko z braku czasu. Skoro mam już odpowiedni kod, to mogę przecież podpinać kolejene modele. A może nawet zrobić arenę do porównywania modeli. Jeżeli jesteś za - daj znać.
Co chciałem pokazać tym eksperymentem? Ano tyle że nie można ufać modelom ogólnego przeznaczenia. One tylko mielą tokeny, które dostały ze źródeł różnej jakości. Co wcale nie oznacza, że nie można zrobić dobrego narzędzia wspomagającego opartego o AI. To raczej kwestia czasu i pieniędzy. Odpowiednie dotrenowanie modelu, dostarczenie zewnętrznych zasobów wiedzy i narzędzi do używania.
Jak napisałem na początku - inspiracją była Paulina. Jednak impulsem moje doświadczenia z vibe coding. Otórz wykazałem, że różne modele znają się na dostępności w różnym stopniu, a udają że są ekspertami. Coś jak na naszym polskim rynku. Dlatego nie ufaj AI podczas kodowania, przynajmniej do czasu aż pojawią się specjalizowane narzędzia.
Wieści o dostępności
Już 15 sierpnia odbędzie się kolejna edycja wydarzenia Lustro historii. Zapraszają Ania Czapnik i Janusz Olszyński z Fundacji Kinematograf. Będzie się dziać w Rabce-Zdroju, więc jeżeli masz blisko lub nawet daleko - warto! Wiem, bo już kilka razy byłem.
Z kolei na 22 października Kinaole zaprasza na Festiwal dostępności do Wrocławia. Na razie informacji nie ma za dużo, więc warto śledzić.
Jeżeli ktoś z działki dostępnościowej nie zna Piotra Witka, to nie wiem, pod jakim kamieniem siedział. Jednak może nie każdy wie, że Piotr prowadzi blog poświęcony technologiom wykorzystywanym przez osoby niewidome. Moja szuflada jest pełna porad, artykułów i testów. Rozszerzeniem jest kanał na YouTube, w którym Piotr prezentuje przede wszystkim aplikacje mobilne korzystające z AI. No polecam!
Jak zwykle zapraszam Cię na kawę. Oczywiście to Ty stawiasz:) A ja się kiedyś odwdzięczę.
I to by było na tyle. Wczoraj coś mnie boleśnie użarło, jak stałem pod Netto czekając na Ewę. Czy w Polsce są jakieś jadowite robale? Palec mi spuchł i nie wiem, co z tym robić. Pewnie siedzisz sobie na plaży nad zimnym Bałtykiem, popijasz piwo i skrolujesz Dostępnik. Baw się dobrze i odpoczywaj.