В приложении делали меню в строке macOS: кнопки с иконками, выпадающий выбор времени напоминания, подсказки горячих клавиш вроде ⌘S и ⌘Q.
Визуально всё аккуратно. Но для VoiceOver такая полировка легко превращается в шум или пустоту.
Что нашли в PR:
• Picker «Notify me» визуально имел подпись, но из-за
.labelsHidden() сам контрол оставался без понятного контекста для VoiceOver. Исправили отдельным accessibilityLabel("Notify me").• Заголовок «NOTIFICATIONS» сделали настоящим ориентиром для VoiceOver через
.accessibilityAddTraits(.isHeader).• Текстовые подсказки «⌘S» и «⌘Q» спрятали от экранного диктора: сами шорткаты уже подключены через
.keyboardShortcut, а чтение символов вслух только мешает.Отдельно проверили контраст скриптом. Там нашлась важная деталь: часть системных цветов Apple не проходит 4.5:1 для обычного текста в некоторых состояниях. Команда оставила их как есть, потому что это нативные semantic colors macOS, и переопределение могло бы сделать приложение менее похожим на остальную систему.
Но две проверки остались ручными: живой проход VoiceOver по popover и проверка крупного системного текста / Dynamic Type без обрезки и наложений.
Вывод простой: доступность нативного интерфейса не заканчивается на «у нас стандартные контролы». Нужно пройти реальный путь:
• что слышит VoiceOver у каждого контрола;
• не читаются ли декоративные символы как полезная информация;
• остаётся ли интерфейс usable при крупном тексте;
• не заменяет ли скрипт контраста живую проверку с ассистивной технологией.
Особенно это касается маленьких popover-меню: там мало места, и одна безымянная кнопка или обрезанный текст быстро ломают весь сценарий.