Prüfschritt 9.3.2.2 Frage zu der Bewertung bei einer Pagination mit Select für die Anzahl der Anzuzeigenden Zeilen

[ElVariablo]

Uns stellt sich bei der Bewertung des Prüfschritts "9.3.2.2" bei folgendem Fall eine Frage:

Es geht um ein Auswahlliste zur Einstellung der anzeigten Datensätze in einer Tabelle, welche sich in Kombination mit einer Pagination unterhalb einer Tabelle befindet. Da ein Select auf das "onChange"-Event reagiert und dadurch die Zeilenanzahl der Tabelle sofort geändert wird, sind wir nicht sicher, ob es sich hierbei um eine unerwartete Kontextänderung („change of context“) oder auch nur um eine Inhaltsänderung ("change of content") handelt. Stichwort: Änderung des Viewports. Ist diese durchaus gängige Konstellation/Muster prüfschrittkonform oder muss der Prüfschritt an dieser Stelle abgewertet werden? Falls diese Konstellation abgewertet werden muss, wie können mögliche Lösungen aussehen. Ein zusätzlicher Button wie in H84 beschrieben, wäre aus Design bzw. UX-Sicht nicht erwünscht. Gibt es weitere Alternativen? Unabhängig davon, was in unserem konkreten Fall das Ergebnis ist, würde eine weitere Konkretisierung des Prüfschritts in Bezug auf die "unerwartete Kontextänderung" hilfreich sein. Auch ein Hinweis auf die konkrete Zielgruppe(n) könnte Klarheit schaffen und Interpretationsspielraum vermeiden, sofern dieser Prüfschritt konkrete Zielgruppen im Fokus hat.

[marcus-herrmann]

Die Absicht hinter (9.)3.2.2 ist, dass es ungewöhnlich und unüblich ist, dass z.B. ein Formularelement zur Optionsauswahl (z. B. Select) für einen brutalen, sofortigen Bruch im Interface sorgt. Also zum Beispiel ein Change Of Context in Form einer neu ladenden Seite stattfindet, anstatt dass nur die angewählte Option in einem Formular dann eben ausgewählt ist. Das wäre vor allem bei Screenreader-Nutzung eine größere Irritation, vor allem dann, wenn Benutzende nicht damit rechnen (Stichtwort "unerwartet"). Es ist in Prüfungen immer eine Einzelfallentscheidung, aber wenn die auf das Select reagierende Tabelle im Dokument unter/hinter/nach dem Select kommt, klingt es mehr nach Change of Content.

[sweckenmann]

Stimme @marcus-herrmann zu, wenn das Select oberhalb von der Tabelle wäre, dann ist es ein Change of Content und die Inhalte wären in einer sinnvollenLesereihenfolge (Stichwort nicht-visueller Nutzung) ggf. Fokusreihenfolge, und es hilft auch Nutzenden, die aufgrund starker Zoomfaktors nur einen kleinen Ausschnitt sehen.

[johannesFischer84]

Aus meiner Sicht wäre es aus Usability-Sicht für alle Nutzenden viel besser, das <select> bzw. Auswahlfeld oberhalb der Tabelle zu positionieren, wie es schon angemerkt wurde.

Aus Barrierefreiheits-Sicht würde ich unabhängig vom Ort des Bedienelements zwei Fälle unterscheiden: Fall 1 - Das change-Ereignis löst ein Neuladen der Seite aus: Der Fokus ist in der Regel wieder zu Beginn der Seite. Das wäre eine unerwartete Kontextänderung bei Eingabe (bzw. Wertänderung) und damit ein Verstoß gegen WCAG 3.2.2. Fall 2 - Das change-Ereignis belässt den Fokus auf dem Auswahlfeld, die Tabellen-Anpassung erfolgt als Hintergrundvorgang: In diesem Fall ist WCAG 3.2.2 erfüllt. Allerdings ist die Veränderung der Tabelle eine Art Statusmeldung nach WCAG 4.1.3. Man müsste die Nutzenden über eine Live-Region darüber informieren, was seine Aktion ausgelöst hat, z. B. "Tabelle zeigt X Zeilen an".

[stefanFarnetani]

@johannesFischer84 hat das sehr gut zusammengefasst.

Das wichtig ist, sich zu überlegen, wie Nutzerinnen informiert werden.
Im Anschluss noch ein paar Varianten zur Verdeutlichung. Es gibt keine direkte Vorgabe zur technischen Umsetzung. Dementsprechend müssen wir auch bei der Bewertung sehr flexibel sein. Es zählt nur das Ergebnis: Die Nutzerin wird informiert. Dies muss unmittelbar davor, danach oder durch ein langes etabliertes Bedienmuster (Formular / Absende-Button) erfolgen.

Fall 1 a) Reload wäre ok, wenn es einen Absende-Button gibt. Ein zusätzliches Verschieben des Fokus ist optional und wird in der Barrierefreiheit nicht bewertet. Aus UX-Sicht ist es oft wünschenswert. b) Eine andere Möglich ist, die Nutzer*in beim Bedienelement zu informieren: z.B. "Anzahl der Ergebnisse (löst Neuladen der Seite aus)". Die zusätzliche Information kann nur für Screenreader kodiert sein. Ich finde diese Lösung nicht elegant, aber sie funktioniert.

Fall 2 a) Johannes beschreibt bereits die Möglichkeit, mit ARIA Live-Region zu informieren. Oft kann man die Live-Region Information mit einer für alle Nutzer*innen sichtbaren Text kombinieren. Z.B. bei einem interaktiven Suchfiltern, die das Ergebnis einschränken, den sichtbaren Satz "12 Suchergebnisse" als live-Region auszeichnen. b) Eine weitere Möglichkeit bei interaktiver Veränderung der Inhalte wäre das anschließende Verschieben des Fokus auf einen veränderten Text/Überschrift am Anfang der veränderten Inhalte. Ich nutze nochmal das Beispiel mit den gefilterten Suchergebnissen. Also auf den Satz/Überschrift "12 Suchergebnisse".

[MarcHaunschild]

Wenn die Änderungen vor dem auslösenden Element stattfinden, kann man auch über eine Abwertung unter meaningful sequence nachdenken.

[stefanFarnetani]

Wenn die Änderungen vor dem auslösenden Element stattfinden, kann man auch über eine Abwertung unter meaningful sequence nachdenken.

Vielleicht war das so gemeint. Ich präzisiere sicherheitshalber.

Eine Abwertung nur, wenn Nutzer*innen nicht informiert wurde. Wenn z.B. über ARIA Live-Regions informiert wurde, kann die Änderung auch an einer andren Stelle auf der Seite erfolgen.

[johannesFischer84]

@stefanFarnetani Stefan, danke für die größere Ausführlichkeit. Zwei Ergänzungen habe ich zu dir:

Bei Fall 1

b) Eine andere Möglich ist, die Nutzer*in beim Bedienelement zu informieren: z.B. "Anzahl der Ergebnisse (löst Neuladen der Seite aus)". Die zusätzliche Information kann nur für Screenreader kodiert sein. Ich finde diese Lösung nicht elegant, aber sie funktioniert.

Aus meiner Sicht muss über eine Kontextänderung in sichtbarem Text informiert werden. Denn sonst wäre es immer noch eine unerwartete Kontextänderung für Nutzende, die keinen Screenreader verwenden.

Bei Fall 2

b) Eine weitere Möglichkeit bei interaktiver Veränderung der Inhalte wäre das anschließende Verschieben des Fokus auf einen veränderten Text/Überschrift am Anfang der veränderten Inhalte. Ich nutze nochmal das Beispiel mit den gefilterten Suchergebnissen. Also auf den Satz/Überschrift "12 Suchergebnisse".

Das Verschieben des Fokus würde ich aber nur dann empfehlen, wenn im <select> nicht schon ein einzelnes Pfeil-nach-unten-Taste-Drücken zur Verschiebung des Fokus führt. Ansonsten müssten Nutzende wie beim Seiten-Neuladen immer wieder zurück zum Auswahlfeld, um die für sie passende Option auszuwählen. Oder sie müssten die Tastenkombination Alt + Pfeil-nach-unten-Taste kennen (<select> klappt auf, wobei ein einzelnes Pfeil-Taste-drücken noch kein change-Ereignis auslöst), was man aber nicht voraussetzen sollte.

[Sommerli2]

Eine Abwertung nur, wenn Nutzer*innen nicht informiert wurde. Wenn z.B. über ARIA Live-Regions informiert wurde, kann die Änderung auch an einer andren Stelle auf der Seite erfolgen.

Die ARIA Live-Regionen führen ja "nur" bei dem Screenreader-Nutzenden zu einem besseren Verständnis. Für die Zielgruppe der kognitiv eingeschränkten Personen ändert das nichts.

[stefanFarnetani]

@Sommerli2 @johannesFischer84

Ich verstehe vollkommen die Hinweise, dass es auch für sehende Nutzer*innen klar sein muss.

Aus meiner Sicht kommt das stark auf die Einzelsituation an. Ich möchte vermeiden, dass generell abgestraft wird, wenn das Muster der "filterbaren Liste" angewendet wird. Das Muster ist in meinen Augen völlig akzeptabel für sehende Nutzer*innen und ausreichend bekannt. Das genannte Beispiel ist eine Variation davon.

Ein Gedankenspiel: Würden genauso darüber diskutieren, wenn anstelle eines selects drei Knöpfe mit der Beschriftung "20 Einträge", "50 Einträge" und "100 Einträge" stehen würde. Es gibt viele Situationen, bei dem Buttons über oder unmittelbar unter einer Liste etwas steuern. Die Paginierung selbst wäre ein Beispiel. Es ist ein gelerntes Muster. Für Computer-Neulinge natürlich schwerer zu verstehen; das sind "Hauptnavigation" oder "Unterstrichene Links" auch. Aber auch dieses gelernte Muster akzeptieren wir als barrierefrei. Für Screenreader Nutzer*innen ist das select problematisch, da es ein Formularelement ist. Nach dem Prinzip a "role is a promise" erwartet man nicht, dass es alleine funktioniert. Ein Knopf hingegen macht das und ist damit deutlicher.

Ich will nicht sagen, dass alles erlaubt ist. Ich habe nur das Gefühl, dass wir etwas zu streng sind in manchen Auslegungen.

[johannesFischer84]

@stefanFarnetani

Würden genauso darüber diskutieren, wenn anstelle eines selects drei Knöpfe mit der Beschriftung "20 Einträge", "50 Einträge" und "100 Einträge" stehen würde.

Knöpfe/Schalter/Buttons würden durch Aktivierung, nicht durch Eingabe (Wertveränderung) ausgelöst. Da wäre WCAG 3.2.2 nicht betroffen bzw. es wäre eine erwartete Kontextänderung, wenn ich den Schalter drücke und der Fokus versetzt wird.

Also wenn man statt <select> ein Menü von <button> Elementen verwendet, wo man den Menü-Schalter aufklappt und dann auf einen der untergeordneten Schalter drückt, wäre es semantisch passend. Optisch sollte es nicht wie ein Auswahlfeld aussehen, sondern eher wie ein Menü, z. B. ähnlich zu den mobilen Hamburger-Navigationsmenüs. Durch das andere optische Aussehen und die andere semantische Auszeichnung wäre die Umsetzung konform.

[stefanFarnetani]

@johannesFischer84 Wir haben uns falsch verstanden. Es ging mir um ein Gedankenexperiment. Ich wollte das nicht korrekt durchziehen.

Aber deine Ausführungen bestätigen, worauf ich hinaus wollte. Die Problematik bei diesem Nutzungsmuster liegt in erster Linie darin, es für Screenreader Nutzerinnen zugänglich zu machen. Alle Einwände, dass das Nutzungsmuster auch für sehende Nutzerinnen ein Problem darstellt, würden bei leicht veränderten Konstellation nicht diskutieren. Stattdessen würden wir Vorschläge machen (wie Du gerade), wie es technisch korrekt umgesetzt wäre.

Quod erat demonstrandum (was zu beweisen war) - Danke für deine Mitarbeit. ;)

[Sommerli2]

Hallo zusammen,

wir haben zum Thema parallel ein Ticket bei der W3C eröffnet, um deren Standpunkt zum Thema abzufragen. Diese sehen die Art der Änderung in oben genannten Fall als Content- nicht aber als Contextänderung.

Ist es möglich von Seiten der BIK-BITV eine offizielle Stellungnahme zu geben, die für uns Klarheit schafft und auf die wir uns künftig beziehen können.

Besten Dank und viele Grüße

[johannesFischer84]

@Sommerli2 Wenn sich wie im Ticket der WCAG Working Group beschrieben nur die Tabelle an sich verändert, wäre das für mich auch nur eine Inhaltsveränderung, die aber mit einer Statusmeldung nach WCAG 4.1.3 einhergehen sollte. Anscheinend soll die Scroll-/Fokusposition unverändert bleiben bzw. dazu wird nichts genannt.

Im Ausgangsbeitrag unserer Diskussion dagegen war die Rede von "Änderung des Viewports". Darunter habe ich verstanden, dass sich die Scrollposition des Fensters oder die Fokusposition verändern soll, was eine unerwartete Kontextveränderung wäre. Aber vielleicht habe ich das missverstanden.

[Sommerli2]

@johannesFischer84 Du hast den Ausgangsbeitrag richtig verstanden. Durch die Änderung der Tabelle (Anzahl der angezeigten Zeilen, ansonsten ändert sich nichts), kann sich die Scrollposition natürlich auch ändern. Das war auch der Grund, warum wir uns nicht sicher waren, ob es eine Inhalts- oder Kontextänderung ist.

[detlevhfischer]

@johannesFischer84 Du schreibst oben:

Allerdings ist die Veränderung der Tabelle eine Art Statusmeldung nach WCAG 4.1.3. Man müsste die Nutzenden über eine Live-Region darüber informieren, was seine Aktion ausgelöst hat, z. B. "Tabelle zeigt X Zeilen an".

In der Regel sind Statusmeldungen ja Ausgaben, die visuell umgesetzt sind (etwa: "20 Einträge werden angezeigt"), die dann als Statusmeldung über role="status" oder aria-live auch programmatisch ausgegeben werden müssen (ohne Fokusversetzung). Wenn sich jedoch umfangreiche Inhlate (hier die Tabelle) ändern, die sich nicht selbst als Inhalt einer Statusmeldung eignen, wäre wohl noch nicht zwingend zu fordern, dass zusätzlich (visuell und programmatisch) eine Statusmeldung darüber ausgegeben wird. Gut wär's natürlich, aber ich denke, das lässt sich nicht aus dem normativen Text ableiten.

[johannesFischer84]

@detlevhfischer Ich habe nochmal nachgelesen. Letztendlich stimme ich dir zu, dass man aktuell für eine optische Tabellenzeilen-Veränderung wohl keine Statusmeldung fordern kann, auch wenn Interpretations-Spielraum besteht bzw. ich es etwas für eine Grauzone halte. Aber ich erläutere meinen Gedankengang mal:

Normativ ist der Begriff "status message". Dieser ist in den WCAG so formuliert:

change in content that is not a change of context, and that provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors

"change in content [...] that provides information [...] on the success or results of an action" heißt für mich auf Deutsch, dass es sich bei Statusmeldungen u. a. um Inhaltsänderungen handelt, die Information zur Auswirkung einer Nutzeraktion bereitstellt.

Im Ausgangsbeispiel geht es darum, dass durch Nutzeraktion (Drop-Down-Auswahl) die Anzahl der Zeilen in der Tabelle verändert werden soll. Die Inhaltsänderung, die Informationen zur Auswirkung der Nutzeraktion bereitstellt, ist die sichtbare Veränderung der Zeilenzahl. Meiner Meinung nach ist das erstmal eine Statusmeldung, auch wenn sie nicht direkt in Textform so formuliert ist.

Das Understanding-Dokument 4.1.3 im Bereich "Examples [...] not add new text" schränkt (meinem Empfinden nach unglücklicherweise) diese normative Bedeutung aber ein:

However, not all changes to content involve the addition of text to the screen. The following are all considerations relevant to this Success Criterion:

• Non-displayed text specific to AT users;
• Modification of status text;
• Removal of status text; and
• Non-textual status content, such as images.

Zwar wird hier "non-textual status content" genannt, wovon ich Tabellen zunächst umfasst sehen würde. Und "such as images" klingt für mich nur nach einem Beispiel. Wenn man in der Detail-Beschreibung zu diesem Stichpunkt weiter unten aber nachliest, werden da eben nur Grafiken beschrieben. Zwar schließt der Text andere Inhalte als Grafiken nicht ausdrücklich aus. Aber wenn Grafiken so deutlich genannt werden und andere Nicht-Text-Inhalte gar nicht, dann hat man auch schwer ein Argument für Nicht-Text-Inhalte wie Tabellen.

[detlevhfischer]

@johannesFischer84 Ich denke, es ist einfacher: Eine ganze Tabelle ist keine Meldung, sondern "status message" ist, wie definiert, ein Text

that provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors

...und gefordert wird ja nur, dass solche Statusmeldungen auch programmatrisch ausgegeben werden. Als Empfehlung richtig ist es allemal, bei Änderungen in der Tabelle eine maßgeschneiderte Meldung zusätzlich zu schaffen, die die Änderung knapp fasst (auch als sichtbare Statuszeile). Aber normativ ableiten als MUSS kann man das wohl nicht...

[johannesFischer84]

@detlevhfischer

sondern "status message" ist, wie definiert, ein Text

Normativ definiert ist der Begriff "status message" nicht als Text, sondern als Inhaltsänderung (change in content), was so gut wie alles beinhalten kann meiner Meinung nach. Aber ich bin jemand, der nicht nur den normativen Text heranzieht, sondern auch auf Understanding und die Techniques großes Gewicht legt. Daher kommen wir wohl trotz der unterschiedlichen Interpretation des normativen Begriffs am Ende zusammen ...

[detlevhfischer]

@Sommerli2 Können wir mit Verweis auf https://github.com/w3c/wcag/discussions/3372 und diese Diskussion dieses Issue schließen?

[Sommerli2]

@Sommerli2 Können wir mit Verweis auf w3c/wcag#3372 und diese Diskussion dieses Issue schließen?

von mir aus gerne.