Elementübergreifende Anforderungen

Siehe auch: Status bzgl. der Bedienbarkeit, Fokusindikator

Viele Bedienelemente können einen Status besitzen, z. B.

• markiert oder nicht markiert,
• gewählt oder nicht gewählt,
• geöffnet oder geschlossen,
• gedrückt oder nicht gedrückt,
• korrekt oder fehlerhaft (siehe auch Fehlervermeidung und -korrektur),
• fokussiert oder nicht fokussiert (siehe auch Fokusindikator),
• bedienbar oder deaktiviert (siehe auch Status bzgl. der Bedienbarkeit).

Hinweis: Welcher Status bei welchem Bedienelement möglich ist, gibt die verwendete Programmiersprache vor.

Hinweis: Konkrete Empfehlungen zu spezifischen Statusänderungen bei einzelnen Elementen werden beim jeweiligen Element beschrieben.

Synonyme: deaktiviert, inaktiv, nur lesend, nur Anzeige, Anzeigemodus, schreibgeschützt, disabled, read-only, display-only

Siehe auch: Elementstatus

Bedienelemente können bedienbar (Standard) oder deaktiviert sein. Formularfelder können darüber hinaus schreibgeschützt sein oder sich im Anzeigemodus befinden.

Hinweis: Welcher Status bei welchem Bedienelement möglich ist, gibt die verwendete Programmiersprache vor.

Synonyme: Erwartungskonformität, consistency

Konsistente Gestaltung und Bedienung hilft den Benutzenden, die Anwendung zu verstehen und effizient zu bedienen. Konsistenz soll angestrebt werden:

• innerhalb der Anwendung und
• mit anderen Anwendungen.

Synonyme für Tastaturkürzel: Tastenkombination, Tastaturkombination, Tastaturbefehl, Tastaturäquivalente, Tastensequenz, Accesskey, Hotkey, Shortcut

Synonyme für Schnelltasten: Merkhilfe, Beschleunigungstaste, Abkürztasten, Mnemonic, Menu accelerator

Tastaturkürzel sind Tasten oder Tastenkombinationen, mit denen aus der Anwendung heraus effizient Funktionen aufgerufen oder Elemente fokussiert werden können. Die Tastaturkürzel können unabhängig von der aktuellen Fokusposition aufgerufen werden. Tastaturkürzel bestehen häufig aus einer Kombination eines druckbaren Zeichens (Buchstabe, Zahl, Sonderzeichen) mit einer oder mehrerer Modifikationstaste(n) (z. B. STRG oder ALT). Tastaturkürzel müssen eindeutig sein.

Schnelltasten sind Tasten, die nur innerhalb eines Elements zur effizienten Navigation genutzt werden können. Sie kommen meist in Menüs zum Einsatz. Als Schnelltaste wird in der Regel der erste Buchstabe des entsprechenden Elements (z. B. Menüeintrages) verwendet. Schnelltasten müssen nicht eindeutig sein: Besitzen z. B. innerhalb eines Menüs verschiedene Einträge die gleiche Schnelltaste, so können die Einträge durch Drücken der Taste nacheinander fokussiert werden. Schnelltasten werden ohne Modifikationstasten verwendet.

Die Tastaturkürzel der Plattform (z. B. des Betriebssystems Windows) sollten in der Anwendung nicht überschrieben oder deaktiviert werden. d. h. die Tastaturkürzel der Plattform sollten auch in der jeweiligen Anwendung funktionieren (z. B. STRG+X und STRG+V zum Ausschneiden und Einfügen von Text).

Die Assistenztechnologien verwenden viele Tastaturkürzel. Diese Tastaturkürzel sollten nicht in der Anwendung genutzt werden, weil andernfalls die Assistenztechnologie oder die Anwendung nicht mit diesen Tastaturkürzeln bedient werden kann.

So verwenden die Screenreader die EINF-Taste als Modifikationstaste für viele ihrer Tastaturkürzel. Die EINF-Taste sollte somit nicht als Modifikationstaste für die Tastaturkürzel der Anwendung genutzt werden.

Weil Assistenztechnologien darüber hinaus weitere Modifikationstasten und Tastaturkürzel ohne Modifikationstasten verwenden, sollte es möglich sein, die anwendungsspezifischen Tastaturkürzel neu zu definieren oder zu deaktivieren.

Unabhängig von den verwendeten Assistenztechnologien sind Tastaturkürzel wichtig für Menschen, die auf die Tastaturbedienung angewiesen sind. Deswegen sollte die Anwendung es ermöglichen, für alle Funktionen eigene Tastaturkürzel zu definieren, selbst wenn standardmäßig für diese keine Tastaturkürzel vorgesehen sind. Sofern eine solche Möglichkeit besteht, sollte in der Hilfe darauf hingewiesen werden.

Die Tastaturkürzel sollten in der Anwendung explizit dokumentiert werden, d. h. in Textform beim jeweiligen Element (dauerhaft sichtbar oder in einem Tooltip), z. B. „Drucken (STRG+D)“.

Die Schnelltasten sollten in der Anwendung implizit dokumentiert werden, z. B. durch Unterstreichen des jeweiligen Buchstabens, z. B. „Drucken“.

Die Schnelltasten innerhalb von Auswahllisten und Ausklapplisten werden in der Regel nicht dokumentiert – dort fungiert der Anfangsbuchstabe des jeweiligen Listeneintrages als Schnelltaste.

