Как определить местонахождение без GPS

Если вы находитесь в Москве, то наверняка большую часть времени ваш телефон думает, что вы где-то в Химках. В других регионах наверняка есть свои «точки притяжения». Все уже знают, что это происходит из-за того, что в целях безопасности глушат GPS. Но Яндекс, Самокат, маркетплейсы вроде Ozon/WB и другие приложения всё равно умудряются довольно неплохо понимать, где вы находитесь. Как? С помощью использования LBS (Location-based services), о методах работы которых я расскажу в этом посте.
Недавно на E-code был доклад на эту тему. Изначально я хотела просто отправить вам ссылку на его запись, но ее все еще нет (или просто я не нашла). Там, конечно, копали гораздо глубже, а я попробую объяснить базу простыми словами.

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

Приложение обычно не спрашивает GPS напрямую. Оно обращается к Location API телефона и получает что-то вроде:

latitude: 55.7512
longitude: 37.6184
accuracy: 35 m
timestamp: ...

Кстати, технически правильнее говорить GNSS. GPS — только американская спутниковая система. Есть ещё ГЛОНАСС, Galileo, BeiDou. Телефон может использовать несколько систем одновременно.

Именно эти данные у нас искажаются, и тогда сервисы отталкиваются от других источников.

Wi-Fi
Телефон видит точки Wi-Fi вокруг, даже если ни к одному не подключён. У каждой из них есть SSID и BSSID:

SSID: CoffeeShop_WiFi (название точки доступа, может повторятся в разных местах)
BSSID: 44:27:f3:7e:59:02 (идентификатор конкретной точки)

Телефон видит примерно такую картину:

BSSID A -65 dBm
BSSID B -73 dBm
BSSID C -81 dBm

dBm это единица мощности сигнала. Если сервис знает, где находятся A, B и C, можно довольно неплохо оценить координаты телефона. Координаты A,B и C сервисы берут обычно из предыдущих наблюдений. В какой-то момент другой телефон одновременно видел эти Wi-Fi и имел хорошую позицию по спутникам:

55.7512, 37.6184 + Wi-Fi A, B, C

Много таких наблюдений постепенно формируют базу:

набор BSSID: примерная область на карте

И потом схема работает в обратную сторону: спутников нет, зато телефон видит знакомое окружение Wi-Fi → можно оценить, где он находится.

У Яндекса, например, есть публичный Локатор API, который умеет определять положение по Wi-Fi, сотовой сети и IP.

Сотовая сеть
С вышками похожая история. Телефон знает, к какой соте подключён. У сети есть идентификаторы вроде MCC, MNC, LAC и Cell ID.

Если совсем просто:
MCC - страна
MNC - оператор
Cell ID - конкретная сота

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

Если ничего этого не помогло - IP

Backend видит публичный IP пользователя и может прогнать его через GeoIP-базу.

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

С VPN всё ещё веселее: физически ты в Москве, а по IP внезапно в Амстердаме.

Просто для галочки упомяну также BLE-маяки (Bluetooth Low Energy), их используют для навигации по большим помещениям (аэропорты, тц и тд). Телефон видит их и по идентификаторам и силе сигнала понимает, где примерно находится, но применение тут все таки достаточно узкое.

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

#ks_разработка

Не тащите мусор из фигмы в прод

Небольшая фронтендерская привычка, которую почему-то до сих пор часто пропускают — оптимизировать SVG перед тем, как класть их в проект.

Я для этого обычно использую SVGOMG.

Если открыть SVG, который только что экспортировали из Figma, внутри нередко можно найти кучу вещей, которые приложению вообще не нужны: лишние группы, id, defs, слишком длинные значения координат, ненужные атрибуты. Иногда сама иконка визуально элементарная, а SVG при этом выглядит так, будто там половина дизайн-системы.

SVGOMG всё это довольно хорошо чистит. Закинул файл, посмотрел, что получилось, скачал оптимизированный вариант. Пара минут.

Особенно я обращаю на это внимание в React-проектах, где SVG используются как компоненты. В таком случае весь этот мусор — уже буквально часть нашего кода.

При этом я бы не советовала бездумно выкручивать все настройки оптимизации на максимум. На сложных SVG можно случайно сломать маски, градиенты или clipPath. Проверьте, остался ли нормальный viewBox и fill/stroke, особенно если иконка должна наследовать currentColor.

На проекте с десятками и сотнями иконок я бы вообще не оставляла это на ручном уровне — там уже логичнее настроить SVGO и автоматически прогонять SVG.

#ks_фронтенд #ks_бесит

Вчера вышел Next 16.4

Команда Next.js теперь официально рекомендует Cache Components для всех Next.js-приложений. В новых проектах через create-next-app они уже включены по умолчанию, а в Next.js 17 эта модель вообще станет дефолтной.

Если кто следил за App Router с самого начала, тот знает, что отношения Next.js с кешированием были, мягко говоря, непростыми: что кешируется автоматически, что не кешируется, почему страница вдруг стала статической или динамической 🤪

С Cache Components идея становится более явной: нужную часть приложения можно пометить 'use cache' и самому определить, что имеет смысл кешировать.

При этом на одной странице можно смешивать закешированный UI и данные с тем, что должно рендериться непосредственно во время запроса.

В 16.4 также добавили ensureStatic - маркер, помечающий что страница должна оставаться статической.
Если его поставить на страничку, а кто-нибудь потом добавит туда динамический контент, Next.js не молча поменяет поведение, а завалит build. Особенно актуально для больших проектов, где производительность страницы иначе начинает зависеть от того, помнит ли каждый разработчик все нюансы её рендеринга.

Ещё стало интереснее с prefetch: допустим, у нас страница сообщения с большим тредом. Можно заранее префетчить основную часть страницы, а загрузку самого треда через новый navigation() отложить до момента, когда пользователь действительно перейдёт по ссылке. То есть не выбирать между «загрузить заранее вообще всё» и «ничего не загружать», а контролировать, какая именно часть страницы нужна на каждом этапе навигации.

Из менее заметного, но приятного: disk cache Turbopack стал занимать на 20–25% меньше места, server HMR делает меньше ненужной работы, production bundles стали компактнее.

Плюс Next.js 16.4 приехал с React 19.3 — со стабильными View Transitions и Fragment Refs.

Для тех, кому не хватило ИИ в новости: появился upgrade flow для агентов. Next.js может подготовить инструкции по миграции, нужные codemods и проверки, а агент — провести проект через обновление. Есть даже экспериментальный agent feedback: агент может собрать проблемы, с которыми столкнулся при работе с Next.js, подготовить отчёт, а разработчик уже решает, отправлять его команде или нет.

Подробнее об этом тут: https://nextjs.org/blog/next-16-4

#ks_фронтенд #ks_новости

Отзыв на книгу «Нахуй безопасность. Как игнорить этот бред и зарелизить проект»

Спойлер: мне понравилось, всем советую!

Отлично подойдёт тем, кто только поверхностно знаком с терминологией безопасников и хочет немного погрузиться в эту тему без скучных лекций и заумных объяснений. Автор в ироничном тоне проведёт вас сквозь дебри терминов, познакомит с типичными проблемами разработки и покажет, что бывает, когда безопасность приносится в жертву быстрому релизу.

Книга написана в духе «Вредных советов»: автор с совершенно серьёзным видом предлагает делать всё то, за что в нормальной компании можно получить по шапке от безопасников. И именно в этом её прелесть.

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

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

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

Рекомендую, особенно тем, кто хоть раз слышал фразу «да пох, и так сойдет!».

#ks_подгон

Кто такие эти ваши CTO и CISO?

Ввожу новую рубрику: расшифровка загадочных IT-аббревиатур 👩🏻‍💻

Если спросить разработчика, кем он хочет стать в будущем, скорее всего, услышишь что-то вроде: CTO, архитектором или тимлидом.

Но давайте честно: часто в нашей голове границы между всеми этими ролями довольно размыты. А когда в разговоре появляются CIO, CISO, CPO и прочие три буквы, становится ещё веселее.

Поэтому ловите небольшую шпаргалку по IT-должностям 👇

👩🏻‍💻 Технические и управленческие роли:

• Tech Lead — технический лидер команды, отвечает за технические решения и качество кода.

• Team Lead — руководитель команды, отвечает за людей, процессы и результаты.

• Software Architect — архитектор, проектирует структуру и взаимодействие систем.

C-level — высшее руководство:

• CTO (Chief Technology Officer) — технический директор. Отвечает за технологическую стратегию компании.

• CIO (Chief Information Officer) — директор по IT. Отвечает за внутренние IT-системы и инфраструктуру.

• CISO (Chief Information Security Officer) — директор по информационной безопасности. Защищает компанию от киберугроз.

• CSO (Chief Security Officer) — директор по безопасности. Ответственный за весь спектр безопасности в компании, включая техническую, экономическую и информационную.

