Accessibility Testing

1. ОТЕСТИРОВАНИИ
ДОСТУПНОСТИ
Екатерина Шепелева

2. Екатерина Шепелева
Lead SoftwareTesting Engineer в EPAM (Киев)
Работала в компаниях:
• Ciklum (Киев, Одесса)
• Lohika (Одесса)
• GeeksForLess (Николаев)
В IT с 2009 года
7 лет в тестировании

3. План на сегодня
• О доступности
[что, зачем и почему]
• Подход к тестированию
[что и как мы проверяем, инструменты]
• Напоследок
[challenges, benefits, мифы]

4. О доступности

5. Что такое accessibility?
Тестирование веб-доступности (Web-Accessibility testing)
Подмножество usability тестирования
Когда сайты правильно спроектированы и
разработаны, все пользователи имеют
равный доступ к информации и
функциональности
Люди с ограниченными возможностями
должны иметь возможность пользоваться
Интернетом

6. Зачем?
Существующие законодательства
Потенциальные судебные иски
Около 20% людей имеют ограниченные
возможности
Дополнительные плюшки для заказчика

7. Законодательства
• США: Americans with DisabilitiesAct – 1990
https://www.ada.gov/
• Австралия: Disability Discrimination Act – 1992
• Великобритания: Disability Discrimination Act – 1995
• Ирландия: Disability Act of 2005
• и другие

8. WEB стандарты
WCAG (Web Content Accessibility Guidelines)
https://www.w3.org/TR/WCAG20/
Section 508
http://www.section508.va.gov/support/html/index.asp
WAI-ARIA (с точки зрения разработки)
https://www.w3.org/WAI/intro/aria.php

9. Виды ограниченных возможностей
ТИП НАРУШЕНИЯ ОПИСАНИЕ
Нарушения зрения • Полная слепота, дальтонизм, низкая острота зрения
• Различные нарушения визуального восприятия
Физическая
недееспособность
• Неспособность использовать мышку или клавиатуру
• Такие ослабленные моторные навыки, как замедленность
движений и работы мышц
Когнитивное расстройство • Трудности с приобретением знаний, расстройство памяти,
неспособность усвоить более сложные сценарии
Нарушение способности
читать и писать
• Проблемы с чтением
Нарушения слуха • Такие слуховые нарушения, как глухота или ухудшение слуха
• Неспособность слышать или неспособность слышать отчетливо

10. Доступность популярна?
кому нужна доступность?

11. Доступность популярна!

12. Подход к тестированию

13. Прежде, чем начать, мы
• Получили одобрение заказчика
• Определили каким стандартам должны соответствовать
• Определили желаемый уровень соответствия (А, АА, ААА)
• Добавили accessibility в DOD
• Определили, что мы делаем, что не делаем

14. Прежде, чем начать, мы
• Получили одобрение заказчика
• Определили каким стандартам должны соответствовать
• Определили желаемый уровень соответствия (А, АА, ААА)
• Добавили accessibility в DOD
• Определили, что мы делаем, что не делаем
А: невозможно
АА: сложно
ААА: несколько
сложно

15. Прежде, чем начать, мы
• Получили одобрение заказчика
• Определили каким стандартам должны соответствовать
• Определили желаемый уровень соответствия (А, АА, ААА)
• Добавили accessibility в DOD
• Определили, что мы делаем, что не делаем
А: невозможно
АА: сложно
ААА: несколько
сложно

16. Прежде, чем начать, мы
• Получили одобрение заказчика
• Определили каким стандартам должны соответствовать
• Определили желаемый уровень соответствия (А, АА, ААА)
• Добавили accessibility в DOD
• Определили, что мы делаем, что не делаем
В процессе:
• Выбрали инструменты
• Провели тренинги

17. Что мы не делаем
•Тестирование доступности на мобильных
устройствах
•Тестирование продукта пользователями с
ограниченными возможностями

18. Что мы делаем
• Ручное тестирование с использованием инструментов
• Без тест кейсов, только чек листы
• Поддерживаем А и АА уровни соответствия
• Уровни соответствия используются для определения приоритета
бага (например, А – минимальный уровень, покрывающий основные
проблемы)
• Критерии доступности, которые мы покрываем:
• Perceivability
• Operability
• Understandability
• Robustness

19. Критерии
КРИТЕРИЙ (WCAG) ОПИСАНИЕ
PERCEIVABILITY • Предоставление текстовых альтернатив для нетекстового контента
• Предоставление титров и других альтернатив для мультимедиа
• Контент может быть представлен по-разному, в том числе с помощью
вспомогательных технологий, без потери смысла
OPERABILITY • Вся функциональность доступна с клавиатуры
• У пользователей достаточно времени для чтения и использования
контента
• Не используется контент, который может вызвать приступ
• Помощь пользователям в навигации и поиске контента
UNDERSTANDABILITY • Текст читаемый и понятный
• Контент появляется и управляется предсказуемым образом
• Помощь пользователям в избежании и исправлении ошибок
ROBUSTNESS • Максимальная совместимость с текущими и будущими
инструментами пользователя

20. Пример чеклиста

21. Примеры багов

22. Примеры багов

