Table: Spezifikation und Erwartungen an die Barrierefreiheit

[deleonio]

Hier wollen wir diskutieren, welche Erwartungen wir an die Komponente haben. Mittels dieser Diskussion haben alle einen aktuellen Stand und können jederzeit neue Hinweise und Verbesserungsvorschläge einbringen.

[deleonio]

Aktuell diskutieren wir, ob eine Tabelle einen Fokus-Rahmen haben darf oder nicht: #2375

Aktueller Stand:

• Ja, wenn die Tabelle einen Scrollbalken anzeigt. Also die Breite der Tabelle größer ist, als der Tabellen-Container.
• Nein, sonst.

Lösung: Mittels eines Listeners wird ermittelt, ob ein Scrollbalken angezeigt wird oder nicht. Wird ein Scrollbalken angezeigt, dann wird der tabindex="0" gesetzt, ansonsten wird der tabindex entfernt.

Link https://javascript.plainenglish.io/how-to-check-if-a-scrollbar-is-visible-with-javascript-95aced8b420d

[MarcusMorba]

Interessant wäre für mich, wie eine optimale Tastatur-Navigation zwischen Header (inkl. Filter, Sortierung), Body, Footer (inkl. Paginator) aussehen sollte, wenn man diese als "sections" betrachtet. Navigation nur via TAB oder auch anderen Shortcuts/Keys?

Nach WCAG bzw. APG-Guide gibt es hier keine definierten Shortcuts.
D.h. es wäre hierfür erstmal interessant, was Nutzer sich wünschen würden. Das Prinzip könnte dann auf alle Content-Elemente angewendet werden, welche aus Header-, Body- und Footer-Sections bestehen.

Unter Windows gibt es folgendes:

• F6 | Cycle through screen elements in a window or on the desktop. (Ctrl + F6 bei Webanwendungen)
• F10 | Activate the Menu bar in the active app.

Ein Basis-Beispiel (Region navigation) hierfür wird bei Mattermost angewandt: https://docs.mattermost.com/channels/keyboard-accessibility.html#:~:text=Region%20navigation&text=Use%20F6%20in%20the%20desktop,Message%20list%20region

Es könnte bei interaktiven Tabellen dann z.B. Ctrl + F6 (focus on next region) und Ctrl + Shift + F6 (focus on previous region) angewandt werden.

Beim W3C APG-Guide gibt es Table und Grid (Interactive Tabular Data and Layout Containers)

• https://www.w3.org/WAI/ARIA/apg/patterns/table/ (no keyboard interaction)
• https://www.w3.org/WAI/ARIA/apg/patterns/grid/

Bei MS heißt die Table mittlerweile "Data Grid" oder "DetailsList":

• https://learn.microsoft.com/en-us/fluent-ui/web-components/components/data-grid?pivots=typescript
• https://developer.microsoft.com/en-us/fluentui#/controls/web/detailslist

Falls gewünscht kann ich gerne ein Detailkonzept ausarbeiten.

[deleonio]

@ElVariablo kannst Du bitte auf diese Nachricht antworten und gerne notwendige Schritte für uns ableiten. Danke

[PippiViktualia]

Vielen Dank für das Input und auch das Angebot ein Detailkonzept zu Erarbeiten. Aber KoliBri stellt derzeit nur Tabellen zur Darstellung von Daten bereit. Tabellen mit interaktiven Bearbeitungsfunktionalitäten (data grid) sind aktuell nicht Bestandteil von KoliBri.

Grundsätzlich sollten interaktive Tabellen aus Sicht der Barrierefreiheit nach Möglichkeit vermieden werden, da deren barrierefreie Umsetzung nicht immer einfach zu realisieren ist. Idealerweise befinden sich Filter und Sortierfunktionalitäten außerhalb der Tabelle und die Datentabelle enthält keine Bearbeitungsfunktionalitäten. So können auch native HTML-Elemente zur Umsetzung der gewünschten Funktionalitäten eingesetzt werden.

[MarcusMorba]

Vielen Dank für das Feedback. Was "interaktive Tabellen" und a11y betrifft, stimme ich zu - das ist nicht einfach zu realisieren. Zudem ist es oft schwierig dem ungeübten Nutzer die notwendigen Shortcuts zur Tastaturbedienung zu vermitteln. Hierfür sind extra Informationen in einer Hilfe-Funktionalität notwendig. Diese könnte global (allgemein o. context-abhängig) oder in der Komponente selbst integriert werden.

Momentan gibt es bestimmt noch genügend Baustellen mit höherer Priorität.