• CPO (Chief Product Officer) — директор по продукту. Решает, что и зачем мы разрабатываем.

• CDO (Chief Data Officer) — директор по данным. Отвечает за стратегию работы с данными.

• CAIO (Chief AI Officer) — директор по искусственному интеллекту. Отвечает за AI-стратегию и внедрение AI.

• CEO (Chief Executive Officer) — генеральный директор. Отвечает за компанию в целом.

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

А кем бы вы хотели стать (когда вырастите)? 😁

#ks_буковки

Должен ли CISO иметь блокирующий голос в ИИ-проектах?

Интересная дискуссия была недавно на технодне от Selectel. Из-за ИИ всё очень быстро меняется, и безопасники могут не успевать проверять проекты и разрабатывать новые средства защиты. Что же тогда делать?

Если дать CISO право вето на любой ИИ-проект, можно сильно затормозить разработку. Но и запускать ИИ без контроля безопасности — сомнительная идея.

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

Одно дело — внутренний помощник для генерации тестовых данных. Другое — ИИ-агент с доступом к клиентской базе и возможностью самостоятельно вызывать API.

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

При этом важно подключать ИБ не за неделю до релиза, когда всё уже готово, а ещё на этапе проектирования. Иначе безопасники превращаются в людей, которые постоянно говорят «нет», а разработчики начинают искать способы их обойти.

Я скорее за то, чтобы у CISO было право вето, но только для проектов с существенными рисками, а не для каждого эксперимента с LLM.

А вы как считаете? CISO должен иметь последнее слово или решение о запуске всё-таки должно оставаться за бизнесом?

#ks_ии #ks_без

Я вчера рассказала про RSS, а сегодня хочу поделиться с вами моим каналом, в котором появляются все самые свежие новости прямиком из RSS-рассылки v8, react, next и других важных для фронтендеров источников: https://t.me/frontend_hot_radar

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

А еще скоро поделюсь с вами статьей о том, как я его делала - с помощью make и openai)

#ks_разработка #ks_фронтенд

Ребят, кто ещё не видел — 19 ноября будет конфа Импульс от Т1

Рекламить не буду, но если кто-то тоже собирается — пишите, можно будет пересечься)

#ks_события

Не заставляйте пользователя скроллить дважды

Открываешь каталог, пролистываешь несколько десятков товаров, переходишь в карточку, смотришь характеристики, нажимаешь «Назад» и оказываешься в начале списка. Теперь нужно снова искать место, на котором остановилась. Хотя, камон, браузер вообще-то умеет запоминать позицию прокрутки 🙄

В SPA мы часто ломаем это поведение сами. Например, при возвращении список заново загружает данные, браузер пытается восстановить скролл, но нужной высоты страницы ещё нет. Когда карточки появляются, пользователь так и остаётся наверху. Или в приложении есть глобальный ScrollToTop, который вызывает window.scrollTo(0, 0) при каждом изменении маршрута, включая возвращение назад.

У браузера для этого есть history.scrollRestoration, который по умолчанию обычно работает в режиме auto. В React Router есть компонент <ScrollRestoration />. Но даже с ним могут возникать проблемы, если контент загружается асинхронно или используется виртуализация.

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

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

#ks_бесит #ks_фронтенд

Фингерпринт: Как сайты узнают вас даже без cookies

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

Похожий принцип используется и в браузерах. Только здесь собирают характеристики устройства и браузерного окружения, чтобы попытаться отличить одного посетителя от другого. Этот метод называется browser fingerprinting.

Когда вы открываете сайт, js может получить довольно много информации: разрешение экрана, язык, часовой пояс, количество логических ядер процессора, некоторые сведения о памяти, поддержку браузерных API и особенности графического рендеринга. Часть параметров доступна напрямую, другие приходится определять косвенно. Например, браузер не предоставляет обычному сайту полный список установленных шрифтов, но их наличие иногда можно определить по особенностям отображения текста.

Один из интересных методов — Canvas fingerprinting. Сайт рисует на скрытом HTML Canvas текст, фигуры или градиенты, а затем считывает получившиеся пиксели. На первый взгляд результат должен быть одинаковым у всех, ведь код отрисовки один. Но на итоговую картинку влияют ОС, браузер, шрифты, видеокарта, драйверы и алгоритмы сглаживания. Даже небольшие различия могут стать дополнительным признаком устройства.

Похожим образом используют WebGL и AudioContext. В первом случае анализируют особенности графического рендеринга, во втором — результаты обработки звука. Собранные характеристики объединяют в отпечаток, который можно использовать для сопоставления посещений. Иногда данные хешируют, но сам по себе хеш не делает такое отслеживание анонимным.

