Verwegene Legenden, vermaledeite Labels und ein Herz für <button>

Nicht nur der Form(s) halber: zuerst ein Hinweis in Sachen “Geiz ist ungeil”. EfA zeigt sich mal wieder alles andere als geizig in der Abteilung Open Knowhow. Mit der neuen Serie Reine Formsache wird in gewohnt solider, kreativer und aktueller Weise der Stand der Dinge in Sachen Formulare zum Besten gegeben. Deshalb zuerst eine ortsübliche Etikette: Lesebefehl!

Im Access-Blog kann man seine Meinung äußern. Ich äußere mich an dieser Stelle, damit ich nicht schon alleine wegen der Zeichenmenge in Datenmüllverbreitungsverdacht gerate. Einige Punkte kann ich somit etwas ausführlicher besprechen.

<legend> oder Überschriften?

Zur fragwürdigen Gruppierung mit verschachtelten fieldsets heißt es:

Wenn Ihr Formular in einer ansonsten mit Überschriften strukturierten (Text-)Seite steht kann es durchaus sinnvoll sein, auf den Einsatz von Fieldset und Legend ganz zu verzichten und dem Formular stattdessen eine eigene Überschrift (H1-6) zu geben.

Für die Lesefaulen: Hintergrund dieser Empfehlung ist die Tatsache, dass Screenreader vor jedem (!) Kontrollfeld, dessen umgebendes <fieldset> mit <legend> versehen wurde, den Inhalt dieser Legende vorlesen.

Frage: Ist das ein Bug oder ein Feature?
Antwort: Wohl eher ein Bug von Screenreadern, denn auch als Scanner Sehender liest man sich vor dem Inneren Ohr nicht jedesmal den Inhalt einer legend vor, ehe man ein Kontrollfeld bedient. Und für einen blinden Nutzer reicht es eigentlich auch aus, wenn er den Anfang und das Ende eines fieldsets vermittelt bekommt. Im visuellen Rendering ist das zu Beginn der Text, am Ende meist die untere Kante eines Farbfeldes oder eine Linie. Bei nicht-visuellen Ausgabegeräten sollte also am Anfang der Text der Legende und nur am Ende ein Ende Text der Legende ausgegeben werden.

Hättewärewenn, deshalb bleibt es bei der EfA-Empfehlung: im Zweifelsfall den Nutzer im Auge behalten und mit ein bisschen Mehraufwand bevorteilen. Zu diesen gehört in diesem Zusammenhang übrigens auch der Webdesigner. Denn legends sind schlecht zu handeln, vor allem wenn sie eine gewisse Länge überschreiten. Hier helfen Überschriften ebenfalls. Sie sind frei editierbar, frei gestaltbar und auch in assistiven Technologien navigierbar.

Implizite und explizite Labels

Die EfA-Labortests haben etwas bestätigt, was schon in der früheren Version der Serie zum Besten gegeben werden musste. Wer Kontrollelemente in Formularen auszeichnet, wird nicht nur auf Linearisierung achten müssen, sondern auch in Zukunft die beteiligten Elemente verknüpfen müssen. Mit den Attributen for und id werden Labels und Kontrollfelder einander zugeordnet. Es gibt aber auch Verwendungen von HTML, deren beschreibende Funktion auch inhaltliche Beziehungen ausdrücken können. Implizite Labels gehören dazu. Implizit bedeutet: Wenn man ein Kontrollfeld mit <label> umklammert, impliziert dies die Aussage: “Kontrollfeld X ist Teil des Vorgangs, den der Labeltext beschreibt”. Genau diese Beziehung wird durch die Attribute for und id ausgedrückt. Viele semantisch denkende Webentwickler sind der Ansicht, dass eine angemessene Interpretation der implizierten Logik durch Screenreader eine Menge Code ersparen könnte. Damit sind nicht nur die besagten Attribute gemeint, sondern bei professionellem Einsatz von CSS auch die häufigen br/echmittel oder umgebende divs, ps oder was sonst noch so in den Weiten des Netzes umherschwirrt.

Frage: Ist das ein Bug oder ein Feature?
Antwort: “Ein Bug“, hören Sie sich vermutlich sagen. Mit ein wenig Einfühlung lassen sich die Anforderungen an einen Screenreader nachvollziehen. Ein Allerweltsbeispiel:

<label>Vorname <input type="text usw. /></label>

Wenn wir versuchen, diesen Vorgang nachzuvollziehen, müssen wir auf jegliche Formen von Intuition, Scanning, Diagonallesen und dergleichen verzichten. Denn ein Screenreader ist eine Maschine, wird auch immer eine bleiben und kann sich keiner geistigen, intellektuellen oder emotionalen Talente bedienen. Für ihn ist folgende logische Interperetationskette zwingend: Mit dem öffnenden Label müsste eine Abfrage einsetzen, die zur Identifikation eines impliziten Labels etwa so vor sich gehen müsste:

1. Zuerst kontrolliert er: Gibt es ein for-Attribut oder nicht?
2. Falls nicht, sollte der Screenreader das Ende des Labels suchen.
3. Wenn er es findet, müsste die Frage: “Befindet sich vor dem schließenden Label-Tag ein Kontrollelement?” beantwortet werden.
4. Ist dies der Fall, kann der Screenreader davon ausgehen, dass es sich um ein implizites Label handelt, das die Zusammengehörigkeit dieser Elemente ausdrückt.
5. Jetzt kann der Screenreader den Labeltext weiterlesen.

Klingt vordergründig erst einmal unaufwändig. In dieser logischen Kette sind aber alle sinnvollen Alternativen nicht genannt. Ebensowenig die Abfragen, die notwendig sind, um eventuelle Fehler im HTML-Code zu tolerieren und auf der Basis von Wahrscheinlichkeiten die oben genannte Eindeutigkeit zu errechnen, obwohl sie semantisch gar nicht existiert. Zu dieser Evaluation gehören beispielsweise folgende Möglichkeiten:

• Gehört das schließende Label vielleicht sogar zu einem Kontrollvorgang, der aus Versehen nicht geschlossen wurde (Validität)
• Entstehen im (eventuellen) Abgleich mit dem (unnötigen) Einsatz von tabindex Konflikte? (Linearität)
• Gibt es weitere Labels, die sich auf dieses Kontrollelement beziehen? (Semantik)
• Alle potentiellen Fehler, die an dieser Stelle vergessen wurden. (Entwicklerdefizite)

Wollte und sollte ein Screenreader alle diese Eventualitäten abfangen, benötigte er neben der geräteinternen Leitungsfähigkeit in erster Linie ein sehr starkes Betriebssystem, um alle diese Vorgänge (der ja nur einer unter vielen ist), zu bewältigen. Hättewärewenn, also bleibt es vorerst bei for und id.

Ein Herz für <button>

Kommen wir nun zum eigentlichen Anliegen dieses Artikels: das <button>-Element. Oops, schon wieder 6000 Zeichen? Naja, dann gibt es eben erneuten Lesebefehl bei EfA und eine Vertröstung auf einen in Kürze erscheinenden Artikel zu diesem formidablen Wegbegleiter für Webentwickler.