Synonyms: Graphical element, icon, image, illustration, content-bearing graphic, pixel graphic, vector graphic, image

See also: Layout graphic

Graphics are used to convey information in a visual, non-textual format.

Note: Additional requirements concerning graphics which communicate the status, value, role or labeling of an element are described at the respective element and/or in the corresponding sections (e.g. element status, label).

No.PropertyDescriptionClassificationReference
295ContrastAll content of graphics must have a contrast ratio of at least 3:1. This applies to the contrast of the graphic with the background as well as to the contrasts within the graphic (between neighboring areas) insofar as they are relevant to the conveying of the information.

Exceptions:
  • disabled elements,
  • graphics that cannot be changed without distorting them, such as logos, flags, screenshots, heat maps or medical charts,
  • graphics that have a visible and equivalent text alternative.

Note: If graphics do not have sufficient contrast and are classified as one of the exceptions, they must not be used as labels for control elements or convey relevant information.

MustEN 301 549:
9.1.4.11, 11.1.4.11
296Color codingIf information is conveyed using different colors within a graphic or between different graphics, then all colors (each with respect to the others) must have a contrast ratio of at least 3:1 (see Practical tip: color coding).

Note: This applies if the colors themselves have no meaning, but only the color difference does.

ShouldEN 301 549: 9.1.4.1, 11.1.4.1
297Color codingIf information is conveyed using a particular color within a graphic, this information must also be conveyed in another way (see practical tip: color coding).

Note: This applies when the color itself has a meaning, such as “green” for correct and “red” for incorrect.

ShouldEN 301 549: 9.1.4.1, 11.1.4.1
298ContrastGraphics should be clearly visible when using Windows Contrast Adjustment (see Practical tip: contrast adjustment).ShouldEN 301 549:
11.7
299ContrastGraphics should not be used as background graphics for text, as this affects their readability.

Note: This can lead to insufficient contrast, especially when users adjust the text color or font size according to their requirements.

ShouldEN 301 549:
11.7
300TextImages of text may not be used unless their text content can be adapted to the user requirements (font style, font size, font color, background color).

Exception: Logos
MustEN 301 549:
9.1.4.5, 11.1.4.5.1.1
301Alternative textComplex graphics must have a detailed description in text form.

Note 1: The detailed description should either be displayed at the graphic, or it should be possible to show it or access it at the graphic using a control element.

Note 2: The complex graphic itself must have a concise alternative text. It is recommended that this makes reference to the detailed description.

MustEN 301 549:
9.1.1.1, 11.1.1.1
302AnimationThe graphic may not sparkle, flash or be visually changed in any other way (see Animation).MustEN 301 549:
11.2.3.1, 9.2.2.2, 11.2.2.2
303Focus visibilityIf the graphic receives the keyboard focus, the focus indicator must be visible (see Focus indicator).MustEN 301 549:
9.2.4.7, 11.2.4.7
No.PropertyDescriptionClassificationReference
304Use of the keyboardIn applications that do not support the virtual cursor, it must be possible to access and exit the graphic with the keyboard (see Use of the keyboard table, below).
Exception: If the graphic serves as a label for a control element or conveys its role, status or value, the control element should receive the keyboard focus and not the graphic.

Note: If the application contains several graphics, there should be an operating mode in which only the interactive elements receive the focus to avoid unnecessary navigation steps for sighted keyboard users.

MustEN 301 549:
11.1.1.1

Use of the keyboard: graphic

Permalink "Use of the keyboard: graphic"

Note: The following requirements only apply if the graphic has to be accessible with the keyboard (see above).

ActionKeyClassification
Focusing graphicTABRequired
Exiting the graphicTABRequired

Use of the pointing device: graphic

