Description

Synonyms: Note, Help, Operation note, Input instruction, Instruction, Accessible Description

Siehe auch: font , text , label , error message , required field label , tooltip , help and support

A description contains additional information on the use and operation of the application (see DIN EN ISO 9241-161: 8.19).

Descriptions can refer to a control element, an area, a screen, or to the entire application. A description consists of an explanatory text, a graphic or a combination of text and graphic.

Descriptions can be

• permanently visible,
• are dynamically shown and hidden during operation (e.g. when hovering with a pointing device, when receiving focus with the keyboard or after enabling a control element).

labels of the control elements are sufficient. Descriptions may be necessary, for example, for an input field at which a particular input format is required.

Note: Therefore, for example, a button should not be described by its appearance or position, but by its label.

Note: Descriptions for a form field, for example, can be displayed to the right or below the field.

Animation). | Must | EN 301 549:
EN 301 549: 9.2.3.1, 11.2.3.1, 9.2.2.2, 11.2.2.2 | | @!256 | Focus visibility | If the description 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, the descriptions must receive the keyboard focus as long as the description is not linked with a keyboard-focusable element.

Note: If the application contains several descriptions that receive the keyboard focus, 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: This applies regardless of how the description is displayed. Frequent variants include:

• button to show an area with the description,
• button to show a tooltip with the description,
• area or tooltip which is shown when hovering using a pointing device or when focusing,
• display using a keyboard shortcut.

Note: This also applies if the description is displayed in a

tooltip.

• It must be possible to close the tooltip with the keyboard without moving the keyboard focus away (e.g. with ESC).
• The tooltip must remain visible until it is explicitly hidden (by moving the keyboard focus away, for example).

Hinweis: Note: This does not apply to tooltips that are shown by the platform software by default.

• It must be possible to close the tooltip with the pointing device without moving the pointing device away.
• It must be possible to move over the tooltip with the pointing device without the tooltip being hidden.
• The tooltip must remain visible until it is explicitly hidden (by moving the pointing device away, for example).

Note: This does not apply to tooltips that are shown by the platform software by default.

Accessibility API). | Must | EN 301 549:
9.4.1.2, 11.4.1.2, 11.5.2.5 | | @!263 | Desktop: Description | Any available visual description that refers to a keyboard-focusable control element must be communicated to the Accessibility API as an Accessible Description of this element.

Note: In this respect, it does not matter whether this description is permanently visible or is only displayed when hovering with a pointing device or when receiving the keyboard focus.

virtual cursor | Should | EN 301 549: 9.1.3.1, 11.1.3.1 | | @!264 | Graphic | If the description contains a graphic that contains content, its equivalent text alternative must be communicated to the Accessibility API. | Must | EN 301 549:
9.1.1.1, 11.1.1.1 |

• JAWS: [label] [role] [required field note] [validation note] [value] [description] [error message] [screen reader operating note] [keyboard shortcut note]
• NVDA: [label] [role] [required field note] [validation note] [description] [keyboard shortcut note] [value]
• Windows Narrator: [label] [role] [value] [required field note] [validation note] [keyboard shortcut note]

Please note:

• The description tends to be given by JAWS and NVDA at the end, and certainly after the label and the role.
• The description is not output by Windows Narrator.
• JAWS and NVDA can be configured so that the description is not output. This feature is used by experienced users of screen readers in order to perceive the content more efficiently. Therefore, only additional information should be included in the description.
• When reading with the virtual cursor descriptions are not generally output by the screen reader. The output of the descriptions only occurs with the TAB navigation. Therefore, only additional information should be included in the description, and the description should only be used with control elements that can receive the keyboard focus.

In HTML, most of the control elements can only be given a description using the title attribute. However, the title attribute is not accessible for the following reasons:

• When using the browser zoom, the tooltip which is displayed using the title attribute is not scaled.
• During the keyboard navigation, the tooltip is not shown (except in the Edge browser) and is therefore imperceptible to sighted keyboard users.
• It is not possible to move over tooltips with the mouse.
• In certain browsers (such as Firefox), the tooltips cannot be hidden without moving the focus away.
• The tooltips cannot be displayed on mobile devices or can only be displayed with difficulty. For these reasons, the title attribute should be avoided.

In HTML, in addition to the title attribute, a few elements can be given a description using another method:

• Buttons marked with the <input type=button|reset|submit> element through the value attribute, unless this is already used for the Accessible Name,
• Buttons marked with the <summary> element through their text content, unless this is already used for the Accessible Name,
• Tables with the <caption> element, unless this is already used for the Accessible Name.

This is designed to ensure, however, that the visible label is at least perceptible by the assistive technology as a description if it is not output as a label (Accessible Name). As the visible label is required to correspond to or at least be contained in the Accessible Name (EN 301 549: 9.2.5.3), none of the three methods should be used for marking up a description.

Further informationen: 3.2.6.1 The title attribute - HTML Standard (whatwg.org) (External Link), Providing Accessible Names and Descriptions | APG | WAI | W3C, 4. Accessible Name and Description Computation - HTML Accessibility API Mappings 1.0 (w3.org)

In ARIA, it is possible to communicate descriptions with the attributes aria-describedby and aria-description.

• With aria-describedby, reference can be made to the IDs of visible or invisible descriptions.
• With aria-description, the description can be specified directly in text form. The attribute is only defined with ARIA 1.3, which means it is not yet supported by older assistive technology.
• Reference can be made to hidden elements using aria-describedby , e.g. those that have been marked with display:none or hidden . The contents of the hidden elements are used for the description of the element with aria-describedby. In such cases, however, the use of aria-description is recommended.

Additional ARIA attributes can be used for the communication of further information to the Accessibility API that has a descriptive character, but is not a description (Accessible Description):

• Error messages with aria-errormessage,
• Placeholders with aria-placeholder,
• Information about keyboard shortcuts with aria-keyshortcuts,
• Reference to a detailed description with aria-details.

Please note: Although the aria-roledescription attribute sounds as though it could be used to describe the role of the element, this is not the case. With aria-roledescription , the role of the element is overwritten, which means that the attribute should be used with caution.

Further informations: aria-describedby property - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (External Link), aria-description property - Accessible Rich Internet Applications (WAI-ARIA) 1.3 (w3c.github.io) (External Link)

• Although a description that is programmatically communicated as an Accessible Description can be more detailed than the label, it should also be concise and meaningful. The description should not be redundant to the label.
• In addition, the Accessible Description should not contain any change of language or structured content, as this is imperceptible with the assistive technology.
• Longer descriptions or descriptions with changes of language or structured content should be implemented in such a way that they can be read with the virtual cursor of the screen reader, i.e. they are available in text form. From the corresponding control element, reference can be made to the detailed description using aria-details details or in a short Accessible Description.
• For each element, it is only possible to communicate a description to the Accessibility API using one method. If several methods are used, only the description whose method has the highest priority is used as the Accessible Description. The priority of the methods is defined as follows:
  1. aria-describedby,
  2. aria-description,
  3. visible label in the case of buttons and tables, unless used for the Accessible Name (see above),
  4. title.
• If the description of a control element occurs explicitly using an attribute (for example, aria-description, aria-describedby, title), the attribute must be situated on the element that receives keyboard focus and has the role of the element to be described. The control element cannot be described by attribute if the attribute is situated on a parent or child element..
• Text content which is shown before or after as pseudo-elements using the CSS selectors are taken into account when determining the description. To avoid this, they should be marked with aria-hidden=true.
• If a reference is made to a form field using aria-describedby, the value of the form field (not its label, however) is taken into account when determining the description of the element using aria-describedby.
• The visible description should not be marked with aria-hidden=true, even if an Accessible Description is available, to ensure that the text-to-speech works using the mouse.
• The visible label should be used as an Accessible Description to avoid a repeated output of the description with the text-to-speech feature.
• To ensure a meaningful reading sequence with the virtual cursor of the screen reader, descriptions should be in the source code, at or within the element which is described, e.g.
  • Input instructions in a form as a child element at the beginning of the <form> element,
  • Input instructions of a form field directly before or after the form field, but after the label of the field under all circumstances.
• Die Attribute title, aria-describedby and aria-description attributes are global attributes, i.e., they can be used with any HTML element and/or ARIA role. It should be noted, however, that most screen readers do not output the Accessible Description when reading with the virtual cursor, which means that these three attributes should only be used for control elements that receive the keyboard focus. There is no problem in using aria-describedby with other elements, provided that the description text to which the attribute refers is also readable with the virtual cursor, i.e. it has not been hidden (e.g. with hidden or aria-hidden=true).

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!