Opis obrazu: Smartfon leżący na drewnianym biurku z wyświetlonym interfejsem czatu AI i podpiętymi słuchawkami — wizualny znacznik projektowania promptów AI przyjaznych dla czytnika ekranu.

Czas czytania: 9 minut

W ciągu ostatnich osiemnastu miesięcy w społeczności dostępności wykrystalizowała się nowa dyscyplina projektowa, która wciąż nie ma ustalonej nazwy. Niektóre zespoły nazywają ją „inżynierią promptów świadomą AT“; inne mówią o „promptach systemowych kształtowanych przez czytnik ekranu“; praktycy wywodzący się z projektowania interfejsów głosowych skłaniają się ku określeniu „warstwa wyjścia mowy LLM“. Niezależnie od nazwy, rzemiosło jest takie samo: pisanie promptów systemowych i reguł kształtowania wyjścia, które sprawiają, że asystenci generatywnej AI — ChatGPT, Claude, Gemini, Copilot, Be My AI — są użyteczni dla ok. 253 milionów ludzi na całym świecie, którzy korzystają z tych produktów za pośrednictwem czytnika ekranu.

Problem jest konkretny, a tryb awarii — głośny. LLM wytrenowany na publicznym internecie generuje domyślnie prozę ozdobioną myślnikami, zagnieżdżonymi listami markdown, blokami kodu, nagłówkami istniejącymi wyłącznie dlatego, że model uznał odpowiedź za „ustrukturyzowaną“, i dekoracyjnymi emoji. Odczytane na głos przez NVDA, JAWS, VoiceOver lub TalkBack, to wyjście staje się strumieniem wtrąceń „myślnik myślnik“, wyliczania „punkt punkt punkt“ bez żadnego sygnału, gdzie kończy się jeden element, anonsów „nagłówek poziomu drugiego“ przerywających zdanie i ciągów nazw emoji („uśmiechnięta twarz w okularach przeciwsłonecznych“) między kolejnymi klauzulami. Informacja jest w środku. Użytkownik nie może jej wyodrębnić bez trzykrotnego przewijania. Ten artykuł jest omówieniem tego, czego dyscyplina żąda od twórców modeli, co produkty dostarczyły do tej pory i jakie problemy UX pozostają nierozwiązane.

Nowa dyscyplina — z czego faktycznie się składa

Projektowanie promptów świadome czytnika ekranu to nie jedna reguła. To mały zestaw ograniczeń, które razem produkują wyjście, które syntezator może wymówić w sposób zrozumiały, a klawisz nawigacyjny czytnika ekranu może przez nie przechodzić. Ograniczenia dzielą się na cztery kategorie.

Zwięzłe odpowiedzi o semantycznej strukturze. Domyślne wyjście LLM jest zbyt długie do dostarczenia mówionego — 600-słowna odpowiedź, która dobrze czyta się w przeglądarce sighted użytkownika, staje się czterominutowym monologiem, który użytkownik czytnika ekranu nie ma możliwości przejrzeć. Dyscyplina wymaga krótszych odpowiedzi, ale co ważniejsze — ustrukturyzowanych krótszych odpowiedzi: otwierającego jednozdaniowego podsumowania, na którym użytkownik może się zatrzymać, a następnie struktury, przez którą czytnik ekranu może nawigować za pomocą nagłówka lub elementu listy.

Unikanie myślników i innych znaków interpunkcyjnych, które syntezatory wymawiają błędnie. Myślnik, półpauza, nawias, ukośnik jako spójnik, separator ASCII — wszystkie te znaki są odczytywane na głos albo jako cisza, dosłowny „myślnik“, albo jako dezorientująca pauza przerywająca klauzulę na pół. Konwencja wyłaniająca się wśród głównych modeli brzmi: preferuj przecinek i kropkę; używaj dwukropka w jednym miejscu, gdzie naprawdę się przydaje; nigdy nie używaj myślników w odpowiedziach przeznaczonych do mowy; nigdy nie używaj separatorów ASCII do oddzielania sekcji.

Deklarowanie, co jest listą, co nagłówkiem, co kodem. Mowa syntetyzowana nie ma hierarchii wizualnej. Nagłówek musi być anonsowany jako „nagłówek“, lista jako „lista z N elementami, element pierwszy“, kod jako „kod“, a model musi albo generować struktury, które czytnik ekranu rozpoznaje (HTML, właściwy markdown, który powierzchnia renderująca konwertuje do ARIA), albo słownie opisywać strukturę samodzielnie („Oto trzy opcje. Opcja pierwsza: …“).

Żadnej zupy markdown. Markdown jest w porządku, gdy powierzchnia renderująca konwertuje go na semantyczny HTML. Markdown jest wrogi, gdy powierzchnia wyświetla surowe gwiazdki i podkreślenia, bo czytnik ekranu anonsuje wtedy „gwiazdka gwiazdka“ przed każdym pogrubionym słowem. Dyscyplina polega na wykryciu kontekstu renderowania — interfejs czatu z renderowaniem markdown kontra terminal kontra interfejs głosowy sterowany czytnikiem ekranu — i odpowiednim kształtowaniu wyjścia. Ten sam model musi generować różne reprezentacje tej samej odpowiedzi dla różnych powierzchni.

Czego czytniki ekranu faktycznie potrzebują od AI

Aby powyższe ograniczenia stały się konkretne, warto przyjrzeć się rzeczywistemu zachowaniu czterech kombinacji czytnik ekranu / system operacyjny dominujących w tej dziedzinie: JAWS na Windows, NVDA na Windows, VoiceOver na macOS i iOS oraz TalkBack na Android. Nie są one wymienne, a prompt generujący świetne wyjście dla jednego może być nieczytelny na innym.

Nawigacja po nagłówkach. Wszystkie cztery czytniki udostępniają klawisz nawigacji po nagłówkach (H w JAWS i NVDA, Rotor w VoiceOver, przełącznik trybu czytania w TalkBack). Aby długa odpowiedź AI była nawigowalna, model musi generować prawdziwe semantyczne nagłówki — albo przez potok renderowania markdown konwertujący do <h2>/<h3> z właściwym zagnieżdżeniem poziomów, albo przez API odpowiedzi ustrukturyzowanej samej powierzchni czatu. Model, który „strukturyzuje“ odpowiedź poprzez pogrubienie pierwszych trzech słów każdego akapitu, wytworzył coś, co wygląda na ustrukturyzowane wizualnie i jest całkowicie płaskie dla czytnika ekranu.

Nawigacja po listach. Listy są przydatne w wyjściu mówionym właśnie dlatego, że czytnik ekranu anonsuje liczbę elementów („lista z siedmioma elementami“) i pozwala użytkownikowi przechodzić między nimi klawiszem nawigacji (I w NVDA, L w JAWS). Działa to jednak tylko wtedy, gdy lista jest prawdziwym elementem <ul> lub <ol>. „Lista“ wygenerowana przez emitowanie znaków punktu na początku każdego wiersza, bez wrappera listy, jest odczytywana jako zwykła proza z niewyjaśnionym wtrąceniem „czarne kółko“ lub „punkt“ w każdym wierszu.

Pomijanie sekcji. Długie odpowiedzi AI — wyjaśnienia, porównania, kod z komentarzami, instrukcje wieloetapowe — wymagają sposobu, w jaki użytkownik czytnika ekranu może przejść do interesującej go sekcji bez słuchania wstępu. To najtrudniejszy element do dobrego zaprojektowania, bo model musi wygenerować nawigowalną strukturę, a powierzchnia czatu musi renderować ją w sposób, który system operacyjny udostępnia technologii wspomagającej, a czytnik ekranu musi być skonfigurowany do używania klawisza nawigacji po nagłówkach na tej powierzchni. Wszystkie trzy rzeczy zawodzą w praktyce; zwykle chodzi o środkową.

Wskazówki wymowy. Głosy syntetyczne potykają się na terminach technicznych, skrótach z mieszanymi literami, adresach URL, identyfikatorach kodu, notacji matematycznej i imionach spoza języka angielskiego. Dobrze zaprojektowany model dla odpowiedzi w kontekście czytnika ekranu rozpisze skróty przy pierwszym użyciu („WCAG, Wytyczne dotyczące dostępności treści internetowych“), rozszerzy skrótowce, których syntezator nie może wymówić, i uniknie umieszczania surowych adresów URL w płynącej prozie, gdzie syntezator będzie czytał ukośniki na głos. Żaden z głównych produktów nie robi tego konsekwentnie w 2026 roku.

