Accessibility (WCAG)

Digital accessibility with Embrace CRM (Customers)

At Embrace CRM, we believe it is important that everyone, with or without disabilities, can make use of digital services. This is not only a social responsibility, but also a legal obligation. Indeed, as of June 28, 2025, organizations will be bound by the European Accessibility Act (EAA). This European law requires, among other things, that websites and digital customer environments are accessible to people with disabilities.

Embrace CRM provides software to housing associations and other real estate organizations. With our product, they can set up their own website and my environment and offer them to customers. The accessibility of these digital environments therefore depends partly on technical choices within our software, and partly on how they are set up by customers.

We focus on the technical accessibility of our product. This means, for example, that buttons, forms and interactive elements such as tabs, search fields and maps are built semantically correctly and with support for assistive technology. We also ensure a logical order of focus, clear error messages and correct use of alternative texts in the interface.

Our customers are responsible for the content and visual design of their websites. For example, they determine whether editors use the correct headlines, whether color contrast meets WCAG requirements, and whether images are appropriately described. These aspects fall outside our technical responsibility, but we do support customers with this through documentation, training and the user group.

The accessibility of our software is currently partly up to par. An independent WCAG audit shows that there are still several technical areas for improvement, such as maintaining focus in menus, correct semantics for forms and error messages, and improvements to search functionality. We are structurally solving these issues in the new version of our product, based on Umbraco 13, which will be widely rolled out in September 2025.

After this release, we will have another independent accessibility study carried out. We share the results with our customers via the user group and on this website. This is how we provide insight into our progress and support customers in meeting their own obligations under the EAA.

Do you have questions or signals about accessibility? Then contact our support department. We'd love to think along with you and use your feedback to further improve our software.

‍

‍

SC 1.1.1: Non-text content (Level A)

Finding: VID-1.F12 — Decorative icon is read aloud by auxiliary software

• Description of the anomaly:
  On multiple pages within the website, a decorative icon (for example, a right arrow) is added to links via CSS pseudo-elements (::before or: :after). These icons are purely visual, but are currently being read aloud by assistive software such as screen readers.
• Cause:
  When using CSS pseudo-elements, no provision has been made to hide the utility software icon. For example, content is used to show the icon, but without an empty text alternative or aria-hidden.
• Consequence:
  Screen reader users hear unnecessary or confusing characters read aloud to links where the icon is. This can lead to reduced accessibility and a confusing user experience.
• Alternative:
  There is no alternative available. Users can't bypass or change behavior.
• Measure:
  The decorative icons are marked as purely visual so that auxiliary software ignores them
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025

SC 1.1.1: Non-text content (Level A)

Finding: VID-1.F40 — Interactive icon with no text alternative

• Description of the anomaly:
  The header appears in the my area “Continue with” when a user has started a process earlier, such as “File a Complaint”. Below this header is a list of items that the user can continue with. Each item in this list contains an icon with a cross (X), intended as an interactive button (for example, to delete or abort the process). However, this icon does not contain any text alternative that clarifies the purpose of the button.
• Cause:
  The icon was probably added via a<span>, <i>or CSS with a visual cross, but without an aria-label, aria-hidden, title, or other form of alternate description in the HTML.
• Consequence:
  For screen reader users, the purpose of the cross is not clear. The button may not be announced or announced incorrectly, leading to confusion or unintended actions.
• Alternative:
  None. The action associated with clicking on the cross is not accessible to help software users without an explicit description.
• Measure:
  An accessible text alternative is added to each interactive icon.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025

SC 1.3.5: Identify the purpose of input (Level AA)

Finding: VID-1.F38 — Missing autocomplete attribute when entering form

• Description of the anomaly:
  On the login page of the my environment, there is a login form where personal information must be filled in: a username and a password. The input fields in this form lack the autocomplete attribute, while the form as a whole has also explicitly disabled autocomplete via autocomplete="off”.
• Cause:
  During implementation, the autocomplete attribute was not added to the relevant input fields. This may have been done for security reasons, but this comes at the cost of accessibility and ease of use.
• Consequence:
  Browsers and auxiliary software cannot support users to automatically fill in known data. This makes it difficult to use, especially for people with cognitive disabilities or motor challenges.
• Alternative:
  None. Users are now completely dependent on manual input.
• Measure:
  The form and associated input fields are updated with correct autocomplete values, as recommended in the WCAG specification.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 1.3.5: Identify the purpose of input (Level AA)

Finding: VID-1.F47 — Missing or disabled autocomplete attribute in personal data input fields

• Description of the anomaly:
  On the settings page within the my environment, there are multiple input fields for personal information such as username, password and current password. For these input fields, the autocomplete attribute is missing or is explicitly set to “off”. As a result, there is no support for filling in this information automatically.
• Cause:
  During implementation, the fields did not have the correct autocomplete attribute, or it was deliberately chosen to block autofill (possibly for security reasons). However, this comes at the expense of accessibility.
• Consequence:
  Users cannot benefit from browser functionalities or auxiliary software that simplify filling out, which is a barrier, especially for people with motor or cognitive disabilities.
• Alternative:
  None. Without autocomplete, users are completely dependent on manual input.
• Measure:
  The input fields are provided with correct autocomplete attributes in accordance with WCAG guidelines.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 2.1.1: Keyboard (Level A)

Finding: VID-1.F14 — Display tabs not accessible via keyboard

• Description of the anomaly:
  On the /projects page, above the list of projects, you can switch between List view and Map view. This functionality is presented as a type of tabs, but cannot be operated with the keyboard. As a result, users who rely on keyboard navigation cannot adjust the view.
• Cause:
  The interactive elements are probably not implemented as real buttons or links (e.g. with <div>or <span>without a tab index and role). As a result, they are skipped by the keyboard and/or not announced correctly by assistive technology.
• Consequence:
  The functionality is inaccessible to users who navigate using the keyboard or screen readers. In addition, there may also be issues with focus order and screen reader support, related to criteria 2.4.3 (focus order), 2.4.7 (visible focus), and 4.1.2 (name, role, value).
• Alternative:
  None. Users cannot change the display option without mouse controls.
• Measure:
  The tabs are converted into semantically correct interactive components with keyboard control support. This means, among other things:
  • Using <button>or <a>with clear aria-selected, aria-controls, role="tab”, and tabindex values.
  • Correct focus style and logical order in the DOM
  • Full compliance with WAI-ARIA Authoring Practices for tab components
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 2.1.1: Keyboard (Level A)

Finding: VID-1.F43 — Invoice summary filter buttons not accessible via keyboard

• Description of the anomaly:
  On the billing overview page in the my area, located under the header “Invoice Summary” three visually designed buttons or links with the texts “All”, “Outstanding” and “2025". These are used to filter the list of invoices. However, these elements are not accessible via the keyboard: they cannot be reached or activated without a mouse.
• Cause:
  The buttons may be built with <div>- or <span>-elements without the appropriate semantics or focus options (such as tabindex="0" or a role). As a result, they are skipped in keyboard navigation and are not interactive for assistive technology users.
• Consequence:
  Users who only use the keyboard are unable to control the filter functionality and therefore have limited access to the contents of the billing statement. This can lead to frustration and a serious impediment to ease of use.
• Alternative:
  There is no alternative available. The filter options are entirely dependent on mouse interaction.
• Measure:
  The buttons are implemented semantically correctly, for example as <button>elements or <a>elements with clear action, so that they are accessible by default with the keyboard. In addition, visual focus styles and logical focus order are also added.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 2.4.3: Focus Order (Level A)

Finding: VID-1.F16 — Focus comes to invisible elements during navigation

• Description of the anomaly:
  On the /projects page, keyboard users experience problems with focus order when navigating through the list of projects and viewing options (List View and Map View). While going through the project list, the focus sometimes jumps to invisible elements, causing it to temporarily disappear. After the last project item, the focus jumps to the second tab (“Map View”) without a clear transition. The opposite also happens when you start at “Map View”: the focus first goes through invisible elements in the project list.
• Cause:
  The DOM structure contains focusable elements that are not visually visible (e.g. display: none of visibility: hidden) or misplaced elements out of the visible order. Correct arial roles or logical groupings that structure the order may also be missing.
• Consequence:
  For keyboard users, it's not clear where the focus is, leading to confusion, loss of context, and the risk of content being unintentionally skipped or untraceable.
