Fortified ID aims to make applications that are usable for all.

Fortified ID uses the guidelines of WCAG 2.1 to make content more accessible to a wider range of people with disabilities.

WCAG defines four principles that provides the foundation of making a website/application accessible: that it is Perceivable, Operable, Understandable, Robust.

Examples of how Fortified user interfaces are designed according with accessibility/a11y in mind:

1. Perceivable – Information and user interface components must be presented in ways that users can perceive. For example, providing alternative text for images and ensuring clear color contrasts.

2. Operable – The user interface and navigation must be usable by all, regardless of physical or cognitive ability. This includes keyboard navigation support and avoiding content that may trigger seizures or other health issues.

3. Understandable – Content and interface must be understandable for users, which means clear language, predictable navigation, and explanations where necessary.

4. Robust – Content must be robust enough to work with a variety of assistive technologies and future user agents.

An overlay changes colors, logos, and texts, and can therefore affect accessibility. After applying one, re-check at least the following:

• Contrast between text and its background, including buttons and links in all states.

• That the primary button hover state is visually distinct from its default state.

• That replaced logos and images still convey the same meaning, and that custom texts remain clear.

All texts in the user interface come from locale files that can be replaced or extended through an overlay.

Customizing translations

All text that is displayed can be customized. The default locale file contains standard translations and can be changed and extended by future updates. Use the overlay method to override the default locale file with a custom file. The default file will be merged with the custom file, with the keys in the custom file taking precedence.

Add more languages

Default provided languages are English and Swedish. Language files must be present in <overlay_dir>/assets/locales/ E.g. assets/locales/en.json

To add more languages add to the array in supportedLanguages and place file (using overlay method) in locales folder. E.g. add the following to the supportedLanguages array {code: 'de', name: 'Deutsch'} and add a file called assets/locales/de.json

The language is resolved in this order:

1. The language stored in the fortifiedid-language cookie, set when the user picks a language.

2. fallbackLanguage from the configuration.

3. sv, if no fallback language is configured.

If the resolved language is not present in supportedLanguages, the first entry in that list is used instead. If a locale file is missing for the selected language, en.json is loaded.

To customise translations use localesMergePath to extend and merge with the provided default files.

Default language file contains the translations keys

The overlay directory contains a ui_config_overrides.json with "localesMergePath": "assets/custom_locales/". See .

A file is placed in <overlay_dir>/assets/custom_locales/en.json containing the following:

The resulting merged language file used in the application will contain the following:

For each language that will be customised, add language files <overlay_dir>/assets/custom_locales/<lang>.json

You can scope your translation strings by prefixing them with the last segment of a path. This allows you to define translation strings that are specific to a particular page or context.

Example for Path-Based Prefixing

For example, given the path:

You can prefix your translation strings with the last part of the path, selector_root, to create translations specific to that page:

Add these translations to your translation file, and they will only apply to the specified path.

Forms Prefixing with Control IDs

For forms, you can also choose to scope translations by using a part of the path as described above or by prefixing with a control ID. This approach helps localize translations at a finer level of granularity for specific form elements.

Example of a control ID-based prefix:

This flexibility in prefixing allows you to maintain organized and context-aware translations across your application.

This page describes how ui_config is overridden in all frontend applications and authenticators.

Configure the ui_config_overrides.json

Use an overlay to provide the custom file and place it in <overlay_dir>/assets/ui_config_overrides.json.

The file is merged with the application defaults, one level deep. A property you set replaces the default value outright; properties you leave out keep their defaults.

There is no single set of default values. Each application ships its own assets/ui_config.json, and the logo slots it uses differ. Read that file in the installed application to see what you are overriding.

All logos are configured as follows:

All logos can be made into links.

For example, BankID has the following default configuration, where it has BankID's logo at the top (with some negative margins because it has so much whitespace in it and we have our own margins otherwise):

"link": false turns the logo into a plain image; omitting link has the same effect. The rest of the configuration, such as title, follows in the same file.

