Content Sliders, Diashows, Carousels, ...
[Materialsammlung]

Bedeutung von Sliders, Diashows und Carousels

Erscheinungsformen von Sliders

Sie laufen unter unterschiedlichen Namen und in verschiedenen Formen und Funktionalitäten: Sliders, Diashows, Carousels und so weiter. Gemeinsam ist allen, dass sich Seitenbereiche automatisch bewegen oder ändern oder dies ausgelöst werden kann, dass also etwas abläuft.

Als häufige Animation für den Ablauf hat sich eingebürgert, dass ein Bereich nach links aus dem Bildschirm gleitet und ein neues Element den Bereich ausfüllt. Als Überbegriff wird daher für diese Features üblicherweise Slider verwendet.

Für Varianten verwende ich einmal folgende Terminologie:

• Der Ausdruck Slider wird häufig für einen sehr großen Bereich am oberen Ende des Hauptinhalts verwendet, er Navigationsfunktionen zum Webauftritt beinhaltet. Einzelne Inhalte des Auftritts werden dadurch hervorgehoben. Nennen wir diese Variante einmal Navigationsabläufe.
• Handelt es sich um das Abspielen von einer Reihe von Bildern wird üblicherweise von einer Diashow gesprochen.
• Beginnt das Abspielen am Ende der Reihe von neuem, nennt man das ein Karussell.
• Endet das Abspielen am Ende der Reihe, schlage ich einmal als Bezeichnung Stafette vor. Falls jemand dafür einen besseren oder gängigen Ausdruck kennt, bitte ich um Hinweise.

Probleme und Chancen für das Web Design

Gemeinsam ist Sliders, dass sie für die Gewährleistung der technischen Barrierefreiheit und die Useability mit Assistierenden Technologien eine große Herausforderung darstellen. Sie gelten im Design aber einmal als schick und modern und leider vielfach als unverzichtbar. Gelegentlich kommt ihnen aber auch überwiegend dekorativer Charakter zu, etwa, wenn Impressionen der Aktivitäten gezeigt werden, die Aktivitäten auf dem Webauftritt aber ausführlich erläutert werden.

Sliders werden eingesetzt, um die Aufmerksamkeit von sehenden Besuchern durch die Bewegung auf bestimmte Seiteninhalte hinzulenken. Sie können jedoch sogar als ein Accessibility Tool dienen, etwa wenn durch eine Diashow Eingaben technisch übernommen werden, um durch die Bildergalerie zu wandern.

Bewegung am Bildschirm

Seitenbereiche in Bewegung fokussieren nicht nur die Aufmerksamkeit, sie lenken auch ab. Für einige Menschen können sie sogar zu Schwindelgefühlen und Übelkeit führen.

Die Symptome für diese Übelkeit sind unter Umständen mit denen von Seekrankheit vergleichbar. Einigen Menschen wird auch beim Lesen im Auto oder Zug schwindlig.

Der Grund für diese subjektiven Probleme ist die Differenz zwischen der visuellen Wahrnehmung und dem Erleben durch unseren Vestibulärsinn. Das Gleichgewichtsorgan sagt, bei der Bildschirmarbeit, dass sich der Körper nicht bewegt, das Auge hingegen liefert den Eindruck von Bewegung, insbesondere wenn sich größere Areale im Blickfeld bewegen.

Wenn sich auf Webseiten animierte Bereiche befinden, ist es daher fein, wenn diese einen möglichst geringen Anteil der Fläche am Bildschirm einnehmen.

Designing Safer Web Animation For Motion Sensitivity

Vorteile von barrierefreien Sliders

• Eine Navigation ist alleine mit der Tastatur oder einer Spracheingabe möglich.
• Screen Reader liefern die benötigten Informationen und Navigationsmechanismen
• Die Möglichkeit zum Anhalten des Karussells erleichtert das genaue Betrachten oder Lesen einzelner Elemente.
• Menschen mit Lernbehinderungen wird mehr Zeit für das Verständnis eines Elements eingeräumt.

Bedienbarkeit mit Maus, Tastatur und Touch Screen

Einführung