• Alternative:
  Unavailable. Users who lose focus can't navigate intuitively or know where they are within the interface.
• Measure:
  The focus order is revised and logically structured so that keyboard navigation matches the visual order on the screen. Invisible or irrelevant elements are removed from the focus order with tabindex=” -1" or aria-hidden="true”. In addition, the navigation within the tabs is functionally separated to prevent unwanted exceedance.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 2.4.3: Focus Order (Level A)

Finding: VID-1.F58 — Keyboard focus leaves open mobile menu on small screens

• Description of the anomaly:
  When viewing the website on a smaller screen (for example, at 1280 × 1080 resolution and 200% zoom), a mobile navigation menu appears that is identified by the three-line icon (hamburger menu). When you open this menu, most of the screen is covered. However, after the last menu item, the keyboard focus jumps to the underlying page content without warning, instead of staying within the menu or closing the menu automatically.
• Cause:
  The mobile menu is technically positioned as an overlay, but no focus management or focus trap has been used. As a result, the user may accidentally navigate outside the active interface.
• Consequence:
  The order of focus is not logical or useful. Users who use the keyboard can unexpectedly navigate to underlying content while the menu is still open, resulting in loss of context, confusion, and potentially unintended actions. This is also an issue among:
  • SC 2.4.7: Visible Focus (Level AA) — because the focus is difficult to follow.
  • SC 2.4.11: Focus not hidden (Level AA) — because content outside the menu is not immediately visible, but gets focus.
• Alternative:
  There is no alternative control available that prevents focus from moving out of the menu.
• Measure:
  A focus trap is being implemented within the mobile menu. This means that keyboard users stay within the open menu for as long as it is active. The focus can only leave the menu via a close button (e.g. Escape or a close icon). If the menu is left anyway, it closes automatically. This update follows the guidelines for modals and overlays from WAI-ARIA Authoring Practices.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 2.4.4: Link Target (Level A)

Finding: VID-1.F19 — Unclear link target when pagination

• Description of the anomaly:
  On the /projects page, below the project overview, there is a pagination component with links that contain only numbers, such as “1", “2", and “3". Based on location and design, it is clear to sighted users that this is pagination, but for users of auxiliary software, this context is missing. Even when requesting a list of links, it is not clear what the purpose of the numbered links is.
• Cause:
  Pagination does not technically include semantic support such as a nav landmark, accessible descriptions of link targets, or screenreader-only text. The links contain only visible numbers with no additional context.
• Consequence:
  Screen reader users don't understand that the numbered links point to follow-up pages with more projects. This leads to confusion, inaccessibility of navigation and possible accidental clicks on irrelevant links.
• Alternative:
  There is no alternative to this form of navigation available for users of auxiliary software.
• Measure:
  Pagination is transformed into a semantically accessible component.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 4.1.2: Name, Role, Value (Level A)

Finding: VID-1.F45 — Single decorative CSS icon button with no meaningful alternative

• Description of the anomaly:
  On the personal information page in the my environment page, there is a button that consists solely of an arrow icon that was added via a CSS pseudo-element (::before or: :after). For screen reader users, this icon is incorrectly pronounced “5”, which is confusing and does not indicate the function of the button.
• Cause:
  The icon is not technically marked as decorative and a meaningful text alternative is missing. The button has no accessible label, and the pseudo-element contains unwanted content that is being spoken.
• Consequence:
  Screen reader users receive confusing and incorrect information (“5”) instead of describing what the button does. This leads to a poor user experience and hampers the correct interpretation of functionality.
• Alternative:
  There may be visible button text on the desktop, but on smaller screens, that text has been removed. Without an accessible alternative, the button is inaccessible on mobile.
• Measure:
  The button gets an accessible text alternative
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 4.1.2: Name, Role, Value (Level A)

Finding: VID-1.F60 — Padlock icon button with no meaningful alternative on a small screen

• Description of the anomaly:
  On smaller screen resolutions (for example, 1280×1080 pixels with 200% zoom), the button becomes “My Environment” replaced with a padlock icon added via a CSS pseudo-element (:before). The original button text is not visible at this resolution, leaving only the icon. Screen readers are currently misreading the icon as “3”.
