Проектирование для доступности: огласка и динамический тип в Ios

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

Понимание VoiceOver

VoiceOver - это встроенный считыватель экрана в iOS, который считывает вслух все, что появляется на экране - кнопки, метки, изображения, слайдеры и даже изменения текста. Он позволяет пользователям с нарушениями зрения перемещаться по приложениям и веб-сайтам, используя богатый набор жестов и устной обратной связи. Когда пользователь касается или перетаскивает палец через экран, VoiceOver описывает элемент под пальцем. Двойное нажатие в любом месте на выбранный элемент активирует его, в то время как трехпалец прокручивает контент. Эта модель взаимодействия на основе жестов является мощной, но она возлагает тяжелое бремя на разработчиков, чтобы обеспечить точные и полные метаданные доступности.

VoiceOver полагается на API доступности (UIAccessibility) для извлечения информации об элементах на экране. Каждый контроль UIKit — , , и пользовательские представления — может обнажать ярлыки доступности, черты, подсказки и пользовательские действия. Если они отсутствуют или плохо проработаны, считыватель экрана либо проигнорирует элемент, либо представит его запутанным образом, эффективно делая части вашего приложения непригодными для использования.

При проектировании VoiceOver разработчики должны убедиться, что все интерактивные элементы правильно помечены и доступны через API-интерфейсы доступности. Это включает в себя не только нативные элементы управления, но и пользовательские интерфейсы, распознаватели жестов и динамический контент. Распространенной ошибкой является предположение, что метки по умолчанию из текстового контента будут достаточными. VoiceOver может читать основной тип управления или необработанный идентификатор, что редко полезно. Всегда предоставляйте явные, читаемые человеком метки.

Ключевые черты доступности

iOS предоставляет набор признаков доступности , которые информируют VoiceOver о поведении элемента.

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

Подсказки и пользовательские действия

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

Для элементов, поддерживающих несколько действий (например, ячейку таблицы, которую можно прокрутить, чтобы выявить кнопки удаления, совместного использования и скрытия), используйте обычные действия . VoiceOver объявляет количество доступных действий и позволяет пользователю выполнять их, прокручивая вверх или вниз в специальном роторе. Внедрение пользовательских действий делает сложные взаимодействия доступными, не заставляя пользователей выполнять физические прокрутки, которые могут быть не обнаружены.

Поддержка VoiceOver

Для эффективной поддержки VoiceOver рассмотрим следующие лучшие практики. Это не просто руководящие принципы — они необходимы для прохождения аудитов доступности и создания справедливого опыта.

  1. Используйте описательные метки для кнопок, ссылок и элементов управления. Кнопка с надписью «Сохранить» приемлема; лучше «Сохранить документ» или «Сохранить черновик». Избегайте общих меток, таких как «Кнопка» или «Предмет 1». Для значков без видимого текста установите ярлык доступности для описания действия, например, «Добавить новый контакт» для значка плюс.
  2. Убедитесь, что все изображения имеют значимый альтернативный текст. Декоративные изображения, которые не передают информацию, должны быть помечены как , поэтому VoiceOver игнорирует их. Информативные изображения, такие как диаграмма или фотография продукта, нуждаются в кратком описании. Не забудьте обновить изображения в и .
  3. Проверяйте навигацию с помощью жестов VoiceOver для выявления потенциальных проблем. Включите VoiceOver в настройках → Доступность → VoiceOver и попробуйте выполнить все основные задачи в приложении, не глядя на экран. Обратите внимание на элементы, которые пропущены, неправильно прочитаны или недоступны.
  4. Использовать признаки доступности для определения назначения элементов пользовательского интерфейса.Например, установить на заголовки разделов и на настраиваемые элементы.
  5. Элементы, связанные с группой , использующие виды контейнеров с и комбинированной этикеткой. Например, карта, показывающая изображение продукта, имя и цену, должна быть одним доступным элементом с этикеткой, такой как «Беспроводные наушники, $79,99».
  6. Уведомления о доступности, когда контент динамически меняется. Используйте , чтобы сфокусировать VoiceOver на обновленном контенте, таком как новое сообщение в чате или модаль, которая появляется.
  7. Избегайте полагаться исключительно на цвет или визуальные сигналы для передачи состояния. Пользователи VoiceOver не могут видеть красные границы ошибок. Всегда сочетайте визуальные индикаторы с текстом, символами или чертами, такими как .
  8. Поддержка ротора доступности при необходимости. Например, если ваше приложение включает в себя ползунок для объема, реализуйте Отрегулированный признак и обнажайте действия приращения и убывания через ротор.

