(TABELLEN) Für Formulare sinnvoll?

[molily]

Hallo, Christian,

Erst einmal danke, dass Du mich in meiner Auffassung bestärkst, aber ich habe immer so Reflexe, wenn ich auch nur an Tabllen denke, da frage ich sicherheitshalber noch mal nach. ;-)

Hm, »undogmatisch« argumentiert wäre selbst das Gegenüberstellen von Überschrift und deren »Kindabsätze« in einer Tabelle legitim, oder bei der anderen »Strukturmetainformation«. Zwei Beispiele:

----------------------------------------------------------------
Überschrift |  Kindabsatz     Text Text Text Text Text Text Text
            |  Text Text Text Text Text Text Text Text Text Text
            |  Text Text Text Text Text Text Text Text Text Text
            |  Text Text Text Text Text Text Text Kindabsatzende
----------------------------------------------------------------
... weitere Zeilen/Paare ...
----------------------------------------------------------------

Weiterhin:

----------------------------------------------------------------------------
Absatz    Text Text Text Text Text Text  |   Zusammenfassung des Absatzes
Text Text Text Text Text Text Text Text  |   Zusammenfassung Zusammenfassung
Text Text Text Text Text Text Text Text  |   Zusammenfassung Zusammenfassung
Text Text Text Text Text Text Abstzende  |   Ende der Absatzzusammenfassung
----------------------------------------------------------------------------
... weitere Zeilen/Paare ...
----------------------------------------------------------------------------

Natürlich müsste eine sequenzartige Textstruktur bestehen, das heißt das Dokument besteht zumindest teilweise aus gleichförmigen in ihrer Struktur gleichen Elementen (aufzählungs- bzw. listenartig), sodass eine gewöhnliche Tabelle mit mehreren Zeilen möglich ist.
Womöglich wäre eine Definitionsliste (dl-Element) beim ersten Beispiel optimal, aber eine Tabelle wäre nicht strenggenommen nicht ein Verstoß gegen die Vorgabe, Tabellen nur für tabellarische Daten zu benutzen.

Von der Dokumentstruktur her gesehen ist das p in folgendem Beispiel ein Kind von h2:
  <h2>murks</h2>
  <p>murks</p>
(»Gott wirf XHTML 2 vom Himmel!«)

Deshalb wird auch mit einer scheinbar linearen Struktur eine Zu- und Unterordnung vorgenommen, eine Tabelle, welche explizit mit ihrem tr-Element einen Datensatz kennzeichnet und in Datensatztitel und Datensatzinhalt aufteilt, ist nicht unbedingt nötig, hätte aber mehr semantisschen Wert. Ein paar Beispiele:

Die Struktur einer Tabelle wäre:

<datensatzliste>
 [Definition der Semantik der datensatz-Kindelemente]
  (<datensatz>
    <datensatzname>...</datensatzname>
    (<[beliebiges Element]>...</[beliebiges Element]>){1,}
  </datensatz>){1,}
</datensatzliste>

Die Struktur einer Definitionsliste:

<datensatzliste>
  (<datensatzname>...</datensatzname>
  <datensatzinhalt>...</datensatzinhalt>){1,}
</datensatzliste>

Eine hX-Struktur:

(<datensatzname>...</datensatzname>
(<datensatzinhalt>...</datensatzinhalt>){1,}){1,}

Erneut: »Gott wirf XHTML 2 (mit den besseren Möglichkeiten zur Dokumentstrukturierung) vom Himmel!« Die schon jetzt mögliche ideelle Verschachtelung habe ich weggekürzt, zugegeben. Darum geht es hier aber nicht, ich gehe von einer

Der Vorteil der Tabelle liegt auf der Hand - denn über die th-Elemente lassen sich sogar quasi neue Elementnamen einführen (um in der Veranschaulichung zu bleiben) beziehungsweise die Bedeutung der Elemente determinieren.

Wenn ich folglich eine Datenstruktur in XML abbilden würde, würde ich ohne Zweifel die erste, semantisch vollwertigere Struktur benutzen. Warum die Semantik verschenken, wenn diese Daten in (X)HTML transformiert werden?

Wenn du die Zugangsrichtlinien 5.*,

Bei 5.1 habe ich so meine Probleme, müssen die Spaltenüberschriften in dem Fall sein?

IMHO: nein. Und zwar aus dem Grund, weil es für das Verständnis nicht nötig ist und die doppelte Verknüpfung zwischen th und td aufgrund desselben tr-Vaters und zwischen label/for und input/id eindeutig genug ist. Das label-Element gibt genug Metainformation über den Spaltenkopfinhalt, sodass ein zusätzliches th als Spaltenüberschrift (scope="col") darüber nicht nötig ist.

Für den Tabellenlinearisierer eines Screenreaders halte ich die zusätzliche Ausgabe der kompletten Headers für unnötig... Man denke an:
  Eingabefeldbeschreibung Doppelpunkt  {label-Inhalt}
  Formulareingabefeld Doppelpunkt Texteingabefeld [Möglichkeit, in den Formularmodus zu wechseln]
Das ist auch nicht Sinn der Sache. Inwieweit label von den Browsern und Zusatzprogrammen momentan überhaupt unterstützt wird, sodass ein Browser aus den labels unabhängig vom umgebenden Markup das Formular in einer bestimmten Weise ausgeben kann, ist mir unbekannt.

Im Grunde genommen sind momentan Tabellen unnötig, da die Zuordnung dank label schon explizit besteht und somit die tabellarische Darstellung nicht mit Markup gelöst werden muss (aber kann).
Ich tippe darauf, dass XForms die Zugänglichkeit sowieso grundlegend vereinfachen wird...

Oder reicht es nicht, wenn ich <th> für die Zeilen mit dem Label verwende?

IMHO ja.

Grüße,
Mathias