Описание на изображението: Смартфон, поставен върху дървено бюро, показва интерфейс за ИИ чат с включени слушалки — визуалният маркер за проектиране на ИИ промптове, съобразени с екранните четци.

Време за четене: 9 минути

През последните осемнадесет месеца в общността по достъпност се оформи нова проектантска дисциплина и тя все още няма установено име. Някои екипи я наричат „инженеринг на промптове, съобразен с помощните технологии“; други я наричат „системни промптове, оформени за екранни четци“; практикуващите, които идват от проектирането на гласови интерфейси, обикновено я наричат „слоят за гласов изход на езиковия модел“. Какъвто и да е етикетът, занаятът е същият: писане на системни промптове и правила за оформяне на изхода, които правят генеративните ИИ асистенти — ChatGPT, Claude, Gemini, Copilot, Be My AI — полезни за приблизително прибл. 253 милиона души по света, които достигат тези продукти чрез екранен четец.

Проблемът е конкретен, а режимът на провал е шумен. Езиков модел, обучен върху публичния уеб, произвежда по подразбиране текст, украсен с тирета, вложени markdown списъци, кодови огради, заглавия, които съществуват само защото моделът е почувствал отговора за „структуриран“, и декоративни емоджита. Прочетен на глас от NVDA, JAWS, VoiceOver или TalkBack, този изход се превръща в поток от „тире тире“ вмятания, изброяване „точка точка точка“ без никакво усещане къде свършва един елемент, съобщения „заглавие ниво две“, които прекъсват изречението, и поредици от имена на емоджита („усмихнато лице със слънчеви очила“) през всяка втора фраза. Информацията е вътре. Потребителят не може да я извлече, без да превърти назад три пъти. Този материал е въведение в това какво изисква дисциплината от създателите на модели, какво са пуснали продуктите досега и какви са нерешените UX проблеми, които все още никой не е решил.

Новата дисциплина — от какво всъщност се състои

Проектирането на промптове, съобразено с екранните четци, не е едно-единствено правило. То е малък набор от ограничения, които заедно произвеждат изход, който синтезаторът може да произнесе разбираемо и навигационен клавиш на екранен четец може да премине през него. Ограниченията попадат в четири групи.

Кратки отговори със семантична структура. Изходът на езиковите модели по подразбиране е твърде дълъг за устно поднасяне — отговор от 600 думи, който се чете добре в браузъра на зрящ потребител, се превръща в четириминутен монолог, който потребителят на екранен четец няма как да прегледа на бегло. Дисциплината изисква по-кратки отговори, но по-важното — структурирани по-кратки отговори: начално едноизреченческо обобщение, на което потребителят може да спре, последвано от структура, през която екранният четец може да навигира по заглавие или по елемент от списък.

Избягвайте тиретата и другата пунктуация, която синтезаторите произнасят погрешно. Дългото тире, средното тире, вмъкнатото в скоби, наклонената черта като съюз, ASCII разделителят — всички те се четат на глас или като тишина, или като буквално „тире“, или като объркваща пауза, която разделя фразата наполовина. Конвенцията, която се оформя сред основните модели, е: предпочитайте запетаята и точката; използвайте двоеточието на единственото място, където то наистина оправдава присъствието си; никога не използвайте тирета в отговорите в устен контекст; никога не използвайте ASCII разделители за разделяне на секции.

Декларирайте какво е списък, какво е заглавие, какво е код. Синтезираната реч няма визуална йерархия. Заглавието трябва да бъде обявено като „заглавие“, списъкът трябва да бъде обявен като „списък с N елемента, елемент първи“, кодът трябва да бъде обявен като „код“, а моделът трябва или да изведе структури, които екранният четец разпознава (HTML, правилен markdown, който повърхността за изобразяване преобразува в ARIA), или сам да опише словесно структурата („Ето три опции. Опция първа: …“).

Без markdown каша. Markdown е добре, когато повърхността за изобразяване го преобразува в семантичен HTML. Markdown е враждебен, когато повърхността показва суровите звездички и долни черти, защото тогава екранният четец обявява „звездичка звездичка“ преди всяка удебелена дума. Дисциплината е да се разпознае контекстът на изобразяване — чат интерфейс с изобразяване на markdown спрямо терминал спрямо гласов интерфейс, управляван от екранен четец — и да се оформи изходът съответно. Един и същ модел трябва да произвежда различни повърхностни представяния на един и същ отговор.

