Missing form label что значит

Empty or Missing Form Label

Did an “Empty Form Label” or “Missing Form Label” error appear in an Accessibility Checker audit of one of your WordPress posts or pages? Read on below for an explanation of these errors, how they impact your website’s accessibility, and how to fix them.

Table of Contents

About the Empty Form Label and Missing Form Label Errors

What is a form label?

A form label is an HTML element used in forms to describe what the the various fields and controls in the form are for.

Regardless of the type of field you’re using, whether it is radio buttons, checkboxes, dropdown selects, or text fields, there must be a element properly associated with the form control, either implicitly or explicitly. Labels can be visible above each field as shown in the following screenshot of the top of our Free Risk Assessment Form:

Or, labels can also be located below, next to, or even after each field, as shown in this screenshot of part of an email opt-in form:

Regardless of placement, properly formatted labels are necessary because they ensure that users of assistive technology like screen readers will know what to enter into each field. They also can provide a larger clickable area which helps people with lower dexterity, including the elderly, to move more easily through a form with both a mouse or on a touchscreen like a mobile phone.

How are labels associated with fields?

For most WordPress users, labels are added to fields as you build your form in whatever WordPress forms plugin you’re using. Usually, all you have to do is fill in a field on the form edit screen, like in this screenshot which shows the editing experience for a text field within the Gravity Forms plugin:

Once you have filled in the “Field Label” section for each field, your form plugin should display the label automatically.

If you’re hand-coding forms or pasting form code from elsewhere on the web, you want to make sure that you’re labeling controls appropriately for accessibility with tags that use the for=»» attribute to match the label with the . The HTML code for associating labels explicitly with form controls looks like this:

The above example shows the HTML code for the subscribe form image that was embedded earlier on the page containing a name field and subscribe checkbox. Note that the labels can either preceded or follow their associated input.

There are several other ways that you can label form controls in an accessible manner. These methods are outlined in W3C’s Web Accessibility Tutorials “Labeling Controls” if you would like to learn more.

What qualifies as an empty form label?

An Empty Form Label error is triggered when a tag is present in your form and associated with an input (form field), but does not contain any text. Here is an example of an empty label in code:

Form labels are also considered empty if they wrap around the tag and contain no other text like this:

What qualifies as a missing form label?

A Missing Form Label error is triggered when an (form field) is present in your form and but is not associated with a element. This could look like this, where the label is present but is missing a for=»» attribute to connect it to the applicable field:

Or there could be no label present at all and only an tag.

How does Accessibility Checker test for empty and missing form labels?

While auditing your page or post content, Accessibility Checker will look at all tags and check to see if they are associated with , either by using “for” or “id” attributes, or by wrapping the label tag around the field . If there is an input present on the page that does not have an associated label, then a Missing Form Label error will be flagged.

For all tags that have a corresponding , Accessibility Checker looks to see if there is text contained within the tag. If there is no text or if there are only spaces, an Empty Form Label error will be flagged.

Impact on Accessibility

Why are form labels important?

Form labels are necessary so that users of assistive technology will know what the field is for and will be able to successfully fill out the form.

Without form labels, a screen reader will only read out the type of the field. For a text field that has an empty label, a screen reader might say only “Edit,” “Edit has auto complete,” or “Edit text, blank.” PowerMapper has a useful page on their website where they have documented what the major screen readers say when presented with an empty form label; if you go to that page you can hear a recording of what different screen readers in different browsers say when encountering empty labels.

It goes without saying that if a person does not know what is supposed to be filled into each field, they cannot possibly complete the form.

Approximately 12 million people 40 years and over in the United States have vision impairment, including 1 million who are blind, 3 million who have vision impairment after correction, and 8 million who have vision impairment due to uncorrected refractive error.

If visitors to your website cannot fill out forms on your website, they will not be able to inquire about services, make a purchase, contact you, sign up for your newsletter, or take any other actions that require a form fill. Not only does this limit their ability to fully engage with your website but it also reduces the possible audience for your products and/or services and will lower your conversion rate. Form labels are just as good for your business as they are for your website’s visitors.

Placeholder text is not a substitute for empty or missing form labels

