Александр Чудеснов написал, как сделать доступным продукт из множества приложений, которые написаны разными командами.
— Страница с правильной цветовой контрастностью, структурой заголовков и HTML-вёрсткой, скорее всего, уже отвечает критериям доступности;
— Есть нюансы: разная реализация некоторых функций в разных браузерах, отдельные неудобные элементы вроде нативного поля ввода даты;
— Проблема в том, что Single Page Applications выходят за рамки возможностей HTML. В них много компонентов, которые не предоставляет сам браузер. При их создании надо отвечать на множество вопросов о взаимодействии с помощью клавиатуры, разметке для скринридеров, управлении фокусом;
— Дизайн-система не всегда спасает: проработанный компонент из ДС может не подходить продукту и не использоваться;
— Относитесь к ДС как к продукту: собирайте статистику использования и обратную связь, отслеживайте и исправляйте проблемы;
— ДС должна решать проблемы команд, предоставлять компоненты с разумными дефолтами, которые можно менять в определённых рамках. Без инструкций в формате «собери сам»;
— Есть проблема в совмещении визуальных и интерактивных паттернов. Кроме визуального стиля компонента важно прорабатывать способы взаимодействия с ним и возможную композицию с другими элементами;
— ДС может содержать визуальный слой, слой интерактивных паттернов и отдельно — собранные готовые компоненты (как в ДС Adobe Spectrum);
— Не пренебрегайте автоматическим тестированием. Тестировать компоненты в разных состояниях проще в Storybook, чем в продакшене. После ручного аудита (в Lighthouse или axe DevTools) стоит написать автоматизированные тесты (axe-Selenium);
— Важно, чтобы доступность интерфейсов стала частью культуры компании: помогите сформировать запрос на доступность, зовите на тестирование людей с инвалидностью, дайте сотрудникам возможность научиться создавать доступные продукты, установить цели, связанные в том числе и с процессами («80% команд знают и используют принципы обеспечения доступности»).
#accessibility
— Страница с правильной цветовой контрастностью, структурой заголовков и HTML-вёрсткой, скорее всего, уже отвечает критериям доступности;
— Есть нюансы: разная реализация некоторых функций в разных браузерах, отдельные неудобные элементы вроде нативного поля ввода даты;
— Проблема в том, что Single Page Applications выходят за рамки возможностей HTML. В них много компонентов, которые не предоставляет сам браузер. При их создании надо отвечать на множество вопросов о взаимодействии с помощью клавиатуры, разметке для скринридеров, управлении фокусом;
— Дизайн-система не всегда спасает: проработанный компонент из ДС может не подходить продукту и не использоваться;
— Относитесь к ДС как к продукту: собирайте статистику использования и обратную связь, отслеживайте и исправляйте проблемы;
— ДС должна решать проблемы команд, предоставлять компоненты с разумными дефолтами, которые можно менять в определённых рамках. Без инструкций в формате «собери сам»;
— Есть проблема в совмещении визуальных и интерактивных паттернов. Кроме визуального стиля компонента важно прорабатывать способы взаимодействия с ним и возможную композицию с другими элементами;
— ДС может содержать визуальный слой, слой интерактивных паттернов и отдельно — собранные готовые компоненты (как в ДС Adobe Spectrum);
— Не пренебрегайте автоматическим тестированием. Тестировать компоненты в разных состояниях проще в Storybook, чем в продакшене. После ручного аудита (в Lighthouse или axe DevTools) стоит написать автоматизированные тесты (axe-Selenium);
— Важно, чтобы доступность интерфейсов стала частью культуры компании: помогите сформировать запрос на доступность, зовите на тестирование людей с инвалидностью, дайте сотрудникам возможность научиться создавать доступные продукты, установить цели, связанные в том числе и с процессами («80% команд знают и используют принципы обеспечения доступности»).
#accessibility
Хабр
Как сделать большой продукт доступным
Примечание: Хабр не поддерживает указание альтернативного текста у картинок отдельно от видимой подписи, поэтому подписи длинные, не пугайтесь. Символ инклюзивного дизайна, вплетенный в структуру,...
Опубликованы видео со 2-й конференции по цифровой доступности (о пользовательском опыте людей с разными нарушениями).
1. Евгений Арнапольский — незрячий пользователь программ экранного доступа (скринридеров). Проводя аналогии между физическим и цифровым миром, рассказал об ассистивных технологиях, а также на примерах Госуслуг, Вконтакте, Сбермаркета и других сервисов показал барьеры в интерфейсах.
2. Денис Редькин — пользователь с нарушением моторики. Как устроено его рабочее место, каким образом он управляет ноутбуком и мобильным телефоном, как играет в компьютерные игры, какие способы управления усложняют, а какие наоборот упрощают ему жизнь.
3. Павел Любецкий — пользователь с астеническим синдромом. В чём выражается синдром, о трудностях с интерфейсами и роли тёмной темы, что помогает сохранять концентрацию и как себя разгрузить.
4. Геннадий Тихненко — пользователь с нарушением слуха. С какими барьерами сталкиваются глухие и слабослышащих люди в физическом и цифровом мире, какие решения сейчас есть на сайтах и в приложениях.
5. Алексей Цаплин — слабовидящий пользователь, использующий одновременно увеличение и программу экранного доступа. С какими трудностями он сталкивается на примерах Пятёрочки, Самоката, Вконтакте и других.
#accessibility
1. Евгений Арнапольский — незрячий пользователь программ экранного доступа (скринридеров). Проводя аналогии между физическим и цифровым миром, рассказал об ассистивных технологиях, а также на примерах Госуслуг, Вконтакте, Сбермаркета и других сервисов показал барьеры в интерфейсах.
2. Денис Редькин — пользователь с нарушением моторики. Как устроено его рабочее место, каким образом он управляет ноутбуком и мобильным телефоном, как играет в компьютерные игры, какие способы управления усложняют, а какие наоборот упрощают ему жизнь.
3. Павел Любецкий — пользователь с астеническим синдромом. В чём выражается синдром, о трудностях с интерфейсами и роли тёмной темы, что помогает сохранять концентрацию и как себя разгрузить.
4. Геннадий Тихненко — пользователь с нарушением слуха. С какими барьерами сталкиваются глухие и слабослышащих люди в физическом и цифровом мире, какие решения сейчас есть на сайтах и в приложениях.
5. Алексей Цаплин — слабовидящий пользователь, использующий одновременно увеличение и программу экранного доступа. С какими трудностями он сталкивается на примерах Пятёрочки, Самоката, Вконтакте и других.
#accessibility
YouTube
Встреча с Евгением, незрячим пользователем программ экранного доступа (скринридеров)
В предверии старта курса по цифровой доступности Accessibility Unity мы проводим вторую бесплатную конференцию.
Тема этой конференции – пользовательский опыт. Встретимся с людьми с нарушением слуха, зрения, моторики, а также с человеком с астеническим синдромом…
Тема этой конференции – пользовательский опыт. Встретимся с людьми с нарушением слуха, зрения, моторики, а также с человеком с астеническим синдромом…
Лена Райан рассказала об отдельной версии сайта для слабовидящих.
— Доступность — это не только версии для слабовидящих. Есть люди с когнитивными нарушениями, тремором рук, ДЦП, без конечностей. Плюс, любой человек может столкнуться с ситуативными и временными ограничениями: одна рука занята, перелом;
— Доступность расширяет аудиторию продукта;
— Если при разработке реализовывать требования доступности сразу, объём работ вырастает всего на 5–7%. Если выносить эти работы на отдельный этап, возможно, придётся перевёрстывать уже сделанное;
— Пользователю проще ориентироваться, если навигация с клавиатуры соответствует естественному потоку документа. Не используйте положительный tabindex;
— Закон не обязывает создавать версию сайта для слабовидящих, если основная версия доступна (и в том числе есть тёмная тема);
— Специальные версии не всегда работают как надо: с одной только клавиатурой проблематично включить навигацию с клавиатуры на сайте Bershka; версия для слабовидящих сайта РЖД теряет акценты и разделение на блоки, чтобы что-то найти надо пользоваться экранной лупой и всё читать;
— Отдельная версия для слабовидящих — не универсальное решение, если там не будет части функций, вместо инклюзивности выйдет дискриминация. Плюс, это дополнительные затраты на вторую версию сайта.
#accessibility
— Доступность — это не только версии для слабовидящих. Есть люди с когнитивными нарушениями, тремором рук, ДЦП, без конечностей. Плюс, любой человек может столкнуться с ситуативными и временными ограничениями: одна рука занята, перелом;
— Доступность расширяет аудиторию продукта;
— Если при разработке реализовывать требования доступности сразу, объём работ вырастает всего на 5–7%. Если выносить эти работы на отдельный этап, возможно, придётся перевёрстывать уже сделанное;
— Пользователю проще ориентироваться, если навигация с клавиатуры соответствует естественному потоку документа. Не используйте положительный tabindex;
— Закон не обязывает создавать версию сайта для слабовидящих, если основная версия доступна (и в том числе есть тёмная тема);
— Специальные версии не всегда работают как надо: с одной только клавиатурой проблематично включить навигацию с клавиатуры на сайте Bershka; версия для слабовидящих сайта РЖД теряет акценты и разделение на блоки, чтобы что-то найти надо пользоваться экранной лупой и всё читать;
— Отдельная версия для слабовидящих — не универсальное решение, если там не будет части функций, вместо инклюзивности выйдет дискриминация. Плюс, это дополнительные затраты на вторую версию сайта.
#accessibility
Хабр
Почему вам не нужна версия для слабовидящих
Представьте, что в кафе на застолье пришел веган. Его друзья, зная это, специально выбрали кафе с отдельным меню для веганов. Но в нем только макароны с кабачками и вишневый компот, а в обычном меню...
Евгений Трифонов об интерфейсах для продвинутых пользователей.
— Продвинутые пользователи (power users) стремятся использовать инструменты максимально эффективно;
— Пользователей мобильных устройств стало больше десктопных, сервисы стали ориентироваться на них, что привело к ухудшению десктопного UX. Некоторые сервисы вообще существуют только в виде мобильных приложений;
— Перемещение данных в облака лишает контроля над ними: стриминг может удалить любой альбом, не даёт возможности выбрать подходящий проигрыватель;
— Не всеми сервисами можно управлять клавиатурой и с помощью горячих клавиш (даже просто переключаться между полями клавишей Tab не всегда получается);
— В некоторых случаях ресурсы на такие доработки есть, проблема в том, что об этом просто не подумали. То есть надо просто тестировать сервисы с участием продвинутых пользователей;
— В этой функциональности нет большой социальной пользы, но разработчики часто сами являются продвинутыми пользователями и понимают её ценность. Это может сподвигнуть их к внедрению улучшений силами разработчиков без больших вложений ресурсов.
#accessibility #power_user
— Продвинутые пользователи (power users) стремятся использовать инструменты максимально эффективно;
— Пользователей мобильных устройств стало больше десктопных, сервисы стали ориентироваться на них, что привело к ухудшению десктопного UX. Некоторые сервисы вообще существуют только в виде мобильных приложений;
— Перемещение данных в облака лишает контроля над ними: стриминг может удалить любой альбом, не даёт возможности выбрать подходящий проигрыватель;
— Не всеми сервисами можно управлять клавиатурой и с помощью горячих клавиш (даже просто переключаться между полями клавишей Tab не всегда получается);
— В некоторых случаях ресурсы на такие доработки есть, проблема в том, что об этом просто не подумали. То есть надо просто тестировать сервисы с участием продвинутых пользователей;
— В этой функциональности нет большой социальной пользы, но разработчики часто сами являются продвинутыми пользователями и понимают её ценность. Это может сподвигнуть их к внедрению улучшений силами разработчиков без больших вложений ресурсов.
#accessibility #power_user
Хабр
Как прогресс ухудшил жизнь продвинутых пользователей (и как это исправить)
Неизбежный xkcd Я не люблю нытьё «раньше трава была зеленее» и в целом рад техническому прогрессу. Но считаю, что вместе с развитием компьютеров произошли и некоторые перемены, которые ухудшили жизнь...
Кирилл Улитин написал о цвете в интерфейсе: о контрасте и конфликте разных информационных слоёв цвета.
— Цветовые пространства RGB и производные от него HSB и HSL не адаптированы для человеческого восприятия. Изменение оттенка даёт цвета, неравномерные по контрасту. Цветовые модели LCH и HSLuv призваны это исправить;
— Контраст зависит от способа воспроизведения: на электронно-лучевых экранах контрастнее жёлтый на чёрном, на светодиодных — чёрный на белом;
— Алгоритм расчёта контраста в WCAG 2.1 иногда ошибается. В новую версию стандарта доступности вошёл алгоритм APCA. Можно использовать инструменты Huetone и Accessible Palette;
— Алгоритмы проверяют цвета в идеальных условиях и не учитывают пользовательский контекст: тип матрицы экрана, яркость, режимы вроде Night Shift или корректирующие очки;
— Цвет может обеспечивать узнаваемость бренда;
— Apple в руководстве по интерфейсному дизайну говорит о том, что конфликт разных информационных слоёв цвета нежелателен: красное сообщение о критической проблеме будет менее эффективным, если красный используется в приложении для некритичных ситуаций;
— При этом в новой версии macOS Big Sur разработчикам дана возможность настраивать основной цвет интерфейса приложения;
— Когда цвет бренда (например, красный) совпадает со статусными цветами в интерфейсе (сообщения об ошибках) надо вводить дополнительный цвет для элементов интерфейса, отличающийся от брендового (например, Microsoft Office 365), или добиваться цветовой разницы от 30 до 40 единиц (например, МойОфис).
#color #accessibility
— Цветовые пространства RGB и производные от него HSB и HSL не адаптированы для человеческого восприятия. Изменение оттенка даёт цвета, неравномерные по контрасту. Цветовые модели LCH и HSLuv призваны это исправить;
— Контраст зависит от способа воспроизведения: на электронно-лучевых экранах контрастнее жёлтый на чёрном, на светодиодных — чёрный на белом;
— Алгоритм расчёта контраста в WCAG 2.1 иногда ошибается. В новую версию стандарта доступности вошёл алгоритм APCA. Можно использовать инструменты Huetone и Accessible Palette;
— Алгоритмы проверяют цвета в идеальных условиях и не учитывают пользовательский контекст: тип матрицы экрана, яркость, режимы вроде Night Shift или корректирующие очки;
— Цвет может обеспечивать узнаваемость бренда;
— Apple в руководстве по интерфейсному дизайну говорит о том, что конфликт разных информационных слоёв цвета нежелателен: красное сообщение о критической проблеме будет менее эффективным, если красный используется в приложении для некритичных ситуаций;
— При этом в новой версии macOS Big Sur разработчикам дана возможность настраивать основной цвет интерфейса приложения;
— Когда цвет бренда (например, красный) совпадает со статусными цветами в интерфейсе (сообщения об ошибках) надо вводить дополнительный цвет для элементов интерфейса, отличающийся от брендового (например, Microsoft Office 365), или добиваться цветовой разницы от 30 до 40 единиц (например, МойОфис).
#color #accessibility