HTML элемент label и его использование при выводе и обработке формы

В разделе Issues проекта Cotonti на Github состоялась (и, возможно, еще не закончилась) дискуссия по поводу внедрения HTML-элементов <label> в формы движка. Если опустить всю лирику, то принципиальными – на мой взгляд – стали два вопроса:

1. Где использовать элемент label?
2. Как использовать элемент label?

Я поясню свою точку зрения, но прежде всего остановимся на теории.

Зачем нужен элемент формы label

Для начала официальная формулировка:

The HTML <label> element represents a caption for an item in a user interface, primarily used to associate text with form controls. This association significantly improves accessibility for users with disabilities and enhances general usability.

Связь между <label> и соответствующим ему элементом формы осуществляется через атрибут id.

В принципе, все понятно: в первую очередь это необходимо для обеспечения accessibility для пользователей с инвалидностью или нарушениями тех или иных органов восприятия. В нашем случае – очевидно – зрения. Например при перемещении курсора (событие focus) в элемент input с оформленным label, скрин-ридер должен озвучить его содержимое:

<label for="rname">Username:</label>
<input type="text" id="rname" name="rname">

Далее следует аспект usability, который обычно просто произнести, но сложно понять. В нашем случае речь идет в основном об удобстве использования чекбоксов и радио-селектов. Per se они очень маленькие и на мобильных устройствах ваш палец окажется слишком велик для них. Если же использовать label в виде “обертки”, все становится проще:

<label>
  Confirm the action:
  <input type="checkbox" name="rconf">
</label>

Обертка в виде элемента label создаст дополнительную площадь, и тапать по нужной зоне будет гораздо удобнее, а id не потребуется. Здесь вообще нет претензий.

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

It provides a meaningful, structural relationship between the description text and the form field that can be better understood by browsers and assistive technologies.

Заметим, что браузеры сегодня понимают и не такое, а ассистивные технологии – это снова про disabilities.

Все это касалось использования <label> при выводе формы. Есть еще и обработка, но <label> здесь также не требуется. Например, простая форма вида:

<form method="post" action="contactus">
  <label for="sender_name">Sender:</label>
  <input type="text" id="sender_name" name="sender_name">
  <button type="submit">Send</button>
</form>

при обработке отдаст вам массив в виде пар “element.name => element.value”. Это очень удобно и просто – при условии что атрибут name будет соответствовать требованиям. А здесь есть одно большое “НО”: кириллица для него допускается  только теоретически (при использовании Юникода), но на практике категорически не рекомендуется. Так что если в описательной части вас устроит латиница, можно и так.

$content = "\n";
foreach ($_POST as $key => $value) {
  if ($value) {
    $content .= "$key:  $value\n";
  }
}

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

$translate = ['sender_name' => 'Отправитель'];

$content = "\n";
foreach ($_POST as $key => $value) {
  if ($value) {
    $content .= $translate[$key] . ":  $value\n";
  }
}

Такой вариант хорош для кейсов, когда у вас есть конечный набор полей, хотя могут быть задачи, при которых элементы могут используются в произвольных комбинациях и могут быть неизвестны. Если же используется конечный набор известных элементов (например, в формах добавления / редактирования страниц или в форме обратной связи), обработку форм можно производить с помощью функции cot_import(). Например:

$sender = cot_import('sender_name', 'P', 'TXT');

Здесь элементы <label> нам не нужны, а уведомления можно формировать с помощью ресурсных R-строк – как это сделано в "коробочном" плагине Contacts:

$R['contact_message'] = <<<TXT
{\$sitetitle} - {\$siteurl}

{$L['Sender']}: {\$author} ({\$email})
{$L['Topic']}: {\$subject}
{$L['Message']}:

{\$text}

{\$extra}
TXT;

На этом теория заканчивается, и можно переходить к конкретным рекомендациям.

Где и как применять элемент label

Ознакомившись с преамбулой, пытливый читатель сделает для себя главный и – в общем-то – правильный вывод:

Поскольку label не является обязательным элементом формы, его проще не использовать вообще.

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

Критически важные для индексирования и ранжирования локации, безусловно, требуют максимального внимания и максимальной же имплементации всех возможных требований. Поэтому для “сеошного чек-листа” <label> можно и указать. Хотя здесь возникает логичный вопрос:

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

Здесь рекомендации недействительны, и вам необходимо принимать решение сообразно собственному пониманию этого вопроса.

Использование label в Cotonti Siena

Обработка всех форм в движке производится с использованием функции cot_import() – прежде всего, по причинам безопасности. Поэтому элементы label имеют чисто декоративный характер и практически нигде не задействованы. Исключение – дефолтная разметка для экстраполей, имеющих тип checkbox и radio. Здесь label применяется в виде “обертки”, обеспечивающей необходимый уровень юзабилити.

Что касается стандартных полей, то лишь малая их часть имеет тип checkbox и radio, требующий label. Для их вывода используются функции cot_checkbox() и cot_radiobox() соответственно. Дефолтные R-строки имеют следующий вид:

$R['input_checkbox'] = '<input type="hidden" name="{$name}" value="{$value_off}" /><label><input type="checkbox" name="{$name}" value="{$value}"{$checked}{$attrs} /> {$title}</label>';
$R['input_radio'] = '<label class="radio-label"><input type="radio" name="{$name}" value="{$value}"{$checked}{$attrs} /> {$title}</label>';

Если вас они не устраивают, несложно подключить кастомные ресурсы.

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

Хотите все делать в шаблоне? Прописывайте каждый <label> вручную, а для соответствующих тегов указывайте id с помощью функции cot_rc_modify(). Применительно к шаблону правки страниц page.edit.tpl это будет выглядеть примерно так (табличная разметка только для примера):

<tr>
  <td>
    <label for="rpagealias">{PHP.L.Alias}</label>:
  </td>
  <td>
    {PAGEEDIT_FORM_ALIAS|cot_rc_modify($this, 'id="rpagealias"')}
  </td>
</tr>

Понятно, что профит от таких трансформаций вы вряд ли почувствуете, да и на юзабилити это никак не скажется. Если есть желание сделать данную форму по-настоящему адаптивной, необходимо перейти с табличной верстки на grid-модель. При этом можно использовать как label, так и простые div’ы или любые другие HTML-элементы. Пример в сниппете.

Выводы

Перефразируя сказанное выше, можно утверждать: все, что WWW-стандарты вас не заставляют делать, можно (и лучше) не делать. Это касается и элементов label. Их использование per se не сделает ваш проект лучше и качественнее. Как правило, существуют и более приоритетные задачи, результат решения которых будет более реален.

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

Ранее мы разрабатывали способы борьбы с поведенческимим ботами Biterika.