#ссылка дня

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

Оно как бы и да и нет. Например, давайте представим себе на минуту средних дизайнеров сайтов и приложений.

Чаще всего они сидят в условиях, близких к идеальным. На стуле, перед большим монитором. И рисуют, не знаю, приложение для оплаты парковки. Он или она молоды и здоровы, мышка твёрдо лежит в руке. Идиллия.

Как по их представлению человек будет пользоваться приложением? Припарковался, устроился поудобнее и оплатил?

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

И так с любым проектом. Думать надо.

Собственно, вот и ссылка на сегодня: https://a11ymyths.com/ru/

Мифы о доступности на разных языках. Всем читать, котаны.

#a11y

#заметка дня

Сразу с панча: не используйте input[type=“number”].

Он тащит за собой целый ворох проблем:

1. странно выглядит (ниже о том, почему);
2. плохо стилизуется;
3. не подчиняется стандартным атрибутам вроде maxlength (sick!);
4. имеет ARIA-роль spinbutton (ниже поясню, что это);
5. позволяет ввести e (10e9) и валидация даже не заикнётся;
6. в старых Safari и Chrome округляет введённые числа (например, номер кредитки) до мантиссы и экспоненты (по-моему, это уже конец);
7. во время ввода можно случайно нажать стрелку вверх или вниз (или даже тронуть колесо мышки на некоторых ос) и введённое число изменится.
8. Если случится кривой автоввод (например, два пробела на маке дадут точку, а нужна запятая), value будет пустой.

Как видите, минусов немало. А откуда они вообще взялись?

А всё просто: input[type=“number”] создавался для имитации т. н. tally counter, ручного счётчика. Ну вы наверняка видели фильмы, где людей или скот считали надетым на палец устройством. Отсюда и ARIA-роль spinner (счётчик оборотов), и стрелки ввода.

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

Так что же делать?

А делать следующее:

<input type="text" inputmode="numeric" pattern="[0-9]*">

В конце 2022 года с такой конструкцией проблем у вас не возникнет. И с точки зрения доступности всё верно. И на мобильных клавиатура нужная встанет.

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

За подробностями можно обратиться к блогу разработчиков официального сайта правительства Великобритании: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

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

Я помню подобное было у сайта kremlin.ru. И то в итоге почти все фишки исчезли со временем... Но мы отклонились от темы.

Подытожим: input[type=“number”] делался не для того, как его применяют.

Подумайте об этом.

#css #html #number #aria #semantics #a11y

#расширение дня

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

Сегодняшнее расширение пытается решить проблему недостаточного контраста на сайтах: https://fixa11y.com/

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

Полезная вещь, короче, надо сказать.

#css #a11y #contrast

#фишка дня

Эмулируем различные особенности зрения легко и просто!

Если залезть в Chrome DevTools, нажать на три кнопки, выбрать Rendering и найти раздел Emulate vision deficiencies, можно легко понять, как видят ваш сайт, например, люди с искажённым цветовосприятием. Дальтоники.

Список эмулируемых особенностей:
1. Нечёткое зрение (тут и близорукость, и дальнозоркость подойдёт)
2. Протанопия (нет красного)
3. Дейтеранопия (нет зелёного)
4. Тританопия (нет синего)
5. Ахроматопсия (нет цвета)

В Chrome 112 нас ждёт ещё возможность имитировать пониженную контрастность (для имитации катаракты, например): https://developer.chrome.com/blog/new-in-devtools-112/#reduced-contrast

А ещё они сделают пункты выбора более понятными :)

#a11y #chrome #devtools

#фишка дня

Как предотвратить взаимодействие пользователя с элементом?

pointer-events: none — скажете вы.

Да. Но нет. А что насчёт клавиатурного фокуса? А скринридеры? Так не пойдёт.

Благо, есть решение!

Начиная с Firefox 112 и Safari 15.5 у нас наконец-то есть поддержка атрибута inert. Что это такое?

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

То есть, если вы зададите элементу атрибут inert, то:
1. Будет предотвращена обработка события click.
2. Элемент перестанет получать фокус и...
3. ...станет недоступен для скринридеров (исключён из a11y tree).

Поддержка уже давно есть в Chrome, начиная со 102 версии, и теперь, с вводом в строй Firefox 112 — есть во всех современных движках.