Обычные ошибки VoiceOver

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

  • Сверхвложенные доступные элементы: Если родительское представление доступно, а его дети также доступны, VoiceOver объявит родителя, а затем каждого ребенка, что приведет к избыточности и путанице.
  • Неправильно обработанные прокрутки : VoiceOver зависит от размера прокрутки просмотра контента. Если размер контента не установлен правильно, VoiceOver может не прокручивать все элементы.
  • Отсутствующие идентификаторы доступности: Хотя идентификатор доступности (] в основном предназначен для автоматизированного тестирования, он не должен использоваться в качестве ярлыка для VoiceOver.
  • Игнорирование команд клавиатуры: Некоторые пользователи объединяют VoiceOver с внешней клавиатурой. Убедитесь, что ваше приложение реагирует на общие сочетания клавиш (например, Cmd+S for Save) и что эти действия можно обнаружить с помощью ротора доступности.

Понимание динамического типа

Dynamic Type позволяет пользователям настраивать размер текста по всей системе приложений iOS, улучшая читаемость и комфорт для людей с низким зрением, пресбиопией или просто тех, кто предпочитает больший текст. Когда пользователь настраивает размер текста в настройках → Display & Brightness → Text Size или использует ярлык доступности, любое приложение, которое поддерживает Dynamic Type, автоматически масштабирует свой текст. Это не просто вопрос использования другого размера шрифта; это требует гибкого макета, который может вместить изменения высоты строки, усечение и даже различные веса шрифта при экстремальных размерах.

Dynamic Type построен на концепции стилей текста, определенных . iOS предоставляет набор предопределенных стилей: , , , , , , , и т. д. Каждый стиль отображается в зависимости от размера и веса предпочитаемого контента пользователя (от дополнительных малых до дополнительных больших плюс размеры доступности). При использовании этих стилей текста система автоматически обрабатывает масштабирование. Использование жестко закодированных размеров шрифтов нарушает эту систему и может сделать текст нечитаемым или вызвать вырезку макета для пользователей, которым нужен больший тип.

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

Категории размеров контента

iOS определяет несколько уровней размера текста, начиная от XS (дополнительно маленький) до XXXL (дополнительно сверхбольшой). Категории размера доступности (больше, чем AX1) разработаны специально для пользователей с нарушениями зрения и могут производить очень большой текст — иногда превышающий 50 баллов для текста тела. При этих экстремальных размерах даже тщательно разработанные макеты могут сломаться, если не протестированы. Инспектор доступности Xcode включает в себя симулятор динамического типа, который позволяет просматривать ваше приложение в каждой категории размера без изменения настроек устройства.

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

Реализация динамического типа

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

  1. Использовать стили текста, которые автоматически адаптируются к настройкам пользователя, такие как , и т. д. В Interface Builder можно установить шрифт в текстовый стиль в Attributes Inspector.В коде использовать .
  2. Избегайте фиксированных размеров шрифтов ; вместо этого полагайтесь на масштабируемые шрифты.Если вы используете пользовательский шрифт, зарегистрируйте его, а затем создайте его с , чтобы применить ту же кривую масштабирования, что и системные шрифты.
  3. Проверьте свое приложение с различными настройками размера текста в опциях доступности. Перейдите в Настройки → Доступность → Дисплей и размер текста → Большой текст для обеспечения размеров доступности. Затем пройдите через каждый экран в вашем приложении, уделяя особое внимание кнопкам, которые обрезаются, изображениям, перекрывающимся и усечению текста.
  4. Убедитесь, что ваш макет остается гибким и читаемым при любых размерах. Используйте ограничения автозаполнения, которые адаптируются к размеру контента, а не к фиксированной ширине. Например, метка должна иметь ограничения на ее супервью, а не фиксированную ширину, чтобы она могла расти и обертываться. Используйте , чтобы разрешить многострочный текст.
  5. Динамично отрегулировать высоту строки и расстояние между абзацами. Высота строк по умолчанию для текстовых стилей является подходящей, но если вы используете атрибутированные строки, убедитесь, что вы установили относительно размера шрифта. Избегайте абсолютных значений точек.
  6. Использовать для пользовательских шрифтов: гарантирует, что ваши шкалы шрифтов идентичны шрифту корпуса системы. также можно использовать для масштабирования констант, таких как поля или радиусы угла пропорционально.
  7. Для изображений или значков, которые сопровождают текст , рассмотрите возможность предоставления нескольких разрешений или использования SVG, чтобы они масштабировались без пикселизации. Иконка, которая находится рядом с ярлыком, может потребоваться для роста, когда текст растет. Вы можете использовать каталоги активов с изображениями, специфичными по размеру, или масштабировать изображения, используя с масштабированием текста.
  8. Обновление макетов при изменении динамического типа во время выполнения . Зарегистрируйте уведомление , чтобы аннулировать макет и пересчитать размеры. При использовании система автоматически вызывает обновление сбора признаков; однако пользовательские представления могут нуждаться в явной обработке.

