Configurable accessibility features

This article explains how to configure accessibility features in IAM to improve compliance with WCAG.

  • Some features are enabled by default for installations using the provided, default Loginapp UI in WCAG mode. This is noted in the respective feature descriptions.
  • For installations with customized HTML templates to comply with WCAG, all features must be configured manually.

IAM provides the following configurable accessibility features:

The following sections explain how to configure the above features.

Changing the initial title of the login page

The index.html file for your application's login page per default contains an invisible special-character string as it's initial page title. This placeholder is only replaced with the correct title once the login page has fully loaded. As a result, screen readers may not read the title properly during the loading phase.

 
Notice

This feature must always be configured manually, even when WCAG mode is enabled and the provided default Loginapp UI is used.

To fix this behavior:

  1. Add a title.properties file to the $CUSTOM_DIRECTORY/src/assets/custom directory.
    This file allows you to define an alternative initial title for the login page.
  2. Set the file's single attribute, title, to a meaningful value, for example:
  3. title=Login
  4. This title will be read by the screen reader and shown in the browser tab until the login page has finished loading. Since translations are not available during this early loading stage, ensure the configured title is understandable in all supported languages.

Adding field-specific error messages

On several occasions, end-users of your application have to enter input, such as a user name, an email address, a phone number, or a password. IAM validates whether the input has the correct format. If validation fails, a generic error message is shown - for example, “Invalid value”.

These generic messages do not indicate which field caused the error. Users who rely on screen readers, such as people with low vision, need more specific feedback (e.g., “Please enter a valid email address”).

To support this, you can define field-specific messages for validation errors in the custom .properties language files located in $CUSTOM_DIRECTORY/src/assets/custom/i18n. If no field-specific message is defined, the generic validation error message is used.

 
Notice

This feature must always be configured manually, even when WCAG mode is enabled and the provided default Loginapp UI is used.

To create a field-specific validation error message, perform the next steps:

  1. The translation keys for generic validation error messages have the following format:
  2. error.validation-failed.<type>
    
  3. where

    • <type> refers to the kind of validation error, such as invalid-value or not-identical
  4.  
    Info

    The translation keys for the generic validation error messages are defined in the reference .properties files.

  5. For field-specific validation error messages, replace these generic keys with the following keys:

  6. error.validation-failed._field.<field>._type.<type>
    
  7. where

    • <field> defines the affected field, such as username, email, or mtanNumber (phone number), and
    • <type> refers to the kind of validation error.
  8. For example: error.validation-failed._field.email._type.invalid-value

  9.  
    Info

    The next table shows where to find the <field> value for a specific input field.
    An overview of the available error types can be found here (second table in the section): Utility functions

  10. Add a meaningful text to the key, for example “Enter a valid email address”:
  11. error.validation-failed._field.email._type.invalid-value = Enter a valid email address 
  12. Add your field-specific translation key/text entry to the respective language .properties file in $CUSTOM_DIRECTORY/src/assets/custom/i18n

Example

The image below shows two versions of the self registration window.

When a validation error occurs

  • The Email and Mobile phone fields at the left throw the generic error text “Invalid value”. This corresponds to the following generic translation key entry, which applies to both fields:
  • error.validation-failed.invalid-value = Invalid value
  • The Email and Mobile phone fields at the right throw different error texts that are specific to each field. This is achieved with the following field-specific translation key entries:
  • error.validation-failed._field.email._type.invalid-value = Please enter a valid email address
    error.validation-failed._field.mtanNumber._type.invalid-value = Please enter a valid phone number

<field> value for translations

The following table shows where to find the <field> value needed for the translation key for field-specific error messages. The column on the left lists the user data plugin that defines the respective UI field. The column on the right provides the plugin's property that contains the <field> value.

User data plugin defining UI field

Value used for <field>

Username User Item

Fix value: username

Password User Item

Possible values:

  • new-password
  • old-password
  • new-password-confirmation
  • mTAN Number Item Definition
  • mTAN Label Item Definition
  • Email Item Definition

Key property

  • Boolean User Context Data Item
  • Date User Context Data Item
  • Date and Time User Context Data Item
  • Enumeration User Context Data Item
  • String User Context Data Item
  • Alias User Item