Ну и, естественно, присущие атрибуту свойства можно повторить ручками, вот пример: https://codepen.io/alinaki/pen/ZEqJepB

#inert #attribute #html #a11y

#расширение дня

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

Сегодняшнее расширение пытается решить проблему недостаточного контраста на сайтах: https://fixa11y.com/

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

Полезная вещь, короче, надо сказать.

#css #a11y #contrast #бородач

#заметка дня

В чате вчера разразилась целая баталия по поводу того, можно ли вкладывать в кнопки aka button что-то помимо простой разметки для текста с иконкой.

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

Так вот, семантически вкладывать div в a в 2023 году весьма верно. А вот вкладывать div в button — уже нет 🙂 Потому что button принимает только фразовый контент, коим div не является. Ссылки даны на кодпен, копируйте оттуда в валидатор и смотрите сами.

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

И решение это — растянуть псевдоэлемент, принадлежащий ссылке или кнопке, на весь контейнер: https://codepen.io/IhorPower/pen/YzRqzyL (пример от подписчика).

Чуть позже разберем бенефиты такого решения, а пока доброе утро, котаны :)

#css #trick #a11y

#фишка дня

Эмулируем различные особенности зрения легко и просто!

Если залезть в Chrome DevTools, нажать на меню "три точки", выбрать Rendering и найти раздел Emulate vision deficiencies, можно легко понять, как видят ваш сайт, например, люди с искажённым цветовосприятием. Дальтоники.

Список эмулируемых особенностей:
1. Нечёткое зрение (тут и близорукость, и дальнозоркость подойдёт)
2. Протанопия (нет красного)
3. Дейтеранопия (нет зелёного)
4. Тританопия (нет синего)
5. Ахроматопсия (нет цвета)

Начиная с Chrome 112 есть возможность имитировать пониженную контрастность (для имитации катаракты, например): https://developer.chrome.com/blog/new-in-devtools-112/#reduced-contrast

#a11y #chrome #devtools #бородач

#фишка дня

Как предотвратить взаимодействие пользователя с элементом?

pointer-events: none — скажете вы.

Да. Но нет. А что насчёт клавиатурного фокуса? А скринридеры? Так не пойдёт.

Благо, есть решение!

Начиная с Firefox 112 и Safari 15.5 у нас наконец-то есть поддержка атрибута inert. Что это такое?

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

То есть, если вы зададите элементу атрибут inert, то:
1. Будет предотвращена обработка события click.
2. Элемент перестанет получать фокус и...
3. ...станет недоступен для скринридеров (исключён из a11y tree).

Поддержка уже давно есть в Chrome, начиная со 102 версии, и теперь, с вводом в строй Firefox 112 — есть во всех современных движках.

Ну и, естественно, присущие атрибуту свойства можно повторить ручками, вот пример: https://codepen.io/alinaki/pen/ZEqJepB

#inert #attribute #html #a11y #бородач

#заметка дня

Недавно я читал обзор автомобиля и автор, в лучших традициях, решил запихать в статью огромную таблицу.

Таблица находилась в выделенном контейнере и приводила к появлению горизонтального скролла в нём. Мне пришлось тянуться к мыши, зажимать Shift чтобы скроллить горизонтально… Какая прелесть.

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

Решение же на самом деле до безумия простое: tabindex=“0” на контейнер и дело в шляпе. Это позволит пользователю установить фокус на желаемый блок и скроллить стрелками.

По пути, раз уж пошло дело, стоит установить стили фокуса и атрибуты role и aria-labelledby для соответствия Web Content Accessibility Guidelines.

Документ здоровый, но для практического применения нужны лишь несколько пунктов: «2.1.1 Keyboard», «4.1.2 Name, Role, Value», «1.4.10 Reflow», «2.4.7 Focus Visible».

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

В общем, не ленитесь. Дайте людям возможность прочитать статью так, как удобно им. Особенно когда это ничего вам не стоит 😉

Ну и повторю решение: https://codepen.io/alinaki/pen/xxgpmeZ

#css #table #keyboard #focus #a11y #бородач

#библиотека дня

Сегодня не самая обычная библиотека, решающая, впрочем, достаточно сложную задачу.

Компания Evil Martians и Андрей Ситник конкретно известны своим скурпулёзным подходом к интерфейсам и их оптимизации. Если кто-то ещё не в курсе существования их блога, настоятельно рекомендую: https://evilmartians.com/chronicles

