Хорошо, лучше, лучше: распутываем сложный мир доступных шаблонов

Марк Бениофф незабываемо заявил, что единственная константа в технологической индустрии — это изменения. Проработав в сфере технологий более 15 лет, я могу это подтвердить. Коллеги-технологи-динозавры могут засвидетельствовать, что то, как Интернет работал в первые дни, кардинально отличалось от того, что многие из нас могли даже представить.

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

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

Какую запутанную паутину мы плетем

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

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

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

Откуда я это знаю? Что ж, я провел последние пять лет, исследуя, создавая и тестируя различные типы доступных шаблонов, работая над руководством по стилю A11y, библиотекой шаблонов ARIA Deque и оценивая популярные шаблоны SVG. Но я также просмотрел множество клиентских шаблонов и библиотек для всех мыслимых фреймворков/платформ. На данный момент я могу без колебаний сказать, что существует врожденная иерархия доступности шаблонов, которая начинает развиваться, когда вы смотрите достаточно долго. И хотя иногда встречаются закономерности, которых следует избегать любой ценой, они не всегда так однозначны. Когда дело доходит до доступности, я бы сказал, что большинство паттернов попадают в градиенты «хорошо, лучше, лучше». Трудная часть состоит в том, чтобы знать, какой шаблон относится к какой категории.

Критическое мышление о шаблонах

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

• Есть ли уже установленный доступный шаблон, который мы можем использовать?
• Какие браузеры и устройства со специальными возможностями (AT) мы поддерживаем?
• Существуют ли какие-либо ограничения фреймворка или другие интеграции/факторы, которые следует учитывать?

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

Существует ли уже установленный доступный шаблон?

Почему кажется, что с каждым новым фреймворком мы получаем совершенно новый набор паттернов? Это постоянное изобретение колеса с новыми вариантами шаблонов может сбить с толку и расстроить разработчиков, тем более что обычно в этом нет необходимости.

Не верите мне? Что ж, подумайте об этом так: если мы подписываемся на систему атомарного дизайна, мы понимаем, что несколько маленьких «атомов» кода объединяются для создания более крупного цифрового продукта. Но в научном мире атомы — не самый маленький компонент жизни. Каждый атом состоит из множества субатомных частиц, таких как протоны, нейтроны и электроны.

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

Примечание . Некоторые заслуживающие доверия источники включают Inclusive Components, Accessible Components и Gov.UK Design System, в дополнение к списку доступных шаблонов, недавно опубликованному Smashing Magazine (плюс более подробный список шаблонов и библиотек в конце статьи). .

Какие браузеры и устройства со вспомогательными технологиями (AT) мы поддерживаем?

Изучив несколько базовых шаблонов, которые могут работать, мы можем перейти к вопросу о поддержке браузерами и вспомогательными технологиями (AT) устройств. Сама по себе поддержка браузера — не шутка. Когда вы добавляете в смесь устройства AT и спецификации ARIA, все становится сложнее… не невозможно, просто требуется гораздо больше времени, усилий и мыслительного процесса, чтобы понять все это.

Но это не все плохие новости. Есть несколько замечательных ресурсов, таких как специальные возможности HTML5 и поддержка специальных возможностей, которые помогают нам лучше понять текущую поддержку браузера и устройств AT. Эти веб-сайты описывают различные доступные подэлементы шаблонов HTML и ARIA, включают тесты сообщества с открытым исходным кодом и предоставляют несколько примеров шаблонов — как для настольных, так и для мобильных браузеров/устройств AT.

Существуют ли какие-либо ограничения фреймворка или другие интеграции/факторы, которые следует учитывать?

После того, как мы выбрали несколько доступных базовых шаблонов и учли поддержку браузера/устройства AT, мы можем перейти к более детальным контекстуальным вопросам, связанным с шаблоном и его окружением. Например, если мы используем шаблон в системе управления контентом (CMS) или имеем соображения по устаревшему коду, будут определенные ограничения шаблона. В этом случае несколько вариантов шаблонов можно быстро сократить до одного или двух. С другой стороны, некоторые фреймворки более снисходительны и открыты для принятия любого шаблона, поэтому мы можем меньше беспокоиться об ограничениях фреймворка и больше сосредоточиться на выборе наиболее доступного шаблона, который мы можем сделать.

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

Оценка шаблонов для доступности

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

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

Доступные шаблоны кнопок

Первая группа паттернов, которые мы рассмотрим для обеспечения доступности, повсеместно распространена почти на каждом веб-сайте или в приложении: кнопки. Первый шаблон кнопки использует роль кнопки ARIA для имитации кнопки, а второй и третий шаблоны кнопок используют HTML-элемент <button> . Третий шаблон также добавляет aria-describedby и CSS для визуального скрытия вещей.

Хорошо: role="button"

 <a role="button" href="[link]">Sign up</a>

Лучше: <button>

 <button type="button">Sign up</button>

Лучшее: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

