Frage zum Wiki-Artikel „aria-*“

[Robert B.]

Hallo,

ich verstehe die Angaben im verlinkten Artikel nicht. Was soll mir zum Beispiel folgendes sagen (Original Copy&Paste aus dem Wiki-Artikel)?

<spanid="aria-autocomplete">aria-autocomplete</span>
Zeigt an, ob bei Benutzereingaben Vorschläge zur Auto-Vervollständigung angeboten werden.

Viele Grüße
Robert

[Matthias Scharwies]

Servus!

Hallo,

ich verstehe die Angaben im verlinkten Artikel nicht. Was soll mir zum Beispiel folgendes sagen (Original Copy&Paste aus dem Wiki-Artikel)?

<spanid="aria-autocomplete">aria-autocomplete</span>
Zeigt an, ob bei Benutzereingaben Vorschläge zur Auto-Vervollständigung angeboten werden.

Ja, da geh ich noch mal rüber. Neuer Textvorschlag (aus MDN):

gibt an, ob die Eingabe von Text die Anzeige einer oder mehrerer Vorhersagen des vom Benutzer beabsichtigten Wertes für eine Combobox, ein Suchfeld oder ein Textfeld auslösen könnte und legt fest, wie Vorhersagen dargestellt werden, wenn sie gemacht werden.

Das ist mir aber zu lang.

Sollte man bei jedem aria-Attribut-Absatz (ich möchte nicht für jedes Attribut eine eigene Seite erstellen) eine Referenz auf den entsprechenden MDN-Artikel erstellen?

Generell habe ich das Problem, wo wir aria-… und WAI-ARIA einführen sollen. In einem Beitrag Barrierefreiheit/WAI-ARIA ist es irgendwo hinten im Wiki versteckt und keiner liest es. In einem der Tutorials zu HTML sollte es erwähnt und erklärt werden.

• HTML/Tutorials/Einstieg
  • Hier wäre es mir zu früh - man soll die richtigen Elemente verwenden und keinen Ersatz mit aria basteln.
• HTML/Tutorials
  • Wie viel ARIA ist zuviel? - hier passt es imho ganz gut. Sollte man es aber noch woanders mal grundlegend erklären?

Da müsste man mal drüber nachdenken.

Vorlage:anchor2

Wenn es Dir nur um das <spanid="aria-autocomplete">…</span> geht, das ist die {{anchor2|...}}-Vorlage.

@Rolf B Könntest du Dich da bitte drum kümmern.

Meine Frage ist noch nicht beantwortet: Warum haben wir 2, die Wikipedia nur eine 1 Vorlage für Anker? (Das hatte Matthias Apsel 2017 so angelegt.)

Warum müssen wir Anker in Überschriften (werden ja zu Seitenankern gemacht) setzen? Das ist imho eine Quelle für Fehler. Wir sollten uns darauf konzentrieren, Überschriften so kurz, prägnant und sachlich wie möglich zu formulieren, dann wäre so etwas nicht nötig.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

Könntest du Dich da bitte drum kümmern.

Äh, ja, das ist diese blöde Eigenschaft der Parserfunktionen, dass sie Leerzeichen wegschmeißen. Ich dachte eigentlich, das hätte ich gefixt. War aber nur im Test-Wiki der Fall.

Meine Frage ist noch nicht beantwortet: Warum haben wir 2, die Wikipedia nur eine 1 Vorlage für Anker?

Also, {{Vorlage:Anchor}} ist sozusagen original aus Mediawiki. Es kann 1-4 IDs erzeugen, in leeren Spans. {{Vorlage:Anchor2}} kann nur eine ID erzeugen und setzt die ID als Text in den Span.

Weshalb Matthias Apsel das gemacht hat - keine Ahnung. Das habe ich nicht hinterfragt. Und ich wäre einverstanden, die Verwendungen von Anchor2 durch Anchor zu ersetzen. Anchor2 bringt keinen Mehrwert, es ist egal, ob ich <span id="foo"></span>foo schreibe oder <span id="foo">foo</span>.

