How do you think “figure” should be used?

• How do you figure?
• Originally written by scottohara
• The Nuggets translation Project
• Permanent link to this article: github.com/xitu/gold-m…
• Translator: Hyde Song
• Proofreader: Xionglong58, Xujiujiu

New to HTML5, the figure and Figcaption elements are designed to create meaningful markup structures:

• Provide a descriptive label for a piece of content,
• The label is associated with the current file, but it is not important to the user’s understanding of it.

For more concrete information, let’s look at each of these elements separately.

figureThe element

The figure element is usually thought of as wrapping around a diagram or diagram, and it can also carry anything (code snippets, references, audio, video, etc.) that is referenced in the main content of the document but not redundant. Figure can be completely deleted in the document flow without affecting the user’s understanding of the main content.

For example, a document describing the unladen Swallow’s air speed might have a section describing the difference between a South African Swallow and a European Swallow. Accompanying the text content may be a figure tag showing the differences between the two birds side by side to complement the information described in the documentation.

In this basic example, figure and Figcaption serve as references. If you remove them, all the text so far still acts as figures.

Image source (2003).

Figure can be used with or without the Figcaption tag. However, using figure without a Figcaption tag or providing other accessible properties (such as aria-label) is of little semantic value. In some cases, no semantics may be expressed if no accessible attributes are given.

figcaptionThe element

Figure Caption Provides a title or summary of the contents of the figure. If you do not use the ARIa-label or aria-Labelledby property on the figure, the Figcaption becomes an accessible property of the figure element.

A figcaption can be placed before or after the figure’s main content, but it must be a direct child of the figure element.

Recommended usage:

<figure> <figcaption>... </figcaption> <! </figure> <figure> <! < figure caption>... </figcaption> </figure> <figure> <figcaption> <div> ... </div> </figcaption> <! --> </figure>Copy the code

Not recommended:

<figure> <div> <figcaption>... </figcaption> </div> <! </figure> <figure> <! <div> <figcaption>... </figcaption> </div> </figure>Copy the code

Figcaption may contain streaming content that sorts most of the children of the body element. However, since the figcaption element serves to provide a title for the figure’s contents, concise descriptive text is often preferred. Figcaption should not repeat the contents of the figure, or anything else in the main document.

figcaptionNot a substitute foraltThe text

One of the biggest misconceptions about using figcaption as the image used in Figure is that it is used instead of image Alt text. As stated in HTML 5.2, this practice is only the last resort for conveying meaningful information if the author does not provide appropriate Alt text for the image.

A note from HTML 5.2:

This should be kept to an absolute minimum. Omitting the Alt attribute is unacceptable if the author has the ability to provide a true alternative text.

Figcaption is used to provide a title and summary for a figure, to associate it with the document that contains the figure, or to convey additional information that may not be obvious when viewing the figure itself.

If you give an image an empty Alt, then the Figcaption actually describes nothing. That doesn’t make sense, does it?

In other words, let’s look at a figure that contains the Sass snippet:

<figure>
  <pre><code>
    $align-list: center, left, right;

    @each $align in $align-list {
      .txt-#{$align} {
        text-align: $align; }} </code></pre> < figCaption > Use Sass's @each loop control to compile three CSS classes; Txt-center,.txt-left, and.txt-right. </figcaption> </figure>Copy the code

Compared to the figure with Alt empty, this is like putting aria-hidden=”true” in the code snippet. Doing so would make it impossible for screen readers and other assistive technologies to parse the content referenced by the title. Unfortunately, however, this mirrors what usually happens with the pictures in figure.

You might think, “Obviously, the title should act like Alt text for an image, right?” . There are two problems with this assumption:

First of all, what is a picture? When the Alt of the image is empty, the screen reader will not show the image and it will not be detected. Some screen readers will display the file name of the image if there is no Alt key in the image, but not all screen readers will (JAWS, for example, has Settings to adjust these behaviors. These images are ignored by default.

Second, the Alt attribute conveys important information about the presentation of the image. Figcaption should provide context to associate the figure with the main document or to display specific information that needs attention. If figcaption replaces Alt, it creates a repetitive message for the visually impaired user.

There are other problems with the misuse of figcaption instead of Alt. But to discover these problems, we need to understand how screen readers parse figures.

figureElements and screen readers

Now that we know how to use figures and their titles, how do these elements look in a screen reader?

Ideally, figure should declare the content of the Role property and figcaption as accessible properties. The user should then be able to find the figure and interact independently with the content of the figure and figcaption. For browsers that do not fully support Figure, like Internet Explorer 11, ARIA’s role=”figure” attribute and aria-label attribute can be used to help improve the likelihood that some screen readers will recognize labels.

Here’s a summary of how screen readers tested display (or not display) this information in different browsers with default Settings:

The 2018 and 2019 versions of JAWS 18

JAWS has the best support for native figures and titles, although the support is not perfect or consistent depending on the detailed Settings of the browser and JAWS.

IE11 needs to use role=”figure”, aria-label, or Aria-Labelledby to point to figcaption to simulate the attributes of native elements. It’s not surprising that IE11 doesn’t support native elements, because the IE11 ratings for HTML5 accessibility will never improve. But at least ARIA can provide semantics.

Edge does not declare the role attribute of figure, whether ARIA is used or not. That may change once the Edge browser switches to the Chromium kernel.

Chrome and Firefox offer similar support, but if an image has an empty Alt or lacks an Alt attribute, JAWS (default detailed setting) Chrome completely ignores figure (including the content of its Figcaption).

This means that the titles that accompany images in various Medium articles are completely ignored by JAWS, which works with Chrome. If JAWS’s Settings are updated to declare all images (such as images that do not provide Alt attributes or values), JAWS uses Chrome to declare these figure titles.

Unlike Chrome, when Firefox is used on JAWS, the Alt of the image is empty or missing, and figure and figcaption are still recognized. But since the picture will be completely ignored, the screen reader will have to infer that the figure is mostly a picture.

NVDA screen reader

No figures were found when testing NVDA 2018.4.1 using IE11, Edge, Firefox 64.0.2, and Chrome 71. The closest sign is NVDA + IE11 declaring “Edit” before declaring the content of an image or figcaption (though “Edit” doesn’t mean anything…). . Testing the role=”figure” pattern did not change the lack of declarations. The contents of the figure are still accessible, but the relationship between the contents and the title is not represented.

VoiceOver (macOS)

The tests were conducted on macOS 10.14.2 using Safari (12.0.2) and Chrome (71.0.3578.98) and using VoiceOver 9.

Safari

When tested using Safari, Figure will show its Role attribute. If there is no semantic attribute (such as no figcaption, aria-label, etc.), the role attribute of figure will not be displayed.

VoiceOver can navigate to a figure and interact individually with the main content of the figure and figcaption.

Chrome

Although Chrome’s accessibility inspector indicates that the semantics of a figure are being revealed and that accessible properties are provided by the title, VoiceOver does not locate or declare the existence of a figure the way Safari does. Unless figure specifically has an aria-label attribute. Using aria-Labelledby or aria-Labelledby on the figure to point to the figure caption, the figure will not be recognized by VoiceOver. In order to properly convey figure to VoiceOver, you need the following tags when using Chrome:

<! Aria-label needs to repeat the caption content and declare the figure as expected. --> <figure aria-label="Figcaption content here."> <! -- Figure Content --> < Figure Caption > Figure Caption content here. </figcaption> </figure>Copy the code

Add a role=”figure” attribute to the figure element, or replace

VoiceOver (iOS 12.1.2)

When I tested Safari and Chrome with VoiceOver, I didn’t show the figure or the relationship between the figure’s contents and the title. Both the

TalkBack (Version 7.2 on Android 8.1)

When I test Chrome (70) and Firefox (63.0.2), I don’t show any figures or the relationship between the figure content and its title. Both the

Narrator & Edge 42 / EdgeHTML 17

Anna doesn’t show the role of figure at all. However, native elements and role=”figure” do have an impact on how the contents of figures are declared. When a figure has semantic properties, the figure’s content (such as the Alt text of the image) and the figure’s semantic properties (Figcaption content or aria-label) are displayed simultaneously. If the Alt value of the image is empty, the figure and its figcaption are completely ignored.

conclusion

Based on the intended use cases for Figure and its titles, and the current support for these elements in screen readers, the following markup patterns should be considered if you want to ensure that the semantics are communicated to the widest possible audience:

<figure role="figure" aria-label="repeat figcaption content here"> <! -- figure content.ifAn image, provide Alt text --> <figcaption> Figure </figcaption> </figure> <! -- Use aria-label compatible with macOS VoiceOver and Chrome using Role ="figure"Compatible IE11. Internet Explorer 11 requires an accessible property (provided by aria-Label). If it weren't for the fact that VO + Chrome doesn't support an accessible property: Aria-Labelledby, that property would take precedence/point to the ID of <figcaption>. -->Copy the code

This pattern ensures that the following collocations show the role attribute of figure and its title:

• JAWS comes with Chrome, Firefox and IE11.
• MacOS VoiceOver comes with Safari and Chrome.
• Edge and Anna will create a relationship, but not declare itfigureThe role attribute of.

Currently, figure is not displayed by mobile screen readers, nor by Edge browsers unless paired with Anna (similarly), or any browser paired with NVDA. But don’t let these gaps prevent you from using elements as the specification expects.

With Edge moving to the Chromium kernel, better support may become a reality in the near future. Although NVDA and mobile screen readers have no declarative semantics, the content is still accessible. Documenting bugs is the best thing we can do right now to make a difference to those bugs.

Thanks for clicking On Steve Faulkner to review my test and read this article.

Develop reading

Here are more resources on Figure and Figcaption and the test page/results used above, as well as bugs from JAWS and NVDA archives:

• HTML Accessibility API Mappings 1.0: figure and figcaption elements, W3C
• HTML5 Accessibility
• HTML5 Doctor: figure and figcaption, (2010)
• HTML5 Accessibility Chops: the figure and figcaption elements, Steve Faulkner (2011)
• ARIA 1.1: figure role
• figure and figcaption test page
• JAWS + Chrome bug filed
• NVDA bug to support figures

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.