Wie bei allen komplexen Webkomponenten stellt auch für einen Slider die Vielfalt von Wahrnehmungsmöglichkeiten und Bedienungskonzepten eine zentrale Herausforderung für die Barrierefreiheit dar. Die Steuerelemente müssen mit der Maus, der Tastatur, mit Spracheingabe und am Touchscreen bedienbar sein, was deren Wahrnehmbarkeit für unterschiedliche Konzepte natürlich voraussetzt. (Multimodalität)

Leider liefern die gängigen Toolkits wie Bootstrap in der Standardversion noch keine barrierefreien Slider. Um sie barrierefrei zu machen benötigen sie substantielle Anpassungen (Stand 2016).

Ein Verständnis für folgende Themenbereiche ist von Bedeutung:

• Tastaturbedienbarkeit
• Screen Reader - Programme zur Steuerung von Sprachausgabe oder Braillezeile
• Technische Aufgaben zur Umsetzung der Barrierefreiheit

Anhalten – Abspielen muss möglich sein

Ein zeitgesteuerter Mechanismus auf einer Webseite muss angehalten werden können (Pause-Schalter). Ein einzelnes Slide muss ohne Zeitdruck wahrnehmbar und bedienbar sein.

Der Pausenmechanismus muss mit der Maus, der Tastatur und am Tochscreen gewährleistet sein. Dies ist insbesondere nötig, wenn sich auf einem Bereich des Slides Text oder Funktionalitäten befinden.

Die Mechanismen zum Anhalten sollten mit Formularelementen, etwa Buttons realisiert werden und nicht als Links. Beim Surfen mit dem Screen Reader werden diese Bedienungsmechanismen als Schalter erwartet und können mit Mechanismen des Screen Readers gezielt angesteuert werden.

Ein Mechanismus, der den Slider anhält, wenn sich die Maus darüber befindet, empfiehlt sich nicht. Die Maus könnte sich gerade zufällig darüber befinden und Funktionalitäten übersehen werden. Für die Tastaturbedienung reicht dieser Mechanismus ohnedies nicht aus.

Gelegentlich werden Slides angehalten, wenn sich der Fokus darauf befindet. Ich würde eher davon abraten, weil diese Funktionalität nicht intuitiv verständlich ist und auch nicht üblich ist. Sie könnte also zu Verwirrung führen. Hinreichend ist ein solcher Mechanismus ohnedies nicht.

WCAG Erfolgskriterium 2.2.2 Pause, Stop, Verbergen (Level A)

Technische Anordnung

Änderungen oberhalb des gerade fokussierten Elements sind bei der Benutzung eines Screen Readers nicht automatisch wahrnehmbar. Solche Änderungen des Kontextes müssen daher vermieden werden oder an den Screen Reader in geeigneter Form weitergegeben werden.

Es empfiehlt sich daher, die Bedienungsmechanismen (Menubar) technisch vor den Bereich mit den Slides zu platzieren. Auf diese Weise ist er beim Lesen mit den Screen Reader – Funktionalitäten verfügbar, bevor die einzelnen Slides erreicht werden.

Icons brauchen Bezeichnungen

Es ist üblich und für die Useability überwiegend auch zweckmäßig, Steuerelemente mit gebräuchlichen Symbolen, anstelle eines visuell sichtbaren Volltextes zu versehen (► anstelle von Play).

Weil diese Symbole aber von Personen oder Assistierenden Technologien möglicherweise nicht verständlich interpretiert werden können, empfiehlt es sich, technische Vorkehrungen zur Verständlichkeit zu treffen.

• Symbolzeichen für Funktionalitäten sollten über ein beschreibendes title-Attribut verfügen.
• Icons für Funktionalitäten müssen über ein adäquates alt-Attribut und title-Attribut verfügen, wenn sie als img-Element eingebaut werden.

Tochscreen Barrierefreiheit

Auch die Darstellung für mobile Devices benötigt sichtbare Steuerungselemente. Es ist nicht als intuitiv vorauszusetzen, dass eine Tastaturberührung das Anhalten bewirkt.

Buttons sollten am Touchscreen erst aktiviert werden, wenn der Finger von ihnen entfernt wird und nicht schon, wenn der Finger sie berührt. Dies erleichtert Menschen mit motorischen Beeinträchtigungen die Bedienung eines Touchscreens.