If you want or need to have the same overrides file for several apps, you can scope parts of the configuration. The available scopes are apps (Password Reset, Forms, Portal, Enrollment), access (the authentication applications such as bidomd and selector), infoendpoint, and logout. You can also scope to a specific application by its name.

In the example above:

• "title": "Acme" at the root applies everywhere, including Password Reset.

• The access scope gives all Access authentication apps a different title and header logo.

• bidomd restores the built-in header logo with the value "default", which in this case is the BankID logo.

A property is looked up from the most specific scope to the least specific, and the first scope that defines it wins:

1. The application name, such as bidomd or selector.

2. An alternate name, when the application declares one. Some applications are published under more than one name.

3. The application scope: access, apps, infoendpoint

Two values have special meaning at any level:

Example: a header logo is set for every Access application, bidomd keeps its built-in BankID logo, and selector shows none.

If variables are defined in the variables object, all instances of the variable will be replaced in the output to the browser. Each name is applied as a regular expression over the whole configuration, so a name containing regular expression characters, or one that occurs inside another value, will produce surprising results. Use a distinctive naming convention such as __VARIABLE_NAME__ to avoid that.

Variables are most useful for values that repeat, such as a file name referenced from several logo slots.

The browser tab title becomes Acme title.

This page takes you from a standard installation to a visibly changed application in four steps. It uses Fortified ID Access as the example, where an overlay directory is configured out of the box.

Where the files go

An overlay directory contains an assets folder, and the files inside it replace files of the same name in the application.

<overlay directory>/
└── assets/
    ├── css_overrides.css
    ├── ui_config_overrides.json
    └── logo.svg

In Fortified ID Access the overlay directory defaults to ${system.customer_home}/overlay, so no configuration change is needed to get started. Other products set overlay_dir or overlay_dirs explicitly. See Overlay.

Change a colour

1. Create <overlay directory>/assets/css_overrides.css.

2. Add the variables you want to change. Only the variables you list are affected.

3. Reload the authentication page. The change applies immediately; no restart is required.

If nothing changes, check that the file is reachable at <application url>/assets/css_overrides.css in the browser. A 404 means the overlay directory is not configured or the file is in the wrong folder.

The full list of variables is in .

1. Place your logo in <overlay directory>/assets/.

2. Create <overlay directory>/assets/ui_config_overrides.json.

3. Reload the page.

Which logo slots an application uses by default differs per application, so check before assuming a slot is in use.

• — which files an overlay can contain and how they take effect

• — the full property reference, scoping, and resolution order

• — changing and adding texts

• — guidelines for sourcing logos and background images

All applications providing UI implement the same pattern regarding styling. An overlay directory supplies organisation-specific files that are served instead of the built-in ones.

Configure the overlay directories

An overlay directory is read before the built-in files. A resource that exists in both is served from the overlay.

Two configuration parameters control this:

• overlay_dir — a single directory. In Fortified ID Access this defaults to ${system.customer_home}/overlay, so in a standard installation you can place the files there without changing any configuration.

• overlay_dirs — a list of directories, searched in the order they are defined. The first directory that contains the requested resource wins.

Example from a Forms config, using two directories.

Inside the overlay directory, create a folder named assets. The application requests its resources below assets/, so that is where the overlay files must sit.

Overlay files fall into two groups, and confusing them is the most common reason a change appears to do nothing.

These replace a built-in file of the same name and are picked up as soon as they exist.

These are naming conventions, not slots. The file name has no meaning to the application until you point at it.

A complete organisation overlay usually contains these six files. The first three take effect on their own, the last three are referenced from them.

Add locale files when texts need changing. For guidance on sourcing the image files themselves, see .

All Fortified ID frontend applications support organisation-specific branding through an overlay mechanism. An overlay controls logos, favicon, background image, colors, titles, and logo behavior across different flows.

