zugängliche Formularelemente in einer Tabelle
Matthias Apsel
- barrierefreiheit
Hallo alle,
ich habe eine Tabelle mit Formularelementen in den Zeilen, die für Sehende durch die Spaltenüberschriften hinreichend beschrieben sind und deshalb kein Label haben.
Wie zeichnet man ein solches Formular für Nutzer assistiver Technologien korrekt und vor allem zugänglich aus?
Bis demnächst
Matthias
ich habe eine Tabelle mit Formularelementen in den Zeilen, die für Sehende durch die Spaltenüberschriften hinreichend beschrieben sind und deshalb kein Label haben.
Wie zeichnet man ein solches Formular für Nutzer assistiver Technologien korrekt und vor allem zugänglich aus?
Was auch immer Du in dem Fall versuchst wird wohl zu einer extrem langen Bearbeitungszeit führen. Entweder sorgst Du dafür, dass der Benutzer umfassend informiert wird, damit er genau orientiert ist (Welche Spalte welcher Zeile, bisheriger Wert, erlaubter Input, nochmaliges Vorlesen nach der Eingabe...) oder aber Du baust ähnlich wie bei der aus Tabellenkalulationen bekannten „Datenmaske“ ein Bearbeitungsformular für genau einen Datensatz - dieses dann mit Labels.
Hallo Raketenschnellschießer,
Naja, eine Tabelle wird ja von assistiver Technologie auch ohne weitere Handstände richtig vorgelesen. Und es ist auch nicht in jeder Zelle ein Formularelement.
Bis demnächst
Matthias
Lieber Matthias,
Naja, eine Tabelle wird ja von assistiver Technologie auch ohne weitere Handstände richtig vorgelesen. Und es ist auch nicht in jeder Zelle ein Formularelement.
da stellt sich mir jetzt die Frage, was denn nun das eigentliche Problem sein soll. Zwei Fälle erkenne ich in Deinen Worten:
Was spricht denn dagegen, grundsätzlich um jedes Eingabefeld ein <label>
zu schnüren?
Liebe Grüße
Felix Riesterer
Hallo Felix Riesterer,
Zwei Fälle erkenne ich in Deinen Worten:
- Tabellenzellen sind eindeutig durch Spaltenbeschriftungen benannt und von daher jedes Eingabefeld in seiner Bedeutung klar.
- Da nur in manchen Zellen ein Eingabefeld vorhanden ist, in anderen aber Inhalt, ist bei den Eingabefeldern eben nicht eindeutig, wofür sie verwendet werden sollen.
Ich denke schon. Stell dir eine zweispaltige Tabelle mit den Spalten Name und Anzahl vor. In der Spalte Anzahl steht ein input. In Wirklichkeit ist es etwas komplexer aber in jeder Spalte steht entweder ein input-Element oder Text.
Was spricht denn dagegen, grundsätzlich um jedes Eingabefeld ein
<label>
zu schnüren?
Bis demnächst
Matthias
Lieber Matthias,
Stell dir eine zweispaltige Tabelle mit den Spalten Name und Anzahl vor. In der Spalte Anzahl steht ein input. In Wirklichkeit ist es etwas komplexer aber in jeder Spalte steht entweder ein input-Element oder Text.
ich sehe das so: Eine Tabellenüberschrift (<th>
) beschreibt einen Inhalt, nicht aber den Sinn eines Eingabe-Elements. Im Falle von "Anzahl" mag das ja noch einigermaßen hinhauen, weil eine Anzahl keine Einheit benötigt (die wäre wohl "Stück" oder "Exemplar"). Aber so ganz prinzipiell ist ein Eingabefeld kein Inhalt.
Was spricht denn dagegen, grundsätzlich um jedes Eingabefeld ein
<label>
zu schnüren?
- die richtige Beschriftung zu bestimmen
- der Aufwand, das label für Sehende auszublenden
Ach so. Schauen wir mal.
"Die richtige Beschriftung zu bestimmen" ist ein Problem? Eines, das durch die Spaltenüberschrift hinreichend abgedeckt werden kann? Das klingt für mich nicht nachvollziehbar logisch. Dazu kommt noch, dass ein solches Formularelement vermutlich serverseitig ausgewertet werden soll. Welchen Kontext versteht denn der Server? Der hat doch irgendetwas, das er mit der Anzahl in Verbindung bringen soll! Warum kann er dann beim Erstellen des Formulars keine sinnvolle Beschriftung leisten?
"Der Aufwand, das label für Sehende auszublenden" sollte ganz schnell erledigt sein, wenn Du das Label nicht um das Eingabefeld herum gruppierst, sondern beide als Geschwisterknoten mit for
- und id
-Attributen verknüpfst. Dann kann CSS das ganz schnell unsichtbar machen.
Liebe Grüße
Felix Riesterer
Hallo Felix Riesterer,
"Die richtige Beschriftung zu bestimmen" ist ein Problem? Eines, das durch die Spaltenüberschrift hinreichend abgedeckt werden kann? Das klingt für mich nicht nachvollziehbar logisch. Dazu kommt noch, dass ein solches Formularelement vermutlich serverseitig ausgewertet werden soll. Welchen Kontext versteht denn der Server? Der hat doch irgendetwas, das er mit der Anzahl in Verbindung bringen soll! Warum kann er dann beim Erstellen des Formulars keine sinnvolle Beschriftung leisten?
name="Anzahl[<?=$k?>]"
wird generiert, das als Beschriftung wäre mir ein bisschen zu blöd, also <label>Anzahl für Bezeichnung</label>
scheint mir sinnvoll zu sein.
Ich muss noch ein bisschen drüber nachdenken, aber so werde ich das wahrscheinlich umsetzen, falls nicht noch ein anderer Vorschlag (idealerweise Expertinnen für Barrierefreiheit) kommt. Ich will ja auch nicht Informationen liefern, die letzlich nur störend wirken, weil die Position in der Tabellenspalte schon ausreichend ist.
"Der Aufwand, das label für Sehende auszublenden" sollte ganz schnell erledigt sein, wenn Du das Label nicht um das Eingabefeld herum gruppierst, sondern beide als Geschwisterknoten mit
for
- undid
-Attributen verknüpfst. Dann kann CSS das ganz schnell unsichtbar machen.
Ja, das war eher eine rhetorische Bemerkung 😉
Bis demnächst
Matthias
Hallo Matthias,
so spontan fällt mir da aria-labelledby
ein.
Gruß
Jürgen
Hallo JürgenB,
so spontan fällt mir da
aria-labelledby
ein.
Ja, das ist mir auch eingefallen. Die Frage ist aber, ob es notwendig ist.
Bis demnächst
Matthias
Hallo Matthias,
ich habe keinen Screenreader, um das zu testen; aber kann man den th-Zellen nicht eine ID geben und alle Eingabefelder der Spalte mit "aria-labelledby" darauf verweisen lassen?
Rolf
Hallo Rolf B,
ich habe keinen Screenreader, um das zu testen; aber kann man den th-Zellen nicht eine ID geben und alle Eingabefelder der Spalte mit "aria-labelledby" darauf verweisen lassen?
Ja, das geht bestimmt. Meine Frage ist nur, ob das nicht vielleicht eine überflüssige Information ist, weil das passende th-Element als Info schon ausreichend ist.
Bis demnächst
Matthias
Hallo Matthias,
meinst Du, dass ein Screenreader automatisch das th Element über der Spalte dem Eingabefeld weiter unten zuordnet und es beim Erreichen des Eingabefeldes vorliest? Hm. Keine Ahnung. Man sollte sich dann auch fragen, wie er mit Zeilenüberschriften umgeht (th Elemente zu Beginn der Row). Aber das ist für mich reiner Spekulatius.
Rolf
Hallo Rolf B,
meinst Du, dass ein Screenreader automatisch das th Element über der Spalte dem Eingabefeld weiter unten zuordnet und es beim Erreichen des Eingabefeldes vorliest?
JAWS 2021 tut das so (grade getestet): "Tabelle, Spalte 6, Reihe 6, Hauptregion, Überschrift, Wählfeld …"
Bis demnächst
Matthias
Hallo Matthias,
meinst Du, dass ein Screenreader automatisch das th Element über der Spalte dem Eingabefeld weiter unten zuordnet und es beim Erreichen des Eingabefeldes vorliest?
JAWS 2021 tut das so (grade getestet): "Tabelle, Spalte 6, Reihe 6, Hauptregion, Überschrift, Wählfeld …"
das ist zwar auf den ersten Blick gut - aber ich glaube, mich würde so viel Information auf einmal überfordern.
Ich weiß, dass Menschen mit eingeschränktem Sehvermögen meistens die auditive Wahrnehmung sehr viel stärker trainieren; vielleicht kommen die damit klar. Aber bei mir ist es so: Wenn die Informationsdichte, die ich mit dem Gehör verarbeiten soll, ausreichend hoch ist, kann ich sie leichter bewältigen, wenn das Gesagte zusätzlich visualisiert wird. Diese Möglichkeit fällt aber hier weg.
Ich weiß also echt nicht, wieviel Information man diesen Menschen "am Stück" durch Vorlesen zumuten kann.
Live long and pros healthy,
Martin
Hallo Der Martin,
Ich weiß also echt nicht, wieviel Information man diesen Menschen "am Stück" durch Vorlesen zumuten kann.
Genau das ist auch mein Problem.
JAWS 2021 tut das so (grade getestet): "Tabelle, Spalte 6, Reihe 6, Hauptregion, Überschrift, Wählfeld …"
Und da ist noch kein label oder aria-labelledby dabei.
Bis demnächst
Matthias