Apple отдельно публикует критерии как минимум для VoiceOver, Voice Control и крупного текста, а также связывает оценку с реальными задачами пользователя: критерии VoiceOver, Voice Control и Larger Text. Поэтому Accessibility Nutrition Labels нельзя заполнять по списку подключённых API: если пользователь не может пройти вход, покупку, настройку и основное действие, поддержку заявлять нельзя.

План на эту неделю: сначала составьте матрицу задач по каждому семейству устройств, затем проведите отдельные проверки VoiceOver и Voice Control, сохраните неудачные пути и только после исправлений переносите выводы в App Store Connect. Непроверенный проект лучше оставить без соответствующей метки, чем публиковать заявление, которое не подтверждается реальным использованием.

Эта статья предназначена независимым разработчикам, которые впервые готовят Accessibility Nutrition Labels и не уверены в критериях Apple. Она также пригодится небольшой команде, поддерживающей iPhone, iPad или Mac, и разработчикам, которым нужен воспроизводимый удалённый macOS-тест вместо постоянно занятого локального устройства.

01

Сначала отделите кодовую поддержку от результата для пользователя

Наличие accessibilityLabel, accessibilityHint, SwiftUI-модификаторов или системных компонентов не доказывает, что приложение доступно в смысле декларации. Код может содержать правильные свойства, но пользователь всё равно столкнётся с недоступной кнопкой покупки, неверным порядком фокуса или модальным окном, из которого невозможно выйти.

Для каждого заявления нужно различать четыре уровня:

  1. функция предусмотрена в коде;
  2. отдельный экран можно пройти в тестовой демонстрации;
  3. вся обычная задача пользователя завершается без недоступного участка;
  4. результат соответствует заявлению в App Store Connect для конкретного семейства устройств.

Только четвёртый уровень является основанием для заполнения метки. Такой подход соответствует обзору Accessibility Nutrition Labels и модели оценки по типовым задачам.

В качестве минимального набора задач следует зафиксировать:

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

Если приложение не требует аккаунта или покупки, такие пункты помечаются как неприменимые с объяснением. Их нельзя просто удалить из тестового плана: иначе через некоторое время команда перестанет понимать, почему определённая метка не была выбрана.

02

Матрица приёмки показывает, что именно можно заявить

Одного общего результата «доступность проверена» недостаточно. Для каждого признака нужны объект проверки, доказательство, критерий прохождения и решение по декларации.

Метрика Что проверять Доказательство Решение при сбое
VoiceOver Фокус, имя, роль, состояние, значение, порядок перехода и завершение обычной задачи Запись маршрута, список дефектов, снимки экрана Не заявлять поддержку, если критический путь не завершается
Voice Control Голосовые команды для стандартных и пользовательских элементов, закрытие окон, восстановление после ошибки Таблица команд и результатов отдельно от VoiceOver Не переносить результат VoiceOver автоматически
Крупный текст Переполнение, обрезание, перекрытие, прокрутка и доступность действий Скриншоты при системных настройках текста, список экранов Не заявлять, если текст скрывает данные или действие
Тёмный интерфейс и цвет Контраст, различимость без цвета, состояние элементов в реальном маршруте Снимки экранов и описание проверенных состояний Исправить интерфейс либо ограничить заявление
Уменьшение движения Переходы, автопроигрывание, параллакс и обязательные действия при отключённой анимации Видео или журнал сценария Не заявлять, если движение блокирует понимание или управление
Субтитры Видео и аудио, необходимые для выполнения задачи, язык, синхронизация и полнота Список медиаматериалов, скриншоты и языковые варианты Не отмечать при непокрытом основном медиамаршруте
Аудиоописания Визуально значимая информация в видео и наличие описания там, где оно необходимо Таблица контента и состояния воспроизведения Не отмечать при пропуске ключевого визуального содержания

Эта таблица не заменяет официальные пороги. При спорной ситуации критерий нужно сверять с актуальной страницей Apple, а не с внутренним соглашением команды. Например, для крупного текста важна не сама интеграция Dynamic Type, а то, остаются ли содержание и действия доступными при увеличении текста. Официальные условия приведены в критериях Larger Text.