Ну конкретно по теме канала — тег Frontend, конечно же.

Так вот, одной из их достаточно новых специализаций является разработка интерфейсов профессиональных утилит, в том числе для десктопа. Например, UI для HTTPie.

А без чего нельзя представить себе профессиональное приложение? Правильно, без хоткеев. Да и вообще нынче доступность без хоткеев — не доступность вовсе.

И вот Андрей Ситник на днях выкатил обновление своей библиотеки KeyUX: https://github.com/ai/keyux

Пример её работы на видео. А что умеет?

1. Добавлять горячие клавиши по aria-keyshortcuts
2. Возвращает на место :active у кнопок при использовании клавиатуры
3. Превращает списки в навигационные элементы
4. Правильно отрабатывает стрелки, табуляцию и Esc.
5. Показывает подсказки если нужно.

В общем, мне кажется, это всё должно было быть в браузерах по-умолчанию.

#javascript #a11y #hotkeys

#фишка дня

Эмулируем различные особенности зрения легко и просто!

Если залезть в Chrome DevTools, нажать на меню "три точки", выбрать Rendering и найти раздел Emulate vision deficiencies, можно легко понять, как видят ваш сайт, например, люди с искажённым цветовосприятием. Дальтоники.

Список эмулируемых особенностей:
1. Нечёткое зрение (тут и близорукость, и дальнозоркость подойдёт)
2. Протанопия (нет красного)
3. Дейтеранопия (нет зелёного)
4. Тританопия (нет синего)
5. Ахроматопсия (нет цвета)

Начиная с Chrome 112 есть возможность имитировать пониженную контрастность (для имитации катаракты, например): https://developer.chrome.com/blog/new-in-devtools-112/#reduced-contrast

#a11y #chrome #devtools #бородач

#заметка дня

Сразу с панча: не используйте input[type=“number”].

Он тащит за собой целый ворох проблем:

1. странно выглядит (ниже о том, почему);
2. плохо стилизуется;
3. не подчиняется стандартным атрибутам вроде maxlength (sick!);
4. имеет ARIA-роль spinbutton (ниже поясню, что это);
5. позволяет ввести e (10e9) и валидация даже не заикнётся;
6. в старых Safari и Chrome округляет введённые числа (например, номер кредитки) до мантиссы и экспоненты (по-моему, это уже конец);
7. во время ввода можно случайно нажать стрелку вверх или вниз (или даже тронуть колесо мышки на некоторых ос) и введённое число изменится.

Как видите, минусов немало. А откуда они вообще взялись?

А всё просто: input[type=“number”] создавался для имитации т. н. tally counter, ручного счётчика. Ну вы наверняка видели фильмы, где людей или скот считали надетым на палец устройством. Отсюда и ARIA-роль spinner (счётчик оборотов), и стрелки ввода.

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

Так что же делать?

А делать следующее:

<input type="text" inputmode="numeric" pattern="[0-9]*">

В 2024 году с такой конструкцией проблем у вас не возникнет. И с точки зрения доступности всё верно. И на мобильных клавиатура нужная встанет.

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

За подробностями можно обратиться к блогу разработчиков официального сайта правительства Великобритании: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

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

Я помню подобное было у многих государственных сайтов,. но почти все блоги исчезли со временем...

Подытожим: input[type=“number”] делался не для того, как его применяют.

Подумайте об этом.

#css #html #number #aria #semantics #a11y #бородач

#заметка дня

В чате вопрос возник: «А при каких условиях и на что нужно ставить role=“button”?»

Вопрос весьма разумный, ведь вроде как кнопка она и есть кнопка, button. Вот только не всё так просто.

Для начала давайте определимся раз и навсегда: ссылки вместо кнопок не используются никогда.

