nicht angemeldet borisbaer
TS
borisbaer
Der Martin
TS
Gunnar Bittersmann
TS
Rolf B
Hallo zusammen,
ich habe eine Tabelle mit verschiedenen Funktionen erstellt (siehe hier), musste diese jedoch etwas umständlich organisieren, weil eine Tabelle ja nicht mehrere forms enthalten darf.
Momentan sind diese Funktionen enthalten:
Für das Sortieren bei kleinem Viewport sowie für die Suchfunktion habe ich jeweils ein separates Formular, bevor die eigentliche Tabelle beginnt.
Für alle anderen Funktionen habe ich nur ein Formular um die Tabelle herum.
Würde ich alle Funktionen in einem Formular vereinen wollen, wäre JavaScript unabdingbar.
Bei deaktiviertem JavaScript kann ich die Tabelle momentan trotzdem mit allen Funktionen verwenden. Das Einzige, was da aktuell bei ausgeschaltetem JavaScript passiert, ist, dass nach dem Erstellen eines neuen Eintrags die Sortierung zurückgesetzt wird.
Nicht ideal, aber immerhin brauche ich nichts zwangsweise JS.
Bei dem Formular, das die Tabelle einschließt, muss ich beim Absenden jedoch recht viele Bedingungen verwenden, damit das geschieht, was geschehen soll, z.B.:
Matthias Scharwiesif ( isset( $_POST['sort'] ) && !isset( $_POST['reset'] ) && !isset( $_POST['create'] ) )
Deshalb wollte ich hier mal nachfragen, welche Möglichkeiten es denn gibt, POST-Daten, die ich im Normalfall einfach durch separate Formulare trennen würde (was ich hier aber nicht kann, da Tabellen nicht mehrere forms enthalten können), stattdessen zu organisieren.
Ich hoffe, mein Anliegen ist einigermaßen klar geworden.
Grüße
Boris
Rolf B
Deshalb wollte ich hier mal nachfragen, welche Möglichkeiten es denn gibt, POST-Daten, die ich im Normalfall einfach durch separate Formulare trennen würde (was ich hier aber nicht kann, da Tabellen nicht mehrere forms enthalten können), stattdessen zu organisieren.
Deshalb wollte ich hier mal nachfragen, welche Möglichkeiten es denn gibt, POST-Daten, die ich im Normalfall einfach durch separate Formulare trennen würde (was ich hier aber nicht kann, da Tabellen nicht mehrere forms enthalten können), stattdessen zu organisieren.
Etwas wie ...
<input name="foo[0]"…>
<input name="bar[0]"…>
<input name="foo[1]"…>
<input name="bar[1]"…>
funktioniert auch dann wunderbar, wenn es mit dem Tabellenkram durchsetzt ist. (Schau Dir $_POST an…) Du kannst aber Deine Daten auch via JS einsammeln und z.B. als JSON-String versenden.
Hello,
wieso sollte man in einer Tabelle nicht mehrere Formulare unterbringen können? Du kannst in jede Zelle eins packen.
Aber vermutlich meinst Du etwas ganz anderes?
Außerdem sollte zumächst geklärt werden, ob nur der aktuelle View (Snapshot) sortiert werden soll, oder die eigentliche Abfrage (dynamische Abfrage) in einer neuen Sortierung ausgeliefert werden soll. Im zweiten Fall kann man dann auch noch über den Aufsetzpunkt (offset) in der Abfrage nachdenken und wie man den in den Sichtbereich bekommt.
Wenn die Abfrage dynamisch neu aufgebaut werden soll, muss man auch bedenken, dass sich zwischen den Abfragezeitpunkten am Datenbestand etwas geändert haben könnte.
Wenn nur der aktuelle View umsortiert werden soll, gibt es hier im Archiv elegante Lösungen mit Javascript.
Ich kann mit dem Tablet jetzt nur nicht komfortabel genug suchen für Dich.
Glück Auf
Tom vom Berg
Hallo Tom,
wieso sollte man in einer Tabelle nicht mehrere Formulare unterbringen können? Du kannst in jede Zelle eins packen.
hier steht ...
A form is not allowed to be a child element of a table, tbody or tr. Attempting to put one there will tend to cause the browser to move the form to it appears after the table (while leaving its contents — table rows, table cells, inputs, etc — behind).
You can have an entire table inside a form. You can have a form inside a table cell. You cannot have part of a table inside a form.
Das heißt, ich kann leider nicht um einen tbody ein form stülpen.
Außerdem sollte zumächst geklärt werden, ob nur der aktuelle View (Snapshot) sortiert werden soll, oder die eigentliche Abfrage (dynamische Abfrage) in einer neuen Sortierung ausgeliefert werden soll. Im zweiten Fall kann man dann auch noch über den Aufsetzpunkt (offset) in der Abfrage nachdenken und wie man den in den Sichtbereich bekommt.
Es wird die ganze Abfrage neu sortiert, d.h. die Seite wird neu aufgebaut, und zwar mit neuer Abfrage. Von Offset weiß ich bisher leider noch nichts. Wozu soll das gut sein?
Wenn die Abfrage dynamisch neu aufgebaut werden soll, muss man auch bedenken, dass sich zwischen den Abfragezeitpunkten am Datenbestand etwas geändert haben könnte.
Das stimmt, aber wo ist das Problem?
Wenn nur der aktuelle View umsortiert werden soll, gibt es hier im Archiv elegante Lösungen mit Javascript.
Ich möchte hier so wenig auf JS angewiesen sein wie möglich.
Grüße
Boris
Hallo,
hier steht ...
A form is not allowed to be a child element of a table, tbody or tr. Attempting to put one there will tend to cause the browser to move the form to it appears after the table (while leaving its contents — table rows, table cells, inputs, etc — behind).
You can have an entire table inside a form. You can have a form inside a table cell. You cannot have part of a table inside a form.
Das heißt, ich kann leider nicht um einen tbody ein form stülpen.
genau, das Formular muss entweder die Tabelle komplett umschließen, oder komplett innerhalb einer Zelle (td oder th) stehen.
Wenn nur der aktuelle View umsortiert werden soll, gibt es hier im Archiv elegante Lösungen mit Javascript.
Ich möchte hier so wenig auf JS angewiesen sein wie möglich.
Das ist okay, ich verfolge denselben Ansatz. Aber gemäßigt: Die Webseite muss auch ohne JS in ihren Grundzügen nutzbar sein. Aber reine Komfortfunktionen (und eine Sortierung zähle ich dazu) dürfen schon mal wegbrechen, wenn JS nicht zur Verfügung steht.
Einen schönen Tag noch
Martin
Hello,
wieso sollte man in einer Tabelle nicht mehrere Formulare unterbringen können? Du kannst in jede Zelle eins packen.
hier steht ...
A form is not allowed to be a child element of a table, tbody or tr. Attempting to put one there will tend to cause the browser to move the form to it appears after the table (while leaving its contents — table rows, table cells, inputs, etc — behind).
You can have an entire table inside a form. You can have a form inside a table cell. You cannot have part of a table inside a form.
Das heißt, ich kann leider nicht um einen tbody ein form stülpen.
Außerdem sollte zumächst geklärt werden, ob nur der aktuelle View (Snapshot) sortiert werden soll, oder die eigentliche Abfrage (dynamische Abfrage) in einer neuen Sortierung ausgeliefert werden soll. Im zweiten Fall kann man dann auch noch über den Aufsetzpunkt (offset) in der Abfrage nachdenken und wie man den in den Sichtbereich bekommt.
Es wird die ganze Abfrage neu sortiert, d.h. die Seite wird neu aufgebaut, und zwar mit neuer Abfrage. Von Offset weiß ich bisher leider noch nichts. Wozu soll das gut sein?
Wenn die Abfrage dynamisch neu aufgebaut werden soll, muss man auch bedenken, dass sich zwischen den Abfragezeitpunkten am Datenbestand etwas geändert haben könnte.
Das stimmt, aber wo ist das Problem?
Wieviele Elemente der Abfrage sollen denn angezeigt werden? Angenommen, deine Datentabelle (Table) hat 4.536 Records (Rows), dann willst Du die bestimmt lieber seitenweise anzeigen lassen und nicht alle 4.536 Datensätze auf einmal ausliefern.
Und dann benötigst du für die Abfrage Offset und Limit (Anzahl der abgefragten DS).
Und wenn Du nun ab einem bestimmten Datensatz in der Anzeige (lass es z. B. den neunten sein), die Abfrage neu sortiert anzeigen lassen willst, dann benötigst Du dessen ID.
Kein Problem, wenn er bei der erneuten Abrage noch da ist. Dumm gelaufen, wenn er inzwischen (durch einen anderen Prozess/User) gelöscht oder relevant geändert wurde.
Dann beginnt die Philosophie für die Gestaltung der Programmlogik.
Das Problem ist also, dass Du die Logik bisher noch nicht fertig entwickelt hast. Dazu schaust Du dir am Besten die Lösungen anderer Seiten an und sagst dann, so oder so nicht will ich das haben.
Anschließend können wir Dir erst wirklich weiterhelfen.
@@TS
Wenn nur der aktuelle View umsortiert werden soll, gibt es hier im Archiv elegante Lösungen mit Javascript.
Wenn Paging im Spiel ist (was es hier ist), dann macht das keinen Sinn. Man will ja nicht die paar aktuell sichtbaren Items neu sortieren, sondern die gesamten Daten.
🖖 Живіть довго і процвітайте
Hello Gunnar,
Wenn nur der aktuelle View umsortiert werden soll, gibt es hier im Archiv elegante Lösungen mit Javascript.
Wenn Paging im Spiel ist (was es hier ist), dann macht das keinen Sinn. Man will ja nicht den die paar aktuell sichtbaren Items neu sortieren, sondern die gesamten Daten.
Herzlichen Glückwunsch zum Hellseherdiplom ;-p
Wenn man mit Filtern arbeitet, kann es durchaus sinnvoll sein, zusätzlich "nur mal eben" den aktuellen Ausschnitt umzusortieren. In größeren Datenbeständen kann das enorm viel Traffic und Zeit einsparen.
Hat allerdings meistens nur Sinn, wenn man das Ausschnittfenster nicht zu klein macht (Anzahl der Zeilen).
Besonders interessant, wenn die DB-Tabelle keinen Index auf der gewünschten Sortierung hat.
Aber ich schrieb ja schon: das ist Philosophie, und nicht Hellseherei.
Glück Auf
Tom vom Berg
Hallo borisbaer,
ich würde ein Form um das ganze Ding drumherumlegen und gut ist.
Submit-Buttons sind Highlander: Es kann zwar mehr als einen geben, aber am Server kommt nur einer an. Deswegen ist
if ( isset( $_POST['sort'] ) && !isset( $_POST['reset'] ) && !isset( $_POST['create'] ) )
meines Erachtens überflüssig. Du bekommst ENTWEDER sort ODER reset ODER apply. Create vielleicht auch mal irgendwann, aber das scheint noch auf Halde zu liegen.
Du solltest aber entweder den reset und sort Buttons für Sortierung und Suche unterschiedliche name-Werte geben, oder ihnen zumindest einen Value hinzufügen, so dass Du apply und reset für Sortierung und Suche unterscheiden kannst.
Und dann musst Du einfach nur von oben nach unten abfragen.
if (isset($_POST['sort'])) {
// Spalten-Header
sortBy($_POST['sort']);
}
else if (isset($_POST['apply']) && $_POST['apply'] == 'sort') {
// Apply-Sort Button
sortBy($_POST['sort'], $_POST['order']);
}
else if (isset($_POST['reset']) && $_POST['reset'] == 'sort') {
// Reset-Sort Button
resetSort();
}
else if (isset($_POST['apply']) && $_POST['apply'] == 'search') {
...
}
else if (isset($_POST['reset']) && $_POST['reset'] == 'search') {
...
}
else if (isset($_POST['create'])) {
...
}
Ein solcher Verteiler ist in einem Form mit vielen Funktionen durchaus okay.
Was Dir auch helfen kann, ist ein spezieller Value in den Tabellentiteln, die einen Sort auslösen. Da steht im Moment name="sort" und value="title", ganz gleich, ob die Tabelle nach dem Titel sortiert ist, und ob das auf- oder absteigend ist. D.h. Du musst Dir im Moment serverseitig merken, welche Sortierung vorliegt. Wenn Du im Value-Attribut bereits codierst, welche Reihenfolge herzustellen ist, brauchst Du das nicht. Im Normalfall würdest Du also in value-Attributen der 4 Spalten die Werte "title.asc", "franchise.asc", "origin.asc" und "year.asc" speichern. Klickt man nun auf den Button für die Titelspalte, sortierst Du nach Titel aufsteigend und speicherst im value-Attribut dieses Buttons nun "titel.desc". D.h. das, was passieren soll, wenn man draufklickt. Bekommst Du nun "sort=titel.desc" geschickt, weißt Du, dass absteigend nach Titel zu sortieren ist, und speicherst dann im value-Attribut wieder "titel.asc".
Rolf
Hello,
ich würde ein Form um das ganze Ding drumherumlegen und gut ist.
Submit-Buttons sind Highlander: Es kann zwar mehr als einen geben, aber am Server kommt nur einer an. Deswegen ist
if ( isset( $_POST['sort'] ) && !isset( $_POST['reset'] ) && !isset( $_POST['create'] ) )meines Erachtens überflüssig.
Das ist nicht überflüssig, sondern falsch, wenn es sich um die Buttons handelt.
Dann kann man gleich if(true == false) hinschreiben ;-p
Eine Möglichkeit gibt es allerdings, dass alle Buttons per POST gleichzeitig ankommen: Das Form wird gehackt.
Daher sollte man dann eher kaskadieren, sodass eben nicht zwei Buttonaktionen gleichzeitig ankommen können. Oder wenn man es ganz paranoid programmieren will, zählt man die angekommenen Aktionsbuttons, und wenn die Anzahl <> 1 ist, stimmt etwas nicht -> Fehlermeldung für fail2ban ins Log schicken.
Bei PHP als Backend geht das am einfachsten, wenn man die Aktionsbuttons (per Namensgebung) in ein Subarray steckt. Dann sollte ein if(is_array($_POST['btn']) && count($_POST['btn']) == 1) zur ersten Kontrolle reichen. Und wenn dann trotzdem kein Button passt, ist das auch ein Fehler fürs Log.
Glück Auf
Tom vom Berg
Hallo Tom,
vielen Dank für den Hinweis bezüglich der Sicherheit. Ich werde mich darum bemühen, solch einen Mechanismus einzubauen!
Grüße
Boris
Hallo Rolf,
ich würde ein Form um das ganze Ding drumherumlegen und gut ist.
so hatte ich es auch am Anfang, aber …
Submit-Buttons sind Highlander: Es kann zwar mehr als einen geben, aber am Server kommt nur einer an.
wenn man z.B. die Enter-Taste zum Bestätigen eines Text-Inputs drückt, anstatt den passenden Submit-Button, dann wird ja immer der erste Submit-Button des Formulars verwendet. Doch da das Formular ganz unten noch einen zweiten Text-Input hat (nämlich zum Erstellen eines neuen Eintrags), wird natürlich beim Drücken der Enter-Taste dort der falsche Submit ausgeführt (nämlich der der Suchfunktion). Ich hoffe, es ist klar, was ich meine.
Deswegen ist
if ( isset( $_POST['sort'] ) && !isset( $_POST['reset'] ) && !isset( $_POST['create'] ) )meines Erachtens überflüssig. Du bekommst ENTWEDER sort ODER reset ODER apply. Create vielleicht auch mal irgendwann, aber das scheint noch auf Halde zu liegen.
Ohne diese Bedingungen funktioniert das Formular bei mir momentan jedoch nicht richtig. Create funktioniert bereits, aber es ist eben nur für den Admin sichtbar. Ich kann es aber gerne für alle sichtbar machen.
Du solltest aber entweder den reset und sort Buttons für Sortierung und Suche unterschiedliche name-Werte geben, oder ihnen zumindest einen Value hinzufügen, so dass Du apply und reset für Sortierung und Suche unterscheiden kannst.
Das werde ich mir noch mal genauer anschauen, danke!
Was Dir auch helfen kann, ist ein spezieller Value in den Tabellentiteln, die einen Sort auslösen. Da steht im Moment name="sort" und value="title", ganz gleich, ob die Tabelle nach dem Titel sortiert ist, und ob das auf- oder absteigend ist. D.h. Du musst Dir im Moment serverseitig merken, welche Sortierung vorliegt. Wenn Du im Value-Attribut bereits codierst, welche Reihenfolge herzustellen ist, brauchst Du das nicht. Im Normalfall würdest Du also in value-Attributen der 4 Spalten die Werte "title.asc", "franchise.asc", "origin.asc" und "year.asc" speichern. Klickt man nun auf den Button für die Titelspalte, sortierst Du nach Titel aufsteigend und speicherst im value-Attribut dieses Buttons nun "titel.desc". D.h. das, was passieren soll, wenn man draufklickt. Bekommst Du nun "sort=titel.desc" geschickt, weißt Du, dass absteigend nach Titel zu sortieren ist, und speicherst dann im value-Attribut wieder "titel.asc".
Speichern ohne serverseitiges Merken? Das ist mir neu. Ich kann natürlich den Buttons diese Values geben, aber da nach einem Klick auf den jeweiligen Button im th die Seite neu aufgebaut wird, erschließt sich mir nicht, wie der Value beim neuen Seitenaufbau übertragen werden soll. Momentan ist die Reihenfolge der Sortierung im th als aria-sort="ascending" bzw. aria-sort="descending" festgelegt.
Grüße
Boris
Hallo borisbaer,
wird natürlich beim Drücken der Enter-Taste dort der falsche Submit ausgeführt (nämlich der der Suchfunktion). Ich hoffe, es ist klar, was ich meine.
Öhm - ja, verdammt.
In dem Fall musst Du den Spieß tatsächlich umdrehen und aus jeder Eingabegruppe ein eigenes Form machen. So, wie Du es gebaut hast.
Eventuell noch feingranularer. Es wurde erwähnt, dass entweder das Form komplett in eine Zelle muss oder die ganze Table ins Form. Das ist richtig, es gibt aber noch eine weitere Möglichkeit: Ein Form kann Form-Elemente haben, die keine Kind-Elemente von ihm sind und irgendwo anders stehen. Dazu gibst Du dem Form eine ID und verweist mit dem form-Attribut derjenigen Elemente darauf, die zum Form dazugehören sollen. Es muss eine id sein, das name-Attribut des Form ist dafür nicht verwendbar.
<form id="sortform" method="post">
<!-- no elements here -->
</form>
<table>
<thead>
<th><button type="submit" name="sort" value="title.asc" form="sortform">Titel</button></th>
...
</thead>
...
</table>
Dieser Button ist Teil des Formulars, auch wenn er kein Kind-Element des Formulars ist.
Vielleicht kannst Du Dich damit besser sortieren.
Rolf
Hallo Rolf,
Eventuell noch feingranularer. Es wurde erwähnt, dass entweder das Form komplett in eine Zelle muss oder die ganze Table ins Form. Das ist richtig, es gibt aber noch eine weitere Möglichkeit: Ein Form kann Form-Elemente haben, die keine Kind-Elemente von ihm sind und irgendwo anders stehen. Dazu gibst Du dem Form eine ID und verweist mit dem form-Attribut derjenigen Elemente darauf, die zum Form dazugehören sollen. Es muss eine id sein, das name-Attribut des Form ist dafür nicht verwendbar.
<form id="sortform" method="post"> <!-- no elements here --> </form> <table> <thead> <th><button type="submit" name="sort" value="title.asc" form="sortform">Titel</button></th> ... </thead> ... </table>Dieser Button ist Teil des Formulars, auch wenn er kein Kind-Element des Formulars ist.
Vielleicht kannst Du Dich damit besser sortieren.
nach langer Zeit konnte ich mich dazu durchringen, die ganze Organisation der POST-Submits der Tabelle neu zu schreiben. Dein oben genannter Ansatz ist tatsächlich der beste für das Problem. Es funktioniert anstandslos und ich bin überhaupt nicht mehr auf JavaScript angewiesen. Wollte nach dem Praxistest nur noch mal Rückmeldung geben. Danke für deine Hilfe! Einziger Wermutstropfen sind die leeren Formulare, aber das ist verschmerzbar. 😉
Gruß
Boris
@@borisbaer
Die Spalte, nach der aktuell sortiert wurde, sollte dies durch das aria-sort-Attribut an ihrer Kopfzelle angeben:
<table>
<thead>
<tr>
<th>
<button type="submit" name="sort" value="given-name.asc" form="sortform">
Vorname
</button>
</th>
<th aria-sort="ascending">
<button disabled="" type="submit" name="sort" value="family-name.asc" form="sortform">
Familienname
</button>
</th>
...
</tr>
</thead>
...
</table>
Den Button hab ich für diese Spalte deaktiviert; er wird ja nicht gebraucht. Absteigende alphabetische Sortierung macht IMHO keinen Sinn. (Möglich ist natürlich auch, dann keinen button in die th zu setzen.)
Edith: fehlendes tr-Element ergänzt
🖖 Живіть довго і процвітайте
Den Button hab ich für diese Spalte deaktiviert […] (Möglich ist natürlich auch, dann keinen button in die th zu setzen.)
Vielleicht sogar besser. Dann wird die Kopfzelle nur als „Familienname“ angesagt, nicht als „Familienname, sortieren, Button, deaktiviert“ (oder so ähnlich).
Das sähe dann kombiniert mit dem anderen Gedanken so aus:
<form id="sortform" method="post">
<span id="sortlabel" hidden="">sortieren</span>
</form>
<table>
<thead>
<th>
<button aria-describedby="sortlabel" type="submit" name="sort" value="given-name.asc" form="sortform">
Vorname
</button>
</th>
<th aria-sort="ascending">
Familienname
</th>
...
</thead>
...
</table>
Hallo Gunnar,
danke für die Hinweise zur Barrierefreiheit, aria-sort hatte ich sogar bereits hinzugefügt, aber aria-describedby kannte ich noch nicht.
In diesem Zusammenhang hätte ich noch eine Frage: HTML-Elemente, die entweder leer sind oder keine eindeutige Bezeichnung enthalten (weil es sich beim Inhalt z.B. um eine SVG handelt), sollen ja für Screenreader trotzdem sinnvoll interpretierbar sein. Nun habe ich da schon von mehreren Möglichkeiten gehört, z.B. die Attribute aria-label oder title zu benutzen oder ein span-Element einzufügen, das dann per CSS-Klasse visually hidden ist.
Welche von diesen drei Möglichkeiten ist denn nun eigentlich die geeignetste?
Grüße
Boris
Servus!
Hallo Gunnar,
danke für die Hinweise zur Barrierefreiheit,
aria-sorthatte ich sogar bereits hinzugefügt, aberaria-describedbykannte ich noch nicht.In diesem Zusammenhang hätte ich noch eine Frage: HTML-Elemente, die entweder leer sind oder keine eindeutige Bezeichnung enthalten (weil es sich beim Inhalt z.B. um eine SVG handelt), sollen ja für Screenreader trotzdem sinnvoll interpretierbar sein. Nun habe ich da schon von mehreren Möglichkeiten gehört, z.B. die Attribute
aria-labelodertitlezu benutzen oder ein span-Element einzufügen, das dann per CSS-Klasse visually hidden ist.Welche von diesen drei Möglichkeiten ist denn nun eigentlich die geeignetste?
Schwer zu sagen:
Fazit: Idealerweise keine divs, sonder die semantisch passenden Elemente.
[EDIT] Bei einem SVG entweder
ich sollte die Fragen vorher lesen! 😉
[/EDIT]
Herzliche Grüße
Matthias Scharwies
Servus!
Servus!
Hallo Gunnar,
danke für die Hinweise zur Barrierefreiheit,
aria-sorthatte ich sogar bereits hinzugefügt, aberaria-describedbykannte ich noch nicht.In diesem Zusammenhang hätte ich noch eine Frage: HTML-Elemente, die entweder leer sind oder keine eindeutige Bezeichnung enthalten (weil es sich beim Inhalt z.B. um eine SVG handelt), sollen ja für Screenreader trotzdem sinnvoll interpretierbar sein. Nun habe ich da schon von mehreren Möglichkeiten gehört, z.B. die Attribute
aria-labelodertitlezu benutzen oder ein span-Element einzufügen, das dann per CSS-Klasse visually hidden ist.Welche von diesen drei Möglichkeiten ist denn nun eigentlich die geeignetste?
[EDIT] Bei einem SVG entweder
- ein title oder metadesc-Element - beides ist zugänglich
- ein role-Attribut z.B. role="decoration" [1]
- als img ein alt-Attribut
- …
ich sollte die Fragen vorher lesen! 😉
[/EDIT]
und im SELF-Wiki: Barrierefreiheit/barrierefreie_SVGs
Herzliche Grüße
Matthias Scharwies
Herzliche Grüße
Matthias Scharwies
@@borisbaer
Welche von diesen drei Möglichkeiten ist denn nun eigentlich die geeignetste?
aria-label kannst du nur bei bestimmten Elementen anwenden: bei interaktiven wie a, button. Und dann ist da die Unschönheit, dass Attributwerte von automatischen Übersetzern evtl. nicht übersetzt werden.
Das SVG-Element title erzeugt ebenso wie das HTML-Attribut title ein Tooltip, was u.U. unerwünscht ist.
Am besten fährst du vermutlich, das SVG auf aria-hidden="true" zu setzen und den Alternativtext in einem visuell versteckten span anzugeben.
☞ Codepen
🖖 Живіть довго і процвітайте
@@Rolf B
Vielleicht kannst Du Dich damit besser sortieren.
Er vielleicht. Ich frag mich, ob alle anderen das auch können. Wahrscheinlich sollte man die Funktion des Buttons (sortieren) noch für Screenreadernutzer mit aria-describedby verständlich machen:
<form id="sortform" method="post">
<span id="sortlabel" hidden="">sortieren</span>
</form>
<table>
<thead>
<tr>
<th><button aria-describedby="sortlabel" type="submit" name="sort" value="title.asc" form="sortform">Titel</button></th>
...
</tr>
</thead>
...
</table>
Edith: fehlendes tr-Element ergänzt
🖖 Живіть довго і процвітайте