Jak produkty sobie z tym radzą

W połowie 2026 roku główne produkty generatywnej AI zajęły wyraźnie różne pozycje w kwestii wyjścia świadomego czytnika ekranu. Żaden z nich nie opanował tej kwestii w pełni. Postęp jest szybszy niż dwanaście miesięcy temu, ale luka między najlepszym a najgorszym jest wciąż duża.

ChatGPT (OpenAI). Klient webowy posiada teraz przełącznik „trybu zwięzłego“, który skraca domyślne odpowiedzi i redukuje dekorację markdown. Tryb głosowy wprowadzony w 2024 roku — i istotnie ulepszony w 2025 — jest najbliższym, do czego jakikolwiek główny produkt doszedł w zakresie interfejsu natywnego dla czytnika ekranu, bo całkowicie omija wizualny czat i dostarcza mówioną odpowiedź z gestami zatrzymania, odtwarzania i „powiedz to jeszcze raz“. Pole niestandardowych instrukcji pozwala użytkownikom czytników ekranu zadeklarować swoje preferencje raz i stosować je w kolejnych sesjach — to obejście na poziomie użytkownika, które społeczność przyjęła. Pozostałe luki: modele GPT domyślnie generują prozę z wieloma myślnikami, chyba że zostanie wskazane inaczej, a poziom nagłówka emitowany w markdown nie zawsze mapuje się czysto na ARIA w powierzchni czatu.

Claude (Anthropic). Dyscyplina promptów systemowych Claude przesunęła się najbliżej opisanych powyżej konwencji. Model jest wyraźnie mniej skłonny do myślników niż linia GPT w 2026 roku, domyślnie generuje krótsze odpowiedzi i dobrze reaguje na instrukcje promptów systemowych jak „rozmawiasz z użytkownikiem czytnika ekranu; nie używaj myślników, preferuj krótkie akapity i używaj prawdziwych nagłówków lub list numerowanych, gdy potrzebna jest struktura“. Powierzchnia czatu Claude.ai renderuje markdown do semantycznego HTML z właściwymi poziomami nagłówków, co sprawia, że klawisz nawigacji po nagłówkach działa. Wyjście głosowe przez integracje firm trzecich istnieje, ale jest mniej rozwinięte niż natywny tryb głosowy ChatGPT.

Gemini (Google). Ścisła integracja z TalkBack na Android to strukturalna przewaga Gemini; model może przekazywać sterowanie do czytnika ekranu na poziomie systemu operacyjnego przez usługi dostępności Android w sposób, którego iOS i konkurenci webowi nie mogą. Przepływ „Hey Google, zapytaj Gemini…“ na dostępnych urządzeniach Android to dla niektórych użytkowników najbardziej naturalne dostępne doświadczenie AI i czytnika ekranu. Pozostałe luki: interfejs webowy wciąż nadmiernie dekoruje odpowiedzi, hierarchia nagłówków w odpowiedziach webowych Gemini jest niespójna, a model jest bardziej skłonny do dekoracyjnych emoji niż jego konkurenci.

Be My AI (Be My Eyes + OpenAI). To najbardziej wąsko ukierunkowany z czterech — asystent wizualny opis używający modeli wizyjnych klasy GPT-4 do opisywania obrazów i otoczenia niewidomym użytkownikom i osobom słabowidzącym. To także jedyny produkt na tej liście zaprojektowany od pierwszego dnia z myślą o użytkowniku czytnika ekranu jako odbiorcą głównym. Projekt promptów Be My AI to najklarowniejsza demonstracja w tej dziedzinie, jak wygląda wyjście świadome AT w praktyce: opisy otwierają się jednozdaniowym podsumowaniem, na którym użytkownik może się zatrzymać, a szczegółową strukturę udostępniają dopiero na żądanie, unikając języka przestrzennego („po lewej“, „powyżej“), który wymaga wzrokowego kontekstu do interpretacji. Produkt pozostaje w 2026 roku najbliższy referencyjna implementacji w tej dziedzinie.

