Ваше iOS-приложение не закончено, если им не может пользоваться незрячий: Гайд по Accessibility

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

---

Почему это важно (и почему вы ошибаетесь, если думаете иначе)

Давайте начнем с цифр, которые обычно игнорируют на спринт-планированиях. Согласно данным Всемирной организации здравоохранения (WHO), более 1,3 миллиарда человек - это около 16% населения мира - живут со значительной формой инвалидности. Источник: WHO, 2023.

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

С точки зрения бизнеса, игнорирование доступности - это добровольный отказ от огромного сегмента рынка. В США и Европе законодательные акты (такие как European Accessibility Act) уже делают инклюзивность обязательной для многих категорий ПО. Доступность - это не благотворительность. Это профессионализм и расширение вашей воронки продаж. Мы создаем технологии для людей, а не для «идеальных пользователей» с 100% зрением и идеальной моторикой в вакууме.

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

Часть 1. Фундаментальные основы, которые должен знать каждый Junior

Прежде чем переходить к «магии», убедитесь, что ваш фундамент не трещит по швам.

1.1. VoiceOver - король доступности

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

Многие ограничиваются простым accessibilityLabel, но этого мало. Чтобы интерфейс «зазвучал» правильно, нужно использовать всю триаду:

let checkoutButton = UIButton()
// 1. Что это? (Существительное)
checkoutButton.accessibilityLabel = "Оформить заказ" 

// 2. Что произойдет? (Глагол)
checkoutButton.accessibilityHint = "Списывает средства с карты и создает заявку на доставку" 

// 3. Какова роль? (Состояние)
checkoutButton.accessibilityTraits = [.button, .playsSound] 

accessibilityLabel - имя объекта

accessibilityLabel - это фундамент. Это короткое, емкое существительное, которое сообщает, что перед нами.

• Главное правило: Краткость. Не нужно описывать детали дизайна (например, «Зеленая круглая кнопка»).

• Ошибка: Оставлять пустые лейблы для иконок. Если у кнопки поиска стоит только изображение magnifyingglass, VoiceOver прочитает «Button». Пользователь поймет, что кнопка есть, но не узнает, зачем она.

accessibilityTraits - роль и состояние

accessibilityTraits сообщает системе тип элемента и его текущее поведение. Это критически важно, так как VoiceOver добавляет специфические жесты или озвучку в зависимости от роли.

• Зачем это нужно: Когда вы указываете .button, система сама добавляет слово «Кнопка» в конце фразы. Если это .header, пользователь сможет быстро перемещаться между заголовками раздела.

• Динамика: Если кнопка «Избранное» нажата, добавьте трейт .selected. Пользователь услышит: «В избранное, кнопка, выбрано». Без этого он не поймет, сработал ли клик.

accessibilityHint - Контекст действия

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

• Когда использовать: Если действие ведет к списанию денег, открытию внешней ссылки или долгому процессу (например, «Начинает загрузку файла»).

• Важно: Опытные пользователи часто отключают подсказки в настройках iOS, чтобы ускорить навигацию. Поэтому никогда не помещайте критически важную информацию только в Hint. Label должен быть понятен и без него.

Никогда не включайте роль элемента в лейбл. Не пишите «Кнопка Оплатить». VoiceOver сам добавит слово «Кнопка», основываясь на traits. Иначе пользователь услышит: «Кнопка Оплатить, кнопка».

Проверять озвучку лучше всего на реальном устройстве, включив VoiceOver в настройках (Настройки -> Доступность). Симулятор не всегда передает реальный «ритм» речи диктора.

1.2. Dynamic Type: дайте людям масштаб

Многие разработчики ошибочно полагают, что доступность - это только для полностью незрячих людей. На самом деле, самая массовая аудитория «Accessibility» - это пользователи с нарушениями зрения (дальнозоркость, близорукость, астигматизм).

По статистике, более 25% пользователей iOS меняют системный размер шрифта. Если ваше приложение игнорирует эти настройки, используя жестко заданные fontSize: 16, вы буквально заставляете четверть своей аудитории щуриться или использовать лупу.

