Рукописный шрифт в мобильном приложении: доступность для VoiceOver и TalkBack

Рукописный шрифт может придать приложению индивидуальность, но сам по себе он не делает экранный текст доступным или недоступным для незрячего пользователя. VoiceOver и TalkBack обычно работают с текстом и семантикой элемента, а не с рисунком букв на экране. Чтобы оформление не мешало, оставьте важные фразы настоящим текстом, подготовьте понятные подписи для нестандартных элементов и проверьте интерфейс с увеличенным текстом и экранным диктором.

У текста на экране есть как минимум два слоя. Первый — видимые очертания: гарнитура, размер, насыщенность, интервалы. Второй — содержимое элемента и его роль в интерфейсе: подпись, кнопка, выбранное состояние. Экранный диктор озвучивает доступное содержимое и сведения о компоненте; рукописный рисунок глифов сам по себе не меняет строку, переданную приложением.

Поэтому надпись, набранная рукописным шрифтом в стандартной текстовой метке, может быть прочитана как обычный текст. Но декоративная надпись, вставленная картинкой, и самодельная кнопка с неописанной иконкой — другой случай: системе может не хватить содержимого и роли. В UIKit стандартные текстовые элементы доступны VoiceOver по умолчанию, а для нестандартных элементов разработчик добавляет нужную информацию. В Jetpack Compose смысл компонента передаётся через semantics; Android рекомендует убедиться, что встроенные значения подходят конкретному интерфейсу.

Сначала определите, зачем он нужен именно этому экрану. Часто достаточно применять личный почерк к короткому названию коллекции, приветствию, подписи к достижению или декоративному акценту. Длинные инструкции, настройки, формы, цены, ошибки и тексты кнопок лучше набирать нейтральной гарнитурой: их приходится быстро сканировать, сравнивать и исправлять.

Это не запрет на выразительный текст. Важно оставить пользователю ясный смысл и предсказуемые действия. Если рукописным начертанием набрано название раздела, оно всё равно должно оставаться настоящей текстовой строкой. Если надпись превращена в изображение ради точного вида, предоставьте эквивалентный текст для вспомогательных технологий и убедитесь, что изображение не дублируется в озвучивании.

Для обычной текстовой метки не добавляйте отдельную accessibility-подпись без причины: дублирование может привести к двойному чтению. Сначала проверьте поведение стандартного элемента. Отдельный label нужен, когда содержимое элемента не выражает его назначение или когда вы создали составной контрол, который платформа не распознаёт сама.

Подпись должна отвечать на вопрос «что это?», а подсказка — только при необходимости пояснять «что произойдёт?». Например, у кнопки с рукописным текстом «Вперед» можно оставить название «Продолжить», если визуальная надпись содержит сокращение или образную формулировку. Не пересказывайте всю инструкцию в accessibility-подписи: она должна быть короткой, конкретной и совпадать с функцией элемента.

Состояние передавайте отдельно от внешнего вида. Для вкладки важно сообщить, что она выбрана; для переключателя — включен он или выключен; для кнопки отправки — доступна ли она. Цветовой акцент, подчёркивание или смена начертания могут поддерживать визуальный сигнал, но не должны быть единственным способом понять состояние.

В интерфейсе с данными связывайте заголовок и значение по смыслу. На карточке профиля экранный диктор не должен сначала прочитать все подписи в строке, а потом все значения. Сгруппируйте пары логично или организуйте порядок обхода так, чтобы связь «Имя — Анна» была ясна без взгляда на экран. Проверьте также порядок озвучивания справа налево, если приложение поддерживает такие языки.

Пользовательские настройки размера текста нужны и декоративной надписи, если она несёт смысл. На iOS собственный шрифт можно масштабировать вместе с Dynamic Type; в UIKit для этого применяют масштабированный экземпляр шрифта и разрешают метке обновляться при изменении категории размера. В SwiftUI стандартный механизм текста тоже поддерживает Dynamic Type. Сам факт включения файла шрифта в приложение такую адаптацию не гарантирует — её нужно учесть в коде и проверить.

В Android задайте текстовые размеры в единицах, предназначенных для текста, и проверьте экран при увеличении системного размера. Ориентируйтесь на поведение конкретной платформы и выбранного UI-фреймворка: фиксированная высота карточки, кнопки или строки может обрезать увеличенную надпись даже тогда, когда сам текст увеличился корректно.

Проверяйте крайние случаи, а не только обычный размер. Длинное имя, составное слово, знак ударения, цифры, кавычки и строчные буквы с выносными элементами могут занять больше места или визуально сблизиться при крупном кегле. Дайте контейнеру возможность расти, переносить текст или перестраивать соседние элементы; не решайте проблему автоматически уменьшенным шрифтом, который снова становится нечитаемым.

