Content Description: какво е, принципи и как да се зададе за accessibility

Какво е Content Description в достъпността

Content Description — низово свойство на елемент от интерфейса, което предава текстовото представяне на визуално съдържание на помощните технологии. Screen reader (VoiceOver в iOS, TalkBack в Android) чете описанието вместо да се опитва да разпознае визуално елемента. Описанието се прилага към изображения без текстов слой, икони, графики, персонализирани контроли и всякакви нетекстови елементи.

Според данните на Google Material Design, 2024, елементите без contentDescription нарушават правилото WCAG 1.1.1 (Non-text Content). Проверката на Accessibility Scanner показва, че до 40% от иконите в магазинните приложения нямат описание. Потребителят на VoiceOver чува само “изображение” или “бутон” без уточнение — такъв интерфейс става неизползваем за навигация.

Content Description не замества видимия текст на елемента. Ако бутонът съдържа текстов етикет “Изпрати”, не е необходимо допълнително описание — screen reader ще прочете текста. За изображения, икони и полета за въвеждане описанието е задължително.

Инструментите Accessibility Scanner (Android) и Xcode Accessibility Inspector (iOS) автоматично проверяват наличието на описания. Препоръчва се тези проверки да се извършват на всеки екран преди пускане.

Защо е необходимо Content Description: потребителски сценарии

Потребителят с увредено зрение разчита на VoiceOver, за да разбере интерфейса. Ако иконата на количката няма описание, той чува само “бутон”. За да разбере какво прави бутонът, трябва да го натисне на сляпо — риск от необратимо действие. Описанието “Премахни продукта от количката” решава този проблем за секунда.

Потребителят с временни ограничения (силно слънце навън, счупен екран) също използва VoiceOver. Според Apple Accessibility Report, 2023, около 20% от потребителите на VoiceOver нямат трайни увреждания на зрението — включват тази функция ситуационно.

WCAG 1.1.1: Non-text Content

Критерият WCAG 1.1.1 (ниво A) изисква всяко нетекстово съдържание да има текстова алтернатива. Изключение: съдържание, което е декоративно, използва се само за визуален дизайн или не носи информация. Тест за декоративност: ако премахнем елемента, променя ли се смисълът на страницата? Ако не — може да бъде скрит от screen reader.

С какво Content Description се различава от Label

Accessibility Label (accessibilityLabel в iOS) — името на елемента, което screen reader произнася при фокусиране. Content Description (accessibilityHint в iOS) — допълнително обяснение, което се озвучава след името и информира за резултата от действието.

Разликата се вижда добре на примера на бутона “Количка”. Label: “Количка”. Description: “Ще отвори екрана за поръчка”. VoiceOver казва: “Количка. Ще отвори екрана за поръчка”. Ако е зададен само Label, потребителят няма да знае какво ще се случи след натискане.

Таблица: Label срещу Description

Правило: Label отговаря на въпроса “Какво е това?”, Description — “Какво ще се случи?”. В Android contentDescription може да изпълнява и двете роли, но на практика е по-добре да ги разделяте: използвайте конкатенация “[име], [обяснение]”.

Когато Description е по-важно от Label

За сложни жестове (плъзгане за изтриване, дълго натискане за контекстно меню) accessibilityHint е задължителен. Потребителят на VoiceOver не знае за скритите жестове, ако не са описани. Посочете: “Плъзнете наляво за изтриване” в hint на елемента.

iOS: атрибут accessibilityHint

На платформата iOS accessibilityHint се задава чрез едноименното свойство на UIView или NSObject. Стойност — низ до 80 знака. VoiceOver чете hint след label, ако е включен режимът на подробни описания (в настройките на VoiceOver — “Verbosity”).

Пример за задаване на hint за персонализиран бутон:

import UIKit

class CustomButton: UIButton {
    override func awakeFromNib() {
        super.awakeFromNib()
        self.accessibilityLabel = "Добави в любими"
        self.accessibilityHint = "Ще запази продукта в списъка с любими"
    }
}

За UIImageView без текстово съдържание е задължително да се зададат isAccessibilityElement = true и accessibilityHint:

let imageView = UIImageView(image: UIImage(named: "chart-sales"))
imageView.isAccessibilityElement = true
imageView.accessibilityHint = "Графика на продажбите за последното тримесечие"

VoiceOver чете: “Графика на продажбите за последното тримесечие”. Ако hint е празен — само “изображение”. Apple HIG, 2024 препоръчва да не се използват глаголи като “натиснете” или “докоснете” в hint — VoiceOver автоматично добавя инструкция за жест.

SwiftUI: модификатор accessibilityHint