Permalink "Use of the pointing device: graphic"
ActionKeyClassification
Showing the tooltipHoverRecommended
No.PropertyDescriptionClassificationReference
305RoleThe “graphic” role must be communicated to the Accessibility API (see Accessibility API).MustEN 301 549: 11.5.2.5
306NameThe graphic must have a concise and meaningful alternative text which is communicated to the Accessibility API as an Accessible Name.MustEN 301 549: 9.1.1.1, 11.1.1.1
307DescriptionComplex graphics must be accompanied by a detailed text alternative that describes all the relevant content of the graphic in full.MustEN 301 549: 9.1.1.1, 11.1.1.1
308OperationIn applications that do not support the virtual cursor , it must be possible to access and exit the graphic with the assistive technology.MustEN 301 549: 9.1.1.1, 11.1.1.1
309Desktop: PositionThe size and position of the graphic must be communicated to the Accessibility API (see Focus visibility).MustEN 301 549: 11.5.2.5, 11.5.2.13

Practical tip: graphics in Web applications that communicate a role, status, or value

Permalink "Practical tip: graphics in Web applications that communicate a role, status, or value"

The HTML standard elements do not have to be considered with regard to the graphics that communicate information about role, status or value, because the corresponding information is automatically communicated correctly by the browser to the Accessibility API.

In the case of custom elements that are implemented with ARIA roles and ARIA attributes, the graphics that convey information about the role, status, or value should be marked as layout graphics. Instead, the information should be programmatically communicated, e.g. with the following attributes:

  • role for the role,
  • aria-valuenow and aria-valuetext for the value,
  • aria-required for required fields,
  • aria-invalid for incorrect form fields,
  • aria-checked and/or aria-selected for the “selected” status,
  • aria-disabled for disabled control elements,
  • aria-pressed for the “pressed” and/or “not pressed” status,
  • aria-expanded for the “reduced”/“hidden” and/or “expanded”/“shown” status
  • aria-haspopup for elements that show a menu, selection list, tree structure, table, or dialog when they are enabled,
  • aria-sort for the sorting direction,
  • aria-current for marking the current element.

Insofar as no ARIA attribute exists for the relevant information, the information should be communicated in text form as part of the label or description of the element.

Further information: Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (External Link)

Practical tip: graphics in Web applications

Permalink "Practical tip: graphics in Web applications"
  • JAWS: [alternative text] graphic
  • NVDA: Graphic [alternative text]
  • Windows Narrator: [alternative text] image

The way in which graphics are marked and labeled depends on the method which is used for the presentation of the graphic:

  • Graphics marked with the <img> element are labeled with the alt attribute.
  • Buttons with graphic labeling which are marked with the <input type=image> element are also labeled with the alt attribute.
  • All other graphics should be marked with role=img and explicitly labeled with aria-label or aria-labelledby. This also applies, for example, to the elements <svg> and <canvas>, CSS background graphics, font icons and letters that are used in a graphical context (e.g. “x” for “deleted”).
  • Graphics for list characters (list-style-image) cannot be provided with an alternative text or marked as layout graphics and should not therefore be used.

In this case, the following exceptions apply:

  • Graphics that are used for the labeling of control elements can be marked as layout graphics. Instead, the control element is expressively labeled (e.g. <button title=delete><img src=… alt></button>, <button aria-label=delete><img src=…></button>). If the control element is labeled using aria-label or aria-labelledby, the contained graphic automatically becomes the layout graphic, and does not have to be marked separately as such.
  • The screen readers provide the relevant information concerning the elements (label, role, status, value) which are located within <svg> and <canvas> if the respective <svg> and/or <canvas> element is not marked as a graphic. This means, for example, that the <svg> and/or <canvas> element can be labeled as a group with role=group and with aria-label or aria-labelledby. In this case, it is not directly perceptible with the screen reader that it is a graphic (this information can be communicated indirectly through the labeling of the group, however), but it is possible to communicate detailed and structured text alternatives within the graphic elements, in the case of diagrams, for example.
  • Font icons or graphics that are shown before or after as pseudo elements using the CSS selectors may also be provided with an alternative text directly in the CSS in the future ( 1.2. Alternative Text for Accessibility - CSS Generated Content Module Level 3 (w3.org) (External Link)). At present, this is not yet reliably supported by the assistive technology, however.

Further information: 4.8.3 The img element - HTML Standard (whatwg.org) (External Link), Images Tutorial | Web Accessibility Initiative (WAI) | W3C

Information about this article

You are welcome to send feedback by email about our handout!