An overlay is a directory of files placed alongside the installation. Together they let you adapt the look and feel of authentication pages, Forms, Portal, Password Reset, and the other applications without modifying application code. New to this, start with Get started.

Overlay files

Two files drive everything else. The remaining files are images you reference from them.

To go further than restyling and replace the user interface of an authenticator entirely, see in the Access documentation.

The default selector page with annotated overlay areas, and an organisation-specific override.

The default portal page with annotated overlay areas, and an organisation-specific override.

These guidelines apply when preparing the image files for an organisation overlay. They describe how to source and choose the files; Overlay describes where to put them and how they take effect.

Logos

• Source logos from the organisation website, or from its press, media, or graphic profile pages whenever possible.

• Prefer svg when an official SVG exists. An official png may be used when no SVG is published.

• Never use a redrawn logo when an official file exists publicly.

• For the negative or white variant, use another official logo variant when no white version is published. Do not produce one by recolouring.

• Take the favicon from the organisation website, ideally as .ico.

• If only a PNG favicon is published, that official file can be used instead.

• The background may be svg, png, jpg, or jpeg.

• Size it for 1920x1080 and optimise it for web delivery.

• The default background declaration scales the image to fill the screen while keeping its aspect ratio. Keep that behaviour in mind when choosing an image with important detail near the edges.

• The hover effect on the primary button must always be visible. The hover state must never be identical to the default state.

• Check contrast between text and its background after changing the palette. See .

The look of all Fortified ID applications is driven by CSS variables that an overlay can redefine.

css_overrides.css

Configure the css_overrides.css file in the assets/ folder of your overlay directory.

The file is empty by default. List only the variables you want to change; everything you leave out keeps its default. The file is applied on every page load, so a change takes effect on reload without restarting the service.

Default values/available variables