In der Hilfe sollten die Tastaturkürzel wie folgt dokumentiert werden:

• Dokumentation der jeweiligen Tastaturkürzel innerhalb der themenspezifischen Kapitel (Beschreibung einer Maske, Funktion, Elements etc.) sowie
• Dokumentation aller Tastaturkürzel auf einer separaten Seite mit Hinweisen zur Tastaturbedienung.

Synonyme: Mausbedienung, Touchbedienung, Stiftbedienung, Pointing device operation, Pointer operation,

Siehe auch: Tastaturbedienung

Die Zeigeinstrumentbedienung umfasst alle Bedienmodalitäten mit einem Zeigeinstrument, z. B.

• Maus,
• Grafiktablett,
• Touchpad,
• Touchdisplay,
• Trackpoint,
• Trackball,
• Joystick,
• Stift.

Aus Sicht der Barrierefreiheit existiert keine zwingende Anforderung, dass eine Anwendung mit einem Zeigeinstrument bedienbar sein muss. Erforderlich ist lediglich die Bedienung mit der Tastatur. Sofern jedoch eine Anwendung mit Zeigeinstrument bedient werden kann, sind bestimmte Anforderungen einzuhalten.

Synonyme: keyboard operation, keyboard interface

Siehe auch: Zeigeinstrumentbedienung, Fokusindikator, Navigationsreihenfolge

Alle Funktionen, die z. B. mit einem Zeigeinstrument, per Bewegungssteuerung oder per Spracheingabe aufrufbar sind, müssen auch mit der Tastatur aufrufbar sein, weil beeinträchtigte Benutzende ggf. kein Zeigeinstrument nutzen bzw. den Zeiger nicht sehen, die Bewegung nicht ausführen oder nicht sprechen können. Beeinträchtigte Benutzende können ggf. auch keine Tastatur nutzen, aber deren Assistenztechnologie simuliert die Tastatur und interagiert mit der Tastaturschnittstelle des Betriebssystems bzw. der Accessibility API.

Die Simulation eines Zeigeinstruments über die Tastatur (z. B. Tastaturmaus über den Ziffernblock) gilt in diesem Zusammenhang nicht als zulässige Bedienalternative zur Zeigeinstrumentbedienung.

Hinweis: Die Bedienung einzelner Elemente wird beim jeweiligen Element beschrieben.

Hinweis: Die Tastaturbedienung muss in der Regel nicht separat implementiert werden, weil die Plattformsoftware oder das verwendete Framework diese bereits zur Verfügung stellt. Es soll jedoch darauf geachtet werden, die Tastaturkürzel nicht für eigene Funktionen zu überschreiben.

Die Standardelemente der Auszeichnungs- bzw. Programmiersprache oder des verwendeten Frameworks sind in der Regel vollständig tastaturbedienbar. Diese sollen somit bevorzugt verwendet werden.

Werden benutzerdefinierte Elemente verwendet, so soll bezüglich der Tastaturbedienbarkeit insbesondere auf Folgendes geachtet werden:

• Erreichbarkeit mit der Tastatur (z. B. mittels tabindex),
• Bedienbarkeit mit der Tastatur (Eventhandler für die Tastatur bzw. geräteunabhängige Eventhandler),
• Bedienbarkeit ist erwartungskonform oder dokumentiert (erwartungskonform hinsichtlich der visuellen Darstellung und der Rolle, die an die Accessibility API übermittelt wird).
• Fokusindikator,
• Fokushandling (z. B. kein Fokusverlust bei Bedienung; Navigationsreihenfolge),
• ggf. definierte Tastaturkürzel sind konsistent mit denen der Plattformsoftware bzw. überschreiben die der Plattformsoftware nicht.

Wird ein benutzerdefiniertes Element implementiert, empfiehlt es sich häufig, ein verwandtes Standardelement zu verwenden und entsprechend anzupassen, weil dann die Grundfunktionalität des Standardelements genutzt werden kann.

Das Ziehen und Ablegen von Elementen (Drag & Drop) kann nur mit einem Zeigegerät ausgeführt werden. Es wird empfohlen, die Bedienalternative mit der Tastatur so zu gestalten, dass sie effizient und erwartungskonform genutzt werden kann. Mögliche Varianten sind u. a.

• Kontextmenü (z. B. zum Verschieben von Elementen in andere Bereiche),
• mehrere Schalter, gruppiert in einer Werkzeugleiste (z. B. zur Änderung der Reihenfolge von Elementen innerhalb eines Bereichs),
• ein Schalter (z. B. zum Datei-Upload),
• eigene Tastaturkürzel (z. B. Anpassung der Größe von Elementen),
• Tastaturkürzel der Plattform (z. B. Ausschneiden und Einfügen von Elementen mit STRG+X und STRG+V),
• Pfeiltastenbedienung (z. B. bei einem Schieberegler),
• Start und Ende mit der EINGABE-Taste, Bewegung mit den Pfeiltasten (z. B. Zeichnen einer Freihandmaske).

Häufig ist eine Kombination der Varianten sinnvoll (z. B. Schalter und Tastaturkürzel).

Da die Bedienalternative mit der Tastatur in der Regel nicht ersichtlich ist, sollte sie in der Anwendung und Hilfe beschrieben werden.

Bedienelemente, die bei der Bedienung der Anwendung ein- und ausgeblendet werden, z. B.