Даже корректно озвучиваемая строка может выглядеть непоследовательно, если в созданном шрифте нет части нужных знаков. При тестировании просмотрите не только заглавные русские буквы, но и ё, кавычки, тире, скобки, цифры, знак процента, валютные символы и латинские фрагменты вроде названия модели. Когда приложение подставляет отсутствующий глиф из другой гарнитуры, рядом могут неожиданно отличаться форма, высота или насыщенность букв.

Составьте несколько коротких контрольных фраз из реального интерфейса: заголовок, кнопку, цену или статус. Ищите пустые квадраты, подмену символа, обрезанный диакритический знак и резкий переход между почерком и системной гарнитурой. Затем прочитайте те же строки экранным диктором: внешний вид и произношение проверяются отдельно, один тест не заменяет другой.

Если рукописное начертание не содержит каждого знака, ограничьте его коротким выражением, набор символов которого вы проверили, а рядом оставьте основной системный текст. Не пытайтесь компенсировать отсутствующие символы изображением целой фразы: так вы усложните масштабирование, локализацию и озвучивание.

Возьмите экран, где рукописный акцент соседствует с обычным текстом и действием: например, приветствие, пояснение и кнопка. Добавьте также один нестандартный элемент, если он есть. Так вы проверите не абстрактную страницу, а реальный путь пользователя.

Включите VoiceOver на iPhone или TalkBack на Android и двигайтесь по экрану последовательно. Слушайте название каждого элемента, его тип и состояние. Убедитесь, что подсказка не повторяет название, декоративная строка не пропала, а нажатие кнопки приводит к ожидаемому следующему шагу.

Измените размер текста в настройках доступности и повторите проход. Проверьте, не обрезался ли заголовок, не перекрыли ли друг друга строки, не уехала ли кнопка за границу карточки и остаётся ли понятен порядок чтения. Проверьте более жирное системное отображение там, где платформа его предлагает: тонкий штрих рукописной гарнитуры может хуже различаться.

Подставьте длинную локализованную строку, имя пользователя, ошибку и состояние с числом. Повторите тест хотя бы на одном небольшом экране. Экранный диктор должен произнести строку так, чтобы смысл не зависел от визуального украшения; визуальная верстка должна выдерживать длину без пропажи действия.

Если чтение непонятно, сначала поправьте текст, роль, состояние или порядок обхода. Не заменяйте весь экран одной длинной accessibility-подписью и не скрывайте важные слова от вспомогательных технологий ради чистого вида. После исправления снова проверьте управление жестами и фокусом.

Обычно нет: стандартная текстовая метка уже предоставляет своё содержимое экранному диктору. Сначала проверьте её в VoiceOver и TalkBack. Добавляйте отдельное название только тогда, когда текст не объясняет назначение элемента или интерфейс построен на нестандартном контроле.

Как правило, да, если это настоящий текст в доступном компоненте. Экранный диктор использует строку и семантику элемента, а не распознаёт форму каждой буквы на картинке. Растровая надпись требует отдельного текстового эквивалента.

Нет. Визуально понятная надпись может не иметь роли или состояния для вспомогательных технологий, особенно если это собственный компонент. Проверяйте не только рисунок, но и озвучиваемое имя, тип, состояние и порядок навигации.

Если надпись передаёт важную информацию, предусмотрите увеличение и проверьте, что компоновка выдерживает его. Если это чисто декоративный орнамент, не превращайте его в отдельное текстовое сообщение диктора и не позволяйте ему мешать основному содержимому.

Для основного интерфейсного текста обычно надёжнее сохранить привычное системное поведение и системные настройки. Пользовательскую гарнитуру применяйте там, где она помогает характеру продукта, и отдельно проверьте масштабирование, начертания, локализацию и читаемость.

Нет, если приложение выпускается и для Android. VoiceOver и TalkBack опираются на разные платформенные компоненты, поэтому проверьте оба сценария на реальных экранах. Общий чек-лист полезен, но исправления семантики нужно выполнять средствами соответствующей платформы.

Посмотрите, не добавили ли вы accessibility-подпись, повторяющую видимую строку, или не открыли ли одновременно родительский контейнер и все дочерние элементы. Исправьте избыточную семантику и снова проверьте порядок фокуса.

Рукописная гарнитура может быть частью мобильного интерфейса, если украшение не подменяет текст, а нестандартные элементы сохраняют понятную семантику. Проверьте масштабирование и реальное озвучивание на iOS и Android до публикации. Если хотите превратить собственный почерк в шрифт, подготовьте его в Fontgenerator и испытывайте именно в тех строках приложения, где он будет использоваться.

Документация платформ: Apple — Adding a custom font to your app (https://developer.apple.com/documentation/uikit/adding-a-custom-font-to-your-app?language=objc), Supporting VoiceOver in your app (https://developer.apple.com/documentation/uikit/supporting-voiceover-in-your-app?language=objc); Android — Semantics in Compose (https://developer.android.com/develop/ui/compose/accessibility/semantics), Make apps more accessible (https://developer.android.com/guide/topics/ui/accessibility/apps).