От какво всъщност се нуждаят екранните четци от ИИ

За да направим горните ограничения конкретни, помага да се разгледа реалното поведение на четирите комбинации екранен четец / операционна система, които доминират в областта: JAWS на Windows, NVDA на Windows, VoiceOver на macOS и iOS, и TalkBack на Android. Те не са взаимозаменяеми и промпт, който произвежда чудесен изход за един, може да бъде нечетим на друг.

Навигация по заглавие. И четирите четеца предлагат клавиш за навигация по заглавия (H в JAWS и NVDA, Rotor във VoiceOver, превключвателят за управление на четенето в TalkBack). За да бъде дълъг ИИ отговор навигируем, моделът трябва да изведе истински семантични заглавия — или чрез процес за изобразяване на markdown, който преобразува към <h2>/<h3> с правилно вложени нива, или чрез собствения API за структуриран отговор на чат повърхността. Модел, който „структурира“ отговора си, като удебелява първите три думи на всеки абзац, е произвел нещо, което изглежда структурирано визуално и е напълно плоско за екранния четец.

Навигация по списък. Списъците са полезни в устния изход именно защото екранният четец обявява броя („списък със седем елемента“) и позволява на потребителя да преминава с навигационния клавиш за елемент от списък (I в NVDA, L в JAWS). Но това работи само ако списъкът е истински <ul> или <ol>. „Списък“, произведен чрез извеждане на символи за водещи точки в началото на всеки ред, без обвивка за списък, се чете като обикновен текст с необяснено вмятане „черен кръг“ или „точка“ на всеки ред.

Прескачане по секция. Дългите ИИ отговори — обяснения, сравнения, код и коментар, многоетапни инструкции — се нуждаят от начин потребителят на екранен четец да прескочи към секцията, която го интересува, без да изслушва увода. Това е най-трудната за добро проектиране част, защото моделът трябва да произведе навигируема структура, и чат повърхността трябва да я изобрази по начин, който операционната система излага на помощната технология, и екранният четец трябва да бъде конфигуриран да използва клавиша за навигация по заглавия в тази повърхност. И трите неща се провалят в реалния свят; обикновено това е средното.

Подсказки за произношение. Синтетичните гласове се препъват в технически термини, акроними със смесени букви, URL адреси, кодови идентификатори, математическа нотация и неанглийски имена. Добре проектиран модел ще, за отговори в контекст на екранен четец, изписва акронимите при първа употреба („WCAG, Насоките за достъпност на уеб съдържанието“), разшири инициализмите, които синтезаторът не може да произнесе, и избягва вграждането на сурови URL адреси в течащ текст, където синтезаторът ще прочете наклонените черти на глас. Никой от основните продукти не прави това последователно през 2026 г.

Как продуктите се справят с това

Към средата на 2026 г. основните генеративни ИИ продукти заеха видимо различни позиции по отношение на изхода, съобразен с екранните четци. Никой от тях не го е овладял напълно. Напредъкът е по-бърз, отколкото беше преди дванадесет месеца, но разликата между най-добрия и най-лошия все още е голяма.

ChatGPT (OpenAI). Уеб клиентът вече предлага превключвател за „кратък режим“, който съкращава отговорите по подразбиране и намалява markdown украсата. Гласовият режим, въведен през 2024 г. — и съществено подобрен през 2025 г. — е най-близкото нещо, до което който и да е основен продукт е стигнал до интерфейс, естествен за екранен четец, защото изцяло заобикаля визуалния чат и поднася устен отговор с жестове за спиране, повторно възпроизвеждане и „кажи го отново“. Полето за персонализирани инструкции позволява на потребителите на екранни четци да декларират предпочитанията си веднъж и те да се прилагат през сесиите, което е заобиколното решение, водено от потребителите, на което общността е заложила. Останалите пропуски: моделите GPT все още по подразбиране произвеждат текст, наситен с тирета, освен ако не им е указано друго, а нивото на заглавията, изведено в markdown, не винаги се съпоставя чисто към ARIA в чат повърхността.

Claude (Anthropic). Дисциплината на системните промптове на Claude се е придвижила най-близо до описаните по-горе конвенции. Моделът е забележимо по-малко склонен към тирета от линията GPT през 2026 г., по подразбиране дава по-кратки отговори и реагира добре на инструкции в системния промпт като „говорите с потребител на екранен четец; не използвайте тирета, предпочитайте кратки абзаци и използвайте истински заглавия или номерирани списъци, когато е необходима структура“. Чат повърхността на Claude.ai изобразява markdown към семантичен HTML с правилни нива на заглавия, което кара клавиша за навигация по заглавия да работи. Гласовият изход чрез интеграции на трети страни съществува, но е по-слабо развит от собствения гласов режим на ChatGPT.

