Comments 4
Вот, кстати, вопрос (может быть и глупый): как разработчику тестировать то, что он наверстал? Простого включения чего-то типа произношения текста будет достаточно или какие-то особые дополнения или опции требуются? Или можно смело полагаться на валидатор?
Вопрос не глупый, а наоборот очень сложный и многоуровневый.
Машинной проверки однозначно недостаточно. Существуют инструменты для автоматического тестирования доступности web-страниц, но они помогают лишь частично. Как правило, всё сводится к примерной оценки контрастности цветовой схемы, плюс отлавливанию вещей типа отсутствующего или пустого атрибута alt у картинок. По-хорошему тестироваться должно руками.
Цветовые аспекты вы можете проконтролировать самостоятельно:
Во-первых, в принципе изначально верстать с учётом достаточной контрастности текста и фона, а также без использования опасных цветовых пар, типа красного и зелёного рядом, так как это наиболее частая проблемная пара у дальтоников. Ну и шрифт адекватных размеров.
Во-вторых, существуют инструменты, позволяющие просмотреть картинку с эмуляцией различных нарушений зрения.
Но вообще если вы используете адекватную цветовую схему, то, как правило, этого уже достаточно. К тому же люди с серьёзными нарушениями зрения, но при этом ещё работающие визуально, применяют специализированное ПО, которое выводит на дисплей модифицируемую картинку: экранное увеличение плюс подмена одних цветов на другие.
Что касается пользователей с нарушениями моторики, то тут вы также можете протестировать самостоятельно. Просто отложите мышь и поработайте со своим сайтом чисто с клавиатуры, попробовав проделать все предполагаемые пользовательские сценарии.
Тут вам пригодится атрибут tabindex, который позволяет включить элементы в цепочку клавиатурного фокусирования, а также задать порядок их перебора. Плюс для повышения удобства навигации с клавиатуры можно добавить вверху страницы ссылку «Перейти к основному содержимому», при нажатии на которую фокус будет перебрасываться к началу основной области (делается внутристраничной ссылкой — href="#main"), а также внизу страницы ссылку «Перейти наверх страницы», которая будет перебрасывать в самое начало. Это даст возможность быстрого перемещения без необходимости скролить.
Невизуальная доступность — это самое сложное, потому что принципы взаимодействия и получения информации здесь принципиально иные.
По-хорошему, если речь идёт о большом и сложном проекте, то лучше привлекать специального тестировщика или вообще внедрять в команду QA-инженера по accessibility, который сможет не только тестировать, но и давать конкретные рекомендации на техническом языке, плюс будет обладать широкими знаниями различных вспомогательных технологий и их специфики на различных платформах.
Самостоятельно вы также можете попробовать протестировать невизуальную доступность, но для этого вам придётся освоить программы экранного доступа и принципы работы с web-контентом через них, а они отличаются. К тому же в этой сфере есть несколько разных концепций представления экранной информации, поэтому освоение одной программы не даст полного покрытия темы.
Впрочем, какую-то базовую вещь протестировать можно и самостоятельно. Например, когда вы будете только осваивать WAI-ARIA, вы сможете хотя бы проверить, действительно ли сделанный chackbox корректно читается, а его состояние отмеченности и неотмеченности распознаётся. Для таких целей я бы, пожалуй, рекомендовал свободную программу экранного доступа для Windows — NVDA. К тому же она одна из самых популярных, и используемый в ней подход к невизуальному представлению информации наиболее распространённый.
Но всё-таки чтобы полноценно тестировать невизуальную доступность вам надо либо очень глубоко самому погружаться в тему, отключая монитор и серьёзно осваивая программы экранного доступа, либо привлекать дополнительного специалиста. Однако не всё так страшно, и если просто верстать с применением структуры HTML и корректно подписывая картинки и кнопки, то значительную часть проблем вы решите автоматически.
Машинной проверки однозначно недостаточно. Существуют инструменты для автоматического тестирования доступности web-страниц, но они помогают лишь частично. Как правило, всё сводится к примерной оценки контрастности цветовой схемы, плюс отлавливанию вещей типа отсутствующего или пустого атрибута alt у картинок. По-хорошему тестироваться должно руками.
Цветовые аспекты вы можете проконтролировать самостоятельно:
Во-первых, в принципе изначально верстать с учётом достаточной контрастности текста и фона, а также без использования опасных цветовых пар, типа красного и зелёного рядом, так как это наиболее частая проблемная пара у дальтоников. Ну и шрифт адекватных размеров.
Во-вторых, существуют инструменты, позволяющие просмотреть картинку с эмуляцией различных нарушений зрения.
Но вообще если вы используете адекватную цветовую схему, то, как правило, этого уже достаточно. К тому же люди с серьёзными нарушениями зрения, но при этом ещё работающие визуально, применяют специализированное ПО, которое выводит на дисплей модифицируемую картинку: экранное увеличение плюс подмена одних цветов на другие.
Что касается пользователей с нарушениями моторики, то тут вы также можете протестировать самостоятельно. Просто отложите мышь и поработайте со своим сайтом чисто с клавиатуры, попробовав проделать все предполагаемые пользовательские сценарии.
Тут вам пригодится атрибут tabindex, который позволяет включить элементы в цепочку клавиатурного фокусирования, а также задать порядок их перебора. Плюс для повышения удобства навигации с клавиатуры можно добавить вверху страницы ссылку «Перейти к основному содержимому», при нажатии на которую фокус будет перебрасываться к началу основной области (делается внутристраничной ссылкой — href="#main"), а также внизу страницы ссылку «Перейти наверх страницы», которая будет перебрасывать в самое начало. Это даст возможность быстрого перемещения без необходимости скролить.
Невизуальная доступность — это самое сложное, потому что принципы взаимодействия и получения информации здесь принципиально иные.
По-хорошему, если речь идёт о большом и сложном проекте, то лучше привлекать специального тестировщика или вообще внедрять в команду QA-инженера по accessibility, который сможет не только тестировать, но и давать конкретные рекомендации на техническом языке, плюс будет обладать широкими знаниями различных вспомогательных технологий и их специфики на различных платформах.
Самостоятельно вы также можете попробовать протестировать невизуальную доступность, но для этого вам придётся освоить программы экранного доступа и принципы работы с web-контентом через них, а они отличаются. К тому же в этой сфере есть несколько разных концепций представления экранной информации, поэтому освоение одной программы не даст полного покрытия темы.
Впрочем, какую-то базовую вещь протестировать можно и самостоятельно. Например, когда вы будете только осваивать WAI-ARIA, вы сможете хотя бы проверить, действительно ли сделанный chackbox корректно читается, а его состояние отмеченности и неотмеченности распознаётся. Для таких целей я бы, пожалуй, рекомендовал свободную программу экранного доступа для Windows — NVDA. К тому же она одна из самых популярных, и используемый в ней подход к невизуальному представлению информации наиболее распространённый.
Но всё-таки чтобы полноценно тестировать невизуальную доступность вам надо либо очень глубоко самому погружаться в тему, отключая монитор и серьёзно осваивая программы экранного доступа, либо привлекать дополнительного специалиста. Однако не всё так страшно, и если просто верстать с применением структуры HTML и корректно подписывая картинки и кнопки, то значительную часть проблем вы решите автоматически.
Спасибо за развёрнутый ответ. Вообще я сторонник хороших контрастных схем, которые не режут глаз и легко читаются, и линейной подачи информации в формах, так что видимо всё не так уж и сложно адаптируется при желании.
Осталось ещё как-то разъяснять людям, что доступность — это правильно, ведь обычно она вместе с автоматизированным тестированием отходит на второй план, если вообще об этом хотя бы задумываются.
Осталось ещё как-то разъяснять людям, что доступность — это правильно, ведь обычно она вместе с автоматизированным тестированием отходит на второй план, если вообще об этом хотя бы задумываются.
К сожалению, главные проблемы лежат в сфере невизуального взаимодействия с интерфейсом, а там очень много подводных камней. То, как воспринимается сайт через screenreader, это совершенно другой мир. Внешне красивые сайты могут быть ужасно неудобными для чтецов экрана, и наоборот. Впрочем, визуальная красота и невизуальная доступность могут сосуществовать, так что это не устойчивая зависимость.
Accessibility в организационном процессе разработки мне скорей напоминает informational security: также обычные разработчики не понимают, зачем их грузят какими-то непонятными вещами, которые никому не видны и обижаются на тестировщиков, которые находят какие-то непонятные ошибки, плюс об accessibility вспоминают обычно лишь при появлении жалоб пользователей, так же как об informational security — когда происходит инцидент.
Если вам нужно протестировать какой-то проект на невизуальную доступность, то пишите. Постараюсь помочь.
Accessibility в организационном процессе разработки мне скорей напоминает informational security: также обычные разработчики не понимают, зачем их грузят какими-то непонятными вещами, которые никому не видны и обижаются на тестировщиков, которые находят какие-то непонятные ошибки, плюс об accessibility вспоминают обычно лишь при появлении жалоб пользователей, так же как об informational security — когда происходит инцидент.
Если вам нужно протестировать какой-то проект на невизуальную доступность, то пишите. Постараюсь помочь.
Sign up to leave a comment.
Стандарт WAI-ARIA 1.0 получил официальный статус рекомендованного W3C: чего ожидать в будущем и куда бежать уже сейчас?