• weil sie sich in Tooltips befinden oder
• weil sie nur angezeigt werden, wenn sich der Tastaturfokus an einer bestimmten Position befindet,

sind mit der Tastatur in der Regel nicht zu bedienen.

Es wird empfohlen, Bedienelemente dauerhaft anzuzeigen und z. B. Bedienelemente in Tooltips zu vermeiden.

Alternativ muss eine Bedienalternative mit der Tastatur implementiert und in der Hilfe und Anwendung beschrieben werden. Darüber hinaus muss die Anwendung so gestaltet werden, dass mit Assistenztechnologie wahrnehmbar ist, wann nicht dauerhaft sichtbare Elemente eingeblendet werden. So müssen z. B. blinde Nutzende mit dem Screenreader erkennen können, dass ein Tooltip Bedienelemente enthält, damit sie die dokumentierte Bedienalternative mit der Tastatur nutzen können.

Synonyme: Benutzereinstellungen, Individualisierung, individuelle Anpassung, Anpassung an Präferenzen, User preferences

Siehe auch: Farben und Kontraste, Schrift, Fokusindikator

Unter Windows können Benutzende die Darstellung der Farben an ihre Bedürfnisse anpassen (Einstellungen > Erleichterte Bedienung > Hoher Kontrast). Im Gegensatz zu anderen Betriebssystemen, die lediglich bestimmte Farbänderungen erlauben (wie Einfärben, Abdunkeln oder Invertieren der Farben), kann unter Windows die Vorder- und Hintergrundfarbe frei gewählt werden. Darüber hinaus können für verschiedene Elementtypen bzw. deren Status eigene Farben definiert werden.

Mit der Windows-Kontrastanpassung können die Farben für folgende Elemente und Zustände angepasst werden:

• Text (SystemColorWindowTextColor)
• Hintergrund (SystemColorWindowColor)
• Links (SystemColorHotlightColor)
• Markierter Text, gewähltes Element (SystemColorHighlightTextColor)
• Hintergrund von markiertem Text oder gewählten Elementen (SystemColorHighlightColor)
• Text von Bedienelementen (außer Links) (SystemColorButtonTextColor)
• Hintergrund von Bedienelementen (außer Links) (SystemColorButtonFaceColor)
• Deaktivierte Elemente (SystemColorGrayTextColor)

Damit die Windows-Kontrastanpassung in einer Anwendung korrekt funktioniert, muss Folgendes beachtet werden:

• Die Definition von Vorder- und Hintergrundfarben muss so erfolgen, dass sie durch die Windows-Kontrastanpassung überschrieben werden kann. Davon ausgenommen sind Grafiken und Videos.
• Inhalte, deren Vordergrundfarbe angepasst wird, darf keinen Hintergrund besitzen, dessen Farbe nicht angepasst wird. Dies gilt z. B. für Text, dessen Hintergrund eine Grafik ist, die nicht angepasst wird. Dies gilt nicht, wenn die Schrift eine Kontur in der Hintergrundfarbe besitzt, weil dann über die Kontur die Sichtbarkeit gewährleistet wird.
• Grafiken mit transparentem Hintergrund müssen vermieden werden. Dies gilt nicht, wenn entweder die Vordergrundfarbe der Grafik angepasst werden kann (z. B. durch Verwendung von SystemColorWindowTextColor) oder die grafischen Inhalte eine Kontur besitzen.
• Für die Elementtypen Text, Links und Formularelemente sowie die Zustände deaktiviert, markiert und gewählt müssen die entsprechenden Informationen an die Accessibility API bezüglich Rolle und Status übermittelt werden. Alternativ müssen die entsprechenden Farben für die Elemente und Zustände verwendet werden (z. B. SystemColorGrayTextColor für deaktivierte Elemente).
• Schriftgrafiken müssen vermieden werden. Alternativ muss sich die Vorder- und Hintergrundfarbe der Schriftgrafiken gemäß den Windows-Einstellungen anpassen lassen.
• Ausschließlich farbkodierte Inhalte müssen vermieden werden, unabhängig vom Kontrast zwischen den Farben.
• Seitenbereiche, Tooltips, Pop-ups sowie Bedienelemente, die durch unterschiedliche Hintergrundfarben gekennzeichnet sind, sollen einen Rahmen erhalten, damit sie sich auch bei der Windows-Kontrastanpassung vom Hintergrund abheben.
• Unterstützt die Anwendung nicht die Windows-Kontrastanpassung, so muss die Anwendung eine eigene Möglichkeit zur Anpassung der Farben mit analogem Funktionsumfang anbieten. Diese Option muss in der Anwendung und Hilfe beschrieben werden.
• Wenn die Windows-Kontrastanpassung durch die Anwendung nur bei einer bestimmten Konfiguration unterstützt wird (z. B. Auswahl eines bestimmten Farbschemas), so muss dies in der Anwendung und Hilfe beschrieben werden.

Beispiel 1: In den zwei folgenden Abbildungen sind in zwei Zeilen je zwei Textinhalte, zwei Schalter und zwei Links dargestellt – einmal in der Standarddarstellung (linke Abbildung) und einmal bei Verwendung der Windows-Kontrastanpassung (Kontrast Nr. 1).

• In der linken Abbildung sind Text, Schalter und Link in beiden Zeilen aufgrund der verwendeten Farben zu erkennen:

  • Text: schwarze Schrift auf weißem Hintergrund,
  • Schalter: schwarze Schrift auf grauem Hintergrund,
  • Link: blaue Schrift auf weißem Hintergrund.

