Перейти к содержанию

Паттерны, компоненты и дизайн-системы

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

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

Некоторые преимущества компонентно-ориентированной разработки включают разбивку на управляемые части, что сокращает время разработки благодаря этим повторно используемым компонентам. Это позволяет дизайнерам, фронтенд- и бэкенд-разработчикам, а также QA работать одновременно. Клиентам, дизайнерам, менеджерам проектов и другим это нравится, потому что они могут предварительно просматривать процесс сборки и использовать живое руководство по стилям в качестве справочника после запуска веб-сайта.

Однако, когда мы рассматриваем паттерны, компоненты и дизайн-системы с учетом доступности, возникают некоторые вопросы. Как узнать, какие паттерны лучше всего с точки зрения доступности? Стоит ли использовать готовую библиотеку паттернов или создавать новые? Как узнать, действительно ли эти паттерны помогут вашим пользователям?

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

Мыслите критически

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

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

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

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

Готовые ресурсы

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

Некоторые отличные ресурсы для доступных паттернов, компонентов и дизайн-систем включают:

Для JavaScript-фреймворков следующие ресурсы достаточно доступны из коробки или легко настраиваются для обеспечения доступности:

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

Все ресурсы должны рассматриваться как отправная точка. Обязательно тестируйте всё!

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

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

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

Программа чтения с экрана ОС Совместимость с браузерами Стоимость
Job Access with Speech (JAWS) Windows Chrome, Firefox, Edge Требуется лицензия (существует бесплатная 40-минутная версия)
Non-Visual Desktop Access (NVDA) Windows Chrome и Firefox Бесплатно (требует загрузки)
Narrator Windows Edge Бесплатно (встроено в машины Windows)
VoiceOver macOS Safari Бесплатно (встроено в машины macOS)
Orca Linux Firefox Бесплатно (встроено в дистрибутивы на основе Gnome)
TalkBack Android Chrome и Firefox Бесплатно (встроено в определенные версии Android OS)
VoiceOver iOS Safari Бесплатно (встроено в iOS-устройства)

Поддержка браузеров в целом сложна, и всё становится еще сложнее, когда вы добавляете AT-устройства и спецификации ARIA в микс.

Но это не все плохие новости. К счастью, отличные ресурсы, такие как HTML5 Accessibility, Accessibility Support и Чек-лист доступной разработки пользовательских элементов управления от WCAG помогают нам лучше понять текущую поддержку браузеров и AT-устройств, и даже когда использовать ARIA в первую очередь.

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

Другие соображения

После того как вы выбрали несколько доступных базовых паттернов или компонентов и учли поддержку браузеров и AT-устройств, вы можете перейти к более конкретным контекстуальным вопросам о паттерне, компоненте, дизайн-системе и среде разработки.

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

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

Существуют дополнительные соображения, которые нужно взвесить при выборе паттерна, компонента или дизайн-системы, такие как:

  • Производительность
  • Безопасность
  • Поисковая оптимизация
  • Поддержка языкового перевода
  • Интеграции с третьими сторонами

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

Источник — https://web.dev/learn/accessibility/patterns

Комментарии