Przekrojowa obserwacja jest taka, że cztery produkty poczyniły postępy w łatwych obszarach — krótsze odpowiedzi, mniej myślników, pole niestandardowych instrukcji — i ledwo zaczęły w obszarach trudnych. Trudne obszary opisano poniżej.

Nierozwiązane problemy UX

Literatura dotycząca projektowania promptów świadomych czytnika ekranu wskazuje cztery otwarte problemy UX, dla których właściwa odpowiedź nie jest jeszcze znana. Żaden z nich nie jest problemem możliwości modelu; wszystkie są problemami projektowania interakcji siedzącymi między LLM, powierzchnią czatu, systemem operacyjnym i czytnikiem ekranu.

Możliwość przerwania. Użytkownik widzący może przeskanować odpowiedź LLM w ok. dwie sekundy i zdecydować, czy ją czytać. Użytkownik czytnika ekranu nie może. Jeśli odpowiedź jest błędna lub odbiega od tematu, użytkownik musi wysłuchać jej wystarczająco dużo, by to stwierdzić, a następnie przerwać. Tryby głosowe mają przycisk zatrzymania. Tryby tekstowe generalnie go nie mają — odpowiedź strumieniuje się i czytnik ekranu anonsuje ją jako nową treść w miarę napływania, a użytkownik nie ma czystego sposobu powiedzenia „przestań generować, to nie jest to, o co pytałem“. Aplikacja Be My AI radzi sobie z tym najlepiej; webowe klienty czatu radzą sobie najgorzej.

Powtarzanie ostatniej odpowiedzi z wybieralną granularnością. Poproszenie czytnika ekranu o ponowne odczytanie ostatniej odpowiedzi jest łatwe, jeśli odpowiedź jest krótka. Jest bezużyteczne, jeśli odpowiedź ma sześć akapitów, a użytkownik chce usłyszeć tylko trzeci akapit ponownie. Interakcja, o którą prosi społeczność, to „powtórz ostatni element listy“, „powtórz ostatnią sekcję nagłówka“, „powtórz ostatni blok kodu“. Wymaga to od powierzchni czatu udostępnienia struktury czytnikowi ekranu w sposób, do którego własne polecenia ponownego odczytu czytnika mogą się odwołać. W 2026 roku żaden z głównych produktów tego nie robi; użytkownik musi korzystać z własnej nawigacji linia po linii czytnika ekranu, co jest uciążliwe.

Nawigacja po sekcjach w wyjściu mówionym. Tryby głosowe nie mają klawisza nawigacji po nagłówkach. Użytkownik słucha czterominutowej odpowiedzi liniowo, bez możliwości przeskoczenia z sekcji „przegląd“ do sekcji „szczegóły“ bez przewijania po czasie. Projektowane wzorce interakcji — mówiona „lista sekcji“, po której użytkownik może nawigować strzałkami, polecenie głosowe „przejdź do sekcji trzeciej“, tryb „pokaż mi tylko nagłówki“ — są wczesne. Funkcja follow-up aplikacji Be My AI „więcej szczegółów o kolorach“ jest najbliżej działającej wersji tego w produkcie gotowym do wysyłki.

Kwestia przekazania AT — kiedy AI mówi, a kiedy czyta treść na głos? To najgłębsze pytanie projektowe. Jeśli użytkownik czytnika ekranu otwiera asystenta AI na stronie internetowej, kto mówi — własny głos AI (warstwa TTS), czy zainstalowany czytnik ekranu użytkownika odczytujący wyjście tekstowe AI? Oba głosy mają różne ustawienia, różne prędkości mówienia, różne wskazówki wymowy, różne gesty zatrzymania i odtwarzania. Dwa systemy próbujące mówić tę samą treść w tym samym czasie nie produkują nic użytecznego. Wyłaniająca się konwencja brzmi: interakcje w trybie głosowym używają własnego TTS AI i wyraźnie tłumią czytnik ekranu; interakcje w trybie tekstowym emitują semantyczny HTML i pozwalają czytnikowi ekranu mówić. Ale granica między dwoma trybami nie zawsze jest czysta — opis obrazu, generowanie kodu, notacja matematyczna i odpowiedzi multimodalne wszystkie siedzą niewygodnie między głosem a tekstem — i to na tej granicy żyje większość aktywnych problemów UX.