• In der rechten Abbildung sind Text, Schalter und Link nur in der oberen Zeile korrekt zu erkennen, weil sie programmatisch als Text, Schalter und Link ausgezeichnet wurden:

  • Text: gelbe Schrift auf schwarzem Hintergrund,
  • Schalter: weiße Schrift auf schwarzem Hintergrund,
  • Link: blaue Schrift auf schwarzem Hintergrund.

• In der rechten Abbildung sind Text, Schalter und Link in der unteren Zeile nicht voneinander zu unterscheiden, da sie alle in der Textfarbe angezeigt werden (gelbe Schrift auf schwarzem Hintergrund). Ursache für die Fehldarstellung ist, dass Schalter und Link nicht programmatisch als solche ausgezeichnet wurden.

Beispiel 2: In den zwei folgenden Abbildungen sind ein bedienbarer Schalter („Absenden“) und zwei deaktivierte Schalter („Prüfen“ und „Löschen“) dargestellt – einmal in der Standarddarstellung (linke Abbildung) und einmal bei Verwendung der Windows-Kontrastanpassung (Kontrast Nr. 1).

• In der Standarddarstellung sind die beiden deaktivierten Schalter aufgrund der ausgegrauten Farben als deaktiviert zu erkennen.
• Bei der Windows-Kontrastanpassung ist lediglich der „Prüfen“-Schalter korrekt als deaktiviert zu erkennen (grüne Schrift auf schwarzem Hintergrund).
• Der „Löschen“-Schalter ist bei der Windows-Kontrastanpassung nicht als deaktiviert zu erkennen, sondern wird als bedienbar angezeigt (weiße Schrift auf schwarzem Hintergrund). Die Ursache für die Fehldarstellung ist, dass er nicht programmatisch als deaktiviert ausgezeichnet wurde.

Beispiel 3: In den zwei folgenden Abbildungen sind vier Schalter dargestellt, die mit einem schwarzen Icon beschriftet sind – einmal in der Standarddarstellung (linke Abbildung) und einmal bei Verwendung der Windows-Kontrastanpassung (Kontrast Nr. 1).

• In der Standarddarstellung sehen alle vier Schalter gleich aus (schwarzes Icon auf weißem Hintergrund).
• Bei der Windows-Kontrastanpassung sehen die vier Schalter aufgrund der unterschiedlichen Technologie zur Darstellung des Icons unterschiedlich aus:
  • Das erste Icon wird korrekt angezeigt, weil ein Font-Icon verwendet wurde, bei dem Vorder- und Hintergrundfarbe angepasst werden (weißes Icon auf schwarzem Hintergrund). Diese Variante ist zu bevorzugen.
  • Das zweite Icon wird nicht angepasst (schwarzes Icon auf weißem Hintergrund), weil es sich um eine Grafik ohne transparenten Hintergrund handelt. Diese Variante ist akzeptabel.
  • Das dritte Icon ist nicht so gut zu erkennen, weil es sich um eine Grafik mit transparentem Hintergrund handelt (schwarzes Icon auf schwarzem Hintergrund). Das Icon ist jedoch aufgrund seiner weißen Kontur wahrnehmbar. Diese Variante ist akzeptabel.
  • Das vierte Icon ist nicht zu erkennen, weil es sich um eine Grafik mit transparentem Hintergrund handelt (schwarzes Icon auf schwarzem Hintergrund). Diese Variante sollte nicht verwendet werden.

Synonyme: Farbkodierung, colour, contrast

Siehe auch: Text, Schrift, Grafiken, Kontrastanpassung

Farben sind ein wichtiges visuelles Gestaltungsmittel. Sehbeeinträchtigte Menschen können jedoch Farben oder Farbunterschiede (Kontraste) möglicherweise nicht wahrnehmen.

Um EN 301 549: 9.1.4.1 bzw. 11.1.4.1 zu erfüllen, muss zwischen zwei verschiedenen Formen von Farbkodierung unterschieden werden:

• der Farbunterschied vermittelt eine Information,
• die Farbe selbst vermittelt eine Information.

Beispiele:

• Der aktive Menüpunkt besitzt eine graue Hintergrundfarbe, alle anderen Menüpunkte besitzen eine weiße Hintergrundfarbe.
• Die Textfarbe ist Schwarz und die Linkfarbe Blau.

Sofern die Farben an sich keine Bedeutung besitzen, sondern nur der Unterschied zwischen den Farben, ist ein Kontrastverhältnis von mindestens 3:1 zwischen den Farben ausreichend.

Allerdings ist es empfehlenswert, ein weiteres visuelles Mittel (z. B. Icon, Schriftschnitt, Größe, Lage, Form, Rahmen, Unterstreichung, Text) zu verwenden, um die per Farbunterschied vermittelte Information abzubilden, z. B.

• Der aktive Menüpunkt besitzt einen fetten Schriftschnitt, alle anderen Menüpunkte einen normalen Schriftschnitt.
• Der Text besitzt keine Unterstreichungen, alle Links sind unterstrichen.

Hinweis: EN 301 549: 9.1.4.1 und 11.1.4.1 formuliert Anforderungen für sehbeeinträchtigte Menschen, welche die Anwendung ohne Assistenztechnologie verwenden. Zusätzliche Anforderungen gelten gemäß EN 301 549: 9.1.3.1 und 11.1.3.1.1 für Nutzende von Assistenztechnologie hinsichtlich von Farbkodierungen, z. B.

• Damit blinde Menschen die per Farbunterschied vermittelten Informationen wahrnehmen können, müssen diese Informationen programmatisch oder in Textform an die Accessibility API übermittelt werden.
• Damit Nutzende der Windows-Kontrastanpassung die per Farbunterschied vermittelten Informationen wahrnehmen können, müssen diese Informationen programmatisch (siehe Praxistipp Kontrastanpassung), über ein weiteres visuelles Mittel (siehe oben) oder in Textform vermittelt werden.

Beispiele:

• Fehlerhaft ausgefüllte Formularfelder besitzen einen roten Rahmen, korrekt ausgefüllte Formularfelder besitzen einen grünen Rahmen.
• Für Meldungen werden unterschiedliche Hintergrundfarben verwendet: Rot für Warnmeldungen, Grün für Erfolgsmeldungen und Gelb für Hinweise.
• In einer Finanzübersicht werden Verluste mit roter Textfarbe und Gewinne mit schwarzer Textfarbe dargestellt.

In diesen Fällen vermittelt die Farbe an sich eine Information und nicht nur der Unterschied zwischen den Farben. Deswegen ist hier ein Kontrastverhältnis von mindestens 3:1 zwischen den Farben nicht ausreichend. In jedem Fall muss ein weiteres visuelles Mittel verwendet werden, um die Information zu vermitteln, z. B.

• Die fehlerhaft ausgefüllten Formularfelder besitzen ein Fehler-Icon (z. B. ein Ausrufezeichen in einem roten Kreis) und die korrekt ausgefüllten Formularfelder besitzen ein Erfolgs-Icons (z. B. ein Häkchen in einem grünen Kreis). Darüber hinaus wird eine aussagekräftige Fehlermeldung in Textform angezeigt, um EN 301 549, 9.3.3.1 bzw. 11.3.3.1 zu erfüllen.
• Die Meldungen besitzen jeweils eine Überschrift, die den Status vermittelt (z. B. „Warnung“, „Erfolg“ und „Hinweis“).
• In der Finanzübersicht werden die Verluste mit einem Minuszeichen vor der Zahl gekennzeichnet.

Hinweis: EN 301 549: 11.1.4.1 formuliert Anforderungen für sehbeeinträchtigte Menschen, welche die Anwendung ohne Assistenztechnologie verwenden. Zusätzliche Anforderungen gelten gemäß EN 301 549: 11.1.3.1.1 für Nutzende von Assistenztechnologie hinsichtlich von Farbkodierungen (siehe oben).

Die WCAG geht bei den Kontrastanforderungen davon aus, dass die Kantenglättung deaktiviert wurde. Dies ist jedoch nicht realistisch, da die meisten Benutzenden mit aktiver Kantenglättung arbeiten. Durch die Kantenglättung können bei dünnen Strichstärken die tatsächlichen Kontraste deutlich unter den aus den Farbwerten errechneten Kontrasten liegen. Deswegen sollen entweder die Strichstärke oder die Farben so angepasst werden, dass das Kontrastverhältnis (von mindestens 4,5:1 für Text und 3:1 für grafische Inhalte) auch bei aktivierter Kantenglättung eingehalten werden kann. Da die Kantenglättung unterschiedlich konfiguriert sein kann, ist es nicht möglich, exakte Werte anzugeben. Folgende Richtwerte werden jedoch in den meisten Fällen dazu beitragen, dass die Kontrastverhältnisse eingehalten werden können:

• Mindeststrichstärke von 2 px oder
• doppeltes Kontrastverhältnis bei geringeren Strichstärken (z. B. mindestens 9:1 statt 4,5:1).

Dabei soll beachtet werden, dass eine Strichstärke von 2 px bei Buchstaben erst ab einer bestimmten Schriftgröße erreicht wird, bei Arial z. B. ab 25 px und bei Times New Roman ab 75 px.

Beispiel: In den folgenden beiden Abbildungen sind drei Mal jeweils der Buchstabe „x“ und ein Schrägstrich („/“) dargestellt, jeweils in der Schriftart „Times New Roman“ und mit der Schriftgröße 16px. Der Kontrast der im CSS definierten grauen bzw. schwarzen Textfarbe zum weißen Hintergrund beträgt rein rechnerisch:

• Links: 4,5:1,
• Mitte: 7:1,
• Rechts: 21:1.

Damit werden für den gesamten Text die erforderlichen Mindestkontraste eingehalten. In der stark vergrößerten Darstellung ist jedoch zu erkennen, dass die errechneten Kontraste beim „x“ aufgrund der Kantenglättung nur teilweise beim dickeren Abstrich (diagonaler Strich von links oben nach rechts unten) und den horizontalen Serifen erreicht werden. Für den dünneren Aufstrich (diagonaler Strich von links unten nach rechts oben) liegt der Kontrast deutlich darunter, z. B. im unteren Bereich maximal bei:

• Links: 2,9:1,
• Mitte: 2,9:1,
• Rechts: 5,2:1.

Für den Schrägstrich werden die errechneten Kontraste an keiner Stelle erreicht.

• Links: maximal 2,4:1, Mittelwert ca. 2,0:1,
• Mitte: maximal 2,5:1, Mittelwert ca. 2,1:1,
• Rechts: maximal 3,5:1, Mittelwert ca. 2,3:1.

Synonyme: Buchstaben, Zeichen, Zahlen, font

