Недавно Фрэнк Фаулкнер — участник рабочих групп W3C — обновил свою статью про проблемы доступности атрибута title — "Using the HTML title attribute".

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

Если title используется для дополнительного описания ссылок, то эту информацию стоит вынести в текст ссылки. Если title используется для добавления описания к изображению, то лучше всего вынести это описание как текст и разместить его рядом с изображением. В 2020 году осталось только единственное место, где title может быть полезен, — добавление дополнительной информации к фреймам. Но фреймы в современном web'е не используются, так что про этот случай можно забыть.

Хорошая статья. Рекомендую почитать.

#a11y #html

https://developer.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/

В последней подборке новостей Web Platform News увидел небольшой пост про проблемы ленивой загрузки iframe — "The <iframe loading="lazy"> attribute is not ready".

В августе 2019 в Chrome появилась поддержка атрибута loading для ленивой загрузки изображений и iframe'ов. Атрибут loading для изображений уже стандартизирован, но loading для iframe остаётся экспериментальной фичей. В статье “Native lazy-loading for the web” команда разработки Chrome не акцентировала на этом внимание (сейчас статью исправили), поэтому эта фича стала появляться на production-сайтах.

На данный момент <iframe loading="lazy"> работает только в Chromium. При этом в текущей реализации есть известные проблемы, исправление которых может поломать сайты, которые уже начали использовать iframe loading Так как разработчики стандартов руководствуются принципом "don't break the web", есть риск, что эти баги будут увековечены в окончательном стандарте. Поэтому если вы уже начали использовать loading для iframe, от него стоит временно отказаться.

#html #lazy #chrome #problem

https://webplatform.news/issues/2020-04-27

Нашёл в дизайн-доках Chromium статьи про создание форм авторизации: "Password Form Styles that Chromium Understands", "Create Amazing Password Forms".

Браузеры и менеджеры паролей помогают пользователям автоматически заполнять поля форм авторизации. Для того чтобы вся эта "магия" работала правильно, нужно использовать семантическую вёрстку и придерживаться определённых правил. Например, чтобы менеджеры паролей смогли подхватить отправленные данные, после успешного логина должен произойти переход на новую страницу или этот переход должен быть сэмулирован с помощью history.pushState или history.replaceState. Для ускорения заполнения формы, поля ввода пароля и логина нужно разметить атрибутами autocomplete="current-password" и autocomplete="username". Если у поля стоит атрибут autocomplete="new-password" браузер или менеджер паролей будут показывать интерфейс для создания пароля.

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

#html #ux

https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
https://www.chromium.org/developers/design-documents/create-amazing-password-forms

Юля Бухвалова написала статью о доступности с большим количеством примеров самых распространённых проблем — "Недоступность в картинках".

В самом начале статьи есть небольшой ликбез (must read) по использованию скринридеров в Windows (Narrator) и macOS (Voice Over). Все скринридеры помогают пользователям перемещаться по сайту, предоставляя списки для заголовков, ссылок, изображений и ориентиров (теги main, header, footer, nav и т.п.)

Пара советов из статьи. Для упрощения работы с формами следует использовать теги fieldset и legend. Не следует верстать на дивах интерактивные элементы, лучше всего использовать вместо них соответствующие элементы из стандарта ( button, input и т.д.) Для изображений img всегда нужно добавлять атрибут alt. Если изображение декоративное, его следует поместить в CSS или использовать пустую строку в описании alt.

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

#a11y #html

http://css.yoksel.ru/inaccessibility/

Элайна Натарио написала статью с объяснением, в каких случаях для описания изображения нужно использовать alt и figcaption — "Alt vs Figcaption".

Основные отличия. Атрибут alt используется для буквального описания, что находится на изображении. Эта информация будет использоваться скринридерами при чтении страницы. Элемент figcaption используется для добавления дополнительной (контекстной) информации к разным объектам на странице: изображения, блоки текста, видео и т.п. Атрибут alt по умолчанию не отображается на странице, элемент figcatption отображается. И alt, и figcaption можно использовать для описания одного и того же изображения:

<figure>
  <img
    src="cat.jpg"
    alt="A black cat sitting on the floor and looking to the side">
  <figcaption>
    Vasya the cat shows his disrepectful behaviour towards his human
  </figcaption>
</figure>

Полезная статья. Рекомендую почитать.

#html #a11y

https://thoughtbot.com/blog/alt-vs-figcaption

Энтони Рикод на perfplanet написал обзор HTML- и CSS-фич, которые могут помочь в уменьшении размера JS-бандла — "HTML and CSS techniques to reduce your JavaScript".

В статье рассказывается про то, как без использования JavaScript отобразить нужное количество строк в контейнере. Рассказывается про использование position: sticky для создания эффекта прилипающих к границам экрана элементов, про плавную прокрутку, про использование CSS Scroll Snap для создания слайдеров и про ленивую загрузку изображений.

Полезный обзор. Почитайте, если ещё не встречались с этим фичами.

#performance #html #css

https://calendar.perfplanet.com/2020/html-and-css-techniques-to-reduce-your-javascript/

Стэрен Джианнини решил отказаться от модных технологий и стал вести свой блог на чистом HTML и CSS без использования CMS, генераторов статических сайтов и т.п. Про это он написал статью "My stack will outlive yours".

Стэрен пишет о том, что концептуально в web'е существуют два вида страниц: web-страницы с простым содержанием и web-приложения. Обычный HTML и CSS покрывает всё необходимое, что может потребоваться для создания простых web-страниц: лендингов, сайтов-портфолио, блогов и сайтов с документацией. При разработке простого сайта не требуется настраивать сборку, устанавливать зависимости и использовать тяжёлые IDE. Он будет прекрасно работать и через 10 лет. Использование семантичной вёрстки поможет не заблудиться в коде, а если нужно будет поменять однотипные места на нескольких похожих страницах, то для этого можно использовать функцию редактора ”Replace in files”.

Мне лично нравится такой подход. Конечно, для сайтов с большим количеством страниц, это может быть непрактично, но для маленьких сайтов это хороший вариант.

#html #css #musings

https://blog.steren.fr/2020/my-stack-will-outlive-yours/

Сара Суайдан рассказала об оптимизации содержимого страницы для режима чтения — "Design for reading: tips for optimizing content for Reader modes and reading apps".

Стили страницы могут быть доступны не для всех пользователей, например они недоступны для пользователей RSS-ридеров или при использовании режима чтения в браузере. Поэтому очень не рекомендуется размещать контент на уровне стилей. Если с помощью разметки нельзя выразить текущее визуальное представление (например, сложную анимацию), то нужно добавить её описание. Иногда, наоборот, нужно скрыть какую-либо часть контента в режиме для чтения. В этом случае может помочь глобальный атрибут hidden.

Основная мысль статьи. Наш контент не всегда выглядит так, как мы этого хотим. Это не должно иметь большого значения, если поддерживать строгое разделение между контентом и стилями; контент будет доступен всем пользователям.

#html #css

https://www.sarasoueidan.com/blog/tips-for-reader-modes/

Эдди Османи написал большую статью про элемент <img> и его влияние на производительность — "The Humble img Element And Core Web Vitals".

В статье Эдди рассказывает про разные аспекты использования изображений, которые могут оказывать негативный эффект на метрики Core Web Vitals. Например, если у изображений не установлены атрибуты width и height, загрузка изображений будет приводить к смещению элементов на странице, ухудшая метрику Cumulative Layout Shift (CLS). Если основное изображение сайта загружается слишком поздно, например, после выполнения клиентского кода, то будет ухудшаться метрика Largest Contentful Paint (LCP). В этом случае нужно добавить изображение в HTML-разметку или загрузить его с помощью preload, если предыдущий вариант не подходит.

Хорошая статья. Рекомендую почитать всем, кто занимается производительностью.

#performance #html

https://www.smashingmagazine.com/2021/04/humble-img-element-core-web-vitals/

Скотт О'Хара написал статью про деактивацию ссылок с учётом доступности — "Disabling a link".

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