Динамический тип обработки в представлениях таблиц и представлениях коллекции

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

Размеры доступности и производительность

При размерах доступности текст может стать очень большим, а одна ячейка может содержать всего несколько слов. В приложениях чата или новостных лентах это приемлемо и ожидаемо. Однако в энергоемких сетках (например, просмотр календарного месяца) масштабирование текста может нарушить макет. В таких случаях вы можете выбрать ограничение максимального размера текста для этого конкретного вида или предоставить альтернативную компактную макет. Будьте прозрачны: если вы намеренно ограничиваете масштабирование, документируйте, что это прагматичный выбор дизайна, но постарайтесь его избежать. Цель состоит в том, чтобы уважать предпочтения пользователя, а не переопределять его.

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

Доступность вне VoiceOver и динамический тип

Хотя VoiceOver и Dynamic Type являются двумя наиболее эффективными функциями доступности в iOS, они не единственные.

  • Switch Control — для пользователей с ограниченным управлением двигателем.
  • AssistiveTouch — виртуальные кнопки и жесты для пользователей, которые не могут выполнять определённые физические движения.
  • Управление голосом — полная голосовая навигация (отличается от VoiceOver).
  • Уменьшить движение — для пользователей, чувствительных к анимации.
  • Увеличить контраст и Кнопочные формы — для лучшей визуальной ясности.
  • Закрытые подписи и Аудио-описания — для медиаконтента.

Каждая из этих функций взаимодействует с вашим приложением определенным образом. Например, элементы, которые поддерживают пользовательские действия в VoiceOver, также работают с Switch Control. Обеспечение того, чтобы каждый интерактивный элемент был полноразмерной сенсорной мишенью (по крайней мере, 44x44 точки), приносит пользу всем пользователям, особенно тем, у кого есть нарушения моторики. Проектирование с доступностью с самого начала означает, что ваше приложение будет хорошо работать со всеми этими вспомогательными технологиями, а не только с VoiceOver и Dynamic Type.

Заключение

Проектирование с учетом доступности не только приносит пользу пользователям с нарушениями, но и улучшает общий пользовательский опыт для всех. Такие функции, как VoiceOver и Dynamic Type, являются зрелыми, хорошо документированными и относительно простыми для реализации, как только вы понимаете базовые API. Интегрируя поддержку VoiceOver с надлежащими ярлыками, чертами и пользовательскими действиями, а также путем принятия Dynamic Type с помощью масштабируемых шрифтов и гибких макетов, разработчики могут создавать более инклюзивные и адаптируемые приложения iOS, которые охватывают более широкую аудиторию. Доступность не является переключателем функций - это философия дизайна, которая уважает человеческое разнообразие. Каждое приложение, которое охватывает его, становится инструментом расширения возможностей для всех пользователей, независимо от их способностей.

Для дальнейшего чтения, обратитесь к Руководству Apple по человеческому интерфейсу по доступности , документации Динамичный тип , Ресурсы разработчика и W3C Руководство по доступности веб-контента (WCAG) 2.2 для базовых стандартов, которые применяются и к мобильным приложениям.