Читательские задачи и барьеры

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

В этой серии рассмотрим отдельный учебный проект a11y-lab. За основу возьмём устройство ProfessorWeb: общая навигация, длинная статья, блоки кода, изображения результата и переходы между уроками. Примером содержания будет материал «Запросы LINQ to XML». Его старый адрес /my/LINQ/linq_xml/level7/7_1.php сохраняется. Мы будем изменять учебную оболочку, а не смысл запроса или путь существующей страницы.

Задача важнее списка элементов

Рассмотрим читателя, который хочет понять разницу между спуском по конкретной ветви XML и методом Descendants. Для него статья начинается не с футера и не с цветовой палитры. Сначала он должен убедиться, что открыл нужную тему. Затем найти раздел о потомках, прочитать выражение, сопоставить его с данными и понять ограничение: одинаковые имена элементов могут встречаться в разных ветвях дерева.

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

Для нашего стенда зафиксируем три сценария. Первый — найти раздел Descendants через оглавление. Второй — сравнить код с текстовым результатом. Третий — открыть каталог прежних уроков, понимая назначение ссылки. Каждый сценарий имеет собственную границу: переход на статью ещё не означает, что пример прочитан, а прокрутка до конца не доказывает понимание метода. Эти различия пригодятся при дальнейшем обсуждении аналитики.

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

Условия чтения и управления

Сайт может использоваться без мыши. Тогда последовательность клавиши Tab становится маршрутом по интерактивным элементам: ссылкам, кнопкам и полям. Если над статьёй расположены десятки ссылок, повторять их на каждой главе неудобно. Переход к основному содержимому сокращает этот путь. Его назначение следует из сценария чтения, а не из желания добавить ещё один декоративный элемент.

При увеличении текста меняется количество строк и доступная ширина. Фиксированная высота карточки, которая выглядела аккуратно в одном масштабе, может скрыть название следующего урока. Читатель уже не понимает, куда ведёт ссылка. Здесь проблема заключается не в самом увеличении и не в длине русского названия, а в ограничении контейнера. Позднее проверим, как содержимое перестраивается и где допустима отдельная горизонтальная прокрутка.

Скринридер предоставляет другой способ изучить структуру: области страницы, заголовки, списки и доступные названия управления. Он не обязан произносить страницу точно так же, как другой скринридер. Однако разметка должна передавать отношения между частями содержания. Если заголовок изображён жирным абзацем, визуальный читатель видит начало раздела, а семантическое представление этого отношения отсутствует.

Отдельное условие — чтение результата без изображения. В старой учебной статье вывод программы может быть показан скриншотом. Короткая подпись «Результат» сообщает, что картинка существует, но не объясняет, какие значения получились. Для разбора запроса важно представить существенный вывод текстом. Это поможет и при недоступной картинке, и при копировании результата, и при работе с другим способом восприятия.

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

Реестр барьеров вместо выдуманного аудита

До выполнения проверки у нас есть предположения. Например, «закреплённый хедер может закрыть заголовок после перехода по якорю». Это основание для будущего сценария, но ещё не обнаруженный дефект ProfessorWeb. Чтобы не смешивать состояния, создайте в учебной папке файл barriers.csv. Ниже показаны вымышленные записи для обсуждения, а не отчёт действующего сайта:

id,scenario,condition,observation,state
A1,Перейти к Descendants,Клавиатура,Не проверено,hypothesis
A2,Сравнить результат с кодом,Изображение недоступно,Не проверено,hypothesis
A3,Открыть каталог прежних уроков,Увеличенный текст,Не проверено,hypothesis

Поле state отделяет предполагаемую проблему от воспроизведённой. После реальной проверки недостаточно заменить его на confirmed. Нужно дописать шаги, точное место, ожидаемое и фактическое поведение, сочетание браузера и средства управления. Тогда другой человек сможет повторить действие и оценить изменение. Формулировка «страница неудобная» не позволяет понять, что именно исправлять.

Представим учебное наблюдение: после перехода к #descendants заголовок целиком перекрыт закреплённой панелью. Из него следует конкретная задача для оформления якоря и прокрутки. Из него не следует, что все заголовки всех курсов скрыты. Для такого вывода понадобится более широкая выборка и проверка общего шаблона. Чем точнее граница наблюдения, тем меньше риск исправлять случай, который мы только предположили.

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

Критерии и границы вывода

В дальнейшем будем соотносить решения с WCAG 2.2, прежде всего с уровнем AA. Это набор проверяемых критериев, а не готовый дизайн страницы. Конкретный критерий помогает сформулировать условие приёмки, но его номер не заменяет объяснение влияния на читателя. Исправляя фокус, нужно понимать и видимость, и порядок, и поведение после действия.

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

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