Context Data Name property

Custom UI

Self-chosen <field> value

Adding landmarks for content sections

A landmark defines a navigational region on a page (for example header, main content, or footer). Landmarks allow assistive technologies such as screen readers to quickly locate and navigate between important sections of the page.

Starting with version 8.6, landmarks for the page header, main content and footer are automatically enabled for installations that use the provided default Loginapp UI with WCAG mode enabled. Installations that use customized HTML templates must add the required landmarks manually to remain WCAG compliant.

To configure landmarks, modify the following custom HTML templates located in $CUSTOM_DIRECTORY/src/assets/custom/templates/layout:

  • default-header.html
  • default-content.html
  • default-footer.html

Screen readers recognize landmarks through ARIA attributes or appropriate HTML tags. ARIA labels provide an accessible name for an element when the visible interface does not contain sufficient descriptive text. Each template must therefore contain an appropriate aria-label.

Proceed as follows

  1. To adjust the default-header.html file:
    1. Remove the landmark role “header” from the upper <div> element (with class iam-container), if applicable.
    2. Define the landmark by either
      • setting the landmark role “banner”, or
      • explicitly adding a <header> tag.
    3. Add the ARIA label aria-label=“{{#translate}}general.aria-label.header{{/translate}}” to either
      • the <div> element containing the “banner” landmark role, or
      • the <header> element.
    4. To define the text used by the ARIA label, add the translation key general.aria-label.header to the appropriate custom language.properties file located in $CUSTOM_DIRECTORY/src/assets/custom/i18n.
    5. Example:

    6.  
      Example
      general.aria-label.header = Top navigation bar
  2. The sample code snippet below illustrates the previous instructions. Here, a <header> tag is added, containing the aria-label attribute.

  3.  
    Example
    <div class="iam-container iam-header-container">
        <div class="iam-row">
            <div class="iam-col-12">
                <div id="iamLanguageSwitcher">
                    <header class="iam-header" id="header" aria-label="{{#translate}}general.aria-label.header{{/translate}}">
                        [...]                    
                    </header>
                </div>
            </div>
        </div>
    </div>
  4. To adjust the default-content.html file:
    1. Define the landmark by either
      • setting the landmark role “main”, or
      • explicitly adding a <main> tag.
    2. Add the ARIA label aria-label="“{{#translate}}general.aria-label.main{{/translate}}”" to either
      • the <div> element containing the “main” landmark role, or
      • the <main> element.
    3. To define the text used by the ARIA label, add the translation key general.aria-label.main to the appropriate custom language.properties file located in $CUSTOM_DIRECTORY/src/assets/custom/i18n.
    4. Example:

    5.  
      Example
      general.aria-label.main = Main content area
  5. The sample code snippet below illustrates the previous instructions. Here, the aria-label attribute is added to the <div> element containing the “main” landmark role.

  6.  
    Example
    <div class="iam-container iam-content-container">
        <div class="iam-row">
            <div id="iamContentTargetContainer" class="iam-col-12" role="main" aria-label="{{#translate}}general.aria-label.main{{/translate}}"></div>
        </div>
    </div>
    
  7. To adjust the default-footer.html file:
    1. Remove the landmark role “footer” from the upper <div> element (with class iam-container), if applicable.
    2. Define the landmark by either
      • setting the landmark role “content-info”, or
      • explicitly adding a <footer> tag.
    3. Add the ARIA label aria-label=“{{#translate}}general.aria-label.footer{{/translate}}” to either
      • the <div> element containing the “content-info” landmark role, or
      • the <footer> element.
    4. To define the text used by the ARIA label, add the translation key general.aria-label.footer to the appropriate custom language.properties file located in $CUSTOM_DIRECTORY/src/assets/custom/i18n.
    5. Example:

    6.  
      Example
      general.aria-label.footer = Bottom navigation bar
  8. The sample code snippet below illustrates the previous instructions. Here, a <footer> tag is added, containing the aria-label attribute.

  9.  
    Example
    <div class="iam-container iam-footer-container">
        <div class="iam-row">
            <div class="iam-col-12">
                <footer class="iam-footer" id="footer" aria-label="{{#translate}}general.aria-label.footer{{/translate}}">
                    [...]
                </footer>
            </div>
        </div>
    </div>
    

Configuring skip links

Skip links allow keyboard and screen reader users to jump directly to a specific page section instead of navigating through repeated elements such as headers, navigation bars, or language switchers.

Starting with IAM version 8.6, skip links are automatically enabled for installations that use the provided default Loginapp UI with WCAG mode enabled. In these installations, the Loginapp provides skip links to the header, main content and footer sections of a page for all default languages (English, German, French, Italian).

You must configure skip links manually if you:

  • Use customized HTML templates for the Loginapp
  • Use the default Loginapp UI, but want to add skip links to page sections other than the header, main content or footer

Manual configuration of skip links

This section explains how to implement skip links for the header, main content, and footer areas when using customized Loginapp HTML templates.

To implement skip links in customized HTML templates, proceed as follows:

  1. The skip link menu should be the first focusable element on the page so keyboard users encounter it immediately. Usually, this would be at the top of the <body> element. Add the following <nav> element:
  2.  
    Example
    <nav class="iam-nav-skip-link" id="iam-skip-links"
         aria-label="{{#translate}}general.aria-label.skip-links{{/translate}}">
        <a href="#iamHeaderContainer" class="iam-skip-link iam-btn">{{#translate}}general.skip-links.header{{/translate}}</a>
        <a href="#iamContentContainer" class="iam-skip-link iam-btn">{{#translate}}general.skip-links.main{{/translate}}</a>
        <a href="#iamFooterContainer" class="iam-skip-link iam-btn">{{#translate}}general.skip-links.footer{{/translate}}</a>
    </nav> 
  3. The skip links must point to the elements representing the header, main content, and footer.
  4. For each skip link,

    1. Take the href value from the corresponding <a> element in the code snippet above.
    2. For example, #iamHeaderContainer from <a href=“#iamHeaderContainer” ... </a>

    3. Remove the # and use the remaining value as an id. Ensure that an element with this id exists in the correct location on the page (e.g., the header container).
  5. To define the text used by the ARIA labels, add the following translation keys to the appropriate custom language .properties file located in $CUSTOM_DIRECTORY/src/assets/custom/i18n:
    • general.aria-label.skip-links - ARIA label for the skip link menu.
      For example: general.aria-label.skip-links = Navigation
    • general.skip-links.header - Skip link text to the header area.
      For example: general.skip-links.header = Skip to header
    • general.skip-links.main - Skip link text to the main content area.
      For example: general.skip-links.main = Skip to main content
    • general.skip-links.footer - Skip link text to the footer area.
      For example: general.skip-links.footer = Skip to footer
 
Notice

You do not have to add skip links to all three areas: header, main content and footer. You can decide which skip links to include. For example, you could add a single skip link to the main content area. However, the target should always be on the same page.

Adding skip links

You can also add skip links to additional page sections beyond the header, main content, and footer. Proceed similar to the instructions above:

For each additional skip link

  1. Add an <a> element referring to the corresponding page area to the skip link navigation element <nav>.
  2. For example:

  3. <a href="#iamareaXContainer" class="iam-skip-link iam-btn">{{#translate}}general.skip-links.areaX{{/translate}}</a>
  4. Define the target landmark, by adding the link reference specified in the previous step to the container representing the respective page area.
  5. For example:

  6. <div id="iamareaXContainer">
        <div class="iam-container iam-areaX-container"> ... </div>
    </div>
  7. To define the skip link text, add the corresponding translation key general.skip-links.areaX to the appropriate custom language .properties file in$CUSTOM_DIRECTORY/src/assets/custom/i18n.

Changing the skip links location

By default, the skip link menu appears in the upper-left corner of the page:

This corresponds with the default styling settings in the following code block:

 
Example
.iam-nav-skip-link {
    position: fixed;
    transform: translateX(-9999px);

    &:focus-within {
       background: $iam-skip-links-bg;
       padding: $iam-skip-links-padding;
       margin: $iam-skip-links-margin;
       box-shadow: $iam-skip-links-box-shadow;
       z-index: 1;
       transform: none;
    }
}

.iam-skip-link {
    display: block;
    background: $iam-skip-link-bg;
    font-weight: $iam-skip-link-font-weight;
    padding: $iam-skip-link-padding;
    margin-bottom: $iam-skip-link-margin-bottom;

    &:last-child {
       margin-bottom: 0;
    }
} 

To relocate the skip links menu, adjust the above code accordingly.

Example
The following screenshot shows a horizontal skip link menu placed centrally on top of the page:

To realize this, add the following code snippet to your custom_styles.scss file:

 
Example
.iam-nav-skip-link {
    top: 0;
    left: 50%;
    transform: translateX(-50%) translateY(-9999px);

    &:focus-within {
       transform: translateX(-50%);
       display: flex;
       align-items: center;
       justify-content: center;
       margin-left: 0 ;
       gap: 0.5rem;
    }
}

.iam-skip-link {
    display: inline-block;
    margin-bottom: 0;
}

Configuring field autocompletion

Starting with IAM version 8.6, the Loginapp UI supports browser autocomplete for the username, password, and one-time password fields. Autocomplete is a browser feature that automatically fills form fields using previously stored user data.

The autocompletion feature is automatically enabled for installations that use the provided default Loginapp UI with WCAG mode enabled.

Manual configuration is required if you:

  • Use customized HTML templates for the Loginapp UI.
  • Use the provided default Loginapp UI, but want to add autocompletion for input fields other than the username, password and one-time-password field.

Autocompletion is achieved by setting the autocomplete HTML attribute in the respective UI field definition. The value of the autocomplete attribute must match the Input Purpose property of the corresponding user data plugin that defines the UI field.

The following example shows how autocomplete is configured for the Username field. Here, the value of the autocomplete attribute is username, which matches with the value of the Input Purpose property of the corresponding Username User Item plugin.

The table below lists the default autocompletion settings for the username, password and one-time password fields in the default Loginapp UI. If you use customized HTML templates, you must set the autocomplete attribute manually.

UI input field

Value autocomplete attribute

Corresponding plugin with Input Purpose property

Username

username

Username User Item

Password

new-password

current-password

Password User Item

One-time password fields

one-time-code

Input fields that support autocompletion

Additionally, you can enable autocompletion for multiple other input fields, such as email, date of birth, name, address (town), and mTAN number, as well as for custom UI fields. The following user data plugins store user data, can define UI input fields, and support the Input Purpose property.

List of plugins with Input Purpose field:

  • Email Item Definition (class: EmailItemDefinitionConfig). Stores email addresses.
  • mTAN Number Item Definition (class: MtanNumberItemDefinitionConfig). Stores mTAN numbers (usually the user's mobile number).
  • mTAN Label Item Definition (class: MtanLabelItemDefinitionConfig). Stores labels for mTAN numbers.
  • Date And Time User Context Data Item (class: DateAndTimeContextDataItemDefinitionConfig). Stores user context data consisting of a date and time value.
  • Date User Context Data Item (class: DateContextDataItemDefinitionConfig). Stores user context data consisting of a date value, such as date of birth.
  • Enumeration User Context Data Item (class: EnumContextDataItemDefinitionConfig). Stores user context data consisting of a string value out of a fixed set of allowed strings.
  • String User Context Data Item (class: StringContextDataItemDefinitionConfig). Stores user context data consisting of a string value, such as name or address.
  • Password User Item (class: PasswordDefinitionConfig). Stores the user's password.
  • Username User Item (class: UsernameDefinitionConfig). Stores the user's username.
  • Alias User Item (class: AliasDefinitionConfig). Stores a context data item that can be used as a login name in the same way as the username.
  • Input UI Element (class: ConfigurableUiInputFieldConfig). Used to configure an input field for a custom UI form, e.g., for a (customized) authentication or self-registration flow.
  • Date UI Element (class: ConfigurableUiDateConfig). Used to configure a date field for a custom UI form, e.g., for a (customized) authentication or self-registration flow.
  • Drop-Down UI Element (class: ConfigurableUiDropDownConfig). Used to configure a drop-down field for a custom UI form, e.g., for a (customized) authentication or self-registration flow.

More information