Siehe auch: Text, Kontrast, Beschriftung, Überschrift

Schrift dient der Darstellung von Textinformationen.

Bei der Verwendung von Sonderzeichen sind hinsichtlich der Übermittlung der Zeichen an die Accessibility API verschiedene Anwendungsfälle zu unterscheiden:

Rein dekorative Sonderzeichen sind so auszeichnen, dass sie nicht an die Accessibility API übermittelt werden. Für sie gelten die gleichen Regeln wie für Layoutgrafiken.

Beispiele:

• Schalter mit der Beschriftung „Weiter »“: Die beiden Größerzeichen sind rein dekorativ. Der Schalter sollte den Accessible Name „Weiter“ besitzen.
• Formularfeldbeschriftung „- - Ort - -“: Die Bindestriche sind rein dekorativ. Das Formularfeld sollte den Accessible Name „Ort“ besitzen.

Sonderzeichen, die nicht ihrer Bedeutung entsprechend verwendet werden, sind mit einem aussagekräftigen Alternativtext zu versehen. Für sie gelten die gleichen Regeln wie für Grafiken.

Beispiele:

• Schalter mit der Beschriftung »: Die beiden Größerzeichen vermitteln visuell die Information „Weiter“. Der Schalter sollte den Accessible Name „Weiter“ besitzen.
• Schalter mit der Beschriftung x: Das Multiplikationszeichen vermittelt visuell die Information „Schließen“. Der Schalter sollte den Accessible Name „Schließen“ besitzen (ggf. mit einem Hinweis, was geschlossen wird, z. B. „Fenster schließen“).

Hinweis: Der Stern („*“) gilt bei Verwendung als Pflichtfeldkennzeichnung nicht als zweckentfremdet.

Sonderzeichen, die entsprechend ihrer Bedeutung verwendet werden, können verwendet werden, sofern das Zeichen durch Assistenztechnologie korrekt ausgegeben wird. Andernfalls soll es mit einem aussagekräftigen Alternativtext versehen werden.

Beispiele:

• Mathematische Formel „3+5 > 5-3“: Die beiden Rechenzeichen sowie das Größerzeichen werden von der Assistenztechnologie korrekt ausgegeben und können somit verwendet werden.
• Text mit den Ordinalzeichen „ª“ und „º“: Die beiden Zeichen werden von der Assistenztechnologie nicht bzw. nicht korrekt ausgegeben und benötigen somit einen Alternativtext.
• Das Wort „Gast“ mit einer Ligatur von s und t. Die meisten Screenreader kennen die Ligatur nicht und geben statt „Gast“ nur „Ga“ und ein Leerzeichen aus.

Die zweckbezogenen Sonderzeichen sollten sparsam verwendet werden. Es wird empfohlen, ein Zeichen zu verwenden, welches von der Assistenztechnologie knapp ausgegeben wird.

Beispiele:

• Ein Zitat kann mit verschiedenen Anführungszeichen versehen werden. Das Zeichen “ wird von der Assistenztechnologie z. B. als „Typographisches Anführungszeichen oben“ oder als „Typographisches Anführungszeichen rechts“ ausgegeben. Das Zeichen " wird hingegen als „Anführungsstriche“ oder „Anführungszeichen“ ausgegeben und ist somit zu bevorzugen.
• Der Satz „Das Zeichen »❖« gefällt mir besser als „➢““ (siehe folgende Abbildung) wird vom Screenreader z. B. als „Das Zeichen doppelt gewinkelte Klammer zu schwarze Raute mit weißem X doppelt gewinkelte Klammer auf gefällt mir besser als typografisches Anführungszeichen unten 3D schmaler rechtsweisender Pfeilkopf Anführungsstriche“ ausgegeben.

Damit Texte gut lesbar sind, soll eine gut lesbare Schriftart und Textformatierung gewählt werden. Dabei soll Folgendes beachtet werden:

• Am besten sind Schriften aus der Familie der humanistischen Serifenlosen zu lesen.
• Ligaturen sollen vermieden werden.
• Die Mindestschriftgröße für Textblöcke soll 22px betragen.
• Die Mindestschriftgröße für nebensächlichen Text (z. B. Fußnoten) soll 17px betragen.
• Schmale und breite Schriftweiten sollen vermieden werden.
• Kleine und große Zeichenabstände sollen vermieden werden.
• Dünne und dicke Schriftschnitte sollen vermieden werden.
• Der Zeilenabstand soll mindestens 120 % der Schriftgröße betragen.
• Die Groß- und Kleinschreibung soll gemäß der Rechtschreibregeln verwendet werden. Die ausschließliche Verwendung von Groß- oder Kleinschreibung soll vermieden werden.
• Die Groß- und Kleinschreibung soll gemäß der Rechtschreibregeln verwendet werden. Die ausschließliche Verwendung von Groß- oder Kleinschreibung soll vermieden werden.
• Kapitälchen sollen vermieden werden.
• Hervorhebungen sollen sparsam verwendet werden. Für Hervorhebungen soll ein fetter Schriftschnitt verwendet werden.
• Kursive Schriftschnitte oder Unterstreichungen sollen vermieden werden. Hinweis: Links sollen unterstrichen werden.
• Die Textausrichtung soll linksbündig sein. Blocksatz soll vermieden werden.

Weitere Informationen finden Sie unter: https://www.leserlich.info (Externer Link) .

