В последние несколько лет компании, занимающиеся цифровой доступностью, начали разрабатывать инструменты с помощью которых, как они утверждают, можно автоматически обнаруживать проблемы доступности веб-страниц и программ. Говорят, что автоматизированное тестирование еще не совсем развито, но через несколько лет произойдет революция в данной области. Я в это не верю.
Проблемы человека должен решать человек
По своей сути, доступность — это взаимодействие людей с компьютерами. Пользователи применяют различные технологические решения для доступа к вашему контенту. Иногда этот способ — программа экранного доступа, программное обеспечение для увеличения, голосовое управление или разные контроллеры. В других случаях, нет необходимости использовать какие-либо аппаратные или программные средства доступности, улучшающие взаимодействие пользователя с ПК. Кроме того, существует множество писаных и неписаных правил, применимых к адаптации пользовательского интерфейса. Например, понятно ли то, как происходит взаимодействие пользователя с ПК при работе с разными операционными системами? Могут ли различные API, связанные со специальными возможностями, представлять определенный элемент пользовательского интерфейса?
Такое уже было раньше с компонентом Treeview, который редко используется вне Windows 98. Нет никаких правил, запрещающих использование данного компонента, однако сделать его действительно доступным вместо того, чтобы просто адаптировать его под какую-то «бездушную спецификацию», практически невозможно.
Результаты автоматического тестирования на доступность должен трактовать человек
Конечно, поиск проблем с доступностью может оказаться непростой задачей. Но настоящая загвоздка заключается в том, как решить найденную проблему. Программа может сделать вывод, что элемент блока <div> с атрибутом role="link" — недоступен для взаимодействия с помощью клавиатуры. Но в чем заключается путь разрешения данной проблемы, может быть непонятно человеку, который будет читать результаты проверки.
Обычно можно заменить элемент <div> элементом <a>, но в других случаях правильным советом будет являться полное удаление role="link". Может ли какой-нибудь инструмент на базе искусственного интеллекта, ML или что-то подобное разобраться в этом и предложить достойное решение? Может быть, когда-нибудь. Но реальность такова, что автоматическая проверка может дать вам неверный совет и для программы всё будет выглядеть так, будто вы исправили проблему доступности, но на самом деле этого не произошло.
Автоматическое тестирование довольно примитивно
В этом году WCAG 2.0 (Web Content Accessibility Guidelines — Руководство по обеспечению доступности веб-контента версии 2.0, прим. переводчика) уже 15 лет. И хотя инструменты, помогающие в так называемом исследовательском тестировании (прим. 1), стали лучше и более эффективно помогают тестировщикам в том, что необходимо сделать, чтобы исправить ту или иную ошибку, большинство подобного рода программ по-прежнему очень заурядны. Адриан Розелли (Adrian Roselli) в своем блоге недавно сравнил результаты собственного исследовательского тестирования с результатами, полученными с помощью бесплатных инструментов автоматического тестирования.
Выводы неутешительны. В то время как Адриан обнаружил 37 ошибок по WCAG, наибольшее количество ошибок, найденных любым из инструментов проверки, составило пять. Ни одна программа не обнаружила нарушений на уровне AA, хотя Адриан нашёл 11. Программы для автоматического тестирования также могут показывать предупреждения, полезные для тестировщика, но по моему опыту, они могут привести к ещё большей путанице, особенно, когда пользователи подобных инструментов недостаточно опытны.
В то время как обнаружение так называемых критериев успешности по WCAG, которые, как правило, оказывают наибольшее влияние на доступность для людей с ограниченными возможностями, можно назвать успехом, неспособность такого рода программ обнаруживать какие-либо критерии на уровне AA, очевидно, является их недостатком. Это ясно даёт понять, что нельзя полагаться только на автоматическое тестирование для достижения минимального уровня доступности AA.
Эффективное автоматизированное тестирование лучше всего помогает предотвращать ухудшение качества
Хоть я и думаю, что инструменты автоматизированного тестирования не очень эффективны для выявления проблем с доступностью и их устранения, такие средства могут помочь поддерживать доступность веб-сайта или приложения. Существенные проблемы будут обнаруживаться на ранних стадиях, если вы будете регулярно проверять код и проводить автоматическое тестирование доступности. Будет ещё лучше, если вы станете придерживаться тех норм создания доступного сайта, которые лучше всего работают на практике. Возможность сравнения с передовыми методами проверки всегда полезнее, чем просто использование инструмента автоматизированного тестирования.
Может ли ситуация стать лучше в будущем?
Может быть. На данный момент трудно оценить будущее нашего сообщества. С одной стороны, некоторые аспекты становится легче тестировать, с другой стороны, время от времени вводятся новые требования. И тогда есть простор для интерпретации правил и относительно того, как их применять. Также не учитывается то, что Интернет — это волшебная и гибкая среда, которую можно адаптировать ко множеству вещей.
Но ручное тестирование — это сложно и дорого
Это правда. Но нужно, как бы вам не хотелось, прибегать к данной процедуре.
В конечном счете, нет никакого способа обойтись без данного вида тестирования и с этим ничего не поделаешь. И хотя вы ожидаете, что разработчик будет знать достаточно для того, чтобы проверять свой код на наличие ошибок, таких как производительность и безопасность, нам также необходимо научить их проводить данные тесты. Дело не в том, что это полностью исчерпает необходимость в исследовательском тестировании, но это, безусловно, могло бы предотвратить использование программ для нахождения ошибок доступности.
Инструменты для автоматизированного тестирования должны работать непрерывно, а проблемы устраняться немедленно. Вот в каком случае эти инструменты полезны. Во всех остальных случаях — автоматизированные инструменты могут оказаться слишком сложными для понимания пользователями, которые не являются экспертами в области доступности. И как только они получат достаточно знаний, чтобы разобраться в таких программах, больше не будет нужды в автоматизированном тестировании.
Обновление от 15 февраля 2023 г.
В своём блоге Карл Гровз опубликовал запись под заголовком «Автоматизация — не враг», где он намеренно приводит название этой статьи без ссылки на нее (что, по моему мнению, справедливо). Как фанатик в области автоматизации, я с энтузиазмом соглашаюсь с тем, что она — наш друг. Я автоматизирую свою жизнь донельзя. У меня есть клавиатурный контроллер Stream Deck, с помощью которого по нажатию одной кнопки можно переключаться между различными почтовыми аккаунтами и многое другое (в зависимости от выполняемой мной работы).
Но, особенно при тестировании доступности, пользователи инструментов автоматизации должны понимать, что такие программы сильно ограничены, с чем Карл также согласен:
Это правда, что существует множество недостатков, когда дело доходит до автоматизации чего-либо, например, тестирования на доступность.
К сожалению, следует отметить, что ни один инструмент автоматизированного тестирования доступности, представленный сегодня на рынке, не может в полной мере обнаружить все возможные проблемы. Фактически, некоторые критерии успешности не могут быть проверены ни одним из доступных в настоящее время инструментов.
Karl Groves
Однако я не понимаю, как он пришёл к изложенной следующим образом мысли:
Тем не менее, безответственно заявлять, что автоматизированное тестирование — это плохо и его следует избегать.
Потому что я не думаю, что кто-то так говорил. По крайней мере, я не упоминал об этом в своей статье. Краткое обобщение того, что я писал такой: «инструменты автоматизированного тестирования имеют ограничения (следовательно, сами по себе они не могут решить проблемы цифровой доступности), и люди должны знать об этих ограничениях».
Некоторое время назад одна компания, конкурирующая с другими в области автоматизированного тестирования, заявила, что их программа Tenon способна обнаружить более 70% проблем, связанных с цифровой доступностью. А потом показала (правда объяснения выглядели достаточно сомнительно), как компания пришла к такому результату. Я решил провести собственное исследование. Что я обнаружил, основываясь на данных этой программы, так это то, что мои собственные выводы из написанного мною в 2012 году в блоге поста «Что и как можно тестировать» по-прежнему верны. Однако существует довольно большая разница между словами «возможно» и «вероятно», и инструменту Tenon.io удалось обнаружить 59% вероятных проблем с доступностью.
Я не думаю, что что-то из вышесказанного противоречит тому, что я писал ранее. Я прямо заявляю: «Хотя обнаружение нарушений критериев уровня А (которые оказывают наибольшее влияние на людей с ограниченными возможностями) можно назвать успехом, неспособность такого рода программ обнаруживать ошибки критериев на уровне AA является их недостатком».
И да, Тест Адриана ограничивается только одним сайтом, но его результаты совпадают с моим опытом. Проблемы на уровне A, как правило, возникают с большей вероятностью, чем проблемы на уровне AA. Как отмечает Карл, очень важно, под каким углом вы смотрите на результаты. 60% найденных вероятных проблем с доступностью – это хороший результат, но мы не можем назвать это «решением данных проблем», — и мы все с этим согласны.
Инструменты для автоматизированного тестирования за последние годы стали лучше не только в том, сколько ошибок они находят. Совместимость — вот ещё один из аспектов. Существует рабочая группа W3C (World Wide Web Consorcium — Консорциум Всемирной паутины, прим. переводчика), которая следит за тем, чтобы программы использовали одинаковые тесты для схожей интерпретации данных. И это хорошо. Я не утверждаю, что данные инструменты не совершенствуются, просто их потенциал невелик. Эти ограничения проистекают из того, как следует рассматривать цифровую доступность: проблема человека, которую нужно человеку и решать и в тоже время из того, какие стандарты по доступности написаны.
Наконец, Карл делает важное замечание о том, что автоматизированные инструменты, которые регулярно используются квалифицированными специалистами по обеспечению цифровой доступности, могут ускорить, дополнить и помочь в ручном / исследовательском тестирование. И я полностью согласен. Профессионалы используют инструменты и знают их недостатки, а также то, как интерпретировать результаты. Но это не означает, что дилетанты могут использовать такие программы в расчете на аналогичный успех.
Заключение
Я рекомендовал клиентам, которым, по моему мнению, это подходило, использовать Tenon.io. Я регулярно советую людям использовать axe (инструмент автоматической проверки доступности), но также говорю, что им может понадобиться профессионал, который объяснит результаты или порекомендует наилучшие методы решения возникших проблем. Советую обращаться к экспертам, если вы не уверены в результатах или как устранить ошибки.
Примечание:
↑ Говоря о доступности, мы обычно называем это «ручным тестированием», но несколько лет назад я узнал, что QA-тестировщики вместо этого используют термин «исследовательское тестирование». Поскольку тестирование на предмет цифровой доступности включает в себя множество примеров изучения контента с помощью различных инструментов и вспомогательных технологий, я решил использовать данный термин.
Перевёл Владислав Бондаренко
Автор статьи: Eric Eggert
Источник: Automated testing won’t solve web accessibility · Eric Eggert