9.1.3.1h Programmatische Ermittelbarkeit - die Placeholder-Frage

[detlevhfischer]

Für placeholderfehlt noch eine Festlegung, ob dies notfalls als zugänglicher Name ausreicht, wenn nichts sonst verfügbar ist. Die defacto-Desktop-Browser-Unterstützung ist hier mit Ausnahme von Edge/Sprachausgabe ganz gut, bei der Sprachausgabe wird placeholdererst nach Aktivieren von "Erweiterte Detailswie Hilfetexte, Schaltflächen unde andere Steuerelemente hören" in den Systemeinstellungen ausgegeben. Mobil ist die Unterstützung bei Android/Chrome gegeben (auch nach Eingabe), bei iOS/Safari nur solange noch nichts eingegeben wurde. MacOS noch nicht geprüft. Vergl. Screenreader-Test: http://3needs.org/en/testing/code/labelling-issues.html#placeholdertest

Der accName algorithm https://www.w3.org/TR/accname-1.1/ sieht placeholdernach wie vor nicht vor. Bugzilla zeigt eine Diskussion über Für und Wider der standardkonformen Umsetzung im Browser https://bugzilla.mozilla.org/show_bug.cgi?id=1480831

Sollen wir placeholderfür 1.3.1h akzeptieren, weil praktisch überwiegend gut unterstützt (es bleibt dabei ein Fehler von 3.3.2a Beschriftungen von Formularelementen, nur placeholderals sichtbares Label zu nutzen)?

[MarcHaunschild]

Als Außenstehender eine Meinung dazu: für die programmatische Ermittelbarkeit würde ich nur akzeptieren, was laut Spezifikation in die Berechnung des accessible Names einfließt und ein Inhalt im accName ist dann eben auch ausreichend, um den Prüfschritt zu erfüllen. Soll-Bestimmungen finde ich persönlich nicht hilfreich.

[johannesFischer84]

Eigentlich könnte es ein Fehler beim WCAG-Kriterium 1.3.1 nur in den Sonderfällen (Eingabefeld plus Absenden-Schalter, kombinierte Eingabefelder) sein. Denn wenn z. B. bei einem Vorname-Eingabefeld nur ein Platzhalter vorhanden ist, wird 3.3.2 mit Fehler bewertet und bei 1.3.1 würde ich es als nicht anwendbar sehen, weil es keine Beschriftung gibt, die verknüpft sein könnte.

Nur in den Sonderfällen müssen Beschriftungen nach 3.3.2 nicht extra (sichtbar) vorhanden sein. Ob man da placeholder akzeptiert, da bin ich zwiegespalten. Hier scheinen sich sogar die W3C-Spezifikationen zu widersprechen. Die Accessible Name Computation akzeptiert das Attribut nicht, wie du sagst. Dagegen die HTML Accessibility API Mappings (input-Element) erlauben die Verwendung des Attributs. Ich sehe es als Grau-Bereich, Akzeptieren wäre ok, tendenziell bin ich aber eher nicht dafür.

[MarcHaunschild]

Soll-Bestimmungen finde ich persönlich nicht hilfreich.

Ausnahme: von mehreren validen Optionen wird die beste als Soll-Option benannt (also ein Label-Element soll allen anderen Möglichkeiten der Beschriftung vorgezogen werden) - wenn sich dies objektiv z.B. durch den besten AT-Support o.ä. belegen lässt. Wobei auch das beim Test keine Rolle spielt. Das wäre eher ein Tipp für Entwickler.

[sweckenmann]

Denn wenn z. B. bei einem Vorname-Eingabefeld nur ein Platzhalter vorhanden ist, wird 3.3.2 mit Fehler bewertet und bei 1.3.1 würde ich es als nicht anwendbar sehen, weil es keine Beschriftung gibt, die verknüpft sein könnte.

Ich sehe das etwas anders. Wenn wir placeholdergrundsätzlich nicht akzeptieren, dann würde ich auch 1.3.1 als nicht konform sehen, denn es ist keine programmatisch ermittelbare Beschriftung vorhanden. Anwendbar ist der Prüfschritt ja, denn es gibt ein Formularfeld.

Ich denke, es wäre hilfreich in der Diskussion zu unterscheiden:

1. Sonderfall Suche-Formular: Reicht placeholder als sichtbare Beschriftung (Bedingung beschrifteter Button)? / als programmatisch ermittelbare Beschriftung?
2. Alle anderen Formulare?

Tendiere zu: Zu 1. Suche: Bei einem Suche-Formular mit beschrifteten Button ("Suche" o.ä.) würde ich sagen 3.3.2 erfüllt, 1.3.1h nicht erfüllt weil im accName algorithm nicht vorgesehen. Orientierung an https://www.w3.org/TR/accname-1.1/ d.h. (versteckteslabeloder aria-label oder title ist ok.)

Zu 2. Formulare grundsätzlich: 3.3.2 und 1.3.1h nicht erfüllt. (sichtbares verknüpftes label oder sichtbare Beschriftung mit aria-labelledby verknüpft ist ok).

[direiter]

Meiner Meinung nach sollte ein Placeholder Text grundsätzlich nicht als Beschriftung für 3.3.2 und 1.3.1 ausreichen. Jedes Eingabefeld benötigt eine sichtbare und eine programmatisch ermittelbare Beschriftung, egal in welchem Zustand es sich befindet. Manche Frameworks realisieren Beschriftungen mittels Placeholder und die Beschriftung „wandert“ über oder unter das Eingabefeld sobald ein Inhalt existiert. Das hat einen Grund den man unbedingt berücksichtigen sollte: Der Placeholder verschwindet in dem Moment, wenn ein Inhalt vorliegt! Ein Nutzer, der Änderungen am Formular vornehmen muss, hat nun weder eine sichtbare, noch eine programmatisch ermittelbare Beschriftung.

Man darf hierbei nicht nur das leere Formular betrachten sondern muss auch berücksichtigen, dass Formulare befüllt sein können. Ob das nun per Tastatureingabe oder aus einer Datenbank geschieht, sollte hierbei keine Rolle spielen. Es ist ja durchaus möglich, dass ich am Ende eines Formulars nochmal ganz nach oben gehe, um alle Eingaben zu überprüfen. Und genau in diesem Fall fehlen die Überschriften.

[MarcHaunschild]

Meiner Meinung nach sollte ein Placeholder Text grundsätzlich nicht als Beschriftung für 3.3.2 und 1.3.1 ausreichen. Jedes Eingabefeld benötigt eine sichtbare und eine programmatisch ermittelbare Beschriftung, egal in welchem Zustand es sich befindet.

Richtig.

Manche Frameworks realisieren Beschriftungen mittels Placeholder und die Beschriftung „wandert“ über oder unter das Eingabefeld sobald ein Inhalt existiert.

Das wäre Unsinn. Welches Framework macht das denn so? Ich würde das selber mit JS und CSS machen, aber das label dafür verwenden.

Eine Technik, um das placeholder zu verschieben und zu erhalten wenn das Feld befolgt wird, ist ungleich schwieriger und dazu sinnfrei. Ich hoffe, dass das niemand tut

[stefanFarnetani]

@direiter @MarcHaunschild
Ich vermute gemeint sind sogenannter flaotling labels. Diese werden z.B. bei Google Material Design verwendet. Technisch wird dabei tatsächlich wird dabei das label verschoben werden. Optisch sieht es aus als ob der Placeholder verschoben wird. https://material-ui.com/components/text-fields/

[johannesFischer84]

@sweckenmann

Ich sehe das etwas anders. Wenn wir placeholder grundsätzlich nicht akzeptieren, dann würde ich auch 1.3.1 als nicht konform sehen, denn es ist keine programmatisch ermittelbare Beschriftung vorhanden. Anwendbar ist der Prüfschritt ja, denn es gibt ein Formularfeld.

