Як обговорювати доступність помилок англійською мовою

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

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

** Допоміжні технології (AT) ** — загальний термін для інструментів, які люди використовують для взаємодії з програмним забезпеченням інакше, ніж типовий користувач мишею і екраном, зокрема, для читання з екрану, перемикачів і голосового керування. “Цю ваду було виявлено під час тестування з допоміжними технологіями, зокрема з програмою для читання з екрану — це не те, що помітить зрячий користувач мишею.”

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

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

** Доступна назва ** — текст, який програма для читання з екрану оголосить для елемента, який може бути отримано з видимого тексту, тексту aria-label або alt, і має описувати мету елемента. “Доступна назва кнопки піктограми просто «button» — для цього потрібен aria-label, наприклад, «Закрити діалогове вікно», щоб користувачі програм для читання з екрану знали, що вона робить.”

** Фокусна пастка ** — помилка, коли фокус клавіатури затримується всередині елемента (часто випадково), і користувач не може вимкнути Tab, або відсутня навмисна пастка у модалі, яка дозволяє фокусу втекти за нею.

• “У модальному елементі є помилка, яка призводить до потрапляння фокусу у пастку — після його відкриття клавішою Tab фокус все одно пересувається до елементів позаду нього, які повинні бути інертними.” *

** Співвідношення контрасту ** — числова мірка різниці між кольором тексту і кольором тла, згідно до WCAG визначено мінімальні співвідношення, необхідні для зручності читання. “Співвідношення контрасту на цій кнопці становить 2. 8: 1, що значно нижче мінімального значення 4. 5: 1 для звичайного тексту — це не пройшло перевірку доступності.”

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

• «Цей елемент не має доступної назви — читач екрану просто оголосить «button» без контексту»
• «Порядок фокусування не збігається з візуальним порядком тут, що плутанина для навігації за допомогою клавіатури.»
• «Чи можемо ми перевірити співвідношення контрасту на цьому тексті проти фактичного кольору тла, а не тільки макет дизайну?»
• «Існує проблема пастки фокусу — фокус втікає з модульного вмісту, який повинен бути інертним, поки він відкритий»
• Це працює візуально, але не вдається з екранним читачем — ось конкретно те, що він оголошує

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

Записання докладного звіту про ваду доступності:

• “Кроки для відтворення: відкрити модальний параметр за допомогою клавіш Tab і Enter, а потім продовжити натискання клавіші Tab. Очікувалося: фокус має залишатися у модалі доки її не закривають. Фактично: після п’ яти вкладок фокус переноситься на посилання на сторінці, розташовану за модальною вкладкою, яка все ще візуально прихована, але не є належним чином інертною. Перевірено з VoiceOver на Safari.”*

Пояснення впливу проблеми контрасту: “Це не просто візуальний нюанс — співвідношення контрасту тексту помилки становить 2. 1: 1, що не відповідає WCAG AA і означає, що користувачі з порушеннями зору можуть не мати можливості прочитати повідомлення про помилку взагалі.”

Опис проблеми з читанням з екрану з урахуванням особливостей:

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

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

• Назвіть ** специфічну допоміжну технологію **, яку було використано для пошуку вади (комбінація назви програми для читання з екрану і назви переглядача) — поведінка може значно відрізнятися у VoiceOver, NVDA і JAWS.
• Описуйте ** порядок фокусування ** і ** пастки фокусування ** як окремі, специфічні помилки, а не просто « пошкоджено навігацію за допомогою клавіатури » — вони мають різні причини і різні виправлення.
• Цитувати ** доступну назву ** елемента, який дійсно повідомляє про це, а не просто про те, що « відсутня мітка » — показ того, що насправді повідомляє програма для читання з екрану, робить прогалини конкретними.
• Увімкніть фактичне число ** співвідношення контрастності **, коли повідомляєте про ваду контрастності, а не просто « текст важко читати » — це перетворює суб’ єктивну скаргу на об’ єктивний, перевіряний факт.

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

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

Навигація по сторінках: доступність з впевненістю

Ефективне спілкування про проблеми доступності - чи то під час перегляду коду, розмови в Slack, чи написання опису запитів на витяг - має вирішальне значення для створення інклюзивного цифрового досвіду. Це не просто про те, щоб вказати проблему; це про те, щоб передати * як * ця проблема впливає на користувачів і пропонує чіткі рішення. Багато розробників вважають це викликом через спеціалізовану термінологію. Давайте зосередимося на вдосконаленні вашого підходу, зрозумівши поширені фрази, які використовуються під час обговорення помилок доступності, особливо з точки зору англомовного користувача.

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

Іншою ключовою областю є детальний опис кроків для чіткого відтворення проблеми. Замість того, щоб сказати «Це не працює з NVDA», що не пропонує ніяких рекомендацій, спробуйте: «Я міг послідовно відчувати цю проблему, використовуючи зчитувач екрана NVDA в Windows 10. Кроки такі: 1. Перейти до [визначеної сторінки/компоненту]. 2. Фокусувати на елементі [назва елемента]. 3. За допомогою NVDA спробуйте прочитати вміст уголос. » Цей варіант є більш конкретним і надає інформацію, яку можна використовувати для будь- кого, хто намагається відтворити ваду. Включення інформації про операційну систему і використане програмне забезпечення для читання з екрану додасть ще більше ясності.

Нарешті, пам’ятайте, що пропонування рішень не про те, щоб диктувати, що * слід * зробити; це про те, щоб пропонувати варіанти. Замість « Вам слід збільшити контрастність », розгляньте: « Я вважаю, що зміна палітри кольорів відповідно до рекомендацій WCAG щодо достатньої контрастності вирішить цю проблему. Крім того, ми можемо розглянути можливість використання шрифту з більшим контрастом для елементів, які зачіпаються. ” Цей підхід до співпраці демонструє готовність працювати разом і представляє рішення конструктивним чином. * Завжди* підтримуйте свої рекомендації посиланням на стандарти доступності (WCAG), коли це можливо – це додає ваги вашому аргументу і показує, що ви провели своє дослідження.