Paginierungssystem

Was macht Paginierungssystem?

Zweck

Das Paginierungssystem-Skill bietet eine Methodik zur Gestaltung der Schnittstelle, die große Datensets in einzelne Seiten unterteilt. Es stellt sicher, dass Benutzer durch lange Listen von Elementen (Produkte, Suchergebnisse, Artikel) navigieren können, während sie ein klares Gefühl dafür behalten, "wo sie sind" und "wie viel Inhalt noch übrig ist". Ein robustes Paginierungssystem balanciert Navigationsgenauigkeit mit Einfachheit aus, minimiert kognitive Belastung und verhindert Desorientierung.

Anwendungsfälle

• Gestaltung von Suchergebnisseiten für E-Commerce- oder Verzeichnisseiten
• Organisation langer Blog- oder Nachrichtenarchive
• Implementierung von "Mehr laden" versus traditioneller nummerierter Paginierung für Inhaltshubs
• Erstellung von Navigation für datenintensive Dashboard-Tabellen oder Logs
• Optimierung von mehrseitigen Formularen oder schrittbasierten Assistenten, bei denen einzelne Abschnitte als separate Ansichten behandelt werden

Wann NICHT verwenden

• Kleine Datensets (<12 Elemente): Wenn alle Inhalte bequem auf einen oder zwei Bildschirme passen, fügt Paginierung unnötige Klicks und Reibung hinzu.
• Infinite-Scroll-Kontexte: Wenn der Benutzer stark entdeckungsorientierte soziale Feeds oder Nachrichtenströme erkundet, bei denen bestimmte Seitenadressen nicht wichtig sind (stattdessen infinite-scroll-implementation verwenden).
• Einzelne narrative Inhalte: Für Artikel oder Geschichten, die einem linearen Fluss folgen, bei dem "Vorherige/Nächste"-Links ausreichend sind.

Eingaben

1. Gesamtanzahl der Elemente: Wie viele Elemente enthält die Sammlung insgesamt?
2. Elemente pro Seite: Wie hoch ist die Standarddichte (z.B. 12, 24, 48 Elemente)?
3. Aktueller Seitenkontext: Welche Seite zeigt der Benutzer gerade an?
4. Anzeigeeinschränkungen: Wie viel horizontaler Platz steht für die Paginierungsleiste zur Verfügung (aus responsive-grid-system)?

Ausgaben

1. Paginierungsanatomie-Spezifikation: Definierte visuelle Stile für Seitenzahlen, Vorherige/Nächste-Schaltflächen und "Springen"-Steuerelemente (Auslassungspunkte).
2. Zustandsmatrix: Visuelle Behandlungen für Standard-, Aktuell-, Hover-, Fokus- und Deaktiviert-Zustände (z.B. "Vorherige"-Schaltfläche auf Seite 1).
3. Responsive Strategie: Ein Plan, wie die Paginierungsleiste von Desktop (vollständige Anzeige) zu Mobilgeräten (kompakte Ansicht) kollabiert.
4. Barrierefreiheitskarte: Explizite Definitionen für ARIA-Rollen, Labels und Tastaturinteraktionsmuster.

Arbeitsablauf

1. Bereichsstrategie definieren

Bestimmen, wie viele Seitenzahlen gleichzeitig basierend auf dem Gesamtumfang angezeigt werden sollen:

• Einfach (3-5 Seiten): Alle Seitenzahlen anzeigen.
• Mittel (6-10 Seiten): Erste, letzte und ein Fenster um die aktuelle Seite anzeigen.
• Komplex (10+ Seiten): Auslassungspunkte (...) verwenden, um übersprungene Bereiche darzustellen (z.B. 1 ... 4 5 6 ... 20).

2. Navigationssteuerung entwerfen

Die visuelle Hierarchie der Paginierungsleiste festlegen:

• Primäre Aktionen: Vorherige- und Nächste-Schaltflächen sollten deutlich sichtbar sein und sich an den Enden der Leiste befinden.
• Aktuelle-Seiten-Anzeige: Einen kontrastreichen Stil (Hintergrundfarbe oder starker Rand) verwenden, um die aktuelle Seite sofort erkennbar zu machen.
• Seitenzahlen: Sicherstellen, dass sie wie interaktive Elemente aussehen (z.B. unter Verwendung von interactive-state-system).

3. Flüssige Abstände und Größen anwenden

Das fluid-spacing-system verwenden, um sicherzustellen, dass Ziele nutzbar sind:

• Touch-Ziele: Jede Seitenzahl und Schaltfläche sollte mindestens 44x44px groß sein; wenn die visuelle Dichte kleinere Steuerelemente erfordert, legt WCAG 2.2 (2.5.8 Mindestzielgröße) eine absolute Untergrenze von 24x24px mit ausreichendem Abstand zwischen den Zielen fest, um versehentliche Aktivierungen zu vermeiden.
• Interne Abstände: Konsistente Abstände (z.B. --space-xs) zwischen den Seitenzahlen verwenden, um Fehlklicks zu vermeiden.

