Graphic

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 ).

Practical tip: color coding).

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

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

Practical tip: contrast adjustment). | Should | EN 301 549:
11.7 | | @!299 | Contrast | Graphics 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.

Images 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 | Must | EN 301 549:
9.1.4.5, 11.1.4.5.1.1 | | @!301 | Alternative text | Complex 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.

Animation). | Must | EN 301 549:
11.2.3.1, 9.2.2.2, 11.2.2.2 | | @!303 | Focus visibility | If the graphic receives the keyboard focus, the focus indicator must be visible (see

Focus indicator). | Must | EN 301 549:
9.2.4.7, 11.2.4.7 |

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.

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

Accessibility API). | Must | EN 301 549: 11.5.2.5 | | @!306 | Name | The graphic must have a concise and meaningful alternative text which is communicated to the Accessibility API as an Accessible Name. | Must | EN 301 549: 9.1.1.1, 11.1.1.1 | | @!307 | Description | Complex graphics must be accompanied by a detailed text alternative that describes all the relevant content of the graphic in full. | Must | EN 301 549: 9.1.1.1, 11.1.1.1 | | @!308 | Operation | In applications that do not support the

virtual cursor , it must be possible to access and exit the graphic with the assistive technology. | Must | EN 301 549: 9.1.1.1, 11.1.1.1 | | @!309 | Desktop: Position | The size and position of the graphic must be communicated to the Accessibility API (see Focus visibility). | Must | EN 301 549: 11.5.2.5, 11.5.2.13 |

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)

• 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

Date:

15.01.2024

License:

CC-BY-SA 4.0

Version:

1.0

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