Synonyme: Fokus, Fokusrahmen, Focus Indicator, Focus Appearance

Siehe auch: Tastaturbedienung, Textcursor

Der Fokusindikator zeigt an, welches Element derzeit den Tastaturfokus besitzt (siehe DIN EN ISO 9241-161: 8.37).

Der Fokusindikator wird üblicherweise durch einen Rahmen um das fokussierte Element angezeigt. Andere Fokusindikatoren wären ebenfalls zulässig, sofern sie die Anforderungen erfüllen, z. B.

• Invertieren von Vorder- und Hintergrundfarbe,
• Veränderte Hintergrundfarbe,
• Änderung der Größe des Elements,
• Einblenden eines grafischen Elements, wie z. B. eines seitlichen Balkens.

In bestimmten Fällen können mehrere Fokusindikatoren angezeigt werden:

• Beispiel 1: Wenn eine Auswahlliste den Fokus erhält, kann ein Fokusindikator um die gesamte Liste angezeigt werden. Darüber hinaus muss ein Fokusindikator beim aktuellen Listeneintrag angezeigt werden.
• Beispiel 2: Bei einem kombinierten Eingabefeld kann sich der Fokus sowohl im Eingabefeld als auch in der Auswahlliste befinden.
• Beispiel 3: Wenn ein interaktives Element innerhalb eines Seitenbereichs den Fokus erhält, dann kann auch der Seitenbereich als fokussiert gekennzeichnet werden.
• Beispiel 4: Die Titelzeilen aller Anwendungsfenster, die nicht den Fokus besitzen, werden ausgegraut dargestellt.

In einigen Fällen kann der Fokusindikator mit der Selektionsmarke (d. h. der Kennzeichnung der ausgewählten Option, siehe Elementstatus) identisch sein, wenn das fokussierte Element mit dem ausgewählten Element identisch ist:

• Beispiel 1: Eine Auswahlliste ohne Mehrfachauswahl besitzt einen Fokusindikator beim fokussierten Listeneintrag. Dieser Indikator kann gleichzeitig als Selektionsmarke dienen, weil der fokussierte Listeneintrag mit dem gewählten Listeneintrag identisch ist. Wenn diese Auswahlliste nicht zusätzlich einen Fokusindikator für die gesamte Liste besitzt, ist jedoch darauf zu achten, dass die Selektionsmarke im fokussierten Status der Auswahlliste sich deutlich von der Selektionsmarke im nicht-fokussierten Status der Auswahlliste unterscheidet (z. B. Kontrastverhältnis mindestens 3:1), um erkennen zu können, ob die Auswahlliste fokussiert ist.
• Beispiel 2: Eine Auswahlliste ohne Mehrfachauswahl besitzt einen Fokusindikator beim fokussierten Listeneintrag, z. B. einen Rahmen. Dieser Fokusindikator wird nicht gleichzeitig als Selektionsmarke verwendet. Als Selektionsmarke wird z. B. eine abweichende Hintergrundfarbe genutzt. Bei der Navigation durch die Listeneinträge wird sowohl der Fokusindikator als auch die Selektionsmarke verschoben. Ein zusätzlicher Fokusindikator für die gesamte Liste bzw. eine Unterscheidung der Selektionsmarke im fokussierten und nicht fokussierten Zustand ist in diesem Fall nicht notwendig, da Fokussierung und Selektion unabhängig voneinander zu erkennen sind.
• Beispiel 3: Eine Mehrfach-Auswahlliste besitzt einen Fokusindikator um die gesamte Liste. Da jedoch bei der Mehrfach-Auswahlliste der fokussierte Listeneintrag nicht mit den gewählten Listeneinträgen übereinstimmt, muss Fokusindikator und Selektionsmarke bei den Listeneinträgen separat gekennzeichnet werden (z. B. wie in Beispiel 2 mit einem Rahmen und einer abweichenden Hintergrundfarbe).

Die Änderung des Fokusindikators zwischen den Elementen wird in den Abschnitten Tastaturbedienung und Navigationsreihenfolge beschrieben. Standardmäßig erfolgt die Navigation mit der TAB-Taste.

Die Änderung des Fokusindikators innerhalb eines Elements wird bei den jeweiligen Elementen beschrieben. Häufig erfolgt die Navigation innerhalb von Elementen mit den Pfeiltasten.

Der Fokusindikator muss ausreichende Kontraste aufweisen und sollte gleichzeitig konsistent gestaltet werden. Bei Anwendungen mit unterschiedlichen Hintergrundfarben ist dies zu erreichen, indem ein zweifarbiger Rahmen (z. B. schwarz und weiß) verwendet wird, der vor jedem Hintergrund ausreichende Kontraste besitzt. Ein zweifarbiger Fokusindikator empfiehlt sich auch bei Bedienelementen auf Farbverläufen oder Grafiken.

Beispiel: Zwei Schalter auf einem Farbverlauf von weiß nach schwarz. Der obere Schalter ist aktuell fokussiert. Der Fokusindikator besteht aus einem schwarzen Rahmen (innen) und einen weißen Rahmen (außen) und ist somit unabhängig von der Hintergrundfarbe immer gut zu erkennen. Es handelt sich dabei um den Standard-Fokusrahmen von Google Chrome.

Synonyme: Cursor

Siehe auch: Tastaturbedienung, Fokusindikator

