Неінклюзивний веб або чому я проти сучасних тенденцій
Інтернет розвивається швидко. Нові фреймворки, нові підходи, нові тренди. Але в дечому ми занадто «просунулись» — і втратили щось важливе.
Семантика? Мало кому цікава. Доступність? «Потім зробимо». Перформанс? Ну, в Chrome на Full HD працює — і добре.
Ця стаття — про моє невдоволення станом справ у фронтенді. Про костилі, які стали нормою. Про доступність, яку ігнорують. І про те, чому «просто і стабільно» — це не соромно.
Чому ми відійшли від простого
Вимоги до дизайну змінились кардинально. В тренді — розумний мінімалізм, «ненав’язливі» ефекти, море нестандартних анімацій. І цей тренд скрізь: від лендингів до SPA.
Уявімо ситуацію. В команду приходить джун, якого в аутсорсі продають за мідла. Поруч — молодий дизайнер, який горить бажанням намалювати щось «естетично-каверзне», нетипове, що «зачепить».
І починається холівар на тему «як впихнути невпихуєме».
Джун дивиться на макет, чеше голову, розуміє, що щось не так. Google не допомагає, запитати нікого, а сперечатись з дизайнером — якось ніяково.
Так народжується його величність костиль. Дів на діві, тисячі рядків дивного JavaScript, і воно наче працює. В Chrome. На Full HD. Майже без лагів.
Показали замовнику — чудово! Баги пофіксимо потім.
Баги фіксяться, код розростається, команда змінюється п’ять разів, все рефакториться, стає «красиво»… але є одне «але».
Доступність. Її немає.
Ми не думаємо про доступність
Бізнес жорстокий, особливо коли дедлайни тиснуть. Коли немає явних вимог до якості, а мета — просто «готовий продукт» — ми не думаємо про такий «пустяк».
А дарма.
Чому це важливо
Аудиторія. За різними оцінками, 15–20% людей мають ті чи інші обмеження: зір, слух, моторика. Ігноруючи доступність, ви відрізаєте частину користувачів.
Закон. В США, ЄС, Канаді є законодавство про доступність вебу. Amazon, Domino’s Pizza, Beyoncé — всі отримували позови за недоступні сайти. В Україні поки тихо, але тренд очевидний.
SEO. Семантичний HTML краще індексується. Скрінрідери і пошукові боти читають сторінку схоже.
Якість коду. Доступний код — зазвичай чистіший код. Правильна семантика = менше костилів.
Мінімум, який варто робити
Семантичні теги: <header>, <nav>, <main>, <article>, <aside>, <footer> замість безкінечних <div>.
Alt для картинок: не «image1.jpg», а опис того, що на зображенні.
Контраст тексту: світло-сірий текст на білому — це не мінімалізм, це нечитабельність.
Фокус: не прибирайте outline без заміни. Користувачі клавіатури існують.
Форми: <label> прив’язаний до <input>. Не placeholder замість label.
Навіщо вигадувати велосипеди
Практична частина. Ми постійно займаємось зайвою роботою, ламаючи те, що вже працює.
Кастомний select
Класика жанру. Рідний <select> «некрасивий», тому пишемо компонент на 500 рядків JS.
Що втрачаємо: нативна поведінка на мобільних, підтримка клавіатури, скрінрідери, автозаповнення браузера.
Що отримуємо: баги, проблеми з фокусом, додаткове навантаження.
Питання: чи справді бізнесу важливіше «красивий» select, ніж відтестована логіка і перформанс?
Кастомний скролл
Ще одне знущання над UX. Кастомні скролбари додають проблеми: несподівана поведінка, конфлікти з тачпадами, проблеми на мобільних.
Якщо дуже треба стилізувати — є scrollbar-width і ::-webkit-scrollbar. Не ідеально, але краще за JS-бібліотеку.
Кастомні чекбокси і радіо
Можна стилізувати нативні через appearance: none + псевдоелементи. Не треба ховати <input> і малювати <div>.
css
input[type="checkbox"] {
appearance: none;
width: 20px;
height: 20px;
border: 2px solid #333;
border-radius: 4px;
}
input[type="checkbox"]:checked {
background: #333;
}Працює, доступне, без JS.
Модалки без <dialog>
HTML має нативний <dialog> з методами .showModal() і .close(). Він вже вміє: блокувати фокус всередині, закриватись на Escape, затемнювати фон через ::backdrop.
Навіщо писати це з нуля?
Здоровий research
Ще одна проблема — відсутність планування.
Як і в медицині, без якісної діагностики результат може не виправдати себе, а то й зашкодити.
Перед тим як писати код
Чи існує нативне рішення? HTML і CSS вміють багато. <details>, <dialog>, <datalist>, :has(), @container — можливо, вам не потрібна бібліотека.
Чи це справді потрібно? Анімація заради анімації? Кастомізація заради кастомізації? Іноді «скучний» варіант — правильний.
Як це вплине на перформанс? Lighthouse, WebPageTest, DevTools Performance — інструменти є, треба ними користуватись.
Як це працюватиме без JS? Progressive enhancement ніхто не відміняв.
Отже
Можливо, я надто скептично ставлюсь до трендів. Можливо, просто люблю простоту.
Але коли бачу сайт на 5 МБ JavaScript, де кнопка «Купити» — це <div onclick> без можливості натиснути з клавіатури, де select перемальований до невпізнання і глючить на мобільних, де контраст тексту — 2:1 замість мінімальних 4.5:1…
Я думаю: ми знову в ері Flash. Тільки тепер це React і «авторське бачення».
Семантика, доступність, перформанс — це не «пустяки на потім». Це база. І якщо ми називаємо себе розробниками, а не «збирачами костилів», варто про це пам’ятати.
герантофил