Как это работает «под капотом»

В iOS существует таблица семантических стилей (.body, .headline, .title1 и т.д.). Каждый стиль привязан к конкретному кеглю, который динамически меняется в зависимости от ползунка в настройках системы.

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

Важно: Если вы используете кастомные шрифты, используйте UIFontMetrics. Это обертка, которая заставляет ваш дизайнерский шрифт масштабироваться пропорционально системному .body или .title.

SwiftUI делает Dynamic Type стандартом «из коробки». Если вы используете .font(.body), всё будет работать само. Но если дизайн требует кастомный шрифт, не забывайте указывать relativeTo:

Здесь relativeTo: .title говорит системе: «Масштабируй этот текст так же активно, как ты масштабируешь заголовки».

Главные боли при внедрении и как их лечить

• Фиксированная высота контейнеров: это главная ошибка. Если у вас кнопка высотой ровно 44pt, то при увеличении шрифта текст просто вылезет за границы или обрежется.

Решение: Используйте Constraints (Auto Layout) без жесткой высоты или minHeight в SwiftUI. Дайте контенту растягивать контейнер.

• Многострочность: по умолчанию UILabel имеет numberOfLines = 1.

Решение: Всегда ставьте 0 для текстовых блоков, чтобы при увеличении шрифт переносился на новую строку, а не превращался в «Купите биле...».

• Иконки и картинки: Если текст вырос в 2 раза, а иконка рядом осталась крошечной, нарушается визуальный баланс.

Решение: Используйте SF Symbols. Они ведут себя как текст и масштабируются вместе с ним автоматически (подробнее об этом в следующем пункте)

// Swift UI
Text("Добро пожаловать")    
  .font(.custom("YourFont", size: 18, relativeTo: .body))    
  .dynamicTypeSize(...DynamicTypeSize.accessibility3)

// UIKit
label.font = UIFont.preferredFont(forTextStyle: .body)
label.adjustsFontForContentSizeCategory = true

Согласно Apple Documentation, использование preferredFont - это стандарт, который гарантирует, что ваш текст останется читаемым при любых настройках системы.

Золотое правило: Проверьте свое приложение на максимальном размере шрифта (Accessibility Sizes). Да, интерфейс станет выглядеть иначе, он будет «длинным», но он останется рабочим. Это и есть настоящая забота о пользователе.

1.3. Иконки, которые умеют «расти»

Если вы используете обычные PNG или SVG-иконки, при увеличении системного шрифта (Dynamic Type) они остаются маленькими «точками» рядом с огромными буквами. Это не только портит дизайн, но и мешает пользователям с плохим зрением считывать смысл интерфейса.

Почему SF Symbols - это стандарт доступности?

• Векторная природа: как и у шрифтов, у SF Symbols есть начертания: .ultraLight, .regular, .bold и другие. Если ваш текст жирный, иконка автоматически подстроится под него, сохраняя визуальный баланс.

• Автоматическое выравнивание: Иконки центрируются по базовой линии текста (Baseline). Вам не нужно высчитывать отступы пиксель в пиксель - система сделает это за вас.

• Адаптивность: При использовании Dynamic Type иконки SF Symbols масштабируются синхронно с текстом.

Как внедрить это правильно

В SwiftUI это работает максимально просто:

HStack {    
  Image(systemName: "heart.fill")    
  Text("Избранное")
}
.font(.body) // Иконка автоматически подстроится

В UIKit важно использовать конфигурации, чтобы иконка знала, на какой стиль текста ей ориентироваться:

// 1. Используйте SymbolConfiguration с textStyle
let config = UIImage.SymbolConfiguration(textStyle: .body)
imageView.image = UIImage(systemName: "heart.fill", withConfiguration: config)

// 2. Включите адаптацию размера
imageView.adjustsImageSizeForAccessibilityContentSizeCategory = true

// 3. Для текста тоже используйте Dynamic Type
label.font = .preferredFont(forTextStyle: .body)
label.adjustsFontForContentSizeCategory = true

Чтобы иконка в UIImageView знала, на какой стиль текста ей ориентироваться и динамически меняла размер при изменении настроек системы, используйте SymbolConfiguration.

Масштабирование иерархии

Начиная с iOS 15, SF Symbols поддерживают многоцветность и иерархию слоев. Это критично для доступности: вы можете выделить главный акцент иконки цветом, помогая пользователю быстрее распознать её смысл.

Если вы используете кастомные иконки, Apple рекомендует создавать их на основе шаблонов SF Symbols. Это гарантирует, что ваша уникальная иконка будет вести себя так же предсказуемо, как и системная.

1.4. Контраст и цветовые схемы

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

Правило №1. Цвет + Символ + Текст

Никогда не полагайтесь только на цвет для обозначения статуса. Если поле ввода заполнено неверно, недостаточно просто сделать его рамку красной.

• Ошибка: Красная рамка (пользователь с протанопией увидит её как темно-серую).

• Решение: Красная рамка + иконка ошибки ! + пояснительный текст.

// ПЛОХО: только красная рамка
textField.layer.borderColor = UIColor.systemRed.cgColor

// ХОРОШО: цвет + иконка + текст
textField.layer.borderColor = UIColor.systemRed.cgColor
errorIcon.image = UIImage(systemName: "exclamationmark.circle.fill")
errorLabel.text = "Некорректный формат email"

Правило №2. Магия чисел (4.5:1)

Существует стандарт WCAG (Web Content Accessibility Guidelines), который определяет минимальный коэффициент контрастности.

• 4.5:1 - минимум для обычного текста.

• 3:1 - для крупных заголовков и графических элементов (иконок).

Если ваш текст - светло-серый на белом фоне, вы буквально отрезаете часть аудитории. Проверить это можно прямо в Xcode через Accessibility Inspector (вкладка Color Contrast).

Программная адаптация под пользователя

iOS дает пользователю возможность включить режим «Увеличение контраста» в настройках. Ваше приложение должно уметь реагировать на это, перерисовывая интерфейс.

Для UIKit: Лучший способ - переопределить метод traitCollectionDidChange, чтобы изменения подхватывались мгновенно без перезагрузки экрана.

override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) {
  if traitCollection.accessibilityContrast == .high {        
    // Более контрастные цвета + границы    
  }
}

Для SwiftUI: В SwiftUI это решается еще элегантнее через обращение к переменным окружения (Environment).

@Environment(\.colorSchemeContrast) var contrast

var buttonBackground: Color {    
  contrast == .increased ? .blue : .blue.opacity(0.8)
}

Смарт-инверсия (Smart Invert)

Многие пользователи с повышенной чувствительностью к свету используют инверсию цветов. В отличие от темной темы, она просто переворачивает цвета.

• Совет: Если в вашем приложении есть фотографии или обложки альбомов, используйте свойство accessibilityIgnoresInvertColors = true для этих элементов. Это предотвратит превращение лиц людей в «рентгеновские снимки», оставив интерфейс инвертированным, а контент - естественным.

// UIKit
profileImageView.accessibilityIgnoresInvertColors = true

// SwiftUI
Image("photo")    
  .accessibilityIgnoresInvertColors(true)

Часть 2. Продвинутые техники (то, что требует инженерного подхода)

Если VoiceOver - это база, то следующие технологии - это то, как люди с моторными и сенсорными нарушениями физически взаимодействуют с вашим кодом.

2.1. Switch Control: навигация без касаний

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

Представьте, что вы управляете телефоном с помощью пульта от телевизора, где есть только кнопки «Далее» и «Ок». Если ваш интерфейс - это хаос из вложенных View, пользователь потратит 10 минут, просто чтобы «прокликать» до нужной кнопки внизу экрана.

Правило №1. Логический порядок (Linearity)