Der Textcursor zeigt die Position in einem Eingabefeld an (siehe DIN EN ISO 9241-161: 8.8). Der Textcursor wird üblicherweise durch einen senkrechten Strich an der Stelle, an der Text eingegeben, bearbeitet oder gelöscht wird, angezeigt.

Die Änderung des Fokusindikators zwischen den Elementen wird bei den Elementen Eingabefeld und Mehrzeiliges Eingabefeld beschrieben. Standardmäßig erfolgt die Navigation innerhalb von Eingabefeldern mit den Pfeiltasten.

Synonyme: Erforderliche Formularfelder, Pflichteingabe, Required

Siehe auch: Fehlermeldung, Beschriftung, Elementstatus

Eine Pflichtfeldkennzeichnung ist ein visueller Indikator für Formularfelder, die ausgefüllt werden müssen. So kann z. B. mit einem Stern (*) beim Formularfeld darauf hingewiesen werden, dass ein Feld ausgefüllt werden muss.

Pflichtfelder können mit einem entsprechenden textlichen Zusatz, wie z. B. „Pflichtfeld“ oder „erforderlich“ gekennzeichnet werden. Wenn die Mehrzahl der Felder Pflichtfelder sind, können alternativ auch die Felder, die nicht ausgefüllt werden müssen, gekennzeichnet werden, z. B. mit „optional“.

Die Pflichtfelder können auch mit einem Symbol gekennzeichnet werden. Etabliert hat sich dafür der Stern („*“), bei dem zumindest bei Fachanwendungen davon ausgegangen werden kann, dass er allen Nutzenden bekannt ist. Wird ein anderes Zeichen verwendet, so sollte dessen Bedeutung am Formularbeginn erläutert werden.

• JAWS: erforderlich ungültiger Eintrag | erforderlich [nach der Rolle und vor dem Wert]
• NVDA: erforderlich ungültiger Eintrag | erforderlich [nach der Rolle und vor dem Wert]
• Windows Sprachausgabe: erforderlich ungültig | erforderlich [nach dem Wert]

Hinweis: Ein nicht-ausgefülltes Pflichtfeld, welches mit required ausgezeichnet wurde, befindet sich aufgrund der HTML-Spezifikation im Status fehlerhaft und wird deshalb von den Screenreadern als „ungültiger Eintrag“ bzw. „ungültig“ ausgegeben. Das Problem tritt bei Verwendung von aria-required nicht auf.

Pflichtfelder können mit dem required-Attribut ausgezeichnet werden.

• Formularfelder, die mit required ausgezeichnet wurden, werden automatisch durch den Browser validiert und befinden sich im fehlerhaften Zustand, wenn sie nicht ausgefüllt wurden.
• Formularfelder, die mit required ausgezeichnet wurden, sind visuell nicht automatisch als Pflichtfelder erkennbar. Sie besitzen allerdings einen Tooltip (z. B. „Bitte füllen Sie dieses Feld aus“), der jedoch für Tastaturnutzende und mit dem Screenreader nicht wahrnehmbar ist, da er nur beim Mouseover eingeblendet wird.
• Ein Formular mit nicht ausgefüllten Pflichtfeldern kann standardmäßig nicht abgesendet werden. Stattdessen wird der Fokus in das erste fehlerhafte Feld gesetzt und der Tooltip als Fehlermeldung eingeblendet und vom Screenreader als Warnmeldung ausgegeben (analog zu role=alert). Diese Fehlermeldungen sind aus folgenden Gründen nicht barrierefrei:
  • Beim Verlassen des Feldes wird die Fehlermeldung automatisch ausgeblendet und kann nicht erneut eingeblendet werden.
  • Bei vielen Browsern werden die Fehlermeldungen nach wenigen Sekunden automatisch ausgeblendet, selbst wenn der Fokus im Feld verbleibt (z. B. bei Chrome und Edge).
  • Die Fehlermeldung wird nur beim ersten fehlerhaften Feld angezeigt. Weitere nicht ausgefüllte Pflichtfelder sind nicht als fehlerhaft zu erkennen.

Deshalb sollte bei Verwendung von required Folgendes beachtet werden:

• Die Pflichtfelder müssen auch visuell als solche gekennzeichnet werden.
• Die visuelle Pflichtfeldkennzeichnung sollte so ausgezeichnet werden, dass sie nicht vom Screenreader ausgegeben wird, um die redundante Ausgabe zu vermeiden.
• Die Anwendung sollte eigene Fehlermeldungen bei allen nicht ausgefüllten Pflichtfeldern dauerhaft anzeigen.

Hinweis: Im Praxistipp zu Radiobuttons und Checkboxen sind Besonderheiten bezüglich deren Auszeichnung als Pflichtfelder erläutert.

Weitere Informationen 4.10.5.3.4 The required attribute - HTML Standard (whatwg.org)

Pflichtfelder können mit dem Attribut aria-required=true ausgezeichnet werden.

• Formularfelder, die mit aria-required=true ausgezeichnet wurden, werden nicht automatisch durch den Browser validiert und befinden sich nicht im fehlerhaften Zustand, wenn sie nicht ausgefüllt wurden. Der fehlerhafte Zustand kann mit aria-invalid=true übermittelt werden.
• Formularfelder, die mit aria-required=true ausgezeichnet wurden, sind visuell nicht automatisch als Pflichtfelder erkennbar.

Weitere Informationen: aria-required property - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org)

Informationen zu diesem Artikel

Datum:

15.05.2023

Lizenz:

CC-BY-SA 4.0