Schaltflächen sollten auf Touchscreens eine gewisse absolute Mindestgröße aufweisen. Diese sollte einige Millimeter betragen, bestenfalls etwa 7 bis 10 Millimeter.

Deaktiviertes CSS oder JavaScript

Inhalte und Funktionalitäten eines Sliders müssen auch dann adäquat dargestellt sein, wenn etwa Stylesheets oder JavaScript im Browser deaktiviert sind. Die einzelnen Slides erscheinen dann wohl zweckmäßigerweise in Form einer Liste.

Wenn Stylesheets deaktiviert sind, sollte auch keine Animation der Elemente im Slider mehr erfolgen. Eine Bewegung der Slides in diesem Zustand kann für Screen Reader zu Problemen führen, etwa wenn Slides oben verschwinden und die nachfolgenden nach oben rücken. Wenn man mit dem Screen Reader versucht schon gefundene Elemente durch das Lesen nach oben zu finden, sind sie verschwunden.

Möglicherweise müssen in den Scripts Vorkehrungen getroffen werden, wenn CSS deaktiviert ist. Elemente dürfen sich etwa nicht überlappen.

Schalter verlieren natürlich ihre Funktion, wenn JavaScript deaktiviert ist. Sie sollten daher in diesem Fall auch nicht mehr visuell als Icons oder technisch wahrnehmbar sein.

Synchrone Alternativen für Sliders?

Bei meinen Tests von Sliders auf verschiedenen Webseiten und eigenen Testslidern bin ich auf folgendes Problem gestoßen, seien sie mit CSS3 oder jQuerry realisiert:

Slider bieten eine diachrone Abfolge von einzelnen Slides, die Überschriften, Bilder und Links enthalten können. Mein Screen Reader JAWS und vermutlich auch andere listen mit den jeweiligen Screen Reader-Funktionalitäten aber jeweils nur die aktuell eingeblendeten Überschriften, Bilder oder Links auf. Das gleiche passiert, wenn ich mit den Cursortasten nach unten lese oder mit Tabulator von Bedienungselement zu Bedienungselement springe. Mir entgehen also mit dem Screen Reader Seiteninhalte.

Sollten parallel und alternativ Inhalte und Funktionalitäten des Sliders in einem Off – Screen Bereich ohne Zeitmechanismus angeboten werden? Diese Inhalte könnten bei deaktiviertem CSS oder JavaScript ja auch verwendet werden.

Redundant Inhalte und Funktionalitäten für den Screen Reader in einem Off Screen Bereich anzubieten ist problematisch: Allzu oft wird bei der Wartung vergessen, den parallelen Inhalt ebenfalls zu warten. Optimal wäre es, wenn technische Lösungen gefunden würden, die Barrierefreiheit ohne Parallelstrukturen erzielen.

Ich freu mich in diesem Punkt besonders auf Hinweise und Lösungsvorschläge. Ein elegantes barrierefreies Design von Sliders würde ohne Parallelstrukturen auskommen. Aber mir fehlen die Beispiele und meine Anfragen in Mailinglisten blieben bislang erfolglos.

Verbergen von rein dekorativen Slideshows

Eine Slideshow, die rein dekorativ ist, sollte natürlich für den Screen Reader verborgen werden. Dies gilt ebenso wie für dekorative Bilder. Sie verfügen über keine zusätzlichen Informationen und schon gar nicht über Funktionalitäten.

Allerdings sollte überlegt werden, dem Screen Reader zumindest das Vorhandensein des Sliders bekannt zu machen.

• Rein dekorative Grafiken
• Für den Screen Reader verbergen
• Testdatei: Dekorative Diashow für Screen Reader optimieren

Darstellung des Sliders und seiner Elemente

Aufbau eines Karussells

Typischerweise erscheint ein Karussell mit folgenden Komponenten:

• Überschrift
• Container
  • Steuerelemente
  • Inhalte (Slides)

Überschrift für Karussells

Eine Überschrift vor dem eigentlichen Karussell ist nicht in jedem Fall erforderlich. Sie kann jedoch auf den folgenden Inhalt vorbereiten und vielleicht auch auf dessen Mechanismen.

Container für das gesamte Karussell

Für ein Karussell sollte in jedem Fall ein aussagekräftiger Container vorgesehen werden, der den Bereich technisch und redaktionell beschreibt.

<div 
  role="region"
  aria-label="Karussell">

Das HTML-Element <section> verfügt bereits implizit über die Rolle region. Der Code kann übersichtlicher daher folgendermaßen aussehen:

<section
  aria-label="Karussell">

Mit dem Attribut aria-aria-roledescription kann darüber hinaus eine eigene Rolle als Akkordeon festgelegt werden. Die Beschriftung kann entsprechend dem Inhalt präzisiert werden:

<section
  aria-roledescription="Karussell"
  aria-label="Aktuelle Videos">

Verfügt das Karussell bereits über eine vorangehende Überschrift sollte in diesem Fall auf die vorhandene Überschrift zur Beschriftung des Karussells referenziert werden:

<h2 id="heading1" >Aktuelle Videos</h2>
<section
  aria-roledescription="Karussell"
  aria-labelledby="heading1">

Schalter in Sliders

Folgende Schalter erscheinen typischerweise in Sliders:

Um der Wiedererkennbarkeit willen sollten die Icons etwa in dieser Form verwendet werden.

Positionierung der Steuerelemente

Wo sollen sich die einzelnen Steuerelemente am Slider befinden? Vorheriges und Nächstes haben sich am linken und rechten Seitenrand als Gewohnheit eingebürgert. Aber Play / Pause / Stop unten links, zentriert oder rechts platzieren? Oder gar links oben beginnend, wie bei einer Menubar gewöhnt?

Die Indikatoren für den Verlauf eines Slider erscheinen gewohnter Weise unten zentriert und sollten da auch bleiben.

Für die Play / Pause / Stop – Schalter empfehle ich die linke Seite, weil dort mit Vergrößerungsprogrammen zu suchen begonnen wird. Tendenziell hat sich der untere Bereich für diese Bedienungselemente eingebürgert, wohl weil sich dort auch in Videoplayern diese Bedienungselemente befinden.

Technisch sollten sich die Bedienungselemente eines Slider jedenfalls – wie bei allen anderen Komponenten – ganz oben befinden. Inhalt und Funktion einer Komponente ist zu Beginn nicht immer bekannt und da ist es zumindest gut, wenn im Vorhinein bekannt ist, welche Steuerungsmöglichkeiten bestehen.

Größe der Steuerelemente im Slider

Die Steuerelemente erscheinen erfahrungsgemäß sehr dezent, klein und kontrastarm. Deswegen sind Sliders ein häufiges Problem für die visuelle Wahrnehmung manuelle Bedienbarkeit mit Maus oder Touchscreen.

Es empfiehlt sich daher, die Bedienungselemente nicht zu klein zu gestalten. Für die Bedienung des Touchscreen ist es fein, wenn Bedienungselemente eine Mindestgröße von 7 bis 10 Millimeter aufweisen.

Wenn sich auf einem Slide Text befindet, muss sich der beim Scrollen auch vergrößern. Prüfen Sie das am PC mit STRG + NUM+ oder Mausrad und am Touchscreen mit dem Zangengriff.

Kontraste und Farben auf Sliders

Für die visuelle Wahrnehmbarkeit von Seitenelementen ist der Kontrast von zentraler Bedeutung. Auf Sliders finden sich zwei Problembereiche:

1. Helligkeitskontraste innerhalb eines Elementes.
2. Kontraste und Lesbarkeit von einzelnen Elementen auf einem Slide.

Slider werden leider oft mit Hintergrundgrafiken realisiert. Dies erschwert die Lesbarkeit von Texten und Erkennbarkeit von Steuerelemente, besonders wenn sie nicht über eine angemessene Größe verfügen.

Icons für Steuerelemente müssen ebenso wie Textbereiche über einen ausreichenden Kontrast des Zeichens zwischen Vordergrund und Hintergrund verfügen. Ein verringerter Kontrast muss durch die Größe des Elements kompensiert werden.

