`) erstellt:1. **Semantik:** Warum ist eine HTML-Liste semantisch gesehen nicht das richtige Element für die Darstellung von proportionalen Datenwerten?2. **Barrierefreiheit:** Wie interpretieren Screenreader eine Donut-Grafik, die technisch nur als ungeordnete Liste umgesetzt wurde?3. **Wartbarkei

Hier sind die Antworten auf deine Fragen zur Verwendung von HTML-Listen für die Darstellung von Donut-Grafiken:

1. Semantik: Warum ist eine Liste nicht das richtige Element?

Semantik im Web bedeutet, dass das gewählte HTML-Element die Bedeutung des Inhalts beschreibt, nicht dessen Aussehen.

• Zweck einer Liste: Ein <ul>-Element definiert eine ungeordnete Sammlung von gleichwertigen Elementen (Aufzählung). Es vermittelt keine mathematische oder proportionale Beziehung zwischen den Elementen.
• Fehlende Teil-Ganzes-Beziehung: Eine Donut-Grafik stellt Datenanteile an einem Ganzen dar (Proportionalität). Eine Liste sagt lediglich: "Hier sind Punkt A, Punkt B und Punkt C". Sie sagt nicht: "Punkt A macht 30 % des gesamten Kreises aus".
• Alternative: Für grafische Daten sind <svg> (Scalable Vector Graphics) oder das <canvas>-Element vorgesehen. SVG ist hier besonders stark, da es grafische Primitive (Kreise, Pfade) nutzt, die explizit für visuelle Repräsentationen gedacht sind.

2. Barrierefreiheit: Wie interpretieren Screenreader eine solche Liste?

Screenreader verlassen sich auf die semantische Struktur, um Nutzern mit Sehbehinderung den Inhalt zu erklären.

• Ankündigung als Liste: Ein Screenreader wird dem Nutzer mitteilen: "Liste mit 3 Elementen". Der Nutzer erwartet nun eine Aufzählung von Texten oder Links.
• Verlust der visuellen Information: Da die Grafik nur durch CSS-Tricks (Clip-Paths, Gradients) erzeugt wird, "sieht" der Screenreader den Donut nicht. Der Nutzer hört nur die nackten Zahlen oder Texte in den Listenelementen, versteht aber nicht, dass diese zueinander in einem proportionalen Verhältnis stehen.
• Fehlende Orientierung: Ohne zusätzliche ARIA-Attribute (wie role="graphics-document" oder aria-label) fehlt der Kontext, dass es sich um ein Diagramm handelt. Der Zusammenhang "Größe des Segments = Wert des Datensatzes" geht komplett verloren.

3. Wartbarkeit: Warum ist die manuelle Berechnung problematisch?

Die Erstellung von Grafiken rein über CSS-Eigenschaften von Listenelementen ist technisch "gehackt" und führt zu hohem Wartungsaufwand:

• Hoher Rechenaufwand: Für jedes Segment müssen Winkel, Startpositionen und ggf. Überlappungen berechnet werden (z. B. mit transform: rotate() und clip-path). Ändert sich ein einziger Wert im Datensatz, müssen oft alle nachfolgenden Elemente neu berechnet und angepasst werden.
• Fehleranfälligkeit: Manuelle Berechnungen in CSS sind schwer zu lesen und zu debuggen. Ein kleiner Tippfehler bei einem Grad-Wert zerstört die gesamte Optik der Grafik.
• Keine Dynamik: Wenn die Daten aus einer Datenbank kommen, müsste man komplexe Logik in JavaScript schreiben, die CSS-Strings manipuliert. In einem SVG hingegen kann man einfach Attribute wie stroke-dasharray oder Pfadkoordinaten nutzen, die für solche geometrischen Formen optimiert sind.
• Responsive Probleme: CSS-Clip-Paths verhalten sich bei Skalierungen oft anders als echte Vektorgrafiken, was zu unschönen Lücken oder "Blitzen" zwischen den Segmenten führen kann.

Fazit: Eine Liste für einen Donut-Chart zu nutzen, ist ein klassisches Beispiel für "mit dem falschen Werkzeug gearbeitet". Es erschwert den Zugang für behinderte Menschen und macht den Code unnötig komplex und starr. SVG ist hier der Industriestandard.