Warum müssen wir Anker in Überschriften (werden ja zu Seitenankern gemacht) setzen? ... Wir sollten uns darauf konzentrieren, Überschriften so kurz, prägnant und sachlich wie möglich zu formulieren

Ja, aber es gibt halt Überschriften, die etwas länger sind und dann eklig lange Link-URLs erzeugen. Ich habe auf mediawiki.org mal nach Verwendungen für Anchor geschaut. Da finde ich auf Communication/de zum Beispiel dies:

{{anchor|com-twitter|Twitter/Facebook}}
<span id="Social_Media"></span>
=== Soziale Netzwerke ===

Das ist – von unten nach oben – die deutsche Überschrift. Dann die englische Überschrift, entweder mit {{subst:Anchor...}} eingesetzt oder manuell erstellt. Und dann nochmal zwei weitere Anker via Vorlage, die prägnante Kurz-IDs sind, die sich bei Übersetzungen vermutlich auch nicht ändern.

Ja, haben wir so nicht. Aber wir haben gelegentlich Überarbeitungen, bei denen sich auch Überschriften ändern. Und wehe, da hat einer die alte Überschrift per Hash verlinkt. Dann braucht man einen Zusatzanker, damit der Link noch funktioniert.

Deswegen hatte ich ja den Gedanken mit der target-Option, die für die Permalink-Icons Vorrang hat: Man kann eine Redirection einrichten, die auf die Überschrift zeigt. Der Target-Anchor sagt jedem: Verwende die Redirection zum Verlinken, nicht die Überschrift als URL-Hash. Und wenn sich was überarbeitet, ändert man 1x die Redirection (bzw. ich kann es auch so machen, dass die Anchor-ID mit ausgegeben wird und das target reiner Zusatz ist, dann braucht man die Redirection gar nicht zu ändern).

Ich würde dann gerne:

• Alle Verwendungen von Anchor2 durch Anchor ersetzen (das sind nicht viele), statt deinen Revert von Anchor2 durch eine reparierte target-Version zu ersetzen
• In Anchor die target-Option einbauen, ohne {{{1}}} als id zu unterdrücken
• Das geänderte Permalink-Script (was data-target für Permalinks bevorzugt) aus dem Testwiki ins Hauptwiki übernehmen.

Wir haben einige Weiterleitungsseiten, die auf Überschriften in Artikeln verweisen. Diese Überschriften könnte man dann mit und mit durch Anchor ohne ID, aber mit target-Option ergänzen.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

Könntest du Dich da bitte drum kümmern.

Äh, ja, das ist diese blöde Eigenschaft der Parserfunktionen, dass sie Leerzeichen wegschmeißen. Ich dachte eigentlich, das hätte ich gefixt. War aber nur im Test-Wiki der Fall.

Meine Frage ist noch nicht beantwortet: Warum haben wir 2, die Wikipedia nur eine 1 Vorlage für Anker?

Also, {{Vorlage:Anchor}} ist sozusagen original aus Mediawiki. Es kann 1-4 IDs erzeugen, in leeren Spans. {{Vorlage:Anchor2}} kann nur eine ID erzeugen und setzt die ID als Text in den Span.

Ja, und das war auch mein Fehler, dann eben den span fett formatiert als „kleine“ Überschrift zu notieren. Ich habe mehrere solcher Spans jetzt als h4 umgewandelt. Evtl. sollte man dann {{TOC|limit=x}} setzen, ist mir aber oft nicht wichtig genug.

Weshalb Matthias Apsel das gemacht hat - keine Ahnung. Das habe ich nicht hinterfragt. Und ich wäre einverstanden, die Verwendungen von Anchor2 durch Anchor zu ersetzen. Anchor2 bringt keinen Mehrwert, es ist egal, ob ich <span id="foo"></span>foo schreibe oder <span id="foo">foo</span>.

Also: weg damit!

Warum müssen wir Anker in Überschriften (werden ja zu Seitenankern gemacht) setzen? ... Wir sollten uns darauf konzentrieren, Überschriften so kurz, prägnant und sachlich wie möglich zu formulieren