Designers commonly design forms for websites that do not show the form labels and instead use placeholder text within the field to try and denote what the field is for. This is especially common for short forms with few fields like email newsletter signup forms, but we’ve seen this technique used even in very long forms.

Example of a common email newsletter subscription section on a website without a visible form label on the email address field and using placeholder text instead.

Though we understand the design value of a cleaner more minimalistic appearance it is incorrect to use placeholder text as a replacement for labels. Screen readers and other assistive technologies do not treat placeholder text as labels, which means that they do not always read or announce the presence of placeholder text. Placeholder text is not broadly supported across all assistive technologies and many older browsers do not display placeholder text at all, which means that both sighted and blind users could be left without knowing what the field is for if there is not also a label for that field.

In addition to not being universally supported by assistive technologies, placeholder text also is bad for accessibility because:

1. Placeholder text is meant to provide an example of the expected input in the field, not to describe the field’s name. Appropriate placeholder text for an email address field is “name@website.com” not the words “email address.” Adding the field’s name rather than an example could be confusing to users.
2. Placeholder text disappears as text is typed or entered in the fields. This causes a number of problems as a result:
   1. If there are no form labels present and the placeholder text has disappeared, the user will have no way of confirming that they have properly filled out the form before hitting submit.
   2. Disappearing placeholder text is especially frustrating if using an autocomplete function in the browser filled multiple fields automatically – in this case, the user would have to delete the autocompleted information in other to ensure it was filled out correctly and then manually retype the answers.
   3. If an error occurs on the form, the user will not know how to fix the problem.
3. Placeholder text is usually displayed with lower color contrast than text provided by users and may not meet color contrast standards for accessibility, making it hard for elderly or visually impaired users to read.
4. Sometimes placeholders do not disappear when users move their input focus into the field. If the placeholder text remains in the field as editable text, the user will have to manually select and delete it which creates extra work for them.

These four accessibility problems impact all visitors to your website, not just users with disabilities.

The Nielsen Norman Group, experts in research-based user experience, has an excellent article, “Placeholders in Form Fields Are Harmful,” which provides additional information about why you should never use placeholder text because the resulting loss in useability will also decrease conversion rates. You can also see examples of problems caused by placeholders in Smashing Magazine’s “Don’t Use The Placeholder Attribute” article.

What if I really want to hide my form labels for aesthetic reasons?

Unfortunately, there is no way to hide form labels and have an accessible form. There are tutorials on the web for making hidden form labels available to screen readers, which does make them accessible to blind and visually impaired users of screen readers, however this does not resolve the issues described above about how missing form labels can negatively impact sighted users.

All people need to be able to easily understand how to fill in the forms on your website and visible labels are necessary for that. If you’re hoping to have a more modern or minimalistic design, there are still great ways to still accomplish that aesthetic without removing form labels.

Relevant WCAG 2.1 Success Criteria

1.1.1 Non-text Content – Level A

If non-text content is a control or accepts user input, then it has a name that describes its purpose.

1.3.1 Info and Relationships – Level A

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

2.4.6 Headings and Labels – Level AA

Headings and labels describe topic or purpose.

3.3.2 Labels or Instructions – Level A

Labels or instructions are provided when content requires user input.

4.1.2 Name, Role, Value – Level A

