BITSPARK / Статьи / Дизайн и элементы сайта
Форма обратной связи на сайте: что это и что проверить до запуска
Коротко: для формы обратной связи на сайте опора - определение веб-формы: MDN называет её одной из главных точек взаимодействия посетителя с сайтом. Посетитель вводит данные в поля, а кнопка отправки передаёт их на адрес, указанный в форме, где их принимает программа на сервере. MDN советует спрашивать только необходимые данные, а статья 5 152-ФЗ говорит о данных, которые отвечают целям обработки и не избыточны. Подписи, ошибки и проверку данных описывают MDN, web.dev и W3C.
Страницы источников открыты 06.10.2026. MDN и web.dev - учебные материалы для разработчиков: это не норма и не стандарт. Курс web.dev Learn Forms помечен «Last updated 2021-11-03 UTC», то есть последний раз обновлялся 3 ноября 2021 года. Русской версии страницы MDN «Your first form» нет: цитаты даны на английском, перевод наш. Пример в статье вымышленный: мастерская кухонь на заказ с сайтом example.ru, форма на котором принимает заявку на замер.
Что такое форма обратной связи на сайте?
Коротко: MDN определяет веб-форму как одну из главных точек взаимодействия посетителя с сайтом, а HTML-элемент form - как раздел страницы с элементами управления, которые позволяют отправлять информацию. Названия форма обратной связи, форма заявки и обратный звонок источники статьи не определяют. В примере MDN контактная форма состоит из трёх текстовых полей и одной кнопки.
Определение веб-формы стоит на первой странице курса MDN о формах:
«Web forms are one of the main points of interaction between a user and a website or application.» Перевод наш: веб-формы - одна из главных точек взаимодействия между посетителем и сайтом или приложением.
- MDN, Your first form - Learn web development | MDN, страница изменена 2 октября 2026 года по пометке внизу
Из чего форма собрана, MDN пишет в следующем абзаце:
«A web form's HTML is made up of one or more form controls (...), plus some additional elements to help structure the overall form» Перевод наш: HTML веб-формы состоит из одного или нескольких элементов управления (...) и дополнительных элементов, которые помогают структурировать форму в целом.
Элементы управления MDN перечисляет там же: однострочные и многострочные текстовые поля, выпадающие списки, кнопки, флажки и переключатели. Русская страница MDN об элементе form, перевод сообщества, определяет сам элемент так:
«HTML-элемент
<form>представляет раздел документа, содержащий интерактивные элементы управления, которые позволяют отправлять информацию.»
- MDN, 0 - HTML | MDN
Слова форма обратной связи, форма заявки и обратный звонок в этих источниках не встречаются как термины. Ближайший пример у MDN называется contact form, контактная форма:
«Our form will contain three text fields and one button. We are asking the user for their name, their email and the message they want to send.» Перевод наш: в нашей форме будут три текстовых поля и одна кнопка. Мы спрашиваем у посетителя имя, адрес электронной почты и сообщение, которое он хочет отправить.
Для заказчика отсюда следует практичный вывод. В задании подрядчику форму обратной связи на сайте лучше описать по составу: какие данные вводит посетитель, куда уходит заявка и что посетитель видит после отправки. Остальные разделы статьи раскрывают эти три вопроса.
Из чего состоит форма?
Коротко: по MDN и web.dev простая форма включает поля ввода, подпись у каждого поля и кнопку отправки. Подпись описывает назначение поля, и её читают программы экранного доступа. Кнопка отправки передаёт данные на адрес, указанный в форме. Кнопку сброса MDN называет плохой практикой с точки зрения удобства. Сообщение об ошибке появляется, если данные не прошли проверку.
Части формы собраны в таблице. Каждая строка опирается на одну из страниц MDN, web.dev или W3C.
| Часть формы | Что это простыми словами | Что пишет источник |
|---|---|---|
| Поле ввода | Место, где посетитель вводит данные | MDN, пример контактной формы: поле имени однострочное, поле почты принимает только адрес электронной почты, поле сообщения многострочное |
| Подпись поля | Текст, который говорит, какие данные вводить | web.dev: видимая и хорошо написанная подпись помогает понять назначение поля; подпись читают программы экранного доступа |
| Кнопка отправки | Кнопка, после которой данные уходят на адрес формы | MDN: щелчок по кнопке отправки отправляет данные на страницу, указанную в атрибуте action |
| Кнопка сброса | Кнопка, которая возвращает все поля к исходным значениям | MDN: с точки зрения удобства считается плохой практикой; без веской причины её не используют |
| Сообщение об ошибке | Текст, который появляется, если данные не прошли проверку | web.dev: сообщение показывают рядом с полем, к которому оно относится |
О подписи web.dev пишет отдельно, и это пункт, который заказчик может проверить глазами:
«A visible and well-written label helps the user understand the purpose of a form control.» Перевод наш: видимая и хорошо написанная подпись помогает посетителю понять назначение элемента управления формы.
- web.dev, Design basics | web.dev, Last updated 2021-11-03 UTC
Там же стоит предупреждение о подсказке внутри поля:
«Never misuse the placeholder attribute as a label. The placeholder is meant for giving a hint about the type of data you should enter, not for describing a form control.» Перевод наш: никогда не используйте атрибут placeholder вместо подписи. Заполнитель задуман как подсказка о типе данных, которые нужно ввести; описывать элемент управления он не должен.
- web.dev, Design basics | web.dev, Last updated 2021-11-03 UTC
Про формулировку и расположение подписи web.dev даёт два совета. Короткая подпись «Email address» (адрес электронной почты) предпочтительнее длинной «Enter your email address» (введите адрес вашей электронной почты), потому что «short labels are easier to scan, reduce visual clutter, and help users to understand what data is needed faster». Перевод наш: короткие подписи легче просматривать, они уменьшают визуальный шум и помогают посетителям быстрее понять, какие данные нужны. Подпись, по словам курса, лучше ставить над полем: в исходном тексте сказано, что «best practice is to position the label above the form control». Перевод наш: лучшая практика - располагать подпись над элементом управления формы.
Сколько полей спрашивать?
Коротко: MDN советует спрашивать только те данные, которые абсолютно необходимы. web.dev и W3C дают тот же совет другими словами. Части 4 и 5 статьи 5 152-ФЗ говорят о персональных данных, которые отвечают целям обработки и не избыточны по отношению к заявленным целям. Числа полей ни одна из этих страниц в процитированных местах не называет.
MDN формулирует совет о длине формы в двух предложениях:
«it's important to remember that the bigger your form, the more you risk frustrating people and losing users.» Перевод наш: важно помнить, что чем больше ваша форма, тем больше риск раздражать людей и терять посетителей.
«Keep it simple and stay focused: ask only for the data you absolutely need.» Перевод наш: делайте проще и сосредоточьтесь на главном: спрашивайте только те данные, которые вам абсолютно необходимы.
В курсе web.dev о безопасности и конфиденциальности тот же совет стоит первым шагом:
«Don't ask for data you don't need, and always question whether you need all of the requested data.» Перевод наш: не спрашивайте данные, которые вам не нужны, и всякий раз задавайте себе вопрос, нужны ли вам все запрашиваемые данные.
- web.dev, Security and privacy | web.dev, Last updated 2021-11-03 UTC
Руководство W3C по доступным формам, обновлённое 27 марта 2026 года, пишет так:
«Only ask users to enter what is required to complete the transaction or process» Перевод наш: просите посетителей вводить только то, что требуется для завершения операции или процесса.
Это советы для разработчиков. Принципы обработки персональных данных сформулированы в статье 5 152-ФЗ. Она называется «Принципы обработки персональных данных», на странице КонсультантПлюс стоит редакция от 26.07.2026, и там же есть пометка о подготовленной редакции с изменениями, не вступившими в силу. Часть 4 статьи 5 звучит так:
«Обработке подлежат только персональные данные, которые отвечают целям их обработки.»
- 152-ФЗ, ч.4 ст.5, Статья 5. Принципы обработки персональных данных \ КонсультантПлюс
Часть 5 той же статьи:
«Содержание и объем обрабатываемых персональных данных должны соответствовать заявленным целям обработки. Обрабатываемые персональные данные не должны быть избыточными по отношению к заявленным целям их обработки.»
- 152-ФЗ, ч.5 ст.5, Статья 5. Принципы обработки персональных данных \ КонсультантПлюс
Предельного числа полей текст этих частей не называет. Какие данные отвечают целям обработки на конкретном сайте - вопрос к юристу владельца сайта.
Для example.ru, мастерской кухонь, форма заявки на замер могла бы спрашивать три вещи. В задании рядом с каждым полем стоит строка о том, зачем оно нужно: имя - как обратиться к посетителю в ответе; телефон - позвонить и согласовать время замера; сообщение - уточнения к заявке. Для поля, у которого такой строки нет, у заказчика остаётся вопрос из совета MDN: нужны ли эти данные абсолютно. Пример вымышленный и не показывает, сколько полей достаточно.
Что происходит после нажатия кнопки отправки?
Коротко: по MDN щелчок по кнопке отправки передаёт данные на адрес из атрибута action формы. Данные уходят на сервер парами имя-значение, и программа на сервере получает их. Что эта программа делает с данными, определяет сайт: MDN называет показ, сохранение в базе, отправку по электронной почте и другую обработку. Куда придёт заявка, заказчик решает заранее.
MDN объясняет путь данных на первой странице курса:
«A click on a submit button (the default value) sends the form's data to the web page defined by the action attribute of the <form> element.» Перевод наш: щелчок по кнопке отправки (значение по умолчанию) отправляет данные формы на веб-страницу, заданную атрибутом action элемента form.
Атрибут action содержит адрес, по которому уходят данные. На странице «Sending form data» сказано, что без этого атрибута данные придут на страницу, где стоит форма:
«If this attribute isn't provided, the data will be sent to the URL of the page containing the form - the current page.» Перевод наш: если этот атрибут не задан, данные будут отправлены на адрес страницы, где расположена форма, то есть на текущую страницу.
- MDN, Sending form data - Learn web development | MDN, страница изменена 25 августа 2026 года по пометке внизу
Название каждого поля задаёт разработчик, и вместе со значением оно уходит на сервер:
«The form data is sent to the server as name/value pairs.» Перевод наш: данные формы отправляются на сервер парами имя-значение.
Принимает данные программа, которую MDN называет скриптом на стороне сервера. О том, как скрипт обработает данные, MDN пишет:
«The way this script will handle that data is up to you.» Перевод наш: как этот скрипт обработает данные, решаете вы.
На странице «Sending form data» в примере на PHP перечислены варианты:
«You might display it, store it in a database, send it by email, or process it in some other way.» Перевод наш: вы можете показать данные, сохранить их в базе данных, отправить по электронной почте или обработать как-то иначе.
web.dev пишет о том же: для обработки формы нужен скрипт:
«A script (running on the server or the client) is needed to process the form.» Перевод наш: для обработки формы нужен скрипт (на сервере или на стороне клиента, то есть в браузере).
- web.dev, Use forms to get data from users | web.dev, Last updated 2021-11-03 UTC
Что делать с заявкой после получения, источники не определяют, и этот выбор остаётся за заказчиком и подрядчиком. На странице MDN описано ещё одно следствие отправки: сервер отвечает, и «loading the URL defined by the action attribute, causing a new page load (or a refresh of the existing page, if the action points to the same page)». По-русски: загружается адрес из action, то есть открывается новая страница или обновляется текущая, если action указывает на неё. Что посетитель увидит на этой странице, решает сайт, и это стоит записать в задание.
Две детали о защите передачи стоят отдельной строки в задании. web.dev: «Always use HTTPS, especially for pages that include a form.» Перевод наш: всегда используйте HTTPS, особенно на страницах с формой. MDN добавляет, что если форма стоит на защищённой странице, а в action указан незащищённый адрес HTTP, то все браузеры показывают посетителю предупреждение безопасности при каждой попытке отправить данные.
Что такое проверка данных в форме и почему одной проверки в браузере мало?
Коротко: проверку введённых данных MDN называет валидацией. Валидация в браузере называется клиентской, на сервере - серверной. Клиентская помогает посетителю сразу исправить ошибку. MDN предупреждает: клиентскую валидацию не следует считать достаточной мерой безопасности, данные нужно дополнительно проверять на стороне сервера. web.dev ту же проверку на сервере называет обязательной перед сохранением данных.
Слово валидация означает проверку: соответствуют ли введённые данные требованиям формы. Русская страница MDN, перевод сообщества, дата изменения на странице 29 апреля 2026 года, объясняет два места проверки:
«Валидация, выполняемая в браузере, называется валидацией на стороне клиента, а выполняемая на сервере - валидацией на стороне сервера.»
Польза клиентской проверки описана там же:
«Валидация на стороне клиента - это первичная проверка введённых данных, которая существенно улучшает удобство взаимодействия с интерфейсом; обнаружение некорректных данных на стороне клиента позволяет пользователю немедленно их исправить.»
Следующий абзац страницы начинается с ограничения:
«не следует рассматривать валидацию на стороне клиента как достаточную меру безопасности!»
Причину MDN называет в предупреждении той же страницы:
«Никогда не доверяйте данным, передаваемым на сервер клиентской программой. Даже если ваша форма правильно валидируется и не допустит введение потенциально вредоносных данных на стороне клиента, злоумышленники по-прежнему могут изменить сетевой запрос.»
Сравнение двух мест проверки собрано в таблицу. Ячейки пересказывают страницы MDN и web.dev.
| Признак | Проверка в браузере | Проверка на сервере |
|---|---|---|
| Где выполняется | В браузере посетителя (MDN) | На сервере, куда отправлены данные (MDN) |
| Что даёт | Первичная проверка; посетитель исправляет данные сразу (MDN) | Проверка данных, которые дошли до сервера; MDN: проверять и очищать нужно все данные, пришедшие на сервер (английская страница «Sending form data») |
| Что сказано о достаточности | MDN: проверку в браузере не следует считать достаточной мерой безопасности | web.dev: данные нужно проверять на сервере перед тем, как сохранять их или передавать дальше |
Курс web.dev добавляет два уточнения, понятных заказчику. Встроенная проверка браузера включается правильными элементами и атрибутами формы. Тексты сообщений у браузеров разные, и это сказано прямо: «Different browsers use different text for error messages.» Перевод наш: разные браузеры используют разный текст сообщений об ошибках. Чтобы посетители видели одно и то же сообщение, курс предлагает задать его средствами JavaScript, и этот выбор стоит обсудить с подрядчиком.
Что W3C и web.dev пишут о подписях, обязательных полях и ошибках?
Коротко: статья опирается на два критерия WCAG уровня A, которые касаются ввода данных. Критерий 3.3.2 требует подписей или инструкций там, где посетитель вводит данные. Критерий 3.3.1 требует, чтобы найденная ошибка была названа в тексте вместе с полем, где она возникла. web.dev советует показывать ошибку рядом с полем, помечать обязательные поля и не передавать ошибку одним цветом.
WCAG (Web Content Accessibility Guidelines) - документ W3C о доступности веб-содержимого. Для каждого критерия успеха W3C публикует страницу Understanding с пояснением. Обе страницы размещены на сайте W3C: пояснение к критерию 3.3.1 обновлено 12 июня 2026 года, к критерию 3.3.2 - 9 марта 2026 года. На обеих у заголовка критерия стоит пометка Level A. Выводов о законе из этих страниц статья не делает.
Критерий 3.3.2 на странице Understanding записан одним предложением:
«Labels or instructions are provided when content requires user input.» Перевод наш: подписи или инструкции предоставляются, когда содержимое требует ввода данных от посетителя.
Слово requires в критерии не сужает его до обязательных полей. Пояснение W3C говорит об этом отдельно:
«The criterion applies to all form fields, whether they're required or optional.» Перевод наш: критерий относится ко всем полям формы, обязательным и необязательным.
Польза подписей и инструкций описана в разделе Benefits:
«Providing labels and instructions (including examples of expected data formats) helps all users (...) to enter information correctly.» Перевод наш: подписи и инструкции (включая примеры ожидаемых форматов данных) помогают всем посетителям (...) правильно вводить информацию.
Критерий 3.3.1 касается ошибок:
«If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.» Перевод наш: если ошибка ввода обнаружена автоматически, поле с ошибкой указывается, а ошибка описывается посетителю текстом.
В разделе Intent той же страницы разобран случай неудачной отправки:
«In the case of an unsuccessful form submission, it is not sufficient to only re-display the form without providing any hint that the submission failed.» Перевод наш: если отправка формы не удалась, недостаточно просто показать форму заново без какого-либо намёка на то, что отправка не прошла.
Способ показа ошибок критерий не задаёт:
«This criterion does not mandate any particular way in which errors should be displayed.» Перевод наш: этот критерий не требует какого-либо определённого способа показа ошибок.
Там же описана встроенная проверка браузера. Страница пишет, что при нескольких ошибках показывается только первая: «If several errors are present, only the first error message is exposed». Перевод наш: если ошибок несколько, показывается только первое сообщение об ошибке. Следующая ошибка появляется после исправления первой и новой отправки. Страница относит это к недостаткам встроенной проверки: «repeated resubmissions and corrections may be required». Перевод наш: могут потребоваться повторные отправки и исправления.
Заказчику стоит посмотреть, что видит посетитель, если ошибок в форме несколько.
Курс web.dev добавляет советы по оформлению. Про место ошибки:
«display error messages next to the form control they refer to.» Перевод наш: показывайте сообщения об ошибках рядом с элементом формы, к которому они относятся.
- web.dev, Design basics | web.dev, Last updated 2021-11-03 UTC
Пометку обязательных полей курс описывает так:
«If a field is mandatory, make it obvious!» Перевод наш: если поле обязательное, пусть это будет очевидно.
- web.dev, Design basics | web.dev, Last updated 2021-11-03 UTC
О цвете сообщения об ошибке сказано в разделе о доступности:
«to communicate an error or success, you should never rely only on color.» Перевод наш: чтобы сообщить об ошибке или успехе, никогда не следует полагаться только на цвет.
- web.dev, Accessibility | web.dev, Last updated 2021-11-03 UTC
В том же разделе web.dev объясняет, чем дополнить цвет: иконкой или названием типа ошибки в начале сообщения. Правила ввода курс тоже предлагает объяснять посетителю: «Make sure users understand how to enter valid data.» Перевод наш: убедитесь, что посетители понимают, как вводить корректные данные.
Что решить о клавиатуре телефона и автозаполнении?
Коротко: web.dev пишет, что тип поля влияет на экранную клавиатуру: для телефона на сенсорном экране показываются символы, нужные для номера, для почты - клавиатура, приспособленная для адреса. Автозаполнение курс описывает как подстановку ранее введённых данных, а подсказки браузеру задаются атрибутом autocomplete. MDN приводит то же о типе поля email.
Тип поля выбирает разработчик, и это можно записать в задание одним пунктом. Курс web.dev объясняет разницу простыми словами на примере телефона:
«If you use type="tel", users on touch devices get a keyboard showing only the characters needed to enter a telephone number.» Перевод наш: если вы используете type="tel", посетители на сенсорных устройствах получают клавиатуру, которая показывает только символы, нужные для ввода номера телефона.
- web.dev, Design basics | web.dev, Last updated 2021-11-03 UTC
Для почты то же сказано через тип email:
«By using type="email" the mobile device displays a keyboard optimized for entering an email address.» Перевод наш: при type="email" мобильное устройство показывает клавиатуру, приспособленную для ввода адреса электронной почты.
- web.dev, Design basics | web.dev, Last updated 2021-11-03 UTC
MDN говорит о типе email в контактной форме то же: подходящая раскладка клавиатуры, например с символом @ по умолчанию, появляется «on devices with dynamic keyboards, like smartphones». Перевод наш: на устройствах с динамической клавиатурой, например на смартфонах.
Автозаполнение курс web.dev объясняет так:
«One way to help users fill out forms faster is by offering them the option to automatically fill in form fields with previously entered data. That's autofill.» Перевод наш: один из способов помочь посетителям заполнять формы быстрее - предложить им автоматически подставить в поля ранее введённые данные. Это и есть автозаполнение.
- web.dev, Autofill | web.dev, Last updated 2021-11-03 UTC
Браузеру помогает атрибут autocomplete:
«Using suitable values for the autocomplete attribute helps browsers offer the best autofill option, and helps users fill out forms faster.» Перевод наш: подходящие значения атрибута autocomplete помогают браузерам предложить лучший вариант автозаполнения и помогают посетителям быстрее заполнять формы.
- web.dev, Autofill | web.dev, Last updated 2021-11-03 UTC
Для заказчика это два вопроса подрядчику. Какие типы полей выбраны для телефона и почты? Подобрано ли для телефонного поля подходящее значение autocomplete? Проверить это при добавлении телефонного поля советует web.dev.
Что стоит рядом с формой?
Коротко: рядом с формой обратной связи стоят вопросы, которые разбирают другие статьи раздела: согласие на обработку персональных данных, политика конфиденциальности, защита от автоматических отправок, форма во всплывающем окне и проверка на телефоне. Здесь они только названы, решение по каждому записывается в задание отдельным пунктом.
| Вопрос рядом с формой | Статья раздела |
|---|---|
| Согласие на обработку персональных данных у формы; в статье есть раздел «Достаточно ли галочки у формы?» | Согласие на обработку персональных данных на сайте: ст.9 152-ФЗ - BITSPARK |
| Политика конфиденциальности и место её размещения; в статье есть раздел «Где на сайте размещать документ?» | Политика конфиденциальности для сайта: что требует 152-ФЗ - BITSPARK |
| Капча: нужна ли форме проверка, которая отличает посетителя от автоматической программы | Капча на сайте: что это, какой бывает и нужна ли она форме - BITSPARK |
| Форма внутри всплывающего окна | Всплывающее окно на сайте: как называется и что проверить - BITSPARK |
| Как выглядит форма на экране телефона и как проверить адаптив до приёмки | Адаптивный сайт: что это и как проверить адаптив до приёмки - BITSPARK |
Что решить до дизайна и что спросить у подрядчика?
Коротко: восемь вопросов опираются на разделы статьи: данные и поля, подписи, адрес отправки, проверка, ошибки и сообщение после отправки, типы полей, соседние решения и работа на телефоне. Ответы на них записываются в задание дизайнеру и разработчику до начала работы над макетом формы.
На главной странице BITSPARK шаг процесса «Структура» описан так: «Собираем архитектуру: сценарии, страницы, контент и логику взаимодействия.» Форма - элемент страницы со своим сценарием: посетитель вводит данные, отправляет их и узнаёт, что произошло.
- Какие данные нужны от посетителя и зачем каждое поле? Опора: MDN - спрашивать только абсолютно необходимые данные; W3C - только то, что требуется для завершения операции; части 4 и 5 статьи 5 152-ФЗ.
- Какая подпись у каждого поля и какие поля обязательные? Опора: web.dev - подпись у каждого элемента управления и понятная пометка обязательных полей; WCAG 3.3.2.
- На какой адрес уходит форма и что делает с данными программа на сервере? Опора: MDN - данные уходят на адрес из action, обработка остаётся за сайтом.
- Где проверяются данные: в браузере, на сервере или в обоих местах? Опора: MDN - клиентская проверка не считается достаточной мерой безопасности.
- Что видит посетитель при ошибке и после успешной отправки? Опора: WCAG 3.3.1 - ошибка названа текстом, поле указано; руководство W3C по формам называет уведомление о выполнении задачи и об ошибках.
- Какие типы полей выбраны для телефона и почты, настроено ли автозаполнение? Опора: web.dev - экранная клавиатура зависит от типа поля, атрибут autocomplete помогает автозаполнению.
- Что стоит рядом с формой: согласие, политика, защита от автоматических отправок? Опора: статьи раздела о согласии, политике конфиденциальности и капче.
- Как форма работает на телефоне и с клавиатуры? Опора: web.dev - проверка формы только с клавиатуры; статья об адаптивном сайте.
Руководство W3C по формам перечисляет уведомления в одной строке:
«User Notifications: Notify users about successful task completion, any errors, and provide instructions to help them correct mistakes.» Перевод наш: уведомления посетителя: сообщайте об успешном завершении задачи и об ошибках и давайте инструкции, которые помогут исправить ошибки.
Для example.ru, мастерской кухонь, запись по форме заявки на замер могла бы выглядеть так. Поля: имя, телефон, сообщение; у каждого есть подпись и строка о том, зачем поле нужно. Для телефонного поля выбран тип, при котором на телефоне показываются символы для номера. Проверка идёт в браузере и на сервере.
После отправки посетитель видит сообщение о том, что заявка принята, а при ошибке - текст рядом с полем. Куда приходит заявка и кто её читает, записано отдельным пунктом. Согласие, политика и защита от автоматических отправок разобраны отдельно, ссылки на статьи раздела стоят в задании.
Что проверить при приёмке на телефоне и на компьютере?
Коротко: шесть проверок, каждая опирается на источник из статьи: отправка формы, подписи и обязательные поля, сообщения об ошибках, клавиатура телефона, проверка только с клавиатуры и просмотр на экране телефона. Список служит для разговора с подрядчиком при приёмке формы на телефоне и на компьютере.
- Отправьте форму с правильными данными и посмотрите, что видит посетитель после отправки. Затем убедитесь, что заявка дошла по адресу, который записан в задании. Опора: MDN - после отправки загружается адрес из action, обработка данных остаётся за сайтом.
- Оставьте обязательные поля пустыми и отправьте форму. Должно быть видно, какое поле не заполнено и в чём ошибка, текстом. Опора: WCAG 3.3.1 - поле с ошибкой указано, ошибка описана текстом; web.dev - ошибка рядом с полем.
- Если в форме есть поле электронной почты, введите вместо адреса слово и отправьте форму. Ошибка должна быть названа словами, а цвет рамки не может быть единственным признаком. Опора: web.dev - встроенная проверка браузера для поля почты и совет не полагаться только на цвет.
- Откройте форму на телефоне. Для телефонного поля должна появиться клавиатура с символами для номера телефона, для поля почты - клавиатура для адреса. Кнопка должна быть достаточно крупной для касания: web.dev советует делать область нажатия кнопки не менее 48px. Как проверять страницы на экране телефона, описано в статье Адаптивный сайт: что это и как проверить адаптив до приёмки - BITSPARK.
- На компьютере пройдите форму только клавишами. Порядок перехода между полями должен совпадать с порядком на экране. Опора: web.dev - проверяйте форму только клавиатурой, порядок табуляции следует визуальному порядку.
- Попросите заполнить форму одного-двух знакомых, которые её не видели. web.dev пишет: «Testing with one single other person is likely to help you improve your forms. Testing with two or more is even better.» Перевод наш: проверка с одним человеком, скорее всего, поможет улучшить формы, а с двумя и больше - ещё лучше.
На главной странице BITSPARK шаг «Запуск» описан так: «Проверяем desktop и mobile, скорость, формы и ключевые сценарии - затем запускаем.» Услуги студии, цены и шаги работы от задачи до запуска описаны там же.
Источники
Страницы открыты 06.10.2026. Страницы web.dev открыты по адресам с ?hl=en, на всех стоит пометка Last updated 2021-11-03 UTC.
- Your first form - Learn web development | MDN - определение веб-формы, состав, совет о составе данных, кнопки, отправка на сервер (на английском).
- Sending form data - Learn web development | MDN - атрибут action, обработка на сервере, проверка данных на сервере, HTTPS (на английском).
- Валидация форм на стороне клиента - Изучение веб-разработки | MDN - проверка на стороне клиента и на сервере (русский перевод сообщества).
- 0 - HTML | MDN - русское определение элемента form.
- Use forms to get data from users | web.dev - скрипт для обработки формы (на английском).
- Design basics | web.dev - подписи, ошибки, обязательные поля, клавиатура телефона (на английском).
- Help users enter the right data in forms | web.dev - встроенная проверка браузера, тексты сообщений (на английском).
- Autofill | web.dev - автозаполнение и атрибут autocomplete (на английском).
- Accessibility | web.dev - подписи, цвет ошибки, клавиатура (на английском).
- Security and privacy | web.dev - минимум данных, HTTPS (на английском).
- How to test forms for usability | web.dev - проверка формы людьми (на английском).
- Understanding Success Criterion 3.3.2: Labels or Instructions | WAI | W3C - критерий 3.3.2, уровень A (на английском; страница обновлена 9 марта 2026 года).
- Understanding Success Criterion 3.3.1: Error Identification | WAI | W3C - критерий 3.3.1, уровень A (на английском; страница обновлена 12 июня 2026 года).
- Forms Tutorial | Web Accessibility Initiative (WAI) | W3C - руководство по доступным формам (на английском; страница обновлена 27 марта 2026 года).
- Статья 5. Принципы обработки персональных данных \ КонсультантПлюс - 152-ФЗ, ч.4 и ч.5 ст.5, ред. от 26.07.2026.
- Согласие на обработку персональных данных на сайте: ст.9 152-ФЗ - BITSPARK - статья раздела о согласии.
- Политика конфиденциальности для сайта: что требует 152-ФЗ - BITSPARK - статья раздела о политике.
- Капча на сайте: что это, какой бывает и нужна ли она форме - BITSPARK - статья раздела о капче.
- Всплывающее окно на сайте: как называется и что проверить - BITSPARK - статья раздела о всплывающем окне.
- Адаптивный сайт: что это и как проверить адаптив до приёмки - BITSPARK - статья раздела об адаптиве.
- BITSPARK - Digital studio - услуги студии, цены и шаги работы.
Обсудить проект в Telegram: t.me/billioniks