:root {
  --color-primary: #024550; /* primary color */
  --color-accent: #00cc7e; /* accent color */

  --color-background: #181830; /* background color, used as fallback color if no background image is used. */
  --color-surface: #ffffff; /* surface color. used for cards and such typically where text appear */
  --color-backface: #f5f5f5; /* backface color, used behind cards and other surfaces */
  --color-on-primary: #ffffff; /* color that contrasts when used on color-primary, typically text on primary backgrounds */
  --color-on-surface: #024550; /* color that contrasts when used on color-surface, typically text on surface backgrounds */
  --color-on-accent: #ffffff; /* color that contrasts when used on color-accent, typically text on accent backgrounds */

  --color-link: #045e6c; /* link color */
  --color-link-hover: #058194; /* link color when hovered */
  --color-link-disabled: #bcbcbc; /* link color when disabled */

  --color-button-background: #181830; /* button background color */
  --color-button-background-hover: #c7f3aa; /* button background color when hovered */
  --color-button-background-disabled: #d4d4d4; /* button background color when disabled */
  --color-button-text: #ffffff; /* button text color */
  --color-button-text-hover: #181830; /* button text color when hovered */
  --color-button-text-disabled: #181830; /* button text color when disabled */

  --color-warning: #c24b1d; /* warning text/icon color */
  --color-favorite: #f59e0b; /* favorite/accented star color */

  --button-radius: 0rem; /* button border radius, default no radius */
  --button-border: none; /* button border, default none, example: --button-border: 1px solid --color-primary; or --button-border: 1px solid #fa8072; */
  --button-border-hover: none; /* button border when hovered, default none. example: --button-border: 1px solid #8fbc8f; */

  --color-button-secondary-background: transparent; /* secondary button background color */
  --color-button-secondary-background-hover: transparent; /* secondary button background color when hovered */
  --color-button-secondary-text: var(--color-on-surface); /* secondary button text color, inherits from palette */
  --color-button-secondary-text-hover: var(--color-on-surface); /* secondary button text color when hovered, inherits from palette */
  --color-button-secondary-background-disabled: transparent; /* secondary button background color when disabled */
  --color-button-secondary-text-disabled: #9ca3af; /* secondary button text color when disabled, default gray-400 */
  --button-secondary-border: 1px solid #d1d5db; /* secondary button border, default gray-300 */
  --button-secondary-border-hover: 1px solid #9ca3af; /* secondary button border when hovered, default gray-400 */
  --button-secondary-border-disabled: 1px solid #e5e7eb; /* secondary button border when disabled, default gray-200 */

  --background-image: url('bg_login.svg') no-repeat center center/cover fixed; /* background image, used behind surface and backface. typically for authentication pages */
  /* image can be svg, png, jpg, jpeg, gif, webp, etc. The image will scale to fill the entire screen but maintain ratio if using the no-repeat center center/cover fixed */
  /* Image should be of size 1920x1080 and size optimized for web for best results  */
  /* apps such as Portal/Password Reset etc will have --background-image: none; as default and only use background color */
  --background-fallback-color: var(--color-background); /* background color, used as fallback color if no background image is used or if loading slowly */

  --color-header-background: var(--color-primary); /* header background color, mainly used in apps such as Portal/Password Reset etc. Default the --color-primary variable is used */
  --color-header-text: var(--color-on-primary); /* header text color, mainly used in apps such as Portal/Password Reset etc. Default the --color-on-primary variable is used */

  --color-progress-filled: var(--color-primary); /* progress bar filled color */
  --color-progress-background: #e2e8e9; /* progress bar background color/(not filled color) */

  --color-loader-indicator-bottom: var(--color-primary); /* loader indicator bottom color, mainly used in authentication pages */
  --color-loader-indicator-middle: var(--color-accent); /* loader indicator middle color, mainly used in authentication pages */
  --color-loader-indicator-top: rgb(from var(--color-surface) calc(r - 5) calc(g - 5) calc(b - 5) / 0.2); /* loader indicator middle color, mainly used in authentication pages */

  /* shadcn/ui Table component variables */
  --muted: 210 40% 96.1%;
  --muted-foreground: 215.4 16.3% 46.9%;
  --border: 214.3 31.8% 91.4%;

  --destructive: oklch(0.577 0.245 27.325);
  --destructive-foreground: oklch(0.577 0.245 27.325);

  --input: oklch(0.922 0 0);
  --ring: oklch(0.708 0 0);

  /* Table-specific tokens for consistent styling across shadcn DataTable and MUI TableComponent */
  --table-header-bg: var(--color-primary);
  --table-header-text: var(--color-on-primary);
  --table-row-hover: rgb(229 231 235); /* neutral-200 */
  --table-row-selected: rgb(229 231 235); /* neutral-200 for selected state */
  --table-row-selected-text: inherit;
  --table-border: var(--border);

  --background: var(--color-backface);
  --foreground: var(--color-on-surface);
  --card: var(--color-surface);
  --card-foreground: var(--color-on-surface);
  --popover: var(--color-surface);
  --popover-foreground: var(--color-on-surface);
  --primary: var(--color-primary);
  --primary-foreground: var(--color-on-primary);
  --secondary: var(--color-accent);
  --secondary-foreground: var(--color-on-accent);
  /* --muted: var(--color-backface); */
  /* --muted-foreground: var(--color-on-surface); */
  --accent: var(--color-accent);
  --accent-foreground: var(--color-on-accent);
  /* --destructive: var(--color-destructive);
  --destructive-foreground: var(--color-on-destructive); */
  --border: var(--color-border);
  --input: var(--color-input);
  --ring: var(--color-ring);
}

Examples

Example: To update the button backgrounds define in your css_overrides.css:

:root {
  --color-button-background: #ffe4c4;
  --color-button-background-hover: rgb(143 188 143);
  --color-button-text: #32cd32;
  --color-button-text-hover: #00fa9a;
}

Example: To change background image

Make sure image is available in the assets folder (using the overlay method preferably) and define in your css_overrides.css