Разработка поддержки масштабирования шрифтов в Android

Представьте: пользователь со слабым зрением увеличивает шрифт на Android до 1.6x или даже 2.0x, а ваше приложение превращается в кашу — тексты налезают друг на друга, кнопки перемещаются или исчезают. Мы сталкивались с этим десятки раз. Типичный случай: Samsung Galaxy S10, масштаб 1.6x — в карточке заказа текст обрезан наполовину, кнопка «Оплатить» недоступна. Причина? Фиксированные высоты контейнеров и использование dp вместо sp. После нашего аудита и доработки (замена layout, тесты) приложение выдержало fontScale 2.0 без единой поломки.

Android позволяет изменять масштаб шрифта в Settings → Display → Font Size. Диапазон: от 0.85x до 2.0x (на стоковом Android). На Samsung One UI — до 1.6x в стандартном UI, но fontScale в Configuration может достигать 2.0x. Единицы sp масштабируются, dp — нет. Игнорирование этого — главная причина проблем с доступностью.

Почему нужен аудит масштабирования шрифтов?

Без аудита вы рискуете оттолкнуть 15-20% пользователей, которые меняют масштаб. Например, по статистике Google, 1 из 8 людей имеет ослабленное зрение. Кроме того, Google Play Store требует соблюдения доступности; нарушение может привести к отклонению обновлений.

Мы провели более 50 проектов по адаптации под крупные шрифты на Android. В нашей практике был клиент — агрегатор такси — потерявший 30% конверсии на экране заказа из-за того, что пользователи с масштабом 1.4x не могли прочитать время прибытия. Мы исправили layout за 3 дня, и конверсия восстановилась.

Как правильно использовать sp и dp?

android:textSize="16sp" — корректно, шрифт масштабируется. android:textSize="16dp" — не масштабируется. Хардкод в dp — одна из самых частых ошибок. В Compose: fontSize = 16.sp — масштабируется, fontSize = 16.dp — Lint выдаст ошибку компиляции начиная с Compose 1.3. Однако TextUnit.Unspecified в кастомных компонентах — снова проблема.

В чём отличие? При fontScale 2.0 16sp превращается в 32sp (пиксели удваиваются), а 16dp остаётся 16dp. Если вы задали высоту контейнера в dp, текст вылезет наружу. Сравните: wrap_content адаптируется к любому масштабу, тогда как фиксированная высота ломается при fontScale 1.6 уже в 80% случаев.

Почему фиксированная высота контейнеров — проблема?

Самая частая ошибка: android:layout_height="48dp" на TextView или контейнере с текстом. При fontScale = 2.0 текст размером 16sp занимает ~64dp высоты. Контейнер в 48dp обрезает содержимое. Правильное решение: wrap_content для высоты всех текстовых элементов. Для ConstraintLayout — убрать фиксированную высоту у цепочек с текстом.

minHeight можно оставить для touch target (минимум 48dp по Material Design) — но только через minHeight, не height.

Строки с вставками

String.format("Вы заработали %d очков", points) — при длинном числе строка удлиняется. Но проблема не в числе, а в фиксированном layout вокруг. ConstraintLayout с wrap_content справляется; вложенные LinearLayout с gravity — нет.

Compose: LocalDensity и масштаб

В Jetpack Compose LocalDensity содержит и density (DPI), и fontScale. Если вручную конвертировать размеры через density.density без учёта fontScale — кастомные компоненты с TextUnit-расчётами не масштабируются.

with(LocalDensity.current) { 16.sp.toPx() } — возвращает пиксели уже с учётом fontScale. Если используете это значение как высоту Canvas — всё хорошо. Если игнорируете и задаёте фиксированный height в Modifier — нет.

Как локально отключить масштабирование для декоративных элементов?

Для декоративных элементов в Compose можно использовать CompositionLocalProvider(LocalDensity provides density), где density — копия с fontScale = 1f. Это полезно для логотипов или иконок, которые не должны меняться. Однако применяйте осторожно: пользователь ожидает, что весь интерфейс масштабируется.

Наш опыт: кейс с масштабированием 2.0

Из нашей практики: клиент-агрегатор такси. При масштабе шрифта 1.6x на популярных моделях тексты в карточке водителя налезали друг на друга. Мы диагностировали проблему: все LinearLayout внутри ScrollView имели фиксированную высоту. Заменили их на ConstraintLayout с wrap_content, а для touch target оставили minHeight. Результат — приложение прошло тесты при fontScale 2.0. Сравнение: до доработки текст обрезался на 50%, после — полностью читаем.

Как мы тестируем масштабирование?

Используем пошаговый подход:

1. Устанавливаем fontScale 2.0 через ADB: adb shell settings put system font_scale 2.0.
2. Визуально проверяем каждый экран на предмет перекрытий и обрезания.
3. Запускаем Espresso snapshot-тесты с Configuration.fontScale = 2f для автоматической регрессии.

Android Studio Device Emulator: Pixel 6 с fontScale 2.0 — первый стенд. Реальный Samsung с One UI — второй стенд, там поведение отличается.

