Мне очень нравятся статьи Ире Адеринокун - просто и по делу. Недавно она опубликовала статью "Tips for making interactive elements accessible on mobile devices", с советами как облегчить жизнь пользователям мобильных сайтов.

В статье много советов, и они должны быть достойны вашего внимания. Размещайте интерактивные элементы в доступных местах на странице. Старайтесь делать интерактивные элементы так, чтобы пользователь понимал, что с ними можно взаимодействовать. Предоставляйте инструкции для нестандартных жестов, например, как в Twitter при обновлении ленты твитов. Увеличивайте расстояние между элементами и область тапа, чтобы интерактивные элементы можно было удобно нажимать пальцем. Группируйте объекты, выполняющие одинаковые действия. Используйте возможности HTML5, для настройки раскладки клавиатуры при работе с <input>. Предоставляйте альтернативу ввода с помощью клавиатуры.

На написание статьи Ире сподвигнули рекомендации W3C - Web Content Accessibility Guidelines 2.1, которые были обновлены в июне 2018 года.

#ui #a11y #mobile

https://bitsofco.de/tips-for-making-interactive-elements-accessible-on-mobile-devices/

В 2017-ом году Анна Селезнёва из Злых Марсиан выступала на Web Standards Days с докладом "Знакомьтесь, модальное окно".

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

Доклад был в 2017-ом году. На данный момент его можно дополнить тем, что элемент <dialog> стал официальной частью стандарта HTML 5.2 в 2018-ом году.

#webstandards #ui #a11y #talk

https://www.youtube.com/watch?v=s6PI8pKQxgo

Увидел твит, в котором человек жаловался на то, что форма для ввода данных ругалась на его имя и фамилию (Zi Ye). В ответах к твиту была ссылка на хорошую статью про валидацию имён от Карли Хо — "What's in a name (validation)?"

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

Для формирования хорошего пользовательского опыта при добавлении в форму поля для ввода имени надо отталкиваться от причин, зачем оно вам необходимо. Если для отправки персонализированных сообщений, то добавьте метку "Как к вам обращаться?", если для отправки товара — "Ваше имя (для получения товара)". Если нельзя отказаться от валидации имени (такое бывает), то в сообщении с текстом ошибки не стоит говорить о том, что имя неправильное, так как это звучит абсурдно, лучше честно сообщить о том, что в системе есть ограничения и перечислить их.

Статья очень полезная. Советую почитать.

#ui #ux #validation

https://dev.to/carlymho/whats-in-a-name-validation-4b41

Сара Хигли поделилась своими мыслями по поводу доступных тултипов в статье — "Tooltips in the time of WCAG 2.1".

Web Content Accessibility Guidelines (WCAG) — это набор рекомендаций w3c по созданию доступного контента. WCAG покрывает много разных кейсов, но в нём нет явных рекомендаций, что делать с тултипами. Вся проблема в том, что у тултипов может быть разная семантика в зависимости от контекста. Более того, в тултипе могут отображаться интерактивные элементы, что вызывает ещё больше вопросов.

Для тултипов с контролами внутри Сара рекомендует использовать паттерн disclosure button, а для информационных тултипов даёт целый список советов:

- Тултипы должны появляться только на интерактивных элементах
- Тултип должен явно описывать контрол, на котором он был вызван
- Используйте aria-describedby и aria-labelledby для ассоциирования UI-контрола с тултипом
- Не используйте атрибут title для тултипов
- Не помещайте важную информацию в тултипы
- Предоставьте возможность закрыть тултип как с помощью клавиатуры, так и с помощью указателя
- Не закрывайте тултип, если пользователь водит по нему указателем мыши
- Не используйте таймаут для закрытия тултипов

Статья очень подробно разбирает проблему доступности тултипов. Рекомендую почитать всем, кто занимается разработкой интерфейсов.

#ui #a11y #wcag

https://sarahmhigley.com/writing/tooltips-in-wcag-21/

Иногда в интерфейсах можно встретить эффект "прыгающих цифр". Например, в таймере который отображает время или в числе, которое меняется при прокрутке слайдера. Робин Рэндл написал статью "The Smallest Difference" про исправление этого эффекта на примере таблиц.

