Anwendungsbezogene Anforderungen

Sofern die Anwendung nicht alle Anforderungen an die Barrierefreiheit erfüllt, kann eine konforme Alternativversion zur Verfügung gestellt werden. Dabei müssen jedoch folgende Anforderungen eingehalten werden:

• Die konforme Alternativversion erfüllt alle Anforderungen, d.h. ist vollständig barrierefrei. Werden mehrere Alternativversionen angeboten, ist mindestens eine Alternativversion vollständig konform. Es ist somit nicht zulässig, für einzelne Benutzergruppen spezifische Alternativversionen anzubieten, die jeweils nur die Anforderungen der jeweiligen Gruppe erfüllen, solange es keine Alternativversion gibt, die alle Anforderungen aller Benutzergruppen erfüllt.
• Die konforme Alternativversion ist bezüglich aller Inhalte und Funktionen äquivalent mit der Version, die nicht barrierefrei ist. So darf die Alternativversion z. B. nicht veraltete Informationen erhalten. Sofern die Standardversion in verschiedenen Sprachen angeboten wird, muss auch die Alternativversion in den Sprachen angeboten werden.
• Die konforme Alternativversion kann auf barrierefreie Weise erreicht werden. Dies bedeutet:
  • Die Funktion zum Wechsel zur konformen Alternativversion muss barrierefrei sein.
  • Die Standardversion darf keine Tastaturfallen oder blitzende Inhalte enthalten. Darüber hinaus darf die Standardversion keine sich bewegende, blinkende, automatisch aktualisierende oder akustische Inhalte enthalten, die nicht gestoppt werden können (https://www.w3.org/TR/WCAG21/#cc5).
  • Alternativ kann über eine barrierefreie Maske (z.B. die Login-Maske) sowohl die konforme als auch die Standardversion erreicht werden oder die konforme Alternativversion ist die Standardversion.
• In der Dokumentation wird der Zweck und das Erreichen der konformen Alternativversion erläutert.
• Der Support-Service kann den Zweck und das Erreichen der konformen Alternativversion erläutern (um EN 301 549, Abschitt 12.2.2, zu erfüllen). Es wird empfohlen, immer nur eine Version der Anwendung anzubieten und diese barrierefrei zu gestalten.

Hinweis 1: Ein typischer Anwendungsfall für eine konforme alternative Version ist, wenn die Standardversion der Web-Anwendung aufgrund des Corporate Design die Kontrastanforderungen für Text oder grafische Inhalte nicht erfüllt. In diesem Fall kann die konforme alternative Version eine CSS-Auszeichnung verwenden, die für ausreichende Kontraste sorgt.

Hinweis 2: Bei ausgewählten Web-Anwendungen, die bereits weitgehend barrierefrei sind, kann ein Overlaytool dazu in der Lage sein, eine konforme Alternativversion zu generieren, die die oben formulierten Anforderungen vollständig erfüllt. In der Regel ist dies allerdings nicht der Fall, insbesondere wenn die Web-Anwendung Probleme aufweist, die nicht automatisiert gefunden und behoben werden können. Ein Overlaytool kann somit nicht pauschal verwendet werden, um eine konforme alternative Version zur Verfügung zu stellen (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik - Publikationen - Gemeinsame Einschätzung der Überwachungsstellen des Bundes und der Länder für die Barrierefreiheit von Informationstechnik zur Verwendung von Overlay-Tools (bfit-bund.de))

Hinweis 3: Für Desktop-Anwendungen trifft die EN 301 549 keine Aussagen zu alternativen Versionen. Es kann jedoch davon ausgegangen werden, dass für Desktop-Anwendungen die gleichen Anforderungen gelten.

Synonyme: Language

Siehe auch: Beschriftung, Beschreibung, Text, Schrift

Fremdsprachige Inhalte können für beeinträchtigte Menschen schwer verständlich sein. Dies gilt insbesondere, wenn diese von der Sprachausgabe mit der falschen Aussprache ausgegeben werden.

Synonyme: Error message, Fehlermeldungen, Eingabehinweise, kontextspezifische Hilfe

Siehe auch: Pflichtfeldkennzeichnung, Beschreibung, Hilfe und Support, Authentifizierung, Formular

Fehlermeldungen informieren Benutzende über Fehleingaben oder Fehlbedienungen. Fehlermeldungen unterstützen bei der Fehlerkorrektur. Fehlermeldungen können

• nach dem Absenden eines Formulars,
• beim Ausfüllen eines Formulars oder
• bei der Bedienung der Software

angezeigt werden.

Eingabehinweise helfen Benutzenden beim Vermeiden von Fehlern. Sie können

• beim Formular,
• beim jeweiligen Formularfeld oder
• bei der Bedienung der Software

angezeigt werden.

Synonyme: Handbuch, Dokumentation, Support, Help

Siehe auch: Beschreibung, Fehlermeldungen

Beispiele:

Synonyme: Skalierung, Schriftgrößenanpassung, Zoom

Siehe auch: Schrift, Text

Die folgenden Anforderungen sollen die Anpassung der Schriftgröße an die Nutzungspräferenzen ohne Assistenztechnologie gewährleisten.

Synonyme: Barrierefreiheits-Schnittstelle, Interoperabilität mit Assistenztechnologie, Kompatibilität mit Assistenztechnologie, Plattformunterstützung von Barrierefreiheitsdiensten für Assistenztechnologien, Programmierschnittstelle für Assistenztechnologien

Siehe auch: Elementstatus, Kontextänderungen, Kontrastanpassung

Assistenztechnologien, wie Screenreader, Bildschirmlupen, Windows-Kontrastanpassung oder Spracheingabe-Software, interagieren in der Regel nicht direkt mit der Software oder dem Browser, sondern mittels einer Schnittstelle für die Barrierefreiheit, die z.B. vom Betriebssystem zur Verfügung gestellt wird: die Accessibility API (Application Programming Interface). Die Software bzw. der Browser übermittelt alle relevanten Informationen in standardisierter Form an die Accessibility API und die Assistenztechnologie greift auf die in der Accessibility API zur Verfügung gestellten Informationen zu. Die Assistenztechnologie nutzt jedoch nur die Informationen aus der Accessibility API, die entsprechend den Bedürfnissen der Benutzenden relevant sind. Wenn Anwendungen mittels Assistenztechnologie bedient werden, erfolgt die Bedienung teilweise nicht direkt, sondern auch vermittelt über die Accessibility API.

Die bekanntesten Accessibility APIs unter Microsoft Windows sind:

• IAccessible2,
• MSAA (Microsoft Active Accessibility, Standard 1997-2005),
• UIA (Microsoft UI Automation, Standard seit 2005).

Windows-Anwendungen sollen die aktuelle Accessibility API UIA verwenden.

Software, die nicht die Accessibility API des Betriebssystems nutzt, kann eigene Schnittstellen für die Übermittlung von Informationen an die Assistenztechnologie implementieren. So nutzen Java-Anwendungen die Java Accessibility API (JAAPI).

Die folgenden Informationen werden bspw. von der Software bzw. dem Browser an die Accessibility API übermittelt und bei Bedarf durch die Assistenztechnologie ausgelesen:

• Rolle eines Objekts (z.B. Überschrift, Checkbox, Tabellenzelle),
• Status eines Objekts (z.B. fokussiert, fokussierbar, deaktiviert, geöffnet),
• Beschriftung eines Objekts,
• Beschreibung eines Objekts,
• Wert eines Objekts (z.B. bei Formularfeldern),
• mögliche Werte (z.B. Maximal- und Minimalwert bei bestimmten Formularfeldern),
• Position in der Objekthierarchie (z.B. Eltern- und Kindobjekte, Anzahl der Geschwisterobjekte, Position in Bezug auf die Geschwisterobjekte),
• räumliche Größe und Lage in Bezug auf den aktuellen Bildschirmausschnitt,
• Ereignisse (z.B. Änderung von Objekteigenschaften).

Hinweise:

• Die meisten Programmiersprachen, die für die Entwicklung von Software genutzt werden können, unterstützen eine Accessibility API. Dies gilt analog für Browser.
• Die Unterstützung der Accessibility API erfolgt dabei meist automatisch, solange die Standardelemente der Programmiersprache oder Auszeichnungssprache (z. B. HTML) verwendet werden. Wenn die Sprache z.B. Eingabefelder als Bedienelement anbietet, dann werden Rolle, Wert, Status, Position in der Objekthierarchie, Größe und Lage des Eingabefeldes korrekt an die Accessibility API übermittelt. Meist muss die sichtbare Beschriftung korrekt mit dem Eingabefeld verknüpft werden, damit sie ebenfalls als Beschriftung des Eingabefeldes an die API übermittelt wird.
• Dies gilt analog für Standardeigenschaften der Programmiersprache oder Auszeichnungssprache, die automatisch an die Accessibility API übermittelt werden. Wird z.B. ein Eingabefeld mit der Eigenschaft „deaktiviert“ versehen, so werden automatisch die Eigenschaften „deaktiviert“ und „nicht tastaturfokussierbar“ an die API übermittelt.
• Je nach verwendeter Programmiersprache oder Auszeichnungssprache kann es sein, dass bestimmte Eigenschaften des Objekts, die an die Accessibility API übermittelt werden sollen, explizit (d. h. in Textform) angegeben werden müssen, weil sie anders nicht übermittelt werden können.
• Sofern kein Standardelement der Programmiersprache oder Auszeichnungssprache verwendet wird, muss entwicklungsseitig sichergestellt werden, dass alle relevanten Objektinformationen korrekt an die Accessibility API übermittelt werden. Wenn die Sprache keine Möglichkeit bietet, um diese Informationen explizit zu definieren, sollen nur Standardelemente verwendet werden.
• Wenn eine Programmiersprache weder eine Accessibility API unterstützt noch einen alternativen Zugriff der verschiedenen Assistenztechnologien auf die benötigten Informationen anbietet, soll sie nicht verwendet werden oder die Software muss dann die Anforderungen aus Abschnitt 5.1 (geschlossene Funktionalität) der EN 301 549 erfüllen.

Die Standardelemente der Plattformsoftware oder des verwendeten Frameworks übermitteln in der Regel automatisch die korrekten Informationen an die Accessibility API. Diese sollen somit bevorzugt verwendet werden.

Beispiel 1:

• In der folgenden Abbildung wird der Dialog „Speichern unter“ der Anwendung „Windows-Fax und -Scan“ gezeigt.
• Abgebildet ist außerdem eine vollständige Liste der Informationen, die für das Eingabefeld „Dateiname“, welches sich in diesem Dialog befindet, an die Accessibility API übermittelt werden (ausgelesen mit Accessbility Insights for Windows).
• Daneben wird die Sprachausgabe des Screenreaders JAWS bei Fokussierung des Eingabefeldes „Dateiname“ gezeigt. JAWS nutzt für die akustische Ausgabe nur die im aktuellen Kontext relevanten Informationen der Accessibility API (z. B. Beschriftung, Rolle, Wert, Tastaturkürzel), übersetzt diese Informationen teilweise in die Anwendungssprache (z. B. die Rolle „Edit(50004)“ in „Eingabefeld“) und ergänzt diese Informationen mit einem eigenen Bedienhinweis („Geben Sie Text ein“), der aus der übermittelten Rolle abgeleitet wird.

Werden benutzerdefinierte Elemente verwendet, so soll insbesondere auf Folgendes geachtet werden:

• die übermittelte Rolle entspricht der visuellen Darstellung und Bedienweise (insbesondere der Tastaturbedienung),
• der Wert und Status sollen an die Accessibility API übermittelt werden,
• die Beschriftung wird als Accessible Name an die Accessibility API übermittelt,
• sofern vorhanden, werden auch Tastaturkürzel, Beschreibungen (als Accessible Description) und Beschriftungen der Gruppen an die Accessibility API übermittelt,
• Aktualisierungen hinsichtlich Wert, Status, Beschriftung etc. werden an die Accessibility API übermittelt (Hinweis: Die Rolle eines Elements soll nicht verändert werden).

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.

Für die Übermittlung der Informationen sollen die entsprechenden Eigenschaften der Accessibility API verwendet werden. Wenn es für eine Information keine entsprechende Eigenschaft in der Accessibility API gibt oder das verwendete Framework diese Eigenschaft nicht unterstützt, muss die Information in Textform (d.h. als Teil des Accessible Names oder der Accessible Description) übermittelt werden.

Beispiel: Deaktivierte Elemente

• Deaktivierte Elemente können meist mit einem Attribut als disabled ausgezeichnet werden. In der Accessibility API UIA entspricht dies der Eigenschaft IsEnabled:false. Assistenztechnologie erkennt aufgrund dieser Eigenschaft, dass das Element deaktiviert ist.
• Wenn eine programmatische Auszeichnung als deaktiviert nicht möglich ist, können alternativ folgende Möglichkeiten angewendet werden:
  • Das Element wird entfernt.
  • Das Element wird nicht fokussierbar gestaltet (sofern es keine Informationen übermittelt und sich nicht innerhalb eines Bereichs befindet, der mit dem virtuellen Cursor gelesen werden kann).
  • Das Element wird im Accessible Name oder in der Accessible Description als „deaktiviert“ benannt.

Beispiel: Schalter mit Wert

• Ein Schalter kann standardmäßig keinen Wert besitzen. Unter Windows ist es jedoch möglich, basierend auf dem Standardelement Schalter ein benutzerdefiniertes Element „Schalter mit Wert“ zu erstellen. Der Wert wird dann als Wert der Eigenschaft Value an die Accessibility API UIA übermittelt.
• In HTML und ARIA ist es nicht möglich, einem Schalter einen Wert zuzuweisen. Soll der „Wert mit Schalter“ in einer hybriden Anwendung, die auf Web-Technologien basiert, eingesetzt werden, dann muss der Wert in Textform als Teil des Accessible Names oder der Accessible Description übermittelt werden.

Die Übermittlung von Informationen über die entsprechenden Eigenschaften der Accessibility API ist gegenüber der Übermittlung dieser Informationen in Textform (als Teil von Accessible Name oder Accessible Description) aus folgenden Gründen immer zu bevorzugen:

• die Assistenztechnologie kann die Eigenschaften, die über die API übermittelt werden, auf eine durch die Anwendung oder von den Benutzenden definierte Art und Weise ausgeben,
• die Assistenztechnologie kann die Eigenschaften, die über die API übermittelt werden, in die korrekte Sprache übersetzen,
• die Assistenztechnologie kann passend zu den Eigenschaften, die über die API übermittelt werden, Bedienhinweise ausgeben oder Bedienmodalitäten anbieten,
• die Assistenztechnologie kann basierend auf den Eigenschaften, die über die API übermittelt werden, eine bestimmte Darstellungsweise anbieten (z.B. eine bestimmte Farbe bei der Kontrastanpassung),
• die Assistenztechnologie kann die Eigenschaften (wie Rolle, Status, Wert) in einer bestimmten Reihenfolge ausgeben, die sicherstellt, dass relevante Informationen zuerst ausgegeben werden und dass die Benutzenden erkennen können, welche Informationen zu welchem Eigenschaftstyp gehören,
• die Benutzenden können in ihrer Assistenztechnologie ggf. konfigurieren, dass sie bestimmte Eigenschaften nicht ausgegeben bekommen möchten.

Dies ist alles nicht möglich, wenn die Information lediglich in Textform übermittelt wird.

Beispiel 2: In der folgenden Abbildung sind drei Schalter mit den Beschriftungen „Absenden“, „Prüfen“ und „Löschen“ zu sehen.

• Der „Absenden“-Schalter ist visuell als bedienbar zu erkennen (schwarze Textfarbe).
• Der „Prüfen“-Schalter ist visuell als deaktiviert zu erkennen (graue Schriftfarbe). Der Schalter ist programmatisch als deaktiviert ausgezeichnet. Diese Umsetzung ist für deaktivierte Schalter zu bevorzugen.
• Der „Löschen“-Schalter ist visuell ebenfalls als deaktiviert zu erkennen (graue Schriftfarbe). Der Schalter ist aber programmatisch nicht als deaktiviert ausgezeichnet, sondern besitzt nur einen Tooltip mit dem Wort „disabled“. Diese Umsetzung darf für deaktivierte Schalter nur gewählt werden, wenn in der verwendeten Technologie keine programmatische Auszeichnung als deaktiviert möglich ist.

In der folgenden Abbildung sind die selben Schalter aus der vorhergehenden Abbildung dargestellt, nun allerdings bei Verwendung der Windows-Kontrastanpassung (Kontrast Nr. 1).

• Der „Absenden“-Schalter ist visuell korrekt als bedienbar zu erkennen (weiße Textfarbe).
• Der „Prüfen“-Schalter ist visuell korrekt als deaktiviert zu erkennen (grüne Schriftfarbe).
• Der „Löschen“-Schalter wird als bedienbar dargestellt (weiße Textfarbe), obwohl er deaktiviert ist. Die Ursache für die Fehldarstellung ist, dass er nicht programmatisch als deaktiviert ausgezeichnet wurde, sondern nur farblich als deaktiviert. Die Farbinformation geht jedoch bei Nutzung der Windows-Kontrastanpassung verloren, so dass hier eine andere visuelle Darstellung verwendet werden müsste, um den Status „deaktiviert“ zu erkennen (z. B. eine Durchstreichung).

In der folgenden Abbildung wird die akustische Screenreader-Ausgabe der drei Schalter aus der vorhergehenden Abbildung dargestellt (am Beispiel der Elementübersicht von JAWS).

• Der „Absenden“-Schalter wird korrekt als bedienbar ausgegeben (Rolle „Schalter“).
• Der „Prüfen“-Schalter wird korrekt als deaktiviert ausgegeben (Status „nicht verfügbar“).
• Der „Löschen“-Schalter wird inkorrekt als bedienbar ausgegeben (Rolle „Schalter“), weil der Status „deaktiviert“ nur per Tooltip übermittelt wird und der Tooltip-Inhalt vom Screenreader nur bei bestimmten Navigationsmethoden ausgegeben wird.

In den drei folgenden Abbildungen wird die Ausgabe der drei Schalter aus den vorhergehenden Abbildungen auf der Braillezeile dargestellt (am Beispiel von JAWS).

• Der „Absenden“-Schalter wird korrekt als bedienbar ausgegeben (Rolle „Schalter“, die mit der Kurzform „sltr“ angezeigt wird).
• Der „Prüfen“-Schalter wird korrekt als deaktiviert ausgegeben (Status „nicht verfügbar“, die mit der Kurzform „xx“ angezeigt wird).
• Der „Löschen“-Schalter wird zwar als deaktiviert ausgegeben (Beschreibung „disabled“), allerdings erfolgt die Ausgabe nicht in Kurzform, nicht an der erwarteten Position und nicht übersetzt in die Sprache des Benutzenden.

Synonyme: Anmelden, Abmelden, Login, Logout

Siehe auch: Kontextänderungen, Zeitbegrenzungen, Kennwort-Eingabefeld

Die Authentifizierung umfasst die Vorgänge des Anmeldens und Abmeldens bei einer Anwendung oder innerhalb einer Anwendung. Die Anmeldung kann erforderlich sein, um eine Anwendung oder bestimmte Teile der Anwendung nutzen zu können.

Hinweis: Anforderungen an Bedienelemente zur Authentifizierung (z.B. Eingabefelder, Kennwort-Eingabefelder und Schalter) werden bei dem jeweiligen Element beschrieben.

Synonyme: Blitzen, Blinken, Aktualisierungen, Flash

Siehe auch: Zeitbegrenzungen, Karussell, Video, Fortschrittsanzeige

Animationen sind:

• automatische visuelle Veränderungen oder
• unerwartete visuelle Veränderungen bei Bedienung der Anwendung.

Beispiele für automatische visuelle Veränderungen:

• Laufschrift,
• automatisch gestartetes Video,
• automatisch scrollende Inhalte,
• blinkende oder blitzende Inhalte,
• Inhalte, die automatisch nach einer bestimmten Zeit aktualisiert werden.

Beispiele für unerwartete visuelle Veränderungen bei Bedienung der Anwendung sind:

• beim Scrollen der Maske werden Inhalte zusätzlich animiert,
• beim Scrollen der Maske werden die Inhalte mit unterschiedlicher Geschwindigkeit gescrollt,
• manuell gestartetes Video enthält blitzenden Inhalte,
• blinkende Fehlermeldung, die nach Absenden eines Formulars eingeblendet wird,
• beim Einblenden von Inhalten werden diese nicht unmittelbar angezeigt, sondern animiert eingeblendet (z.B. skaliert, verschoben, gedreht oder in ihrer Transparenz verändert).

Synonyme: Tab-Reihenfolge, Focus order

Siehe auch: Tastaturbedienung, Kontextänderungen, Zeitbegrenzungen

Die Navigationsreihenfolge bestimmt, in welcher Reihenfolge mit der Tastatur fokussierbare Elemente und Bereiche den Fokus erhalten. Typischerweise betrifft dies die folgenden Navigationsmethoden:

• Navigation zwischen den Elementen mit der Tabulatortaste,
• Navigation innerhalb der Elemente mit den Pfeiltasten,
• Navigation zwischen den Bereichen (z.B. mit der F6-Taste),
• Schnellnavigation (z.B. mit BILD AB, ENDE).

Die korrekte Navigationsreihenfolge sollte über die Reihenfolge der Elemente im Quellcode gesteuert werden. Das Attribut tabindex sollte nicht verwendet werden. Das Attribut autofocus sollte nur mit Bedacht verwendet werden, weil dadurch ggf. für sehbeeinträchtigte und blinde Menschen die Inhalte vor dem automatisch fokussierten Element schwer wahrnehmbar sind. Es gibt jedoch Anwendungsfälle, bei denen autofocus sinnvoll eingesetzt werden kann, z. B. auf einer Login-Seite, um das erste Eingabefeld zu fokussieren. Weitere Informationen: 6.6.3 The tabindex attribute - HTML Standard (whatwg.org), 6.6.7 The autofocus attribute - HTML Standard (whatwg.org)

Die korrekte Navigationsreihenfolge sollte über die Reihenfolge der Elemente im Quellcode gesteuert werden. Das Attribut tabindex=0 muss für Bedienelemente verwendet werden, die andernfalls nicht den Tastaturfokus erhalten würden. Elemente, die per JavaScript fokussierbar sein sollen, sich jedoch nicht automatisch im TAB-Kreislauf befinden, werden mit tabindex=-1 ausgezeichnet. Dies gilt z. B. für Schalter in Werkzeugleisten, Einträge in Auswahllisten oder Radiobuttons innerhalb einer Radiobuttongruppe. In diesen Fällen wird lediglich jeweils ein Schalter, ein Listeneintrag bzw. ein Radiobutton mit tabindex=0 ausgezeichnet und alle anderen mit tabindex=-1. Weitere Informationen: Developing a Keyboard Interface | APG | WAI | W3C

Enthält das aktuelle Fenster der Anwendung viele fokussierbare Elemente, können Nutzende, die auf Tastaturbenutzung angewiesen sind, nicht effizient durch das Fenster navigieren, da sie mit der TAB-Taste diese Elemente durchlaufen müssen. Um eine effiziente Navigation mit der Tastatur zu ermöglichen, wird empfohlen, eine oder mehrere der folgenden Methoden zu implementieren und in der Hilfe zu dokumentieren:

• Bereichsnavigation (z.B. mit F6),
• Sprunglinks am Anfang des Fensters bzw. vor Bereichen mit vielen Navigationsschritten,
• Tastaturkürzel für häufig benötigte Funktionen bzw. Bedienelemente,
• Bereiche mit vielen Navigationsschritten ein- und ausblendbar gestalten (z.B. Menü mit Untermenü, Registerkarten, Akkordeon),
• Auslagern von Inhalten mit vielen Navigationsschritten auf sekundäre Masken (z.B. in Dialogfenster, die separat aufgerufen werden können),
• Verwenden von gruppierenden Elementen, innerhalb derer mit den Pfeiltasten anstelle der TAB-Taste navigiert wird (z.B. Werkzeugleiste, Interaktive Tabelle, Menü),
• bei Anwendungen, die den virtuellen Cursor nicht unterstützen: Modus bei dem nur Bedienelemente den Fokus erhalten.

Synonyme: Aktualisierungen, change of context

Siehe auch: Animationen, Zeitbegrenzungen, Navigationsreihenfolge, Modaler Dialog

Kontextänderungen sind:

• Wechsel zu einem anderen Programm,
• Änderung des Viewports (z.B. Wechsel zu einem anderen Anwendungsfenster),
• Änderungen des Tastaturfokus,
• Änderung des Inhalts, der die Bedeutung der Seite ändert.

Bei Bedienung erwartete und erforderliche Kontextänderungen sind z.B.:

• Aktivierung eines Links: Öffnen einer neuen Maske,
• Aktivierung eines Hilfe-Links: Öffnen der Hilfe, ggf. in einer anderen Anwendung (z.B. im Browser oder PDF-Reader),
• Aktivierung eines seiteninternen Links: Scrollen zur verlinkten Position und Änderung des Tastaturfokus,
• Aktivierung eines Absenden-Schalters: Öffnen einer neuen Maske,
• Aktivierung eines Löschen-Schalters: Entfernen des zu löschenden Elements, ggf. Änderung des Tastaturfokus (weil der Löschen-Schalter deaktiviert oder entfernt wurde),
• Aktivierung des Logout-Schalters: Logout aus der Anwendung,
• Aktivierung eines Menü-Schalters: Öffnen des Menüs und Fokussierung des ersten Menüeintrags,
• Aktivierung eines Schalters zum Öffnen eines modalen Dialogs: Öffnen des Dialogs und Fokussierung des ersten Elements im Dialog,
• Scrollen der Seite: Änderung des sichtbaren Bereichs,
• Navigation mit der Tastatur (z.B. mit der Tabulatortaste): Änderung des Tastaturfokus, ggf. Änderung des sichtbaren Bereichs (sofern sich das fokussierte Element nicht im sichtbaren Bereich befindet),
• Navigation durch eine Radiobuttongruppe, bei der sich hinter jedem Radiobutton zugehörige Formularfelder befinden, die nur in Abhängigkeit vom Radiobutton sinnvoll bedient werden können: Die Formularelemente beim ausgewählten Radiobutton werden aktiviert, die jeweils anderen Formularelemente werden deaktiviert.
• Navigation durch eine Gruppe von Karteireitern: Die zugehörige Registerkarte wird eingeblendet (alternativ erst nach Aktivierung des Karteireiters).

Beispiele für unerwartete Kontextänderungen, die vermieden oder angekündigt werden müssen:

• Aktivierung einer Checkbox innerhalb eines Formulars: Einblenden von weiteren Formularfeldern, die sich visuell und in der Navigationsreihenfolge vor der Checkbox befinden,
• Texteingabe in ein Eingabefeld: Löschen von bereits getätigten Eingaben in anderen Feldern, weil sich die Eingaben in diesem Feld und den anderen Feldern gegenseitig ausschließen,
• Texteingabe in ein Eingabefeld: Nach Erreichen der maximalen Zeichenzahl wird der Fokus ins folgende Eingabefeld gesetzt,

Beispiele für unerwartete Kontextänderung, die vermieden oder angekündigt werden sollen:

• Aktivierung eines Links: Öffnen einer neuen Maske in einer anderen Anwendung,
• Aktivierung eines Karteireiters: Die eingeblendete Registerkarte oder ein Element in dieser erhält den Fokus.

Beispiele für unerwartete Kontextänderungen, die vermieden werden müssen:

• Navigation durch eine Radiobuttongruppe: Öffnen einer neuen Maske,
• Navigation durch eine Tabelle: Öffnen eines modalen Dialogs,
• Vollständig ausgefülltes Formular: Absenden des Formulars,
• Fokussieren eines Absenden-Schalters: Absenden des Formulars,
• Fokussieren des Löschen-Schalters: Entfernen des zu löschenden Elements.

Synonyme: Timeout, Time limit

Siehe auch: Animationen, Kontextänderungen, Authentifizierung, Karussell

Zeitbegrenzungen sind zeitliche Vorgaben, um Inhalte wahrzunehmen, Elemente zu bedienen oder Aufgaben abzuschließen. Zeitbegrenzungen können z.B. auftreten, wenn

• nach einer bestimmten Zeit der Inaktivität ein automatisches Logout erfolgt,
• ein für die Authentifizierung notwendiger PIN nur eine bestimmte Zeit gültig ist,
• Meldungen nach einer bestimmten Zeit ausgeblendet werden,
• Inhalte automatisch aktualisiert werden (z.B. in einem Karussell),
• Laufschrift angezeigt wird.

Informationen zu diesem Artikel

Datum:

21.04.2023

Lizenz:

CC-BY-SA 4.0