Привет, Хабр!
Я часто вам рассказываю, как HTML и CSS помогают улучшить пользовательский опыт в наших веб-интерфейсах. Мне это наскучило. Сегодня я хочу поговорить с вами о практиках, которые заставляют пользователей очень сильно ругать разработчиков.
Мы рассмотрим примеры, когда только использование HTML и CSS может привести к замешательству людей. Многие же думают, что эти технологии безопасны и не могут принести вреда. Вот и проверим это.
Давайте посмотрим, что я вам подготовил.
Маскируйте обычный текст под ссылку
Многие пользователи любят ссылки за то, что их можно открыть в новой вкладе или окне. Зажал клавишу ctrl, кликнул по тексту ссылки, и она открылась в другой вкладке. Удобно!
Вот для разработчиков, которые хотят помучить пользователей, я нашёл отличный пример. Давайте посмотрим на текст «Ещё информация по запросу "Ламин Ямаль"».
Как думаете, мы смотрим на ссылку? Я думал, что да, но давайте попробуем вызвать контекстное меню на тексте.
Оно отличается от варианта, когда используется ссылка. Нет пунктов «Открыть в новой вкладке», «Открыть в новом окне», «Открыть в приватном окне» и других. Проще говоря, перед нами совсем не ссылка.
Давайте посмотрим, каким элементом размечен текст.
<body> <div class="AkyxZ VDgVie imso-loa" jscontroller="HoZvlf" role="link" tabindex="0" jsaction="x8IMsf"> <!-- здесь иконка --> Ещё информация по запросу "Ламин Ямаль" </div> </body>
Это элемент div. Получается, разработчики обманули нас. Визуально мы видим текст. Его цвет заставляет нас думать, что перед нами ссылка, а по факту в разметке находится обычный текст.
Если вам не нравится вариант с элементом div, то можно использовать элемент button. Его также нельзя открыть в отдельной вкладке, зажав клавишу ctrl.
Используйте иностранные слова для альтернативного текста у атрибута alt
Декоративные изображения тоже могут преподнести неприятные сюрпризы, если подойти к делу с изобретательностью. Лично у меня её не хватает, поэтому часто ищу примеры у коллег.
Давайте рассмотрим блок со статьёй.
Обращу ваше внимание, что после текста «Батраков не спас.», есть ссылка на комментарии. В ней используется смайлик «Огонёк». Давайте посмотрим, как размечен этот элемент.
<body> <a class="comment-count material-1117377750" href="https://www.sports.ru/football/blogs/3504260.html#comments"> <img class="comment-count__icon" src=" https://photobooth.cdn.sports.ru/preset/legacy/fire-yellow.svg " alt="fire"> <span class="link link_size_small link_color_blue comment-count__value">23</span> </a> </body>
В атрибуте указано слово «fire». У меня нет слов, чтобы описать моё восхищение. Это прекрасный трюк для ужасных интерфейсов!
Возможно, вы слышали, что интерфейсами пользуются пользователи с тотальной или частичной слепотой. Для этого они используют специальную программу, которая называется скринридер. Они анализируют разметку и проговаривают её, сообщая людям разную полезную информацию.
Подсказка «fire» будет мешать людям несколькими вариантами. Во-первых, она не информативна, потому что не понятна её связь со ссылкой. Во-вторых, она на английском языке. Таким образом, если пользователи не знают его, то не поймут подсказку совсем.
Заставляйте вводить цифровой код для авторизации с помощью маленьких клавиш цифровой клавиатуры
Авторизация с помощью цифрового кода является очень популярной функцией. Я даже не могу представить, сколько людей каждый день её используют. Вот где настоящая возможность навредить пользователю.
Недавно моя мама травмировала кисть руки. Пока происходит восстановление, ей сложно банально резать продукты. Если она это сделает, то кисть будет болеть весь день от напряжения. Вот так бывает после падения на руку.
Пятнадцатого числа каждого месяца она вносит платежи за коммунальные услуги. Для этого она использует веб-версию своего банка. В этом месяце она также хотела это сделать.
В здоровой руке держала телефон, а больной нажимала по экрану. Через какое-то время я увидел, что мама начинает злиться. Подошёл и предложил помощь. Она согласилась и отдала телефон.
Смотрю и вижу, что нужно ввести код из пуш-уведомления для авторизации.
Интерфейс отображает клавиатуру не для ввода цифр, а стандартную. У неё размер клавиш с цифрами маленький, и поэтому по ним нужно целиться.
Это не вызывает проблем у пользователя со здоровой рукой. Он по привычке не обратит внимание и заполнит поле. Но если кисть травмирована, клавиатура становится инструментом пытки.
Давайте посмотрим, как разработчики реализовали такое превосходное решение.
<body> <input type="text" class="c0i5_5_3-a7 tsHeadline700XLarge"> </body>
Всё просто. Разработчики используют элемент input вместе с атрибутом type и значением text. Именно оно говорит браузерам использовать стандартную цифровую клавиатуру на мобильных устройствах.
Отключайте отправку данных заполненных форм с помощью клавиши Enter
Готовя пример из предыдущего раздела, я случайно нашёл ещё один полезный совет для ужасных интерфейсов. Когда я ввёл номер телефона, по привычке нажал клавишу Enter, ожидая, что интерфейс отправит введённые данные.
Но, как вы видите, ничего не произошло. Я находился в том же поле ввода телефона. Подумав, что я не нажал клавишу Enter, конечно же, я нажал клавишу ещё раз. И ещё раз.
В общем, форма не отправлялась. Я полез в код выяснять причину.
<body> <div data-widget="loginOrRegistration" class="sm6_30"> <div class="s6m_30"> <div class="n4m_30 t5m_30"> <!-- здесь логотип OzonID --> </div> <div class="bq03_9_2-a"> <span class="tsHeadline600Large c65_4_2-a5">Введите номер телефона</span> </div> <div class="ms9_30"> <span>Мы отправим код или позвоним. Отвечать на звонок не нужно. Код может прийти на почту или в СМС</span> </div> <div class="mt8_30"> <div> <div class="z3l_30"> <div class="c85_4_2-a"> <label class="c85_4_2-a0"> <div class="f5_4_3-a f5_4_3-a7 f5_4_3-b6 f5_4_3-b7 lz4_30"> <div class="f5_4_3-b0"> <input autocomplete="off" type="tel" name="autocomplete" autofocus="autofocus" class="d5_4_4-a d5_4_4-a3 l4z_30"> </div> </div> </label> </div> <div class="e35_4_5-a e35_4_5-b5 l2z_30 zl4_30"> <!-- здесь выпадающий список с кодом страны --> </div> <div> <button type="submit" class="b25_9_5-a b25_9_5-b7 b25_9_5-b5 b25_9_5-b"> <div class="b25_9_5-a7"> <div class="b25_9_5-a2 tsCompactControl500Medium">Войти</div> </div> </button> <div class="t6m_30"> <!-- здесь альтернативные методы авторизации --> </div> </div> </div> </div> </div> </div> </div> </body>
А разработчики не используют элемент form. Какие же они молодцы!
Ловко меня обдурачили. Больше всего меня позабавило, что они к элементу button добавили атрибут type со значением submit. Как будто так форма отправится.
Если элемент form не используется, то пользователь не может отправить данные по нажатию клавиши Enter. Так что если хотите, чтобы я снова много раз жал эту клавишу, то делайте, разработчики сайта.
Портите обводку интерактивных элементов с помощью свойства overflow
Скорее всего, вы слышали, что нельзя убирать обводку у интерактивных элементов, которая создаётся с помощью свойства outline. Если вы объявите его со значением 0 или none, то вам скажут: «Нельзя так!».
По этой причине нужно действовать хитро. Полностью убирать обводку не получится, но можно её отображать обрезанной. Давайте посмотрим эту технику на примере списка новинок книг.
Обводка обрезана сверху. Мне как пользователю, постоянно использующему интерфейсы при помощи клавиатуры, такие штуки всегда вводят недоумение. Я только каких загогулин не встречал.
А теперь посмотрим, почему обводка отобразилась таким образом.
Мы видим, что у родительского элемента установлено свойство overflow со значением hidden. Обводка вокруг ссылки выходит за границы, и поэтому она обрезается. Гениальный трюк!
Так что добавляйте везде свойство overflow, где используются дочерние интерактивные элементы. Тогда пользователи ваших интерфейсов вряд ли увидят корректную обводку.
Заключение
Подведём итог. В этой статье мы с вами рассмотрели советы для создания ужасных интерфейсов. Вот они:
не используйте элемент
aдля текста, который выглядит как ссылка;для смайликов, размеченных элементом
img, добавляйте альтернативный текст, который будет сбивать с толку пользователей скринридера;используйте иностранные слова для альтернативного текста;
при авторизации в приложении используйте стандартную цифровую клавиатуру при вводе цифрового кода;
не используйте элемент
form, чтобы пользователь не мог отправить данные с помощью клавишиEnter;обрезайте обводку вокруг интерактивных элементов с помощью свойства
overflowсо значениемhidden.
Вот такой список у меня получился. Конечно, это далеко не все приёмы, которые можно использовать против пользователей, но это хороший первый шаг. Будьте уверены, что они скажут вам пару «добрых» слов.
Но давайте зададим себе простой вопрос: «Это нам вообще нужно?» Вряд ли вы хотите принести пользователю неудобства. Я верю в то, что вы создаёте интерфейсы совсем не для этого. По этой причине предлагаю воспринимать всё, о чём я рассказал, немного иначе.
Пожалуйста, воспринимайте мою статью как небольшой список подозрительных решений, которые стоит поискать в своих проектах. Если вы их найдёте, у вас появится повод сделать интерфейс лучше.
На этом всё. Спасибо за чтение!
P. S. Помогаю больше узнать про CSS и дружелюбные интерфейсы в своих ТГ‑каналах CSS isn't magic и UX + Dev = a11y. Присоединяйтесь. Как вступить, написано в профиле.
© 2026 ООО «МТ ФИНАНС»
Комментарии (44)
luchezarnaja
29.09.2026 12:01Определенно хочу продолжения. Это что-то наряду с ихний и евоный, муки и страдания. Прекрасно.
Spaceoddity
29.09.2026 12:01Декоративные изображения тоже могут преподнести неприятные сюрпризы, если подойти к делу с изобретательностью
А вот тут я бы уже смотрел на мета-уровень - что декоративная графика вообще делает в HTML? ;)
Подсказка «fire» будет мешать людям несколькими вариантами.
/* режим душнилы */
Это всё-таки именно альтернативный текст для изображения - либо одно, либо другое.
Изначально же его предназначение было в том, чтобы дать юзеру понимание того что изображено на картинке, если она не прогрузилась. Про скринридеры в те время и не задумывались...
/* режим душнилы */
OlegZH
29.09.2026 12:01/* режим душнилы */
(замечание в сторону) Может быть, имелось в виду /* режим душнилы on*/ и /* режим душнилы off*/? Но, тогда, душнилой оказываюсь уже я. ;-) Извините. ;-|
Spaceoddity
29.09.2026 12:01Ой зря вы эти игры затеяли - держите ответный режим душнилы ;)
(замечание в сторону)
Именно что в сторону - к семантике веба это не имеет отношения.
Или вы всерьёз хотите подискутировать на тему оформления комментариев? Потому что тема далеко не однозначная ;)
OlegZH
29.09.2026 12:01Я мог бы, разве что, подискутировать о том, что все
комментариитеги должны быть парными.
ion_nsk_region
29.09.2026 12:01Это всё-таки именно альтернативный текст для изображения - либо одно, либо другое.
Изначально же его предназначение было в том, чтобы дать юзеру понимание того что изображено на картинке, если она не прогрузилась. Про скринридеры в те время и не задумывались...Но мы ведь здесь и сейчас живём. Руководство по обеспечению доступности веб-контента (WCAG) существует уже больше 20 лет. Использование alt атрибута там упоминается ещё в самых первых версиях от 1999 года. И судиться по этому поводу начали уже в 2000 году.
А с марта этого года в России:
Скрытый текст
А с марта этого года в России уже введён ГОСТ Р 52872-2019 "Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности". Там нет явного указания каким именно образом обеспечивать читаемость изображений на вебсайтах, так что задачу можно решить и альтернативами для атрибута alt. Но за несоответствие требованиям уже можно словить штраф по статье 9.13 КоАП РФ Уклонение от исполнения требований к обеспечению доступности для инвалидов объектов социальной, инженерной и транспортной инфраструктур и предоставляемых услуг.
Spaceoddity
29.09.2026 12:01Но мы ведь здесь и сейчас живём. Руководство по обеспечению доступности веб-контента (WCAG) существует уже больше 20 лет.
Это их проблемы! Ладно бы ещё W3C был. Мы разработчики. А музыку заказывает заказчик. Если в ТЗ будет прописано "что, где, как" - не проблема. Но по дефолту закладываться на "максимальный уровень доступности веб-контента" - довольно сомнительная практика.
Какие-то полумеры получаются, не находите? То, что у меня прописаны alt - ещё не значит что у меня реализована полноценная поддержка скринридеров ;)
ion_nsk_region
29.09.2026 12:01А музыку заказывает заказчик. Если в ТЗ будет прописано "что, где, как" - не проблема. Но по дефолту закладываться на "максимальный уровень доступности веб-контента" - довольно сомнительная практика.
Согласен по всем пунктам.
Мой комментарий был скорее о том, что в современных реалиях нельзя ограничиваться только исходным предназначением атрибута
alt, потому что сейчас гораздо больший риск столкнуться со штрафом или судебным иском из-за отсутствия поддержки скринридеров, чем из-за того, что у незагрузившегося изображения нет альтернативного текста. Я думаю, что автор статьи придерживается такого же мнения, отсюда и совет в статье - заполнять атрибутaltкак для скринридеров, а не просто как альтернативный текст на случай если изображение не загрузится.
JBFW
29.09.2026 12:01что декоративная графика вообще делает в HTML?
Это когда "херов имидж" (hero_image) на весь экран и на 10+ мегабайт?
rabitagorgor
29.09.2026 12:01Встречал даже платежные формы, где для ввода реквизитов карты у полей не проставлен признак ввода только цифр, соответственно на мобильных отображается полная клавиатура отображается. Бесит, конечно, жутко.
RTFM13
29.09.2026 12:01Еще бесят раздельные поля для каждой цифры пинкода обвешенные гигабайтными скриптами так, что приходится печатать одним пальцем отсчитывая в уме паузы. Естественно и копипаста и бэкспейс - всё в пролёте.
Markscheider
29.09.2026 12:01Еще бесит, когда наберешь в поле ввода 3 цифры, переключишься в другое приложение (остаток номера посмотреть), потом возвращаешься, а они три набранные заботливо стерли (андроид, приложение мосуслуг)
naky
29.09.2026 12:01Заставляйте вводить цифровой код для авторизации с помощью маленьких клавиш цифровой клавиатуры
Здесь упущен один важный нюанс: под каждую цифру должно быть отдельное поле ввода, вызывающее килограмм джаваскриптовых обработчиков на ввод каждой цифры, чтобы у пользователя не было ни малейшего шанса просто взять и ввести все цифры без ожидания по пол секунды между ними.
И ещё момент: после ввода всех цифр ни в коем случае ничего не должно происходить автоматически. Кнопка подтверждения должна быть запрятана под экранную клавиатуру.
У меня в банкинге именно так.
ogost
29.09.2026 12:01Здесь упущен один важный нюанс: под каждую цифру должно быть отдельное поле ввода, вызывающее килограмм джаваскриптовых обработчиков на ввод каждой цифры,
Ооо да. И поэтому просто нельзя взять и вставить из буфера обмена.
У меня в банкинге именно так.
Не только у вас, коллега, и не только в банкинге.
redfox0
29.09.2026 12:01Однажды комбо собрал: шесть отдельных полей для ввода 6 цифр (ну хоть из буфера вставляется нормально) и… нет кнопки “Отправить”. Вообще нет никакой кнопки. После ввода последней цифры тоже ничего не происходит.
Надо нажать Enter, когда курсор в последнем поле. Документация есть, про эту особенность там не написано.
JBFW
29.09.2026 12:01Джаваскриптовые обработчики - это прекрасТно:
по умолчанию в поле стоит, к примеру, 300 - вам надо 500, но если вы сначала сотрете "3" - скрипты тут же пересчитают итоговую стоимость "0", комиссии, то, сё, напишут что юзер идиот, потому что платить 0 нельзя! Вернитесь на предыдущую страницу, и попробуйте еще раз!А если вы сначала добавите "5" - скрипты тутже пересчитают итоговую стоимость "3500", комиссии, то, сё, напишут что юзер идиот, потому что этой суммы должно хватить намного больше чем на 1 месяц, а там скидка! Вернитесь на предыдущую страницу и выберите другой период!
Всё для вашего удопства!
sen4o
29.09.2026 12:01Про Enter в форме - вечная боль конструкторов. На WordPress встречал ровно такое: форма собрана из div-ов, у кнопки onclick, и Enter ничего не делает, пока не обернешь все в нормальный
И к пункту про код еще добавлю autocomplete=“one-time-code”: если код приходит по SMS, телефон сам предлагает его над клавиатурой, и целиться по маленьким цифрам не нужно вообще. Маме с больной рукой это помогло бы сильнее всего
P.S. у ямаля щас просто пушечный сезон.
achekalin
29.09.2026 12:01Да что там примеры как не надо делать:
Хабр использует загружаемые фонты. Мелочь, но на плохом канале связи для загрузки текстового, по сути ресурса, нужно дождаться, пока телефон (!) вытянет к себе начертание шрифта, который на телефоне особо и не повлияет на чтение - дюно доказывает, что дизайнер сидел на маке, и оттуда же гарнитуры взял.
В конце статьи поле ввода коммента - его не могли сделать простым, но и на мобильных устройствах оттестировать серьезно времени не нашлось. Не знаю, кто виновать, но на свежем андроиде в свежем хроме писать - мучение, а пользоваться для правки - еще неудобнее.
Писать новый материал даже на десктопе врагу не пожелаешь, на мобилке лучше не пробовать.
meer
29.09.2026 12:01Про плохой канал есть еще нередко встречаемая история, когда содержимое страницы уже начало прогружаться, успеваешь прочесть заголовок и пару строк, потом вдруг все исчезает - ибо реклама-то или скрипт аналитики не загрузились! И сидишь ждешь-гадаешь, кого же мы тут ждем сейчас, чтобы можно было продолжить чтение.
leshchev-artem
29.09.2026 12:01Маскируйте обычный текст под ссылку
Мне как-то попалось наоборот, ссылка была замаскирована под обычный текст. Цвет и размер шрифта те же, что и остальной текст + не было подчёркивания. Это была хитро замаскированная отписка от рассылки :)
Cryvage
29.09.2026 12:01Не забудьте ещё запретить копирование на странице. А то прибыль упустите.
JBFW
29.09.2026 12:01Причина может быть в другом: для копирования выделенного текста надо сначала выделить текст, а вот выделение как раз и невозможно, его запретили.
Запретили потому, что юзеры постоянно по ошибке выделяют просто рандомный кусок страницы, который потом то пытается вставиться первым в поля ввода, то телефон пытается его "обьяснить и перевести", то еще что.По хорошему конечно надо интерфейс переделывать, чтобы по нему не возили лишний раз пальцем и мышкой, но ведь проще запретить выделять...
serafims
29.09.2026 12:01С полями ввода цифр кода авторизации бывает ещё лютая дичь, когда под каждую цифру делают отдельное поле, с перескоков в следующее при вводе, но не могут реализовать корректное стирание кода по backspace с переходом на предыдущее поле. А кликаешь в предыдущее, чтобы его очистить, курсор перекидывает вправо...
ideological
29.09.2026 12:01На такое сейчас обращают внимание только душнилы :), всех как будто бы всё устраивает и ни один менеджер не чувствует необходимости сделать нормально
Обрезаемый в карточках текст, выравнивание по ширине, незаметный ползунок скролла..
opusmode
29.09.2026 12:01Как бы можно, а зачем?
Когда лет так 8-9 назад крутили аналитику по новостному ресурсу, уже было очевидно, что вход через главную был не основным, шли из соцсетей на конкретную новость
Это, напомню, было почти 10 лет назад
Сегодня твой сайт тем более никому не нужен. Есть куча агрегаторов, страницы сайтов в лентах соцсетей. Если у тебя предполагается взаимодействие - пили приложение.
А ещё лучше адаптируй под llm, ведь большинство будет не заходить, а считывать обработанное от нейросетки
Ну и чо толку от ваших карточек менеджеру?
ts347
29.09.2026 12:01...формы, не отправляющиеся по Enter.
Потому что 99% пользователей никогда и не додумались бы до этого.
Потому что на телефоне нет разницы, нажать кнопку на экране или
на клавиатуреснова на экране.Короче, виноват Стив Джобс.
Spaceoddity
Клик колёсиком мыши
Теперь по поводу семантики гиперссылок. Для начала у вас пример так себе - визуально отличается от основного текста, но нижнего подчёркивания (в дефолтном состоянии, как минимум) при этом нет. Так что тут кликайте на свой страх и риск ;)
Но проблема действительно имеет место быть. Я уж не знаю кто и когда (наверное всей индустрией совместно) решил что интерактивные элементы интерфейса надо оформлять так же как и гиперссылки... Хотя варианты были - dashed, dotted, outline... Плюс на это наложилась и встречная практика, когда гиперссылки стали оформлять... не как гиперссылки))
Ну и наконец третий фактор подоспел - ссылки-ссылками, только сейчас они повсеместно через аякс уже работают, так что клик СКМ снова мимо - хотя это тоже можно фиксить (как раньше делали gracefull degradation для отключенного js - сейчас тоже самое, только в целях улучшения юзабилити).
k4ir05
Так подчёркивание ссылок уже давно стали убирать, это уже давно не является их отличительным свойством. И этот пример как раз иллюстрирует это
и это
legrus
Клик колёсиком мимо ссылки вызывает
демоноврежим скролла страницы, а оно мне надо? Только контрол-клик!Spaceoddity
В чём проблема? Ну для начала - не промахивайтесь. И ЛКМ мимо цели может в дебри увести)) Во-вторых, ну появился режим скрола - и? Отмените его ещё одним кликом. Если же у вас включается скролл - ну не знаю... значит у нас "микроменеджмент" разный... попробуйте с настройками мыши поиграться - потому что это не дело, девайс не должен за пользователя "додумывать" ;)
Вне моего понимания! Задействовать две конечности для такой заштатной процедуры? Я и на клавиатуре-то частенько одной управляюсь...
olivera507224
Одна рука на клавиатуре, одна на трекпаде, колеса в этой схеме просто не существует. Вы - это не все. И далеко не все как вы.
JBFW
на тачпаде нет колесика мышки...
Spaceoddity
это проблемы тачпада
ts347
Разве еще существуют тачпады, у которых нельзя настроить тап двумя и тремя пальцами?
JBFW
Можно, но это тупо неудобно
Newpson
А как же вы скроллите без колёсика тогда? Наверное, двумя пальцами вверх-вниз. Аналогично, тап двумя пальцами вызывает контекстное меню (ПКМ), тап тремя пальцами эмулирует нажатие на колёсико (СКМ). Конечно, если речь не про древний тачпад с полосочкой для скроллинга сбоку; на таком можно забиндить, как выше сказали, СКМ = ПКМ + ЛКМ.
JBFW
Вот тому кто придумал "скролл двумя пальцами" пальцы бы поотламывать. Вместо того чтобы просто пролистать страницу - оно то пролистывает, то считает это "тапом двумя пальцами", то "тапом одним пальцем", то ещё как.
Чтоб ему задницу в туалете так вытирать: то с бумагой, то без бумаги, в зависимости от того насколько одновременно пальцы лягут
ts347
У вас явно проблема либо с тачпадом, либо с пальцами, без обид. Возможно, стоит выкрутить чувствительность в настройках. Потому что скролл двумя пальцами это на самом деле лучшее, что придумали в тачпадах.
Ну и не совсем понятно, что́ вы хотели бы вместо этого.
JBFW
Была вполне удобная схема: слева - "левая кнопка", справа - "правая кнопка", вверх-вниз по краю - скролл.
Одним пальцем, без складывания разных фигур.
А теперь - браузер интерпретирует два пальца как попытку увеличить-уменьшить шрифт: можно отключить, но это непросто ("наш пользовательский опыт говорит что народу нравится"), скролл то работает то нет.
Хорошо еще что некоторые ноуты умеют эмуляцию полоски скролла, но не все
Newpson
согласен с предыдущим ответившим вам. Проблем с жестами не было никогда, учитывая что я использовал тачпады разной степени всратости: малюсенькие на ультрабюджетных нетбуках 2010-х годов, среднего размера на макбуке тех же лет, большие современные из сегмента “выше среднего”, а также большие современные ультрабюджетные варианты - и ни в одном из случаев не было проблемы распознавания жестов.
Но при этом у знакомого на моём ноутбуке, действительно, получалось скроллить двумя пальцами через раз. Из возможных причин, которые я мог наблюдать: либо слишком близко пальцы друг к другу, либо касается только один палец, либо пальцы слишком слабо касаются тачпада. Быть может, дело привычки. Но я сам, если что, больше фанат нормальной мыши, чем тачпада.
JBFW
Так-то тачпадами пользуюсь со времен когда они только появились. даже клавиатуру специально с тачпадом брал - это удобнее мыши, когда не нужно в мелкие детали целиться.
Но вот этот скролл - поубивал бы.
mSnus
Либо есть мультитач, либо нажатие двух кнопок одновременно обычно