Ссылка – это или переход к якорю на этой же странице, или же переход на другую страницу и только. Никаких a[href=“#”] с onClick, забудьте.

Остаются button, input[type=“button”] и input[type=“submit”].

Последние потомков внутри не предполагают и являются замещаемыми. Это значит, псевдо-элементов у нас тоже там нет. Впрочем, они вполне себе неплохо оформляются и как вещь в себе работают сносно: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/button

И вот, button. Что же с ним может быть не так, что нам потребуется нечто с role=“button”?

Давайте с очевидного: валидатор запрещает иметь div внутри button.

Выражаясь языком спецификации, button ожидает фразовый контент, а не потоковый: https://caninclude.glitch.me/can/include/?child=div&parent=button

То есть речь идёт не только о div, а ещё о десятке тегов. В итоге официально вкладывать можно практически один лишь span. Наверное, это не всем и не всегда удобно.

Впрочем, браузеры такой трюк позволяют.

Но если вам не всё равно — добавьте role=“button” и tabindex на любой удобный вам элемент, чтобы превратить его в интерактивный. Валидатор и скринридеры будут довольны. А ещё старые Safari, которые не умеют во flexbox на кнопках.

Мы у себя в дизайн-системе назвали такой компонент PlainButton, вот иногда ну надо.

Второй же случай посложнее.

Есть такой вид кнопок, toggle-кнопки. Переключатели. Это не checkbox, это не switch. Это просто что-то, что можно «зажать» сейчас и «отжать» потом. Например, кнопки в текстовом редакторе.

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

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

В общем, если вы подменяете логику работы кнопки с моментальной реакции на что-то иное вроде toggle, вам необходимо отдельно указать как минимум два необходимых атрибута: role=“button” и aria-pressed. Это же касается, например, кнопок открытия аккордеонов. Вот только вместо pressed нужно будет устанавливать expanded: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role

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

#button #a11y #role #toggle #бородач

#ссылка дня

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

Оно как бы и да и нет. Например, давайте представим себе на минуту средних дизайнеров сайтов и приложений.

Чаще всего они сидят в условиях, близких к идеальным. На стуле, перед большим монитором. И рисуют, не знаю, приложение для оплаты парковки. Он или она молоды и здоровы, мышка твёрдо лежит в руке. Идиллия.

Как по их представлению человек будет пользоваться приложением? Припарковался, устроился поудобнее и оплатил?

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

И так с любым проектом. Думать надо.

Собственно, вот и ссылка на сегодня: https://a11ymyths.com/ru/

Мифы о доступности на разных языках. Всем читать, котаны.

#a11y #бородач

#заметка дня

Недавно я читал обзор автомобиля и автор, в лучших традициях, решил запихать в статью огромную таблицу.

Таблица находилась в выделенном контейнере и приводила к появлению горизонтального скролла в нём. Мне пришлось тянуться к мыши, зажимать Shift чтобы скроллить горизонтально… Какая прелесть.

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

Решение же на самом деле до безумия простое: tabindex=“0” на контейнер и дело в шляпе. Это позволит пользователю установить фокус на желаемый блок и скроллить стрелками.

По пути, раз уж пошло дело, стоит установить стили фокуса и атрибуты role и aria-labelledby для соответствия Web Content Accessibility Guidelines.

Документ здоровый, но для практического применения нужны лишь несколько пунктов: «2.1.1 Keyboard», «4.1.2 Name, Role, Value», «1.4.10 Reflow», «2.4.7 Focus Visible».

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

В общем, не ленитесь. Дайте людям возможность прочитать статью так, как удобно им. Особенно когда это ничего вам не стоит 😉

Ну и повторю решение: https://codepen.io/alinaki/pen/xxgpmeZ

#css #table #keyboard #focus #a11y #бородач

#инструмент дня

Как сделать текст поверх картинки читаемым?

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

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

Как подобрать цвет оверлея и прозрачность? Очень просто, воспользоваться вот этим инструментом: https://codepen.io/yaphi1/pen/oNbEqGV

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

#css #tool #a11y

#инструмент дня

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

А для этого о них надо как-то договориться, продемонстрировать, выявить возможные проблемы и нестыковки. К примеру, стрелки не работают там, где должны.

Ну или, как вариант, показать кому-то как эффективно можно управлять текстовым или графическим редактором, девтулзами. Стать настоящим хоткей-ниндзей!

Что ж, по крайней мере для маководов у меня есть решение! Keycastr — https://github.com/keycastr/keycastr

Задача этой маленькой утилиты буквально вывести на экран нажатые клавиши. Конечно, есть выбор — показывать все, или только модификаторы.

Очень круто было наблюдать, как наш техлид джирой манипулирует :)

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

Upd.

Альтернатива для Windows: http://carnackeys.com/

Для Linux:
https://github.com/bm-mit/key-caster
https://www.thregr.org/wavexx/software/screenkey/
https://github.com/critiqjo/key-mon

#hotkey #a11y #record