Перевод подготовлен Ксенией Блэйк.
Доступность имеет очень большое значение, поскольку интернет является основным средством коммуникации, получения образования, проведения досуга и социального взаимодействия. Однако для многих людей большинство из вышеперечисленного до сих пор является недоступным. В ходе анализа на доступность, недавно проведенного Web Aim для миллиона главных страниц сайтов, выяснилось, что 97,4 % из них имеют легко обнаруживаемые дефекты.
У участников ежегодной конференции TPAC , в которой принимают участие все группы, входящие в состав консорциума W3C, есть уникальная возможность собраться и подробно обсудить различные инициативы по продвижению доступности. Как правило, предложений всегда очень много, но они внедряются с трудом. Как мне кажется, причины кроются в структуре самой организации и вот почему: в консорциуме W3C, есть специальная инициативная группа (Web Accessibility Initiative), которая занимается поддержкой и продвижением доступности. Несмотря на то, что эта группа осуществляет проверку всех стандартов, первоначальная разработка большинства из них практически исключает доступность как таковую.
И даже у тех стандартов, которые имеют хоть какую-то поддержку доступности, есть проблемы с ее развитием. Единственный стандарт, где доступность, можно сказать, полностью реализована — это руководство (WCAG) 2. Есть еще такой стандарт как ATAG, созданный для разработки различных инструментов для редактирования веб-контента — блоги, социальные сети, видео, но лишь некоторые из них ему соответствуют и то частично.
UAAG 2.0, стандарт, который отвечает за доступность браузеров и пользовательских веб-агентов, был опубликован только в качестве небольшой заметки в соответствующей рабочей группе. К сожалению, достичь компромисса по поводу того, как сделать UAAG основным документом, содержащим требования по доступности браузеров, так и не удалось. Единственный стандарт с поддержкой доступности, который активно разрабатывается консорциумом W3C – это WAI ARIA — стандарт, присваивающий дополнительные роли, свойства и значения элементам — так называемый набор семантических атрибутов, которые добавляются к HTML для улучшения доступности интерактивных элементов. ARIA еще используется при создании электронных документов ePub и PDF.
Когда-то давно основной целью разработки стандарта была адаптация HTML-кода под API программы экранного доступа для создания комплексных решений. Теперь даже для простенького веб-сайта необходимо наличие ARIA. Например, если веб-страница содержит две основные зоны: горизонтально расположенное навигационное меню и его вертикальное подменю, это обычная практика дать им специфические названия. Поскольку в HTML не существует подобного механизма, то приходится использовать ARIA.
Доступность стала сложной и не предсказуемой
Для того чтобы сделать полностью доступный продукт, вы должны знать как все эти технологии взаимодействуют друг с другом. Как их можно объединить для наибольшего удобства пользователя. Первое, что вам нужно знать это, что такое доступное видимое название имя элемента (Accessible name) и переписывает ли атрибут aria-label значение атрибута aria-labelledby. По секрету скажу, нет, не переписывает.
W3C предоставляет документацию, которая называется «Практическое применение ARIA» (ARIA Authoring Practices, где можно узнать обо всех возможных вариантах употребления ARIA. Но в этих примерах не отражены гарантированные решения по использованию ARIA с HTML, поскольку ARIA считается технологически нейтральным стандартом. Есть, конечно, документ HTML Accessibility API Mappings, где показано взаимодействие ARIA и HTML через программные интерфейсы с поддержкой доступности, и спецификация the ARIA in HTML, где даются советы по использованию ARIA с HTML в целом, но этого мало.
Кроме всего прочего, вам также необходимо изучить программу экранного доступа и ее возможности. В связи с тем, что рынок адаптивных технологий быстро развивается, всегда есть неуверенность в том, можно ли до сих пор использовать старые, проверенные временем HTML элементы, такие как , которые были популярны 20 лет назад, поскольку они постепенно перестают поддерживаться современными браузерами. Всё это не упрощает жизнь разработчика.
Эксперты по доступности нам постоянно твердят одно и то же: «Не используйте ARIA без надобности». Интересно, как мы, разработчики, должны это понять? Нам катастрофически не хватает обучающих материалов. Вместо того чтобы сделать обучение понятным и доступным, мы оставляем все на откуп дизайнеров и разработчиков для принятия серьезных решений.
WCAG 3 не решит эту проблему
К сожалению, в руководстве по доступности WCAG 3 эту проблему, скорее всего, тоже не с Многие люди связывают большие надежды с руководством по доступности WCAG 3. Однако тестирование доступности — это наименьшая из наших проблем. Все равно ничто волшебным образом не поможет разработчикам разобраться в том, как добиться определенного результата, к тому времени, когда WCAG 3 станет рекомендованным к использованию (поскольку оно не сильно улучшит взаимодействие между технологиями). Поэтому, каким образом новый стандарт повлияет на процесс тестирования в целом, пока неизвестно.
Необходимы совместные усилия
Уже давно ведутся споры о том, когда нужен альтернативный текст и какие элементы стоит маркировать как ссылки, а какие как кнопки. Очень хорошо, что мы можем отталкиваться от контекста при принятии решения, поскольку веб – это комплексное медиа-пространство.
Однако если дело касается ARIA, то в дереве объектной модели документа DOM и объектной модели доступности AOM должен быть четко определённый результат, что сделает поведение программ экранного доступа более предсказуемым.
Например: если вы назначите атрибут aria-haspopup для диалогового окна =»dialog», то программы экранного доступа почему-то будут определять его как всплывающее меню. Что не способствует решению проблемы.
Недостаток предсказуемости и совместимости программного обеспечения раздражают пользователей. Разработчики не могут рассчитывать на стабильную работу информационных технологий, поскольку их использование очень сильно расходует человеческий ресурс, который можно было бы правильно применить еще где-то.
Когда мы только начинали говорить об ARIA, основная идея заключалась в том, что большинство атрибутов будет быстро и легко переконвертировано в стандартные элементы HTML, такие как диалоги, выпадающие списки, панели вкладок. К сожалению, обещанного так и не случилось. Дивный новый Мир доступности, функционирующий из коробки, так и не стал реальностью.
Теперь ARIA это мета язык, который обеспечивает коммуникацию между технологиями с помощью создаваемого терминологического словаря. Есть, конечно, и некоторые интересные примеры использования, где ARIA позаимствовала некоторые фишки HTML, хотя должно было быть как раз наоборот. У ARIA даже появилась роль абзаца.
Разве можно обвинять разработчиков, когда за поиском истины они пропускают стандартные решения HTML, все, что они видят это ARIA и доступное имя меток. Даже в названии самого стандарта ARIA присутствует слово «доступность». ARIA практически не прощает ошибок разработчика, и последствия могут быть более опасными, чем какой-то затерявшийся нестандартный элемент HTML. Но ARIA гораздо сложнее в разработке, потому что требует строгого соблюдения иерархии. Некоторые роли обязательно должны быть внутри других ролей. Использование некоторых ролей предполагает определенную клавиатурную навигацию, которую так запросто не придумаешь.
Что делать
Я считаю, что процесс реализации доступности должен быть предсказуемым, легким в понимании и гибким. Сделав упор на ARIA, вместо того, чтобы интегрировать доступность в основу развития информационных технологий, мы сделали доступность не доступной для понимания разработчика. Про так называемую поддержку адаптивных технологий я вообще молчу. Мы должны вернуться назад и модернизировать основные стандарты доступности. Это упростит документацию, улучшит надежность, и разработчику станет проще искать и исправлять ошибки. А главное, все это поспособствует тому, что доступность станет легче преподавать.
Для достижения наилучших результатов браузеры должны принять на себя большую часть нагрузки по проверке кода. Почему до сих пор в консоли разработчика нет предупреждения о том, что у поля редактирования отсутствует метка? Почему я должен загрязнять HTML глупыми атрибутами ARIA, на которые браузеру наплевать. На каждый случай употребления role=»link» () должно появляться сообщение «Вы уверены, что хотите использовать именно эту роль? Может быть, ее следует заменить на HTML-элемент !.
Если мы хотим, чтобы веб был для всех, то и его инструменты тоже должны быть для всех. А без изучения основ HTML внедрение доступности никогда не будет полноценным.
Оригинал статьи: Eric Eggert. Fix web accessibility systematically