Тёмная тема не для всех: о чём молчит веб-разработка, когда речь заходит об этике и доступности

от автора

Когда мы говорим об интерфейсах, слишком часто упор идёт на скорость, удобство и эстетику. А что насчёт того, чтобы быть понятным, полезным и доступным для всех? Эта статья — попытка по-человечески и технически осмыслить роль этики в разработке веб-интерфейсов. С примерами, с кодом, с шероховатостями.


Когда последний раз вы думали не о красивой анимации, а о том, как слепой пользователь услышит ваш сайт? Или как человек с дислексией воспримет ваш лэндинг с витиеватым шрифтом на кислотном фоне?

Обычно такие мысли приходят либо под конец проекта, либо вообще после релиза — если приходят. И это не потому, что разработчики плохие. Просто в чеклистах QA нечасто значится «дружелюбие к невидимому пользователю». А зря.

Этика в веб-разработке — это не про «быть хорошим». Это про быть профессионалом, который делает продукт для людей. Для всех людей. А не только для тех, у кого 100% зрение, стабильный интернет и MacBook Pro с ретиной.

Погнали разбираться.


Этическая слепота: почему мы не замечаем очевидное

Слепой пользователь не увидит, где кнопка. Пользователь с тремором не сможет навестись мышкой на маленький чекбокс. А человек с цветовой слепотой не отличит кнопку «ОК» от «Отмена», если вы покрасили их в зелёный и красный.

Один из самых ярких кейсов:

Форма обратной связи без label’ов. Только placeholder внутри input’ов. Выглядит чисто, но попробуйте пройти её с VoiceOver или NVDA. Screen reader просто промолчит. Пользователь вслепую тыкает в поле, а интерфейс молчит. Магия UX превращается в адскую головоломку.


Семь заповедей доступного интерфейса

1. Семантическая разметка — это не для красоты

<!-- Плохо --> <div onclick="submitForm()">Отправить</div>  <!-- Хорошо --> <button type="submit">Отправить</button>

Потому что <div> не знает, что он кнопка. А <button> знает. И скринридеры тоже знают.

2. Альтернативный текст — не надо «alt=»image»»

<!-- Плохо --> <img src="chart.png" alt="chart">  <!-- Лучше --> <img src="chart.png" alt="График роста трафика за февраль 2025 года">

Если картинка несёт смысл — передайте его. Если декоративная — просто alt="".

3. Контраст и шрифты — не только для эстетов

Слишком светло, слишком сливается, слишком модно. WCAG рекомендует контраст минимум 4.5:1 для обычного текста и 3:1 для крупного.

Инструмент: WebAIM Contrast Checker

4. Клавиатурная навигация — must have

<!-- Добавьте tabindex --> <a href="#" tabindex="0">Подробнее</a>

Проверьте, можно ли пройти весь сайт только с клавиатурой. Tab, Shift+Tab, Enter — ваша проверка на человечность.

5. ARIA — но с умом

<!-- Пример --> <div role="dialog" aria-labelledby="dialog-title" aria-describedby="dialog-desc">   <h2 id="dialog-title">Подтверждение удаления</h2>   <p id="dialog-desc">Вы точно хотите удалить файл?</p> </div>

ARIA помогает, но не заменяет семантику. Лучше <button> без ARIA, чем <div> с кучей role.

6. Управляемый фокус

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

const dialog = document.querySelector('#myDialog'); const openBtn = document.querySelector('#openDialog');  openBtn.addEventListener('click', () => {   dialog.showModal();   dialog.querySelector('button').focus(); });  dialog.addEventListener('close', () => {   openBtn.focus(); });

7. Анимации: красиво, но не всем

Пользователи с вестибулярными нарушениями могут чувствовать дискомфорт от резких переходов. Уважайте prefers-reduced-motion:

@media (prefers-reduced-motion: reduce) {   * {     animation: none !important;     transition: none !important;   } }

Практика: как это выглядит в реальном проекте

На одном из проектов заказчик хотел «минимализм» — без подписей к формам, тонкие шрифты, модалки без закрытия с клавиатуры. Команда пошла по пути компромиссов: визуально всё осталось почти как было, но под капотом — full accessibility.

  • Скрытые label’ы через sr-only

  • Фокус-трапы внутри модальных окон

  • Контраст подобран с учётом WCAG

  • Кастомные чекбоксы с полноценной навигацией

И знаете, что? После запуска мы получили благодарственное письмо от пользователя с нарушением зрения. Это было лучше, чем любое A/B тестирование.


Заключение

Доступность — это не благотворительность. Это не про «инклюзию ради инклюзии». Это просто правильная разработка. Если интерфейс хорош для всех — он хорош по-настоящему.

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

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


ссылка на оригинал статьи https://habr.com/ru/articles/895478/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *