Перевод подготовлен Ксенией Блэйк.
Когда речь заходит о тестировании веб страниц или мобильных приложений на доступность, предполагается, что человек, который постоянно использует программу экранного доступа, больше всего подходит на эту роль. Безусловно, если вы постоянно работаете с подобными программами, то невольно со временем становитесь экспертом в данной области. Вы способны обнаружить специфические дефекты доступности, которые скорее всего никто другой даже не заметит. Кроме того, есть определенные задачи, которые эксперты программ экранного доступа могут выполнить гораздо быстрее, чем специально обученный тестировщик или начинающий пользователь.
Многое зависит от первоначального уровня доступности веб-сайта или приложения, которое нужно анализировать, и даже эксперт может оказаться не в лучшем положении. Наихудший сценарий: когда сайт, который необходимо проверить на доступность, полностью недоступен. Это означает, что незрячий пользователь не сможет понять, что происходит на экране и провести полноценный анализ веб-сайта. Даже наполовину доступная часть доставляет незрячим экспертам неудобства. Например, когда часть содержимого скрыта, и вы не можете сравнить свое понимание структуры содержимого веб-страницы с тем, что в действительности отображено на экране. В течение 25-ти лет Я работаю в кампании TPGi как незрячий специалист по доступности. За это время все изменилось до неузнаваемости. Когда я составляла самый первый отчет, мы использовали браузер Internet Explorer 3.0 в связке с JAWS 3.0. Самыми часто проявляющимися проблемами были неподписанные изображения, формы без программного определения меток или заголовки, выполненные в виде обычного текста с изменённым шрифтом. Не смотря на то, что описанные выше проблемы существуют и по сей день, анализ доступности не казался таким уж сложным. Сегодня, во времена модифицированных виджетов и фреймворков, изолированных компонентов объектной модели документа DOM и различных средств обработки и представления графики, приходится разрабатывать более комплексные тестовые сценарии.
Итак, какие проблемы для незрячего специалиста наиболее сложны, и есть ли их решения? В этой статье я опишу только те, с которыми лично приходилось сталкиваться во время работы.
Интерактивные элементы управления промаркированы как простой текст
Я часто сталкиваюсь с тем, что интерактивные элементы управления веб-содержимым лишь внешне напоминают ссылки, кнопки или флажки. Как правило, их основной функционал — попросить пользователя предоставить или подтвердить личные данные, а также — добавить дополнительную информацию. Поскольку, судя по структуре кода, они не промаркированы при помощи собственно HTML, то и не попадают в порядок переноса клавиатурного фокуса с одного элемента на другой, а также не видны в списке выбора элементов заполнения форм или ссылок в JAWS. Поэтому пользователь программ экранного доступа их просто не замечает, когда перемещается по веб-странице.
А вот классический пример кода:
<p>В связи с огромным количеством заказов все операторы не доступны. Оставайтесь на линии и дождитесь ответа оператора.<span class=»button»>Узнать больше</span></p>
Элемент разделения контента DIV, который визуально похож на кнопку, на самом деле таковой не является, потому что для ее разметки не был использован стандартный язык HTML. Поэтому она и недоступна с клавиатуры. Но по некоторым названиям кнопок: «Узнать больше «или «Подробно» плюс CSS стили, кое-что нам все-таки становится известно. Еще одним примером некорректной (или ее еще называют нейтральной) маркировки интерактивных элементов управления являются виджеты, визуально похожие на лицензионное соглашение, где нужно подтвердить согласие с условиями договора, отметив соответствующий флажок. Для того, чтобы это сделать, я при помощи курсорных стрелок нахожу место, где примерно он должен располагаться, привожу JAWS К PC и затем нажимаю левую кнопку мыши. Если я понимаю, что содержимое экрана изменилось и появилась кнопка «Отправить», то все отлично, идем дальше. Если же этого не происходит, то я начинаю подробно исследовать код элемента под фокусом. Для этого я использую панель Веб-разработчика в Chrome или Firefox, что позволяет мне отследить его местоположение во вкладке «Элементы», в которой отражается объектное представление документа веб-страницы. Далее — по типу элемента тэгам <SPAN> или CSS-классу например, это может быть радио кнопка или флажок. Я пытаюсь выявить скрытую информацию, которая всплывает по щелчку мыши. Пример — код: <input type=»checkbox»> or <input type=»radio»> controls, class=»checkbox/radiobutton».
Если на экране ничего не меняется, то я анализирую программный код соседних элементов на наличие непосредственно самой функции обработки щелчка мышью. Если ни один из данных методов не срабатывает, тогда приходится применять старый проверенный способ – спросить коллег о том, что происходит на экране и свериться — действительно ли элемент под курсором является интерактивным или не является.
Решение
Пользователи программ экранного доступа должны иметь возможность видеть все роли интерактивных элементов. Поэтому для маркировки ссылок <a, кнопок — <button> и флажков <input type=»checkbox»>. должен использоваться стандартный язык HTML, который гарантирует полный клавиатурный доступ. Если же по какой-то причине не возможно использовать стандартные метки для маркировки элементов управления, то дополнительный атрибут, показывающий его роль, должен быть добавлен. Например: <div role=»button»>Узнать больше о количестве заказов</div>. Но добавление данного атрибута предполагает дополнительное использование JavaScript для клавиатурной поддержки, чтобы элемент активировался при нажатии Enter или пробела.
Визуальное, а не структурное отображение состояния элемента
Такие проблемы чаще всего встречаются, когда нужно создать пользовательский профиль или удалить товары из корзины в онлайн супер-маркете. Шкала прогресса, которая показывает состояние заказа, как правило, располагается чуть выше самого содержимого формы. Визуально этот процесс можно определить по изменениям начертания шрифта или цвета текста. Но для программ экранного доступа нет структурного понимания текущей ступени шкалы прогресса. Вот типичный пример:
<ol class=»steps»>
<li>Контактная информация</li>
<li class=»текущая позиция« информация об оплате»</li>
<li>Авторизация платежа</li>
</ul>
Визуально данный текст может иметь древовидную структуру, в которой при помощи стиля подчеркивания указывается текущее состояние процесса выполнения задачи. Но для меня, как незрячего пользователя, это все равно не понятно.
у программы JAWS есть две очень полезные функции, без которых я, как незрячий эксперт по доступности, не могу обойтись. Это:
- определение шрифта, которое осуществляется по нажатию клавиши Insert+F
- Определение цвета текста и фона, которое осуществляется по нажатию клавиши 5. Когда я нажимаю Insert+F, JAWS сообщает размер и тип шрифта, а также выравнивание текста под курсором. А при нажатии клавиши5JAWS проговаривает цвет и фон символа под курсором. Таким образом я могу сравнить визуальное оформление содержимого формы редактирования и той информации, что находится выше. Если же Jaws не сообщает ничего полезного, то я анализирую код данного элемента. Но теперь я уже обращаю больше внимания на CSS. Если же класс выделенного элемента отличается от не выделенного, я найду местоположение данного класса в «Панели разработчика» в браузере и посмотрю, какие визуальные изменения в нем прописаны.
Кажется, что это очень долгий процесс, но на самом деле — не совсем так. Он дает мне глубокие знания и помогает правильно выбрать решение для клиента.
Решение
К тому элементу, который указывает на конкретную позицию в шкале прогресса или страницу в списке, нужно добавить атрибут aria-current. Пример: <ol id=»Steps»> <li>Контактная информация</li> <li aria-current=»текущая позиция»>Информация об оплате</li> <li>Авторизация платежа </li></ol>
Снимки экрана
Когда я стала серьезно заниматься доступностью, то сразу поняла, что разработчикам проще понимать дефекты доступности, когда отчеты сопровождаются снимками экрана или Скриншотами. На снимке должен быть изображен сам код, а также содержимое вокруг него. Таким образом, у разработчика есть определенный контекст, от которого нужно отталкиваться. Но как это сделать незрячему человеку, особенно проблематично – делать захват активного элемента под курсором. В этом нам поможет Firefox или Chrome, в арсенале которых есть соответствующие инструменты. Например: когда я анализирую конкретный элемент, то нажимаю контекстное меню и выбираю «захватить точку на экране». Если мне нужно добавить контекст, то я захватываю код исходного элемента. Если же я не уверена, что сделала все правильно, то нахожу файл на диске и нажимаю Insert+пробел+O,F. И JAWS распознает код на картинке. Это, конечно, не самое удобное решение. Иногда приходится просить сотрудников, делать более точные снимки экрана с выделением конкретных частей. Но в любом случае, большую часть работы я могу выполнять самостоятельно. И это приятное чувство.
Проблемные области тестирования
Не смотря на достигнутые успехи, есть некоторые критерии тестирования, которые практически невыполнимы при помощи программ экранного доступа. Например: не видя экран, незрячему специалисту будет очень сложно понять, обрезан ли текст или он наслаивается на другую область содержимого при разных размерах, разрешениях или ориентации экрана. Распознавание снимка экрана дает мне лишь некоторые сведения о том, есть ли содержимое на экране или нет, но я не могу в деталях описать проблему и посоветовать ее решение. Также я стараюсь избегать проблем со шрифтом, цветом текста и отступами на строке. А еще картинок, на которых изображены чарты или диаграммы. Там, где возможно, я также не тестирую клавиатурный фокус, поскольку JAWS имеет свойство добавлять дополнительные элементы куда не нужно. Например: он иногда видит скрытые элементы, которые по замыслу разработчика не должны быть видны в принципе.
Заключение
В кампании TPGi мы создали рабочую таблицу Excel, где в один столбец поместили все критерии доступности WCAG 2.1, которые содержат критерии успеха A – приемлемый уровень и AA высокий.
Мы разделили столбец на две части: критерии — тестирование со зрением и без. Я могу протестировать примерно две третьих из всего имеющегося. Конечно, в идеале я бы хотела иметь возможность самостоятельно делать весь отчет, и я продолжу идти к своей цели. Но пока даже у меня есть предел..
Оригинал статьи: Isabel Holdswort Accessibility testing as a screen reader user