Многие используют компонентно-ориентированную разработку, применяя в своем рабочем процессе шаблоны проектирования, библиотеки компонентов или полноценные системы проектирования. Даже если вы формально не использовали эти инструменты, вероятно, вы применяете аналогичный процесс для разбиения большого проекта веб-сайта, приложения или другого цифрового продукта на управляемые части.
Как и при строительстве физического сооружения, важно строить по частям. Сначала фундамент, затем конструкция, стены, окна, крыша и всё остальное. Инструменты компонентно-ориентированной разработки позволяют нам делать это для веб-сайтов, приложений и других цифровых продуктов.
К преимуществам компонентно-ориентированной разработки можно отнести разбиение задачи на управляемые части, что сокращает время разработки благодаря использованию многократно используемых компонентов. Это позволяет дизайнерам, фронтенд- и бэкенд-разработчикам, а также специалистам по контролю качества работать одновременно. Клиентам, дизайнерам, менеджерам проектов и другим пользователям это нравится, поскольку они могут предварительно просмотреть процесс сборки и использовать постоянно обновляемое руководство по стилю в качестве справочного материала после запуска веб-сайта.
Однако, когда мы рассматриваем шаблоны, компоненты и системы проектирования с точки зрения доступности, возникают некоторые вопросы. Как узнать, какие шаблоны лучше всего подходят с точки зрения доступности? Следует ли использовать уже существующие шаблоны или библиотеки, или создавать новые? Как понять, действительно ли эти шаблоны помогут вашим пользователям?
При таком огромном выборе вариантов вы можете запутаться в шаблонах, компонентах и системах проектирования. Цель этого модуля — предоставить вам общую информацию о том, как оценивать шаблоны, компоненты и системы проектирования с точки зрения доступности, и дать вам отправную точку для принятия более доступных решений.
Мыслите критически
Выбор подходящего шаблона, компонента или системы дизайна — это не высшая математика, но требует времени и критического мышления. На самом деле, не существует «одного идеального шаблона», но потенциально может быть множество вариантов, которые подойдут. Важно научиться выбирать лучший вариант для вашей уникальной ситуации.
В последующих модулях тестирования вы подробнее узнаете о методах и приемах оценки шаблонов, компонентов и систем проектирования на предмет доступности. Прежде чем приступить к этому, вам необходимо задать себе несколько фундаментальных вопросов, таких как:
- Существует ли уже готовый, доступный шаблон, компонент или система проектирования?
- Какие браузеры и вспомогательные технологии я поддерживаю?
- Существуют ли какие-либо ограничения в коде или фреймворке? Есть ли другие интеграции, факторы или потребности пользователей, которые мне следует учитывать?
В зависимости от вашей среды разработки и потребностей пользователей, у вас могут возникнуть дополнительные или отличающиеся от перечисленных вопросы. Рассматривайте эти вопросы как отправную точку при оценке доступности.
Созданные ресурсы
Прежде чем создавать что-то совершенно новое, проведите тщательное исследование и изучите уже существующие шаблоны, компоненты и системы проектирования. Проведя небольшое исследование, вы можете с удивлением обнаружить решение (или несколько), которые соответствуют вашим потребностям.
Среди отличных ресурсов, содержащих доступные шаблоны, компоненты и системы проектирования, можно выделить следующие:
- Доступные компоненты
- Библиотека ARIA Университета Деке
- Система проектирования Gov.UK
- Инклюзивные компоненты
- MagentaA11y
- Система веб-дизайна США (USWDS) создана для федерального правительства Соединенных Штатов.
- Список доступных выкроек из журнала Smashing Magazine
Для JavaScript-фреймворков следующие ресурсы по умолчанию достаточно доступны или могут быть настроены для обеспечения доступности:
- Когда CSS недостаточно: требования к JavaScript для доступных компонентов
- Реакции
- Angular: библиотека Material Design
- Vue: Vuetensils
Однако — и это нельзя недооценивать — никогда не следует просто копировать/вставлять код и предполагать, что он впишется в вашу среду и автоматически удовлетворит потребности пользователя. Это относится ко всем шаблонам, компонентам и системам проектирования, даже если они помечены как полностью доступные.
Все ресурсы следует рассматривать как отправную точку. Обязательно всё протестируйте!
Поддержка браузеров и вспомогательных технологий (АТ).
После изучения нескольких базовых шаблонов, компонентов или полноценной системы проектирования, которые могут подойти для вашей среды разработки, вы можете перейти к поддержке вспомогательных технологий. Одним из основных типов вспомогательных технологий, на который следует обратить внимание при оценке шаблонов, компонентов и систем проектирования, являются программы чтения с экрана.
Программы чтения с экрана были разработаны с учетом конкретных браузеров и лучше всего работают в паре с ними. Мы подробнее рассмотрим эту тему в модуле по тестированию вспомогательных технологий , но для целей оценки шаблонов полезно понимать, что такие комбинации существуют, чтобы вы знали, какая поддержка вам необходима.
| программа чтения с экрана | ОС | Совместимость с браузерами | Расходы |
|---|---|---|---|
| Доступ к рабочим местам с помощью речи (JAWS) | Windows | Chrome, Firefox, Edge | Требуется лицензия (существует бесплатная 40-минутная версия). |
| Невизуальный доступ к рабочему столу (NVDA) | Windows | Chrome и Firefox | Бесплатно (требуется загрузка) |
| Рассказчик | Windows | Край | Бесплатно (встроено в компьютеры под управлением Windows) |
| Озвучка | macOS | Сафари | Бесплатно (встроено в компьютеры macOS) |
| Косатка | Linux | Firefox | Бесплатно (встроено в дистрибутивы на основе Gnome) |
| TalkBack | Android | Chrome и Firefox | Бесплатно (встроено в некоторые версии ОС Android) |
| Озвучка | iOS | Сафари | Бесплатно (встроено в устройства iOS) |
Поддержка браузеров, как правило, представляет собой сложную задачу, а ситуация еще больше усложняется, когда к этому добавляются AT-устройства и спецификации ARIA.
Но не всё так плохо. К счастью, такие полезные ресурсы, как HTML5 Accessibility , Accessibility Support и контрольный список WCAG для разработки доступных пользовательских элементов управления, помогают нам лучше понимать текущую поддержку браузеров и вспомогательных технологий, а также когда вообще следует использовать ARIA.
Эти ресурсы описывают различные доступные подэлементы шаблонов HTML и ARIA, включая тесты с открытым исходным кодом, разработанные сообществом. Вы также можете ознакомиться с примерами шаблонов для настольных компьютеров, мобильных браузеров и вспомогательных технологий. Таким образом, эти ресурсы помогут вам принять более взвешенное решение относительно шаблонов, компонентов и систем проектирования, которые вы, возможно, захотите использовать.
Другие соображения
Выбрав несколько доступных базовых шаблонов или компонентов и учтя поддержку браузеров и вспомогательных технологий, вы можете перейти к более конкретным контекстным вопросам, касающимся шаблона, компонента, системы проектирования и среды разработки.
Например, если вы работаете с системой управления контентом (CMS) или используете устаревший код, могут существовать некоторые ограничения на выбор используемых шаблонов. После анализа несколько вариантов шаблонов могут быстро сократиться до одного-двух.
Многие JavaScript-фреймворки позволяют разработчикам использовать практически любой шаблон по своему выбору. В подобных случаях у вас может быть меньше ограничений, и вы сможете выбрать наиболее доступный вариант шаблона.
При выборе узора, компонента или системы дизайна следует учитывать и другие факторы, такие как:
- Производительность
- Безопасность
- Оптимизация для поисковых систем
- Поддержка языкового перевода
- Интеграция со сторонними сервисами
Эти факторы, несомненно, повлияют на ваш выбор шаблона, но вам также следует учитывать людей, создающих контент и сам код. Выбранный вами шаблон должен быть достаточно надежным, чтобы справляться с любыми потенциальными ограничениями, связанными с контентом, созданным редактором или пользователем, а также должен быть разработан таким образом, чтобы его могли использовать разработчики с любым уровнем знаний в области доступности.