Валидация

Validating the data

Now that our users get prompted to complete required fields, we need to make sure that the data they submit is in the format we require.

We’ll want the ‘Name’ field to be submitted in the format ‘Firstname Lastname’, and to only contain letters and a space (NB in real world scenarios, you might need to take account of other locales – this example has been kept simple deliberately). We can achieve this by adding a pattern attribute to the ‘Name’ field, setting it’s value to the regular expression we want the data to be compared against:

When using the pattern attribute, the and for the start and end of the regular expression are implied and don’t need to be included.

You can help the user by including a title attribute that tells them the format you require:

The text in the title attribute is then appended to the built-in validation message:

Note that some screen reader / browser combinations might lead to the title attribute being read out in addition to the aria-describedby text, so watch out for this e.g. I found that using NVDA with IE10 caused the title attribute and the aria-describedby element’s text to be read out, but using NVDA with Chrome and Firefox didn’t exhibit this behaviour. Only the aria-describedby text was read. Later on we’ll revisit this and show you one solution using CSS3.

Develop utility functions

Before validating the form, you can develop some reusable utility functions to check if:

• A field is required.
• The length of a field is between min and max.
• The email is in a valid format.
• The password is strong.

The following function returns true if the input argument is empty:

The following function returns false if the argument is not between the and argument:

To check if a password is strong, which match a specified pattern, you’ll also use a regular expression:

The following table illustrates the meaning of each part of the regular expression used to validate the password:

Password RegEx	Meaning
^	The password starts
(?=.*)	The password must contain at least one lowercase character
(?=.*)	The password must contain at least one uppercase character
(?=.*)	The password must contain at least one number
(?=.*)	The password must contain at least one special character.
(?=.{8,})	The password must be eight characters or longer

Validating required input

Forms frequently include required input that needs to be clearly identified using labels. Also, the attribute can be added to form controls, to programmatically indicate that they are required. Most current web browsers support this attribute and will communicate missing required input to the user, using standard web browser dialog mechanisms. These dialogs are expected to respect the settings and preferences of the user in the web browser (and operating system), such as default font-size, colors, and language.

In the example below, the attribute is added to the input field. If your web browser supports HTML5, it will not allow you to submit the form without entering text into the input field. Instead, it will display a message that is generated by the web browser itself.

Note that the label also displays “(required)”, to inform users that don’t use assistive technology or use older web browsers that do not support the HTML5 attribute.

The ‘required’ attribute

The simplest change you can make to your forms is to mark a text
input field as ‘required’:

This informs the (HTML5-aware) web browser that the field is to be
considered mandatory. Different browsers may mark the input box in
some way (Firefox 4 Beta adds a red box-shadow by default), display a
warning (Opera) or even prevent the form from being submitted if this
field has no value. Hopefully these behaviours will converge in
future releases.

For these examples we have created our own valid/invalid CSS
formatting to override the browser default. . That’s why you may see something like the following:

Before you type anything into the box a red marker is shown. As
soon as a single character has been entered this changes to a green
marker to indicate that the input is ‘valid’.

Using CSS you can place markers inside or alongside the input box,
or simply use background colours and borders as some browsers do by
default.

The required attribute can also apply to checkboxes
which we’ve covered separately.

Sample styling using images and sprites

As shown above, once you’ve added HTML5 attributes to your form
elements, they can be easily styled using CSS so that each input field
is clearly marked as valid or invalid.

Here you can see the above styles applied to a required input field:

This solution is still more complicated than it needs to be as it
requires two extra images to be loaded. Fortunately, we can assume that
all browsers supporting HTML5 form validation techniques will also
support images being replaced in the CSS by ‘Base64 encoded datasets’.

Using a service such as Spritebaker or other techniques, the above style
settings become:

The above code can now be copied directly to your CSS style sheet.
There’s no need to copy any images and, especially if your style-sheets
are gzip-compressed, there will be next to no impact on load times. In
a few minutes you could have your whole website updated.