Gdzie to zmierza

Dyscyplina jest mniej więcej tam, gdzie dostępność webowa była ok. 2002 roku — za fazą „czy to realny problem?“, za fazą „kto jest odpowiedzialny?“, w fazie „jakie są faktyczne reguły?“. W ciągu 2026 i 2027 roku prawdopodobnie nastąpią trzy rzeczy.

Po pierwsze, twórcy modeli skodyfikują swoje wewnętrzne prompty dla czytników ekranu i opublikują je, tak jak Anthropic publikuje prompty systemowe Claude w deklaracjach dostępności w stylu VPAT, a OpenAI zaczął dokumentować domyślne zachowania GPT. Społeczność prosi o odpowiednik karty modelu — „kartę wyjścia dla czytnika ekranu“ — która nazywa konwencje, do stosowania których dany model został wytrenowany lub który ma skonfigurowany prompt systemowy.

Po drugie, powierzchnie czatu — klienty webowe, aplikacje mobilne, integracje IDE — zyskają właściwe potoki renderowania semantycznego HTML i właściwą ekspozycję ARIA dla historii czatu, z klawiszami nawigacyjnymi zmapowanymi do czytnika ekranu na poziomie systemu operacyjnego. To jest nieglamurowa praca, i to jest praca, która najbardziej przesunie igłę dla codziennych użytkowników.

Po trzecie, sami dostawcy czytników ekranu — Vispero (JAWS), NV Access (NVDA), Apple (VoiceOver), Google (TalkBack) — zaczną dostarczać funkcje świadome AI: natywna nawigacja po nagłówkach wewnątrz powierzchni czatu AI, standardowy gest „zatrzymaj generowanie“, inteligentniejsze polecenia ponownego odczytu znające strukturę odpowiedzi LLM. Ekosystem wtyczek open-source NVDA już produkuje wczesne wersje tego. Własnościowe czytniki są wolniejsze, ale kierunek jest ten sam.

Głębsza obserwacja jest taka, że projektowanie promptów świadomych czytnika ekranu przestało być niszową troską garści niewidomych deweloperów i stało się bazowym oczekiwaniem każdego zespołu produktu AI, który chce dostarczać na regulowane rynki. Europejski Akt o Dostępności (EAA) stosuje się do „interaktywnych terminali samoobsługowych“ i „konsumenckiego sprzętu terminalowego z interaktywną możliwością obliczeniową“ — kategorii, która prawie na pewno obejmuje głównego asystenta AI na telefonie. Warstwa wyjścia świadoma AT nie jest już funkcją; jest wymogiem zamówień publicznych. Zespoły, które teraz opanują reguły, dostarczą produkty, które przetrwają 28 czerwca 2025 roku i późniejszy okres. Zespoły traktujące to jako afterthought będą kolejną rundą spraw egzekucyjnych EAA.

Podsumowanie

Rzemiosło jest małe, stawki są wysokie, a reguły wciąż są pisane. Jeśli tworzysz z LLM i nie odbyłeś jeszcze rozmowy z użytkownikiem czytnika ekranu o tym, jak produkt faktycznie brzmi, gdy go używa, to jest następna pozycja na liście. Większość tego, co jest nie tak z AI dla użytkowników czytników ekranu w 2026 roku, nie jest problemem możliwości modelu; jest problemem projektowania promptów i powierzchni, który każdy zespół produktowy może rozwiązać w sprincie, jeśli zdecyduje się to zrobić.

Społeczność była hojna ze swoim czasem, testowaniem i cierpliwością. Traci też cierpliwość szybciej niż kiedyś, bo produkty są teraz powszechne, a wymówka „wciąż to rozgryzamy“ straciła ważność. Dyscyplina jest tutaj. Konwencje się ujednolicają. Kolejne osiemnaście miesięcy wyłoni zespoły, które słuchały, od tych, które tego nie robiły.