• Cause:
  The visual text “My Environment” is visually hidden on small screens, but no alternative is available for users of assistive software. The CSS icon used does not include a proper aria-hidden marker or semantic alternative. As a result, a random character (“3”) is read aloud.
• Consequence:
  Screen readers provide an incomprehensible and incorrect description of the button, leading to confusion and inaccessibility for users who navigate with assistive technology. As a result, the function of the button is not clear.
• Alternative:
  Not present. There is no accessible name or description available in the current deployment for users on smaller screens.
• Measure:
  The button is provided with an accessible textual pointer.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 2.4.7: Visible Focus (Level AA)

Finding: VID-1.F15 — Visibly focus on invisible or illogical keyboard navigation elements

• Description of the anomaly:
  On the /projects page, the visual focus disappears when you navigate through the overview of projects with the keyboard. Between the individual project cards, the focus becomes invisible or moves to elements that are out of sight. After the last project, the focus unexpectedly ends up on the second tab “Map View”. When you're just starting with “Map View”, the focus first moves through the (visually invisible) project list.
• Cause:
  The DOM structure may contain elements that are still focusable but are visually hidden or outside the visible viewport. The lack of focus styles or an inconsistent tab order can also contribute to the problem. The absence of proper management of the focus order leads to unwanted behavior.
• Consequence:
  The user can't see where the focus is, which is confusing and frustrating for people who rely on keyboard controls. This prevents effective interaction with the page and violates multiple WCAG criteria, including:
  • SC 2.4.3: Focus Order (Level A) — the order of focus is not logical.
  • SC 2.4.11: Focus not hidden (Level AA) — focus is on elements out of sight.
• Alternative:
  No available alternative. The invisible focus cannot be solved for keyboard users without adjusting the code.
• Measure:
  The page is being modified so that:
  • The focus order matches the visual order of the interface.
  • Invisible or irrelevant elements no longer receive focus (via tabindex=” -1" or aria-hidden="true”).
  • All interactive elements get a clear and visible focus style.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 2.4.7: Visible Focus (Level AA)

Finding: VID-1.F59 — Focus exits mobile menu and becomes invisible

• Description of the anomaly:
  When the website is viewed on a smaller screen (for example, 1280 × 1080 pixels with a 200% zoom), a mobile navigation menu appears, recognisable by the menu icon with three horizontal lines. When this menu opens, it fills a large part of the screen. After the last menu item, the keyboard focus moves to underlying page content. Because that content is then not visible (because the menu is still open), the focus is invisible.
• Cause:
  There is no focus management in the mobile menu. There is no focus trap or logical closure of the menu structure. This allows the user to leave the context of the opened menu while it is still in view. In addition, there is no automatic closure or clear visual focus indication.
• Consequence:
  Users who navigate with the keyboard lose the visibility and context of focus. As a result, it is unclear where they are on the page. This hinders access to the menu's functionality and causes confusion. This problem also affects the following success criteria:
  • SC 2.4.3: Focus Order (Level A) — the order is not logical.
  • SC 2.4.11: Focus not hidden (Level AA) — the focus is placed outside the vision area
• Alternative:
  None. The user cannot regain focus independently without mouse interaction.
• Measure:
  A focus trap is being implemented within the mobile menu so that keyboard users stay inside the menu as long as it is open. In addition, a logical closure is added, such as a close button or automatic closure as soon as the focus tries to leave the menu.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 2.4.7: Visible Focus (Level AA)

Finding: VID-1.F82 — Focus moves illogical search suggestion list

• Description of the anomaly:
  On multiple pages of the website, including the home page near the header “Search”, there is a search component that shows suggestions when entering a search term. When you go through the suggestion list with the keyboard and reach the last item, the focus jumps directly to the underlying page, outside the context of the search component. As a result, the focus is no longer visible and the user loses context.
• Cause:
  The suggestion list is not technically restricted or limited in order of focus. In addition, WAI-ARIA attributes and correct focus management techniques are missing. This creates an illogical and inaccessible user experience.
• Consequence:
  Users who navigate with the keyboard are unable to stay within the search component consistently. The focus is visually lost and ends up elsewhere on the page. This leads to a bad experience and affects several WCAG criteria:
  • SC 2.4.3: Focus Order (Level A) — the order is not logical and predictable.
   
  • SC 4.1.2: Name, Role, Value (Level A) — the interaction with the component is not properly supported by auxiliary software.
 
