Главная » Статьи » Как у вас обстоят дела с figure в HTML 5?

Как у вас обстоят дела с figure в HTML 5?

Как у вас обстоят дела с figure в HTML 5?

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

Элемент figure

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

Например, документ, в котором описывается скорость полета ласточки, может содержать раздел, объясняющий различия между южноафриканской и европейской ласточками. Сопровождая этот контента, figure может демонстрировать параллельное сравнение этих птиц, чтобы дополнить информацию, изложенную в документе.

Этот мета-пример рисунка и подписи используется со ссылкой на предшествующий контент. Если бы я не включил его, вся информация до этого момента все равно описывала бы цель figure.

figure может использоваться с или без figcaption. Однако без заголовка или альтернативного средства предоставления доступного имени (например aria-label) figure может не предоставлять большой ценности, передавая только семантику. В некоторых случаях он может вообще не передавать никакой семантики, если ему не задано доступное имя.

Элемент figcaption

figcaption предоставляет заголовок или краткое изложение контента, который содержит figure. Значение figcaption должно быть доступным именем для элемента figure, если вместо него для figure не используется атрибут aria-label или aria-labelled.

figcaption может быть помещен до или после первичного содержимого figure, однако он должен быть прямым потомком элемента figure. Допустимые шаблоны:

<figure> <figcaption>...</figcaption> <!-- содержимое figure -->
</figure> <figure> <!-- содержимое figure --> <figcaption>...</figcaption>
</figure> <figure> <figcaption> <div> ... </div> </figcaption> <!-- содержимое figure -->
</figure>

Недопустимые шаблоны:

<figure> <div> <figcaption>...</figcaption> </div> <!-- содержимое figure -->
</figure> <figure> <!-- содержимое figure --> <div> <figcaption>...</figcaption> </div>
</figure>

figcaption может содержать контент потока, который классифицирует большинство элементов, разрешенных как дочерние элементы элемента body. Но, поскольку элемент предназначен для обеспечения подписи к содержимому figure, обычно предпочтителен краткий описательный текст. figcaption не должен повторять содержимое figure или другой контент в первичном документе.

figcaption не является заменой текста alt

Что касается изображений, используемых внутри figure, одно из самых больших недоразумений при использовании figcaption заключается в том, что он используется вместо альтернативного текста изображения. Такая практика описана в HTML 5.2 как некорректная попытка донести значимую информацию, но только тогда, когда изображения публикуются без возможности автора предоставить соответствующий текст alt.

Из руководства HTML 5.2: Такие случаи должны быть сведены к абсолютному минимуму. Если у автора есть хоть малейшая возможность предоставить реальный альтернативный текст, то было бы недопустимо опускать атрибут alt.

figcaption предназначен для предоставления подписи или резюме к figure, привязки его к документу, в котором содержится figure, или передачи дополнительной информации, которая может быть неочевидна при просмотре самого figure.

Если для изображения задано пустое значение alt, тогда figcaption фактически ничего не описывает. И это не имеет особого смысла, не так ли? Давайте рассмотрим figure, содержащий фрагмент кода Sass:

<figure> <pre><code> $align-list: center, left, right; @each $align in $align-list { .txt-#{$align} { text-align: $align; } }
This use of Sass’s @each control directive will compile to
three CSS classes; .txt-center, .txt-left, and .txt-right.

По сравнению с изображениями с пустыми alt внутри figure, это все равно, что вставить фрагмент кода aria-hidden=»true». Это лишит возможности программы чтения с экрана и другие вспомогательные технологии анализировать содержимое, к которому относится заголовок. Однако это, к сожалению, отражение того, что обычно происходит с изображениями в figure.

«Но не очевидно ли, что заголовок должен быть текстом alt для изображения?», — подумаете вы. Есть два нюанса, относительно этого предположения:

Во-первых, что это за изображение? Когда изображение имеет пустой alt, оно не будет объявляться и не будет обнаружено при навигации с помощью программы чтения с экрана. Если не использовать alt для изображении, некоторые программы чтения с экрана сообщали бы имя файла изображения, но не все (программы чтения с экрана, такие как JAWS, имеют параметры для настройки этого поведения. Но поведение по умолчанию для изображений, подобных этим — игнорировать).

Во-вторых, alt предназначен для передачи важной информации, которую представляет изображение. A figcaption должен предоставлять контекст для связи figure (изображения) с основным документом или для выдачи определенной части информации, на которую следует обратить внимание. Если а figcaption заменяет собой alt, то это создает дублирующую информацию для зрячих пользователей.

Существуют и другие проблемы связанные с неправильным использованием figcaption вместо alt изображения. Но чтобы выявить эти проблемы, нам нужно понять, как программы чтения с экрана распознают figure.

figure и программы для чтения с экрана

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

В идеале figure должен объявлять роль и содержимое figcaption, как доступное имя. Человек должен иметь возможность переходить в figure и независимо взаимодействовать с содержимым figure и figcaption. Для браузеров, которые не полностью поддерживают figure, таких как Internet Explorer 11, ARIArole=»figure» и aria-label могут использоваться для увеличения вероятности того, что разметка будет распознаваться некоторыми программами чтения с экрана.

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

JAWS 18, 2018 и 2019

JAWS имеет лучшую поддержку для объявления собственно figure и их подписей, хотя поддержка не является совершенной или постоянной в зависимости от браузера и настроек JAWS.

IE11 требует использования role=»figure» и aria-label или aria-labelled, указывающих на figcaption, чтобы воспроизвести нативные объявления. Неудивительно, что IE11 не поддерживает нативный элемент, так как рейтинг браузера IE11 в HTML5 Accessibility не улучшается. Но, по крайней мере, ARIA aria может предоставить семантику.

Edge не будет объявлять о присутствии роли figure вообще, независимо от того, используется ARIA или нет. Скорее всего, это изменится, когда Edge переключится на Chromium.

Chrome и Firefox предлагают аналогичную поддержку, однако JAWS (с настройками по умолчанию) + Chrome будет полностью игнорировать figure (включая содержимое его figcaption), если изображение имеет пустой текст alt или атрибут alt отсутствует.

Это означает, что те подписи, которые сопровождают изображения в различных статьях Medium, полностью игнорируются JAWS в паре с Chrome. Если настройки JAWS обновляются для объявления всех изображений (например, изображений, в которых не указан атрибут или значение alt), то JAWS с Chrome должен объявлять эти подписи к рисункам.

JAWS с Firefox, в отличие от Chrome, все равно будет объявлять figure и figcaption, если изображение содержит пустой alt или alt отсутствует, но, так как изображение будет полностью игнорироваться, человек с помощью программы чтения с экрана просто сделает вывод, что основным содержимым этого figure было изображение.

NVDA

При тестировании NVDA версии 2018.4.1 с IE11, Edge, Firefox 64.0.2 и Chrome 71 figure не определялся. Самым близким признаком того, что что-то здесь может быть, было то, что NVDA + IE11 объявлял «редактировать» до объявления изображения или содержимого figcaption (хотя это «редактировать» не имело никакого смысла…). Шаблоны тестирования с role=»figure» не изменили это поведение. Содержимое figure по-прежнему было доступно, но связь содержимого и подписи не передавалась.

VoiceOver (macOS)

Тестирование проводилось с Safari (12.0.2) и Chrome (71.0.3578.98) на macOS 10.14.2, с VoiceOver 9.

Safari

При тестировании с Safari, роль figure объявлялась. Роль figure не объявлялась если он не имеет доступного имени (например, нет figcaption, aria-label и т.д.). VoiceOver может переходить в figure и взаимодействовать с основным контентом figure и figcaption отдельно.

Chrome

Хотя инспектор доступности Chrome отмечает, что семантика figure раскрывается, а доступное имя обеспечивается его заголовком, VoiceOver не обнаруживает и не объявляет о присутствии figure, как это происходит в Safari, если figure специально не содержит aria-label. Использование aria-describedby ИЛИ aria-labelledby для figure, чтобы указать на figcaption не выявляет figureв для VoiceOver. Для правильной передачи данных в VoiceOver с помощью Chrome потребуется следующая разметка:

<!-- aria-label должен повторять содержимое figcaption, чтобы объявлять figure, как ожидается. -->
<figure aria-label="Figcaption content here."> <!-- содержимое figure --> <figcaption> Figcaption content here. </figcaption>
</figure>

При добавлении элемента role=»figure» к элементу figure или другому элементу вместо figure, все равно требуется aria-label, чтобы сделать роль доступной для VoiceOver с Chrome.

VoiceOver (iOS 12.1.2)

При тестировании VoiceOver как с Safari, так и с Chrome, не объявлялись ни figure, ни связь содержимого figure с его заголовком. И шаблон figure, и role=»figure» дали одинаковые результаты.

TalkBack (7.2 на Android 8.1)

При тестировании как с Chrome (70), так и с Firefox (63.0.2) не объявлялись ни figure, ни связь содержимого figure с его заголовком. И шаблон figure, и role=»figure» дали одинаковые результаты.

Narrator & Edge 42 / EdgeHTML 17

Narrator вообще не объявляет роли figure. Тем не менее, нативный элемент role=»figure» действительно влияет на способ объявления содержимого figure. Когда figure имеет доступное имя, содержимое figure (например, текст alt изображения) и доступное имя figure (содержимое figcaption или aria-label) будут объявлены вместе. Если изображение имеет пустой alt, figure и его figcaption полностью игнорируют.

Заключение

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

<figure role="figure" aria-label="repeat figcaption content here"> <!-- содержимое figure. если это изображение, предоставляет текст alt --> <figcaption> Caption for the figure. </figcaption>
</figure> <!-- aria-label для macOS VoiceOver + Chrome role="figure" для IE11. Для IE11 нужно доступное имя (предоставляемое aria-label). Если VO + Chrome не поддерживает доступное имя из aria-labelledby, этот атрибут не будет ссылаться / указывать на ID для <figcaption>.
-->

Этот шаблон гарантирует, что следующие пары будут объявлять роль figure и его заголовок:

JAWS с Chrome, Firefox и IE11.

macOS VoiceOver с Safari и Chrome.

Edge с narrator будут создавать связь, но не объявлять роль figure.

В настоящее время мобильные программы чтения с экрана не будут объявлять figure, кроме случаев использования Edge с Narrator или любого браузера в сочетании с NVDA. Но пусть это не удерживает вас от использования элементов в соответствии с их спецификациями.

С переходом Edge на Chromium, поддержка, скорее всего, в ближайшем будущем улучшится. И хотя NVDA и мобильные программы чтения с экрана не объявляют семантику, контент остается доступным. Регистрация ошибок — лучшее, что мы можем сделать на данный момент, чтобы добиться изменений в этих пробелах.

Источник: https://www.scottohara.me/

Редакция: Команда webformyself.