Das WCAG-Kriterium 1.3.1 sagt aus, dass Information, die optisch verfügbar ist, auch programmatisch verfügbar sein muss. Die Anwendbarkeit sehe ich bei Formularfeldern ohne Beschriftung nicht unbedingt. Ein Formularfeld ist vorhanden, dann muss das Formularfeld als input enthalten sein. Aber eine Beschriftung ist nicht vorhanden, also kann auch nicht gefordert sein, dass sie z. B. als label semantisch verfügbar ist. Es sei denn, man interpretiert den placeholder als sichtbare Beschriftung. Weil dieser aber bei Eingabe verschwindet, würde ich ihn nicht als Beschriftung interpretieren. Ich bin nicht grundsätzlich dagegen, 1.3.1 als anwendbar zu betrachten, tendiere aber eher zu nicht anwendbar.

@direiter

Meiner Meinung nach sollte ein Placeholder Text grundsätzlich nicht als Beschriftung für 3.3.2 und 1.3.1 ausreichen. Jedes Eingabefeld benötigt eine sichtbare und eine programmatisch ermittelbare Beschriftung, egal in welchem Zustand es sich befindet.

Grundsätzlich eine Beschriftung für jedes Eingabefeld finde ich sinnvoll. Aber die WCAG lässt beim Sonderfall Eingabefeld plus Absenden-Schalter eine Ausnahme zu. Siehe WCAG-Technik H65, dort wird nur für Screenreader z. B. ein title-Attribut gefordert, weil eben ein Platzhalter bzw. eine Vorbelegung für Screenreader nicht ausreicht. Man kann also hier keine Beschriftung einfordern, nur empfehlen.

[johannesFischer84]

Zu 2. Formulare grundsätzlich: 3.3.2 und 1.3.1h nicht erfüllt. (sichtbares verknüpftes label oder sichtbare Beschriftung mit aria-labelledby verknüpft ist ok).

Hier stimme ich zu.

[MarcHaunschild]

@sweckenmann

Ich sehe das etwas anders. Wenn wir placeholder grundsätzlich nicht akzeptieren, dann würde ich auch 1.3.1 als nicht konform sehen, denn es ist keine programmatisch ermittelbare Beschriftung vorhanden. Anwendbar ist der Prüfschritt ja, denn es gibt ein Formularfeld.

Das WCAG-Kriterium 1.3.1 sagt aus, dass Information, die optisch verfügbar ist, auch programmatisch verfügbar sein muss. Die Anwendbarkeit sehe ich bei Formularfeldern ohne Beschriftung nicht unbedingt. Ein Formularfeld ist vorhanden, dann muss das Formularfeld als input enthalten sein. Aber eine Beschriftung ist nicht vorhanden, also kann auch nicht gefordert sein, dass sie z. B. als label semantisch verfügbar ist. Es sei denn, man interpretiert den placeholder als sichtbare Beschriftung. Weil dieser aber bei Eingabe verschwindet, würde ich ihn nicht als Beschriftung interpretieren. Ich bin nicht grundsätzlich dagegen, 1.3.1 als anwendbar zu betrachten, tendiere aber eher zu nicht anwendbar.

Ich hoffe, das hilft noch und es wird nicht zu kleinteilig.

Die Beispiele in der WCAG sind immer sehr eindeutig. Wenn sich Entwickler daran hielten, wäre alles einfacher. ;-)

Als Beispiel für eine gelungene Umsetzung wird dort folgender Code gezeigt:

<input type="text" title="Type search term here"/> <input type="submit" value="Search"/>

Ein leeres Feld, ein Button mit der Aufschrift "Suchen" . Versteht jeder. Screenreader lesen den title, denn der ist Teil des accName. Zu sehen ist allerdings nichts. placeholder dagegen ist zu sehen, aber laut Speck sollte es nicht zu hören sein.

Heißt für mich: leeres Feld und aussagekräftiger title: Success Ein zusätzliches placeholder: macht nichts kaputt, denn es ist sowohl für Sehende, als auch für SR-Nutzer weiterhin verständlich, also auch: Success

placeholder aber kein title: fail

[cstrobbe]

Accessible Name and Description Computation 1.1 erkennt placeholder nicht als "accessible name", weil das auch HTML 5.2 widersprechen würde:

Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the control’s label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control.

Diese Warnung gibt meinen wichtigsten Einwand gegen placeholder als "Label" wieder: Der Text ist nur so lange da, bis der Benutzer etwas eingegeben hat. Deswegen erfüllt ein placeholder weder Prüfschritt 1.3.1h noch 3.3.2a. (Wenn wir bei Kontrast nicht nur den Default-Zustand überprüfen, sondern auch die Hover- und Fokus-Zustände, dann müssten wir bei 1.3.1h und 3.3.2a auch den Zustand überprüfen, wenn der Benutzer schon etwas in das Feld eingegeben hat?)

[detlevhfischer]

@cstrobbe Das sind aber eher Argumente, die alle nicht 1.3.1 betreffen (cognitive, mobility, vision impairments im Sinne von visuellen Nutzern mit Beeinträchtigungen). Bei 1.3.1 geht es aber doch um die programmatische Ermittelbarkeit. In den meisten Browser/Screenreader Combos wird auch nach der Eingabe von Text bei Fokussierung noch der hinterlegte placeholder ausgegeben. Die Unterstützung ist seit meinem letzten Test, wo Edge/Sprachausgabe noch schwächelte, sogar noch besser geworden (siehe http://3needs.org/en/testing/code/labelling-issues.html#placeholdertest ). 3.3.2a ist dagegen klar ein FAIL, wenn es als visuelles Label nur den Placeholder gibt, Ich kann mich aber auch dem Argument anschließen, dass placeholder nicht als programmatisch ermittelbares Label gedacht ist - aber praktisch funktioniert es ja in den meisten Umgebungen.

[cstrobbe]

Aus meiner Sicht fallen Browser bei fehlendem accName auf placeholder zurück aus dem gleichen Grund, dass Screenreader einmal angefangen haben den Wert vom src-Attribut auszugeben wenn bei einem img-Element das alt-Attribut fehlte. Ich will damit nicht behaupten, dass placeholder völlig mit dem src-Attribut vergleichbar wäre, nur das keines von beiden Attributen für Barrierefreiheit gedacht ist.

[mayerhh]

Ich habe einen Vorschlag für die Berücksichtigung von ´placeholder´ bei 9.1.3.1h erstellt: https://github.com/BIK-BITV/BIK-Web-Test/pull/187/files

Das Hauptproblem bei der Sache ist, wie schon oben angemerkt wurde, dass es bezüglich der Verwendung von placeholder widersprüchliche Aussagen beim W3C gibt.

Nach den "HTML Accessibility API Mappings 1.0" vom 17 August 2020 darf placeholder verwendet werden

https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element

Die "Accessible Name and Description Computation 1.1" vom 18 Dezember 2018 erwähnt placeholder nicht.

Das ist vielleicht kein Widerspruch. Den in der Einleitung der HTML Accessibility API Mappings steht:

HTML Accessibility API Mappings defines how user agents map HTML elements and attributes to platform accessibility application programming interfaces (APIs). It leverages and extends the Core Accessibility API Mappings 1.2 and the Accessible Name and Description Computation 1.1 for use with the HTML host language.

In diesem Sinn und weil die Inhalte von placeholdervon praktisch allen Hilfsmitteln ausgegeben werden, sollten wir das akzeptieren. Das gilt aber nur für die programmatische Ermittelbarkeit (9.1.3.1h).

Wenn wir placeholder akzeptieren könnte der Sonderfall für Suchfeld mit nachfolgenden Button bzw. Input gestrichen werden.

[johannesFischer84]

@mayerhh Danke für die Erläuterung.

Das ist vielleicht kein Widerspruch. Den in der Einleitung der HTML Accessibility API Mappings steht:

HTML Accessibility API Mappings defines how user agents map HTML elements and attributes to platform accessibility application programming interfaces (APIs). It leverages and extends the Core Accessibility API Mappings 1.2 and the Accessible Name and Description Computation 1.1 for use with the HTML host language.

Dass die HTML-AAM (API Mappings) die AccName erweitern war mir noch nicht bewusst. Das wäre tatsächlich ein Argument, warum man placeholder als programmatische Verknüpfung akzeptieren könnte, ähnlich dem title (mein Gefühl damit wäre trotzdem nicht so gut, aber darauf kommt es nicht unbedingt an).

Wenn wir placeholder akzeptieren könnte der Sonderfall für Suchfeld mit nachfolgenden Button bzw. Input gestrichen werden.

Das verstehe ich nicht. Man müsste doch weiterhin beschreiben, dass das Eingabefeld keine dauerhaft sichtbare Beschriftung braucht. Außerdem gibt es den Fall, dass nur der Schalter einen Text hat und das Eingabefeld verfügt nicht mal über einen Platzhalter/Vorbelegung. Vielleicht wird auch eine Vorbelegung (value-Attribut) verwendet, die auch nach den HTML Accessibilty API Mappings keine Alternative darstellt. Man könnte aus meiner Sicht nur placeholder in der Sonderfall-Beschreibung als Screenreader-Alternative ergänzen.

[mayerhh]

Es ist ein bisschen unübersichtlich, weil dieser Sonderfall "Suchfeld + Button" in beinah identischer Form bei 9.1.3.1h "Beschriftung programmatisch ermittelbar" UND 9.3.3.2 "Beschriftungen von Formularelementen vorhanden" auftaucht.

Bei 9.1.3.1h bleibt bezüglich der programmatischen Ermittelbarkeit nur noch übrig

Das unbeschriftete Eingabefeld mit Textvorbelegung muss in solchen Fällen entweder ein aussagekräftiges title-Attribut oder ein verstecktes Label haben

Wenn die Textvorbelegung mit placeholder akzeptieren können wir hier schlecht noch ein verstecktes label o.ä. fordern. Für den Fall einer fehlenden Textvorbelegung reicht die allgemeine Beschreibung.

Um 9.3.3.2 soll es hier nicht gehen. Da muss das weiter stehen bleiben, aber das ist eine andere Baustelle.

[johannesFischer84]

Bei 9.1.3.1h bleibt bezüglich der programmatischen Ermittelbarkeit nur noch übrig

Das unbeschriftete Eingabefeld mit Textvorbelegung muss in solchen Fällen entweder ein aussagekräftiges title-Attribut oder ein verstecktes Label haben

Genau, das würde noch übrig bleiben, wobei auch aria-label und dann ggf. placeholder ebenfalls zulässig wäre, ein value-Attribut jedoch nicht. Auf diesen Satz kann man nicht verzichten, denn sonst wäre es ja kein Sonderfall mehr. Außerdem muss man noch in die Situation einführen. Das könnte dann so oder ähnlich lauten:

Wenn ein einfaches Suchformular nur aus einem Eingabefeld und einem Button besteht, ist zwar ggf. kein sichtbares Label nach 9.3.3.2 erforderlich, jedoch muss für Screenreader anderweitig ein Accessible Name verknüpft sein: Das unbeschriftete Eingabefeld muss in solchen Fällen entweder ein aussagekräftiges title-Attribut, ein verknüpftes verstecktes Label, ein aria-label-Attribut oder ein placeholder-Attribut haben. (Ein alleiniges value-Attribut ist nicht zulässig)

[CarstenKaul]

Ich habe einen Vorschlag für die Berücksichtigung von ´placeholder´ bei 9.1.3.1h erstellt: https://github.com/BIK-BITV/BIK-Web-Test/pull/187/files

Das Hauptproblem bei der Sache ist, wie schon oben angemerkt wurde, dass es bezüglich der Verwendung von placeholder widersprüchliche Aussagen beim W3C gibt.

Nach den "HTML Accessibility API Mappings 1.0" vom 17 August 2020 darf placeholder verwendet werden

https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element

Die "Accessible Name and Description Computation 1.1" vom 18 Dezember 2018 erwähnt placeholder nicht.

Das ist vielleicht kein Widerspruch. Den in der Einleitung der HTML Accessibility API Mappings steht:

HTML Accessibility API Mappings defines how user agents map HTML elements and attributes to platform accessibility application programming interfaces (APIs). It leverages and extends the Core Accessibility API Mappings 1.2 and the Accessible Name and Description Computation 1.1 for use with the HTML host language.

In diesem Sinn und weil die Inhalte von placeholdervon praktisch allen Hilfsmitteln ausgegeben werden, sollten wir das akzeptieren. Das gilt aber nur für die programmatische Ermittelbarkeit (9.1.3.1h).

Wenn wir placeholder akzeptieren könnte der Sonderfall für Suchfeld mit nachfolgenden Button bzw. Input gestrichen werden.

Danke an mayerhh und die Vorposter. Meine Tests mit JAWS und NVDA zeigen seit einigen Wochen, dass Placeholder-Texte auch nach dem Ändern/Löschen von beiden Screenreadern weiterhin als Label vorgelesen werden - ohne irgendwelche Aria-Label. Mit der Argumentation von mayerhh würde ich zukünftig auch Placeholder, sofern sie im Praxistest mit Screenreadern Beachtung finden, bei 1.3.1 als erfüllt bewerten.

[cstrobbe]

Ich zitiere die Definition von label

A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.

Das Problem mit dem placeholder ist, dass der Wert für sehende Benutzer nicht persistent ist, und deswegen und deswegen Prüfschritt 9.3.3.2 nicht erfüllt. Dazu kommt, dass manche Benutzer bestimmte Eingabefelder vom ihrem Browser bzw. Hilfsmittel automatisch ausfüllen lassen, und wenn dort mal die falschen Werte eingesetzt werden wird is ohne "echtem" Label schwierig, die Fehler zu korrigieren. (Siehe die WCAG-Diskussion zu SC 3.3.2 und placeholder.) Wenn placeholder nicht ausreicht für SC 3.3.2, wollen wir es dann wirklich als ausreichend betrachten für Prüfschritt 9.1.3.1h?

[detlevhfischer]

Es gibt auf jeden Fall noch die Unterstützungslücke bei iOS/Safari/VoiceOver http://3needs.org/en/testing/code/labelling-issues.html#placeholdertest Habe ich gerade noch einmal auf iOS 14.5.1 und iPadOS 14.5 überprüft. Hier wird nach Eingabe von Text placeholder nicht länger ausgegeben (erst, wenn man den Input wieder komplett gelöscht hat). Falls jemand das auf die Schnelle bei MacOS/Safari/VoiceOver überprüfen kann, wissen wir noch mehr.

[anatom5]

Ich habe noch eine Frage zu diesem Thema: würde ein Placeholder "Suchbegriff eingeben" als zugänglicher Name nicht ausreichen, wenn das <input type="search" placeholder="Suchbegriff eingeben"> in einen Container mit role="search" eingebettet ist und das Inputfeld von einem sichtbaren Suchen-Button (grafisch oder textlich) gefolgt bzw. abgeschlossen wird? Für Screenreader ergibt sich dann doch aus dem Kontext eindeutig, um was es sich hier handelt. Wie seht ihr das?

[johannesFischer84]

@anatom5 Ich sehe diesen Fall nicht anders. Zwar benötigt das <input> aufgrund des Sonderfalls Eingabefeld + Schalter keine sichtbare Beschriftung. Aber ein Accessible Name ist erforderlich. Und da ist es eben weiterhin eine Grauzone, ob man das placeholder-Attribut als Accessible Name anerkennt oder nicht.