html что такое label

Всегда используйте 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.

Источник

Html формы для сайта — теги Form, Input и Select, Option, Textarea, Label и другие для создания элементов вебформ

Приветствую вас, уважаемые читатели блога KtoNaNovenkogo.ru. Сегодня я хочу поговорить о такой неотъемлемой составляющей верстки любого сайта, как HTML формы. Какой бы не был движок вашего сайта (cms), на нем обязательно будут в том или ином виде использоваться формы, созданные с помощью тегов Form и Input, а так же атрибутов и параметров Button, Checked, Value, Checkbox, Radio, Checkbox, Submit.

Ну, и еще можно добавить к этому элементы для создания выпадающих списков и текстовых полей — Select, Option, Textarea, Label, Fieldset, Legend.

Зачем нужны и как работают формы на современных сайтах

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

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

Да, хочу еще напомнить, что мы уже успели рассмотреть много материалов на тему языка гипертекстовой разметки, например, узнали принципы формирования цветов в Html, трех видов списков на тегах ul, ol, li, dl) и принципы создания таблиц на тегах Tr, Th, Td, Table.

По своей сути формы состоят из элементов, для создания которых внутри основного контейнера из тегов Form вставляют различные тэги — Checked, Value, Checkbox, Radio, Checkbox, Submit и др. Нам лишь нужно будет расположить ее код в любом удобном для этого месте шаблона сайта, указав с помощью тегов и их атрибутов, как она должна будет выглядеть.

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

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

Например, в случае обратной связи пользователь, после того как заполнит поле со своим именем, введет свой E-mail и текст сообщения, а затем нажмет на кнопку отправки, будет вправе надеяться на отправку данных из формы на E-mail автора сайта. Но реализовать такое с помощью только одного языка гипертекстовой разметки (здесь читайте что такое Html, теги и валидатор W3C), к сожалению, не возможно.

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

Обычно программа обработки представляет из себя скрипт, написанный на языке PHP. Поэтому в атрибуте Action тэга Form вы должны будете прописать путь к файлу этого скрипта, лежащего на сервере вашего хостинга. Приведу в качестве примера подписку на RSS ленту моего блога посредством E-mail:

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

Теги Form и Input для создания кнопок, чекбоксов и радиокнопок

Любая форма должна быть заключена в открывающий и закрывающий тэги Form. Это своеобразный контейнер для их создания. У этого тега имеется ряд обязательных и необязательных атрибутов:

Рассмотрим остальные тэги, позволяющие создавать разнообразные вебформы. Самый универсальный – это Input. Внутри него обязательно прописывают атрибут Type, который определяет, что именно будет из себя представлять HTML форма, созданная с помощью этого тэга.

C помощью Input и Type можно создавать следующие элементы:

Input не имеет закрывающего тега. Что именно будет представлять из себя вебформа, созданная с помощью него, целиком и полностью зависит от параметра указанного в атрибуте Type. Если Type не указан, то по умолчанию будет создано текстовое поле.

Примеры форм, созданных на Input с различными значениями для Type

Другие атрибуты тэга Input и примеры их использования

Рассмотрим, для чего нужны остальные атрибуты:

Теперь давайте рассмотрим все примеры формы с Input. Внешний вид текстового поля похож на вид поля для ввода пароля, поэтому рассмотрим только вариант создания Text, например, для ввода адреса электронной почты:

Теперь давайте рассмотрим создание вебформы с радиокнопками (Radio):

Обратите внимание, что в этой форме два раза используется тег Input – по разу для создания каждой из двух радиокнопок. Причем, в каждом из них прописан атрибут Name с одинаковым значением (rezultat), а значение Value разное (YES и NO).

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

Рассмотрим пример создание вебформы с чекбоксами (Checkbox):

Чекбоксы отличаются от радиокнопок возможностью выбрать сразу несколько вариантов. Name служит для определения в файле обработчика, в каком именно чекбоксе проставлены флажки,а Value — задает то значение, которое будет отослано в обработчик (если Value задан не будет, то в обработчик будет отправлен текст, расположенный рядом с данным чекбоксом).

Select, Option, Textarea, Label, Fieldset, Legend — выпадающие списки, текстовые области и другие элементы вебформ

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

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