По умолчанию система сканирует экран слева направо и сверху вниз. Но в сложных интерфейсах (например, с каруселями или модальными окнами) этот порядок ломается. Вы должны вручную «проложить рельсы» для курсора.

В UIKit мы используем массив accessibilityElements, который жестко задает последовательность фокуса:

override func viewDidLoad() {    
  super.viewDidLoad()        
  
  view.accessibilityElements = [        
    backButton,        
    avatarView,        
    nameLabel,        
    followButton,        
    messageButton    
  ]
}

В SwiftUI порядок управляется модификатором .accessibilitySortPriority(_:):

VStack {    
  Button("Назад") { }        
    .accessibilitySortPriority(3) 
  
  Image("avatar")        
  .accessibilitySortPriority(2)        
  
  Button("Подписаться") { }        
    .accessibilitySortPriority(1)
}

Правило №2. Управление фокусом при событиях

Самая частая боль пользователя Switch Control - когда после нажатия на кнопку открывается поп-ап, а фокус остается «висеть» где-то на заднем плане. Пользователь оказывается в ловушке: он не может взаимодействовать с новым окном.

Для решения этой задачи мы используем уведомления системы:

UIKit: Перемещение фокуса на алерт

func showAlert() {    
  let alert = UIAlertController(title: "Подтвердите действие",
                                message: "Вы уверены?",
                                preferredStyle: .alert)        
  
  present(alert, animated: true) {        
    UIAccessibility.post(notification: .screenChanged,
                         argument: alert.view)    
  }
}

UIKit: Фокус на новый элемент после загрузки

func loadMorePosts() {    
  tableView.reloadData()        
  
  DispatchQueue.main.async {        
    if let cell = self.tableView.cellForRow(at: IndexPath(row: 0, section: 0)) {            
      UIAccessibility.post(notification: .screenChanged, argument: cell)        
    }    
  }
}

SwiftUI: AccessibilityFocusState (iOS 15+)

struct AlertView: View {    
  @State private var showAlert = false    
  @AccessibilityFocusState private var isFocused: Bool        
  
  var body: some View {        
    Button("Удалить") { showAlert = true }            
      .alert("Подтвердите действие", isPresented: $showAlert) { 
          Button("Удалить", role: .destructive) { }                    
            .accessibilityFocused($isFocused)            
      }            
      .onChange(of: showAlert) { if $0 { isFocused = true } }    
  }
}

SwiftUI: Фокус на текстовое поле при ошибке

struct LoginView: View {    
  @State private var username = ""    
  @AccessibilityFocusState private var isUsernameFocused: Bool        
  
  var body: some View {        
      VStack {            
        TextField("Имя пользователя", text: $username)                
          .accessibilityFocused($isUsernameFocused)                        
        
        Button("Войти") {                
          if username.isEmpty {                    
            isUsernameFocused = true // Возвращаем фокус                
          }            
        }        
      }    
  }
}

Группировка - спасение от бесконечных кликов

Если у вас в ленте 20 постов, и в каждом есть аватар, имя, дата, текст и лайк - пользователю придется нажать на кнопку переключателя 100 раз, чтобы просто пролистать ленту.

Решение: Группируйте связанные элементы.

UIKit: Группировка элементов поста

override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) {
  super.init(style: style, reuseIdentifier: reuseIdentifier)        
  
  isAccessibilityElement = true    
  accessibilityLabel = "Пост от Анна Иванова, 2 часа назад. Сегодня отличный день!"        
  accessibilityCustomActions = [        
    UIAccessibilityCustomAction(name: "Лайк") { _ in            
      self.toggleLike()            
      return true        
    },
    UIAccessibilityCustomAction(name: "Поделиться") { _ in
      self.share()            
      return true        
    }
  ]
}

SwiftUI: Группировка с кастомными действиями. В SwiftUI для этого есть .accessibilityElement(children: .combine):

