Слишком часто доступность не приходит в голову дизайнеру при создании пользовательских интерфейсов. Игнорирование соображений доступности на этапе проектирования может повлиять на ваш веб-сайт или приложение и оказать большое влияние на ваших пользователей. Будь то юзабилити-тестирование, создание прототипов, принятие доступной библиотеки шаблонов или даже просто аннотирование каркасов, дизайнеры должны включить доступность в свой рабочий процесс. Вместо того, чтобы перегружать инженеров QA поиском дефектов доступности, представление о доступности с самого начала или «сдвиг влево» может оказать чрезвычайно положительное влияние на создаваемый вами контент.
Сдвиг влево
Там Многочисленные исследования показывают изменения стоимости исправления дефектов на разных этапах процесса разработки. Исходя из стоимости исправления дефекта на этапе проектирования с коэффициентом 1x, эти исследования показывают различия в стоимости, которые увеличиваются до 6x во время реализации, 15x во время тестирования после принятия кода и до 100x в случае обнаружения после того, как дефект выявил его. в производство. Исследования, проведенные NIST, оценивают стоимость исправления дефектов как 10x во время интеграционного тестирования и 15x во время тестирования системы, но только 30x в производстве. [^2] Независимо от того, каковы фактические затраты вашей организации, одно можно сказать наверняка: выявление дефектов на этапе проектирования и разработки обходится на порядок дешевле, чем в дальнейшем.
Deque собрал данные за 20 лет тестирование доступности. Исходя из наших данных, тенденция, которую мы наблюдаем в течение последних пяти лет по мере усложнения веб-приложений, заключается в том, что число дефектов на странице неуклонно растет и составляет от 30 до 50 дефектов на страницу. Эти числа дефектов часто затмевают любую частоту функциональных дефектов и усиливают значение при тестировании смещаемой доступности и исправлении как можно дальше в процессе.
Около 70% дефектов доступности можно избежать с помощью соответствующей комбинации автоматизированного и управляемого тестирования в процессе проектирования и разработки.
Цель данной статьи — дать вам общее представление о том, как этого можно достичь.
Этап проектирования
Аннотации
Аннотации — это текстовые или графические пояснения, добавленные в проект для информирования исполнителя о намерении. Подобно дизайнеру, который комментирует такие вещи, как цвет и размер шрифта, информация о доступности также должна передаваться в проектах. Давайте погрузимся в простой виджет аудиоплеера и оценим, какие аннотации нам понадобятся.
Наш аудиоплеер будет состоять из трех элементов управления:
- Элемент управления для перехода к предыдущему треку (когда применимо)
- Элемент управления для воспроизведения и приостановки воспроизведения текущей звуковой дорожки
- Элемент управления для перехода к следующей дорожке (когда применимо)
Имя, роль и состояние
Доступное имя компонента будет определять, что Пользователь вспомогательных технологий будет проинформирован о взаимодействии с ним. Очень важно аннотировать каждый из наших элементов управления аудиопроигрывателем, потому что визуально они представлены только с иконографией и без текстового содержимого. Это означает, что мы аннотируем 3 элемента управления с доступными именами «Предыдущая дорожка», «Пауза» и «Следующая дорожка».
Далее, мы хотим подумать о цели каждый из этих 3 элементов управления. Поскольку они являются интерактивными элементами, которые выполняют действия аудиоплеера, очевидным выбором роли здесь является «кнопка». Это не то, что следует принимать во внимание при проектировании, а скорее это то, что дизайнеры должны аннотировать, чтобы убедиться, что разработчики добавляют эту семантическую информацию к элементам управления. Распределение ролей с самого начала избавит вас от необходимости возвращаться и добавлять их к элементам управления после того, как реализация уже состоялась.
Наконец, точно так же, как дизайнеры отображают, как выглядит элемент управления при наведении, они должны думать о различных состояниях своего виджета с точки зрения доступности. В случае с нашим аудиоплеером у нас на самом деле есть немало состояний для аннотации для разработчика. Начиная с кнопки «Предыдущий трек», мы знаем, что она должна быть отключена, если нет предыдущего трека для воспроизведения. Кнопка воспроизведения / паузы должна переключать аудиопроигрыватель между режимами воспроизведения и паузы. Это означает, что нам нужно аннотировать, что доступное имя должно соответствовать этому состоянию. Доступное имя кнопки должно быть «Пауза» при воспроизведении звука и «Воспроизведение» при приостановке звука. Для кнопки «Следующая дорожка» мы должны отметить, что она должна быть отключена, когда следующей дорожки нет. Наконец, состояния наведения и фокусировки для каждой из кнопок должны быть аннотированы, чтобы пользователи клавиатуры имели некоторую визуальную индикацию текущего фокусированного элемента управления в аудиоплеере.
Взаимодействие для всего компонента
Когда на первом треке: отключить кнопку «предыдущий трек»
Когда на последнем треке: отключить «следующий трек» Кнопка »
При воспроизведении отобразите кнопку« пауза »и скройте кнопку« воспроизведение »
Когда не воспроизводите: отобразите кнопку« воспроизведение »и скройте кнопку« пауза »
После нажатия кнопки «play» поместите фокус на кнопку «pause»
После нажатия кнопки «pause» поместите фокус на кнопку «play»
«Юзабилити-тестирование»
Юзабилити-тестирование, методология исследования UX, в которой исследователь предлагает пользователю выполнить ряд задач и проанализировать их поведение, это очень важный этап на этапе проектирования. Информация, полученная в результате тестирования юзабилити, имеет жизненно важное значение для формирования цифровых впечатлений пользователей. Выполнение этого теста с пользователями с ограниченными возможностями чрезвычайно важно, потому что оно позволяет вашей команде понять, насколько легко эти пользователи смогут взаимодействовать с контентом, который они создают. Если вы проводите юзабилити-тестирование в существующей системе, вы сможете получить очень реалистичный сценарий для участника, который отлично подходит для пользователей, которые полагаются на различные вспомогательные технологии.
Если вы проводя юзабилити-тестирование на несуществующей системе, будьте готовы решать проблемы доступности, связанные с выходом программного обеспечения для проектирования. Интерактивные прототипы, полученные с помощью этих инструментов, часто сильно отличаются от того, каким будет конечный продукт в браузере или на платформе ОС. Кроме того, эти «функциональные прототипы» обычно крайне недоступны. Если возможно, найдите близкую альтернативу в дикой природе, которую вы можете использовать вместо своего прототипа, которая может дать вам хорошее представление о том, как ваши участники будут взаимодействовать с вашей системой. Например, если вы создаете новый компонент мобильной навигации, найдите существующий в Интернете и проведите с ним тестирование удобства использования. Определите, что сработало в этой альтернативе, и узнайте, что нужно улучшить. В любом случае, всегда будьте готовы предоставить условия для участников юзабилити-тестирования на основании их инвалидности. Обеспечение того, чтобы тесты проходили гладко без каких-либо препятствий, не только порадует ваших участников, но и позволит вам пройти больше тестов за меньшее время.
Библиотеки шаблонов
Библиотеки шаблонов — это коллекции пользователей. компоненты интерфейса и чрезвычайно полезны как на стадии проектирования, так и на стадии разработки. Наличие достаточного набора компонентов пользовательского интерфейса позволяет легко создавать полнофункциональные приложения. Для дизайнера эти компоненты помогают поддерживать согласованность во всем приложении, что улучшает общее восприятие для ваших пользователей. Для разработчика наличие полностью протестированных, доступных, повторно используемых компонентов помогает быстро создавать высококачественный контент. К этим компонентам следует обращаться с особой тщательностью с точки зрения доступности, поскольку они, вероятно, будут использоваться много раз в ваших приложениях.
Работа С Разработчиками
Говоря вместе с коллегами-разработчиками и дизайнерами на конференциях и встречах я часто слышу о разделенных командах, в которых дизайнеры и разработчики работают в полной изоляции друг от друга. Мало того, что разработчики должны быть включены на этапе проектирования в такие вещи, как совещания по рассмотрению дизайна, но и дизайнеры должны быть также включены на этапе разработки.
Сотрудничество является ключевым моментом, когда речь идет о создании потрясающего доступного контента.
Зачастую разработчики осведомлены о деталях реализации, которые могут помочь в разработке проектных решений или даже изменить подход к решению проблемы проектирования. Аналогичным образом, дизайнеры могут помочь разработчикам контролировать, когда речь идет о доступной реализации их проектов, потому что такие детали, как интервалы и использование определенного цвета, могут оказать огромное влияние на доступность. В то время как разработчики реализуют дизайн, дизайнеры должны уделять пристальное внимание таким вещам, как индикация фокуса, порядок вкладок, порядок чтения, шрифты, цвета и даже доступные имена и альтернативные тексты изображений. Потому что, в конце концов, что хорошего в этих удивительных аннотациях для специальных возможностей, если разработчик их игнорирует?
Этап разработки
Автоматизированное тестирование доступности
Нам, разработчикам, нравится Идея, что некоторые вещи в наших рабочих процессах могут быть полностью автоматизированы. К счастью, есть много удивительных библиотек автоматизации доступности, которые ваша команда должна использовать для создания устойчивых доступных интерфейсов. Инструменты статического анализа, такие как eslint-plugin-jsx-a11y, могут немедленно предоставить разработчикам обратную связь, предупреждая их о потенциальных проблемах доступности, пока они кодируют. Разработчики могут даже настроить свой текстовый редактор так, чтобы они отображали эти предупреждения прямо при вводе кода, распознавая эти дефекты по мере их появления.
Механизмы правил доступности, такие как ax-core, могут быть интегрированы практически в любую среду или окружающей среды и может помочь поймать много чрезвычайно распространенных проблем доступности. Отличный способ убедиться, что вся ваша команда создает доступный контент, — это интегрировать эти типы инструментов в конвейеры CI (непрерывная интеграция) и CD (непрерывная доставка). Написание тестовых примеров для специальных возможностей (единичных или сквозных) — еще одна отличная форма автоматизации. В моей команде у нас настроено все вышеперечисленное, поэтому нельзя даже объединять запросы на включение до тех пор, пока не пройдут все наши тесты автоматизации доступности. Это означает, что мы можем гарантировать минимальные дефекты доступности, даже если это сделано на наших серверах разработки, и, безусловно, не введем его в эксплуатацию.
Систематическое управление дефектами доступности
Вопросы доступности должны рассматриваться не иначе, как безопасность или функциональные дефекты. Они должны регулярно сортироваться и расставляться по приоритетам с остальной «нормальной» рабочей нагрузкой. Измерение прогресса и сбор метрик, специфичных для дефектов доступности, также могут быть полезны, особенно если ваша команда только начинает наращивать доступность. Это также может помочь выявить слабые места или узкие места вашей системы. Если ваша команда участвует в ретроспективах спринта (или что-то подобное), доступность должна быть предметом обсуждения. Размышление о том, что работает, а что нет, является здоровым упражнением и может привести к улучшению общего подхода вашей команды к устойчивой доступности.
Этот бета-инструмент Cool axe
Мы говорили о доступности автоматизация, которая является отличной отправной точкой для тестирования. Тем не менее, неизбежно, человек должен подобрать там, где останавливаются роботы, чтобы получить полное покрытие тестирования доступности. Ручное тестирование требует глубокого понимания доступности, а также Руководства по доступности веб-контента W3C или «WCAG». Бета-версия Axe поможет вам пройти это ручное тестирование без необходимости быть экспертом по доступности. Он имеет большой набор интеллектуальных управляемых тестов, которые задают очень простые вопросы и выполняют все тяжелые работы для вас!
Учитывая, что мы всегда стремимся автоматизировать все, можно скептически отреагировать на утверждение, что тестирование доступности не может быть полностью автоматизирован и требует человеческого мозга, чтобы покрыть все основы. Однако давайте возьмем изображения в качестве примера и какую информацию, если таковая имеется, они предоставляют в контексте веб-страницы. Библиотека автоматизации доступности не может получить информационное намерение путем сканирования или обработки изображения. Даже если мы подадим алгоритму машинного обучения изображение, и оно может дать точное описание того, что находится на этом изображении, оно не будет знать, что это изображение передает в контексте страницы. Информация, которую передает данное изображение, или то, используется ли это изображение исключительно в качестве украшения, полностью зависит от автора контента.
Связывая все вместе
Имея в виду доступность с самого начало разработки делает создание доступного контента намного проще, чем на поздних этапах жизненного цикла разработки программного обеспечения. Внедрение доступности в идею, дизайн и реализацию вашего программного обеспечения создает более устойчивый продукт.
Настройте свою команду на успех, используя такие ресурсы, как WCAG, ARIA, ARIA Authoring Practices и Stack Overflow. Предотвращайте попадание дефектов доступности в ваше программное обеспечение, используя библиотеки автоматизации специальных возможностей и интегрируя их в свои серверы непрерывной интеграции. Наша команда усердно работала над заполнением пробела между автоматизированным и ручным тестированием, мы хотели бы, чтобы вы попробовали Axe Beta! Если дефекты доступности обрабатываются систематически, вы можете не только избавить свои приложения от этих проблем, но и помешать им вернуться в будущее.
Хотите присоединиться ко мне? в бесплатной мастерской на эту тему? Зарегистрируйтесь для участия в нашей предстоящей виртуальной мастерской Translating Design Wireframes, которая будет разбита на две 3-часовых сессии.
(ra, il) 
Загрузка...