For the browser-impaired, this is how the required input field will
appear in Safari with either the image or the Data URI
backgrounds:

The same styling can be extended to textarea elements, but
won’t work for checkboxes,
select elements, etc. For those you might want to place the
valid/invalid markers alongside the element or format the input
elements themselves using borders, background colours, etc.

What is form validation

Before submitting data to the server, you should check the data in the web browser to ensure that the submitted data is in the correct format.

To provide quick feedback, you can use JavaScript to validate data. This is called client-side validation.

If you don’t carry the client-side validation, it may cause a bad user experience. In this case, you may feel a noticeable delay because it takes time for the form data to transfer between the web browsers and the server.

Unlike the client-side validation that performs in the web browser, the server-side validation is performed on the server. It’s critical always to implement the server-side validation.

The reason is that client-side validation is quite easy to bypass. Malicious users can disable JavaScript and submit bad data to your server.

In this tutorial, you’re going to focus on the client-side validation only.

Validation by the user

Where possible, users should be able to check their input and correct it if necessary. This is particularly important for actions that are permanent or otherwise critical, but also when data cannot be automatically checked. For example, providing users with the option to check the postal address that they provided can be useful before a purchase is completed.

Require user confirmation

Where possible, require user confirmation for irreversible actions, such as permanent deletion of data. Examples include:

• A CMS allows users to delete comments from the trash folder permanently. When this action is initiated, a dialog box is displayed to the user to confirm the action.

• A banking application requires users to confirm transfer transactions by selecting a checkbox labeled “I have checked that the amount I wish to transfer is correct”.

• A shopping website displays a summary of the order, shipping address, and billing information that the user must confirm before the purchasing transaction is completed and the order is placed.

Provide undo functionality

Where possible, provide mechanisms to undo reversible actions. Examples include:

• A Content Management System (CMS) can delete unwanted comments. Instead of deleting them right away, they are stored in a “trash” folder so that they can be restored.

  

  

  

  

  

  

  

  

  

  

• Previous:
  Form Instructions

• Next:
  User Notification

Проверка данных формы с помощью PHP

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

Теперь код можно безопасно отображать на странице или в электронном письме.

Сдедующим шагом применим ещё две функции:

1. Из данных, вводимых пользователем (с помощью PHP функции ) удалим ненужные символы (лишние пробелы, табуляции, переходы на новую строку)
2. C помощью PHP функции из данных, вводимых пользователем, удалим обратную косую черту (\)

И, наконец, создадим функцию, которая будет выполнять все рассмтренные проверки за нас, что намного удобнее, чем писать один и тот же код снова и снова. Назовем функцию test_input().

В следующем примере будем проверять каждую переменную с помощью функции test_input():

Пример

Попробуй сам

В начале сценария мы проверяем, используя суперглобальную переменную $ _SERVER , была ли отправлена ​​форма. Если для запроса страницы был использован метод POST, значит, форма была отправлена ​​— и ее нужно проверить. Если форма не была отправлена — пропускаем проверку и отображаем пустую форму.

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

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

Назад
Вперёд

2012: W3C представил окончательные спецификации HTML5

Глобальный консорциум по веб-стандартизации W3C объявил в декабре 2012 года о завершении процесса формирования спецификаций HTML5. Новые спецификации признаны целостными и стабильными, благодаря чему разработчики и представители бизнеса теперь официально могут рассматривать их как стандарт для «реализации и планирования» своих веб-проектов.

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

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

Консорциум планирует разработать тесты на корректность реализации стандартов в существующем ПО и наладить работу с сообществом по проведению данных тестов. Тестирование позволит W3C убедиться, что все десктопные, мобильные и веб-приложения, применяющие HTML5 — браузеры, системы создания и управления контентом, почтовые клиенты, серверные приложения — одинаково корректно внедрили предложенные спецификации.

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

