Nö, der Seitenautor sollte damit gar nichts zu tun haben. Der pflegt seinen Inhalt genau einmal ein.
Jagut, dann könnte man dem Seitenautor ein Werkzeug geben, in dem er die Daten einpfegen kann, um dann das HTML generieren zu lassen. Wenn so ein Werkzeug aber noch nicht benutzt wird, dann würde ich mir zwei mal überlegen, wie oft ich das brauchen würde und ob ich mir nicht lieber die Mühe mache redundantes HTML per Hand zu schreiben.
Du willst aber nicht den Inhalt doppelt (als Tabelle und als Beschreibungsliste) im DOM haben, oder?
Ne stimmt, eigentlich nicht. Ich dachte zuerst, dass es kaum eine Rolle spielt, wenn immer nur eine Alternative im Accessibility-Tree aktiv ist. Beim genaueren drüber Nachdenken stimmt das aber nicht, das würde einen Rattenschwanz mit sich ziehen, den ich erst nicht bedacht habe. Bspw. könnten Anker in den jeweiligen Teilen nicht mehr die selber IDs haben, und damit scheidet das dann auch schon aus. Die Navigation würde dadruch kaputt gehen. Dann doch besser eine Variante auf dem Server vorrrendern und die Alternative per JavaScript aktiveren, wenn Bedarf besteht.
Oder man lässt die Tabelle ganz weg und man layoutet die Definitionslisten bei ausreichend großem Viewport wie eine Tabelle.
Kann man so machen. Dann hat man natürlich die Beschriftungen zigfach im HTML-Code. Aber genau das willst du ja, wenn sie kopierbar sein sollen.
Ja, das ist m.M.n. nicht optional. Ein Benutzer kann erwarten, dass sich Text markieren lässt, erfüllt sich die Erwartung nicht, ist das schlechte UX.