В шрифтах OpenType для некоторых символов есть альтернативные глифы, отображение которых можно включать с помощью CSS. Для цифр есть альтернативный глиф перечёркнутого нуля, глифы старого и моноширинного стиля. Использование последнего стиля как раз и может решить проблему "прыгающих цифр". Для этого необходимо подключить OpenType-шрифт с такой возможностью (у меня заработало с шрифтом -apple-system) и добавить к необходимому контенту CSS-свойство font-variant-numeric: tabular-nums;. Использовании tabular-nums в таблице с большим количеством чисел очень положительно сказывается на читабельности. В статье есть гифка, где хорошо виден эффект от применения этого свойства.

Кажется, что это мелочь, но именно такие мелочи формируют пользовательский опыт.

#css #ui #ux

https://www.robinrendle.com/notes/the-smallest-difference.html

Скорее всего мы все сталкивались с эффектом "прыгающей страницы", когда при чтении статьи на экране смартфона текст прыгает из-за загружающихся изображений. Как этого избежать, Крейг Баклер рассказал в статье "Jank-free page loading with media aspect ratios".

Страница сдвигается из-за того, что в макетах с отзывчивым дизайном мы не можем задать жёсткие размеры у изображений, чтобы браузер зарезервировал для них место, так как размер может быть любым. Но браузер может рассчитать размер изображения, зная пропорции изображения и его ширину или высоту. В будущих версиях Chrome и Firefox появится поддержка определения пропорций на основе атрибутов width и height. Также разрабатывается спецификация для нового CSS-свойства aspect-ratio. Но пока поддержка пропорций не появится во всех браузерах, можно использовать трюк с пропорциональным отступом (если для padding использовать проценты, то отступ будет высчитываться на базе ширины элемента).

Концептуально проблема с "прыгающей страницей" решена в спецификации Scroll Anchoring. Проблема в том, что на данный момент эта спека не поддерживается Safari и, соответственно, всеми браузерами на iOS.

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

#css #specification #ui

https://blog.logrocket.com/jank-free-page-loading-with-media-aspect-ratios/

C 2009 года проходит событие, когда весь декабрь на сайте calendar.perfplanet.com публикуются статьи про производительность. Первого декабря появилась статья Стояна Стефанова, про то как отслеживать деградацию производительности компонентов — "JavaScript component-level CPU costs".

Стоян предлагает измерять производительность количеством инструкций, которые требуются процессору для рендеринга компонентов. Количество инструкций, в отличие от времени, более предсказуемая величина, так как она не сильно зависит от окружения. Получить количество инструкций можно с помощью трассировки в Chrome. Автоматизировать сбор метрик можно с помощью Puppeteer. Но не всё так гладко, так как для выполнения одного и того же кода может требоваться разное количество инструкций из-за сборщика мусора или оптимизаций. Чтобы корректно подсчитать метрику, не рекомендуется запускать один и тот же код несколько раз. Для того чтобы исключить операции, вызванные GC, необходимо вычесть количество инструкций GC (можно получить в трассировке) из общего количества инструкций.

Идея интересная, но мне кажется сомнительным гонять эти проверки перед каждым коммитом, как предлагается в статье.

#performance #ui #chrome

https://calendar.perfplanet.com/2019/javascript-component-level-cpu-costs/

Неделя релизов продолжается. Вчера компания Adobe представила свою библиотеку React-компонентов — "Introducing React Spectrum".

В React Spectrum каждый компонент поделён на две части, которые живут в отдельных библиотеках. В библиотеке React Aria находятся хуки для работы с a11y, i18n и поведением компонентов. В библиотеке React Stately — хуки для работы со стейтом компонентов. Такое разделение удобно для переиспользования кода между разными платформами. Эти библиотеки комбинируются под зонтиком библиотеки React Spectrum, которая имплементирует дизайн-систему от Adobe. Компонентов в библиотеке довольно много. Есть Calendar, Table, Tree и другие стандартные компоненты.

Интересное решение. Если нужен компонент с немного другим поведением, можно не форкать библиотеку, а просто переопределить необходимый хук.

#react #ui #release

https://react-spectrum.adobe.com/blog/introducing-react-spectrum.html