Согласно списку на сайте W3C, в стандарт HTML5 войдут следующие документы: описание базового API; описание языка разметки HTML (синтаксис, атрибуты, типы данных); список отличий HTML5 от HTML4; описание средств обеспечения доступности для людей с ограниченными возможностями, а также ряд документов, охватывающих специфические аспекты HTML. Так, отдельные документы будут посвящены механизму Microdata, позволяющему авторам добавлять на свои веб-страницы элементы, для которых нет соответствующих HTML-тэгов или атрибутов, а также XML-совместимой разметке XHTML и возможностям тэга alt.

Кроме того, консорциум выпускает документ, содержащий отдельную спецификацию для Canvas 2D — элемента HTML5, позволяющего создавать внутри HTML-документа векторные изображения при помощи JavaScript.

Одновременно с завершением работы по стандартизации HTML5 началась подготовка будущей серии стандартов HTML, сообщает W3C. В частности, уже готовы первые черновики HTML 5.1 и HTML Canvas 2D Context, Level 2. В новейшей версии HTML5 будет введен принципиально новый элемент «main», предназначенный для выделения основного значимого контента страницы. Черновые спецификации для этого крупного нововведения уже опубликованы на сайте W3C.

Всего за несколько дней до выпуска HTML5 консорциум наконец-то представил еще один открытый веб-стандарт — стандарт веб-шрифтов WOFF (Web Open Font Format). WOFF представляет собой открытую спецификацию контейнера для структуры SFNT, использующейся в шрифтах TrueType и OpenType, предназначенную для реализации в Web.

Первый черновик WOFF был представлен в 2010 году, и реализации стандарта уже существуют во всех крупных десктопных браузерах, включая Chrome, Firefox, Safari и Internet Explorer. Мобильные браузеры в этом плане отстают — новый стандарт не успели внедрить ни в предустановленный браузер Android, ни в Opera Mini.

Using CSS to highlight required fields and invalid data

In tandem with the new input types and attributes provided by HTML5, CSS3 gives us some new pseudo-classes we can use to provide visual clues to the user as to which form fields are required, which are optional, and which contain validation errors.

Required fields can use the pseudo-class:

Optional fields can use the pseudo-class:

The success or failure of form validation can be signified to the user through the use of the , , , and pseudo-classes:

Remember earlier when I mentioned certain screen reader / browser combinations can lead to the title attribute being read aloud in addition to the element’s text? Well, one way around this is to remove the title attribute from the input element, and make use of the CSS3 pseudo class to show the text:

Now, in addition to showing the help text when the input field receives focus, we’ll also show the help text when the input field’s value is invalid.

After making all these changes our HTML now looks like this:

2010: Microsoft запускает альтернативу W3C — HTML5 Labs

Корпорация Microsoft анонсировала в декабре 2010 года запуск нового проекта под названием HTML5 Labs, который должен собрать различные разработки прототипов или неутвержденных версий спецификаций веб-стандартов. Проект является альтернативным по отношению к деятельности консорциума W3C и ориентирован на поддержку HTML5 в веб-браузере Microsoft Internet Explorer 9. В нем уже описаны два прототипа – разработки IndexedDB (реализация системы хранения больших объемов структурированных данных (закладок, писем и т.п.) в виде базы данных с возможностью быстрого поиска) и WebSockets (замена системы обмена данными по протоколам в виде единого транспортного сокета TCP-протокола). Тем не менее пока Microsoft не считает их готовыми настолько, чтобы применить в IE9. Однако корпорация не говорит о «мертворожденности» этих стандартов и предлагает разработчикам улучшить их или создать другие решения в контексте развития HTML5.

Консорциум World Wide Web Consortium объявил в октябре 2012 года о планах, согласно которым окончательная версия стандарта HTML5 будет утверждена к 2014 году, а HTML 5.1 — к 2016-му.

