Skip to content

Commit f8bcc31

Browse files
authored
Add Known Issues page (English) (#334)
2 parents 47248ce + d943f45 commit f8bcc31

File tree

2 files changed

+287
-0
lines changed

2 files changed

+287
-0
lines changed

docs/91-known-issues.mdx

Lines changed: 140 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,140 @@
1+
---
2+
title: Bekannte Probleme
3+
---
4+
5+
## Allgemein
6+
7+
### Alle Texteingabefelder
8+
9+
In Chrome unter Windows erhält ein leeres HTML-Eingabefeld beim Klicken außerhalb des Eingabefelds, aber innerhalb einer WebComponent, keinen Fokus. Dieses Problem tritt manchmal nicht auf, wenn das Eingabefeld bereits einen Wert enthält. Wir vermuten ein Problem mit der Fokus-Weitergabe im Zusammenhang mit WebComponent-Verhalten.
10+
11+
[🐞 GitHub Issue #7713](https://github.com/public-ui/kolibri/issues/7713)
12+
13+
### NVDA buchstabiert bestimmte Wörter statt sie vorzulesen
14+
15+
Es wurde beobachtet, dass NVDA auf einem System mit deutscher Spracheinstellung bestimmte englische Wörter wie "selection" buchstabiert, anstatt sie korrekt vorzulesen.
16+
17+
[🐞 GitHub Issue #6898](https://github.com/public-ui/kolibri/issues/6898),
18+
[Stack Overflow](https://stackoverflow.com/questions/69091167/nvda-spells-words-where-it-shouldnt)
19+
20+
## Komponenten
21+
22+
### kol-select
23+
24+
- Deaktivierte Optionen in KolSelect beeinflussen die Gesamtanzahl in einigen Screenreadern. Wenn eine Option mit disabled: true gesetzt ist, wird sie möglicherweise trotzdem in der Gesamtanzahl der Optionen von unterstützenden Technologien mitgezählt. Die Verwendung von aria-hidden="true" auf `<option>` entspricht nicht den WAI-ARIA-Richtlinien und verursacht Browser-Warnungen, daher wurde dies entfernt. Infolgedessen könnten Screenreader eine höhere Anzahl verfügbarer Optionen ansagen, als tatsächlich auswählbar sind.
25+
26+
[🐞 GitHub Issue #7453](https://github.com/public-ui/kolibri/pull/7453)
27+
[🐞 GitHub Issue #7920](https://github.com/public-ui/kolibri/pull/7920)
28+
29+
### kol-input-color
30+
31+
Die Komponente InputColor ist ein Wrapper für das native HTML-Element `<input type="color">`, das Zugänglichkeitsprobleme aufweist:
32+
33+
- Mit NVDA wird das Element als "klickbar" und nicht als Eingabefeld angekündigt.
34+
- Es ist nicht möglich, mit einem Screenreader eine Farbe auszuwählen.
35+
- **9.1.3.1h Programmgesteuerte Erkennbarkeit der Beschriftung von Formularelementen:**
36+
Das Label wird vom Screenreader nicht angekündigt. Da linear gelesen wird, ist bei Verwendung von `hideLabel` kein Label wahrnehmbar.
37+
- **9.1.3.2 Sinnvolle Reihenfolge:**
38+
Beim Öffnen der Farbauswahl für "Farbe mit Fehler" erfolgt keine Ausgabe. Sie ist nicht über die Tab-Taste, sondern nur mit den Pfeiltasten erreichbar, was für Screenreader-Nutzer sehr verwirrend ist.
39+
- **9.2.4.3 Logische Tastaturnavigationsreihenfolge:**
40+
Die Fokusreihenfolge für "Farbe mit Fehler" ist sehr ungewöhnlich. Nutzer erkennen nicht, dass sie die Pfeiltasten verwenden müssen. Dies ist besonders problematisch, da es auf Schwarz nicht sichtbar ist.
41+
- **9.2.4.7 Deutlich sichtbare Fokusposition:**
42+
Der Fokus ist auf dem schwarzen Farbsymbol bei "Farbe mit Fehler" nicht sichtbar.
43+
44+
Für vollständige Barrierefreiheit sollten vordefinierte Farblisten, z. B. mit KolSelect oder KolCheckbox, verwendet werden.
45+
46+
[🐞 GitHub Issue #5549](https://github.com/public-ui/kolibri/issues/5549),
47+
[🐞 GitHub Issue #7455](https://github.com/public-ui/kolibri/pull/7455)
48+
49+
### kol-table-stateful und kol-table-stateless
50+
51+
#### Änderungen an `aria-sort` werden manchmal in NVDA nicht angekündigt
52+
53+
Wenn sich die Sortierreihenfolge einer Tabellenspalte ändert (d. h. wenn sich das `aria-sort`-Attribut ändert), kündigen Screenreader diese Änderung normalerweise automatisch an. Aus unbekannten Gründen geschieht dies manchmal in NVDA nicht.
54+
55+
[🐞 GitHub Issue (PR) #5780](https://github.com/public-ui/kolibri/pull/5780),
56+
[🐞 NVDA Issue #10890](https://github.com/nvaccess/nvda/issues/10890),
57+
[🐞 NVDA Issue #8132](https://github.com/nvaccess/nvda/issues/8132)
58+
59+
#### Feste Tabellenköpfe (Sticky Headers)
60+
61+
Feste Tabellenköpfe werden derzeit nicht unterstützt, da `position: sticky` nicht mit `overflow: auto` im Tabellen-Container funktioniert, ohne andere Nachteile einzuführen.
62+
63+
[🐞 GitHub Issue #7490](https://github.com/public-ui/kolibri/issues/7490),
64+
[CSSWG Drafts Issue](https://github.com/w3c/csswg-drafts/issues/865),
65+
[Code-Beispiel (StackBlitz)](https://stackblitz.com/edit/stackblitz-starters-umfg2y7m)
66+
67+
### kol-input-number und kol-input-date
68+
69+
#### 'readonly' wird in NVDA nicht angekündigt
70+
71+
Die Komponenten InputNumber und InputDate rendern die jeweiligen nativen HTML-Elemente `<input type="number">` und `<input type="date">`, die beide das Attribut `readonly` unterstützen. Beim Fokussieren des Elements wird erwartet, dass das Attribut `readonly` als Teil der Elementbeschreibung angekündigt wird. Dies ist bei NVDA nicht der Fall.
72+
73+
[🐞 GitHub Issue #5554](https://github.com/public-ui/kolibri/issues/5554) (Für number),
74+
[🐞 GitHub Issue #5749](https://github.com/public-ui/kolibri/issues/5749) (Für date),
75+
[🐞 NVDA Issue #13672](https://github.com/nvaccess/nvda/issues/13672)
76+
77+
### kol-input-date
78+
79+
#### VoiceOver liest Datumsfelder mit Prozentangabe in Google Chrome vor
80+
81+
In Google Chrome liest VoiceOver bei leeren `date`-Eingabefeldern (ohne Anfangswert) einen unerwarteten Prozentwert zusammen mit der üblichen Eingabeaufforderung vor.
82+
83+
Dieses Problem tritt bei Windows Narrator nicht auf, der leere Datumsfelder korrekt behandelt.
84+
85+
Es gibt einen Bug-Report zu diesem Problem:
86+
87+
[VoiceOver reads negative percent values for month, day, and year steppers in `<input type="date">`](https://issuetracker.google.com/issues/361250561?pli=1)
88+
89+
### kol-input-text
90+
91+
Das Suchfeld dieser Komponente ist stark vom Browser abhängig. Beispielsweise wird das Schließen-Symbol je nach Browser angezeigt oder nicht. Barrierefreiheit ist daher nicht gewährleistet.
92+
93+
[🐞 GitHub Issue #6307](https://github.com/public-ui/kolibri/issues/6307)
94+
95+
### kol-select
96+
97+
#### Screenreader liest nur die zuletzt ausgewählte Option vor
98+
99+
KolSelect verwendet das native HTML-Element `<select>`.
100+
101+
Bei Verwendung von KolSelect mit der Eigenschaft `multiple` kann das native HTML-Element `<select>` Probleme mit Screenreadern verursachen. Oft wird nicht die gesamte Auswahl vorgelesen, sondern nur die letzte. Daher ist KolSelect nicht vollständig barrierefrei.
102+
103+
#### Eingeschränkte Styling-Möglichkeiten für `<select>` und `<option>`-Elemente
104+
105+
[Stackblitz-Beispiel](https://stackblitz.com/edit/vitejs-vite-nthnce?file=src%2Fstyle.css)
106+
107+
Das `<select>`-Element und seine `<option>`-Tags bieten nur eingeschränkte Styling-Möglichkeiten. Insbesondere Zustände wie "selected", "focus" oder "active" können nicht zuverlässig per CSS angepasst werden. Dies erschwert es, Barrierefreiheitsstandards einzuhalten, insbesondere ausreichende Kontrastverhältnisse sicherzustellen.
108+
109+
**Auswirkungen**:
110+
111+
- **Eingeschränkte Anpassbarkeit**: Der visuelle Zustand von Dropdown-Optionen (z. B. bei Fokus oder Auswahl) kann nicht in allen Browsern konsistent angepasst werden. Dadurch ist es schwierig, ein barrierefreies visuelles Erlebnis für alle Nutzer zu schaffen.
112+
113+
- **Browserabhängige Darstellung**: Das Erscheinungsbild des `<select>`-Elements variiert je nach Browser und Betriebssystem, was zu uneinheitlichen Nutzererfahrungen führt.
114+
115+
- **Kontrastprobleme**: Da der Kontrast der Standard-Dropdown-Darstellung vom Browser gesteuert wird, ist es nicht immer möglich, WCAG-konforme Kontrastverhältnisse sicherzustellen, was die Lesbarkeit für sehbehinderte Nutzer beeinträchtigen kann.
116+
117+
### kol-icon
118+
119+
#### Firefox-Problem mit `aria-label` bei Barrierefreiheit
120+
121+
Die Verwendung von `aria-label` oder `aria-labelledby` auf `<kol-icon>` oder dessen verschachtelten Elementen funktioniert in Firefox nicht zuverlässig. Selbst das direkte Anwenden dieser Attribute auf `<kol-icon>` hat keine Wirkung, was auf ein browser-spezifisches Problem mit ARIA-Unterstützung bei Custom Elements oder Shadow DOM hinweist.
122+
123+
##### Wichtige Punkte
124+
125+
- Das Problem liegt in der Handhabung von ARIA-Attributen bei benutzerdefinierten Webkomponenten oder tief verschachtelten Elementen in Firefox.
126+
- Es handelt sich nicht um dynamische Ankündigungen (`aria-live`), sondern speziell um die Unfähigkeit von Firefox, `aria-label` oder `aria-labelledby` in diesen Fällen korrekt zu verarbeiten.
127+
- Das Problem ist browser-spezifisch und tritt nicht konsistent in Chrome, Edge oder Safari auf.
128+
129+
##### Fazit
130+
131+
Dies ist eine Einschränkung in der ARIA-Implementierung von Firefox. Bis das Problem behoben ist, sollten alternative Strategien wie visuell versteckter Text in der Nähe des Elements oder redundante Fehlermeldungen verwendet werden, um Barrierefreiheit sicherzustellen.
132+
133+
[🐞 GitHub Issue #7076](https://github.com/public-ui/kolibri/issues/7076),
134+
[🐞 GitHub Issue #7119](https://github.com/public-ui/kolibri/issues/7119)
135+
136+
### Toaster
137+
138+
Toasts werden in einem Container gerendert, der als erstes Element in `<body>` eingefügt und mit einem hohen `z-index` versehen wird.
139+
140+
Bei der Verwendung von [modalen Dialogen](https://developer.mozilla.org/de/docs/Web/HTML/Element/dialog) werden diese über Toasts auf der [Top Layer](https://developer.mozilla.org/en-US/docs/Glossary/Top_layer) gerendert. Daher werden Toast-Nachrichten immer von Modalen blockiert. Wir empfehlen, Toasts in Modalen komplett zu vermeiden und Rückmeldungen direkt im Modal zu geben.
Lines changed: 147 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,147 @@
1+
---
2+
title: Known Issues
3+
---
4+
5+
## General
6+
7+
### All text inputs
8+
9+
In Chrome on Windows, clicking outside an HTML input but inside a WebComponent 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.
10+
11+
[🐞 GitHub issue #7713](https://github.com/public-ui/kolibri/issues/7713)
12+
13+
### NVDA spells out certain words instead of reading them
14+
15+
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.
16+
17+
[🐞 GitHub issue #6898](https://github.com/public-ui/kolibri/issues/6898),
18+
[Stack Overflow](https://stackoverflow.com/questions/69091167/nvda-spells-words-where-it-shouldnt)
19+
20+
21+
## Components
22+
23+
### kol-select
24+
25+
- 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.
26+
27+
[🐞 GitHub issue #7453](https://github.com/public-ui/kolibri/pull/7453)
28+
[🐞 GitHub issue #7920](https://github.com/public-ui/kolibri/pull/7920)
29+
30+
### kol-input-color
31+
32+
The component InputColor is a wrapper for the native HTML element `<input type="color">` which has accessibility problems:
33+
34+
- With NVDA, the element is announced as "clickable" and not as an input element.
35+
- It's not possible to select a color using a screen reader.
36+
- **9.1.3.1h Labeling of form elements programmatically detectable:**
37+
The label is not announced by the screen reader. Since it reads linearly, no label is perceivable when `hideLabel` is used.
38+
- **9.1.3.2 Meaningful sequence:**
39+
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.
40+
- **9.2.4.3 Logical keyboard navigation order:**
41+
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.
42+
- **9.2.4.7 Clearly visible focus position:**
43+
The focus is not visible on the black color icon in "Color with error."
44+
45+
For full accessibility, consider using predefined colors lists, e.g. using KolSelect or KolCheckbox.
46+
47+
[🐞 GitHub issue #5549](https://github.com/public-ui/kolibri/issues/5549),
48+
[🐞 GitHub issue #7455](https://github.com/public-ui/kolibri/pull/7455)
49+
50+
### kol-table-stateful and kol-table-stateless
51+
52+
#### `aria-sort` changes sometimes not announced in NVDA
53+
54+
When a table column changes its sort order (i.e. when its `aria-sort` attribut changes), screen readers announce this change automatically.
55+
For unknown reasons, this sometime does not happen in NVDA.
56+
57+
[🐞 GitHub issue (PR) #5780](https://github.com/public-ui/kolibri/pull/5780),
58+
[🐞 NVDA issue #10890](https://github.com/nvaccess/nvda/issues/10890),
59+
[🐞 NVDA issue #8132](https://github.com/nvaccess/nvda/issues/8132)
60+
61+
#### Sticky headers
62+
63+
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.
64+
65+
[🐞 GitHub issue #7490](https://github.com/public-ui/kolibri/issues/7490),
66+
[CSSWG Drafts issue](https://github.com/w3c/csswg-drafts/issues/865),
67+
[Code-Sample (StackBlitz)](https://stackblitz.com/edit/stackblitz-starters-umfg2y7m)
68+
69+
### kol-input-number and kol-input-date
70+
71+
#### 'readonly' not announced in NVDA
72+
73+
The components InputNumber and InputDate render their respective native HTML elements `<input type="number">` and `<input type="date">` which both support the
74+
attribute `readonly`.
75+
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.
76+
77+
[🐞 GitHub issue #5554](https://github.com/public-ui/kolibri/issues/5554) (For number),
78+
[🐞 GitHub issue #5749](https://github.com/public-ui/kolibri/issues/5749) (For date),
79+
[🐞 NVDA issue #13672](https://github.com/nvaccess/nvda/issues/13672)
80+
81+
### kol-input-date
82+
83+
#### VoiceOver Reads Date Inputs with Percentage in Google Chrome
84+
85+
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.
86+
87+
Notably, this issue does not occur with Windows Narrator, which handles empty date inputs correctly.
88+
89+
There is a Bug Report for this Issue:
90+
91+
[VoiceOver reads negative percent values for month, day, and year steppers in `<input type="date">`](https://issuetracker.google.com/issues/361250561?pli=1)
92+
93+
### kol-input-text
94+
95+
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.
96+
97+
[🐞 GitHub issue #6307](https://github.com/public-ui/kolibri/issues/6307)
98+
99+
### kol-select
100+
101+
#### Screen reader only reads last selected option
102+
103+
KolSelect is using native HTML `<select>`.
104+
105+
When using KolSelect with the `multiple` property, the native HTML `<select>` may cause problems with screen readers.
106+
Often the entire selection is not read out, but only the last one. Therefore, the KolSelect has no full accessibility.
107+
108+
#### Limited Styling Capabilities for `<select>` and `<option>` Elements
109+
110+
[Stackblitz Example](https://stackblitz.com/edit/vitejs-vite-nthnce?file=src%2Fstyle.css)
111+
112+
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.
113+
114+
**Impact**:
115+
116+
- **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.
117+
118+
- **Browser-Dependent Rendering**: The appearance of the `<select>` element varies across browsers and operating systems, resulting in inconsistent user experiences.
119+
120+
- **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.
121+
122+
### kol-icon
123+
124+
#### Firefox Accessibility Issue with `aria-label`
125+
126+
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.
127+
128+
##### Key Points
129+
130+
- The issue lies in Firefox's handling of ARIA attributes on custom web components or deeply nested elements.
131+
- This is not related to dynamic announcements (`aria-live`) but specifically to the inability of Firefox to process `aria-label` or `aria-labelledby` correctly in these cases.
132+
- The issue is browser-specific and does not consistently occur in Chrome, Edge, or Safari.
133+
134+
##### Conclusion
135+
136+
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.
137+
138+
[🐞 GitHub issue #7076](https://github.com/public-ui/kolibri/issues/7076),
139+
[🐞 GitHub issue #7119](https://github.com/public-ui/kolibri/issues/7119)
140+
141+
### Toaster
142+
143+
Toasts are rendered in a container that's appended as first element of `<body>` and elevated using a high `z-index`.
144+
145+
When using [modal Dialogs](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog) these are rendered above toasts on the
146+
[top layer](https://developer.mozilla.org/en-US/docs/Glossary/Top_layer). Hence, toast messages are always blocked by Modal Dialogs. We recommend completely
147+
avoiding Toasts in Modals and giving feedback within the modal directly.

0 commit comments

Comments
 (0)