Known Issues
General
All text inputs
In Chrome on Windows, clicking outside an HTML input but inside a Web Component does not give focus to the input when it is empty. This issue sometimes does not occur if the input already contains a value. We suspect a focus propagation problem related to WebComponent behavior.
NVDA spells out certain words instead of reading them
It has been observed that on a system with German locale, NVDA spells out certain English words such as "selection", instead of reading them properly.
🐞 GitHub issue #6898, Stack Overflow
Text selection in Firefox
In Firefox, text selection when using Web Components does not work as expected. Highlighting and selecting text behaves inconsistently or fails.
🐞 GitHub issue #7761, Mozilla Bug #1587724, Mozilla Bug #1233594, Mozilla Bug #1590379
Components
kol-select
- Disabled options in KolSelect affect the total count in some screen readers. When an option is set to disabled: true, it may still be included in the overall option count announced by assistive technology. Using aria-hidden="true" on
<option>is not conforming with WAI‑ARIA and causes browser warnings, therefore it has been removed. As a result, screen readers might announce a higher number of available options than can actually be selected.
🐞 GitHub issue #7453 🐞 GitHub issue #7920
kol-input-color
The component InputColor is a wrapper for the native HTML element <input type="color"> which has accessibility problems:
- With NVDA, the element is announced as "clickable" and not as an input element.
- It's not possible to select a color using a screen reader.
- 9.1.3.1h Labeling of form elements programmatically detectable: The label is not announced by the screen reader. Since it reads linearly, no label is perceivable when
hideLabelis used. - 9.1.3.2 Meaningful sequence: When opening the color selection for "Color with error," there is no output. It is not accessible via the Tab key, only with the arrow keys, making it very confusing for screen reader users.
- 9.2.4.3 Logical keyboard navigation order: The focus order for "Color with error" is very unusual. Users do not realize that they have to use arrow keys to enter. This is especially problematic since it is not visible on black.
- 9.2.4.7 Clearly visible focus position: The focus is not visible on the black color icon in "Color with error."
For full accessibility, consider using predefined colors lists, e.g. using KolSelect or KolCheckbox.
🐞 GitHub issue #5549, 🐞 GitHub issue #7455
kol-table-stateful and kol-table-stateless
aria-sort changes sometimes not announced in NVDA
When a table column changes its sort order (i.e. when its aria-sort attribut changes), screen readers announce this change automatically. For unknown reasons, this sometime does not happen in NVDA.
🐞 GitHub issue (PR) #5780, 🐞 NVDA issue #10890, 🐞 NVDA issue #8132
Sticky headers
Sticky headers in tables are not supported at the moment, because position: sticky doesn't work together with overflow: auto on the table container, without introducing other drawbacks.
🐞 GitHub issue #7490, CSSWG Drafts issue, Code-Sample (StackBlitz)
kol-input-number and kol-input-date
'readonly' not announced in NVDA
The components InputNumber and InputDate render their respective native HTML elements <input type="number"> and <input type="date"> which both support the attribute readonly. When focusing the element, it's expected that the readonly attribute is announced as part of the element description. This isn't the case for NVDA.
🐞 GitHub issue #5554 (For number), 🐞 GitHub issue #5749 (For date), 🐞 NVDA issue #13672
kol-input-date
VoiceOver Reads Date Inputs with Percentage in Google Chrome
In Google Chrome, when using VoiceOver with empty date input fields (no initial value), an unexpected percentage value is read aloud alongside the usual prompt.
Notably, this issue does not occur with Windows Narrator, which handles empty date inputs correctly.
There is a Bug Report for this Issue:
VoiceOver reads negative percent values for month, day, and year steppers in <input type="date">
kol-input-text
The search of this component is highly browser-dependent. For example, the close button is either shown or hidden depending on the browser. Accessibility is therefore not achieved.
kol-select
Screen reader only reads last selected option
KolSelect is using native HTML <select>.
When using KolSelect with the multiple property, the native HTML <select> may cause problems with screen readers. Often the entire selection is not read out, but only the last one. Therefore, the KolSelect has no full accessibility.
Limited Styling Capabilities for <select> and <option> Elements
The <select> element and its <option> tags offer limited styling options. Specifically, states such as "selected", "focus" or "active" cannot be reliably customized using CSS. This leads to challenges in meeting accessibility standards, especially in ensuring sufficient contrast ratios.
Impact:
-
Limited Customization: The visual state of dropdown options (e.g., on focus or selection) cannot be consistently customized across all browsers. This makes it difficult to create an accessible visual experience for all users.
-
Browser-Dependent Rendering: The appearance of the
<select>element varies across browsers and operating systems, resulting in inconsistent user experiences. -
Contrast Issues: Since the contrast of the default dropdown rendering is controlled by the browser, it's not always possible to ensure WCAG-compliant contrast ratios, which may hinder readability for users with visual impairments.
kol-icon
Firefox Accessibility Issue with aria-label
The use of aria-label or aria-labelledby on <kol-icon> or its nested elements does not work reliably in Firefox. Even applying these attributes directly to <kol-icon> has no effect, which points to a browser-specific issue with ARIA support in custom elements or shadow DOM contexts.
Key Points
- The issue lies in Firefox's handling of ARIA attributes on custom web components or deeply nested elements.
- This is not related to dynamic announcements (
aria-live) but specifically to the inability of Firefox to processaria-labeloraria-labelledbycorrectly in these cases. - The issue is browser-specific and does not consistently occur in Chrome, Edge, or Safari.
Conclusion
This is a limitation in Firefox’s ARIA implementation. Until it is resolved, alternative strategies like visually hidden text near the element or redundant error messages should be used to ensure accessibility.
🐞 GitHub issue #7076, 🐞 GitHub issue #7119
Toaster
Toasts are rendered in a container that's appended as first element of <body> and elevated using a high z-index.
When using modal Dialogs these are rendered above toasts on the top layer. Hence, toast messages are always blocked by Modal Dialogs. We recommend completely avoiding Toasts in Modals and giving feedback within the modal directly.