For all user interface components (including but not limited to: form elements, links, and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

How to Fix an Empty or Missing Form Label Error

What to do (in short)

To fix empty or missing form label errors, you’ll need to determine how the field and form were created and then either add text to your existing field label or add field labels if they are missing completely.

How to find and fix Empty Form Label and Missing Form Label errors in WordPress

For any pages or posts that have either an Empty Form Label error or a Missing Form Label error in the WordPress editor, you can open the details tab in the Accessibility Checker meta box, then expand the applicable error to see a list of code that caused the error to appear.

The above screenshot shows an example of a form label that has been flagged as empty. This particular example is a label within a WP Forms form. Ideally you only have one form plugin on your website and one form per post or page, but if you have multiple and are not sure what label this is referencing you can look at the code for clues.

In this code snippet, we can clearly see “wpforms” in the label’s class which tells us this label is part of a form built in WP Forms. The for attribute provides is with the unquie field ID which is sometimes helpful in finding the specific field as some plugins display the field ID in their backend form builder. WP Forms does not, unfortunately, but you likely don’t actually need to know which field this is by ID as it should be visually obvious to you when looking at your form if there are labels missing.

If you see a missing or empty form label error in Accessibility Checker, the best course of action is to open your form builder and add labels to all fields in every form or ensure that any options within the form settings to hide labels are unselected.

What if your forms have missing or empty labels you cannot find or fix?

Depending upon how you have added forms to your WordPress website, it possible you may encounter empty or missing form labels that you cannot correct. This is less likely to happen with a form building plugin, but more likely to happen if you have embedded code that includes a form from a third-party source or if there is a minimally (or not at all) configurable form included in a different type of WordPress plugin, such as a user registration or membership plugin, an email newsletter plugin, or e-commerce plugin.

In that case, you may need to choose a different plugin to use on your website or will need to contact the provider of the code you have used for assistance. If you encounter accessibility errors that are caused by a third-party plugin you cannot control, please reference “What to do if a Plugin You’re Using has Accessibility Errors” for ideas on how to proceed.

Источник

Валидация форм на стороне клиента

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

Начальные требования:	Владение компьютером, достаточное понимание HTML, CSS, и JavaScript.
Цель:	Понять, что такое валидация на стороне клиента, почему это важно и как применять различные техники для её реализации.

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

Однако, не следует рассматривать валидацию на стороне клиента как достаточную меру безопасности! Любые данные, отправляемые через форму, необходимо дополнительно проверять на безопасность и на стороне сервера, поскольку валидацию на стороне клиента достаточно просто обойти и она может не остановить злоумышленников. Чтобы лучше понимать потенциальные угрозы, рекомендуем ознакомиться с разделом Безопасность вебсайтов; валидация на стороне сервера выходит за рамки этого модуля, но о ней следует помнить.

Что такое валидация формы?

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

• «Обязательное поле» (Вы не можете оставить поле пустым).
• «Пожалуйста, введите номер телефона в формате xxx-xxxx» (Чтобы данные считались корректными, их необходимо указать в определённом формате).
• «Пожалуйста, введите корректный email-адрес» (вы ввели данные в неправильном формате).
• «Длина пароля должна быть от 8 до 30 символов и включать одну заглавную букву, один символ, и одну цифру.» (Требования к формату данных достаточно конкретные).

Это называется валидацией формы. По мере ввода, браузер и/или сервер проверяют данные, чтобы определить, соответствуют ли они требуемому формату. Валидация, выполняемая в браузере, называется валидацией на стороне клиента, а выполняемая на сервере — валидацией на стороне сервера. В этом разделе мы сосредоточимся на валидации, выполняемой на стороне клиента.

Если формат корректен, приложение позволяет отправить данные на сервер и (обычно) сохранить в базу данных; в противном случае выводится сообщение с описанием того, что нужно исправить, позволяя ввести данные снова.

Мы хотим максимально упростить заполнение веб-форм. Тогда почему мы настаиваем валидации данных? На это есть три основные причины:

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

Предупреждение:: Никогда не доверяйте данным, передаваемым на сервер клиентской программой. Даже если ваша форма правильно валидируется и не допустит введение потенциально вредоносных данных на стороне клиента, злоумышленники по-прежнему могут изменить сетевой запрос.

Типы валидации на стороне клиента

Существует два типа валидации на стороне клиента, с которыми вы столкнётесь в Интернете:

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

Использование встроенной валидации форм

Одной из самых важных функций элементов форм HTML5 является способность валидировать бóльшую часть пользовательских данных без использования JavaScript. Это выполняется с помощью атрибутов валидации у элементов формы. Многие из них мы уже рассмотрели в этом курсе:

• required : Определяет, что для отправки формы данное поле предварительно должно быть заполнено.
• minlength и maxlength : Задаёт минимальную и максимальную длину текстовых данных (строк)
• min и max : Задаёт минимальное и максимальное значение для поля, расчитанного на числовой тип данных
• type : Определяет тип данных, на который рассчитано поле: число, email-адрес или какой-то другой предустановленный тип
• pattern : С помощью регулярного выражения, определяет шаблон, которому должны соответствовать вводимые данные.

Если данные, введённые в поле формы, соответствуют правилам перечисленных выше атрибутов, они считаются валидными, если нет — не валидными

Когда элемент валиден, справедливы следующие утверждения:

• Элемент соответствует CSS-псевдоклассу :valid , позволяющему стилизовать только валидные элементы.
• Если пользователь пытается отправить данные, браузер отправит форму при условии, что ничто другое (например, JavaScript) не помешает ему это сделать

Когда элемент не валиден, справедливы следующие утверждения:

• Элемент соответствует CSS-псевдоклассу :invalid или, в зависимости от ошибки, другим псевдоклассам (например, :out-of-range ), которые позволяют применять определённые стили к элементам, не являющимся валидными.
• Если пользователь пытается отправить данные, браузер заблокирует форму и выведет сообщение об ошибке.

Примечание: Существует ошибки, которые не позволяют отправлять форму, в частности badInput , patternMismatch , rangeOverflow или rangeUnderflow , stepMismatch , tooLong или tooShort , typeMismatch , valueMissing , или customError .

Примеры встроенной валидации форм

В этом разделе мы протестируем некоторые из атрибутов, которые обсуждали выше.

Простой начальный файл

Давайте начнём с простого примера: поле, позволяющее указать своё предпочтение — банан или вишня. Этот пример включает обычное текстовое поле , связанный с ним элемент и кнопку отправки формы . Исходный код можно найти на GitHub по адресу fruit-start.html, а ниже приведён рабочий пример.

Для начала скопируйте файл fruit-start.html в новую папку на вашем жёстком диске.

Атрибут required

Самым простым в HTML5-валидации является атрибут required . Добавьте его к элементу, чтобы сделать заполнение обязательным. Элемент с данным атрибутом соответствует CSS-псевдоклассу :required , а если поле ввода пустое, вместо отправки формы отобразится сообщение об ошибке. Пока поле пустое, оно также будет соответствовать CSS-псевдоклассу :invalid .

Добавьте к полю атрибут required , как показано ниже.

Обратите внимание на CSS, который включён в файл примера:

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

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-validation.html (отдельно можно найти исходный код.)

Попробуйте отправить форму без введения значения. Обратите внимание, что не валидное поле получает фокус, появляется сообщение об ошибке («Заполните это поле») и блокируется отправка формы.

Наличие атрибута required у любого элемента, который его поддерживает, означает, что элемент соответствует CSS-псевдоклассу :required , независимо от того, имеет он значение или нет. Если элемент не содержит значение, он будет соответствовать псевдоклассу :invalid .

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

Валидация с помощью регулярного выражения

Ещё одной полезной функцией валидации является атрибут pattern , который в виде значения принимает Регулярное выражение. Регулярное выражение (regex) — это шаблон, который может быть использован для сопоставления набора символов в текстовой строке, поэтому они идеально подходят для валидации формы и используются для множества других целей в JavaScript.

Регулярные выражения достаточно сложны и мы не подем подробно рассматривать эту тему в данной статье. Ниже приведены несколько примеров, чтобы дать вам представление о том, как они работают.

• a — Соответствует одному символу a (не b , не aa , и так далее).
• abc — Соответствует символу a , за которой следует b , за которой следует c .
• ab?c — Соответствует символу a , за которым опционально может следовать b , за которым следует c . ( ac или abc )
• ab*c — Соответствует символу a , за которым опционально может следовать любое количество символов b , за которыми следует c . ( ac , abc , abbbbbc , и так далее).
• a|b — Соответствует символу a или b .
• abc|xyz — Соответствует в точности abc или в точности xyz (но не abcxyz или a или y , и так далее).

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

Давайте рассмотрим пример. Добавьте в атрибут pattern следующий шаблон:

Это даёт нам следующее обновление — опробуйте его:

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-pattern.html (исходный код.)

В этом примере элемент принимает одно из четырёх возможных значений: строку «banana», «Banana», «cherry», или «Cherry». Регулярные выражения чувствительны к регистру, но с помощью шаблона «Aa», вложенного в квадратные скобки, мы сделали поддержку написания слова как с большой, так и с маленькой буквы.

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

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

Примечание: Некоторым типам элементов для валидации с помощью регулярного выражения не требуется атрибут pattern . Например, поле с типом email валидирует значение по шаблону одного email-адреса или, если присутствует атрибут multiple , шаблону списка email-адресов, разделённых запятыми.

Примечание: Элемент

(en-US) не поддерживает атрибут pattern .

Ограничение длины вводимых значений

Можно ограничить максимально допустимое количество символов для текстовых полей или

(en-US) используя атрибуты minlength и maxlength . Поле будет не валидным, если количество символов его содержимого будет меньше minlength или больше maxlength .

Зачастую браузеры не позволяют пользователям вводить в текстовое поле значение, длина которого превышает максимально допустимую. Можно существенно повысить удобство использования, если помимо ограничения в атрибуте maxlength добавить доступный индикатор, отображающий текущее и максимально допустимое количество символов, что даст пользователю возможность уместить содержимое в заданные рамки. Хорошим примером является окно написания твита в Twitter. Для реализации такого функционала можно использовать JavaScript, включая решения, использующие maxlength .

Ограничение допустимых значений

В полях, предназначеннх для ввода чисел (например, ), диапазон допустимых значений можно определить с помощью атрибутов min и max . Если поле содержит значение за пределами данного диапазона, оно будет не валидным.

Давайте рассмотрим другой пример. Создайте новую копию файла fruit-start.html.

Содержимое элемента замените на:

• Здесь мы в полю с типом text атрибутам minlength и maxlength , задали одинаковое значение 6, что соответствует количеству символов в словах banana и cherry.
• В поле с типом number атрибуту min мы задали значение 1, а атрибуту max значение 10. При вводе чисел за пределами данного диапазона, поле будет становиться не валидным; с помощью стрелок увеличения/уменьшения пользователи не смогут выйти за границы диапазона. Текущее поле не является обязательным для заполнения, поэтому даже после очистки будет оставаться валидным.

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-length.html (исходный код.)

Примечание: (и другие типы, такие как range и date ) могут также принимать атрибут step , который задаёт шаг увеличения или уменьшения значения при использовании кнопок вверх и вниз. В примере выше мы явно не указывали атрибут step , поэтому он получает значение по умолчанию, равное 1 . Это значит, что дробные числа, такие как 3.2, будут не валидными.

Полный пример

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

И немного CSS для стилизации HTML:

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

Примечание: Рабочий пример можно найти на GitHub по адресу full-example.html (исходный код.)

Валидация форм с помощью JavaScript

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

Constraint Validation API

Большинство браузеров поддерживают Constraint Validation API, который состоит из набора свойств и методов, доступных на DOM-интерфейсах следующих элементов форм:

Для перечисленных выше элементов Constraint Validation API делает доступными следующие свойства.

• validationMessage : Возвращает локализованное сообщение, описывающее ограничения валидации (если таковые имеются), которым не удовлетворяет определённый элемент. Если элемент не участвует в валидации ( willValidate установлено в false ) или значение элемента удовлетворяет установленным ограничениям (является валидным), будет возвращена пустая строка.
• validity : Возвращает объект ValidityState , который содержит несколько свойств, описывающих состояние валидности элемента. Подробное описание всех свойств доступности можно найти на странице справочника ValidityState ; ниже приведён список наиболее используемых:
  • patternMismatch : Возвращает true , если значение не соответствует шаблону, указанному в атрибуте pattern , и false если соответствует. Если true, элемент соответствует CSS-псевдоклассу :invalid .
  • tooLong : Возвращает true , если значение длиннее максимальной длины, указанной в атрибуте maxlength , и false если оно короче или равно ей. Если true, элемент соответствует CSS-псевдоклассу :invalid .
  • tooShort : Возвращает true , если значение короче минимальной длины, указанной в атрибуте minlength , и false если оно длинее или равно ей. Если true, элемент соответствует CSS-псевдоклассу :invalid .
  • rangeOverflow : Возвращает true , если значение больше указанного в атрибуте max максимума, и false если меньше или равно ему. Если true, элемент соответствует CSS-псевдоклассам :invalid и :out-of-range
  • rangeUnderflow : Возвращает true , если значение меньше указанного в атрибуте min , и false если больше или равно ему. Если true, элемент соответствует CSS-псевдоклассу :invalid и :out-of-range .
  • typeMismatch : Возвращает true , если значение не соответствует требуемому синтаксису (когда для type задано значение email или url ), и false если синтаксис корректный. Если true , элемент соответствует CSS-псевдоклассу :invalid .
  • valid : Возвращает true , если элемент соответствует всем ограничениям валидации — следовательно, считается валидным, и false если не соответствует какому-то ограничению. Если true, элемент соответствует CSS-псевдоклассу :valid ; иначе :invalid .
  • valueMissing : Возвращает true , если у элемента есть атрибут required , но не введено значенение, иначе возвращает false . Если true, элемент соответствует CSS-псевдоклассу :invalid .
• willValidate : Возвращает true , если элемент будет участвовать в валидации при отправке формы; иначе возвращает false .

Также для перечисленных выше элементов Constraint Validation API делает доступными следующие методы.

• checkValidity() : Возвращает true , если значение элемента проходит валидацию, иначе возвращает false . Если элемент не валиден, данный метод также запускает на нём событие invalid .
• setCustomValidity(message) : Позволяет добавить в элемент кастомное сообщение об ошибке; при этом элемент будет считаться не валидным и отобразится указанная ошибка. Это позволяет использовать JavaScript-код, чтобы представить ошибку валидации иначе, чем это предусмотрено стандартными средствами валидации HTML5. При сообщении об ошибке данное кастомное сообщение показывается пользователю.

Реализация кастомного сообщения об ошибке

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

У этих автоматических сообщений есть два недостатка:

• Не существует стандартного способа их стилизации с помощью CSS.
• Они зависят от локали браузера, из-за чего страница может быть на одном языке, а сообщение об ошибке — на другом, как показано на следующем скриншоте браузера Firefox.

Настройка таких сообщений об ошибках является одной из наиболее распространённых причин использования Constraint Validation API. Давайте рассмотрим простой пример, как это делается.

Начнём с простого HTML (Не стесняйтесь поместить это в пустой HTML-файл. Вы можете взять за основу свежую копию fruit-start.html, если хотите):

Добавьте на страницу следующий JavaScript:

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

В коде обработчика мы проверяем, возвращает ли свойство поля email validity.typeMismatch значение true , что значит, что содержащееся значение не соответствует шаблону корректного email-адреса. Если возвращается true , мы вызываем метод setCustomValidity() (en-US) с кастомным сообщением. Это делает поле не валидным, поэтому попытка отправить форму приводит к ошибке и отображается кастомное сообщение об ошибке.

Если свойство validity.typeMismatch возвращает false , мы вызываем метод setCustomValidity() с пустой строкой. Это делает поле валидным, поэтому форма может быть успешно отправлена.

Попробовать пример можно ниже:

Примечание:: Данный пример можно найти на GitHub по адресу custom-error-message.html (отдельно можно найти исходный код.)

Более подробный пример

Теперь, когда мы разобрали простой пример, давайте посмотрим, как можно использовать данный API для создания более сложной валидацию.

Во-первых, HTML. Опять же, не стесняйтесь писать его вместе с нами:

Эта простая форма использует атрибут novalidate , который отключает автоматическую валидацию браузером; это позволяет нашему скрипту взять управление валидацией на себя. Однако, это не отменяет поддержку Constraint Validation API или псевдоклассов, таких как :valid или ему подобных. Это значит, что хотя браузер автоматически и не проверяет валидность формы перед отправкой данных, вы можете сделать это самостоятельно и соответствующим образом стилизовать форму.

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

Мы хотим показывать сообщение об ошибке внутри элемента . Данному элементу задан атрибут aria-live , чтобы гарантировать, что наше кастомное сообщение об ошибке будет доступно всем, включая пользователей скринридеров.

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

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

Теперь давайте рассмотрим JavaScript, который реализует кастомную валидацию.

Комментарии объясняют логику хорошо, но кратко:

• При каждом изменении значения поля, мы производим его валидацию. Если данные валидны, удаляем ранее отображаемые сообщения об ошибках. Если данные не валдны, запускаем showError() , чтобы показать соответствующую ошибку.
• При каждой попытке отправить форму, мы снова производим валидацию. Если данные валидны, позволяем отправку формы. Если данные не валидны, запускам showError() , чтобы показать соответствующее сообщение об ошибке, а также предотвращаем отправку формы с помощью preventDefault() .
• Функция showError() использует различные свойства объекта validity поля ввода, чтобы определить тип ошибки и отобразить соответсвущее сообщение.

Примечание: Рабочий пример можно найти на GitHub по адресу detailed-custom-validation.html (отдельно можно найти исходный код.)

Constraint Validation API явяется мощным инструментом валидации форм, позволяющим получить контроль над пользовательским интерфейсом, существенно превосходящий возможности HTML и CSS.

Примечание: Для получения дополнительной информации смотрите руководства Constraint validation guide и Constraint Validation API.

Проверка форм без встроенного API

В некоторых случаях, например, при необходимости поддержки устаревших браузеров или кастомных элементов формы, вы не сможете или не захотите использовать Constraint Validation API. Вы по-прежнему сможете использовать JavaScript для валидации форм, но для этого всё нужно будет писать самостоятельно.

Для создания своего валидатора формы, задайте себе несколько вопросов:

Какую тип валидации я должен выполнить? Вам нужно определить, как данные будут валидироваться: с помощью строковых операций, преобразования типов, регулярных выражений и так далее. Решать вам. Что мне нужно делать, если форма не проходит валидацию? Это явно вопрос пользовательского интерфейса. Вы должны решить, как в этом случае будет себя вести форма. Будет ли она в любом случае отправлять данные? Нужно ли выделять поля, содержащие ошибки? Нужно ли отображать сообщения об ошибках? Как я могу помочь пользователю исправить не валидные данные? Чтобы снизить степень разочарования пользователя, очень важно предоставить как можно больше полезной информации, чтобы помочь исправить данные, которые он ввёл неправильно. Нужно предложить правильные варианты, чтобы дать понять, какие данные вы ожидаете от него получить, а также сообщение, чётко описывающее ошибку. Если вы хотите подробнее ознакомиться с требованиями к пользовательскому интрефейсу при валидации форм, предлагаем прочитать следующие статьи:

• SmashingMagazine: Form-Field Validation: The Errors-Only Approach
• SmashingMagazine: Web Form Validation: Best Practices and Tutorials
• WebFX: 10 Tips for Optimizing Web Form Submission Usability
• A List Apart: Inline Validation in Web Forms

Пример без использования Constraint Validation API

Чтобы проиллюстрировать это дальше приводится упрощённая версия предыдущего примера, которая работает с устаревшими браузерами.

HTML почти тот такой же; мы только удалили функционал валидации HTML5.

CSS также не требует особых изменений; мы только заменили CSS-псевдокласс :invalid на реальный класс и не использовали селектор по атрибутам, так как он не работает в Internet Explorer 6.

Существенно изменился только JavaScript-код, который теперь должен выполнять гораздо больше работы.

Результат выглядит следующим образом:

Как вы можете видеть, сделать собственную валидацию не так уж и сложно. Сложность состоит лишь в том, чтобы сделать его кроссплатформенным и работающим с любой формой, которую можно создать. Для проверки формы доступно множество библиотек, например Validate.js.

Проверьте свои навыки!

Вы дошли до конца этой статьи, но можете ли вы вспомнить самую важную информацию? Вы можете найти дополнительные тесты, чтобы убедиться, что вы сохранили эту информацию, прежде чем двигаться дальше — Test your skills: Form validation.

Заключение

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

• Отображать явные сообщения об ошибках.
• Снисходительно относиться к формату ввода.
• Указывать, где именно возникла ошибка. Особенно в больших формах.

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

Источник