The document is divided into the following sections:

Each section contains several areas, “control elements”, for example, is divided into one section for each specific control element.

The individual sub-sections are divided into:

  • Introduction:

    • Synonyms: Other names for the described UI element, which can also be used to locate the element in the index,
    • Reference to similar elements or related topics,
    • Description of the element or topic,
  • Presentation (requirements concerning the visual presentation)

  • Operation (operating requirements, especially with keyboard and pointing devices)

  • Programming/interfaces (requests for information which are communicated to the Accessibility API .

The requirements are presented in table form:

Unique requirement numberTopic-related classification of the requirementRequirement to be met, supplemented with explanatory notes if necessaryRelevance of the requirement (see Klassifizierung der AnforderungenReferenzen

Note: The validity of the requirements is specified as follows:

  • Web applications: “Web:”
  • Desktop applications: “Desktop:”
  • Hybrid applications: “Desktop:”
  • Valid for all applications: Not applicable

Classification of the requirements

Permalink "Classification of the requirements"

The requirements are classified as follows:

MustLegal requirement according to BITV 2.0

Minimum requirements that must be met to achieve compliance with BITV 2.0
EN 301 549, Version 3.2.1 (External Link)

Note: All the requirements of EN 301 549, sections 11.1 to 11.4, refer to the WCAG 2.1. The numbering of the corresponding requirements from EN 301 549 corresponds to the numbering in the WCAG 2.1.

  • Must
  • May not
ShouldKey requirements that should be met

According to Section 3 (4) of BITV 2.0, efforts should be made to comply with the requirements for certain areas of application: “For central navigation and entry offers, as well as for offers that enable user interaction such as forms and the completion of authentication, identification and payment processes, efforts should be made to achieve the highest possible level of accessibility.”
  • WCAG (External Link) 2.1, AAA criteria
  • WCAG 2.1, A- and AA-criteria that are not a component of section 11 of EN 301 549
  • WCAG 2.2 criteria (draft)
  • Other W3C specifications
  • Other ISO norms
  • Further standards of the DIN EN ISO 9241 series (suitability for use) with special relevance to accessibility
  • should
  • should not
Implementation recommendations, notes
  • Note
  • Can
  • Recommended

The specific requirements concerning the use of the keyboard, i.e. which keys are to be used for which purpose, are classified as follows:

RequiredMinimum requirements
If these requirements cannot be met, the alternate use of the keyboard should be documented.
RecommendedRecommended requirements
The fulfillment of these requirements serves the purpose of easier and more efficient operations with the keyboard.

Note: The requirements regarding the use of the keyboard cannot be classified as “must” or “should”, as EN 301 549 only requires the possibility for the use of the keyboard, but does not define specific keys, as these depend on the respective platform, for example. The elementary guide also contains notes, recommendations and practical tips. These are not standardized. In the notes, recommendations and practical tips, however, “must”, “may not”, “should” and “should not” are used insofar as reference is made to a requirement.

Coverage of the requirements

Permalink "Coverage of the requirements"

The sections on general topics (“application-related requirements” and “element-spanning requirements”) address the dialog-related requirements of EN 301 549 (in particular, section 9 on Web and 11 on Software). The requirements are explained here in general (i.e. not in relation to specific UI elements) and in as much detail as possible (i.e. with possible special cases, exceptions, etc.).

In the sections on individual UI elements (text, graphic, structure, control elements), only the relevant requirements regarding the respective UI element are listed. This article describes what a general requirement means as regards a specific element. However, the requirements are not necessarily explained in detail; i.e. for special cases and exceptions, reference is made to the respective general section.

For example:

  • In the section on the UI element Checkbox the requirement for the visual resizing of the check box is not addressed, because no check box-specific problems or requirements in relation to zooming exist. However, the requirements concerning the resizing can be found in the “resizing” section and also apply to check boxes.
  • In the section on the UI element check box, the specific contrast requirements are described so as to further explain the extent to which the general contrast requirements from the “colors and contrasts” section apply to the check box. However, the special case of the disabled check box is not discussed here, because exceptions for disabled elements are described in the “colors and contrasts” section.

The following elements are not described in this document due to their limited degree of relevance to software:

  • Rich text editor,
  • Video,
  • Audio,
  • Image map,
  • Maps.

However, there is the intention to include these requirements and elements in a future version of the document.

Technology-specific features

Permalink "Technology-specific features"

Some programming languages or frameworks do not allow all the requirements to be met due to limitations to the respective technology. In this case, it should be checked as to whether another programming language or another framework can be used. Alternatively, the requirements should be met as sufficiently as possible. All deviations should be documented in the help and in the accessibility declaration.

This document does not address technology-specific features, but focuses on the expected behavior of the UI elements.

Information about this article

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