Скотт Джел написал пост про необходимость сбора метрик сайтов, учитывающих средства доступности, — "We need more inclusive web performance metrics".

Метрики FCP и LCP, которые предоставляют браузеры, — отличные средства для анализа скорости появления контента на странице. Но эти метрики отражают опыт работы с сайтами не всех пользователей. Для кого-то контент может быть недоступен, пока страница не станет полностью интерактивна, так как многие web-приложения добавляют интерактивность для средств доступности с помощью загружаемого JavaScript. То есть если пользователь использует скринридер, то он не сможет получить доступ к странице, пока на ней не будет выполнен необходимый JavaScript-код.

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

#a11y #metrics #performance

https://www.filamentgroup.com/lab/a11y-ready/

В техническом блоге Facebook была опубликована статья про подходы улучшения доступности, которые были использованы на новом сайте социальной сети, — "Making Facebook.com accessible to as many people as possible".

Основные пункты статьи. Чтобы не допускать распространённых ошибок доступности, используют eslint-плагин eslint-plugin-jsx-a11y. Для работы с фокусом используют специальные компоненты, которые также упрощают добавление навигации с клавиатуры. Для улучшения читабельности текста на этапе сборки конвертируют размер шрифта в rem. Иерархия заголовков в документе поддерживается автоматически с помощью специального API. Улучшили работу горячих клавиш с помощью API на базе React контекста. Для валидации разметки используют самописный инструмент, который подсвечивает красным оверлеем все элементы с проблемами a11y.

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

#a11y #react #facebook

https://engineering.fb.com/web/facebook-com-accessibility/

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

В самом начале статьи есть небольшой ликбез (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/

Барри Поллард — автор книги "HTTP/2 in Action" и один из авторов "Web Almanac" — проанализировал данные Lighthouse из HTTP Archive и поделился своими находками — "What do Lighthouse Scores look like across the web?".

Всего лишь 10% сайтов были оценены больше 80 в категории производительности. Медианное значение оценки — 31. Это означает, что большинство сайтов неоптимизировано, и, скорее всего, работают медленно. Наиболее низкая оценка метрик приходится на Largest Contentful Paint (LCP) и Time to Interactive (TTI) — всего лишь 21% сайтов получили хорошую оценку по этим метрикам.

Лучше всего сайты показывают себя в категориях Accessibility и SEO. Хорошие оценки Accessibility объясняются набором типов проверок в Lighthouse. Нужно понимать, что в категории Accessibility оценка не говорит о том, что сайт доступен (можно написать недоступную страницу с оценкой 100), оценка говорит о том, что сайт следует основным советам для улучшения доступности.

Интересное исследование. Рекомендую почитать, чтобы получить больше понимания об оценках в Lighthouse.

#performance #a11y #research

https://www.tunetheweb.com/blog/what-do-lighthouse-scores-look-like-across-the-web/

Джош Комю написал статью о том, как он программирует без клавиатуры — "Hands-Free Coding".

В этом году у Джоша возник локтевой туннельный синдром, из-за которого он больше не может использовать мышь и клавиатуру. Чтобы продолжать работать, он перешёл на альтернативные системы ввода: голосовой ввод текста и систему отслеживания взгляда. Для голосового ввода текста используется программа Talon, которая приспособлена для написания кода. Для отслеживания взгляда используется девайс tobii 5. По сравнению с обычным воркфлоу скорость написания кода примерно в два раза ниже, но самое главное, что благодаря такому набору софта/железа можно полноценно работать с компьютером.

Рекомендую почитать статью и посмотреть там небольшие скринкасты рабочего воркфлоу Джоша.

P.S. В случае проблем не откладывайте поход к врачу, не упарывайтесь с кодом и делайте регулярные перерывы.

#programming #a11y

https://joshwcomeau.com/accessibility/hands-free-coding/
https://habr.com/ru/company/vdsina/blog/524664/ (перевод)

Реми Шарп поделился своими мыслями о влиянии JavaScript на доступность сайтов — "Please disable JavaScript to view this site".

Недавно Хэйдон Пикеринг — автор нескольких книг про фронтенд-разработку — сделал в своём блоге редизайн, который поставил на уши сообщество разработчиков. Если вы попробуете зайти на его сайт, с большой вероятностью вам будет предложено отключить JS, чтобы получить к нему доступ. Таким образом Хэйдон продемонстрировал своё отношение к текущим трендам web-разработки.

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

Основная мысль статьи: JavaScript настолько стал неотъемлем от веба, что мы перестали задумываться о его влиянии на доступность и воспринимаем его наличие как нечто само собой разумеющееся.

#js #musings #a11y

https://remysharp.com/2020/11/30/please-disable-javascript-to-view-this-site

Элайна Натарио написала статью с объяснением, в каких случаях для описания изображения нужно использовать 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

Матиас Байненс — разработчик V8 и Chrome — написал статью о том, как была реализована симуляция недостатков зрения в Chrome DevTools — "Simulating color vision deficiencies in the Blink Renderer".

Результаты исследования WebAIM говорят о том, что контраст текста — самая распространённая проблема доступности сайтов. Вы скорее всего встречали его упоминание в DevTools или Lighthouse и с большой вероятностью удивлялись тому, что эти инструменты жаловались на плохой контраст, в то время как вы могли легко всё прочитать. Дело в том, что анализ контраста включает в себя разные особенности восприятия цвета: кто-то не видит красный цвет, кто-то зелёный и т.п.

Для реализации симуляции недостатков зрения разработчики сделали прототип на обычных web-технологиях. Для этого они воспользовались SVG-фильтром на root-элементе. В этом фильтре описывается преобразование цветов на основе научной работы "A Physiologically-based Model for Simulation of Color Vision Deficiency". Чтобы не внедрять на страницу лишние элементы, решение с SVG было перенесено в движок браузера.

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

#a11y #internals #chrome

https://developers.google.com/web/updates/2020/11/cvd

Вчера в блоге Google появилась новость о том, что Google Docs переходит на движок рендеринга, работающий поверх canvas, — "Google Docs will now use canvas based rendering: this may impact some Chrome extensions".

После публикации в сети появились обсуждения насколько это оправдано. Своими мыслями поделился один из авторов оригинального Google Docs. Он говорит о том, что HTML-движки хороши для рендеринга обычных сайтов, но им не хватает фич для реализации полноценных WISWYG-редакторов. И о том, что кастомный движок рендеринга выигрывает по скорости у HTML-движков благодаря ограниченному набору функций.

У многих возникли вопросы по поводу доступности. Я немного потестил тестовый документ из статьи, и с доступностью там более менее всё ок. Озвучивание текста включается с помощью хоткея cmd+option+z — появится div с aria-live вне области просмотра с текстом документа текущей страницы. При перемещении по документу озвучивается текущая строка.

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

#architecture #announcement #google #a11y

https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html
https://news.ycombinator.com/item?id=27129858 (обсуждение на Hacker News)

Скотт О'Хара написал статью про деактивацию ссылок с учётом доступности — "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

Использование focus-visible с обратной совместимостью

Патрик Лаук поделился своим подходом для управления стилями фокуса — ":focus-visible and backwards compatibility".

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

Для кастомизации фокуса во всех браузерах с учётом :focus-visible Патрик советует использовать следующий подход:

/* стилизация фокуса */
/* в устаревших браузерах */
button:focus {
  outline: dotted 5px teal; 
}

/* отключение стилей `:focus` */
/* в современных браузерах */
*:focus:not(:focus-visible) {
  outline: none !important;
}

/* стилизация фокуса */
/* в современных браузерах */
button:focus-visible {
  outline: dotted 5px teal; 
}

На данный момент :focus-visible поддерживается во всех браузерах (в Safari за экспериментальным флагом).

#css #a11y

https://www.tpgi.com/focus-visible-and-backwards-compatibility/

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

Попробовал сегодня по-быстрому сделать удобочитаемые переносы слов заголовков статей на сайте 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/

Новое дерево доступности в Chrome DevTools

Йохан Бей из команды разработки Chrome DevTools рассказал про новое дерево доступности, которое появится в будущих версиях Chrome — "Full accessibility tree in Chrome DevTools".

С помощью дерева доступности скринридеры и другие технологии доступности предоставляют средства для работы со страницей. В Chrome 97 и ниже дерево доступности в один момент времени может отображать только выбранный элемент и его потомков. В новой версии Chrome дерево будет отображаться для всей страницы сразу, упрощая поиск элементов, которые недоступны скринридерам. Обновлённое дерево также позволит реализовать новые функции и инструменты для решения проблем доступности.

Новое дерево доступности пока доступно только в Chrome Canary.

#debug #a11y #internals #devtools

https://developer.chrome.com/blog/full-accessibility-tree/