Полностью отключить ссылку можно удалением атрибута href. После удаления href скринридеры не будут считать ссылку ссылкой, поэтому нужно добавить role="link". Чтобы скринридеры анонсировали неактивный статус, нужно добавить aria-disabled="true".

В коде деактивированная ссылка с учётом всех требований будет выглядеть так:

<a role="link" aria-disabled="true">
  Learn something!
</a>

#a11y #html

https://www.scottohara.me/blog/2021/05/28/disabled-links.html

Сценарии использования HTML-элемента dialog

Сэм Торогуд из Google рассказал про сценарии использования элемента <dialog> — "In Defence Of Dialog".

Элемент <dialog> предназначен для создания диалоговых окон. Нативный HTML-диалог поддерживает автоматический захват фокуса при переходе по Tab и устраняет проблемы с контекстом наложения без использования JavaScript.

В статье рассказывается про создание одного и нескольких модальных окон с помощью <dialog>, про реализацию открывающегося сайдбара с закрытием по затемнённому фону, про предотвращение прокрутки при открытии окон. Также из статьи узнал про method="dialog" в формах. Если форма с method="dialog" находится внутри <dialog>, то она будет автоматически закрыта при отправке формы. Для всех сценариев использования в статье есть интерактивные демки.

У нативного диалога трагичная судьба — процесс его проникновения в основные браузерные движки занял десять лет. На протяжении этого времени его даже однажды хотели удалить из спецификации. Сейчас поддержка <dialog> есть в Chrome, в Firefox за экспериментальным флагом и в Safari Technology Preview 134.

#html

https://whistlr.info/2021/in-defence-of-dialog/

В поиске лучшего способа балансировки переносов слов

Попробовал сегодня по-быстрому сделать удобочитаемые переносы слов заголовков статей на сайте defront. Оказалось, что не всё так просто.

Зачем нужна балансировка переносов. Браузеры не заботятся о читаемости текста при переносе слов, поэтому в блогах зачастую можно встретить такие переносы заголовков статей:

Причины отсутствия поддержки AVIF в
Safari

хотелось бы, чтобы текст выглядел так:

Причины отсутствия
поддержки AVIF в Safari

В последнем варианте текст сбалансирован и не отвлекает внимание.

Для решения этой проблемы можно воспользоваться готовыми балансировщиками переноса слов. Есть две популярные реализации: от New York Times и от Adobe. Реализация от Adobe для меня слишком тяжёлая, реализация от New York Times полегче, но она хорошо работает только с небольшими объёмами текста.

Реализация New York Times для небольших заголовков подходит идеально, также она работает быстрее балансировщика Adobe благодаря использованию простого алгоритма на базе бинарного поиска. Но у неё есть проблема с видимым сдвигом позиции слов. Дениэл Александерсен в статье про форк балансировщика от New York Times предлагает скрывать текст заголовка до тех пор, пока не сработает балансировка, но мне это кажется очень хрупким решением. Если по каким-то причинам скрипт окажется сломан, то пользователь не увидит заголовка статьи. Также есть сомнения, что все скринридеры будут хорошо интерпретировать появляющийся из ниоткуда заголовок статьи.

Ещё можно сделать автоматическую вставку <br> в нужном месте разрыва заголовка. На больших экранах заголовки будут выглядеть хорошо, на маленьких экранах в редких случаях перенос будет выглядеть странно:

Использование
SomeNewApi
и
OtherNewApi
в Node.js

Также в стандарте CSS Text Level 4 есть упоминание CSS-свойства text-wrap: balance. Оно было предложено Adobe в 2013 году, и его поддержки до сих пор нет ни в одном браузере.

Сначала хотел использовать форк балансировщика New York Times, но его недостатки перевешивают все преимущества. Возможно, что потом попробую покопать в сторону варианта с <br>, но пока оставлю всё без изменений. Балансировка переноса слов — это коварная штука.

#html #ux #a11y

https://defront.ru/posts/2022/01-january/11-in-search-of-best-line-wrap-balance/