Чтобы избежать проблем прошлого, теперь HTML решено развивать более модульно, этим и обусловлено решение сразу приступить к созданию версии 5.1. Изначально в HTML5 хотели включить ряд элементов, сейчас ставших отдельными спецификациями, — Web Storage, Web Workers и WebSocket Protocol. Но теперь все нестабильные компоненты решено вынести в отдельную версию HTML 5.1. Это позволит W3C сосредоточиться на повышении стабильности и межбраузерной интероперабельности остальных компонентов HTML 5.

W3C будет непросто достичь намеченных целей: в это время согласно сайту коонсорциума, в HTML5 десять нерешенных проблем, 300 ошибок и 11 особенностей, получивших формальные возражения разработчиков.

Build the HTML form

First, open the file and enter the following code:

In this HTML file, we place the file in the section and file in the body section before the closing tag.

Second, add the following HTML markup to create the signup form. The final index.html file will look like the following:

The notable thing about the signup form is that each field is wrapped in a with the class .

Each form field has three elements:

• A label
• An input field
• A element

You’ll use the tag to show the error message to the users.

If an input field isn’t valid, we’ll make its border color red by adding the class to the element. It’ll look like this:

If the value of an input field is valid, then we’ll make its border color green by adding the class to the element as follows:

Check out the style.css for details of the and classes.

New text INPUT types

On the iPhone/iPad the different input types are associated with
different keyboards, making it easier for people to complete your
online forms. In other web browsers they can be used in combination
with the required attribute to limit or give advice on
allowable input values.

INPUT type=»email»

Note that for this example we’ve made use of another HTML5
attribute placeholder which lets us display a prompt or
instructions inside the field — something that previously had to be
implemented using messy onfocus and onblur JavaScript
events.

The above code displays an input box as follows:

Again, different browsers implement this differently. In Opera it’s
sufficient to enter just *@* for the input to be accepted. In
Safari, Chrome and Firefox you need to enter at least *@-.-.
Obviously neither example is very limiting, but it will prevent people
from entering completely wrong values, such as phone number, strings
with multiple ‘@’s or spaces.

Here is how it appears in Safari (with our CSS formatting to show the
(in)valid state):

INPUT type=»url»

Again, the input box appears as normal:

As mentioned above, we can improve on this by making use of the
pattern attribute which accepts a JavaScript regular
expression. So the code above becomes:

Now our input box will only accept text starting with http:// or https:// and at least one additional character:

If you’re not yet familiar with regular expressions, you really
should make it a priority to learn. For those already
familiar, note that the ^ and $ are already implicit
so the input has to match the entire expression. Pattern modifiers .

INPUT type=»number» and type=»range»

The number and range input types also accept
parameters for min, max and step. In most
cases you can leave out step as it defaults to 1.

Here you see an example including both a number input,
typically displayed as a ‘roller’ and a range input displayed
as a ‘slider’:

As with other HTML5 input types, browsers that don’t recognise the
new options will default to simple text inputs. For that reason it’s a
good idea to include a size for the input box.

The slider option is a bit bizarre in that no values are
displayed, but may be useful for more ‘analog’ inputs. There are some
bugs with the number input in that if you don’t set a
max value, clicking ‘down’ with the input blank will result in
a very large number.

Here is how the two inputs are displayed in Safari:

and in Opera:

They are currently not supported in Firefox 4 Beta.

If you want to restrict the input of a text field to numbers without
having the up/down arrows associated with the input box, you can always
just set the input type to text and use a pattern of
«\d+» (one or more numbers).

INPUT type=»password»

We have a separate article with details on validating passwords using
HTML5, including JavaScript code for customising the browser
generated alert messages.

7 причин перейти на HTML5

HTML5 – новый этап стандартизации веба

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

