Доступность — важнейший аспект при разработке и проектировании приложений для iOS, и ее значение выходит за рамки простого требования соответствиям. Речь идет о создании инклюзивных и универсально используемых цифровых продуктов. Доступность гарантирует, что все пользователи, независимо от их способностей или неспособностей, смогут получить доступ к приложениям и извлечь из них пользу. Сюда входят люди с нарушениями зрения, слуха, двигательных и когнитивных функций, а также те, кто испытывает временные трудности.
Одной из ключевых причин, по которой доступность в разработке приложений должна быть приоритетной, является ориентированность на пользователя. Проектируя приложения с учетом требований доступности с самого начала, разработчики не только ориентируются на широкую аудиторию, но и улучшают общее впечатление пользователей. Доступный дизайн часто подразумевает упрощение интерфейса приложения и облегчение навигации по нему, что приносит пользу не только людям с ограниченными возможностями, но и всем пользователям, включая пожилых людей или тех, кто плохо знаком с технологиями. Такая инклюзивность дизайна может привести к повышению удовлетворенности и удержанию пользователей, а в перспективе — к расширению их базы.
Более того, придерживаясь установленных стандартов доступности, таких как Руководство по доступности веб-контента (WCAG), разработчики могут создавать приложения, которые будут более удобны для использования в различных условиях и людьми с различными видами инвалидности. Эти рекомендации представляют собой основу для обеспечения доступности цифрового контента, охватывая такие аспекты, как коэффициент контрастности, размер шрифта и гибкие возможности навигации, что гарантирует, что приложения будут удобны для людей с самыми разными способностями.
Внедрение таких функций, как VoiceOver, программы чтения с экрана для слабовидящих пользователей, и Dynamic Type, которая позволяет пользователям изменять размер текста, может значительно улучшить удобство использования приложения. Эти функции, а также другие, такие как Siri и Dictation, являются неотъемлемой частью iOS-разработки, улучшая пользовательский опыт и потенциально повышая рейтинг приложения в App Store.
В наше время очень важно думать обо всех пользователях приложений, и Apple только что предоставила инструмент для использования этого намерения воли. Это тема для сегодняшней статьи.
Как проверить, есть ли у вашего приложения проблемы с доступностью?
Вам необходимо провести аудит и понять все потенциальные проблемы с доступностью вашего приложения.
В Xcode 15 появился новый замечательный инструмент для проверки того, соответствуют ли наши приложения правилам доступности или нет. Для этого уже существовали другие инструменты, такие как A11yUITests. Но теперь они вам больше не нужны, поскольку вы можете использовать Xcode, чтобы делать эту работу.
Вам просто нужно вызвать performAccessibilityAudit в вашем XCUIApplication в цели XCUITest и все. Посмотрите код ниже:
func testAutomatedAccessibility() {
let myApp = XCUIApplication()
myApp.launch()
do {
try myApp.performAccessibilityAudit()
} catch {
XCTFail("The automated accessibility audit fail because [\(error.localizedDescription)]")
}
}
Давайте посмотрим, как это реализовать шаг за шагом.
Реализация аудита доступности с нуля
Итак, давайте начнем создавать проект. В только что созданный проект добавим этот ContentView, который имеет несколько ошибок доступности:
struct ContentView: View {
var body: some View {
VStack(spacing:10) {
Text("My Title!")
.font(.system(size: 35))
.foregroundStyle(Color(uiColor: .darkGray))
.bold()
Label(
title: { Text("Subtitle") },
icon: { Image(systemName: "42.circle") }
)
Button {
print("Tappable Image")
} label: {
Image(systemName: "globe")
.foregroundStyle(.tint)
.background {
RoundedRectangle(cornerRadius: 10)
.foregroundStyle(.gray)
}
}
.fixedSize()
.frame(width: 25, height: 25)
}
.padding()
}
}
Теперь давайте проведем аудит этого единственного представления и выясним все проблемы a11y.
Перейдите в папку проекта и добавьте новую цель:
В модальном окне выберите UI Testing Bundle и дайте имя, которое, по вашему мнению, подходит для тестов аудита доступности:
ПОМНИТЕ, ЧТОБЫ АВТОМАТИЧЕСКИЙ АУДИТ ДОСТУПНОСТИ РАБОТАЛ, ВАМ НУЖЕН ПАКЕТ UI TESTING BUNDLE.
Следующим шагом будет создание UI-теста, который будет выполнять наши проверки. Перейдите к целевому UI-тесту и добавьте новый тест для проверки доступности нашего представления:
func testAutomatedAccessibility() {
let myApp = XCUIApplication()
myApp.launch()
do {
try myApp.performAccessibilityAudit()
} catch {
XCTFail("The automated accessibility audit fail because [\(error.localizedDescription)]")
}
}
Это приведет к трем ошибкам доступности:
Ошибки следующие:
- Область нажатия слишком мала
- Контрастность не работает
- Не поддерживаются динамические размеры шрифта
В нашем представлении это простые проверки, но что, если у вас сложная вложенная структура SwiftUI? Как бы вы узнали, что является причиной отказа этого теста?
Не думайте об этом, потому что команда разработчиков Xcode также предоставила очень хороший инструмент для создания отчетов.
Чтение отчетов об ошибках доступности
Перейдите в навигатор отчетов, щелкните в разделе тестов и дважды щелкните на «Область нажатия слишком мала»:
В следующем окне вы увидите, какой именно элемент вызывает у вас проблемы, нажмите на «Element Screenshot.png» под ошибкой, как на изображении ниже:
То же самое можно проделать и с двумя другими проблемами.
Исправление проблем с доступностью в нашем примере
Чтобы исправить представление, сделайте примерно следующее:
struct ContentView: View {
var body: some View {
VStack(spacing:10) {
Text("My Title!")
.font(.largeTitle) // new font
.foregroundStyle(.primary) // new foreground style
.bold()
Label(
title: { Text("Subtitle") },
icon: { Image(systemName: "42.circle") }
)
Button {
print("Tappable Image")
} label: {
Image(systemName: "globe")
.resizable() // add resizable
.foregroundStyle(.tint)
.frame(width: 25, height: 25) // new size for this view
.padding()
.background {
RoundedRectangle(cornerRadius: 10)
.foregroundStyle(.gray)
}
}
}
.padding()
}
}
#Preview {
ContentView()
}
Изменения следующие:
- Шрифт, который мы используем для заголовка, — это .largeTitle, который имеет динамический размер. Это означает, что когда пользователь изменит размер шрифта в конфигурации iPhone, заголовок будет соответствовать новому размеру, заданному системой.
- Второе изменение заключается в том, что foregroundStyle стиль заголовка теперь .primary, что является динамическим цветом. Этот цвет хорошо контрастирует с фоном по умолчанию в светлом и темном режимах.
- И наконец, нам также нужно было увеличить размер кнопки, чтобы у пользователя была большая область для нажатия.
Таким образом, мы устранили все проблемы с доступностью на нашем экране. Давайте подробнее рассмотрим API функции performAccessibilityAudit.
Специфический аудит доступности в SwiftUI
В вашем приложении вам может понадобиться отфильтровать некоторые элементы, которые, как вы уже знаете, не соответствуют требованиям доступности. Например, представьте, что у вас есть устаревшая кнопка, которая не изменится, пока UX/UI-дизайнеры не создадут новую, а текущий дизайн привязан к дизайн-системе. У вас нет возможности изменить эту конкретную кнопку, так что в этом случае вы можете просто пропустить любую a11y проблему, связанную с этой кнопкой.
Посмотрите на приведенный ниже код, где мы игнорируем все ошибки, возникающие при работе с кнопкой:
func testAutomatedAccessibilityIgnoreLoginButton() {
let myApp = XCUIApplication()
myApp.launch()
let handler: ((XCUIAccessibilityAuditIssue) -> Bool) = { issue in
if issue.element == myApp.buttons["login button"] {
false // ignore problems with login button
} else {
true // check any other error
}
}
do {
try myApp.performAccessibilityAudit(for: .all, handler) // changed here!
} catch {
XCTFail("The automated accessibility audit fail because [\(error.localizedDescription)]")
}
}
С помощью приведенного выше кода мы говорим:
- Получить все ошибки доступности.
- При возникновении ошибки проверьте, находится ли она в «login button», если да, то просто проигнорируйте ее, иначе тест будет провален.
С помощью того же API мы можем проверить конкретные ошибки на экране. Например, чтобы проверить только проблемы с цветовым контрастом, можно использовать приведенный ниже код:
func testAutomatedAccessibilityForColorContrast() {
let myApp = XCUIApplication()
myApp.launch()
do {
try myApp.performAccessibilityAudit(for: .contrast) // checking just for the color contrast here
} catch {
XCTFail("The automated accessibility audit fail because [\(error.localizedDescription)]")
}
}
Или даже проверить на несколько типов ошибок:
func testAutomatedAccessibilityForColorContrastHitRegionAndTrait() {
let myApp = XCUIApplication()
myApp.launch()
do {
try myApp.performAccessibilityAudit(for: [.contrast, .hitRegion , .trait]) // three error types checked here
} catch {
XCTFail("The automated accessibility audit fail because [\(error.localizedDescription)]")
}
}
Очень круто, не правда ли?
Типы ошибок доступности в iOS
Возможно, вы задаетесь вопросом: какие типы специфических ошибок я могу проверить? Я перечислю их ниже:
- all: Этот тип будет получать все ошибки из вашего кода, это самый общий тип. Это значение по умолчанию для аудита.
- contrast: Это проверка минимального цветового контраста, который должен быть у ваших элементов, чтобы их можно было визуализировать для большей части аудитории.
- dynamicType: Относится к способности вашего шрифта использовать динамический размер.
- elementDetection: Это когда вы добавляете представления, которые не отображаются на экране, и эти представления берут на себя фокус озвучивания, а пользователь не знает, что происходит, потому что в фокусе озвучивания находится невидимый экран.
- hitRegion: Это происходит, когда у вас слишком маленькие кнопки. Высота и ширина меньше, чем 44 точки.
- sufficientElementDescription: Когда у вас есть кастомный элемент, у которого нет доступного для озвучивания описания.
- textClipped: Когда текст обрезан и озвучивание не может прочитать его пользователю.
- trait: У каждого компонента пользовательского интерфейса есть свои характеристики доступности, эта ошибка возникает, когда у вас их явно нет.
Вы можете смешивать и сочетать все, что вам нужно для аудита в вашем приложении, используя вышеперечисленные элементы.
И мы закончили!
Как сделать ваше приложение SwiftUI более доступным
В заключение следует сказать, что повышение доступности вашего SwiftUI-приложения — это не только соблюдение стандартов или избегание потенциальных ошибок. Речь идет о внедрении философии инклюзивности и ориентированного на пользователя дизайна.
Проводя тщательный аудит доступности с помощью таких инструментов, как performAccessibilityAudit в Xcode, разработчики могут выявить и решить проблемы, которые могут помешать пользователям с разными способностями.
Помните, что доступность — это путешествие, а не конечный пункт. Она требует постоянного обучения, тестирования и адаптации. Как разработчики, мы обязаны быть в курсе последних стандартов и практик доступности. Внедрение этих принципов не только делает наши приложения более доступными, но и делает их лучше для всех.
Поддерживая атмосферу инклюзивности и осведомленности в процессе разработки приложений, мы способствуем созданию мира, в котором технологии будут действительно доступны для всех. Давайте продолжать разрабатывать приложения, но с прицелом на то, чтобы сделать наш цифровой мир более гостеприимным и доступным для всех.
Друзья iOS-разработчики, это все. Надеюсь, вам понравилось читать эту статью так же, как мне понравилось ее писать.