Gemini (Google). Тясната интеграция с TalkBack на Android е структурното предимство на Gemini; моделът може да предаде към екранния четец на ниво операционна система чрез услугите за достъпност на Android по начин, който конкурентите за iOS и уеб не могат. Потокът „Хей Google, попитай Gemini…“ на достъпни Android устройства е, за някои потребители, най-естественото налично преживяване с ИИ плюс екранен четец. Останалите пропуски: уеб интерфейсът все още прекалено украсява отговорите, йерархията на заглавията в уеб отговорите на Gemini е непоследователна, а моделът е по-склонен да произвежда декоративни емоджита от конкурентите си.

Be My AI (Be My Eyes + OpenAI). Това е най-тясно ограниченият от четирите — асистент за визуално описание, който използва модели за зрение от класа на GPT-4, за да описва изображения и обкръжение за слепи и слабовиждащи потребители. Той е и единственият продукт в този списък, проектиран от първия ден с потребителя на екранен четец като основна аудитория. Проектирането на промптовете на Be My AI е най-ясната демонстрация в областта на това как изглежда на практика изход, съобразен с помощните технологии: описанията започват с едноизреченческо обобщение, на което потребителят може да спре, продължават със структуриран детайл само при поискване и избягват пространствен език („отляво“, „отгоре“), който изисква зрящ контекст за тълкуване. Продуктът остава, през 2026 г., най-близкото нещо в областта до референтна реализация.

Общото наблюдение е, че четирите продукта са постигнали напредък по лесните части — по-кратки отговори, по-малко тирета, поле за персонализирани инструкции — и едва са започнали по трудните части. Трудните части са по-долу.

Нерешени UX проблеми, които никой не е решил

Литературата за проектиране на промптове, съобразено с екранните четци, се обединява около четири нерешени UX проблема, при които правилният отговор още не е известен. Нито един от тях не е проблем на възможностите на модела; всички те са проблеми на проектирането на взаимодействието, които стоят между езиковия модел, чат повърхността, операционната система и екранния четец.

Възможност за прекъсване. Зрящ потребител може да прегледа отговор на езиков модел за прибл. две секунди и да реши дали да го прочете. Потребителят на екранен четец не може. Ако отговорът е грешен или нецеленасочен, потребителят трябва да изслуша достатъчно от него, за да разбере това, и след това да прекъсне. Гласовите режими имат бутон за спиране. Текстовите режими обикновено нямат — отговорът се поднася на потока и екранният четец го обявява като ново съдържание, докато пристига, а потребителят няма чист начин да каже „спри да генерираш, това не е каквото попитах“. Приложението Be My AI се справя с това най-добре; уеб чат клиентите се справят най-зле.

Повторение на последния отговор с избираема степен на детайлност. Да поискаш от екранен четец да прочете отново последния отговор е лесно, ако отговорът е кратък. Това е неизползваемо, ако отговорът е шест абзаца, а потребителят иска да чуе отново само третия абзац. Взаимодействието, което общността иска, е „повтори последния елемент от списъка“, „повтори последната секция със заглавие“, „повтори последния блок код“. Това изисква чат повърхността да изложи структурата на екранния четец по начин, който собствените команди за повторно четене на екранния четец могат да адресират. През 2026 г. никой от основните продукти не прави това; потребителят трябва да използва собствената навигация ред по ред на екранния четец, което е трудоемко.

Навигация по секция в устния изход. Гласовите режими нямат клавиш за навигация по заглавия. Потребителят слуша четириминутен отговор линейно, без начин да прескочи от секцията „общ преглед“ към секцията „конкретика“, без да превърта назад по време. Прототипираните проектни решения за взаимодействие — устен „списък със секции“, през който потребителят може да навигира с клавишите със стрелки, гласова команда „иди на секция трета“, режим „дай ми само заглавията“ — са в ранен стадий. Последващото запитване „повече детайли за цветовете“ в приложението Be My AI е най-близката функционираща версия на това в издаден продукт.

