Доступность в редакционном процессе

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

В последней главе вы подготовите редакционный процесс для ProfessorWeb, опираясь на стенд a11y-lab и отчёт четырнадцатого урока. Диалог и видео остаются необязательными прототипами. Мы не объявляем соответствие всего действующего сайта по результатам учебного примера.

Автор и общий шаблон

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

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

Для рисунка сначала выбирается роль: информативный объект, повтор уже имеющегося текста или декоративное дополнение. Затем появляется соответствующая альтернатива. Универсальное правило «всем картинкам пустой alt» удобно для формы, но теряет смысл. Универсальное «всем длинное описание» создаёт другую проблему — лишнее повторение.

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

Состояния материала

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

Условный реестр может иметь следующую форму. Это шаблон данных; строки наблюдений заполняются после фактической работы:

material_id,permalink,content_review,template_version,scenario,environment,observed_result,limitation,responsible,status

content_review относится к смыслу и альтернативам, template_version — к общей оболочке, scenario — к действию читателя. Поле observed_result не заполняется ожидаемым эффектом из урока. limitation позволяет прямо указать, что ещё не рассмотрено.

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

Состояние «не проверено» является полноценной записью. Оно отличается от «не работает» и от «соответствует». Неизвестность помогает выбрать следующую задачу и не создаёт фиктивной уверенности. В основной части серии именно так отмечены будущие наблюдения стенда.

Проверка по типам материалов

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

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

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

WAI рассматривает доступность как часть планирования, выполнения и сопровождения проекта. Planning and Managing Web Accessibility. Наш процесс использует этот принцип, но конкретные роли и набор материалов выбраны для учебной библиотеки, а не объявлены единственной обязательной организацией.

Серьёзность по препятствию

В отчёте полезно описывать влияние на действие. «Кнопка не имеет понятного имени» объясняет риск выбора, а «мелкая ошибка ARIA» мало говорит читателю. Серьёзность зависит от того, блокирует ли проблема задачу, существует ли другой доступный путь и насколько широко затронут компонент.

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

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

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

Граница заявления о соответствии

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

WAI описывает подходы к оценке и отчётам о соответствии. Conformance Evaluation and Reports. Для нашего курса точнее говорить о подготовленных компонентах и будущих сценариях, чем объявлять всю библиотеку соответствующей на основании нескольких учебных файлов.

Также отделяйте доступность от индивидуального предпочтения. Человек может любить другую тему или более узкую строку, даже если конкретный критерий соблюдён. Наблюдение предпочтения полезно дизайну, но не заменяет проверку требования. Обратное тоже верно: выполнение численного минимума не гарантирует одинаковое удобство каждому читателю.

Регламент для следующего автора

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

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

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