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).
No.PropertyDescriptionClassificationReference
246ContrastText descriptions must have a contrast ratio of at least 4.5:1 with respect to the background.

Note: With large font (from 24 px and/or from 18.7 px in the case of bold font), a contrast ratio of at least 3:1 is sufficient.

MustEN 301 549:
9.1.4.3, 11.1.4.3
247ContrastText descriptions should have a contrast ratio of at least 7:1.

Hinweis: Note: With large font (from 24 px and/or from 18.7 px in the case of bold font), a contrast ratio of at least 4.5:1 is sufficient.

ShouldWCAG 2.1: 1.4.6 (AAA)
248ContrastGraphic descriptions must have a contrast ratio of at least 3:1. This applies to the contrast with the background as well as to the areas of content within the graphic.MustEN 301 549:
9.1.4.11, 11.1.4.11
249ResizingIt must be possible to scale the description by up to 200%. During the scaling, the description must remain completely visible and may not obscure other areas of the page or be obscured by them.MustEN 301 549:
9.1.4.4, 11.1.4.4
250ResizingThe description must be displayed in full without horizontal scrolling at a screen width of 320 px.MustEN 301 549:
9.1.4.10, 11.1.4.10
251ComprehensibilityIf additional instructions are required to be able to understand the operation, descriptions with operating instructions must be displayed. @- Note: Descriptions are not necessary if the labels
9.3.3.2, 11.3.3.2
252ComprehensibilityThe description should be formulated in the application language.ShouldEN 301 549: 9.3.1.2
253Reference to sensory propertiesInformation in the description which relates to the elements of the application must not refer exclusively to their sensory properties.

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

MustEN 301 549:
9.1.3.3, 11.1.3.3
254PositionThe descriptions should be positioned so that they can be unambiguously associated with the elements or areas to which they refer.

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

ShouldDIN EN ISO 9241-125: 5.1.1, 5.1.14
255AnimationThe description may not sparkle, flash or be visually changed in any other way (see Animation
EN 301 549: 9.2.3.1, 11.2.3.1, 9.2.2.2, 11.2.2.2
256Focus visibilityIf the description receives the keyboard focus, the focus indicator must be visible (see Focus indicator
9.2.4.7, 11.2.4.7
No.PropertyDescriptionClassificationReference
257Use of the keyboardIn applications that do not support the virtual cursor
9.1.3.1, 11.1.3.1
258Use of the keyboardIf the description is not permanently visible, it must also be possible to display it with the use of the keyboard.

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.

MustEN 301 549:
9.2.1.1, 11.2.1.1
259Use of the keyboardIf the description contains control elements, they must be operable with the keyboard. @- Note: This also applies if the description is displayed in a tooltip
9.2.1.1, 11.2.1.1
260Use of the keyboardIf a description is displayed in an automatically-displayed tooltip, the following must be met:
  • 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.

MustEN 301 549:
9.1.4.13, 11.1.4.13
261Use of the pointing deviceIf a description is displayed in an automatically-displayed tooltip, the following must be met:
  • 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.

MustEN 301 549:
9.1.4.13, 11.1.4.13
No.PropertyDescriptionClassificationReference
262RoleIf the description receives the keyboard focus, an appropriate role (e.g. “text”) must be communicated to the Accessibility API (see Accessibility API
9.4.1.2, 11.4.1.2, 11.5.2.5
263Desktop: DescriptionAny 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.

MustEN 301 549:
9.1.3.1, 11.1.3.1, 11.5.2.5
263BeschreibungIf the description is long or contains structured content, the description should be given keyboard focus and its content can be read using the virtual cursor
9.1.1.1, 11.1.1.1

Practical tip: descriptions in Web applications

Permalink "Practical tip: descriptions in Web applications"
  • 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

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