Die Indikatoren für das vorherige oder nächste Slide erscheinen häufig erst durch einen HOVER-Effekt, also wenn die Maus über den Bereich des Indikators gesetzt wird. Ich denke, dass es für das Verständnis der Bedienungsmöglichkeiten höchst hilfreich ist, wenn diese Steuerelemente standardmäßig sichtbar sind.

Werden Sliders mit Hintergrundgrafiken realisiert, wird gelegentlich der Hintergrund der Steuerelemente ausgegraut (opacity). Dass ein Kontrastminimum eingehalten wird, muss für jede einzelne Hintergrundgrafik und jedes einzelne Slide gewährleistet werden.

Bei den Indikatoren für den Verlauf der Slides („Knopfreihe“) darf die Darstellung des aktiven Slides nicht alleine auf farblichen Informationen beruhen. Die Indikatoren müssen sich entweder im Farbkontrast oder der Darstellung unterscheiden, wenn sie das aktuelle Slide anzeigen oder nicht.

Kontraste im Web Design

Fokussichtbarkeit auf Sliders

Der Fokus muss visuell auch auf den Slides wahrnehmbar sein. Wenn sich auf einem Slide Links oder gar Formularelemente befinden, genügt es nicht, wenn in einem Karussell ein Knopfindikator visuell hervorgehoben wird.

Die Fokusreihenfolge zwischen und innerhalb der einzelnen Slides muss valide und verständlich sein. Ein einfaches Testverfahren ist es, einfach im Browser die Stylesheets und JavaScript zu deaktivieren und die Reihenfolge der Elemente auf ihre Konsistenz hin zu prüfen.

Fokus wahrnehmbar für bedienbare Elemente

Varianten von Übergangseffekten (Transitionen)

Slider können nicht nur über Gleiteffekteverfügen, in denen ein Bereich nach links hinaus gleitet. Wie bei den Übergängen in Powerpointpräsentationen sind unterschiedlichste Effekte denkbar.

Im Hinblick auf die Barrierefreiheit auf höchstem Niveau empfehlen sich Übergänge ohne Bewegungen.

Formen von Abläufen

Karussell oder Stafette?

Sliders erscheinen in folgenden Formen:

1. Beginnt das Abspielen am Ende der Reihe von neuem, nennt man das ein Karussell.
2. Endet das Abspielen am Ende der Reihe, schlage ich einmal als Bezeichnung Stafette vor. Falls jemand dafür einen besseren oder gängigen Ausdruck kennt, bitte ich um Hinweise.

Welche dieser beiden Varianten gewählt werden soll, ist im Einzelfall zu überlegen. Folgende Umstände können in Betracht gezogen werden:

Wenn der Slider über keine Verlaufsindikatoren verfügt, sollte eine Diashow nach dem letzten Slide möglicherweise enden (Stafette statt Karussell ). Es könnte ansonsten der Eindruck entstehen, dass noch nicht das gesamte verfügbare Bildmaterial gesichtet wurde, bis ein einzelnes Bild als bereits gesehen wieder erkannt wird.

Abspielen auf Anfrage?

Es kann überlegt werden, ob der Slider standardmäßig nicht im Pausezustand sein sollte, also die Transitionen erst aktiv ausgelöst werden müssen. Dies dürfte vor allem für Stafettenslider empfehlenswert sein, die einen Ablauf „Schritt für Schritt“ darstellen.

Tab Panels: Alternative und Vorbild

Wenn der Slider als Navigationsmechanismus dient, sollte als Alternative ein Tab Panel in Erwägung gezogen werden. Die Funktionalitäten sind sehr ähnlich, nur dass keine automatische Bewegung zwischen den Inhaltsbereichen erfolgt.

Tab Panels sind optisch wie Reiter in einem Karteikasten gestaltet. Eine horizontale Liste von Tab Headers erlaubt durch Anklicken das Einblenden unterschiedlicher Inhalte.

Bei der technischen Umsetzung von Slidern lässt sich jedenfalls einiges von den Tab Panels abschauen. Die Navigation zwischen den Punkten in einer Reihe kann überwiegend auf gleiche Weise gestaltet werden. Folgendes gut dokumentiertes Beispiel für einen Tab Panel scheint mir jedenfalls interessant, ohne dass ich es im Detail geprüft hätte:

ARIA Tab Panel Example

Ich bin mir bewusst, dass ich meine umfangreichen Webartikel mit Tab Panels realisieren sollte. – Das wird schon noch kommen!

Empfehlungen zusammengefasst

1. Nach Möglichkeit sollte auf Sliders gänzlich verzichtet werden. Sie können irritieren, erschweren die Wahrnehmung und Bedienung und sind technisch nur sehr schwer barrierefrei zu realisieren.
2. Der Zeitmechanismus muss unterbrochen werden können (Pause / Play). Das muss auch alleine mit der Tastatur funktionieren.
3. Falls mit dem Slider Funktionalitäten, wie Navigationsmechanismen, verbunden sind, müssen die Funktionalitäten ohne Mausbedienung verfügbar sein.
4. Sofern Bilder im Karussell nicht rein dekorativen Charakter aufweisen, müssen sie jeweils adäquat mit einer Textalternative versehen werden.
5. Steuerelemente müssen als Formularelemente und nicht als Links realisiert werden.
6. Es empfiehlt sich, den Pausemechanismus nicht durch Hover- oder Fokuseffekte auszulösen.
7. Steuerelemente des Sliders sollten sich technisch oberhalb der einzelnen Slides befinden.
8. Icons für Steuerelemente benötigen technisch eine textuelle Beschreibung, etwa ein TITLE-Attribut und einen Alternativtext.
9. Überschriften, Links und andere Elemente innerhalb eines Slider müssen auch ohne Zeitmechanismus, also synchron verfügbar sein (für Screen Reader Mechanismen und bei deaktiviertem CSS oder JavaScript).
10. Wenn Scripts deaktiviert sind, sollten Icons für Steuerelemente auch nicht mehr sichtbar sein.
11. Rein dekorative Slideshows können für den Screen Reader verborgen werden.
12. Slider mit weniger als ca. 7 einzelnen Slides sollten in Diashows und in erklärenden Abläufen (Schritt für Schritt) generell über Verlaufsindikatoren verfügen.
13. Verlaufsindikatoren sollten als Steuerelemente verfügbar sein.
14. Steuerungselemente werden visuell am unteren Rand eines Slider erwartet.
15. Die Steuerelemente sollten eine ausreichende Mindestgröße aufweisen, am Touchscreen auch über eine absolute Mindestgröße (ca. 7 - 10mm).
16. Text in Sliders muss skalierbar sein, d.h. er muss mit Browsermechanismen und am Touchscreen vergrößert werden können.
17. Texte und Icons auf Sliders müssen über einen ausreichenden Kontrast verfügen.
18. Wenn ein Slider über eine Hintergrundgrafik verfügt, ist es fein, wenn hinter Text oder Icons die Grafik völlig ausgegraut ist.
19. Die Steuerelemente sollten standardmäßig visuell wahrnehmbar sein.
20. Bei den Indikatoren für den Verlauf darf sich die Information über den Zustand nicht alleine aus der Farbe erschließen, sondern muss etwa durch Form oder Kontrast variieren.
21. Der Fokus muss auch auf Sliders gewährleistet werden. Ich empfehle, sich dabei nicht auf den Browser zu verlassen.
22. Die Fokusreihenfolge muss technisch verständlich sein, was bedeutet, dass sich die Steuerelemente oberhalb der Slides befinden.
23. Die Fokusreihenfolge muss visuell verständlich sein, wobei Steuerelemente, die technisch oberhalb der Slides, visuell aber unterhalb der Slides angeordnet sind, eine Ausnahme bilden.
24. Es empfiehlt sich, die Fläche für animierte Bereiche gering zu halten, damit Schwindelgefühle möglichst vermieden werden.
25. Es empfiehlt sich, bei den Übergängen zwischen den einzelnen Slides nicht durch allzu aufwendige Animationen zu verwirren.
26. Es sollte überlegt werden, ob am Ende des Durchlaufs ein automatischer Neustart beginnt (Karussell) oder der Ablauf beendet wird (Stafette).
27. Es sollte überlegt werden, ob der Slider erst durch Drücken der Play-Taste ausgelöst wird.