В SwiftUI hint се задава чрез верижен модификатор:

Image(systemName: "trash")
    .accessibilityLabel("Изтрий")
    .accessibilityHint("Ще изтрие безвъзвратно избрания елемент")

SwiftUI автоматично комбинира модификатори за съставни view. Ако Image се намира вътре в Button, SwiftUI използва label на бутона като основен accessibilityLabel.

Android: свойство contentDescription

В Android contentDescription се задава или в XML маркирането, или програмно чрез setContentDescription(). TalkBack озвучава описанието при фокусиране на елемента.

Пример в XML:

<ImageView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:src="@drawable/ic_search"
    android:contentDescription="Търсене на продукти" />

Програмно задаване за динамични елементи:

binding.iconSearch.contentDescription =
    "Търсене. Ще отвори екрана за търсене с филтри"

За декоративни изображения (разделители, фонове, декоративни икони) задайте contentDescription = "@null" или setContentDescription(null) — TalkBack ще пропусне такъв елемент. В XML: android:contentDescription="@null". Празният низ "" не работи — TalkBack пак ще каже “изображение”.

Android: важни детайли за ImageButton и CheckBox

За ImageButton винаги задавайте contentDescription — TalkBack не вижда текста върху изображението. За CheckBox описанието трябва динамично да се променя: “Избрано” / “Не е избрано” вместо статично описание. Използвайте setContentDescription в слушателя за състояние.

Правила за писане на описания

Информативност — описанието трябва да предава смисъла, а не външния вид. Не “Синя икона с отметка”, а “Продуктът е добавен в количката”. Screen reader не се интересува от цветове — интересува се от резултата.

Краткост — оптимална дължина 2–4 думи (до 80 знака). Дългите описания забавят навигацията: VoiceOver чете последователно, всяка дума е секунда от времето на потребителя. Според Apple WWDC 2023, “Accessibility by Design”, фраза, по-дълга от 5 секунди четене, прекъсва когнитивния поток.

Уникалност — на един екран не трябва да има два елемента с еднакво описание. Потребителят няма да може да различи какъв резултат ще доведе фокусирането върху първия и втория елемент. Ако има няколко бутона “Купи” — добавете идентификатор: “Купи iPhone 15”, “Купи iPhone 15 Pro”.

Локализация — Content Description се превежда на всички езици, които приложението поддържа. Грешката в локализацията на описанието е една от честите причини за провал на Accessibility Review в App Store.

Дължина на описанието: изследвания

Изследването на Nielsen Norman Group, 2024 показа, че оптималната дължина на описанието за screen reader е 3–5 думи (до 50 знака). По-дългите описания намаляват скоростта на навигация с 30%, тъй като потребителят трябва да изчака завършването на четенето преди следващата стъпка.

Типични грешки при използване

Излишество — описанието дублира видимия текст. Ако бутонът съдържа текст “Изпрати”, не задавайте accessibilityHint = “Бутон изпрати”. VoiceOver ще прочете текста автоматично, а hint ще добави ненужен шум.

Объркване с Label — използване на contentDescription вместо label за текстови бутони. В iOS accessibilityLabel трябва да съвпада с текста на бутона (или да бъде празен, ако текстът вече е видим), а hint само обяснява действието. Според Google Testing Blog, 2024, 23% от проверените приложения в Play Store имат дублиращи се описания.

Игнориране на динамиката — описанието не се актуализира при промяна на състоянието. Например при превключвателя “Wi-Fi” описанието остава “Включи Wi-Fi” дори след включване. Правилно: динамично да промените описанието на “Изключи Wi-Fi” чрез наблюдение на състоянието.

Рендер цикли и регресии

След актуализация на дизайна (смяна на икони, пренареждане на елементи) Content Description често се губи. Причина: дизайнерът заменя изображението, разработчикът не проверява свойствата за достъпност на новия актив. Решение: направете проверката на достъпността задължителна стъпка в code review — добавете контролен списък с точка “Content Description актуализиран ли е?”.

Как да проверите Content Description

• В iOS: Xcode → Accessibility Inspector — изберете елемента, проверете полетата Label и Hint
• В Android: инсталирайте Accessibility Scanner от Play Store — пуснете на вашия екран
• На двете платформи: включете VoiceOver/TalkBack и обходете целия екран с жестове
• Напишете UI тест, който проверява contentDescription за всички ImageView

Пример за UI тест за iOS

func testContentDescriptionExists() {
    let app = XCUIApplication()
    app.launch()
    let image = app.images["chart-sales"]
    XCTAssertNotNil(image.label)
    XCTAssertGreaterThan(image.label.count, 0)
}