VStack(alignment: .leading) {    
  HStack {        
    Image("avatar").clipShape(Circle())        
    Text("Анна Иванова")    
  }    
  Text("Сегодня отличный день для прогулки!")
}
  .accessibilityElement(children: .combine)
  .accessibilityLabel("Пост от Анна Иванова. Сегодня отличный день для прогулки!")
  .accessibilityActions {    
    Button("Лайк") { toggleLike() }    
    Button("Поделиться") { share() }
  }

Скрытие декоративных элементов

Декоративные элементы, не несущие смысловой нагрузки, должны быть скрыты от Switch Control:

SwiftUI:

VStack {    
  Rectangle()        
    .fill(LinearGradient(colors: [.blue, .purple], 
                         startPoint: .top, endPoint: .bottom))        
    .accessibilityHidden(true) // Скрываем декор       
  Text("Статистика за неделю")        
    .font(.title)

}

UIKit:

override init(frame: CGRect) {    
  super.init(frame: frame)        
  
  isAccessibilityElement = false    
  accessibilityElements = [header, statsCard, chartCard, actionsCard]
}

2.2. AssistiveTouch и кастомные жесты

Люди с ограниченной подвижностью часто используют AssistiveTouch для имитации сложных жестов (например, Pinch-to-zoom). Если ваше приложение завязано на нестандартных жестах (например, свайп тремя пальцами для удаления), вы обязаны предоставить альтернативу.

Используйте accessibilityCustomActions, чтобы добавить действия в контекстное меню системы:

let deleteAction = UIAccessibilityCustomAction(name: "Удалить сообщение") { _ in    
  self.deleteMessage()    
  return true
}
messageView.accessibilityCustomActions = [deleteAction]

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

2.3. Совместимость со слуховыми аппаратами (MFi)

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

import AVFoundation

func setupAudioForHearingAids() {    
  let session = AVAudioSession.sharedInstance()    
  do {        
    // Установка категории, поддерживающей Bluetooth-гарнитуры и слуховые аппараты        
    try session.setCategory(.playAndRecord, options: [.allowBluetoothA2DP, .allowBluetooth])        
    try session.setActive(true)    
  } catch {        
      print("Ошибка настройки аудио-сессии: \(error)")    
  }
}

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

Часть 3. Секретные фишки, о которых молчат туториалы

Здесь начинается магия - приемы, которые делают использование приложения бесшовным.

3.1. «Невидимая» навигация для слабовидящих

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

let hiddenStatusButton = UIButton()
// Элемент физически на экране, но полностью прозрачен
hiddenStatusButton.backgroundColor = .clear 
hiddenStatusButton.accessibilityLabel = "Текущий статус сервера: Стабилен"
// Мы не скрываем его через .isHidden = true, так как тогда его не найдет VoiceOver

Это позволяет «рассказать» незрячему пользователю о контексте, который зрячий считывает мгновенно (например, по цвету индикатора).

3.2. Когнитивная доступность через управление анимациями

Для людей с вестибулярными нарушениями или эпилепсией резкие анимации могут вызвать физическую боль или приступ. Apple предоставляет API для проверки системной настройки «Уменьшение движения».

Ваша обязанность - проверять этот флаг:

if UIAccessibility.isReduceMotionEnabled {    
  // Вместо вылетающей анимации используем простое появление (Fade-in)    
  UIView.transition(with: containerView, duration: 0.3, options: .transitionCrossDissolve, animations: {        
    self.showData()    
  })
} else {    
  // Стандартная «красивая» анимация    
  self.performComplexAnimation()
}

3.3. Перехват магических жестов (Magic Tap)

В iOS есть жест «двойное касание двумя пальцами» (Magic Tap). Он предназначен для самого важного действия на экране - ответить на звонок, остановить музыку или отправить сообщение.

Вы можете реализовать его в своем контроллере:

override func accessibilityPerformMagicTap() -> Bool {    
  // Например, запускаем или останавливаем таймер/плеер    
  self.toggleMainAction()    
  return true
}

Это невероятно удобная фишка, которой пользуются «продвинутые» пользователи VoiceOver, но которую реализуют меньше 1% разработчиков.