Въпросът за предаването към помощните технологии — кога ИИ говори, а кога чете съдържание на глас? Това е най-дълбокият проектантски въпрос. Ако потребител на екранен четец отвори ИИ асистент на уебстраница, кой говори — собственият глас на ИИ (слоят за преобразуване на текст в реч) или инсталираният от потребителя екранен четец, който чете текстовия изход на ИИ? Двата гласа имат различни настройки, различни скорости на говорене, различни подсказки за произношение, различни жестове за спиране и повторно възпроизвеждане. Две системи, които се опитват да говорят едно и също съдържание едновременно, не произвеждат нищо използваемо. Конвенцията, която се оформя, е: взаимодействията в гласов режим използват собственото преобразуване на текст в реч на ИИ и изрично потискат екранния четец; взаимодействията в текстов режим извеждат семантичен HTML и оставят екранния четец да говори. Но границата между двата режима не винаги е чиста — описанието на изображения, генерирането на код, математическата нотация и многомодалните отговори стоят неудобно между глас и текст — и тази граница е там, където живеят повечето от актуалните UX проблеми.

Накъде върви оттук нататък

Дисциплината е приблизително там, където беше уеб достъпността през прибл. 2002 г. — отвъд фазата „това реален проблем ли е?“, отвъд фазата „отговорен ли е някой?“, навлязла във фазата „какви са всъщност правилата?“. Три неща вероятно ще се случат през 2026 и 2027 г.

Първо, създателите на модели ще кодифицират вътрешните си промптове за екранни четци и ще ги публикуват, така както Anthropic публикува системните промптове на Claude в декларации за достъпност в стил VPAT, а OpenAI започна да документира поведенческите настройки по подразбиране на GPT. Общността иска еквивалента на карта на модела — „карта за изход за екранни четци“ — която посочва конвенциите, които даден модел е обучен или системно подканен да следва.

Второ, чат повърхностите — уеб клиенти, мобилни приложения, интеграции в среди за разработка — ще получат правилни процеси за изобразяване на семантичен HTML и правилно излагане на ARIA за историята на чата, с навигационните клавиши, съпоставени към екранния четец на ниво операционна система. Това е неблагодарна работа и е работата, която ще раздвижи нещата най-много за ежедневните потребители.

Трето, самите доставчици на екранни четци — Vispero (JAWS), NV Access (NVDA), Apple (VoiceOver), Google (TalkBack) — ще започнат да пускат функции, съобразени с ИИ: вградена навигация по заглавия в ИИ чат повърхностите, стандартизиран жест „спри генерирането“, по-интелигентни команди за повторно четене, които познават структурата на отговора на езиковия модел. Екосистемата от добавки с отворен код на NVDA вече произвежда ранни версии на тези. Собственическите четци са по-бавни, но посоката е същата.

По-дълбокото наблюдение е, че проектирането на промптове, съобразено с екранните четци, престана да бъде нишова грижа на шепа слепи разработчици и стана базово очакване на всеки екип за ИИ продукт, който иска да навлезе на регулирани пазари. Европейският акт за достъпност се прилага към „интерактивни терминали за самообслужване“ и „потребителско терминално оборудване с интерактивни изчислителни възможности“ — категория, която почти със сигурност обхваща голям ИИ асистент на телефон. Слоят за изход, съобразен с помощните технологии, вече не е функция; той е обвързващ при обществените поръчки. Екипите, които изяснят правилата сега, ще пуснат продуктите, които ще оцелеят след 28 юни 2025 г. и нататък. Екипите, които го третират като нещо второстепенно, ще бъдат следващата вълна от случаи на правоприлагане по EAA.

Заключителни мисли

Занаятът е малък, залозите са големи, а правилата все още се пишат. Ако изграждате с езикови модели и още не сте провеждали разговор с потребител на екранен четец за това как всъщност звучи продуктът ви, когато той го използва, това е следващото нещо в списъка. Повечето от това, което е сбъркано в ИИ за потребителите на екранни четци през 2026 г., не е проблем на възможностите на модела; то е проблем на проектирането на промпта и повърхността, който всеки продуктов екип може да поправи в един спринт, ако реши да го направи.

Общността беше щедра с времето, тестването и търпението си. Тя също така губи търпение по-бързо отпреди, защото продуктите вече са масови и оправданието „все още го изясняваме“ се изчерпа. Дисциплината е тук. Конвенциите се сближават. Следващите осемнадесет месеца ще разграничат екипите, които слушаха, от екипите, които не слушаха.