Это самый простой и прямолинейный подход, который легко реализовать.
ИНН: 1234567890
КПП: 1234567890
Адрес: Улица Пушкина дом Колотушкина
Помимо простоты, это самый легковесный вариант. 5 строк и несколько элементов. Стилизовать такой вариант получается намного быстрее следующих.
Однако, смотрим в документацию и видим, что
используется когда ни один другой элемент не подходит, элемент div используется в качестве крайней меры. В противном случае это приводит к снижению доступности для читателя. Также Согласно руководству W3C по доступности веб-контента (WCAG):
информация, структура и отношения, передаваемые через презентацию, должны быть доступны программно. Это означает, что структура пар ключ-значение должна быть ясно выражена в разметке, а не только в визуальном представлении
Выходит, данное решение не удовлетворяет принципу устойчивости (robust) WCAG 2, использованию правильной семантической верстки. Хорошо, тогда попробуем второе решение.
Решение №2
Элементы
, , предназначены для представления пар ключ-значение. Список — термин — описание могут смутить, поэтому обратимся к документации w3.org
элемент предоставляет ассоциативный список, состоящий из нуля или более групп имя-значение. … Группы «Имя-значение» ( и соответственно) могут представлять собой термины и определения, разделы метаданных и значения, вопросы и ответы или любые другие группы данных «имя-значение»
В контексте HTML, «термин» в может быть более широко интерпретирован, чем просто академический или словарный термин. Он может обозначать любой элемент данных, который имеет связанное с ним значение. Так что использование ИНН и номера в качестве «терминов» вполне приемлемо.
ООО "Моя оборона"
ИНН
1234567890
КПП
1234567890
Адрес
Улица Пушкина дом Колотушкина
Принцип устойчивости WCAG тоже соблюдён. А скринридер распознает эти элементы как определения, причем читая их последовательно: Термин «ООО Моя оборона» → термин «ИНН» → 1234567889 → термин «КПП» → 1234567890 → термин «Адрес» → Улица Пушкина дом Колотушкина.
Стилизовать такой вариант немного сложнее, чем первое решение. Однако, здесь возникает еще один вопрос — не табличные ли это данные? Ведь здесь есть её признаки:
Структура таблицы включает в себя две базовые части:
Подлежащее — это признак, по которому данные группировали и обрабатывали.
Сказуемое — это данные, которые раскрывают суть подлежащего.
Решение №3
Элемент
предназначен для представления табличных данных. С одной стороны, можно представить решение задачи как список таблиц вида:
ИНН
1234567890
КПП
1234567890
Адрес
Улица Пушкина дом Колотушкина
Несмотря на то, что выше представлена простая таблица, данные в ней не группированы. По сути это выборка данных из общей таблицы, которая должна бы выглядеть иначе. Взглянем на верстку:
ООО "Моя оборона"
ИНН
1234567890
КПП
1234567890
Адрес
Улица Пушкина дом Колотушкина
Получилось громоздко. Скринридер увидит, что к «ООО Моя оборона» относится целая табличная часть, но читать он ее будет криво: ООО «Моя оборона» → ИНН → ООО «Моя оборона» → 1234567890 > ООО «Моя оборона» → КПП → ООО «Моя оборона» → …
Как исправить ситуацию? Переверстать всё в одну таблицу и сгруппировать данные:
Название компании
ИНН
КПП
Адрес
ООО «Моя оборона»
1234567890
1234567890
Улица Пушкина дом Колотушкина
ООО «Рога и копыта»
2234567890
2234567890
Улица Гагарина в гостях у Татарина
Теперь это действительно таблица со сгруппированными данными. У таблицы есть «шапка» и «тело» и у скринридера не возникнет неполадок. Также в таком случае получится удовлетворить и требования WCAG. Однако, визуально задача будет решена неверно, ведь необходимостью было присвоить каждому элементу найденного списка отдельную сущность.
Заключение
Таким образом, в случае задачи сверстать список пар ключ-значение, удовлетворив требования семантики и доступности, необходимо выбирать Решение №2
. А если нужно грубо и быстро, то классический и самый популярный вариант с