Мы подходим к самому тонкому льду. Большинство разработчиков считают, что доступност�� заканчивается на VoiceOver. Но инклюзивность - это еще и про то, как мозг обрабатывает информацию.

Часть 4. Экстремальные случаи, о чем почти никто не пишет

Здесь код встречается с нейробиологией. Мы адаптируем приложение для тех, чей мир воспринимается иначе.

4.1. Поддержка пользователей с эпилепсией и мигренью

Светочувствительная эпилепсия - это не шутки. Одно неудачное мерцание в баннере или «эффект стробоскопа» при переходе между экранами может вызвать приступ.

Apple ввела API для автоматической проверки видеоконтента на наличие вспышек, но как разработчик, вы должны контролировать свои кастомные анимации.

func checkForPhotosensitiveTriggers() {    
  // В iOS 17+ появилась системная настройка "Dim Flashing Lights"    
  // Мы можем проверить её программно (через медиа-запросы в SwiftUI или проверки в UIKit)    
  if UIAccessibility.isReduceMotionEnabled {        
    // Отключаем все высокочастотные анимации (более 3 вспышек в секунду)
    self.stopBlinkingAnimations()    
  }
}

4.2. Адаптация для пользователей с дислексией

Дислексия мешает мозгу быстро распознавать буквы. Исследования показывают, что специализированные шрифты (например, OpenDyslexic) с «утяжеленным» основанием букв помогают удерживать строку.

Хотя Apple не включает этот шрифт в систему по умолчанию, вы можете разрешить пользователю переключать шрифт в настройках вашего приложения:

// Регистрация кастомного шрифта для дислексиков
label.font = UIFont(name: "OpenDyslexic-Regular", size: 17) ?? .systemFont(ofSize: 17)

Интересный факт: По данным Dyslexia Center of Utah, до 20% населения имеют симптомы дислексии. Игнорировать их - значит терять каждого пятого читателя вашего лонгрида.

На этом сайте размещен замечательный пример того, как люди с дислексией могут видеть текст.

4.3. Тихий режим (Sensory Overload)

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

Реализация «спокойного режима»:

Swift

func enableQuietMode() {    
  // 1. Отключаем тактильную отдачу (Haptics)    
  // 2. Убираем лишние декоративные анимации    
  // 3. Упрощаем UI до текста и базовых кнопок    
  self.view.subviews.filter { $0 is DecorativeView }.forEach { $0.isHidden = true }
}

Часть 5: Тестирование и валидация

Этот раздел - мост между «я написал код» и «я уверен, что это работает». В мире Accessibility автоматизация покрывает лишь около 30–40% проблем, но именно эти проценты - самые раздражающие «детские болезни» интерфейса.

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

5.1. Ловим баги с помощью автоматизированных тестов:

Юнит-тесты на accessibilityLabel - это необходимый минимум, но они не гарантируют, что интерфейс удобен. Они гарантируют, что он не «пустой». Если вы используете Snapshot-тестирование, я крайне рекомендую библиотеку AccessibilitySnapshot. Она позволяет рендерить вьюхи так, как их «видит» система доступности, подсвечивая области фокуса.

Но настоящий стандарт - это XCUITest. Вы можете симулировать поведение пользователя VoiceOver:

func testExploreVoiceOverNavigation() {    
  let app = XCUIApplication()    
  app.launch()        
  
  // Проверяем, существует ли элемент с конкретным идентификатором доступности    
  let checkoutButton = app.buttons["checkout_button_identifier"]    
  XCTAssertTrue(checkoutButton.exists)        
  
  // Проверяем, что лейбл корректно озвучивается (важно для локализации)    
  XCTAssertEqual(checkoutButton.label, "Оформить заказ на сумму 500 рублей") 
  
  // Симулируем выбор элемента в режиме VoiceOver    
  checkoutButton.tap()
}