Хотя первые шаблоны на первый взгляд кажутся простыми, они вызывают некоторые вопросы доступности. Например, в первом шаблоне кнопки мы видим, что ARIA role="button" используется в "хорошем" шаблоне вместо HTML-элемента <button> . Думая с точки зрения доступности, поскольку мы знаем, что HTML-элемент <button> был введен в HTML4, мы можем разумно предположить, что он полностью поддерживается последними версиями всех основных браузеров и будет прекрасно работать с большинством AT-устройств. Но если мы копнем глубже и посмотрим на поддержку специальных возможностей для ARIA role="button", мы увидим небольшое преимущество с точки зрения вспомогательных технологий, в то время как элементу HTML <button> не хватает некоторых областей охвата браузера + AT, особенно если учесть поддержка голосового управления.

Тогда почему шаблон ARIA не относится к категории «лучших»? Разве ARIA не делает его более доступным? Неа. Фактически, в подобных случаях специалисты по доступности часто повторяют первое правило ARIA — не используйте ARIA. Это ироничный способ сказать: используйте HTML-элементы, когда это возможно. ARIA действительно мощная, но в неумелых руках она может принести больше вреда, чем пользы. Фактически, в отчете WebAIM Million говорится, что «страницы с ARIA в среднем содержат на 60% больше ошибок, чем страницы без него». Таким образом, вы должны знать, что делаете при использовании ARIA.

Еще одно возражение против использования ARIA в этой ситуации заключается в том, что необходимая нам функциональность кнопки должна быть построена для шаблона role="button" , в то время как эта функциональность уже предварительно встроена в элемент <button> . Учитывая, что элемент <button> также на 100 % поддерживается браузером и является простым в реализации шаблоном, он немного опережает в иерархии при оценке первых двух шаблонов. Надеюсь, это сравнение поможет разрушить миф о том, что добавление ARIA делает шаблон более доступным — часто верно обратное.

Третий шаблон кнопки показывает HTML-элемент <button> в сочетании с aria-describedby , связанным с элементом ID, который визуально скрыт с помощью CSS. Хотя этот паттерн немного сложнее, он добавляет много нового с точки зрения контекста, создавая связь между кнопкой и целью. Если вы сомневаетесь, в любое время мы можем добавить больше контекста к ситуации, тем лучше, поэтому мы можем предположить, что при правильном кодировании это лучший шаблон при сравнении только этих конкретных шаблонов кнопок.

Доступные шаблоны контекстных ссылок

Вторая группа паттернов, которую мы рассмотрим, — это контекстные ссылки. Эти шаблоны помогают предоставить пользователям AT больше информации, чем то, что видно на экране. Первый шаблон ссылки использует CSS для визуального скрытия дополнительной контекстной информации. В то время как второй и третий шаблоны ссылок добавляют в смесь атрибуты ARIA: aria-labelledby и aria-label соответственно.

Хорошо: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Лучше: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

Лучшее: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

Хотя все три шаблона контекстных ссылок выглядят одинаково, когда мы проверяем код или тестируем их с помощью AT-устройств, обнаруживаются некоторые очевидные различия. В первом шаблоне используется метод CSS для визуального скрытия контента для зрячих пользователей, но все же отображается скрытый контент для незрячих пользователей AT. И хотя этот метод должен работать в большинстве случаев, реальной связи между ссылкой и дополнительной информацией не образуется, поэтому связь в лучшем случае является условной. Таким образом, первый шаблон ссылки является хорошим выбором, но не самым надежным шаблоном ссылки из трех.

Следующие два шаблона ссылок немного сложнее оценить. Согласно спецификациям ARIA от W3C, «цель aria-label такая же, как и у aria-labelledby . Он предоставляет пользователю узнаваемое имя объекта». Итак, теоретически оба атрибута должны иметь одинаковую базовую функциональность.

Однако в спецификациях также указано, что пользовательские агенты отдают приоритет aria-labelledby над aria-label при принятии решения о том, какое доступное имя передать пользователю. Исследования также выявили проблемы, связанные с автоматическим переводом и атрибутами aria-label. Значит, мы должны использовать aria-labelledby , верно?

Ну не так быстро. Далее в тех же спецификациях ARIA говорится: «Если интерфейс таков, что невозможно иметь видимую метку на экране (или если видимая метка не является желаемым пользовательским интерфейсом), авторы должны использовать aria-label и не должны используйте aria-labelledby ». Разговор о путанице — так какой шаблон мы должны выбрать?

Если бы у нас были масштабные потребности в переводе, мы могли бы решить изменить визуальный аспект и написать ссылки с отображаемым полным контекстом (например, « Узнайте больше об этой удивительной вещи ») или решить использовать aria-labelledby . Однако давайте предположим, что у нас не было масштабных потребностей в переводе или мы могли удовлетворить эти потребности разумным/доступным способом, и мы не хотели менять визуал — что тогда?