• Alternative:
  Not present. Users can't intuitively return to the search field or suggestion list via keyboard.
• Measure:
  The search component is revised using appropriate semantics and focus control.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 2.4.7: Visible Focus (Level AA)

Finding: VID-1.F89 — “Contact” menu item in dropdown lacks visible focus when keyboard navigation

• Description of the anomaly:
  On all pages of the website, the main navigation is located at the top. At a screen resolution of 1280 pixels wide, the menu item becomes “Contact” moved to a drop-down menu under the button “More”. When this item is reached via the keyboard, a visible focus style is missing. As a result, keyboard users cannot tell which element has been selected.
• Cause:
  The focus style is missing or not clearly visible in the CSS used for drop-down items. The default browser focus may be overwritten without an alternate visual indication. This is a common pitfall with custom navigation components or when using JavaScript-driven dropdowns.
• Consequence:
  Users who navigate via the keyboard can't see which part of the menu is currently in focus. This hampers their ability to make targeted choices and can lead to frustration or unintentional behavior.
• Alternative:
  None. With no visible focus, the drop-down menu for keyboard users is functionally limited or even inaccessible.
• Measure:
  A well-contrasting and consistent focus style is applied to all interactive elements in the drop-down menu.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 3.3.1: Fault Identification (Level A)

Finding: VID-1.F39 — Unclear error messages with forms

• Description of the anomaly:
  On multiple pages, including the logon-page, when mandatory fields are left blank or incorrectly filled in, the message appears “Please fill out this field”. This message is an instruction, but not a clear error message. This does not make it clear to users where and why the error occurs.
• Cause:
  The error messages are standard browser notifications (HTML5 validation), triggered via required attributes without further semantic support. No modified or accessible error message has been added that indicates an error.
• Consequence:
  Users may not understand why their input isn't being accepted. Especially for people with cognitive disabilities or assistive software, it is unclear whether and where an error occurred, because the message does not indicate an error, does not mention a field name, and is not worded negatively (as is common with error messages).
• Alternative:
  None. The notification depends on the browser and offers no additional context or consistency across forms.
• Measure:‍
  
  • Custom error messages are implemented that:
  • Make it clear that a mistake has been made.
  • Name the field to which the error relates.
  • explain what is expected.

    ‍

• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 4.1.2: Name, Role, Value (Level A)

Finding: VID-1.F13 — Cookie notification metrole="dialog” with no accessible name

• Description of the anomaly:
  When the website is opened for the first time, a cookie message appears on the screen. <h1><h6>This message is technically marked with role="dialog” but does not include an accessible name via aria-label, aria-labelled by, or a visible header (such as a —). As a result, screen readers only announce the dialogue as “Dialog Box”, without further explanation or context.
• Cause:
  When implementing the cookie message, no provision was made to name the dialogue with a semantically correct name. The message lacks a title or associated label that can be read by help software.
• Consequence:
  Screen reader users don't understand what the dialog box is about or what is expected of them. Without an indication such as “Cookie settings” whether “Cookie Notification” the function and urgency of the window is unclear, which can lead to confusion or the unintentional closure of the message without action.
• Alternative:
  None. There is no alternative access to the content or meaning of the cookie dialog box.
• Measure:
  The cookie notification will be given an accessible name.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 4.1.2: Name, Role, Value (Level A)

Finding: VID-1.F17 — Tab component with no correct ARIA structure and accessible name