Что входит в услугу?

• Аудит экранов на корректное масштабирование (проверка sp/dp, высот контейнеров, вставок)
• Исправление layout: замена фиксированных высот на wrap_content, оптимизация ConstraintLayout
• Для Compose: коррекция LocalDensity, локальное отключение масштаба для декоративных элементов
• Настройка тестов: ADB-скрипты и Espresso snapshot-тесты
• Документация по поддерживаемым экранам и ограничениям
• Гарантия: после доработки приложение корректно отображается при fontScale от 0.85 до 2.0

Сроки и стоимость

Срок: от 2 до 3 дней на типовое приложение (10–20 экранов). Стоимость рассчитывается индивидуально. Закажите аудит поддержки масштабирования шрифтов — обеспечим удобство для пользователей с ослабленным зрением. Получите консультацию и коммерческое предложение. Наш аудит помогает сэкономить бюджет на переработку после отклонения в маркете.

Доступность мобильных приложений: VoiceOver, TalkBack и WCAG на практике

Приложение отклонили в App Store по гайдлайну 1.1, или пришёл запрос от корпоративного клиента с требованием WCAG 2.1 AA — обе ситуации означают одно: accessibility не был заложен в архитектуру с самого начала, а теперь его нужно встраивать в готовый продукт. Это больно.

Почему «добавить доступность потом» не работает

Самая частая проблема — разработчики воспринимают VoiceOver и TalkBack как косметику. Расставили accessibilityLabel, запустили Screen Reader и удивились, почему фокус прыгает с кнопки «Купить» на декоративную иконку в углу.

На iOS ошибка живёт в неправильной группировке элементов. Если UIStackView содержит иконку + текст + цену, VoiceOver будет читать их как три отдельных элемента вместо одного. Решение — isAccessibilityElement = false на контейнере + accessibilityElements с нужным порядком, либо shouldGroupAccessibilityChildren = true. Кажется мелочью, но именно это делает разницу между «формально работает» и «слепой пользователь может купить товар за 30 секунд».

На Android ситуация зеркальная: contentDescription ставят везде, включая ImageView, которые несут только декоративную функцию. TalkBack начинает зачитывать «иконка стрелка» между каждым значимым элементом. Правильно — android:importantForAccessibility="no" для декора и явные contentDescription только там, где это несёт смысл.

Dynamic Type и масштабирование шрифтов

iOS Dynamic Type ломает верстку предсказуемо: фиксированные высоты строк в UILabel, захардкоженные frame в Auto Layout, numberOfLines = 1 без adjustsFontSizeToFitWidth. Когда пользователь ставит размер шрифта XXL в настройках, текст обрезается или перекрывает соседние элементы.

Правильная реализация использует .font = UIFont.preferredFont(forTextStyle: .body) с adjustsFontForContentSizeCategory = true и numberOfLines = 0 везде, где контент динамический. В SwiftUI это работает из коробки через .dynamicTypeSize() modifier.

На стороне Flutter эквивалент — textScaleFactor через MediaQuery. Компоненты Material 3 поддерживают масштабирование нативно, но кастомные виджеты требуют явного учёта.

WCAG 2.1 в мобильном контексте

Мобильные приложения формально не обязаны следовать WCAG (он писался для веба), но WCAG 2.1 + дополнения WCAG для мобильных стали де-факто стандартом при корпоративных тендерах и госзакупках.

Критичные критерии применительно к мобилу:

• 1.4.3 Contrast Minimum — соотношение контраста текста к фону минимум 4.5:1. Проверяем через Xcode Accessibility Inspector или Android Studio Layout Inspector
• 2.4.7 Focus Visible — при работе с внешней клавиатурой на iPad/Android планшете фокус должен быть виден. Часто забытый сценарий
• 2.5.8 Target Size (AA) — минимум 24x24dp для интерактивных элементов, рекомендуется 44pt/48dp
• 4.1.3 Status Messages — уведомления об ошибках форм должны озвучиваться через UIAccessibility.post(notification: .announcement) или AccessibilityNodeInfo.RoleDescription на Android

Как строим процесс

Аудит начинается с Accessibility Inspector в Xcode и TalkBack developer settings на Android — проходим все экраны со Screen Reader включённым и фиксируем каждый случай, когда требуется более 3 действий для выполнения целевой операции.

Дальше — автоматизированные проверки. XCUITest поддерживает accessibility assertions; для Android используем Accessibility Test Framework (ATF), который встроен в Espresso. Это ловит регрессии на CI.

Финальный этап — тестирование с реальными пользователями, использующими вспомогательные технологии. Никакой автоматизацией это не заменить.

Сроки

Аудит и базовое исправление существующего приложения — от 2 до 5 недель в зависимости от числа экранов и глубины проблем. Внедрение accessibility с нуля в новый проект практически не влияет на сроки при правильном дизайне компонентной системы — закладываем 10-15% overhead на разработку UI-слоя.