03

VoiceOver и Voice Control проверяются как разные способы взаимодействия

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

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

Особое внимание нужно уделить кастомным контролам. Системная кнопка может работать корректно, тогда как собственный компонент на основе жеста окажется невидимым для VoiceOver или будет объявлять устаревшее состояние. Аналогичная проблема возникает с нижними листами, всплывающими подсказками, drag-and-drop, каруселями и элементами, которые появляются после сетевого ответа.

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

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

Пример рабочего журнала можно хранить в репозитории рядом с задачей релиза:

Задача: покупка месячного плана
Платформа: iPhone
VoiceOver: не пройдено
Причина: кнопка подтверждения не получает фокус после закрытия диалога оплаты
Voice Control: не проверено
Решение: не заявлять поддержку до исправления и повторной проверки
Доказательства: vo-purchase-01.mov, vo-purchase-01.png

После исправления запись не следует заменять одной фразой «готово». Нужны дата теста, версия сборки, устройство или симулятор, настройки доступности и повторный результат.

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

04

Текст, цвет и движение оцениваются внутри обычного маршрута

Проверка крупного текста должна проходить на экранах, которые пользователь действительно посещает. Увеличьте системный размер текста и пройдите вход, поиск, просмотр результата, покупку и настройки. Фиксируйте не только переполнение заголовков, но и:

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

Тёмный интерфейс проверяется тем же маршрутом, а не отдельным красивым экраном. Цвет не должен быть единственным способом отличить ошибку от успеха, выбранный элемент от невыбранного или доступный статус от недоступного. Эти принципы нужно сопоставлять с фактической компоновкой приложения.

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

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

05

Субтитры и аудиоописания применяются только к подходящему контенту

Наличие текстового описания в интерфейсе не означает наличие субтитров. Субтитры относятся к синхронизированной речи и значимым звукам в медиаматериале, тогда как обычный абзац рядом с кнопкой выполняет другую функцию.

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

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

Официальные критерии для такой проверки находятся на страницах Captions и Audio Descriptions. Аудиоописание нужно оценивать не по наличию расшифровки, а по тому, получает ли пользователь значимую визуальную информацию во время воспроизведения.

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

06

Каждое семейство устройств получает собственный вывод

Нельзя копировать результат с iPhone на iPad или Mac. Отличаются размер и ориентация экрана, клавиатурный ввод, указатель, меню, панели, системные контролы и поведение модальных окон. Даже при общем коде пользовательская задача может стать недоступной из-за другой компоновки.

Для каждого семейства устройств создайте отдельную строку матрицы:

Семейство: iPad
Сборка: 1.8.0 (204)
Задачи: запуск, вход, поиск, покупка, настройки
VoiceOver: пройдено 4 из 5
Voice Control: пройдено 5 из 5
Крупный текст: не пройдено — кнопка подтверждения перекрывается
Итог: метку крупного текста не заявлять

Неприменимую метку нужно обосновать: например, в приложении нет медиаконтента, необходимого для выполнения задачи. Но нельзя объявлять iPad-версию эквивалентной iPhone-версии только потому, что тестировалась одна и та же ветка исходного кода.

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

Для повторяемой подготовки среды полезно отделить графическую проверку от командной сборки:

xcodebuild \
  -workspace SampleApp.xcworkspace \
  -scheme SampleApp \
  -configuration Debug \
  -destination 'platform=iOS Simulator,name=iPhone 16' \
  build

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

07

Доказательственный пакет защищает от ошибочной публикации

Перед заполнением Accessibility Nutrition Labels соберите пакет, который другой участник команды сможет проверить без устных пояснений:

  1. список обычных задач и критериев завершения;
  2. перечень платформ и версий сборки;
  3. настройки VoiceOver, Voice Control, текста, цвета и движения;
  4. результаты по каждой задаче;
  5. видео или снимки неудачных маршрутов;
  6. ссылки на исправления и повторные тесты;
  7. итоговое решение по каждой метке;
  8. подтверждение, что проверялась именно публикуемая сборка.

Имя приложения, Bundle ID, аккаунты, тестовые пользователи, адреса и снимки с персональными данными должны быть обезличены в материалах для внешнего обмена. Внутреннее хранилище может содержать дополнительные сведения, но доступ к нему следует ограничить.

После сохранения декларации проверьте публичную карточку приложения и соответствие версии. Если метка не отображается сразу, не меняйте заявление вслепую и не создавайте дубликат. Сначала проверьте статус в App Store Connect и текущие инструкции в разделе управления Accessibility Nutrition Labels. Для автоматизированных процессов можно использовать API деклараций доступности, но автоматическая отправка данных не заменяет человеческую проверку задач.

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

08

Частые вопросы

Требуется ли уже обязательное заполнение меток

Сейчас нельзя утверждать, что существует единая дата, после которой любое приложение не примут без Accessibility Nutrition Labels. Официальная позиция описывает переход к обязательному предоставлению в будущем, но дата зависит от опубликованных требований App Store Connect. На практике это означает: не откладывайте подготовку матрицы, но не приписывайте Apple срок, которого нет в официальном источнике.

Нужно ли дублировать проверку для iPhone, iPad и Mac

Да, если приложение поддерживает несколько семейств устройств. Разные размеры, способы ввода и платформенные компоненты меняют выполнимость задачи. Для каждой платформы сохраняйте отдельный результат, даже если используется одна кодовая база. Метку нельзя переносить копированием: сначала сравните фактические маршруты и доступные варианты в текущем интерфейсе App Store Connect.

Какой маршрут VoiceOver считается достаточным

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

Почему сведения видны в App Store Connect, но не отображаются публично

Сохранение декларации в панели и её публичное отображение — разные этапы. Проверьте приложение, версию, статус обработки и фактическую карточку, не создавая повторную декларацию. Зафиксируйте время проверки, снимок экрана и идентификатор версии. Если расхождение сохраняется, используйте официальную процедуру управления метками, поскольку фиксированный срок появления не следует выводить из опыта одной команды.

09

Готовая проверка перед отправкой

Перед публикацией релиза ответственный разработчик должен подтвердить каждый пункт:

  • [ ] Основные пользовательские задачи перечислены, а не заменены списком API.
  • [ ] Отдельно проверены запуск, вход, основное действие, покупка или подписка, настройки и ошибка.
  • [ ] VoiceOver проверен на фокус, имя, роль, состояние, значение и порядок перехода.
  • [ ] Voice Control проверен отдельно, без переноса результата VoiceOver.
  • [ ] Кастомные элементы, жесты, диалоги и восстановление после ошибки включены в тест.
  • [ ] Крупный текст проверен на переполнение, перекрытие и прокрутку.
  • [ ] Тёмный интерфейс и различение без цвета проверены внутри обычных маршрутов.
  • [ ] Уменьшение движения проверено на переходах и обязательных состояниях.
  • [ ] Субтитры и аудиоописания заявляются только для действительно используемого медиаконтента.
  • [ ] iPhone, iPad и Mac имеют отдельные результаты там, где они поддерживаются.
  • [ ] Все неудачные пункты сохранены вместе с исправлением и повторной проверкой.
  • [ ] Метки соответствуют текущей публикуемой сборке, а не ветке разработки.
  • [ ] После публикации проверена публичная карточка приложения.

Если текущий вариант — локальный Mac с постоянно занятыми диском, симуляторами и тестовыми состояниями, у него есть несколько реальных ограничений: рабочая машина становится недоступной для других задач, окружение трудно воспроизвести после сбоя, а проверку разных платформ приходится вручную освобождать и перенастраивать. Временный облачный Mac не решает тестирование физических жестов, но для повторяемой сборки, хранения отдельных симуляторов и удалённой Accessibility Inspector-проверки может оказаться удобнее покупки отдельного компьютера. Поэтому при коротком релизном цикле разумно изучить справочные материалы NodeMini по удалённому Mac, создать изолированную среду на срок приёмки, завершить реальные задачи и только затем обновлять данные App Store Connect.