Ja, aber es gibt halt Überschriften, die etwas länger sind und dann eklig lange Link-URLs erzeugen. Ich habe auf mediawiki.org mal nach Verwendungen für Anchor geschaut. Da finde ich auf Communication/de zum Beispiel dies:

{{anchor|com-twitter|Twitter/Facebook}}
<span id="Social_Media"></span>
=== Soziale Netzwerke ===

Das ist – von unten nach oben – die deutsche Überschrift. Dann die englische Überschrift, entweder mit {{subst:Anchor...}} eingesetzt oder manuell erstellt. Und dann nochmal zwei weitere Anker via Vorlage, die prägnante Kurz-IDs sind, die sich bei Übersetzungen vermutlich auch nicht ändern.

Ja, haben wir so nicht. Aber wir haben gelegentlich Überarbeitungen, bei denen sich auch Überschriften ändern. Und wehe, da hat einer die alte Überschrift per Hash verlinkt. Dann braucht man einen Zusatzanker, damit der Link noch funktioniert.

Deswegen hatte ich ja den Gedanken mit der target-Option, die für die Permalink-Icons Vorrang hat: Man kann eine Redirection einrichten, die auf die Überschrift zeigt. Der Target-Anchor sagt jedem: Verwende die Redirection zum Verlinken, nicht die Überschrift als URL-Hash. Und wenn sich was überarbeitet, ändert man 1x die Redirection (bzw. ich kann es auch so machen, dass die Anchor-ID mit ausgegeben wird und das target reiner Zusatz ist, dann braucht man die Redirection gar nicht zu ändern).

Jedem? Nein, wenn, dann müsste man so etwas kommunizieren und in der /Dokumentation, sowie der Hilfe notieren.

Ich würde dann gerne:

• Alle Verwendungen von Anchor2 durch Anchor ersetzen (das sind nicht viele), statt deinen Revert von Anchor2 durch eine reparierte target-Version zu ersetzen
• In Anchor die target-Option einbauen, ohne {{{1}}} als id zu unterdrücken
• Das geänderte Permalink-Script (was data-target für Permalinks bevorzugt) aus dem Testwiki ins Hauptwiki übernehmen.

Warum immer für alles ein Script schreiben - ist HTML nicht genug?

Antwort: „Das sind doch nur wenige Byte“ - aber es läppert sich doch. Und macht unsere Mediawiki.common.js immer größer.

Wir haben einige Weiterleitungsseiten, die auf Überschriften in Artikeln verweisen. Diese Überschriften könnte man dann mit und mit durch Anchor ohne ID, aber mit target-Option ergänzen.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias Scharwies,

Warum immer für alles ein Script schreiben - ist HTML nicht genug?

Genauso genug wie 640K RAM… Deswegen haben wir die common.js (bzw. die Server- und Client-Scripte im Skin) ja. Permalinks, Skin-Changes, die Verbergen-Vorlage, da kommt was zusammen. Der Komplex "Beispiele" ist auch dabei. Ich hatte schon überlegt, die Tab-Darstellung der Beispiel direkt in der Vorlage zu realisieren, statt es mit JS zu machen. Aber das geht nur teilweise: man kann <a> und <iframe> nicht aus Wikitext ausgeben (bzw. man müsste diese Tags für Mediawiki freischalten und ich bin nicht sicher, dass ich das will - da ist Missbrauchspotenzial).

Seltener gebrauchte Dinge wie die Helferlein oder die EditTools lade ich ja bereits mit mw.load on-demand nach. Aber mit der {{BeispielVorschau}} Vorlage können wir deine Absicht wieder aufgreifen, die Helferlein als Beispiele anzubieten. Die lassen sich dann als BeispielVorschau einbauen, und der Helferlein-Adaptercode kann weg.

Und macht unsere Mediawiki.common.js immer größer.

Das ist technisch kein Problem, finde ich. Menschlich natürlich schon, das Ding will gepflegt werden.

