Англійська мова для звітів тестування WCAG і Screen Reader

Написання звіту про виявлення вади доступності відрізняється від написання загального звіту про помилку — вам слід вказати певний критерій успіху WCAG, описати, з якими проблемами зіткнулися допоміжні технології, і пояснити, яким чином ця проблема впливає на користувача, а не лише те, що виглядає неправильно візуально. Цей підручник містить англійською мовою структурування цих результатів, щоб їх було розділено на пріоритети і виправлено.

Ключовий словник

WCAG успішний критерій — специфічна, пронумерована вимога з Web Content Accessibility Guidelines (наприклад, “1.1.1 Нетекстовий вміст”), використовується для зафіксування результату до офіційного стандарту, а не особистої думки.

• “Це не відповідає критерію успіху WCAG 2. 1 1. 4. 3 (Контрастність мінімальна) — колір тексту має співвідношення контрастності 2. 8: 1 на тлі, що нижче за необхідне 4. 5: 1.” *

** Програма для читання з екрану повідомляє про це ** — текст або опис, який програма для читання з екрану вимовляє уголос, коли користувач переходить до елемента, який часто відрізняється від того, що показано візуально.

• « Програма для читання з екрану оголосить цю кнопку просто як « кнопка » без мітки, оскільки піктограма не має доступної назви. » *

** Назва доступності ** — текст, який програма для читання з екрану використовує для ідентифікації інтерактивного елемента, обчислений з видимого тексту, aria-label, alt тексту або з подібних джерел. “Кнопка вилучення, що містить лише піктограму, не має доступної назви — нам потрібно додати aria-label=\"Delete item\", щоб користувачі програм для читання з екрану знали, що вона робить.”

** Порядок фокусування ** — послідовність, у якій інтерактивні елементи отримують фокусування клавіатури, коли користувач пересувається за допомогою клавіш табуляції сторінкою, ця послідовність має відповідати логічному порядку читання.

• « Порядок фокусування переходить з поля пошуку безпосередньо до нижнього колонтитула, пропускаючи весь список результатів — це перериває навігацію за допомогою клавіатури для тих, хто не використовує миші. » *

** Допоміжна технологія (AT) ** — програмне або апаратне забезпечення, яке допомагає користувачам з обмеженими можливостями взаємодіяти з цифровим вмістом, включаючи програми для читання з екрану, пристрої перемикачів і програмне забезпечення для голосового керування. “Ми перевірили цей поток з двома допоміжними технологіями: VoiceOver на macOS і NVDA на Windows, оскільки поведінка зчитувача екрана може відрізнятися між ними.”

Звичайні фрази

• «Це не відповідає критерію успіху WCAG [версія] [номер] ([назва]).»
• «Тестовано з [назва програми для читання з екрану] на [ОС] — оголошення було [що воно каже]»
• «Доступна назва для цього елемента відсутня/неправильна»
• «Користувачі, які користуються лише клавіатурою, не можуть виконати [конкретну дію], тому що [конкретна причина]»
• «Вплив: користувач зчитувача екрану не знав би, що [спеціфічні наслідки]»

Приклади висловлювань

Написання висновку за стандартною структурою — критерій, спостереження, вплив:

• “Знайти: Кнопка « Надіслати » має недостатню контрастність кольорів (2. 1: 1) на тлі, що не відповідає стандарту WCAG 2. 1 SC 1. 4. 3 (контрастність мінімальна, потрібно 4. 5: 1). Вплив: користувачі з поганим зором можуть не бути в змозі сприймати, що кнопка присутня або інтерактивна. ”*

Опис того, що програма для читання з екрана фактично повідомляє, а не лише те, що видно: «Тестування з VoiceOver на macOS Safari. Коли фокус пересунуто на перемикач цін, VoiceOver оголосить лише « перемикач, вимкнути » без вказівок на те, що саме керує перемикач. Зрячий користувач бачить мітку «Річний рахунок» поряд з ним, але цей текст не пов’язаний програмно з контролем.”

Відмінність візуальної вади від вади доступності у звіті:

• “Це не візуальна помилка — розкладка виглядає правильно на екрані. Проблема в тому, що модальний діалог не захоплює фокус клавіатури, тому користувач, який користується тільки клавіатурою, може вибратися з відкритого модального вмісту в вміст за ним, що дезорієнтує і може призвести до небажаних дій.” *

Приоритизація результатів за впливом, а не лише за тяжкістю:

• “Я б віддав перевагу відсутнім міткам форм перед проблемою порядку заголовків. Відсутні мітки блокують користувачів зчитувачів екрану від заповнення форми реєстрації взагалі, в той час як проблема порядку заголовків робить навігацію менш ефективною, але не блокує виконання завдання. “*

Професійні поради

• Завжди цитуйте конкретний критерій успіху WCAG за номером і назвою — це перетворює суб’єктивну думку на перевіряну, посилання на вимогу, яку важко відкинути.
• Зверніть увагу на точне поєднання програми для читання з екрану та платформи, з якою ви тестували (наприклад, «NVDA на Windows з Chrome») — поведінка справді відрізняється у різних поєднаннях, і ця деталь допомагає іншим відтворити результати.
• Цитата фактичного тексту оголошення, а не перефразування — « він оголосить « кнопку » без мітки » корисніше для розробника, ніж « кнопка не має хорошої мітки. »
• Відокремте ** спостереження ** (що сталося) від ** впливу ** (що користувач з обмеженими можливостями насправді не може зробити) — обидва мають значення, і вплив зазвичай є тим, що робить виявлення пріоритетним.
• Під час сортування декількох результатів, визначайте пріоритет за ** чи блокує це виконання завдання **, а не лише за тим, наскільки візуально очевидна проблема.

Практичні вправи

1. Напишіть висновок, у якому буде вказано певний критерій успіху WCAG, спостереження і висновок щодо впливу.
2. Напишіть речення, у якому буде вказано точний текст, який програма для читання з екрану повідомила про пошкоджений елемент.
3. Напишіть одноречення, у якому ви поясните, чому ви віддаєте перевагу одному з виявлених недоступних елементів над іншим.

Розробка мови: підтримка для не-національних розробників

Метою тестування доступності є не просто позначення пунктів у контрольному списку; це забезпечення того, щоб всі могли ефективно використовувати продукт. Це означає, що комунікація повинна бути чіткою і точною, особливо при документуванні проблем, знайдених під час аудиту або повідомлення результатів іншим розробникам. Для не-рідних англомовних носіїв, що пересуваються у світі технічного письма і доступності, це може бути особливо викликом. Це не просто переклад слів; це розуміння ніянсів професійного спілкування - тонких способів, в яких мова використовується для передачі авторитету, запропонувати рішення і ефективно співпрацювати. Розглянемо, як ви можете сформулювати проблему для вашої команди. Замість простого повідомлення « Кнопці не вистачає альтернативного тексту », більш корисним підходом буде: « Основна кнопка на цій формі на даний момент не має пов’ язаного альтернативного тексту; це порушує WCAG 1. 1. 1 (Нетекстовий вміст) і може значно ускладнити користування для користувачів, які покладаються лише на програми для читання з екрану. » Зауважте доданий контекст — посилання на певний критерій успіху демонструє ваше розуміння впливу проблеми.

Іншою поширеною пасткою є використання надмірно буквальних перекладів. Фрази на кшталт «веб-сайт недоступний» часто надто тупі і не передають серйозності ситуації. Краще було б сказати: « Ми виявили декілька випадків, коли поточний дизайн не повністю відповідає рекомендаціям WCAG, особливо щодо навігації за допомогою клавіатури і контрасту кольорів. » Цей підхід зосереджується на тому, що потрібно зробити, а не просто на тому, що є неправильним. Аналогічно, під час написання опису запиту на завантаження, замість того, щоб сказати « Виправити доступність », спробуйте щось на зразок: « Цей PR розв’ язує визначені проблеми доступності, пов’ язані з мітки форм і сумісністю з програмами для читання з екрану, забезпечуючи відповідність зі стандартами WCAG 2. 1 рівня AA. » Використання конкретних термінів — « мітки форм », « сумісність з програмами для читання з екрану » — негайно сигналізує про обсяг роботи і демонструє знайомство з відповідними рекомендаціями.

Крім того, пам’ятайте, що конструктивна оцінка є ключовою. При обговоренні проблеми з колегою, уникайте обвинувачувальної мови. Замість того, щоб сказати « Ви зробили це недоступним », спробуйте сказати: « Я помітив деякі проблеми з навігацією у цьому розділі за допомогою програми для читання з екрану. Чи можемо ми дослідити способи поліпшення семантичної структури і атрибутів ARIA, щоб підвищити доступність?» Цей м’ який підхід сприяє співпраці і заохочує орієнтований на рішення підхід. Не бійтеся прохання про пояснення — якщо ви не розумієте термін або фразу, яку використовує людина, для якої мова є рідною, ввічливо запитайте про пояснення. « Чи можете ви розібратися, що ви маєте на увазі під « порядком фокусування клавіатури » у цьому контексті? » — це цілком прийнятно.

І нарешті, зверніть увагу на тон вашого письма. Звіти про доступність повинні бути професійними та об’єктивними, зосереджуючись на технічних деталях, а не на особистих думках. Зберігання чіткого, короткого і добре структурованого стилю значно покращить розуміння і спростить ефективне співробітництво у вашій команді. Пам’ ятайте, що ясність мови безпосередньо перекладається на ясність у дії - допомагаючи забезпечити, щоб поліпшення доступності були реалізовані ефективно і ефективно.