Комментарии 15
Если хочется семантическую таблицу, но чтобы визуально это был список, в чём проблема?
![](https://habrastorage.org/getpro/habr/upload_files/d0f/da4/bad/d0fda4bad3efbb2b848a59064ababca5.png)
В DevTools у tbody
меняем dispaly
на flex
, и вперёд. Я заголовочную строку оставил как есть для сравнения, а строки с данными оформил как вложенные флексбоксы. В оригинале они не заполняют контейнер, а идут друг за другом, и я сделал так же, но нет проблем задать flex-wrap
, и визуально будут полноценные карточки, заполняющие контейнер.
Так что, можно и не ограничивать себя рамками №2. А вот разумность всего этого — отдельный вопрос. Разве бухгалтеры пользуются скринридерами?
нет проблем задать
flex-wrap
, и визуально будут полноценные карточки, заполняющие контейнер.
Тогда это выглядит вот так:
![](https://habrastorage.org/getpro/habr/upload_files/3df/ca1/675/3dfca1675ca8144ac740fd411f5957f5.png)
В начале статьи я сразу предупредил, что цель подушнить и разобраться "как правильно". Фактор разумности уже долгое время остаётся холиварным, хотя, на мой взгляд, здорово, когда разработчик задумывается о поддержке доступности.
Если стилизовать таблицу предложенным вами способом, то скринридер читает только значения, не повторяя необходимые ключи, так как их, по заданию задачи, не должно быть сверху (я добавил туда display: none
). В инструментах отладки поддержки доступности предложенный вариант определяется как таблица со значениями. В итоге, мы не поймем, где написано про ИНН, а где про КПП и так далее.
Можно доработать таблицу старым хаком, который позволяет сжимать широкую таблицу до мобильных размеров. Но тогда встает вопрос о целесообразности таких изощренных методов с большим количеством DOM-узлов и повторящихся псевдоэлементов. Проще вернуться к варианту с <dl>
, <dt>
, <dd>
Где про это было в условиях задачи? Вот что я прочитал:
Теперь это действительно таблица со сгруппированными данными … Однако, визуально задача будет решена неверно
Я и спросил, если нужна «действительно таблица», которая бы визуально выглядела как список, почему просто её соответствующе не оформить.
Не увидел никакой душноты в статье. Полезная интересная аналитика.
Спасибо
Проблема в том, что для "семантического" заголовка в таблице используется caption
, а не thead
+tr
+th
Если вы пишите в дано что у вас возвращается список, почему бы не использовать список? Берете ul, каждая карточка отдельная li, дальше заголовок с названием организации, и p, span, address для структуры, если надо что то добавить для скринридера есть aria.
Целью является соответствие семантике. Вот выдержка из WAI-ARIA:
WAI-ARIA is intended to augment semantics in supporting languages like [HTML] and [SVG2], or to be used as an accessibility enhancement technology in other markup-based languages that do not explicitly include support for ARIA. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page, because the invention of new types of objects is faster than standardized support for them appears in web languages.
It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of object. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively. For example, it's better to use an
h1
element in HTML than to use theheading
role on adiv
element.
Не стоит использовать ARIA, если в этом нет необходимости. HTML5 предоставляет широкий спектр семантических элементов.
Элементов вёрстки печатной страницы. К семантике ваших данных они не имеют никакого отношения. Фактически, выбор тегов в хтмл определяется лишь тем, как вы хотите, чтобы всё выглядело без стилей. Именно поэтому у вас в хтмл есть заголовки, параграфы, списки и таблицы, но нет организаций, пользователей, договоров и платёжных поручений. И вам приходится выбирать как вторых утрамбовать в первых, ибо при должной фантазии сделать это можно любым способом. Например, сделать каждое свойство секцией, его имя - заголовком, а значение - цитатой.
Простите, но у меня пара вопросов:
1) а разве надо верстать не так, как нарисовал дизайнер?
2) а вот в рамках реального проекта вот этих пользователей, которые используют screen reader - их сильно отличное от нуля количество?
Именно так. Статья этому не противоречит. Вариантов сверстать одно и то же довольно много. Однако, в статье я ищу вариант сделать это еще семантически верно + доступно.
Довольно мало, но это еще зависит от рода проекта. Полагаю, что на сайте посвященном инклюзивности, привлекающим людей с ограниченными возможностями, процент будет повыше, чем в рядовом интернет-магазине.
Как нарисовал дизайнер — это дело CSS. А вёрстка в HTML должна соответствовать природе данных.
<dl> или <table>? Исследуем подходы к представлению пар ключ-значение в HTML