23. Основные проверки
• Гипертекст (HTML валидаторы – изображения, таблицы,
формы, ссылки, стили, структура, doctype)
• Навигация с помощью клавиатуры
• Текстовые альтернативы
• Цвета и контрастность
• Увеличение (200%), растягивание и разрешение
• Аббревиатуры, термины
• Мигающий или двигающийся контент

24. Инструменты

25. WAVE
WAVE - инструмент для оценки веб доступности, который
обеспечивает визуальную обратную связь о доступности веб-
контента, отображая иконки и индикаторы на странице.
• Online инструмент | http://wave.webaim.org/
• Дополнение к Chrome / FireFox | http://wave.webaim.org/extension/
• Бесплатный

33. JAWS
JAWS (Job Access With Speech) — программа для чтения с экрана
компьютера, предназначенная для людей с ослабленным зрением.
Чтение происходит путем предоставления пользователю информации, отображаемой на
экране, через озвучивание текста на экране (text-to-speech) и с помощью шрифта Брайля,
позволяющего без ограничений пользоваться клавиатурой.
http://www.freedomscientific.com/Products/Blindness/JAWS
Цены:
Professional: 1100$
Home edition: 900$
90 days license: 179$

34. Сравнение скрин ридеров

35. NVDA и ChromeVox
• NVDA (от NV Access) | https://www.nvaccess.org/
• ChromeVox | http://www.chromevox.com/

36. Статистика
http://webaim.org/projects/screenreadersurvey5/

37. Еще больше инструментов
• tota11y | http://khan.github.io/tota11y/
• MarkupValidator Service | https://validator.w3.org/
• AChecker | https://achecker.ca/checker/
• AInspector Sidebar for Firefox | https://addons.mozilla.org/ru/firefox/addon/ainspector-sidebar/
• No Coffee | https://accessgarage.wordpress.com/2013/02/09/458/
• Colour Contrast Check | https://snook.ca/technical/colour_contrast/colour.html
• + RGB-to-Hex Converter | http://www.javascripter.net/faq/rgbtohex.htm
• Web Accessibility EvaluationTools List | https://www.w3.org/WAI/ER/tools/
• Chrome Accessibility | https://chrome.google.com/webstore/category/collection/accessibility
• …

38. Мобильное тестирование
На мобильных устройствах:
• Встроенные возможности
• Screen readers:
• AndroidTalkBack | Settings > Accessibility >TalkBack
• iOSVoiceOver | General > Accessibility >VoiceOver
• Встроенные опции (увеличение/уменьшение, инверсия цветов и пр.)
• Ручные проверки
На компьютере:
• Валидация HTML
• Анализ контрастности цветов
• …
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Mobile_Resources
https://developer.mozilla.org/en-US/docs/Learn/Accessibility/Mobile

39. И напоследок

40. Чего ожидать: challenges
• Низкий приоритет этого вида тестирования
• Чем позже начинается тестирование доступности, тем больше
придется переделывать:
• Если проект не новый, устаревшие или 3rd party компоненты может быть
невозможно изменить и сделать их compliant. План обхода (хоть и
нежелательный) – создать альтернативную страницу без использования такого
компонента
• UX дизайн может быть создан без учета требований доступности > многие
элементы (например, функциональность, появляющаяся по наведению мыши)
должны быть переделаны
• Если стили (цвета, шрифты), которые используются в продукте, одинаковы для
нескольких продуктов заказчика, будет весьма проблематично их изменить
• Тестировщикам сложнее найти проблемы, чем представителям target
audience | https://dou.ua/lenta/interviews/blind-programmer/
• Разные инструменты могут найти разные баги

41. Как предложить заказчику: benefits
• Пройти аудит / сертификацию
• Стать более конкурентноспособными > привлечь больше
клиентов > заработать больше денег
• Улучшить usability и производительность продукта в целом
• Улучшить автоматизацию на проекте
• Максимальная выгода при минимальных усилиях:
• основные юзер сценарии
• наиболее посещаемые страницы
• исправление основных проблем (уровень А)

42. Мифы о тестировании доступности
Доступные сайты некрасивые и
скучные
Не предполагается, что доступные сайты черно-белые и без дизайна
Для доступности нужно много
денег, времени и усилий
Сделать сайт доступным – просто означает “сделать правильно”, а не
как-то совершенно иначе
• Доступность сайта принесет
пользу только небольшому
количеству человек
• Нет никаких
дополнительных
преимуществ у того, чтобы
сделать сайт доступным
Около 20% людей имеют ограниченные возможности
В какой-то момент каждый из нас сталкивается с тем, что какая-то
ссылка не работает, текст слишком мелкий, звук не проигрывается,
невозможно попасть курсором на нужную кнопку и так далее.
• Улучшение usability и производительности для всех пользователей
• Позитивное влияние на репутацию компании
Доступность - это по желанию Доступность требуется законом
Инструментов достаточно для
того, чтобы проанализировать
сайт на доступность
Многие из проверок по доступности не достаточно объективны для
того, чтобы проверять их автоматизировано, так как нужна
человеческая оценка, чтобы определить, например, достаточно ли
какая-то формулировка понятна

43. Бонус!

48. Вопросы?
Контакты:
eshepelieva@gmail.com
eshepelieva
search for Kateryna Shepelieva
search for eshepelieva
Подходите за визитками 
Спасибо за внимание!