На самом деле, HTML5 это все тот же язык разметки, понятный браузерам, в который просто добавили дополнительные инструменты для работы с объектами и мультимедиа. По сути это просто новая версия уже давно используемого в Интернете стандарта HTML4, стандартизированного Консорциумом W3C в 1997 году. Таким образом, с точки зрения разработчиков, HTML5 – это не есть что-то принципиально новое, на чем нужно будет учиться работать. Новый стандарт просто расширил возможности разработчиков. Теперь среда HTML5 позволяет реализовать те визуальные «фишки» и опции, которые раньше были доступны только благодаря технологии Flash.

Сам разговор о том, приживется или нет технология HTML5 в веб-разработке, лишен всякого смысла: распространение HTML5 – это новый этап стандартизации веб-технологий W3C. Известен даже предположительный срок, когда должна осуществиться полная доработка всех компонентов HTML5 – 2014 год. После этого Консорциум W3C объявит рекомендацию всем разработчикам о применении нового стандарта верстки. Так же, как это когда-то произошло с HTML4 в 1997 году и его предшественниками еще раньше. Вопрос выбора альтернативы даже не стоит – все браузеры будут поддерживать HTML5 по умолчанию.

Физические законы в «цифре»

Какими возможностями обладает HTML5? По сути это пустая оболочка, в которую можно внедрить что угодно. Благодаря таким инструментам, как Box2D, Canvas, на сайте можно реализовать 3D-модели объектов, которые будут перемещаться и взаимодействовать друг с другом по физическим законам.

«Многослойность» сайта

Благодаря HTML5, можно внедрить сложную анимацию на корпоративный сайт, как это в последнее время стало распространенным. При этом анимированные компоненты не будут смешиваться с содержимым страницы, они будут как бы на разных «слоях» и будут ограничиваться контурами объекта, а не областью его движения/трансформации. Чтобы лучше понять разницу, приведем простой пример. Если в качестве анимированного объекта, перемещающегося поверх сайта, сделать автомобиль, то при реализации с использованием технологии Flash кликабельным будет весь прямоугольник, в который вписан контур машины, даже если визуально там будет находиться текст основного содержания страницы. HTML5 работает более корректно и позволяет избежать данного `побочного эффекта`. Даже при отклонении в 10 пикселей от объекта анимации сайт будет воспринимать нажатие как работу с другим «слоем».

Анимация без границ

Это важное достоинство HTML5 по сравнению с технологией Flash. Если раньше вся анимация концентрировалась в так называемой «шапке» сайта, а все остальные блоки шли отдельно, то сейчас границы между анимацией и блоками контента исчезли

Анимация может осуществляться где угодно и как угодно, и при этом не будет мешать основному содержанию сайта.

Третье измерение

HTML5 позволяет придать сайту эффект трехмерного пространства. Те же самые «слои» могут перемещаться при скроллинге с разной скоростью и, таким образом, формировать эффект параллакса.

Работа с видео без сбоев

HTML5 позволяет работать с видео, так что никакие сбои в работе Flash-плеера больше не лишат возможности пользователей радости просмотра мультимедийного контента.

Работа без перезагрузки внутренних страниц

Большим сдерживающим фактором в распространении HTML5 было то, что многие браузеры далеко не полностью использовали возможности языка javascript. Особенно это касалось браузера Internet Exporer, чья доля была очень высока, но который практически не поддерживал javascript.
Новая технология Ajax позволяет делать сайты на HTML5 без перезагрузки внутренних страниц. Не надо ждать, пока сменится контент, интерфейс остается неизменным и подгружается практически мгновенно. Фактически сайт становится похожим на программу.

Примечание о безопасности форм PHP

Учтите, что переменная может использоваться хакерами!

Если Вы используете на странице сайта PHP_SELF, то пользователь может ввести в адресной строке косую черту (/), а затем выполнить несколько команд межсайтового скриптинга (XSS).

Примечание: XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — тип атаки на веб-системы, заключающийся во внедрении в выдаваемую веб-системой страницу вредоносного кода (который будет выполнен на компьютере пользователя при открытии им этой страницы) и взаимодействии этого кода с веб-сервером злоумышленника. XSS позволяет злоумышленникам внедрять клиентские скрипты в веб-страницы, просматриваемые другими пользователями..

Предположим, у нас есть следующая форма на странице с именем «send_form.php»:

<form method=»post» action=»<?php echo $_SERVER;?>»>

Теперь, если пользователь вводит обычный URL-адрес в адресной строке, например «http://site_name.com/send_form.php», приведенный выше код будет преобразован в:

<form method=»post» action=»send_form.php»>

Теперь пользователь вводит URL-адрес в адресной строке и после косой черты несколько команд межсайтового скриптинга:

http://site_name.com/send_form.php/%22%3E%3Cscript%3Ealert('hacked')%3C/script%3E

После таких манипуляция приведенный выше код будет переведен на:

<form method=»post» action=»send_form.php/»><script»>(‘hacked’)</script»>

Этот код добавляет тег скрипта и команду предупреждения alert. Когда страница начнёт загружаться, код JavaScript будет выполнен и пользователь увидит окно предупреждения. Дальнейшая загрузка страницы прекратится до тех пор, пока пользователь не кликнет ОК. Это простой пример того, как можно использовать переменную PHP_SELF.

Примечание: Имейте в виду, что любой код JavaScript можно внедрить внутрь тега ><script»>! Хакер может перенаправить посетителя сайта к файлу на другом сервере, а тот файл может содержать вредоносный код. Этот код, в свою очередь, может изменять глобальные переменные или пренаправлять данные формы на другой адрес, например, для кражи пользовательской информации.

Селект

Изменение селекта сбрасывает фокус

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

Решение

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

Обратите внимание, что после селекта есть кнопка, которая и будет запускать обработчик после изменения значения поля

Селект без лейбла

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

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

Альтернативный вариант:

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

Кастомные селекты не доступны

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

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

Если все-таки вы должны использовать кастомный селект, вам нужно будет вручную контролировать состояние ряда атрибутов ARIA с помощью JavaScript. Рассмотрите, пожалуйста в качестве основы реализацию от рабочей группы WAI-ARIA.

Develop input field validating functions

You’ll develop four functions for validating values of the form fields:

1) Validate the username field

The following function uses:

• The function to check if the username is provided.
• The function to check if the length of the username is between 3 and 25 characters.
• The and functions to show the error and success indicator.

The function returns if the field passes the checks.

2) Validate the email field

3) Validate the password field

The following function checks the password field if it is provided and match the required format:

4) Validate the confirm password field

The function checks if the confirm password is the same as the password.

Required fields

If we try to submit this form now without completing any of the required fields, the browser will notify us:

Did you notice how we no longer have ‘required’ in the required fields tags anymore? This is because most screen readers will pick up the attribute now, so if we leave ‘required’ in the label tag screen reader users will have ‘required’ read to them twice, which they could find rather annoying.

A word of warning though: not all browsers implement the attribute accessibly, so it might not be picked up correctly in certain browser / screen reader combinations. As such, current best practice recommends supplementing the required attribute with the aria-required=”true” attribute:

Cross-browser?

The good news is that HTML form validation is supported by all the latest desktop browsers, and most mobile browsers. The bad news is that it is only partially supported in Safari, and isn’t supported at all on iOS Safari, or the default Android browser. If you need to support older versions of IE prior to IE10 you won’t find any of those support form validation either.

So, what can you do if you have to support browsers that don’t have support for form validation yet?

One option is to not do anything and rely on your server-side validation only. This would require no extra work on your part, but would the UX for those using unsupported browsers be satisfactory?

Another option would be to continue to use solely JavaScript for your client-side validation, and not add any of the new features discussed above.

A third approach is to use JavaScript to detect whether the browser supports form validation, use it if it does, and fall back to JavaScript-based validation if it doesn’t. Libraries such as Modernizr can help with HTML5 feature detection, but you can always write your own code if you don’t want to include another JavaScript library: