Accessible design of user interface elements

Foreword

Online betrachten

According to the objectives of the “Accessible Information Technology Ordinance” (BITV 2.0), modern information and communications technology should be designed so that, as far as possible and as a general rule, it is accessible without any restriction.

There is considerable ambiguity as regards the implementation, as the existing specifications leave a lot of scope for interpretation.

These discrepancies frequently lead to differing interpretations of the existing specifications, and in the event of the acceptance of artifacts or entire ICT systems, to annoyance, and in some cases, legal disputes.

The authors of this document have taken on the task of closing this gap between the legal requirements, guidelines, standards and existing design guides or style guides – also from software manufacturers.

The visual user interface elements described in DIN EN ISO 9241-161 have been considered for this purpose, supplemented by additional elements and extended with regard to the accessibility requirements in accordance with EN 301 549 v3.2.1. Requirements have been defined for each UI element in terms of presentation, operation and programming/interfaces.

This reference guide serves as a supplement to DIN EN ISO 9241-161 and as an aid for the implementation of EN 301 549 v3.2.1, and is not intended to replace the currently valid legal requirements or guidelines. On the contrary, this collection is based on and subject to a corresponding update process.

Table of contents

• Goals and target group

• Scope of validity

• Notes for the reader

Goals and target group

Online betrachten

This document attempts to fill the following gaps in the accessibility publications:

• For Web documents, in W3C, there are several specific examples of how accessible pages must be designed (see, for example How to Meet WCAG (Quickref Reference) (w3.org) (External Link)). Corresponding documents are not available for software.

• Section 11 of EN 301 549 details the requirements concerning software. These requirements are of a general nature. There is no description of how UI elements must be specifically implemented in order to meet the requirements. For desktop software, there is no equivalent to the WAI-ARIA Authoring Practices ( WAI-ARIA Authoring Practices 1.2 (w3.org) (External Link)).

• In the form of WCAG2ICT ( Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT) (w3.org) (External Link)) in 2013, W3C published a document describing the way in which the WCAG requirements can be applied to software and documents. This document is outdated, however, and does not contain the requirements of the current WCAG 2.1.

The document is primarily aimed at software developers.

Other roles in the field of software development for which the document may be helpful include

• Design (especially with regard to the requirements of fonts, colors an contrasts and the information in the “presentation” sections for each UI element),

• Editing for the text content of the software and Help,

• Accessibility test,

• Disabled people who use software (to familiarize themselves with common keyboard conventions, for example, refer to the “use of the keyboard” sections for each UI element).

Scope of validity

Online betrachten

Scope of validity

This document describes the accessibility requirements for Web and Desktop software as well as hybrid applications (which combine Web and Desktop technologies) which operate on the Microsoft Windows platform software and which have an open functionality. The requirements are primarily derived from EN 301 549 (version 3.2.1, sections 9 and 11).

This document does not initially apply to the following software:

• Software with closed funktionality (Section 5.1 of EN 301 549),

• Software for two-way voice communication (section 6 of EN 301 549),

• Software with video functionality (section 7 of EN 301 549),

• Help authoring tools (section 11.8 of EN 301 549),

• Software with access to transposition or emergency services (section 13 of EN 301 549),

• Software that runs on platform software other than Microsoft Windows (such as Unix, Linux, Chrome OS, macOS, iOS, Android),

• Assistive technology,

• Platform software,

• Apps for mobile devices (such as tablets or smartphones).

In addition, this document does not apply to:

• Hardware (section 8 of EN 301 549),

• Documents (section 10 of EN 301 549), even if the documents are interactive (e.g. spreadsheet with macros, PDF with form)

Many of the requirements described here can be transferred to software from other platforms.

Notes for the reader

Online betrachten

Layout of the document

The document is divided into the following sections:

• Application-related requirements, which apply to the whole of the software,

• Element-spanning requirements, which apply to all or several UI elements,

• Text elements,

• Grafical elements,

• structural elements (for the structuring of the dialog boxes in individual areas),

• control elements,

• Composite control elements (complex control elements which consist of several simple control elements).

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:

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

The requirements are classified as follows:

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

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

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.

Coverage of the elements

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

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.

Application-related requirements

Online betrachten

Table of contents

• Conforming alternate version

• Application language and change of language

• Error prevention and correction

• Help and support

• Resizing

• Accessibility API

• Authentication

• Animations

• Navigation sequence

• Changes of context

• Time limits

Conforming alternate version

Online betrachten

If the application fails to meet all the accessibility requirements, a conforming alternate version can be made available. In this respect, however, the following requirements must be met:

• The conforming alternate version meets all the requirements, i.e. it is completely accessible. If several alternative versions are offered, at least one alternative version is fully conforming. Therefore, offering specific alternative versions for individual user groups which only meet the requirements of the respective group is not permitted unless there is no alternative version which fulfills all the requirements of all user groups.

• The conforming alternate version is equivalent in terms of all its content and functions to the version which is not accessible. This means that the alternative version may not contain outdated information. Insofar as the standard version is offered in different languages, the alternative version must also be offered in the languages.

• The conforming alternate version can be achieved in an accessible way. This means:

  • The function for changing to the conforming alternate version must be accessible.

  • The standard version may not contain any keyboard traps or flashing content. In addition, the standard version may not contain any moving, flashing, automatically updating or acoustic content that cannot be stopped (https://www.w3.org/TR/WCAG21/#cc5).

  • Alternatively, both the conforming and standard version can be achieved using an accessible screen (e.g. the login screen), or the conforming alternate version is the standard version.

• The purpose and achievement of the conforming alternate version is explained in the documentation.

• The Support Service can explain the purpose and achievement of the conforming alternate version (to comply with EN 301 549, section 12.2.2).

It is recommended that only one version of the application is offered at a time and that it is designed so that it is accessible.

Note 1: A typical use case for a conforming alternate version is when the standard version of the Web application does not meet the contrast requirements for content consisting of text or graphics due to the corporate design. In this case, the conforming alternate version can use a CSS marking that provides for sufficient contrast.

Note 2: For selected Web applications that are already largely accessible, an overlay tool may be able to generate a conforming alternate version that fully meets the above requirements. However, this is usually not the case, especially if the Web application has problems that cannot be found and fixed automatically. Therefore, an overlay tool cannot be used as a standard to provide a conforming alternate version ( Monitoring Center of the German Federal Government for the Accessibility of Information Technology - Publications - Joint Assessment of the Monitoring Centers of the Federal Government and Federal States for the Accessibility of Information Technology on the use of Overlay Tools (bfit-bund.de) (External Link))

Note 3: For desktop applications, EN 301 549 does not make any statements about alternative versions. However, it may be assumed that the same requirements apply to desktop applications.

Application language and change of language

Online betrachten

Synonyme: Language

See also: labels, description, text, font

Foreign-language content can be difficult for disabled people to understand. This is especially the case if such content is output by the text-to-speech software with the incorrect pronunciation.

Presentation

Programming/interfaces

Error prevention and correction

Online betrachten

Synonyms: Error message, error messages, input instructions, context-specific help

See also: Required field labeling,, description, help and support,, authentication, form

Error messages inform users about incorrect entries or incorrect operations. Error messages help with the correction of errors. Error messages can be displayed

• after submitting a form,

• when filling out a form, or

• when operating the software.

Input instructions help users to avoid errors. These can be displayed

• on the form,

• on the respective form field, or

• when operating the software.

Presentation

Programming/interfaces

Help and support

Online betrachten

Synonyms: Manual, documentation, support, help

See also: description, error messages

Presentation

Operation

Use the keyboard: Help

Resizing

Online betrachten

Synonyme: Scaling, adjusting the font size, zoom

See also: font, text

The following requirements should ensure that the font size can be adjusted to the user preferences without assistive technology.

Presentation

Accessibility API

Online betrachten

Synonyms: Accessibility interface, interoperability with assistive technology, compatibility with assistive technology, platform support for accessibility services for assistive technology, programming interface for assistive technology

See also: Element status, changes of context, contrast adjustment

Assistive technology such as screen readers, screen magnifiers, Windows Contrast Adjustment and voice input software do not generally interact directly with the software or the browser, but using an interface for the accessibility which is made available by the operating system, for example: the Accessibility API (Application Programming Interface). The software and/or browser sends all the relevant information to the Accessibility API in standardized form, and the assistive technology accesses the information which is made available in the Accessibility API. However, the assistive technology only uses the information from the Accessibility API, which is relevant based on the needs of the user. If applications are operated using assistive technology, to a certain extent the operation does not take place directly, but is also conveyed using the Accessibility API.

The best-known Accessibility APIs on Microsoft Windows are:

• IAccessible2,

• MSAA (Microsoft Active Accessibility, Standard 1997-2005),

• UIA (Microsoft UI Automation, Standard seit 2005).

Windows applications should use the current Accessibility API UIA.

Software which does not use the Accessibility API of the operating system can implement its own interfaces for the communication of information to the assistive technology. In this context, Java applications use the Java Accessibility API (JAAPI).

The following information, for example, is communicated by the software and/or the browser to the Accessibility API and read out by the assistive technology if required:

• Role of an object (e.g. heading, check box, table cell),

• Status of an object (e.g. focused, focusable, disabled, open),

• Labeling of an object,

• Description of an object,

• Value of an object (e.g. for form fields),

• Possible values (e.g. maximum and minimum values in the case of specific form fields),

• Position in the object hierarchy (e.g. parent and child objects, amount of sibling objects, position relative to sibling objects),

• Spatial size and location in terms of the current screen area,

• Events (e.g. change of object properties).

Please note:

• Most programming languages which are usable for software development purposes support an Accessibility API. This applies to browsers as well.

• In this respect, the Accessibility API is usually supported automatically as long as the default elements of the programming language or markup language (e.g. HTML) are used. For example, if the language provides input fields as a control element, then the role, value, status, position in the object hierarchy, size, and location of the input field will be communicated correctly to the Accessibility API. In most cases, it is necessary for the visible label to be linked to the input field correctly so that it is also communicated to the API as the label of the input field.

• This applies in the same way to the standard characteristics of the programming language or markup language, which are communicated to the Accessibility API automatically. If an input field is provided with the “disabled” characteristic for example, the “disabled” and “not keyboard focusable” characteristics are communicated to the API automatically. 05.15.2023 Page 20 of 317

• Depending on the programming language or markup language used, it may be the case that certain characteristics of the object that are to be communicated to the Accessibility API must be explicitly specified (i.e. in text form), as otherwise they cannot be communicated.

• Unless a default element of the programming language or markup language is used, the developers are required to ensure that all the relevant object information is communicated to the Accessibility API correctly. If the language does not provide a possibility to explicitly define this information, only default elements should be used.

• If a programming language does not support an Accessibility API or it does not offer an alternative form of access to the required information through the various assistive technology, it should not be used, or the software must then meet the requirements detailed in Section 5.1 (closed functionality) of EN 301 549.

Programming/interfaces

Practical tip: Accessibility API with desktop applications

The default elements of the platform software or the framework used typically communicate the correct information to the Accessibility API automatically. They should therefore be used with preference.

Example 1:

• The following figure shows the “Save as” dialog of the “Windows Fax and Scan” application.

• A complete list of the information which is communicated to the Accessibility API for the “file name” input field which is located in this dialog (read out with Accessibility Insights for Windows) is also shown.

• In addition, the text-to-speech output of the screen reader JAWS is displayed during the focusing of the “file name” input field. For the acoustic output, JAWS only uses the Accessibility API information which is relevant in the current context (e.g. label, role, value, keyboard shortcuts), partially translates this information into the application language (e.g. the “Edit(50004)” role into “input field”), and supplements this information with its own operating instruction (“add text”), which is derived from the communicated role.

If custom elements are used, attention should be paid to the following in particular:

• the communicated role corresponds to the visual presentation and operation (in particular the use of the keyboard),

• the value and status should be communicated to the Accessibility API,

• the label is communicated to the Accessibility API as the Accessible Name,

• if available, the keyboard shortcuts, description) (as Accessible Description) and labels of the groups are also communicated to the Accessibility API,

• Updates concerning the value, status, label, etc. are communicated to the Accessibility API (note: the role of an element should not be changed).

If a custom element is implemented, it is often recommended that a related default element is used and customized accordingly, as it is then possible to use the basic functionality of the default element.

The corresponding characteristics of the Accessibility API should be used for the communication of the information. If there is no corresponding characteristic for sending the information in the Accessibility API or if the framework used does not support this characteristic, the information must be communicated in text form (i.e., as part of the Accessible Name or the Accessible Description).

For example: Disabled elements

• Disabled elements can usually be marked as disabled with an attribute. In the Accessibility API UIA, this corresponds to the IsEnabled:false characteristic. Assistive technology detects that the element is disabled due to this characteristic.

• If a programmatic marking as disabled is not possible, alternatively, the following options can be applied:

  • The element is removed.

  • The element is not designed as focusable (as long as it does not send any information and is not located within a range which can be read with the virtual cursor).

  • The element is named as “disabled” in the Accessible Name or Accessible Description.

For example: Button with value

• A button can have no value by default. Using Windows, however, it is possible to create a “button with value” custom element, which is based on the default button element. The value is then communicated to the Accessibility API UIA as the value of the Value characteristic.

• In HTML and ARIA, it is not possible to assign a value to a button. If the “button with value” is to be used in a hybrid application which is based on Web technologies, the value must be communicated in text form as part of the Accessible Name or the Accessible Description.

The communication of information about the corresponding characteristics of the Accessibility API is always to be preferred over the communication of such information in text form (as part of Accessible Name or the Accessible Description) for the following reasons:

• the assistive technology is able to output the characteristics which are communicated using the API in a way which is defined by the application or by the users,

• the assistive technology is able to translate the characteristics communicated using the API into the correct language,

• the assistive technology is able to output operating instructions or to offer operating modalities according to the characteristics which are communicated using the API,

• the assistive technology is able to offer a specific form of presentation based on the characteristics communicated using the API (e.g. a specific color when using ontrast adjustment),),

• the assistive technology is able to output the characteristics (such as role, status, value) in a specific sequence, which ensures that relevant information is output first and that users are able to identify which information belongs to which type of characteristic,

• if required, users can configure their assistive technology so that they do not wish to receive outputs for certain characteristics.

None of this is possible if the information is only communicated in text form.

Example 2: The following figure shows three buttons with the label “Submit”, “Check” and “Delete”.

• The “Submit” button is visually identifiable as operable (black text color).

• The “Check” button is visually identifiable as disabled (gray font color). The button is programmatically marked as disabled. This implementation is to be preferred for disabled buttons.

• The “Delete” button is also visually identifiable as disabled (gray font color). The button is not programmatically marked as disabled, but only has one tooltip with the word “disabled”. This implementation may only be selected for disabled buttons if no programmatic marking as disabled is possible in the technology which is used.

The following figure shows the same buttons from the previous figure, but when using Windows Contrast Adjustment (Contrast no. 1).

• The “Submit” button is correctly visually identifiable as operable (white text color).

• The “Check” button is correctly visually identifiable as disabled (green font color).

• The “Delete” button is displayed as operable (white text color), although it is disabled. The reason for the incorrect presentation is that it was not programmatically marked as disabled, but only as disabled in terms of its color. The color information is lost when using Windows Contrast Adjustment, however, so that a different visual presentation must be used here for the identification of the “disabled” status (e.g. a strike-through).

The following figure shows the acoustic screen reader output of the three buttons from the previous figure (with the example of the JAWS element overview).

• The “Submit” button is correctly output as operable (“button” role).

• The “Check” button is correctly output as disabled (“not available” status).

• The “Delete” button is incorrectly output as operable (“button” role), as the “disabled” status is only communicated by tooltip, and the tooltip content is only output by the screen reader with certain navigation methods.

In the three following figures, the output of the three buttons from the preceding figures is shown on the Braille line (with the example of JAWS).

• The “Submit” button is correctly output as operable (“button” role) which is shown with the abbreviation “sltr”).

• The “Check” button is correctly output as disabled (“not available” status, which is shown with the abbreviation “xx”).

• The “Delete” button is shown as disabled (“disabled” description), but the output is not in the abbreviated form, not at the expected position, and is not translated into the language of the user.

Authentication

Online betrachten

Synonyme: Sign in, sign out, login, logout

See also: Changes of context, time limits, password input field

The authentication encompasses the processes of signing in and out of an application or within an application. Logging in may be required to be able to use an application or certain parts of the application.

Note: Requirements regarding the authentication control elements (such as input fields, password input fields and buttons) are described for the respective element.

Presentation and operation

Programming/interfaces

Animations

Online betrachten

Synonyms: Sparkling, flashing, updates, flash

See also Time limits, carousel, Video, progress bar

Animations are:

• automatic visual changes or

• unexpected visual changes when using the application.

Examples of automatic visual changes:

• moving text,

• automatically started video,

• automatically scrolling content,

• sparkling or flashing content,

• content that is automatically updated after a certain time.

Examples of unexpected visual changes when using the application are:

• content is additionally animated when scrolling in the screen,

• content is scrolled through at different speeds when scrolling in the screen,

• manually started video contains flashing content,

• flashing error message which is shown after sending a form,

• when viewing content, the content is not displayed immediately, but shown in animated form (e.g. scaled, shifted, rotated or changed in terms of its transparency).

Presentation

Programming/interfaces

Navigation sequence

Online betrachten

Synonyms: Tab sequence, focus order

See also: Use of the keyboar, Changes of context, Time limits

The navigation sequence decides the sequence in which the elements and areas to be focused with the keyboard receive the focus. Typically, this applies to the following navigation methods:

• Navigating between the elements with the tab key,

• Navigating within the elements with the arrow keys,

• Navigating between areas (e.g. with the F6 key),

• Quick navigation (e.g. with PAGE UP, END).

Operation

Practical tip: navigation sequence in Web applications

HTML

The correct navigation sequence should be controlled by the order of the elements in the source code. The tabindex=0 attribute should not be used. The autofocus attribute should only be used with caution, as the contents before the automatically focused element are only perceptible with difficulty for visually impaired or blind people. There are applications in which autofocus can be put to good use, however, e.g. on a login page for the focusing of the first input field. Further information: 6.6.3 The tabindex attribute - HTML Standard (whatwg.org), 6.6.7 The autofocus attribute - HTML Standard (whatwg.org)

ARIA

The correct navigation sequence should be controlled by the order of the elements in the source code. The tabindex=0 attribute must be used for control elements that would not otherwise receive the keyboard focus. Elements that should be focusable by JavaScript but are not automatically in the TAB circuit are marked with tabindex=-1. This applies, for example, to buttons in toolsbars, Einträge in selection lists oder radio buttons within a group of radio buttons. In these cases, just one button, one list entry and/or one radio button is marked with tabindex=0 and all others are marked with tabindex=-1. Further information: Developing a Keyboard Interface | APG | WAI | W3C

Practical tip: efficient navigation in applications

If the current application window contains several focusable elements, users who depend on the use of a keyboard cannot navigate through the window efficiently because they have to use the TAB key to navigate through these elements. To allow for an efficient form of keyboard navigation, it is recommended that one or more of the following methods are implemented and documented in the Hilfe option:

• Area navigation (e.g. with F6),

• Skip links at the start of the window and/or before areas with several navigation steps,

• keyboard shortcuts for frequently required functions and/or control elements,

• Designing areas with several navigation steps so that they can be shown and hidden (e.g. Menu with sub-menus, tabs, accordion),

• Outsourcing of contents with several navigation steps to secondary screens (e.g. in dialog windows which can be opened separately),

• Use of grouping elements that are navigated within using the arrow keys instead of the TAB key (e.g. toolbar, menu),

• with applications that do not support the virtuellen Cursor: Mode in which control elements receive the focus only.

Changes of context

Online betrachten

Synonyms: Updates, change of context

See also: Animations, time limits, navigation sequence, modal dialog

Changes of context are:

• Changing to another program,

• Changing of the view port (e.g. switching to another application window),

• Changes to the keyboard focus,

• Changing the content that changes the meaning of the page.

Changes of context expected and required during operation include:

• Enabling a link: Opening a new screen,

• Enabling a Help link: Open Help, possibly in another application (e.g. in a browser or PDF reader),

• Enabling an internal page link: Scrolling to the linked location and changing the keyboard focus,

• Enabling a Submit button: Opening a new screen,

• Enabling a Delete button: Removing the element to be deleted, possibly changing the keyboard focus if necessary (as the delete button has been disabled or removed),

• Enabling the Logout button: Logout from the application,

• Enabling a Menu button: Opening the menu and focusing of the first menu item,

• Enabling a button to open a modal dialog: Opening the dialog and focusing of the first element in the dialog,

• Page scrolling: change of the visible area,

• Navigation with the keyboard (e.g. with the tab key): Change of the keyboard focus, possible change of the visible area (if the focused element is not situated in the visible area),

• Navigating through a radio button group in which there are associated form fields behind each radio button which can only be operated depending on the radio button: The form elements are enabled when the radio button is selected, the other form elements are disabled.

• Navigation through a group of tab panels: The corresponding tab is shown (alternatively, only after the enabling of the tab panel).

Examples of unexpected changes of context which must be avoided or announced:

• Enabling of a check box within a form: Showing additional form fields that are visually located in the navigation sequence before the check box,

• Text input in an input field: Deleting of entries already made in other fields because the entries in this field and the other fields are mutually exclusive,

• Text input in an input field: After reaching the maximum number of characters, the focus is placed in the following input field,

Examples of unexpected changes of context which have to be avoided or announced:

• Enabling a link: Opening a new screen in another application,

• Enabling of a tab panel: The displayed tab or an element in it receives the focus.

Examples of unexpected changes of context which must be avoided:

• Navigation through a group of radio buttons: Opening a new screen,

• Navigation through a table: Opening a modal dialog,

• Fully filled out form: Submitting the form,

• Focusing of a Submit button: Submitting the form,

• Focusing of the Delete button: Removing the element to be deleted.

Operation

Programming/interfaces

Time limits

Online betrachten

Synonyme: Timeout, Time limit

See also: Animations, changes of context, authentication, carousel

Time limits are specified time constraints in which to view content, operate elements or complete tasks. Time limits may occur, for example, if

• an automatic logout occurs after a certain period of inactivity,

• a PIN required for authentication is only valid for a certain time,

• messages are hidden after a certain time,

• content is updated automatically (e.g. in a carousel),

• scrolling is displayed.

Presentation and operation

Element-spanning requirements

Online betrachten

Table of contents

• Element status

• Operability status

• Consistency

• Keyboard shortcuts and shortcut keys

• Use of the pointing device

• Use of the keyboard

• User preferences

• Colors and contrasts

• Font

• Focus indicator

• Text cursor

• Required field label

Element status

Online betrachten

See also: Operability status, focus indicator

Several control elements can have a status, e.g.

• highlighted or not highlighted,

• selected or unselected,

• open or closed,

• pressed or not pressed,

• correct or incorrect (also see Error prevention and correction),

• focused or not focused (also see Focus indicator),

• operable or disabled (also see Operability status).

Note: Which specific status is possible for which control element is specified by the programming language used.

Note: Specific recommendations on specific status changes for individual elements are described at the respective element.

Operation

Programming/interfaces

Operability status

Online betrachten

Synonyms: disabled, inactive, display mode, write-protected, read-only, display-only

See also: Element status

Control elements can be operated (standard) or disabled. Form fields can also be read-only or in display mode.

Note: Which specific status is possible for which control element is specified by the programming language used.

Presentation

Operation

Programming/interfaces

Consistency

Online betrachten

Synonyms: Conformity with expectations

Consistent design and operation helps users to understand and operate the application efficiently. Consistency should be aimed for:

• within the application and

• with other applications..

Presentation

Programming/interfaces

Keyboard shortcuts and shortcut keys

Online betrachten

Synonyms for keyboard shortcuts: Key combination, keyboard combination, keyboard command, keyboard equivalents, key sequence, access key, hot key, shortcut

Synonyms for shortcut keys: Mnemonic, acceleration key, shortcut key, menu accelerator

Keyboard shortcuts are keys or combinations of keys with which functions can be initialized or elements can be focused from within the application. The keyboard shortcuts can be initialized regardless of the current focus position. Keyboard shortcuts often consist of a combination of a printable character (letter, number, special character) with one or more modifier keys (e.g. CTRL or ALT). Keyboard shortcuts must be unique.

Shortcut keys are keys that can only be used within an element for the purpose of efficient navigation. They are usually used in menus. The shortcut key is usually the first letter of the corresponding element (e.g. menu item). Shortcut keys do not have to be unique: If, for example, different entries within a menu have the same shortcut key, the entries can be focused one after the other by pressing the key. Shortcut keys are used without modifier keys.

Presentation

Operation

Programming/interfaces

Practical tip: keyboard shortcuts and shortcut keys

Platform-specific keyboard shortcuts

The keyboard shortcuts of the platform (of the Windows operating system, for example) should not be overridden or disabled in your application. i.e. the keyboard shortcuts of the platform should also work in the application (e.g. CTRL+X and CTRL+V to cut and paste text).

Keyboard shortcuts of assistive technology

The assistive technology uses several keyboard shortcuts. These keyboard shortcuts should not be used in the application, as otherwise the assistive technology or the application won’t work with these keyboard shortcuts.

The screen readers use the INSERT key as a modifier key for several of their keyboard shortcuts, for example. Therefore, the INSERT key should not be used as a modifier key for the keyboard shortcuts of the application.

As assistive technology also uses additional modifier keys and keyboard shortcuts without modifier keys, it should be possible to redefine or disable application-specific keyboard shortcuts.

Configuring keyboard shortcuts

Regardless of the assistive technology which is used, keyboard shortcuts are important for people who depend on the use of the keyboard. The application should therefore make it possible to define special keyboard shortcuts for all functions, even if they are not provided with any keyboard shortcuts by default. Where this is possible, the Help option should make reference to it.

Documentation of the keyboard shortcuts and shortcut keys

The keyboard shortcuts should be explicitly documented in the application, i.e. in text form at the respective element (permanently visible or in a tooltip), e.g. “Print (CTRL+D)”.

The shortcut keys should be implicitly documented in the application, by underlining the letter for example, such as “Print”.

The shortcut keys within selection lists and drop-down lists are not generally documented – there, the first letter of the respective list entry acts as the shortcut key.

In the Help option, the keyboard shortcuts should be documented as follows:

• Documentation of the respective keyboard shortcuts within the topic-specific sections (description of a screen, function, elements etc.) as well as

• Documentation of all keyboard shortcuts on a separate page with instructions for the use of the keyboard.

Use of the pointing device

Online betrachten

Synonyms: Use of the mouse, use of the touch pad, use of the pen, pointing device operation, pointer operation

See also: Use of the keyboard

The use of the pointing device encompasses all the operational modalities with a pointing device, e.g.

• Mouse,

• Graphics tablet,

• Touch pad,

• Touch display,

• Track point,

• Track ball,

• Joystick,

• Pen.

Presentation

Operation

From the perspective of accessibility, there is no compulsory requirement for an application to be operable with a pointing device. All that is required is the operation with the keyboard. However, if an application can be operated with a pointing device, specific requirements must be met.

Use of the keyboard

Online betrachten

Synonyms: keyboard operation, keyboard interface

See also: Use of the pointing device,, fokus indicator, navigation sequence

It must be possible for all functions which can be initialized using a pointing device, motion control or voice input to also be initialized using the keyboard, as disabled users may not be able to use a pointing device and/or may not see the pointer, may not be able to perform the movement or may not be able to speak. It is also possible that disabled users are unable to use a keyboard, but their assistive technology simulates the keyboard and interacts with the keyboard interface of the operating system and/or the Accessibility API.

In this context, the simulation of a pointing device with the keyboard (e.g., keyboard mouse using the numeric keypad) is not considered a permissible alternative form of operation to the use of the pointing device.

Presentation

Operation

Use of the keyboard (general requirements)

Note: The operation of individual elements is described at the respective element.

Note: The use of the keyboard does not generally need to be implemented separately, as it is already made available by the platform software or the framework which is used. Care should be taken to avoid overwriting the keyboard shortcuts for other individual functions, however.

Programming/interfaces

Practical tip: use of the keyboard in Web and desktop applications

Custom elements

The standard elements of the marking and/or programming language or of the framework used are generally fully keyboard-operable. They should therefore be used with preference.

If custom elements are used, in terms of the keyboard operability, it is necessary to pay attention to the following in particular:

• Accessibility with the keyboard (e.g. using the tabindex),

• Operability with the keyboard (event handler for the keyboard and/or device-independent event handler),

• Operability conforms to the expectations or has been documented (conforms to expectations regarding the visual presentation and the role, that is communicated to the Accessibility API.

• Focus indicator,

• Focus handling (e.g. no loss of focus during operation; Navigation sequence),

• possibly defined keyboard shortcuts are consistent with those of the platform software and/or do not override those of the platform software.

If a custom element is implemented, it is often recommended that a related default element is used and customized accordingly, as it is then possible to use the basic functionality of the default element.

Drag & Drop

Dragging and dropping elements (drag and drop) can only be done with a pointing device. Designing the alternative form of operation with the keyboard so that it can be used efficiently and in accordance with expectations is recommended. Possible variants include

• Kontextmenü (e.g. for moving elements to other areas),

• several buttons, grouped in one toolbar (e.g. for changing the sequence of elements within an area),

• a button (e.g. for uploading files),

• individual keyboard shortcuts (e.g. adjustment of the size of elements),

• keyboard shortcuts of the platform (e.g. cutting and pasting elements using CTRL+X and CTRL+V),

• use of the arrow keys (e.g. slider),

• Start and finish with the ENTER key, move with the arrow keys (e.g. drawing a freehand screen).

A combination of the variants is often a good idea (e.g. buttons and keyboard shortcuts).

As the alternative form of operation with the keyboard is not usually visible, it should be described in the application and the Help option.

Control elements that are not permanently visible

Control elements that are shown and hidden when using the application, e.g.

• because they are in tooltips, or

• because they only appear when the keyboard focus is in a particular position,

are not usually operable with the keyboard.

Displaying control elements all the time and avoiding control elements in tooltips, for example, is recommended.

Alternatively, an alternative form of operation must be implemented using the keyboard and described in the Help option and the application. In addition to this, the application must be designed so that it is perceptible with the assistive technology when elements that are not always visible are shown. Blind users, for example, must be able to perceive that a tooltip contains control elements with the screen reader, so that they can use the documented alternative form of operation with the keyboard.

User preferences

Online betrachten

Synonyms: User settings, customization, individual adaptation, adaptation to preferences, user preferences

See also: Colors and contrasts,, font, Focus indicator

Presentation

Practical tip: contrast adjustment for desktop applications

In Windows, users can customize the presentation of the colors to suit their needs (Settings > Ease of Access > High contrast). Unlike other operating systems which only allow certain color changes (such as coloring, darkening or inverting the colors), Windows allows you to freely choose the foreground and background colors. In addition to this, it is possible to define individual colors for different element types and/or their status.

With Windows Contrast Adjustment, it is possible to adjust the colors for the following elements and states:

• Text (SystemColorWindowTextColor)

• Background (SystemColorWindowColor)

• Links (SystemColorHotlightColor)

• Highlighted text, selected element (SystemColorHighlightTextColor)

• Background of highlighted text or selected elements (SystemColorHighlightColor)

• Text of control elements (außer Links) (SystemColorButtonTextColor)

• Background of control elements (außer Links) (SystemColorButtonFaceColor)

• Disabled elements (SystemColorGrayTextColor)

For Windows Contrast Adjustment to work correctly in an application, the following must be considered:

• The foreground and background colors must be defined in such a way that they can be overwritten with Windows Contrast Adjustment. This does not apply to graphics or videos.

• Content whose foreground color is adjusted may not have a background whose color is not adjusted. This applies, for example, to text whose background is a graphic that is not adjusted. This does not apply if the font has a contour in the background color, as the visibility is then ensured through the contour.

• Graphics with a transparent background must be avoided. This does not apply if either the foreground color of the graphic can be adjusted (by using SystemColorWindowTextColor, for example), or if the content of graphic has a contour.

• For the element types Text, Links and Form Elements as well as the states Disabled, Highlighted and Selected, the corresponding information about the role and status must be communicated to the Accessibility API. Alternatively, the appropriate colors for the elements and states must be used (for example, SystemColorGrayTextColor for disabled elements).

• Images of text must be avoided. Alternatively, the foreground and background colors of the images of text must be adjustable according to the Windows settings.

• Only color-coded contents must be avoided, regardless of the contrast between the colors.

• Page areas, tooltips, pop-ups and control elements that are shown in different background colors should be given a frame so that they also stand out from the background with Windows Contrast Adjustment.

• If the application does not support Windows Contrast Adjustment, the application must offer its own possibility for adjusting the colors with the equivalent functionality. This option must be described in the application and the Help option.

• If your application only supports Windows Contrast Adjustment for a specific configuration (for example, selecting a specific color scheme), it must be described in the application and the Help option.

Example 1: The two following figures show two lines with two pieces of text, two buttons and two links – one in the default presentation (figure on the left), and one with the use of Windows Contrast Adjustment (Contrast no. 1).

• In the figure on the left, the text, button and link are visible in both lines based on the colors used:

  • Text: black font on white background,

  • Button: black font on gray background,

  • Link: blue font on white background.

• In the figure on the right, the text, button and link can only be identified correctly in the top line, as they have been programmatically marked as text, button and link:

  • Text: yellow font on black background,

  • Button: white font on black background,

  • Link: blue font on black background.

• In the figure on the right, the text, button, and link in the bottom row are indistinguishable, as they are all displayed in the text color (yellow font on a black background). The reason for the incorrect presentation is that the button and link were not programmatically displayed as such.

Example 2: In the two following figures, one operable button (“Send”) and two disabled buttons (“Check” and “Delete”) are shown – one in the default presentation (the figure on the left), and one with the use of Windows Contrast Adjustment (Contrast no. 1).

• In the standard presentation, the two disabled buttons can be seen to be disabled due to the grayed-out colors.

• When using Windows Contrast Adjustment, only the “Check” button is correctly visually identifiable as disabled (green font on black background).

• The “Delete” button is not identifiable as disabled when using Windows Contrast Adjustment, but is shown as operable (white font on a black background). The reason for the incorrect presentation is that it was not programmatically marked as disabled.

Example 3: In the two following figures, four buttons are shown that are labeled with a black icon – one in the default presentation (figure on the left), and one with the use of Windows Contrast Adjustment (Contrast no. 1).

• In the default presentation all four buttons look the same (black icon on white background).

• When using Windows Contrast Adjustment, the four buttons look different because of the different technology used for the presentation of the icon:

  • The first icon is displayed correctly because a font icon was used in which the foreground and background colors are adjusted (white icon on black background). This variant is to be preferred.

  • The second icon is not adjusted (black icon on white background) because it is a graphic without a transparent background. This variant is acceptable.

  • The third icon is not so easy to identify because it is a graphic with a transparent background (black icon on a black background). The icon is perceptible due to its white outline, however. This variant is acceptable.

  • The fourth icon cannot be seen because it is a graphic with a transparent background (black icon on a black background). This variant should not be used.

Colors and contrasts

Online betrachten

Synonyms: Color coding, color, contrast

See also: text, font, graphics, contrast adjustment

Colors are an important visual design tool. People with impaired vision may not perceive colors or differences in color (contrasts), however.

Presentation

Programming/interfaces

Practical tip: color coding

To comply with EN 301 549: 9.1.4.1 and 11.1.4.1, respectively, a distinction must be made between two different forms of color coding:

• the color difference conveys a piece of information,

• the color itself conveys a piece of information.

The color difference conveys a piece of information

Examples:

• The active menu item has a gray background color, all the other menu items have a white background color.

• The text color is black and the link color is blue.

If the colors themselves have no meaning, but only the difference between the colors does, a contrast ratio of at least 3:1 between the colors is sufficient.

The use of another visual method, however, (e.g. icon, font style, size, position, shape, border, underline, text) to reproduce the information conveyed by the color difference is recommended, e.g.

• The active menu item has a bold font style, all other menu items have a normal font style.

• The text is not underlined, but all links are underlined.

Note: EN 301 549: 9.1.4.1 and 11.1.4.1 formulate requirements for visually impaired people who use the application without assistive technology. For users of assistive technology, according to EN 301 549: 9.1.3.1 and 11.1.3.1.1, additional requirements apply with regard to the color coding, e.g.

• To enable blind people to perceive the information conveyed by color difference, this information must be communicated to the Accessibility API programmatically or in text form.

• To enable users of the Windows Contrast Adjustment to perceive the information conveyed by color difference, this information must be conveyed programmatically (see Practical tip: contrast adjustment), by another visual means (see above), or in text form.

The color conveys a piece of information

Examples:

• Incorrectly filled out form fields have a red border, correctly filled out form fields have a green border.

• Different background colors are used for messages: red for warning messages, green for success messages and yellow for tips.

• In a financial statement, losses are shown with a red-colored text and profits with black-colored text.

In these cases, the color itself provides a piece of information, and not just the difference between the colors. Therefore, a contrast ratio of at least 3:1 between colors is not sufficient in this case. Another visual method must certainly be used to convey the information, e.g.

• The incorrectly filled out form fields have an error icon (e.g. an exclamation mark in a red circle) and the correctly filled out form fields have a success icon (e.g. a check mark in a green circle). An expressive error message is also displayed in text form in order to comply with EN 301 549, 9.3.3.1 or 11.3.3.1.

• The messages each have a heading that conveys the status (e.g. “Warning”, “Success” and “Tip”).

• In the financial statement, losses are shown with a minus sign in front of the number.

Note: EN 301 549: 11.1.4.1 formulates requirements for visually impaired people who use the application without assistive technology. For users of assistive technology, according to EN 301 549: 11.1.3.1.1, additional requirements apply with regard to the color coding (see above).

Practical tip: anti-aliasing

Regarding the contrast requirements, the WCAG assumes that anti-aliasing has been disabled. However, this is unrealistic, as most users work with anti-aliasing enabled. Due to the anti-aliasing, in case of thin line thicknesses, the actual contrasts can be significantly below the contrasts that are calculated from the color values. Therefore, either the line thickness or the colors should be adjusted in such a way that the contrast ratio (of at least 4.5:1 for text and 3:1 for content of graphics) can also be maintained when anti-aliasing is enabled. Because the anti-aliasing can be configured differently, it is not possible to specify exact values. However, in most cases the following guideline values will help to ensure that the contrast ratios can be maintained:

• minimum line thickness of 2 px or

• doubled contrast ratio at lower line thicknesses (e.g. at least 9:1 instead of 4.5:1).

In this context, it should be noted that a line thickness of 2 px is only achieved for letters above a certain font size; from 25 px for Arial and from 75 px for Times New Roman.

For example: In the following two figures, the letter “x” and a forward slash (“/”) are shown three times in the font style “Times New Roman” and with the font size 16 px. The contrast between the gray and/or black text color defined in the CSS and the white background is:

• Left: 4,5:1,

• Center: 7:1,

• Right: 21:1.

This means that the required minimum contrasts will be maintained throughout the text. In the considerably magnified presentation, however, it can be seen that due to the anti-aliasing, the contrasts calculated for the “x” are only partially achieved with the thicker downward line (diagonal line from the top left to the bottom right) and the horizontal serifs. For the thinner upward line (diagonal line from bottom left to top right), the contrast is clearly below this, e.g. at the most in the lower range at:

• Left: 2,9:1,

• Center: 2,9:1,

• Right: 5,2:1.

For the forward slash, the calculated contrasts are not achieved at any point.

• Left: maximum 2,4:1, average approx.. 2,0:1,

• Center: maximum 2,5:1, average approx. 2,1:1,

• Right: maximum 3,5:1, average approx. 2,3:1.

Font

Online betrachten

Synonyme: Letters, characters, numbers, font

See also: Text, contrast, label, heading

The font is used for the presentation of text information.

Presentation

Programming/interfaces

Practical tip: special characters

When using special characters, different use cases must be distinguished between in terms of the communication of the characters to the Accessibility API:

Decorative special characters

Purely decorative special characters are marked so that they are not communicated to the Accessibility API. The same rules apply to them as to layout graphics.

Examples:

• Button with the label “Next »”: The two forward arrows are purely decorative. The button should have the Accessible Name “Next”.

• Form field label “- - Location - -”: The dashes are purely decorative. The form field should have the Accessible Name “Location”.

Non-purpose-related special characters that contain content

Special characters which are not used according to their meaning are to be accompanied by an expressive alternative text. The same rules apply to them as to graphics.

Examples:

• Button with the label »: The two forward arrows visually convey the information “Next”. The button should have the Accessible Name “Next”.

• Button with the label x: The multiplication symbol visually conveys the information “Close”. The button should have the Accessible Name “Close” (possibly with an indication of what is being closed, e.g. “Close window”).

Note: If used as a required field label, the asterisk (“*”) is not considered to be non-purpose-related.

Purpose-related special characters that contain content

Special characters which are used according to their meaning can be used, provided the character is output correctly using the assistive technology. Otherwise, it should be accompanied by expressive alternative text.

Examples:

• Mathematical formula “3+5 > 5-3”: The two arithmetic operators as well as the larger character are output correctly by the assistive technology and can therefore be used.

• Text with the ordinal characters “ª” and “º”: The assistive technology does not output the two characters at all and/or does not do so correctly, and therefore the two characters require an alternative text.

• The word “guest” with a ligation of s and t. Most screen readers do not know the ligation, and instead of “guest”, only state “gu” and a space.

Special-purpose characters should be used sparingly. It is recommended to use a character which is output in concise form by the assistive technology.

Examples:

• A quote can be given different quotation marks. The “ character is output by the assistive technology, for example, as “typographical quotation mark, top” or “typographical quotation mark, right”. The " character, by contrast, is output as “inverted commas” or “quotation mark”, and is therefore to be preferred.

• The sentence “I prefer the character »#« to “#”” (see the following figure) is output by the screen reader, for example, as “I prefer the double bracket black hashtag with white X double bracket character to lower typographical quotation mark 3D narrow right-pointing arrow head inverted commas”.

Practical tip: font style and text formatting

To make texts easy to read, a legible font style and text formatting should be chosen. In this respect, the following should be taken into account:

• The most readable fonts are those from the humanist sans serif category.

• Ligations should be avoided.

• The minimum font size for text blocks should be 22px.

• The minimum font size for additional text (e.g. footnotes) should be 17px.

• Narrow and wide fonts should be avoided.

• Small and large character spacing should be avoided.

• Thin and thick font styles should be avoided.

• The line spacing should be at least 120% of the font size.

• Upper and lower case lettering should be used according to the orthography rules. The exclusive use of upper or lower case lettering should be avoided.

• Upper and lower case lettering should be used according to the orthography rules. The exclusive use of upper or lower case lettering should be avoided.

• Small caps should be avoided.

• Highlighting should be used sparingly. A bold font style should be used for highlighting.

• Italic font styles or underlining should be avoided. Note: Links should be underlined.

• The text should be left-aligned. The use of justify should be avoided.

You can find more information at: https://www.leserlich.info (External Link).

Focus indicator

Online betrachten

Synonyms: Focus, focus frame, focus appearance

See also: Use of the keyboard, text cursor

The focus indicator displays which element currently has the keyboard focus (see DIN EN ISO 9241-161: 8.37).

The focus indicator is usually displayed with a border around the focused element. Other focus indicators are also permitted, provided that they meet the requirements, e.g.

• Inverting of foreground and background color,

• Changed background color,

• Changing the size of the element,

• Superimposing of a graphical element, such as a side bar.

In certain cases, several focus indicators can be displayed:

• Example 1: When a selection list receives the focus, a focus indicator can be displayed around the entire list. A focus indicator must also be displayed with the current list entry.

• Example 2: With a combined input field, the focus can be on the input field as well as on the selection list.

• Example 3: If an interactive element receives the focus within a page area, then the page area can also be shown as focused.

• Example 4: The title bars of all application windows that do not have the focus are shown grayed out.

In some cases, the focus indicator can be identical to the selection marker (i.e. the marking of the selected option, see Element status), if the focused element is identical to the selected element:

• Example 1: A selection list without multiple selection has a focus indicator on the focused list entry. This indicator can serve as a selection marker at the same time, as the focused list entry is identical to the selected list entry. If this selection list does not also have a focus indicator for the entire list, however, to be able to detect whether the selection list is focused, it is necessary to ensure that the selection marker in the focused state of the selection list differs clearly from the selection marker in the non-focused state of the selection list (e.g. minimum contrast ratio 3:1).

• Example 2: A selection list without multiple selection has a focus indicator on the focused list entry, e.g. a border. This focus indicator is not used simultaneously as a selection marker. A different background color, for example, is used as the selection marker. When navigating through the list entries, both the focus indicator and the selection marker are moved. In this case, an additional focus indicator for the entire list or a differentiation of the selection marker in the focused and non-focused state is not necessary, as the focusing and selection can be perceived independently of each other.

• Beispiel 3: A multiple selection list has a focus indicator that surrounds the entire list. Since the focused list entry does not match the selected list entries in the case of the multiple selection list, the focus indicator and selection marker must be marked separately for the list entries (e.g., as shown in example 2 with a border and a different background color).

Presentation

Operation

Use of the keyboard: focus indicator

The change of the focus indicator between the elements is described in the use of the keyboard and navigation sequence sections. By default, the navigation takes place with the TAB key.

The change of the focus indicator within an element is described at the respective elements. The navigation within elements often takes place with the arrow keys.

Use of the pointing device: focus indicator

Programming/interfaces

Practical tip: focus indicator

The focus indicator must have sufficient contrast, and should be designed consistently at the same time. With applications that have different background colors, this can be achieved by using a two-color border (e.g. black and 05.15.2023 Page 68 of 317 white) that has sufficient contrast against each background. A two-color focus indicator is also useful with control elements on gradients or graphics.

For example: Two buttons on a color gradient from white to black. The top button is currently focused. The focus indicator consists of a black border (inside) and a white border (outside), which means that it always easy to see, regardless of the background color. It is the standard focus frame offered by Google Chrome.

Text cursor

Online betrachten

Synonyms: Cursor

See also: Use of the keyboard, Focus indicator

The text cursor displays the position in an input field (see DIN EN ISO 9241-161: 8.8). The text cursor is typically displayed by a vertical line at the point at which the text is entered, edited or deleted.

Presentation

Operation

Use of the keyboard: text cursor

The change of the focus indicator between the elements is described at the input field and multi-line input field elements. By default, the navigation within the input fields takes place with the arrow keys.

Use of the pointing device: text cursor

Programming/interfaces

Required field label

Online betrachten

Synonyms: Required form fields, required input, required

See also: error message, label, element status

A required field label is a visual indicator for form fields that have to be filled out. In this respect, for example, an asterisk (*) can be used to indicate that a form field has to be filled out.

Presentation

Programming/interfaces

Practical tip: required field label

Required fields can be labeled with a corresponding textual supplement, such as “required field” or “required”. If the majority of the fields are required, the fields that do not need to be filled out can alternatively be labeled with “optional”, for example.

The required fields can also be marked with a symbol. The asterisk (“*”) has established itself for this purpose, in which it can be assumed, at least in specialist applications, that it is known to all users. If another character is used, its meaning should be explained at the beginning of the form.

Practical tip: programmatic label of required fields in Web applications

Screen reader output

• JAWS: required invalid entry | required [after the role and before the value]

• NVDA: required invalid entry | required [after the role and before the value]

• Windows Narrator: required invalid | required [after the value]

Note: A required field which is not filled out but which has been marked with required is in the incorrect status due to the HTML specification, and is therefore output by the screen readers as “invalid entry” and/or “invalid”. The problem does not occur when using aria-required.

HTML

Required fields can be marked with the required attribute..

• Form fields that have been marked as required are automatically validated by the browser and will have an incorrect status if they have not been filled out.

• Form fields that have been marked as required are not automatically visually identifiable as required fields. They have a tooltip, (e.g. “Please complete this field”), which is not perceptible to users of the keyboard and with the screen reader, however, as it is only displayed in the case of a mouse over.

• By default, a form which has required fields that have not been filled out cannot be submitted. Instead, the focus is placed in the first incorrect field and the tooltip is displayed as an error message and output by the screen reader as a warning message (analogous to role=alertalert). These error messages are not accessible for the following reasons:

  • When exiting the field, the error message is hidden automatically and cannot be displayed again.

  • Several browsers automatically hide error messages after a few seconds, even if the focus is in the field (with Chrome and Edge, for example).

  • The error message is only displayed at the first incorrect field. Other required fields that are not filled out are not to be perceived as incorrect.

Therefore, when using required, the following should be considered:

• Required fields must also be visually labeled as such.

• The visual required field label should be marked so that it is not output by the screen reader to avoid the redundant output.

• The application should continuously display its own error messages for all required fields that have not been filled out.

Note: In the practical tip on radio buttons and checkboxes , the particularities regarding their marking up as required fields are explained.

Further information 4.10.5.3.4 The required attribute - HTML Standard (whatwg.org)

ARIA

Required fields can be marked with the aria-required=true attribute.

• Form fields that have been marked with aria-required=trueare not automatically validated by the browser and will not have an incorrect status if they have not been filled out. The incorrect status can be communicated with aria-invalid=true .

• Form fields that have been marked with aria-required=true are not automatically visually identifiable as required fields.

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

Text elements

Online betrachten

Table of contents

• Headings

• Label

• Description

• Text

Headings

Online betrachten

Synonyme: Section heading, main heading, heading

See also: font, text, label, titel, group

Headings are used to outline sections of text. They describe the content of each section of text.

Presentation

Operation

Use of the keyboard: heading (in an application without a virtual cursor)

Programming/interfaces

Practical tip: headings in Web applications

Screenreader output

• JAWS: Heading level [number] [label]

• NVDA: Heading level [number] [label]

• Windows Narrator: Heading level [number] [label]

HTML

Headings are marked with the HTML elements <h1>, <h2>, <h3>, <h4>, <h5> and <h6>. In this respect, the following should be taken into account:

• Headings should be concise, clear and expressive, as for users of screen readers, they are the primary method of navigating and perceiving the page structure.

• The headings should be nested correctly from a hierarchical perspective, i.e. an <h1> should be followed by <h2>-headings whose sections can in turn contain <h3> headings. According to the HTML specification, no heading levels may be skipped, for example, <h2> should not be followed by <h4>, <h5> oder <h6>.

• The main heading (<h1>) should describe the purpose of the respective page (and not just include the application name, for example).

Headings can be grouped within the <hgroup> elements along with paragraphs (<p>-Element) to specify a caption or an alternative heading, for example. This grouping is not perceptible with any of the screen readers for Windows, i.e. the content of the <p> element is output as normal text, as according to the “HTML Accessibility API Mappings”, the <hgroup> element does not have any semantics.

Further information: 4.3.6 The h1, h2, h3, h4, h5, and h6 elements - HTML Standard (whatwg.org) , 4.3.11 Headings and outlines - HTML Standard (whatwg.org) (External Link), Headings | Web Accessibility Initiative (WAI) | W3C

ARIA

If the heading is not implemented with the HTML elements, it is also necessary to take account of the following:

• The role is communicated with role=heading.

• The heading level is communicated with aria-level Only the numbers from 1 to 6 should be used. With numbers greater than 6, JAWS outputs the heading with the level 2.

  • With numbers greater than 6, JAWS outputs the heading with the level 2.

  • With numbers greater than 9, NVDA and Windows Narrator output the heading with the level 2.

• The labeling should take place using text content.

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

Label

Online betrachten

Synonyms: Designation, form field label, name, accessible name

See also: font, text, graphik, form, group, description, error message, required field label

Labels are used for the identification of control elements (see DIN EN ISO 9241-161: 8.21).

A label consists of a short, descriptive text or an expressive graphic and/or a combination of text and graphic. The label can be situated inside the element or adjacent to the element which is labeled.

Presentation

Use of the pointing device: labeling

Programming/interfaces

Practical tip: labeling in Web applications

Screenreader output

• 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 Sprachausgabe: [Label] [role] [value] [required field note] [validation note] [keyboard shortcut note]

Please note:

• The label is output by the screen readers first, immediately before the role.

• Only one group label is output before the label, if available.

• During the reading with the virtual cursor, the label is output at the element itself or where it is located in the source code, depending on the control element. To ensure that labels can also be assigned to the control elements correctly in the case of reading with the virtual cursor, the label should be located in the source code in the element (e.g. with links and buttons), directly in front of the element (with form fields other than radio buttons and check boxes) or directly after the element (with radio buttons and check boxes).

HTML

In HTML, the labeling method depends on the element type:

• Links, buttons (that are marked with the <button element>are labeled using their text content or the alternative text of the graphic,

• Buttons (that are marked with the <input> element) are labeled using the value attribute.

• Form elements are labeled with the <label> element.

• Form field groups (<fieldset>) are labeled with the <legend> element.

• Graphics (<img>) are labeled with the alt attribute.

• Figures (<figure>) are labeled with the <figcaption> element.

• Tables are labeled with the <caption> element.

• iFrames and regions (e.g. <nav> and <section>) are labeled with the title attribute. Certain elements may not be labeled (e.g. <div> or <span>).

Further information: 4.10.4 The label element - HTML Standard (whatwg.org), Providing Accessible Names and Descriptions | APG | WAI | W3C, Labeling Controls | Web Accessibility Initiative (WAI) | W3C, 4. Accessible Name and Description Computation - HTML Accessibility API Mappings 1.0 (w3.org)

ARIA

In ARIA, it is possible to communicate labels with the attributes aria-labelledby and aria-label.

• With aria-labelledby reference can be made to the IDs of visible or invisible labels.

• With aria-label the label can be specified directly in text form.

• Certain elements that are marked with ARIA roles can also be labeled with their text content. This also applies to the button, link, checkbox, radio, option and tab. roles. In the ARIA specification, these elements are marked with “Name From: content”.

• Certain elements that are marked with ARIA roles must be explicitly labeled (generally with aria-label or aria-labelledby) Labeling using the text content is not possible. This also applies to the following roles: listbox, combobox, dialog, form, application, grid.In the ARIA specification, elements that have to be labeled are marked with “Accessible Name Required: True”. Whether an element can be explicitly labeled can be seen in the ARIA specification at “Name From: author”.

• A label can also be marked with role=caption caption, and then serves the purpose of the labeling of tables (role=grid, role=table, role=treegrid) and figures (role=figure), as long as the label is the first (or with role=figure the final) child element of the element to be labeled. Regardless of the marking with role=caption , reference to the label should be made with aria-labelledby.

• Certain ARIA roles cannot be labeled, such as generic, paragraph, presentation, code, insertion, deletion, emphasis, strong, subscript and superscript. In the ARIA specification, these elements are marked with “Name From: prohibited”. Elements with these roles may contain text, however.

• Reference can be made to hidden elements using aria-labelledby , e.g. those that have been marked with display:none or hidden . The contents of the hidden elements are used to label the element with aria-labelledby. In such cases, however, the use of aria-label is recommended..

Further information: aria-label property - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (External Link), aria-labelledby property - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (External Link), caption role - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (External Link)

General information

• Each control element must have a label which is communicated to the Accessibility API as the Accessible Name. This also applies if the element has no visible label.

• The label should be concise and expressive.

• The Accessible Name should not contain any change of language or structured content, as this is not perceptible with the assistive technology.

• For each element, it is only possible to communicate a label to the Accessibility API using one method. If several methods are used, only the label whose method has the highest priority is used as the Accessible Name. The priority of the methods is defined as follows:

  1. aria-labelledby,

  2. aria-label,

  3. HTML labeling methods (e.g. <label>, <caption>, value, alt, if applicable to the element),

  4. text content (if permissible for the element),

  5. title,

  6. placeholder (only for input fields).

• Elements should not be labeled using the title- or placeholderattribute, as these two attributes, which are actually intended for the communication of a description and/or an input instruction, are used only as a label if no correct label is available. This is a repair mechanism which is designed to ensure that an element is not output without a label.

• If the labeling of a control element occurs explicitly using an attribute (for example, aria-label, aria-labelledby, id, which are referenced via <label for>the attribute must be situated on the element that receives keyboard focus and has the role of the element to be labeled. The control element cannot be labeled 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 label. To avoid this, they should be marked with aria-hidden=true.

• If a reference is made to a form field using aria-labelledby, the value of the form field (not its label, however) is taken into account when determining the labeling of the element with aria-labelledby.

• ARIA elements must generally be labeled with an ARIA method (e.g. aria-label or aria-labelledby) or using their text content (if permissible for the respective role). In this way, for example, an ARIA check box cannot be labeled with the <label>element and an ARIA graphic cannot be labeled with the alt attribute. An exception is presented by ARIA elements whose underlying HTML elements allow for the appropriate HTML labeling method. Accordingly, a combined input field (<input role=combobox>) can be labeled with the <label> element because the HTML element <input> can be labeled with the <label> element.

• The visible label should not be marked with aria-hidden=true true, even if an Accessible Name is available, to ensure that the text-to-speech works using the mouse.

• The visible label should be used as an Accessible Name to avoid a repeated output of the label with the text-to-speech feature.

• For form fields, the Accessible Name in the source code should be immediately in front of the element, except for radio buttons and check boxes, in which case the Accessible Name in the source code should be immediately behind it. This is important, to ensure that the label can be assigned to the form fields correctly when reading with the virtual cursor of the screen reader. ⦁ Depending on the type of element, the text content of elements is also imperceptible with the virtual cursor of the screen reader if the elements are explicitly labeled (e.g. with aria-label or aria-labelledby).

  • In the case of control elements (such as links and buttons), the text content should be used as a label. It must otherwise be ensured that all the information contained in the text content is also available in the Accessible Name.

  • In the case of grouping elements (such as form field groups, regions, lists, or tables), their contents are perceptible with the virtual cursor, even if they are explicitly labeled. These elements should therefore be labeled explicitly so that their purpose is recognizable.

Description

Online betrachten

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

See also: 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).

Presentation

Operation

Programming/interfaces

Practical tip: descriptions in Web applications

Screenreader output

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

HTML

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)

ARIA

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)

General information

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

Text

Online betrachten

Synonyms: Continuous text

See also: font, label, description, error message, graphic

The text is used to convey information in writing. Among others, text can contain headings, links, lists und Graphics enthalten.

Presentation

Operation

Use of the keyboard: text (in an application that does not support the virtual cursor)

Programming/interfaces

Practical tip: text

Application that does not support the virtual cursor

Longer texts (guideline: 80 to 400 characters) without a text structure (i.e., continuous text only, without lists, tables, headings, etc.) in applications that do not support the virtual cursor, should

• receive the focus in multiple TAB steps (approximately 80 characters per TAB step), or

• be marked so that they are readable with the virtual cursor, or

• be offered in a linked document which can be read with the virtual cursor (e.g. HTML, PDF, RTF).

Long texts (from approx. 400 characters) or texts with structure (e.g. lists, tables, headings) should

• be marked so that they are readable with the virtual cursor, or

• be offered in a linked document which can be read with the virtual cursor (e.g. HTML, PDF, RTF).

Applications with several TAB steps on text and other non-operable elements should have a mode to disable such unnecessary navigation steps for sighted keyboard users. This mode and its enabling should be described in the accessibility instructions.

Application that supports the virtual cursor

If copying individual text content in the application context may be relevant, this should also be possible with the keyboard. The following requirements must then be met for the text content:

• the text content is focusable with the keyboard, ⦁ the Textcursor is visible within the text,

• within the text, it is possible to navigate with the arrow keys to determine the starting point of the highlighting,

• the text can be highlighted with SHIFT + arrow keys,

• the highlighted text can be copied using CTRL+C (also via the context menu if necessary), and is saved to the Windows clipboard after copying.

To accomplish this, read-only input fields can be used.

If the entire content of a section of text must be copyable, a button for the copying of the text content can be implemented. Pressing the button should result in the text being copied to the clipboard.

Applications with several TAB steps on copyable pieces of text should have a mode for disabling such navigation steps. This mode and its enabling should be described in the accessibility instructions.

Graphical elements

Online betrachten

Table of content

• Graphic

• Layout graphic

• Progress bar

Graphic

Online betrachten

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

Presentation

Operation

Use of the keyboard: graphic

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

Use of the pointing device: graphic

Programming/interfaces

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

HTML

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.

ARIA

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

Screen reader output

• JAWS: [alternative text] graphic

• NVDA: Graphic [alternative text]

• Windows Narrator: [alternative text] image

HTML and ARIA

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

Layout graphic

Online betrachten

Synonyms: Decoration graphic, decorative graphic, non-content-bearing graphic, possibly also background graphic

See also: Graphic

Layout graphics serve the purpose of the visual design of the application, but without conveying information. Layout graphics can be purely decorative, for example, or displayed in text form in parallel with information, but without communicating information in addition to the text.

Presentation

Operation

Programming/interfaces

Practical tip: layout graphics in Web applications

Screen reader output

None

HTML and ARIA

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

• Graphics that are marked with the <img> element should be marked with a blank alternative text as a layout graphic (<img src=… alt="">).

• Graphics that are marked with the <svg> element should be marked with aria-hidden as a layout graphic (<svg aria-hidden=true>).

• Graphics that are marked with the <canvas> element should be marked with aria-hidden as a layout graphic (<canvas aria-hidden=true>).

• Font characters that are purely decorative should be marked as a layout graphic with aria-hidden (<span aria-hidden=true>~~~</span>).

• Font icons or graphics that are shown before or after as pseudo-elements using the CSS selectors should be marked as layout graphics with aria-hidden (<span class=… aria-hidden=true></span>). In the future, it will be possible for these pseudo-elements to be directly marked as layout graphics in the CSS ( 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.

• Font icons should be marked as a layout graphic with aria-hidden (<span aria-hidden=true>i</span>).

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

• CSS background graphics (background-image) are automatically layout graphics.

• Other CSS graphics (e.g. those created with border) are automatically layout graphics.

Layout graphics should not receive the keyboard focus, i.e. the graphic itself or its descendant elements should not be marked with tabindex or as control elements (e.g. <button>).

Further information: Decorative Images | Web Accessibility Initiative (WAI) | W3C

Progress bar

Online betrachten

Synonyms: Progress display

See also: Slider, graphic

A progress bar shows how far a process has progressed (see DIN EN ISO 9241-161: 8.30). The progress can be displayed in text form, graphically (e.g. progress bar) or as a combination of graphics and text. The presentation of the progress bar changes automatically until the process is complete.

Presentation

Operation

Use of the keyboard: progress bar

Note: The following table only applies if the progress bar has to be accessible with the keyboard (see above).

Programming/interfaces

Practical tip: progress bar in Web applications

Screen reader output

Progress bar with value:

• JAWS: [label] [value] progress bar percent

• NVDA: [label] progress bar [value]

• Windows Narrator: [label] [value in %] percent status bar current value [value] minimum value [minimum value] maximum value [maximum value]

Progress bar without value:

• JAWS: [label] 0 progress bar indeterminate

• NVDA: [label] busy indicator

• Windows Narrator: [label] 0 percent progress bar

Please note:

• JAWS misleadingly outputs the value with the addition “percent”, without converting it into a percentage value.

• The updating of the progress bar is not automatically perceptible with JAWS and Windows Narrator.

• NVDA automatically outputs the progress bar update regardless of the focus position with short beeps whose pitch represents the level of the value.

HTML

The progress bar should be implemented with the HTML element <progress>.

The current value is set with the value attribute. If no value attribute is specified, the progress bar is indeterminate and only indicates that progress is being made without being able to show its extent.

The maximum value is set with the max attribute. It should be noted that its value is imperceptible with many forms of assistive technology. The minimum value is always 0.

The label should be linked to the progress bar with the <label for=ID> element.

The <progress> element can contain different child elements depending on the HTML specification. These are neither visually perceptible nor output by the assistive technology, however.

Further information: 4.10.13 The progress element - HTML Standard (whatwg.org)

ARIA

If the progress bar is not implemented with the HTML element, it is also necessary to take account of the following:

• The role is communicated with role=progressbar.

• The current value can be specified with aria-valuenow. If the value is not specified, the progress bar is indeterminate.

• aria-valuetext can also be used to specify a value in text form which should be then output by the assistive technology instead of the value in aria-valuenow.

• The minimum and maximum values can be specified with aria-valuemin and aria-valuemax.

• The labeling can take place with aria-label or aria-labelledby.

• The presentation of the progress bar should be verified in Windows High Contrast mode.

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

Structural elements

Online betrachten

Table of contents

• Desktop: Window

• Tooltip

• Form

• Toolbar

• Group

• List

• Table

• Hierarchical table

• Title bar

• Status bar

• Modal dialog

Desktop: Window

Online betrachten

Synonyms: Application window

See also: Title bar, status bar, modal dialog

A window contains all the currently visible elements of the application (see DIN EN ISO 9241-161: 8.51). A window can contain the following elements:

• Title

• Working area (with menu if necessary),

• Status bar.

Note: All the requirements concerning the window refer to desktop applications only. For Web applications, the browser is the window. The Web application itself does not contain any windows.

Examples:

Presentation

Only those requirements that are directly related to the window are described below. Requirements of elements within the window are described at the respective element.

Operation

Use of the keyboard: window

Use of the pointing device: window

Programming/interfaces

Tooltip

Online betrachten

Synonyms: Quick info, info tip, mouse over

See also: Description, tooltip, modal dialog

The purpose of a tooltip is to display an additional piece of information dynamically, e.g. the label (with graphic control elements in particular), a description, a keyboard shortcut, or context-specific Help. (see DIN EN ISO 9241-161: 8.50). Tooltips are displayed during the focusing of the corresponding UI element. Tooltips do not contain any interactive elements.

Presentation

Operation

Use of the keyboard: tooltip

Use of the pointing device: tooltip

Programming/interfaces

Form

Online betrachten

Synonyms: Form area

See also: Group, error prevention and correction, required field label, authentication, control elements

Forms have the purpose of the input of data. A form contains one or more form elements.

Presentation

Only those requirements that are directly related to the form are described below. Requirements regarding interactive elements within the form are described at the respective element.

Operation

Use of the keyboard: form

Programming/interfaces

Toolbar

Online betrachten

Synonyms: Symbols bar, toolbox, command bar tab

See also: Menu, group, menu button

Toolbars serve the grouping of interactive elements for the editing of content or data (see DIN EN ISO 9241-161: 8.49).

A toolbar contains interactive elements (in most cases, buttons or toggle switches) that are grouped visually with a border, for example. The contents of the toolbar are usually arranged horizontally above or below the area, the contents of which are edited with the elements of the toolbar. The elements of the toolbar can be arranged in several lines. For toolbars with several buttons, icons are often used to label the buttons due to space-related constraints.

Presentation

Only those requirements that are directly related to the toolbar are described below. Requirements regarding interactive elements within the toolbar are described at the respective element.

Operation

Use of the keyboard: toolbar

Programming/interfaces

Practical tip: toolbar in Web applications

Screen reader output

With TAB navigation:

• JAWS: [label] toolbar bar

• NVDA: [label] tool bar

• Windows Narrator: [label] tool bar

With the virtual cursor:

• JAWS: Toolbar with [amount] controls … toolbar end

• NVDA: Toolbar … out off the toolbar

• Windows Narrator: tool bar … -

HTML

There is no element for toolbars in HTML. Instead of this, buttons and other control elements can be grouped in a list (<menu> and <li>), a labeled region (e.g. <section>) or form field group (<fieldset>, labeled with <legend>). The navigation between the elements then takes place with the TAB key and not the arrow keys. To support the efficient keyboard navigation, it should be possible to skip the region and/or form field group (see practical tip on efficient navigation).

Further information: 4.4.7 The menu element - HTML Standard (whatwg.org) (External Link), 4.3.3 The section element - HTML Standard (whatwg.org) (External Link) 4.10.15 The fieldset element - HTML Standard (whatwg.org)

ARIA

When implementing toolbars, the following should be taken into account:

• The role is communicated with role=toolbar.

• The toolbar should be labeled with aria-label or aria-labelledby.

• A non-standard vertical orientation of the toolbar can be specified with aria-orientation=vertical. Frequently, the orientation is not output by the assistive technology, so that with a vertically oriented toolbar, operation with all arrow keys should be possible.

• The toolbar should also be visually recognizable as such, so that sighted keyboard users are able to recognize the operation with the arrow keys.

• The toolbar should contain at least three control elements.

• The visible elements within the toolbar and the programmatically focused element should have the same position and size.

Further information: toolbar role - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (External Link), Toolbar Pattern | APG | WAI | W3C

Group

Online betrachten

Synonyms: Form field group, group field, grouping, groupbox

See also: Headings, form, toolbar

Groups are used to summarise elements that belong together in terms of their content (see DIN EN ISO 9241-161: 8.15). The group has a label which acts as a group label for the elements it contains.

Presentation

Programming/interfaces

Practical tip: form field groups in Web applications

Screen reader output

• JAWS: [label] group start [label] … group end [label]

• NVDA: [label] grouping … outside of grouping

• Windows Narrator: [label] …

Please note:

• Form field groups are not output by Windows Narrator.

• In JAWS and NVDA, the end of the form field group is only perceptible with the virtual cursor when reading. When navigating with TAB, the “group” and/or “grouping” role is only output with the first (and/or with SHIFT+TAB with the last) form element in the group, i.e. when accessing the group. Exiting the group is not perceptible when navigating with TAB. The element overviews of the screen readers display the label of the form field group for each form element in the group.

• For JAWS and NVDA to be able to identify the form field groups, they must be labeled, regardless of whether they are labeled with the HTML element <fieldset> or are marked with the ARIA group and/or radiogroup roles.

• If there is a heading within the <fieldset> and outside the <legend> element, the group label will not be output correctly by JAWS. Headings should therefore be avoided in <fieldset>.

HTML

Form field groups are marked with the <fieldset> element and serve the grouping of form fields that belong together, especially in the case of radio buttons. The form elements that belong to the group are nested in the source code within the <fieldsets>. The labeling of the form field group takes place with the <legend> element which should be the first child element in the <fieldset>. As the group label is output before the label of the form elements that it contains, it is necessary to take account of the following:

• The label of the group should be as concise as possible without losing any meaning.

• Form field groups should not be nested within each other.

According to the HTML specification, the <legend> element can contain control elements. Sometimes, however, this is not supported by the assistive technology; it is therefore recommended that the label of the form field group is only included in the <legend> element in text form. The <fieldset> element can be marked as disabled with disabled. This means that all the contained form elements are disabled (with the exception of form elements located in the <legend> element).

Further information: 4.10.15 The fieldset element - HTML Standard (whatwg.org), [4].10.16 The legend element - HTML Standard (whatwg.org)](https://html.spec.whatwg.org/multipage/form-elements.html#the-legend-element)

ARIA

If the form field group is not implemented with the HTML element, it is also necessary to take account of the following:

• The role of the list is communicated with role=group or role=radiogroup (with radio buttons only). When output by screen reader, no distinction is made between the group and radiogroup.

• The labeling of the group can take place with aria-label or aria-labelledby.

• The ARIA role radiogroup (in contrast to the role group) can be marked with the aria-readonly attributes as read-only, aria-required as a required field and aria-invalid as incorrect. In addition to this, aria-errormessage can be used to assign an error message to the ARIA radio buttongroup.

• Both the ARIA role radiogroup and the ARIA role group can be marked with aria-disabledas disabled. This means that all the contained form elements are output as disabled by the assistive technology (i.e. they should actually be disabled).

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

List

Online betrachten

See also: Selection list, tree structure, table

A list is used for the structured display of data. A list contains several list entries. Lists can be sorted or unsorted. Lists can be nested inside each other. Lists often have a visual indicator at the beginning of each list entry, which is also known as a bullet point, e.g.

• a dash or an icon for an unsorted list

• a letter or a number for a sorted list.

List entries can contain control elements.

Presentation

Operation

Use of the keyboard: list (in an application that supports the virtual cursor)

With applications that support the virtual cursor, neither the list nor its list entries receive the keyboard focus. It should only be possible for interactive elements within the list entries to be accessed and operated with the keyboard.

Use of the keyboard: list (in an application that does not support the virtual cursor)

With applications that do not support the virtual cursor, each list entry must be able to receive the focus so that its contents are perceptible with assistive technology (e.g. screen reader).

Note: In the programming languages for software, there is often no element for lists. Instead of this, selection lists are used for non-nested lists, and tree structures are used for nested lists. In this case, the selection list and/or tree structure should include a note in its label or description that it is only for the presentation of content and not for the selection.

Use of the pointing device: list

Programming/interfaces

Practical tip: lists in Web applications

Screen reader output of sorted and unsorted lists

With the virtual cursor:

• JAWS:

  • List with [amount] items (nesting level [number])

  • [Bullet point] [list entry]

  • List end (nesting level [number])

• NVDA:

  • List with [amount] entries

  • [Bullet point] [list entry]

  • Out of list

• Windows Narrator:

  • enter list

  • [Position] of [amount] level [number] heading levell [number] [bullet point] [list entry]

  • exit list

Note: The Windows Narrator incorrectly outputs “heading level [number]“ for each list entry due to the implicit and/or explicit aria-level.

HTML

Unsorted lists are marked with <ul> and <li>. For control elements in a list, <menu> is also used instead of <ul>. The <menu> element is communicated to the Accessibility API with the semantics of the <ul> element.

Sorted lists are marked with <ol> and <li>. With sorted lists, it is possible to specify the start value with start, change the direction with reversed, and determine the type of bullet point with type.
Nested lists are implemented such that a list (<ol> or <ul>) is located within a <li> element of the parent list.

The difference between a sorted list and an unsorted list, i.e., between <ol> and <ul>, can only be identified visually and with the assistive technology on the basis of the bullet points. The bullet points should therefore match the list type.

Simple bullet points, such as disc for unsorted lists or decimal and/or lower-latin for sorted lists, should be chosen to ensure the correct output and to avoid lengthening it unnecessarily. The following sample values of the list-style-type CSS characteristic are output by the JAWS (first entry), NVDA (second entry, if different), and Windows Narrator (third entry, if different) screen readers as follows:

• none: [no output]

• disc: Bullet points

• circle: round hollow bullet point / white bullet point / empty bullet point

• square: black square / large filled black square / [no output]

• disclosure-open: black downward pointing small triangle / black downward pointing small triangle / [no output]

• disclosure-closed: filled right-pointing small triangle / black right-pointing small triangle / [no output]

• decimal: [number]

• lower-roman: [number; with numbers that only consist of one letter, just the letter; with numbers that consist of several letters, the individual letters or as a word] / [number; with numbers that consist of several letters, the individual letters] / [number; with numbers that consist of several letters, the letters as a word]

• lower-latin: [letter]

• lower-greek: [letter with the supplement “Greek lowercase”] / [no output] / [no output]

• georgian: [no output]

List characters with list-style-image are not output by JAWS and NVDA and are output as an “image” (without alternative text) by Windows Narrator.

Further information: 4.4.5 The ol element - HTML Standard (whatwg.org) (External Link), 4.4.6 The ul element - HTML Standard (whatwg.org) (External Link), 4.4.7 The menu element - HTML Standard (whatwg.org) (External Link), 4.4.8 The li element - HTML Standard (whatwg.org) (External Link)

ARIA

If the list is not implemented with the HTML element, it is also necessary to take account of the following:

• The role of the list is communicated with role=list.

• The role of the list entries is communicated with role=listitem.

• Nested lists can be implemented with aria-level according to the ARIA specification. This is only output correctly by Windows Narrator, however. For nested lists to be output correctly by JAWS and NVDA, nested lists should be nested correctly in the source code (for example: <div role=list><div role=listitem>Entry 1<div role=list><div role=listitem>Entry 1.1 …).

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

Table

Online betrachten

See also: List, Hierarchical table

A table is used for the structured display of data (see DIN EN ISO 9241-161: 8.44).

A table consists of cells which are arranged in columns and rows. In most cases, the first row contains the column headings and the first column frequently contains the row headings. Tables can also contain various functionalities, e.g.

• sorting and filtering of the cell contents (e.g. through the column headings),

• scaling of the column and row size,

• showing or hiding of columns and/or changing the order of columns,

• showing and hiding of subordinate table rows (see: Hierarchical table),

• displaying sum total rows at the end of the table,

• in-line editing of cell contents (hereinafter referred to as editing mode),

• external editing of the cell content, e.g. using a toolbar above the table or a button within the table cells,

• Selection of table rows, e.g. by check box (multiple selection) or radio button (single selection),

• Selection of table cells, e.g. by mouse or keyboard selection,

• Browsing or scrolling through the records, if necessary, with pagination.

The requirements for the individual control elements within the table are described for the respective control element. Only the additional requirements for the whole of the element are described here.

Presentation

Operation

Use of the keyboard: table (in an application that supports the virtual cursor)

With applications that support the virtual cursor, neither the tables nor their cells receive the keyboard focus. It should only be possible for interactive elements within the table cells to be accessed and operated with the keyboard. This only applies if the table is not marked with role=grid. Tables with role=grid are operated like tables in applications without the virtual cursor (see following section).

Use of the keyboard: table (in an application that does not support the virtual cursor)

With applications that do not support the virtual cursor and with tables that have been marked with role=grid, each table cell must be able to receive the focus so that its contents are perceptible with the assistive technology (e.g. screen reader). It is not sufficient if it is only possible to navigate through the table only one row at a time, for example. For tables in applications that do not support the virtual cursor, a distinction is made between the navigation and edit mode:

• In the navigation mode, the arrow keys can be used to navigate between the cells.

• In edit mode, the interactive elements within a cell are operable. If the cell contains multiple interactive elements, it is possible to navigate between the elements in the edit mode.

Table 1: Use of the pointing device: table

Programming/interfaces

Practical tip: tables in desktop applications

Tables in list form

Some programming languages for desktop applications do not allow for the creation of tables which fulfill the navigation requirements within the table (with the use of the arrow keys). Instead of this, the table can only be navigated one row at a time. Therefore, for example, the table cannot be perceived in a structured way with a screen reader (because the entire row is output, in some cases without the corresponding column headings). In addition, in most cases, the control elements in the table cannot be operated with the keyboard.
In the following exceptional cases, the use of these tables is acceptable if the technology used does not offer an alternative:

• the table only contains two columns or

• the table contains a maximum of five columns and the column headings and cell contents are short (maximum of one to two words or numbers), and

• the column headings are output when navigating through the rows, or the output is not necessary because the purpose of the columns is determined by the context (e.g. the cell content), and

• the rows and column headings do not contain control elements and/or all control elements are perceptible with assistive technology (role, purpose, status) and are operable with the keyboard and/or assistive technology.

If these requirements cannot be met, a different form of presentation must be chosen for the data.

Interactive elements in the table

Some programming languages for software do not allow for the creation of tables which fulfill the requirements referred to here regarding the operation of interactive elements within tables. In this case, interactive elements within the tables should be avoided. Instead of this, the tables should only be used to display data and the associated interactive elements should be located outside the table. Examples:

• One or more control elements can be inserted in front of the table to manage the sorting of the table contents.

• A form can be inserted above the table to filter the table contents.

• Above the table, a button can be added with which a modal dialog can be opened. In the modal dialog, the table can be fully configured using the keyboard (by adjusting the column widths, for instance).

• Above the table, there is a toolbar with which the selected table rows can be edited or deleted.