• Description of the anomaly:
  The /projects page uses an interactive tab component with two tabs: “List View” and “Map View”. The container that contains these tabs has no semantic role (role="tablist”) and no accessible name. As a result, the whole thing is not presented as a logical and recognisable tab component to users of assistive technology.
• Cause:
  The tab structure is visually structured without the appropriate ARIA roles and attributes. As a result, screen readers cannot correctly interpret the structure, relationship between the tabs and the associated content panels.
• Consequence:
  Screen reader users are not provided with information about the nature of the component (tab structure), how many tabs there are, which is active, and what content the active tab is connected to. This leads to confusion and a greatly reduced user experience.
• Alternative:
  Not present. Without additional semantics, it is not possible for assistive technology to recognize the tab structure.
• Measure: The tab component is semantically rebuilt based on the WAI-ARIA Tab Authoring Practices.
• planning: The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 4.1.2: Name, Role, Value (Level A)

Finding: VID-1.F22 — Map view with no accessible name or role

• Description of the anomaly:
  On the /projects page, there is an interactive component with two tabs: “List View” and “Map View”. When the second tab is active, a map is displayed. This map is visually visible, but lacks a semantic role and has no accessible name, so assistive technology users do not know that a map is available or what its purpose is.
• Cause:
  The map was added as a visual element (e.g. via a <div>or iframe), without support by role, aria-label, or other accessible description. As a result, semantic context is missing.
• Consequence:
  Screen readers provide no information about the map's existence or function. This makes it impossible for blind or visually impaired users to understand that they are working with a map or what information it contains. This affects the usability and inclusiveness of the component.
• Alternative:
  None present. The content is provided visually only without additional textual or semantic support.
• Measure:
  The map will be provided with an accessible name and role.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 4.1.2: Name, Role, Value (Level A)

Finding: VID-1.F41 — Interactive icon (cross) with no accessible name in the “Continue with” list

• Description of the anomaly:
  On the my environment, appears when a user has previously started a process such as “File a Complaint”, the header “Continue with” followed by a list of pending processes. Each item in this list includes a cross icon (for example, to delete the item or cancel the process). However, this interactive icon has no accessible name or alternative text.
• Cause:
  The icon was probably added as a decorative symbol via a<span>, <i>or CSS (::before/: :after), without adding an aria-label, title, or visually hidden text. As a result, the element lacks the necessary semantic information.
• Consequence:
  Screen reader users can't understand what the icon does. This prevents the correct interpretation and operation of the interface. The problem affects both:
  • SC 4.1.2 — because the interactive element does not have an accessible name.
  • SC 1.1.1: Non-text content (Level A) — because the functional icon offers no text alternative.
• Alternative:
  None. The purpose of the icon is invisible to auxiliary software, and there is no textual equivalent.
• Measure:
  The button or icon gets an accessible name.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 4.1.2: Name, Role, Value (Level A)

Finding: VID-1.F44 — Map component with no accessible name or role

• Description of the anomaly:
  On the pages with a map view (for example, with contract information or related locations). This map has no semantic role and lacks an accessible name, so users of auxiliary software do not know that it is a map or what its content is.
• Cause:
  The map was technically added as an unlabeled visual element (such as an <div>or<iframe>) with no additional Wai-Aria marking, aria-label, aria-labelledby, or role.
• Consequence:
  Screen readers do not provide information about the presence of a map or its purpose. This means that users do not understand that they are in a map context, nor what the meaning or function of the element is.
• Alternative:
  None. No additional text, title, or semantics are provided for users who cannot perceive the visual aspect.
• Measure:
  The map component is made accessible by:
  • Add role="region” (or, if appropriate, application).
  • Adding an accessible name via aria-label="contract details card” or aria-labelledby linked to a visible headline.
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

SC 4.1.2: Name, Role, Value (Level A)

Finding: VID-1.F84 — Search component with no correct role and accessible name

• Description of the anomaly:
  On various pages of the website — including the homepage near the header “Search” — an interactive search component is used. When a user enters a search term, a list of results and suggestions appears. However, this component is not presented in a semantically correct way: it lacks a correct role (such as combobox, listbox, option) and an accessible name or description of the goal.
• Cause:
  The dynamic suggestion list is visually available but lacks the appropriate Wai-Aria attributes to make it clear that it is a coherent search component. There was no use of role="combobox”, aria-expanded, aria-controls, or aria-activedescendant, nor a descriptive label or title.
• Consequence:
  Users of screen readers or other assistive software don't understand that a search function is used with direct suggestions. In addition, the current state of the component (e.g. open or closed) is unclear, leading to confusion and possible navigation problems. Focus may also be lost or out of the visible context.
• Alternative:
  None present. Without additional semantics, the component is inaccessible to users who are unable to use visual cues.
• Measure:
  The search component is being rebuilt according to accessible guidelines combo boxes
• Planning:
  The update will be widely rolled out after the update from Umbraco 7 to Umbraco 13, scheduled for November 2025.

‍