Доступность — это не только техническая задача, но и задача управления процессом.
Это означает, что организации и проекты должны постоянно интегрировать доступность в процесс проектирования, разработки и тестирования. Это требует наличия команды, опыта и приверженности, а также лидерства.
Оглавление
1. Ответственность за доступность
2. Процесс веб-разработки
2.1 Фаза планирования / проектирования
2.2 Фаза создания / реализации
2.3 Фаза тестирования
3. Серьезное отношение к доступности
3.1 Управление временем
В этой статье я хотел бы указать на некоторые рекомендуемые шаги, которые необходимо предпринять при реализации плана обеспечения доступности ИКТ (информационно-коммуникационных технологий) для отдельного проекта или организации, которые очень хорошо описаны Инициативой W3C по веб-доступности (WAI) в разделе «Планирование и управление веб-доступностью».
Они также предоставляют руководство по немедленному устранению барьеров доступности на существующих веб-сайтах в разделе Web Accessibility First Aid: Подходы для промежуточного ремонта.
1. Ответственность за доступность
Несколько недель назад меня пригласили на сессию вопросов и ответов о том, кто несет ответственность за доступность. Все участники согласились с тем, что для интеграции доступности в проект или, в более широком смысле, в организационную культуру нужна команда.
Как команда, вы должны установить цели по внедрению доступности или адаптировать внутренние стандарты, лучшие практики и инструменты, необходимые для интеграции доступности. Также было бы полезно создать руководство по доступности не только для конкретного проекта, но и для всей организации.
По аналогии с процессом Scrum, где Scrum-мастер отвечает за то, чтобы Scrum-команда успешно внедряла Scrum-структуру и не допускала препятствий, было бы полезно иметь в команде эксперта по доступности (или внешнего консультанта) для поддержки команды и обеспечения того, чтобы все члены разрабатывали с учетом доступности на протяжении всего процесса веб-разработки.
2. Процесс веб-разработки
При определении процесса веб-разработки в рамках гибкого рабочего процесса процесс начинается с планирования продукта, затем следует фактическое создание продукта, и последнее — его надлежащее тестирование.
Этот цикл повторяется для каждой задачи до тех пор, пока задачу нельзя считать выполненной. Давайте подробнее рассмотрим каждый этап процесса веб-разработки.
2.1 Этап планирования/проектирования
При разработке продукта доступность должна учитываться с самого начала. Поэтому, проводя исследования, убедитесь, что люди с ограниченными возможностями также будут пользоваться вашим продуктом.
Когда дело доходит до установления требований, определите не только цели маркетинга и продаж, но и цели доступности, такие как стандарты доступности и лучшие практики.
Большая часть внедрения доступности в процесс может быть выполнена при проектировании информационной архитектуры и пользовательского опыта. Помните о том, о чем нужно думать при разработке продукта с учетом доступности.
Вот несколько примеров того, что должно быть частью информационной архитектуры:
Проектирование для настольных и мобильных компьютеров
Взаимодействие очень различно. На настольном компьютере пользователи в основном используют мышь и/или клавиатуру, а на мобильном — сенсорный экран, набирают текст и стирают его одним, двумя или тремя пальцами. Совместимость с программами чтения с экрана на настольных компьютерах отличается от совместимости с программами чтения с экрана на мобильных устройствах. Решите, какие браузеры следует поддерживать.
Проектирование для зрячих и слепых пользователей клавиатуры
Зрячие пользователи клавиатуры нуждаются в полной функциональности клавиатуры и визуальном индикаторе фокуса. Они должны иметь возможность перейти непосредственно к основному содержанию, минуя навигационное меню. Динамические виджеты должны быть полностью работоспособными (для предотвращения залипания клавиатуры).
Для слепых пользователей должна быть предусмотрена надлежащая семантическая разметка. Структура DOM должна быть разделена на ориентиры с использованием правильной структуры заголовков.
Создатели контента уже могут предоставлять альтернативный текст для изображений. Они также создают контент таким образом, чтобы он был понятен любому пользователю.
Пользовательские виджеты создаются с разметкой ARIA для совместимости с программами чтения с экрана.
Проектирование для пользователей с нарушениями зрения, такими как слабое зрение или дальтонизм
Лучше всего уже иметь систему проектирования и прототипы продукта с использованием инструмента проектирования, такого как Figma или Adobe XD, где можно визуализировать структуру файлов, установить цвета с достаточной контрастностью, которые никогда не используются в одиночку для передачи информации, и доступную типографику.
Компоненты должны быть правильно спроектированы, а прототипы представлены для настольных компьютеров, планшетов, мобильных устройств и при увеличении до 400%.
Проектирование для пользователей с нарушениями слуха
Визуальные дизайнеры должны создавать прототипы для видео- и аудиоматериалов, которые включают видеоподписи и транскрипты.
Проектирование для пользователей с когнитивными нарушениями
Создатели контента должны предоставлять альтернативный текст для изображений, учитывая лучшие практики, например, не писать текст длиннее 150 символов, так как некоторые программы чтения с экрана не читают весь текст и внезапно останавливаются. Кроме того, пользователи не могут приостановить работу скринридера на альтернативном тексте.
Составители контента также должны создавать контент, понятный любому пользователю, и сохранять короткие и простые предложения.
2.2 Этап создания/реализации
Когда есть четкие инструкции, полученные на предыдущем этапе планирования, веб-разработчикам гораздо проще создавать эти компоненты и делать их доступными. Им больше не нужно думать о том, как оформить компоненты, какой цвет или шрифт использовать, и можно приступать к кодированию.
Что-то, что действительно помогло бы работать с проверенными компонентами, оставаться последовательным в коде и гарантировать качество кода, — это библиотека компонентов, созданная, например, с помощью Storybook или Pattern Lab.
Разработчики, обладающие высоким уровнем знаний о том, как писать доступный код, могут создавать компоненты и тестировать их перед внедрением.
Еще одним преимуществом библиотеки компонентов является то, что новые разработчики, которые приходят в проект позже, или разработчики, которые не так хорошо знакомы с доступностью, могут посмотреть на любой компонент в библиотеке, просто скопировать его и сразу же использовать, не беспокоясь об этом.
Создание компонентов
При создании компонентов разработчик должен быть уверен, что использует правильный семантический HTML (совместимость с определенными браузерами) для структурирования макета (ориентиры), добавляет alt-текст ко всем встроенным изображениям и соблюдает логический порядок чтения.
Разработчик должен понимать, что дерево DOM — это фактический порядок чтения, которому следует экранное устройство чтения, и должен уметь правильно использовать стили CSS и знать преимущества и недостатки некоторых атрибутов.
При создании пользовательских компонентов и виджетов, разработчик должен быть внимательным, чтобы использовать правильную разметку ARIA.
2.3 Этап тестирования
Когда дело доходит до тестирования, важно, чтобы тестировщик Q&A знал, как тестировать на доступность и когда требования выполняются.
Тестирование разметки фронтенда
Первым шагом будет использование автоматизированного тестирования (если оно еще не интегрировано в процесс разработки) с помощью таких инструментов, как axe. 30% проблем уже можно устранить таким образом.
Основная часть тестирования по-прежнему выполняется вручную. Так, использование сайта и его виджетов только с помощью клавиатуры или скринридера должно быть выполнено и проверено тестировщиком самостоятельно.
Это, конечно, включает в себя кроссбраузерное тестирование и различные комбинации браузеров и скринридеров, потому что каждый скринридер ведет себя по-разному в зависимости от браузера.
Рецензенты должны знать, что даже если все компоненты и виджеты прошли тестирование на доступность, это не обязательно означает, что они полностью доступны при совместном использовании на веб-странице.
Поэтому при создании страницы необходимо провести дополнительное тестирование. Кроме того, тестировщики должны обеспечить логический порядок чтения, иерархию заголовков для разделов и контента, а также понятность.
Если возникают проблемы, тестировщики отвечают за описание дефектов с помощью подробных пользовательских историй доступности, инструкций по воспроизведению ошибок и изображений, критериев приемки и т.д.
3. Серьезное отношение к доступности
Если к доступности с самого начала отнеслись серьезно, велики шансы, что потребности пользователей будут удовлетворены. В противном случае почти гарантировано, что на сайте будут проблемы с доступностью, которые не позволят пользователям с ограниченными возможностями использовать сайт должным образом.
В этом случае на помощь приходит модернизация. И я уверен, что все мы не заинтересованы в том, чтобы играть в эту игру.
Вы всегда должны спрашивать себя:
Будет ли лучше исправить старый дизайн или лучше начать все с чистого листа и создать новый дизайн правильным образом, со встроенной доступностью?
3.1 Управление временем
Компании часто обеспокоены тем, сколько дополнительного времени занимает обеспечение доступности. При правильной реализации с самого начала, как описано выше, задачи доступности добавляют максимум 5% к общему времени разработки, что, на мой взгляд, вполне приемлемо, в отличие от удвоения или утроения времени (и стоимости), если доступность добавляется в конце процесса разработки или намного позже.
Спасибо, что прочитали и уделили время. Я очень ценю это!