Користувачі зі слабким зором взаємодіють із застосунками в дуже різних умовах: зі збільшенням, системними функціями доступності, високим контрастом або екранним читачем. Завдання команди — не створити окрему версію, а не зламати основний досвід під час таких налаштувань.
Перевірте основні бар’єри
- текст і кнопки не повинні зникати за фіксованої ширини;
- іконки мають мати назви та не бути єдиним носієм сенсу;
- фокус повинен бути видимим і логічним;
- помилки не можна передавати лише кольором або тонкою рамкою;
- збільшення не повинно блокувати горизонтальне читання.
Перевіряйте реальні задачі: пошук, заповнення форми, підтвердження платежу, читання довгого тексту та відновлення після помилки. Те, що виглядає прийнятно на окремому компоненті, може стати непридатним у повному сценарії.
Android quality guidelines ставлять у центр послідовні взаємодії та підтримку різних пристроїв. Для доступності це означає, що масштабування і системні налаштування потрібно враховувати ще в архітектурі layout.
Як вбудувати в процес
Додайте accessibility-перевірки до макетів, компонентів і приймання функції. Попросіть людей із різними способами взаємодії пройти один ключовий сценарій. Результати фіксуйте як конкретні проблеми, а не як загальне «потрібно зробити доступніше».
Доступний продукт ширший за аудиторію, яка прямо називає себе людиною з інвалідністю. Він працює краще для всіх, хто збільшує текст, втрачає увагу, користується однією рукою або має тимчасові обмеження.
Джерело: Android Developers: What a great user experience looks like.