Причем, все составляющие ее элементы (вроде Select, Option, Textarea, Label, Fieldset, Legend) представляют собой уже законченные заготовки (контейнеры), для вставки которых достаточно будет лишь использовать нужный тег с нужными атрибутами и параметрами.

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

Т.о. получается, что вебформы в Html являются попыткой перенести ключевые элементы, используемые в любой операционной системе, на страницы вебсайта. Но для чего они могут понадобиться на страницах сайта?

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

Хотя, данные можно отправить не только на сервер, но и, например, по электронной почте на адрес, заданный в атрибуте Action тэга Form. При отправке из Html данных на E-mail у пользователя, заполняющего поля, после нажатия им на кнопку отправки данных, запустится почтовая программа используемая на его компьютере по умолчанию.

Открывающий тег Form в таком случае должен выглядеть примерно так:

Вместе с Textarea можно использовать следующие атрибуты:

Label — для чего нужен этот Html тэг в форме

Html тег Label позволяет реализовать одну очень интересную возможность в формах, которая имеется в операционных системах. Там, если вы помните, для того чтобы активировать какой-либо элемент, не обязательно щелкать именно по нему, можно щелкнуть и по названию этого элемента — все равно произойдет его активация.

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

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

Но как связать элемент Html формы и текст? Для этого нужно дописать в атрибут ID с уникальным параметром, а текст нужно окружить открывающим и закрывающим тэгами Label. И это еще не все. В открывающем теге Label нужно прописать атрибут For, параметр которого должен быть точно таким же, как и у атрибута ID в Html теге элемента формы. Получается примерно так:

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

Fieldset и Legend — разбиваем форму на части

Вы, наверное, часто видели, что большие формы в Html бывают разбиты на группы (Fieldset), которые обведены в рамочку и у каждой такой группы имеется свой заголовок (Legend). Реализуется это с помощью всего двух тэгов: Fieldset и Legend. Они парные, т.е. у них должны быть в обязательном порядке открывающий и закрывающий.

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

Вот пример создания групп с помощью Fieldset и Legend:

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru

Комментарии и отзывы (22)

Спасибо за статью! Это как раз то, что я искала — уроки Html! Все доступно, понятно!

О спасибо большое) то что нужно, щас буду писать лабу по информатике и Html. Спасибо автору за статью.

Ирина Пакидова, SaT: пожалуйста, рад, что вам пригодилось.

Спосибо! реально помогло!

Люди подскажите как создать файл обработки с помощью которого можно будет создавать новый аккаунт

вот вроде всё правильно но почемуто кнопка отправить всё равно не создаётся я не понимаю что делать помогите кто знает!

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

Благодарю автора за статью. Как раз искала форму для своего сайта. Материал оказался очень полезен!

Дмитрий спасибо. Очень помогли. У вас нашел, как устанавливать форму с кодом ссылки на сайт. И все получилось. Блага, счастья и здоровья!

Хочу сделать меню для PDA, просто ссылки на страницы сайта с помощью Тега как сделать?

Добрый день. Такая кнопка

Объясните пожалуйста, Что такое и onclick=»DiscountFind ()

это, просто если сказать, где то в стилях есть настройка как отображать)) где то так: #findbtn

Интересует такая вещь:

1. Люди заходят на сайт (типа интернет магазин)

2. Пишут в каком-то окошке «Текст»

3. Выбирают шрифт, цвет, размер

4. Ниже в окошке видят пример «Текста» + изменяемая цена

Есть ли такая форма или как это вообще сделать?

Добрый день. Полезная статья. Спасибо огромное!

Не могли бы вы подсказать, как можно стилизовать такие формы?

Определенный бэкграунд, фон-картинку задать и т.д.

Может кто сталкивался, поделитесь, плз, ссылочкой.

Совет — сделайте код не картинками а чтоб его можно было копировать,а не набирать самому

А каким образом сделать форму чтобыпроизводились вычисления?

Очень подробно написано! Но у меня остался вопрос, есть форма и нужно увеличить шрифт, как это возможно сделать?

Очень доходчиво описан тег и его атрибуты!

Полезная статья. Можно ещё добавить другие формы для описания. Такие как ползунок,выставления даты, времени,выбор цвета,для ввода номера телефона.

Не подумайте что я умничаю. Просто я сам новичок и эти формы будут полезны таким как я

Источник

HTML Inputs and Labels: A Love Story

Grow sales with a smart marketing platform. Try Mailchimp today.

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!

Источник