Основываясь на текущих рекомендациях ARIA 1.1 (с обещанием перевода aria-label в ARIA 1.2), а также на том факте, что aria-label немного проще реализовать разработчикам по сравнению с aria-labelledby , мы могли бы принять решение о том, что aria- aria-label важнее. aria-labelledby в нашей оценке шаблона. Это яркий пример того, когда контекст сильно влияет на наш выбор доступного шаблона.

Доступные шаблоны <svg>

И последнее, но не менее важное: давайте исследуем группу шаблонов изображений SVG на предмет доступности. SVG — это визуальное представление кода, но, тем не менее, код. Это означает, что устройство AT может пропустить недекоративное изображение SVG, если в шаблон не будет добавлено значение role="img" .

Предполагая, что следующие шаблоны SVG носят информационный характер, в каждый из них добавлено значение role="img" . Первый шаблон SVG использует <title> и <text> в сочетании с CSS, чтобы визуально скрыть содержимое от зрячих пользователей. Следующие два шаблона SVG включают элементы <title> и <desc> , но с атрибутом aria-labelledby , добавленным к последнему шаблону.

Хорошо: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

Лучше: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

Лучше всего: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

Давайте сначала посмотрим на первый шаблон с использованием <title> и <text> и визуально скрытого CSS. В отличие от предыдущего визуально скрытого текста в шаблонах, между элементами <title> и <text> существует неотъемлемая связь, поскольку они сгруппированы под одним зонтиком элемента SVG. Однако эта связь не очень сильна. На самом деле, если вы вернетесь к моему исследованию шаблонов SVG, мы увидим, что только 3 из 8 комбинаций браузер/AT услышали полное сообщение. (Примечание: образец свиньи №1 эквивалентен образцу лампочки №7.)

Это верно, хотя рабочие спецификации W3C SVG определяют элемент <text> как «графический элемент, состоящий из текста… символы, которые должны быть отрисованы, выражаются в виде символьных данных. В результате текстовые данные в формате SVG легко доступны для слабовидящих». Этот первый шаблон в порядке, но мы можем сделать лучше.

Второй шаблон удаляет элемент <text> и заменяет его элементом <desc> . Спецификации W3C SVG гласят:

«Дочерний элемент <title> представляет собой краткую текстовую альтернативу для элемента... а элемент <desc> представляет более подробную текстовую информацию для элемента, такую ​​как описание».

Это означает, что элементы <title> и <desc> в SVG могут использоваться аналогично альтернативному тексту изображения и параметрам длинного описания, которые традиционно используются в элементах <img> . После добавления элемента <desc> во второй SVG мы видим аналогичную поддержку браузера/AT с 3 из 8 комбинаций, слышащих полное сообщение. (Примечание: шаблон «Свинья» № 2 эквивалентен шаблону «Лампочка № 10».) Хотя результаты этих тестов, похоже, отражают первый шаблон, причина, по которой этот шаблон попадает в категорию «лучших», заключается в том, что его немного проще реализовать в коде. мудрее, и он влияет на большее количество пользователей AT, поскольку он работал на JAWS, VoiceOver для настольных ПК и мобильных устройств VoiceOver, в то время как первый шаблон поддерживал менее популярные комбинации браузера и AT.

В третьем шаблоне снова используются элементы <title> и <desc> , но теперь в микс добавлены aria-labelledby и ID. Согласно тем же тестам SVG, добавление этого дополнительного фрагмента кода означает, что мы можем полностью поддерживать 7 из 8 комбинаций браузер/AT. (Примечание: шаблон свиньи № 3 эквивалентен шаблону лампочки № 11.) Из трех шаблонов SVG этот третий является «лучшим», поскольку он поддерживает большинство устройств AT. Но у этого шаблона есть недостаток в использовании некоторых комбинаций браузера и AT; вы услышите дубликат заголовка/описания изображения для этого шаблона. Хотя это может раздражать пользователей, я бы сказал, что в целом лучше слышать дублированный контент, чем вообще ничего.

Заключительные мысли

Хотя мы все, безусловно, ценим выбор в технологиях, интересно, подошли ли мы к моменту времени, когда переизбыток вариантов оставил нас парализованными и запутанными в том, что делать дальше? Что касается выбора доступных шаблонов, мы можем задавать прямые вопросы о параметрах шаблона/библиотеки, поддержке браузера/AT-устройства, ограничениях фреймворка и многом другом.

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

«Включение — это не привлечение людей к тому, что уже существует, — это создание нового пространства, лучшего пространства для всех».

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

Связанные ресурсы

Инструменты

• Поддержка специальных возможностей, Майкл Фэирчайлд, a11ysupport.io
• Доступность HTML5, Стив Фолкнер

Библиотеки шаблонов

• Проект доступности
• Руководство по стилю специальных возможностей
• Доступные компоненты, Скотт О'Хара
• Доступный плагин переупорядочения списка с помощью drag-and-drop , Харрис Шнайдерман
• Библиотека шаблонов ARIA от Deque
• Доступная библиотека React от Deque
• Система дизайна GOV.UK
• Инклюзивные компоненты, Хейдон Пикеринг
• Система веб-дизайна США (USWDS)
• Учебники по веб-доступности