Dumme Frage: sind wir im /self Forum mit dieser Diskussion richtig? Ist das nicht eher ein Internum?

Rolf

[Robert B.]

Moin Matthias,

ich verstehe die Angaben im verlinkten Artikel nicht. Was soll mir zum Beispiel folgendes sagen (Original Copy&Paste aus dem Wiki-Artikel)?

<spanid="aria-autocomplete">aria-autocomplete</span>
Zeigt an, ob bei Benutzereingaben Vorschläge zur Auto-Vervollständigung angeboten werden.

Ja, da geh ich noch mal rüber. Neuer Textvorschlag (aus MDN):

gibt an, ob die Eingabe von Text die Anzeige einer oder mehrerer Vorhersagen des vom Benutzer beabsichtigten Wertes für eine Combobox, ein Suchfeld oder ein Textfeld auslösen könnte und legt fest, wie Vorhersagen dargestellt werden, wenn sie gemacht werden.

Unter Auto-Complete verstehe ich eher Automatische Vervollständigung und keine „Vorhersagen“. Was mir aus obigem Copy&Paste aber vollkommen unklar ist:

• Was heißt <spanid…></span>? OK, es ist wohl ein technischer Fehler im Wiki.
• Wie nutze ich das (HTML-) Attribut (?) in semantischem HTML?

Sollte man bei jedem aria-Attribut-Absatz (ich möchte nicht für jedes Attribut eine eigene Seite erstellen) eine Referenz auf den entsprechenden MDN-Artikel erstellen?

Wäre das nicht ein Fall für eine Definitionsliste?

Viele Grüße
Robert

[Matthias Scharwies]

Servus!

• Was heißt <spanid…></span>? OK, es ist wohl ein technischer Fehler im Wiki.

Ja, das haben wir wieder gefixt.

• Wie nutze ich das (HTML-) Attribut (?) in semantischem HTML?

Zuerst: es gibt ja ein passendes HTML-Attribut:

<label for="firstName">First Name:</label>
<input name="firstName" id="firstName" type="text" autocomplete="given-name" />

<label for="lastName">Last Name:</label>
<input name="lastName" id="lastName" type="text" autocomplete="family-name" />

Wenn der Browser jetzt merkt, dass Du "R" eingibst, wird er es auf Robert automatisch vervollständigen und auf Deine Bestätigung warten.

Bei Passwörtern sollte man eher autocomplete="off" verwenden, wobei type="password" das eh schon verhindert.

Unter Auto-Complete verstehe ich eher Automatische Vervollständigung und keine „Vorhersagen“.

Ja, aber woher soll der Browser wissen, ob Du oder Rolf das R eingegeben hast? Deshalb eine "Vorhersage" aufgrund vorheriger Eingaben.

Im MDN wird als Beispiel für aria-autocomplete eine Combobox verwendet, für die ich einfach eine datalist genpommen hätte. Aria ersetzt hier imho die for="id-des-Eingabe-Elements"-Verbindung.

Sollte man bei jedem aria-Attribut-Absatz (ich möchte nicht für jedes Attribut eine eigene Seite erstellen) eine Referenz auf den entsprechenden MDN-Artikel erstellen?

Wäre das nicht ein Fall für eine Definitionsliste?

Ja, stimmt!

Herzliche Grüße

Matthias Scharwies

[Robert B.]

Moin Matthias,

Wenn der Browser jetzt merkt, dass Du "R" eingibst, wird er es auf Robert automatisch vervollständigen und auf Deine Bestätigung warten.

Bei Passwörtern sollte man eher autocomplete="off" verwenden, wobei type="password" das eh schon verhindert.

type=password verhindert das aber, nur solange es beim Passwort bleibt. Sobald ich mir per hübschem Button das Passwort anzeigen lasse und das input auf type=text setze, kann automatisch vervollständigt und sogar die Rechtschreibung geprüft werden. Daher ist dort spellcheck=false autocomplete=off immer eine gute Idee.

Viele Grüße
Robert