Зачем сайтам всё это? Есть вполне обоснованные сценарии: антифрод, обнаружение ботов, подозрительных входов и массовых регистраций. Но те же методы можно использовать для отслеживания посетителей без cookies, в том числе между разными сайтами, если у них есть общий механизм сбора и сопоставления данных.

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

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

И кстати, инкогнито вас не спасет) Приватный режим обычно удаляет историю и данные сессии после закрытия приватных окон, но не делает браузер неузнаваемым для сайтов. Доступные js характеристики устройства никуда автоматически не исчезают.

#ks_разработка #ks_без

Подделка фингерпринта: знакомимся с термином «спуфинг»

Вчера я рассказала про то, из чего может состоять фингерпринт, используемый для антифрод-систем. Это достаточно эффективный механизм, однако и с ним злоумышленники научились бороться. Спуфинг (spoofing) - это общий термин, означающий способ обмана, при котором злоумышленник подделывает данные, чтобы выдать себя за другого человека, устройство или организацию.

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

async function collectFingerprint() {
const ua = navigator.userAgentData;
return { 
  userAgent: navigator.userAgent,
  language: navigator.language,
  platform: navigator.platform,
  timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
  screen: `${screen.width}`x`${screen.height}`,
  cores: navigator.hardwareConcurrency,
  memory: navigator.deviceMemory ?? null,
  webdriver: navigator.webdriver,
  clientHints: ua ? await ua.getHighEntropyValues([ "architecture", "platformVersion", "fullVersionList", "model" ]) : null }; 
}
collectFingerprint().then(console.log);

Эти данные отправляются на бекенд и анализируются::
- может оказаться, что HTTP User-Agent заявляет одну платформу, а Client Hints - другую
- у одной сессии резко изменилось несколько характеристик окружения
- множество регистраций имеют одинаковые признаки автоматизации и необычно высокую частоту запросов
- браузерные сигналы противоречат другим наблюдениям сервера

На основе анализа рассчитывается Risk Score - оценка риска для конкретной ситуации. И, уже в зависимости от нее, возможны разные сценарии:
Низкий риск - пропускаем пользователя, но можем продолжать мониторинг
Средний риск - запрашиваем дополнительную проверку, например капчу или подтверждение по email
Высокий риск - временно ограничиваем действие (регистрацию, авторизацию, платёж и тд)
Критический риск - блокируем опасное действие и передаём событие на дополнительную проверку

#ks_без

Как сообщить команде решение, с которым ты сама не согласна?

Есть особый вид тимлидского развлечения: тебе приносят решение сверху, ты с ним споришь, приводишь аргументы, предлагаешь альтернативы, но решение всё равно принимают не в твою пользу. Причем хорошо, если дали поспорить — иногда и этого не дают, просто ставят перед фактом.

А теперь иди и расскажи об этом команде 🙃

И тут есть два соблазна.

Первый — включить корпоративного дипломата и сделать вид, что ты с самого начала считала идею прекрасной.

Второй — честно сказать: «Ну, я тоже считаю, что это полный треш, но нам сказали делать».

Оба варианта так себе (и то и то пробовала на практике): в первом случае команда чувствует фальшь, а во втором ты вроде как на стороне ребят, но по факту снимаешь с себя ответственность и оставляешь их один на один с решением, которое им предстоит выполнять.

Поэтому переходим к третьему варианту.

Что важно объяснить команде:

• Что именно решили и почему. Не «так захотел бизнес», а какой результат нужен, какие ограничения есть и какие компромиссы пришлось принять.
• Что удалось обсудить до принятия решения. Если была возможность повлиять на выбор — расскажи, какие аргументы приводили и почему выбрали другой путь. Если решение просто спустили сверху — не делай вид, что команда участвовала в обсуждении. Лучше честно обозначить, какие вопросы ещё можно поднять.
• На что мы можем влиять. Решение может быть уже принято, но способ реализации, сроки, технические компромиссы и меры снижения рисков часто ещё можно обсуждать.
• Что будет, если наши опасения подтвердятся. По каким признакам поймём, что что-то пошло не так? Когда вернёмся к обсуждению? Кто будет поднимать вопрос?

Я бы сказала примерно так:

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

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

А вам приходилось защищать перед командой решение, которое вы сами не поддерживали? Как выкручивались?

#ks_лидерство

SLI, SLO, SLA, или почему «доставим за 30 минут» — это три разных разговора

Вы открыли пиццерию. Пицца вкусная, курьеры быстрые, приложение работает. На сайте красуется обещание «доставим за 30 минут». Но как понять, насколько хорошо пиццерия с этим справляется?

SLI (Service Level Indicator) — показатель, которым измеряют качество сервиса. Например, доля заказов, доставленных не позднее чем через 30 минут после оформления. За прошлую неделю таких оказалось 94%. Это наш SLI. Никаких обещаний, просто измерили, как работает доставка.

SLO (Service Level Objective) — целевое значение показателя, которого команда хочет достичь. Пиццерия ставит цель: не менее 95% заказов должны приезжать за 30 минут. Теперь понятно, что результат в 94% за прошлую неделю до цели немного не дотянул.

SLA (Service Level Agreement) — соглашение с клиентом о том, какой уровень сервиса ему гарантируют и что произойдёт, если обязательство нарушат. Например, пиццерия обязуется доставлять не менее 90% заказов за 30 минут в течение месяца. Если условие не выполнено, клиентам положена компенсация согласно соглашению.

Получается, что SLI — это фактические 94% доставок вовремя, SLO — внутренняя цель в 95%, а SLA — обязательство перед клиентами обеспечить 90% с оговорёнными последствиями нарушения.

SLO обычно выше SLA, потому что обещать клиентам ровно тот результат, которого команда едва достигает, довольно рискованно. Лучше иметь запас. При этом SLA есть не у каждого сервиса, а SLO вполне может существовать без него.

У SLO есть ещё одно интересное понятие — error budget, или бюджет ошибок. Если цель — 95% доставок вовремя за месяц, то оставшиеся 5% можно потратить на опоздания, не нарушив внутреннюю цель. На тысячу заказов это 50 опозданий. После пятидесятого команда уже не укладывается в SLO, даже если остальные пиццы курьеры доставят телепортацией.

В IT всё то же самое, только вместо пиццы — доступность API, время ответа сервера или доля успешных запросов.

Хотя пицца, конечно, понятнее 🍕

#ks_буковки #ks_разработка

Попробуй пройти свой интерфейс без мышки

Есть довольно простой способ проверить, насколько удобно пользоваться вашим сайтом. Убери руку с мышки и попробуйте сделать что-нибудь полезное с помощью одной клавиатуры: открыть меню, найти нужный товар, положить его в корзину, заполнить форму и оформить заказ. Желательно без желания выбросить ноутбук в окно 🙃

Для навигации понадобятся в основном три клавиши: Tab — переход к следующему интерактивному элементу, Shift + Tab — к предыдущему, Enter или Space — активация кнопок и других элементов (в зависимости от их типа). Esc обычно помогает закрыть открытое меню или модальное окно. На словах всё довольно просто, а практике быстро выясняется, что:

- фокус у некоторых элементов вообще не виден. Ты нажимаешь Tab, но понятия не имеешь, где сейчас находишься;

- до красивой кастомной кнопки нельзя добраться с клавиатуры, потому что на самом деле это div с обработчиком onClick;

- модалка открылась, но фокус остался где-то на странице под ней. Или наоборот: окно закрылось, а фокус исчез в неизвестном направлении;

- выпадающее меню работает только при наведении мышкой. С клавиатуры оно как будто не существует.

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

Это не просто неудобства для тех, кто предпочитает клавиатуру. Для людей, которые не могут пользоваться мышью, такие ошибки могут сделать интерфейс недоступным.

У клавиатурной навигации есть вполне конкретные требования в WCAG: интерактивные элементы должны быть доступны с клавиатуры, фокус должен быть видимым, а пользователь не должен застревать внутри компонента без возможности выбраться. Подглядеть паттерны доступности компонентов можно в справочнике ARIA Authoring Practices Guide: https://www.w3.org/WAI/ARIA/apg/patterns/

Конечно, успешный проход с клавиатуры ещё не означает, что с доступностью всё хорошо; надо еще проверять скринридеры, подписи элементов, контрастность и другие аспекты. Но если ты не можешь оформить заказ, не прикоснувшись к мышке, это уже повод задуматься.

#ks_фронтенд

Всем привет, я с очередным анонсом, на этот раз для лидов 🔥

На VK JT TeamLead Meetup обсудят управление командой, развитие сотрудников и роль лида в бизнесе. Участие бесплатное, с обязательной регистрацией

📍 Москва — 24 октября, 15:30
📍 Петербург — 28 октября, 17:30

Программа и регистрация

#ks_события #ks_лидерство