Как показывать ошибки в ячейках редактируемой таблицы

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

В форме обычно видны подпись поля и введённое значение. В таблице пользователь читает данные по пересечениям строк и колонок: «цена для товара А», «срок для заявки Б». При ошибке важно не только указать неверную ячейку, но и не разрушить эту связь. Сообщение, оторванное от строки или показанное в общей шапке, заставляет заново искать исходное значение.

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

Сначала определите тип проверки. Локальная проверка касается отдельного значения: количество должно быть целым, дата — допустимой, обязательное поле — заполненным. Межполевое правило зависит от других ячеек той же строки: дата окончания не может быть раньше начала. Серверная проверка может обнаружить конфликт с записью, которой нет в текущем наборе. Для каждого типа понадобится понятное место объяснения.

Короткая ошибка полезна, если называет поле и правило. «Некорректно» сообщает только о неудаче. «Цена должна быть числом» уже указывает проблему, а «Введите цену в рублях, например 1250,50» добавляет способ исправления. Не повторяйте длинное правило в каждой строке, если оно уже видно в заголовке колонки или подсказке; в сообщении оставьте именно то, чего не хватает для решения.

Если ошибка зависит от нескольких значений, укажите связь словами: «Окончание периода должно быть не раньше даты начала». Для конфликта с сохранёнными данными назовите обстоятельство без технического кода: «Заявка с таким номером уже существует». Если исправление невозможно прямо сейчас, обозначьте безопасное действие: например, обновить запись или обратиться к владельцу доступа.

Используйте одну устойчивую структуру текста: ошибка → причина → рекомендация, когда она известна. Не превращайте её в обвинение пользователя и не скрывайте значимую информацию за формулировками «что-то пошло не так». При этом не раскрывайте внутренние идентификаторы, SQL-ошибки и данные других пользователей.

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

Не полагайтесь только на красную рамку или изменение цвета текста. Добавьте видимый знак состояния, короткий текст и программную связь сообщения с элементом ввода. Тогда смысл ошибки можно найти и без цветового зрения, а вспомогательная технология сможет сообщить пояснение вместе с полем. В веб-разметке aria-invalid может обозначать недопустимое значение, а aria-describedby — связывать редактор с поясняющим текстом. Это техники реализации, а не замена ясного сообщения; примеры такого сочетания есть в технике ARIA21 W3C.

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

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

Проверка на каждый символ может мешать: значение ещё не закончено, а интерфейс уже объявляет его неверным. Для простого формата можно проверять после выхода из ячейки; для правил с сервером — после сохранения или небольшой задержки после ввода. Важнее последовательность: пользователь заранее понимает, когда появится ошибка, и может повторить её клавиатурой.

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

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

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

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

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

Представьте таблицу товаров с колонками «Артикул», «Цена», «Остаток» и кнопкой «Сохранить изменения». Пользователь меняет цену на -200 и остаток на 12,5. После сохранения сервер отклоняет обе ячейки: цена не может быть отрицательной, остаток хранится в целых единицах.

Интерфейс показывает в колонке цены: «Цена не может быть меньше нуля. Укажите 0 или больше». В колонке остатка: «Введите целое количество, например 12». Рядом с каждой ячейкой остаётся маркер ошибки; общий баннер сообщает «Не сохранено: исправьте 2 значения» и ведёт к первой ошибке. Значения остаются в таблице, а пользователь может исправить их клавиатурой и повторить сохранение. Сообщение не меняет порядок строк и не сбрасывает фильтр по категории.

Если сервер сообщает, что артикул уже есть у другой записи, это не ошибка цены или остатка. Покажите её на уровне строки, назовите колонку «Артикул» и предложите проверить дубликат. Если найдено 40 проблем после импорта, не раскрывайте сорок сообщений одновременно: дайте сводку, фильтр «Только ошибки» и последовательную навигацию. Содержание каждой ошибки всё равно должно быть доступно в строке.

Для связанного правила, например «дата окончания раньше даты начала», укажите оба поля, даже если редактировалась только дата окончания. Пользователь должен понимать, какое значение нужно согласовать. Если исправление может повлиять на другие поля, не подставляйте его автоматически без подтверждения.

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

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

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

Нет, цвет должен дополнять текст или другой заметный сигнал. Сообщение должно назвать поле и описать проблему, чтобы ошибку могли найти люди с нарушенным цветовосприятием и пользователи вспомогательных технологий. Это следует из критерия 3.3.1 WCAG. Когда способ исправления известен, полезно также учитывать критерий 3.3.3 об указании ошибки.

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

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

Убирайте его после успешной повторной проверки значения или после подтверждённого сохранения — в соответствии с логикой продукта. Если значение исправлено локально, но сервер ещё не принял его, замените ошибку состоянием «изменение не сохранено», а не объявляйте запись успешной.

Хорошая ошибка в таблице сохраняет адрес записи, объясняет правило и помогает исправить значение, не теряя другие данные. Сначала определите область проверки и момент её запуска, затем проверьте поведение сообщений, клавиатуры и прокрутки на серии реальных строк. Если вы создаёте собственный шрифт для интерфейса с таблицами, испытайте цифры, короткие метки и пояснения в макете через Fontgenerator.