Согласно исследованиям Deque Systems, автоматизированные инструменты могут обнаруживать до 57% проблем WCAG (Web Content Accessibility Guidelines), но оставшиеся 43% требуют человеческого участия.

5.2. Accessibility Inspector - ваш «рентген» для UI

В Xcode скрыт мощнейший инструмент - Accessibility Inspector. Если вы его еще не открыли (Xcode -> Open Developer Tool -> Accessibility Inspector), сделайте это сейчас.

Три функции, которые спасут ваш проект:

1. Inspection: Наведите курсор на любой элемент в симуляторе, и инспектор покажет полную иерархию атрибутов. Вы увидите, где traits конфликтуют друг с другом.

2. Audit: Нажмите на иконку «Target» и выберите «Run Audit». Инспектор выдаст список предупреждений: «Слишком низкий контраст», «Отсутствует описание у изображения», «Малая область нажатия». Это самый быстрый способ починить 80% визуальных огрехов.

3. Settings: Прямо в инспекторе можно на лету переключать Dynamic Type или инверсию цвета, не заходя в настройки симулятора.

5.3. Ручное тестирование в режиме Screen Curtain

Ни один тест не заменит реальный опыт. Настоящий «хардкор» для разработчика - это включить Screen Curtain (Экранная завеса). Этот режим полностью выключает изображение на экране, оставляя только звук VoiceOver. Почувствуйте себя незрячим пользователем телефона - это чертовски тяжело.

• Как включить: Тройное касание тремя пальцами при включенном VoiceOver.

• Задача: Попробуйте дойти от главного экрана до подтверждения заказа вслепую.

Если вы запутались или застряли в бесконечном цикле навигации - ваш UX сломан. Обратите внимание на VoiceOver Rotor (жест поворота двумя пальцами, как будто крутите ручку радио). Это меню позволяет пользователю быстро перемещаться по заголовкам или ссылкам. Если в вашем приложении ротор показывает «Заголовки не найдены», значит, вы не настроили accessibilityTraits = .isHeader, и незрячий пользователь вынужден пролистывать каждый элемент вручную, вместо того чтобы прыгнуть к нужному разделу.

5.4. Математика контраста (для перфекционистов)

Если дизайнер настаивает на «стильном светло-сером тексте на белом фоне», покажите ему формулу относительной яркости. Контрастность C рассчитывается как:

C = \frac{L1 + 0.05}{L2 + 0.05}

где L1 - яркость более светлого цвета, а L2 - более темного. Для обычного текста значение C должно быть не менее 4.5, а для крупного - 3.0. Это не просто цифры, это физиологический порог читаемости для людей с нарушениями зрения. Калькулятор контрастности WebAIM - ваш лучший друг в спорах с дизайнером.

Что дальше? Теперь, когда мы разобрались с технической проверкой, пора поговорить о самом важном - об этике и о том, как превратить инклюзивность из «задачи в бэклоге» в философию команды.

Часть 6. Морально-этический блок

6.1. Доступность ≠ Милостыня

Часто разработчики относятся к доступности как к «доброму делу». Это токсичный подход. Доступность - это гражданское право.

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

6.2. Баланс между бизнесом и этикой

Как убедить менеджера потратить время на Accessibility?

1. SEO и охват: Доступный код лучше индексируется и понятнее системе.

2. Лояльность: Люди с инвалидностью - самые преданные пользователи. Если продукт работает для них, они никогда не уйдут к конкуренту, у которого «кнопка-загадка».

3. Legal: В 2023 году количество исков по цифровой доступности (ADA в США) выросло на 14% Источник: UsableNet Report. К сожалению в нашей стране такой практики нет вовсе.

Заключение. Ваш план действий на сегодня

Не нужно переписывать всё приложение сразу. Начните с малого:

1. Включите VoiceOver на своем iPhone и попробуйте закрыть глаза и заказать что-то в своем приложении. Вы удивитесь, как это больно.

2. Проверьте контрастность основных кнопок.

3. Добавьте dynamicTypeSize для текстовых блоков.

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

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