что такое label в html
Формы — Основы вёрстки контента
Формы — важный интерактивный элемент веб-страницы. Как и ссылки, формы обеспечивают взаимодействие пользователя и страницы, позволяя отправлять данные. Для этого в HTML существуют специальные конструкции, которые говорят браузеру, какие поля может использовать пользователь и как их обрабатывать.
Тема форм достаточно большая, чтобы описать её в рамках одного урока, ведь со всеми возможными нюансами это может вылиться в целый курс. Не бойтесь — в этом уроке вы узнаете достаточно, чтобы научиться делать хорошие формы.
Создание формы
Для отделения формы от остальных участков вёрстки используется специальный тег
Сервер — удалённый компьютер, на котором хранится весь проект. Сейчас вы смотрите на страницу, которая сгенерирована на сервере и отдана вам по определённому адресу. Этот адрес указан сейчас в вашем браузере.
Примером взаимодействия с формой является любой сайт-поисковик. Например, Google или Yandex. Вы вводите поисковый запрос, который отправляется на сервер. Сервер обрабатывает результат и выдаёт вам подходящие сайты. Это взаимодействие происходит с помощью серверных языков программирования, таких как PHP, Ruby и так далее. В рамках вёрстки мы не можем влиять на то, как обработается результат. Результат вёрстки — набор тегов, с помощью которых браузер соберёт данные и отправит их на сервер.
Смысл этого действия вы лучше поймёте, если будете заниматься Backend разработкой. Например, на языке PHP или Python. Если сейчас вам кажется это сложным, то не отчаивайтесь. Разработчики всегда вам подскажут, куда стоит отправлять данные.
Поля формы
В примере вы можете увидеть два атрибута тега
Попробуйте изменить размер элемента
. Это можно сделать потянув за правый нижний угол. Так вы можете не только увеличить ширину, но и высоту элемента.
Такое поведение зачастую вредит нашему дизайну. Поэтому разработчики в большинстве случаев запрещают такое поведение. Тут есть несколько вариантов:
input
type=»text»
Самый простой вид input, который позволяет ввести любую пользовательскую информацию. Никаких проверок полей не происходит. Единственное исключение — удаление переносов строк перед отправкой на сервер. Если нужны данные с переносом текста, то используйте тег
Заметьте, что сейчас поле никак не подписано и из-за этого абсолютно непонятно что надо ввести пользователю. Первое, что приходит в голову — добавить перед полем заголовок или параграф. Да, это создаст видимость описания поля. Но только видимость! С точки зрения семантики в таком варианте нет никакой связи между текстом и полем ввода. Это критично для слепых, которые пользуются скринридерами, так как они не смогут связать название и поле для ввода.
Скринридер (Screen Reader) — устройство для чтения текста с экрана. Используется слепыми или слабовидящими людьми.
. Это справедливо даже в случае визуального отсутствия подписи к полю.
type=»radio»
Радиокнопки используются для выбора одного варианта из множества доступных. Почему такой тип называется radio? Есть мнение, что такое название тип получил от первых автомобильных радиоприёмников. В них было доступно несколько радиостанций, но выбрать можно было только одну. Здесь смысл очень похож на принцип таких приёмников.
type=»checkbox»
Чекбоксы немного похожи на радиокнопки, но имеют существенное отличие — возможность выбора сразу нескольких значений. Представьте, что пользователь выбирает любимые блюда. Скорее всего это не одно блюдо, а сразу несколько. Можно дать возможность просто их написать с помощью
, но грамотнее будет использовать чекбоксы.
Списки
Отдельным элементом формы являются списки. Представьте себе фильтр на сайте по продаже техники. Одновременно вы можете отфильтровать товары только в одной категории. Для этого можно использовать радиокнопки или даже чекбоксы в случае множественного выбора. Но есть ещё один способ — использование списка.
Для элементов радиокнопок и чекбоксов для выбора по умолчанию используется атрибут checked
Отправка формы
В прошлом разделе мы рассмотрели различные способы взаимодействия пользователя и формы. Но это не имеет никакого смысла, если форма не будет отправлена. Для этого нужно создать элемент, при взаимодействии с которым будет отправлена форма.
Отправка формы может быть осуществлена одним из двух способов:
Разделение участков формы
Текст внутри текстового поля
Во всех примерах этого урока текстовые поля изначально были пустыми. Наверное вы часто видели, что до фокуса на поле есть текст, предлагающий ввести данные или показывает формат, в котором ожидаются данные.
Самостоятельная работа
Создайте форму для регистрации пользователя на сайте. Форма должна принимать следующие данные:
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты.
Нашли опечатку или неточность?
Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.
Что-то не получается или материал кажется сложным?
Загляните в раздел «Обсуждение»:
Об обучении на Хекслете
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
Наши выпускники работают в компаниях:
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Всегда используйте label
Это перевод статьи Адама Сильвера — «Always use a label».
Иногда дизайнеры слишком сильно упрощают форму, убирая подпись к полю (примечание переводчика: здесь и далее имеется в виду тег label). Проблема в том, что минимализм не всегда означает простоту в использовании, а это, безусловно, и происходит с подписями.
На самом деле, подпись к полю является важной частью для создания лёгких в использовании форм. Вот почему:
1) Зрячие пользователи смогут видеть инструкции и будут знать, что делать. Без подписей к полям в лучшем случае это будет сложно.
Подпись к полю помогает зрячим пользователям понять, что нужно вводить
2) Незрячие пользователи смогут услышать инструкции благодаря использованию скринридеров. Без подписей к полям это будет невозможно.
Поле «Username» доступно для чтения скринридерами
3) Пользователи с моторными нарушениями смогут легче найти и активировать элементы с помощью мышки или пальца благодаря увеличению размеров активной области. Это происходит потому, что клик и нажатие пальцем по подписи работает так, будто пользователь кликнул по самому элементу управления.
Большая площадь поля помогает пользователям с моторными нарушениями активировать элемент
Но для меню выбора вида/размера/цвета/количества не нужны подписи, не так ли?
Нужны, и, к сожалению, довольно часто подписей нет в формах выбора товаров. ASOS страдает этой проблемой, как вы видите.
Форма выбора товаров на ASOS пренебрегает подписями у раскрывающихся списков
Вместо подписей здесь используется первое значение из раскрывающегося списка. Пока значение не выбрано это допустимо для хорошо видящих пользователей, но создаёт трудности для пользователей с нарушением зрения или моторных функций. Если значение выбрано, как в примере выше с выбором цвета, сложности возникают уже у всех типов пользователей.
House of Fraser показывает подпись к раскрывающемуся списку выбора количества вещей, улучшая удобство использования всем пользователям.
House of Fraser имеет подпись у поля с выбором количества вещей
Простая форма поиска не нуждается в подписях, не так ли?
Нуждается, но, к сожалению, формы поиска часто разрабатываются без подписей. В качестве примера можно посмотреть на Selfridges.
Форма поиска Selfridges пренебрегает подписью к полю
Чтобы объяснить назначение формы, вместо подписи здесь используется подсказка для поля и кнопка отправки (иконка лупы). Но это чересчур сложно для использования людьми с ограниченными возможностями — и, конечно — подсказки полей не должны использоваться как замена подписям.
Smashing Magazine показывает, как использование подписей может быть красивым и функциональным одновременно.
Форма поиска Smashing Magazine использует подпись у поля
Использование подписей к полям может нести дополнительные сложности в дизайне, но уход от этих проблем — это не решение. Принимайте этот вызов, и не стоит чересчур упрощать. И конечно, всегда используйте тег label.
Анимация label для текстового input
Эта техника — пример прогрессивного UX, когда подписи к полям формы утрачивают важность по мере того, как пользователь продолжает заполнять форму. Утрачивающие по ходу взаимодействия с пользователем важность элементы уходят на второй план, а новые и актуальные перемещаются на передний план.
Рассуждения о семантике
Всю HTML-разметку веб-страницы можно сделать с помощью только
Пробел в значении атрибута placeholder — трюк, позволяющий для управления логикой фокуса использовать только CSS.
Обнаружение изменений при вводе текста
Как работает CSS-правило :placeholder-shown
Для того, чтобы добавить эффектный прыжок подсказки из поля наружу, нужны следующие условия:
Вот как написать эти условия в CSS:
Фрагмент CSS устанавливает стиль подписи-метки в зависимости от состояния текстового поля. Селектор
— это то, что соединяет input и следующий после него в HTML-коде label и расположенный на том же уровне. Когда это CSS-правило становится активным, подпись к полю меняет свой внешний вид: перемещается и масштабируется. Т.е. покидает поле ввода и не мешает пользователю печатать в нём.
Чтобы оживить переход состояния метки, можно добавить такой переход.
Лучше этот переход разделить на два и таким образом выделять метку, когда фокус переместится в поле ввода текста. Всегда полезно дать пользователю визуальную подсказку о том, где находятся курсор и фокус. Курсор во многих случаях слишком тонкий, поэтому уделить больше внимания тому факту, что фокус перемещен в поле для ввода не повредит.
Кармашки для меток
Для кармашков подойдут контейнеры со скругленными углами того же цвета, что и фон.
кармашки для прыгающих label
На картинке для наглядности цвет контейнеров-кармашков показан ярким и четким. Он иллюстрирует форму HTML-узлов, которые для этого используются.
Может показаться излишним использовать два элемента для label и его подложки вместо того, что окажется одним. Однако так будет проще нарисовать кармашек поверх существующей разметки и добавить ему какие-нибудь трансформации для эффектного появления.
Тогда для перемещения кармашка-подложки можно использовать точно такую же логику трансформации как для текста. Единственное отличие состоит в том, что контейнер со скругленными углами по вертикали перемещается в противоположном направлении навстречу тексту.
Пример
В заключение
Лёгкая анимация элементов формы в ответ на действия пользователя усиливает ощущение ответной реакции, а перемещение подсказок в ответ на изменение состояния поля ввода — хороший пример прогрессивного UX.
Чтобы определить, когда нужно активировать анимацию используется только CSS.
HTML Inputs and Labels: A Love Story
Take your JavaScript to the next level at Frontend Masters.
Most inputs have something in common — they are happiest with a companion label! And the happiness doesn’t stop there. Forms with proper inputs and labels are much easier for people to use and that makes people happy too.
A happy label and input pair
In this post, I want to focus on situations where the lack of a semantic label and input combination makes it much harder for all sorts of people to complete forms. Since millions of people’s livelihoods rely on forms, let’s get into the best tips I know for creating a fulfilling and harmonious relationship between an input and a label.
Content warning: In this post are themes of love and relationships.
The love story starts here! Let’s cover the basics for creating happy labels and inputs.
How to pair a label and an input
There are two ways to pair a label and an input. One is by wrapping the input in a label (implicit), and the other is by adding a for attribute to the label and an id to the input (explicit).
Think of an implicit label as hugging an input, and an explicit label as standing next to an input and holding its hand.
Unfortunately, an implicit label is not handled correctly by all assistive technologies, even if for and id attributes are used. Therefore, it is always the best idea to use an explicit label instead of an implicit label.
Each separate input element should only be paired with one label. And a label should only be paired with one input. Yes, inputs and labels are monogamous. ♥️
Note: There’s one sort of exception to this rule: when we’re working with a group of inputs, say several radio buttons or checkboxes. In these cases, a element is used to group certain input elements, such as radio buttons, and serves as the accessible label for the entire group.
Not all inputs need labels
An input with a type=»submit» or type=»button» does not need a label — the value attribute acts as the accessible label text instead. An input with type=»hidden» is also fine without a label. But all other inputs, including
and elements, are happiest with a label companion.
What goes in a label
The content that goes inside of a label should:
This way, we get the benefit of a clear label that describes what the input is for, and a bonus hint to the user that the input needs to be entered in a specific format.
Best practices for a healthy relationship
The following tips go beyond the basics to explain how to make sure a label and input are as happy as can be.
Do: Add a label in the right place
A user with low vision who uses a screen magnifier in combination with a screen reader may be confused when the reading order appears to skip around on the screen. A keyboard user may have trouble predicting where focus will go next when the source order does not match the visual order.
Think about it. If we have some standard HTML where the label comes before the input:
That places the label before the input in the DOM. But now let’s say our label and form are inside a flexible container and we use CSS order to reverse things where the input visually comes before the label:
A screen reader user, who is navigating between elements, might expect the input to gain focus before the label because the input comes first visually. But what really happens is the label comes into focus instead. See here for the difference between navigating with a screen reader and a keyboard.
So, we should be mindful of that. It is conventional to place the label on the right-hand side of the input for checkboxes and radio buttons. This can be done by placing the label after the input in the HTML, ensuring the DOM and visual order match.
Do: Check inputs with a screen reader
Whether an input is written from scratch or generated with a library, it is a good idea to check your work using a screen reader. This is to make sure that:
Over the last few years, I have used JavaScript libraries, like downshift, to build complex form elements such as autocomplete or comboboxes on top of native HTML ones, like inputs or selects. Most libraries make these complex elements accessible by adding ARIA attributes with JavaScript.
However, the benefits of native HTML elements enhanced using JavaScript are totally lost if JavaScript is broken or disabled, making them inaccessible. So check for this and provide a server-rendered, no-JavaScript alternative as a safe fallback.
Check out these basic form tests to determine how an input and its companion label or legend should be written and announced by different screen readers.
Do: Make the label visible
Connecting a label and an input is important, but just as important is keeping the label visible. Clicking or tapping a visible label focuses its input partner. This is a native HTML behavior that benefits a huge number of people.
Imagine a label wanting to proudly show its association with an input:
A label really wants to show off its input arm candy. 💪🍬
That said, there are going to be times when a design calls for a hidden label. So, if a label must be hidden, it is crucial to do it in an accessible way. A common mistake is to use display: none or visibility: hidden to hide a label. These CSS display properties completely hide an element — not only visually but also from screen readers.
Consider using the following code to visually hide labels:
Kitty Giraudel explains in depth how to hide content responsibly.
To preserve and maintain a healthy relationship between inputs and labels, there are some things not to do when pairing them. Let’s get into what those are and how to prevent them.
Don’t: Expect your input to be the same in every browser
Don’t: Substitute a label with a placeholder
Here is why a placeholder attribute on an input should not be used in place of a label:
Placeholders are like the friend that shows up when everything is perfect, but disappears when you need them most. Pair up an input with a nice, high-contrast label instead. Labels are not flaky and are loyal to inputs 100% of the time.
The Nielsen Norman Group has an in-depth article that explains why placeholders in form fields are harmful.
Don’t: Substitute a label with another attribute or element
When no label is present, some screen readers will look for adjacent text and announce that instead. This is a hit-and-miss approach because it’s possible that a screen reader won’t find any text to announce.
The below code sample comes from a real website. The label has been substituted with a element that is not semantically connected to the input.
The above code should be re-written to ensure accessibility by replacing the span with a label with for=»cardNumber» on it. This is by far the most simple and robust solution that benefits the most people.
While a label could be substituted with a span that has an id with a value matching the input’s aria-labelledby attribute, people won’t be able to click the span to focus the input in the same way a label allows. It is always best to harness the power of native HTML elements instead of re-inventing them. The love story between native input and label elements doesn’t need to be re-written! It’s great as-is.
Don’t: Put interactive elements inside labels
Only plain text should be included inside a label. Avoid inserting things such as headings, or interactive elements such as links. Not all screen readers will announce a label correctly if it contains something other than plain text. Also, if someone wants to focus an input by clicking its label, but that label contains a link, they may click the link by mistake.
I always find that real-life examples help me to properly understand something. I searched the web and found examples of labels and inputs from a popular component library and website. Below, I explain where the elements fall short and how they can be improved to ensure a better pairing.
Component library: Material
MaterialUI is a React component library based on Google’s design system. It includes a text input component with a floating label pattern that has become a popular go-to for many designers and developers:
The floating label pattern starts with the label in the placeholder position that moves the label to its proper place above the field. The idea is that this achieves a minimal design while solving the issue of placeholders disappearing when typing.
Clicking on the input feels smooth and looks great. But that’s the problem. Its qualities are mostly skin-deep.
At the time of writing this post, some issues I found with this component include:
The Huffpost website has articles containing a newsletter subscription form:
This form looks quite nice but could be improved
At the time of writing this blog post, the email input that Huffpost uses could benefit from a number of improvements:
A surprising number of people struggle to enter information into poorly-constructed inputs. That list includes people with cognitive, motor and physical disabilities, autism spectrum disorders, brain injuries, and poor vision. Other people who struggle include those in a hurry, on a poor connection, on a small device, on an old device, and unfamiliar with digital forms, among many others.
Additionally, there are numerous reasons why JavaScript might break or be switched off in a browser, meaning inputs become dysfunctional or completely inaccessible. There are also people who are fully capable of viewing a web page but who may choose to use a keyboard along with a screen reader.
The message I want to get across is that happy label and input pairs are crucial. It doesn’t matter if your form is beautiful if it is unusable. I can bet that almost everyone would rather fill out an ugly but easy-to-use form rather than a pretty one that causes problems.
I want to warmly thank the following people for helping me with this post: Eric Eggert, Adam Silver, Dion Dajka, and Kitty Giraudel. Their combined accessibility knowledge is a force to be reckoned with!
Как создавать и стилизовать чекбоксы: подробный гайд
Чекбокс — это компонент ввода на сайте, который обычно выглядит как пустой квадрат в невыбранном состоянии, а если его выбирают, то он меняет вид — в квадрате появляется галочка.
Чекбоксы можно найти на любом сайте в интернете. Их используют, когда нужно выбрать ответ на вопрос из нескольких вариантов или чтобы отметить больше одного ответа.
Вы можете увидеть этот компонент, когда вам предлагают оформить подписку на рассылку новостей на сайте или просят прочитать и согласиться с политикой конфиденциальности.
В отличие от тех же радиокнопок, которые позволяют выбрать только один ответ, чекбоксы могут «включать» и «выключать» разные значения.
Иногда чекбоксы на сайте отмечены по умолчанию. Например, для регистрации пользователю обязательно нужно согласиться с обработкой персональных данных. В этом случае галочка уже может стоять в поле, чтобы дать понять, что это условие обязательно для регистрации на сайте.
В этой статье мы разберем, как создать чекбоксы и как настроить стиль, разметку и цвета с помощью HTML и CSS.
Атрибуты чекбокса
Синтаксис чекбокса в HTML выглядит очень просто:
Он обычно содержит несколько атрибутов:
Как создать стильный чекбокс
По умолчанию
Если мы пользуемся только HTML и не настраиваем стили при помощи CSS, то стиль чекбокса по умолчанию выглядит вот так:
Стиль по умолчанию
HTML-код такого чекбокса выглядит довольно просто:
По сути, кроме указания вам не нужно ничего делать.
Чекбокс с галочкой
Тогда мы получим чекбокс с галочкой:
Чекбокс с галочкой
Обязательный чекбокс
Используя другой атрибут, можно прописать в коде обязательный чекбокс. Это значит, что пользователь не сможет отправить форму, пока не отметит нужный чекбокс. Этот атрибут часто используется, если нужно принять какие-либо условия.
Чтобы установить такой чекбокс, в строку ввода нужно добавить дополнительный атрибут:
И если пользователь не поставил галочку и пытается отправить форму, то у него не получится это сделать. Всплывет окно с подсказкой:
Кастомный чекбокс
Теперь перейдем к настройке кастомного чекбокса. На самом деле стилизовать сам чекбокс очень проблематично. Но существует простой трюк, который позволит вам использовать любой элемент, который вы хотите.
В чем суть трюка? Мы спрячем окошко для галочки и создадим вместо него поддельный чекбокс, который и будем настраивать с помощью CSS.
Скрываем чекбокс: способ первый
И квадрат с галочкой исчезнет:
Квадрата с галочкой нет
Теперь наш чекбокс выглядит как простой текст, но на самом деле в структуре кода видно, что окно с галочкой просто не отображается у пользователя на экране:
Скрываем чекбокс: способ второй
Текст больше не съезжает
Настройка стиля: закруглим края и добавим цвет
Теперь можно приступать к настройке своего собственного стиля чекбокса. Например, можно сделать окошко для галочки с закругленными краями, прописав:
Если вы хотите, чтобы чекбокс выделялся на фоне черного текста, то настройте собственную цветовую палитру. Можно менять как цвет обводки, так и фона внутри. Для этого впишите код желаемого цвета, например:
И установите стиль границ:
border: 2px solid #33475B
Так у нас получился серо-синий цвет чекбокса:
Добавляем фон
Чтобы настроить собственное отображение выбранного чекбокса, на галочки и фон нужно потратить чуть больше времени. Придется вручную прописать стиль, позицию и настройки отображения галочки. Мы создали собственный чекбокс, который выглядит так:
Чтобы сделать такой простой стиль, необходимо написать несколько строк кода:
Кроме того, можно даже создавать сложные чекбоксы с анимацией. Если вы хотите посмотреть, как выглядят анимированные чекбоксы, то загляните в статью Custom HTML and CSS Checkbox Examples You Can Use Too.