4. Barrierefreiheit (WCAG AA/AAA) einrichten

• Landmarke: Die Paginierung in ein <nav>-Element mit aria-label="pagination" einbetten.
• Aktuelle Seite: aria-current="page" auf dem aktiven Seitenlink verwenden.
• Deaktivierte Zustände: Sicherstellen, dass die "Vorherige"-Schaltfläche visuell und programmatisch deaktiviert ist (z.B. aria-disabled="true"), wenn sie sich auf der ersten Seite befindet.
• Tastaturpfad: Benutzer müssen mit der Tab-Taste durch jede Seitenzahl und jedes Steuerelement navigieren können, und das fokussierte Steuerelement darf niemals vollständig durch fixierte Kopf-/Fußzeilen verdeckt werden (WCAG 2.2, 2.4.11 Fokus nicht verdeckt).

5. Responsive Anpassungen planen

Den Übergang von Desktop zu Mobilgeräten abbilden:

• Die Reduktionsregel: Auf Mobilgeräten die meisten Seitenzahlen ausblenden und nur "Vorherige", "Nächste" und den aktuellen Status anzeigen (z.B. "Seite 4 von 20").
• Visuelle Skalierung: Wenn Seitenzahlen erhalten bleiben müssen, das "Fenster" auf die aktuelle Seite und ihre unmittelbaren Nachbarn reduzieren (z.B. 1 ... 4 ... 20).

Entscheidungsregeln

• Zahlen vs. Mehr laden: Zahlen verwenden, wenn Benutzer bestimmte Ergebnisse mit einem Lesezeichen versehen oder teilen müssen (z.B. "Siehe Seite 4"). "Mehr laden" verwenden, wenn das Ziel eine verlängerte Entdeckung und Vergleich ist.
• Das "7-Elemente"-Maximum: Auf Desktop vermeiden, mehr als 7-9 Elemente in der Paginierungsleiste anzuzeigen (einschließlich Auslassungspunkte und Schaltflächen), um das Layout sauber zu halten.
• Vorhersagbarkeit: "Vorherige" immer links und "Nächste" immer rechts platzieren. Diese Schaltflächen niemals verstecken; sie nur deaktivieren, wenn sie nicht anwendbar sind.
• Sofortiges Feedback: Das Klicken auf eine Seitenzahl sollte den Benutzer sofort zum Anfang der Inhaltsliste scrollen oder einen klaren "Lade"-Zustand anzeigen.

Einschränkungen

• Barrierefreiheit: Die Paginierung muss tastaturnavigierbar und screenreaderfreundlich sein. Labels müssen beschreibend sein (z.B. "Gehe zu Seite 5" statt nur "5"). Interaktive Ziele müssen mindestens das WCAG 2.2 24x24px Minimum (2.5.8) erfüllen, wobei 44x44px für primäre Vorherige/Nächste-Steuerelemente bevorzugt werden.
• Responsivität: Die Paginierungsleiste darf niemals horizontalen Überlauf verursachen oder andere UI-Elemente überlappen.
• Visuelle Hierarchie: Die Paginierung sollte visuell vom Inhalt unterscheidbar sein, aber nicht prominenter als der Inhalt selbst.

Häufige Fehlermuster

• Winzige Touch-Ziele: Kleine, gedrängte Zahlen, die auf Mobilgeräten unmöglich genau anzutippen sind.
• Unsichtbarer aktiver Zustand: Benutzer wissen nicht, auf welcher Seite sie sich befinden, weil der "Aktiv"-Stil zu subtil ist.
• Unterbrochene Tastaturschleife: Vergessen, den Fokus zu behandeln, wenn der Seiteninhalt über AJAX aktualisiert wird (der Benutzer sollte an den Anfang der Ergebnisse verschoben werden).
• Die "Mobile Explosion": Versuch, 10 Seitenzahlen auf einem Mobilbildschirm anzuzeigen, was horizontalen Scrollen oder Layoutbrüche verursacht.
• Vage Labels: Nur Zahlen ohne aria-labels verwenden, was es für Screenreader-Benutzer schwierig macht, den Kontext zu verstehen.

Validierungskriterien

• Aktuelle Seite ist visuell unterscheidbar und hat aria-current="page".
• Navigation ist in ein <nav> mit einem beschreibenden aria-label eingebettet.
• Touch-Ziele erfüllen mindestens das WCAG 2.2 Minimum von 24x24px (44x44px für primäre Vorherige/Nächste-Steuerelemente).
• Deaktivierte Zustände (Vorherige auf Seite 1, Nächste auf letzter Seite) sind klar und programmatisch definiert.
• Responsives Verhalten ist definiert (kompakte Ansicht für Mobilgeräte).
• Tastaturnutzer können die gesamte Paginierungsleiste navigieren.
• Auslassungspunkte werden korrekt für große Bereiche verwendet.