Проблема С Инструментами Автоматического Тестирования Доступности

Автоматизированный инструмент обеспечения доступности — это часть программного обеспечения, которая может проверить веб-страницу или даже весь веб-сайт на доступность. Автоматизированные инструменты доступности полезны, потому что они могут сэкономить вам огромное количество времени. Не хотите проверять изображения на наличие замещающего текста на каждой странице вашего сайта? Запустите сайт через автоматизированный тестер, и он все сделает за вас!

Инструменты автоматического тестирования доступности существуют уже давно и исторически были полезным способом проверки веб-сайтов на доступность. Bobby, одному из первых и наиболее известных инструментов автоматического тестирования доступности, существует уже почти 10 лет, и хотя он больше не доступен в свободном доступе, существует множество других бесплатных инструментов, таких как WebXact (http://webxact.watchfire.com/). и Wave (http://wave.webaim.org/index.jsp) существуют.

Но не слишком ли хороши эти инструменты, чтобы быть правдой? Можете ли вы так легко проверить веб-сайт на доступность? К сожалению, ответ – решительное нет. Существует ряд основных проблем, связанных с использованием только автоматизированных инструментов для проверки доступности:

Буквальная интерпретация руководящих принципов

Любой автоматизированный инструмент тестирования доступности, будучи частью программного обеспечения, не имеет ничего общего со здравым смыслом. Он будет интерпретировать каждое руководство по доступности буквально, не задумываясь о том, что еще находится на странице.

Согласно словарю Dictionary.com, слово «руководство» определяется как «правило или принцип, определяющий надлежащее поведение». Руководство просто предлагает рекомендации относительно наилучшей практики – его не следует применять просто так, без учета других факторов.

Например, одно из рекомендаций W3C по обеспечению доступности гласит, что сводка таблицы должна быть предоставлена для всех таблиц. (Эта сводка не отображается на экране, но она зачитывается вслух пользователям программ чтения с экрана перед чтением содержимого таблицы.) Сводки таблиц полезны, поскольку они сообщают пользователям программ чтения с экрана, чего ожидать от таблицы. Однако непосредственно перед таблицей может быть заголовок, описывающий, о чем эта таблица. В этом случае это резюме по существу бесполезно, поскольку оно просто повторяет то, что говорилось в предыдущем заголовке.

Не могу проверить какие-либо проблемы с контентом

То, как контент структурирован как на странице, так и на веб-сайте, играет важную роль в обеспечении доступности. Веб-сайт может быть идеально закодирован и соответствовать самым высоким стандартам кодирования. Однако, если его контент плохо структурирован, сайт окажется трудным или невозможным для некоторых веб-пользователей с особыми потребностями.

Существует ряд важных аспектов доступного контента, ни один из которых не могут быть проверены автоматическими инструментами тестирования доступности. Некоторые из этих важных соображений включают в себя:

Контент загружается заранее, чтобы каждый абзац начинался с заключения.

Обеспечение того, чтобы контент был разбит на управляемые фрагменты с описательными подзаголовками.

Использование списков там, где это необходимо.

Обеспечение использования простого и понятного языка.

Не могу проверить многие проблемы с кодированием

Огромное количество рекомендаций по обеспечению доступности, как правило, связано с тем, как кодируется сайт. К сожалению, инструменты автоматического тестирования доступности не могут проверить многие из них. Примеры соображений доступности, связанных с HTML, которые эти инструменты не могут проверить, включают:

Обеспечение того, чтобы текст был реальным текстом и не был встроен в изображения.

Обеспечение работы сайта без использования JavaScript или Flash.

Предоставление эквивалентных текстовых ссылок при использовании карт изображений на стороне сервера.

Обеспечение того, чтобы структура HTML отражала внешний вид (например, заголовки помечаются как заголовки в коде HTML).

Используются устаревшие рекомендации.

Инструменты автоматического тестирования доступности обычно используют рекомендации W3C по доступности, которым уже более пяти лет. Таким образом, некоторые из этих рекомендаций устарели и больше не применяются. Фактически, сейчас считается, что некоторые из них скорее препятствуют доступности, чем помогают, поэтому лучше полностью игнорировать эти рекомендации.

Например, инструмент автоматического тестирования доступности, вероятно, будет настаивать на том, чтобы элементы формы содержали текст по умолчанию. Он также может настаивать на том, что ссылки должны быть разделены текстом, не относящимся к ссылкам. Ни одно из этих рекомендаций больше не актуально, и их реализация может скорее ухудшить доступность, чем улучшить ее.

Большинство рекомендаций не проверены должным образом

Автоматизированные инструменты обеспечения специальных возможностей могут проверять наличие ряда рекомендаций и сообщать вам, когда они не соблюдаются. Однако когда инструмент утверждает, что рекомендации выполняются, на самом деле это может быть ложной правдой.

Например, если все изображения содержат замещающий текст, программа сообщит о том, что это правило прошло успешно. Но что, если альтернативный текст не описывает изображение? Что, если альтернативный текст переполнен бессмысленными ключевыми словами для поисковых систем? Как автоматизированный инструмент доступности может знать это?

Предупреждения могут быть неправильно истолкованы

Отчеты, созданные автоматическими инструментами обеспечения специальных возможностей, содержат предупреждения, а также ошибки. Эти предупреждения по сути представляют собой рекомендации, которые автоматизированный инструмент не может проверить, но которые могут быть ошибками. Зачастую это не так, и на самом деле зачастую они даже не имеют значения. Однако некоторые люди, читающие отчет, могут попытаться избавиться от этих предупреждающих сообщений, внеся соответствующие изменения на свой сайт. Поступая таким образом, они могут внедрять рекомендации, которые не должны выполняться, и непреднамеренно снижать доступность веб-сайта.

Заключение

Инструменты автоматического тестирования доступности могут быть полезны, поскольку они могут сэкономить много времени при выполнении некоторых самых простых проверок доступности. Однако их следует использовать с осторожностью, и их нельзя использовать в качестве отдельного руководства для проверки доступности. Действительно, при оценке доступности сайта всегда следует применять некоторые экспертные знания о доступности, возможно, в сочетании с фантастической панелью инструментов веб-доступности (http://www.nils.org.au/ais/web/resources/toolbar/), чтобы существенно помочь ускорить ручные проверки.




В статье обсуждается и критикуется вопрос использования автоматизированных средств обеспечения доступности в веб-разработке. Это показывает, что этот метод не совсем соответствует требованиям доступности и ненадежен для проверки обширных частей веб-сайта.

Эти инструменты автоматического тестирования пытаются эффективно измерить, насколько доступна веб-страница для различных пользователей, в том числе для людей с плохим зрением или ограниченной мобильностью. Тем не менее, автоматизированные тесты доступности не оправдывают этих ожиданий из-за таких проблем, как буквальная интерпретация, неспособность идентифицировать контент и особенности кодирования, несовместимость с последними рекомендациями по доступу и индексирование нерелевантных уведомлений. Таким образом, опасно полагаться на то, что автоматизация тестов доступности обеспечивает лишь часть правды для безопасных мер оценки доступности.

Вместо этого эксперты предлагают полагаться на запрограммированные компьютерные программные инструменты, доступные для ручного тестирования в сочетании с оценкой набора элементов, составляющих веб-сайт, на различных уровнях доступности. Сочетание этих методов улучшает результаты за счет оценки как можно большего количества характеристик доступности.

Вместе с данным постом часто просматривают: