Разделы портала

Онлайн-тренинги

.
Создание максимально недоступного сайта с отличным рейтингом Lighthouse
07.02.2024 00:00

Автор: Мануэль Матузович (Manuel Matuzović)
Оригинал статьи
Перевод: Ольга Алифанова

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

Встроенный в Google инструмент тестирования Lighthouse оценивает доступность наших сайтов по шкале от 0 до 100. Похвально иметь высокий рейтинг, однако то, что вы набрали 100, не значит, что у сайта прекрасная доступность. Чтобы это доказать, я провел небольшой эксперимент.

Всегда приятно видеть посты с высоким Lighthouse-рейтингом в социальных сетях, демонстрирующие, как здорово люди оптимизировали свой или клиентский сайт. Сразу видно, что их волнует качество того, что они сделали.

Lighthouse присваивает рейтинг 100 в зеленом кружке, если мы провели отличную работу. Это можно гордо демонстрировать клиентам или в Твиттере.

Замерять качество кода важно, но еще важнее правильно интерпретировать рейтинги, присвоенные нам автоматизированными инструментами. Если Lighthouse сообщает, что наш сайт доступен на 100%, это не значит, что это правда так. Это лишь означает, что мы заложили базу для ручного тестирования. Lightouse использует библиотеку тестирования доступности axe-core со специальным набором правил для своих тестов. Он выявляет ряд плохих практик, но этот ряд не исчерпывающий. Другие практики могут быть по сути неплохими, но вредить при неправильном применении.

Нельзя проверить качество, используя только автоматизированное тестирование. Чтобы это доказать, я создал максимально недоступный сайт с отличным рейтингом Lighthouse.

Предыстория

Зак Лезерман недавно опубликовал в Твиттере пост:

«Идея для поста в блог: Как создать максимально медленный сайт с отличным рейтингом Lighthouse».

А вот ответ Вадима Макеева, вдохновивший меня на эту статью:

«Интересно будет это почитать! Вот вариант для аудита a11y: `<img src=picture.png alt=picture.png>`»

Я подумал, что отличной идеей будет не только заморочить голову максимальному количеству народа, но и параллельно добиться прекрасного Lighthouse-рейтинга.

Оставим за бортом максимум народа

Возьмем эту простую, доступную страничку за основу.


CodePen: “100%” доступность - шаг 0

Только CSS

Начнем с простого. Я хочу убедиться в наличии CSS-зависимости в моем прекрасном сайте. Для этого я добавляю атрибут hidden в элемент body. Hidden – это HTML-эквивалент display: none; в CSS.

HTML

<body hidden>
 ...
 </body>



(теперь ничего не отображается)

Hidden визуально скрывает содержание и удаляет его из дерева доступности. Этого уже достаточно, чтобы исключить всех и пройти тесты Lighthouse, но это было бы слишком просто. Я хочу создать сайт, который полностью недоступен, но технически отображает содержание. Поэтому добавим еще CSS и вернем содержание назад.

HTML

<head>
 <link rel="stylesheet" href="/style.css" />
 </head>
 <body hidden>
 ...
 </body>

CSS

.loaded {
 display: block;
 }

Мы вернулись в исходную точку, но теперь CSS должен загрузиться, если пользователи хотят получить доступ к содержанию сайта.

CodePen: “100%” доступность - шаг 1

Только JS

Добавим еще одну зависимость. Я больше не применяю класс, отображающий содержимое в HTML- я добавляю его через JS.

HTML

<head>
 <link rel="stylesheet" href="/style.css" />
 <script src="/script.js"></script>
 </head>
 <body hidden>
 ...
 </body>

JS

document.querySelector('body').classList.add('loaded');

Отлично! Сайт выглядит точно так же, но чтобы хоть что-то показать, CSS и JS-файлы должны загрузиться и верно отработать.

Great! The site still looks the same but in order for it to display anything at all the CSS and JS file must load and work properly.

CodePen: “100%” доступность - шаг 2

Настало время для первого Lighthouse-теста. Скрестим пальцы!

 

Отличный рейтинг для сайта, где только CSS и JS. Супер, но мы можем лучше.

Пользователи экранного чтеца

Оставить за бортом пользователей экранного чтеца можно массой способов. Простейший и наиболее эффективный – это использовать атрибут и значение aria-hidden="true". Это мощный атрибут, применять его надо осторожно – он удаляет элементы из дерева доступности. В норме его надо использовать только для помощи пользователям вспомогательных технологий, удаляя повторяющееся или излишнее содержание. На нашем сайте мы поместим его в элемент body.

HTML

<body hidden aria-hidden="true">
 ...
 </body>

Теперь пользователи экранного чтеца испытают то «редкое» чувство работы с недоступным сайтом.

Исходно Lighthouse не помечал это, как проблему, но вроде бы это исправлено. Отлично! К сожалению (и счастью для этой статьи), это можно обойти, установив tabindex на -1 на всех доступных для фокусировки элементах.

<a href="https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/" rel="noopener" tabindex="-1">  
 Read the article  
 </a>
 <form action="#form">  
 <p>  
 <label for="text">Dummy form</label><br>  
 <input id="text" tabindex="-1">  
 </p>  
 <button tabindex="-1">Send</button>  
 </form>

CodePen: “100%” доступность - шаг 3

Пользователи клавиатуры

Пользователи клавиатуры могут переходить по странице, нажимая клавишу Tab и прыгая с ее помощью от одного элемента к другому. Браузеры показывают рамку вокруг этих элементов, когда они в фокусе.

 

Избавимся от этого.

CSS

*:focus {
 outline: none !important;
 }

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

JS

document.addEventListener('keydown', function (e) {
 e.preventDefault();
 });

Наше исключающее всех приложение теперь убирает функциональность всех клавиш по умолчанию.

CodePen: “100%” доступность - шаг 4

Время для еще одного теста.


Все еще все отлично.
Что ж, настало время для грязной игры.

Режим высокой контрастности

Слабовидящие люди могут улучшить контрастность Windows, включив так называемый «Режим высокой контрастности».


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

Мы можем прицелиться конкретно в этих пользователей, использовав специальную возможность media.

CSS

@media screen and (-ms-high-contrast: active) {
 /* High contrast styling rules */
 * {
 color: #000000;
 }
 }

Правила в этом media-запросе применяются только при включенном режиме высокого контраста. К сожалению, мы не знаем, какие цвета используются темой – мы даже не знаем, светлая она или темная. Установка цвета на #000000 у всех элементов может как сработать, так и нет – зависит от пользовательских настроек. Этот 50% шанс недостаточно хорош для меня, но нам повезло: цвета режима высокой контрастности Windows соответствуют ключевым словам системных цветов CSS. Мы можем использовать эти ключевые слова, чтобы убедиться, что наш текст всегда соответствует цвету фона режима высокой контрастности – неважно, какой цвет там используется. Цвет фона соответствует окну. Поэтому воспользуемся значением цвета фона для цвета текста всех элементов.

CSS

@media screen and (-ms-high-contrast: active) {
 * {
 color: window !important;
 }
 }

 

О, я чувствую себя злобным властелином. Мои LinkedIn-сообщения будут переполнены предложениями о работе от компаний вроде Facebook или Uber.

CodePen: “100%” accessible - step 5

Пользователи мыши

Выкинуть за борт пользователей мыши очень легко – убираем курсор.

CSS

*,
 *:hover {
 cursor: none;
 }

cursor: none; для пользователей мыши – это то же, что и outline: none; для пользователей клавиатуры. Оправиться от шока поначалу нелегко, но интерактивные элементы все еще кликабельны. Улучшим качество нашего приложения, испортив пользовательский опыт еще больше.

CSS

body {
 pointer-events: none;
 }

pointer-events: none; освобождает пользователя от возможности кликнуть на что бы то ни было на нашем сайте. Это свойство хорошо поддерживается, но дабы убедиться, что оно работает в максимальном количестве браузеров, можно применить принцип, который называется пассивной деградацией.

JS

function removeA11y() {
 if ('pointerEvents' in document.body.style) {
 console.log('pointer-events supported');
 return;
 }
 document.addEventListener('click', function (e) {
 e.preventDefault();
 });
 }
 removeA11y();

Этот резервный JavaScript-сценарий включится в игру и уберет все возможности для клика со всех элементов, если браузер плохо поддерживает pointer-events.

CodePen: “100%” доступность - шаг 6


Отлично! Все еще супер-доступно!

Читабельность

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

CSS

body {
 opacity: 0.03;
 }

Содержимое страницы все еще на месте, но почти невидимо. И замечательно!

Lighthouse исходно не помечал это, как проблему, но вроде бы это исправили. Отлично! К сожалению (и к счастью для этой статьи), это можно обойти, используя свойство filter.

body {
 filter: opacity(0.03);
 }

CodePen: “100%” доступность - шаг 7

Режим чтения

Тестируя сайт в разных браузерах, я заметил, что он все еще доступен в Safari в режиме чтения.


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

CSS

body {
 opacity: 0.03;
 font-size: 1px;
 }

CodePen: “100%” доступность - шаг 8

Просмотр исходного кода

Сайт недоступен для людей с плохим и хорошим зрением, а также пользователям мыши, клавиатуры и экранного чтеца. Если опытные пользователи браузера сталкиваются с таким сайтом, в них просыпается Дэвид «Zero Cool» Мерфи, и они пытаются взломать этот сайт. Под взломом я имею в виду просмотр исходного кода страницы.

Добавлю вишенку на торт моего плюющего на пользователей сайта – я конвертирую текст в html-сущности. Сущности обычно используются для отображения зарезервированных символов, невидимых символов, и трудных для печати на стандартной клавиатуре символов. Я использую их, чтобы сделать текст сайта непонятным.


CodePen: “100%” доступность - шаг 9

И, наконец, финальный тест.

 

Заключение

Моей целью не было опорочить Lighthouse или axe-core, движок Lighthouse. Я использую оба инструмента и рад, что они существуют.

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


«Эти проверки сообщают о возможностях для улучшения доступности вашего веб-приложения. Лишь часть проблем доступности можно найти автоматическим образом, поэтому ручное тестирование приветствуется».

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

 

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

Обсудить в форуме