nicht angemeldet
Matthias Apsel
Gunnar Bittersmann
marctrix
Gunnar Bittersmann
Der Martin
Henry
marctrix
Matthias Apsel
Der Martin
Der Martin
Matthias Apsel
JürgenB
in der verlinkten Page ist <article> ein "Unterelement" von <section>. Unter https://wiki.selfhtml.org/wiki/HTML/Seitenstrukturierung/article ist es jedoch (imho richtig) genau andersrum.
Was ist den nun korrekt?
Hallo nur malso,
Was ist den nun korrekt?
Kommt darauf an. https://blog.selfhtml.org/2013/04/29/html5-serie-inhalte-strukturieren/
Bis demnächst
Matthias
@@nur malso
in der verlinkten Page ist <article> ein "Unterelement" von <section>. Unter https://wiki.selfhtml.org/wiki/HTML/Seitenstrukturierung/article ist es jedoch (imho richtig) genau andersrum.
Was ist den nun korrekt?
Beides. Je nachdem. Man kann sowohl article in section schachteln als auch andersrum. Natürlich auch section in section. Bei article in article bin ich mir grad nicht sicher, ob das sinnvoll sein könnte.
Was hingegen nicht korrekt ist:
Camping_RIDER
Christian Kruse<header>
<h1>Name unserer Seite</h1>
</header>
<article>
<header>
<h1>Überschrift des Artikels</h1>
</header>
⋮
</article>
h1 sollte nur genau einmal auf einer Seite vorkommen und die Seitenüberschrift (Überschrift des Artikels) enthalten – und nicht die Websiteüberschrift. Richtig ist:
<header>
<p>Name unserer Website</p>
</header>
<article>
<header>
<h1>Überschrift des Artikels</h1>
</header>
⋮
</article>
Ich berichtige das im Wiki gleich mal.
LLAP 🖖
Hej Gunnar,
Bei
articleinarticlebin ich mir grad nicht sicher, ob das sinnvoll sein könnte.
Überraschenderweise ist das erlaubt. Es setzt halt voraus, dass jeder der untergeordneten Artikel ohne die anderen Sinn ergibt, als auch das übergeordnete wieder eine thematisch ausreichend enge Einheit bildet, um als ein Artikel durchgehen zu können.
Wohl eher eine Denksportaufgabe für einen schreibwerkstatt als ein Detail mit Praxisrelevanz.
h1sollte nur genau einmal auf einer Seite vorkommen
Das ist (d)eine subjektive Meinung. Ich weiß, dass andere die teilen.
Entscheidend ist, wie wir hier mehrfach diskutiert haben, dass die Überschriften-Hierarchie nachvollziehbar ist.
und die Seitenüberschrift (Überschrift des Artikels) enthalten – und nicht die Websiteüberschrift. Richtig ist:
Dann musst du mehrere h1 verwenden.
<header> <p>Name unserer Website</p> <header> <article> <header> <h1>Überschrift des Artikels</h1> </header> ⋮ </article>Ich berichtige das im Wiki gleich mal.
Dann bedürfen die Beispiele des W3C zur Erläuterung der Überschriften-Elemente auch einer Überarbeitung. 😉
Im Ernst: du schießt über das Ziel hinaus mit deinen Forderungen.
Die h1 ausschließlich im Hauptartikel hat einen einzigen Vorteil für die wenigen Nutzer von Screenreadern: Sie können zusätzlich zur Navigation zum main Element (m-Taste in den meisten screenreadern) und der Nutzung eines Skip-Links (einmal Return drücken) dann auch noch mit einmaligem (statt zwei- oder dreimaligen) Druck auf die Taste, die einen zur nächsten Überschrift 1. Ordnung bringt, zum Beginn des ersten Artikels springen.
Warum man das fordert, werde ich nie verstehen. Die Seitenstruktur für Menschen die schlecht sehen (die zahlenmäßig wesentlich mehr sind als Blinde) und eigene Stylesheets verwenden, wird dadurch schwerer verständlich.
Dazu kommt, dass eine h1 auch noch logisch falsch ist, denn dadurch wird alles was folgt dieser Überschrift zugeschlagen. Auch die marginal-Spalte, auch der footer usw - einfach alles. Das ist in fast allen Fällen schlichtweg inhaltlich falsch.
Marc
@@marctrix
h1sollte nur genau einmal auf einer Seite vorkommenDas ist (d)eine subjektive Meinung. Ich weiß, dass andere die teilen.
Gestern bei Gelegenheit Heydon gefragt. Seine Antwort: nur eine h1 pro Seite. Aber auch nur eine subjektive Meinung. 🤷♂️
Womöglich ist es ja so, dass alle, die sich damit auskennen, wie Webseiten in AT umgesetzt werden, diese Meinung teilen; während andere, die davon keine Ahnung haben, diese Meinung nicht teilen.
LLAP 🖖
Hallo,
sehen wir uns doch zum Vergleich mal an, wie es in Printmedien gehandhabt wird. Gängige Textverarbeitungsprogramme (z.B. MS Word, LO Writer) gehen davon aus, dass man Überschrift 1 (oder Heading 1) als Kapitelüberschrift verwendet, und nicht als Gesamt-Überschrift des Werks.
Will man es anders machen und beispielsweise Heading 1 für den Titel und Heading 2 für die Kapitelüberschriften nehmen, muss man am Numerierungskonzept Hand anlegen.
Gestern bei Gelegenheit Heydon gefragt. Seine Antwort: nur eine
h1pro Seite.
Also anders als bei einem Textdokument.
Aber auch nur eine subjektive Meinung. 🤷♂️
Natürlich. Aber vielleicht ist auch mein Vergleich falsch und man müsste eigentlich gleichsetzen:
eine Webseite == ein Kapitel
Dann würde euer Modell mit einmal h1 pro Seite wieder passen.
Womöglich ist es ja so, dass alle, die sich damit auskennen, wie Webseiten in AT umgesetzt werden, diese Meinung teilen; während andere, die davon keine Ahnung haben, diese Meinung nicht teilen.
Ich glaube nicht, dass es daran liegt.
Es sind einfach zwei unterschiedliche Ansichten, mehr nicht.
Und ich bin mir nicht sicher, welche ich eigentlich vertrete.
Ciao,
Martin
@@Der Martin
sehen wir uns doch zum Vergleich mal an, wie es in Printmedien gehandhabt wird.
Das kann man nicht vergleichen. Oder anders gesagt: wenn man es tut, dann hinkt der Vergleich.
Im Print gibt es auschließlich die visuelle Hierarchie.
Bei HTML geht es um die logische Hierarchie. Auf Webseiten wird daraus mittels CSS die visuelle Hierarchie generiert, das ist aber für das HTML ohne Belang.
LLAP 🖖
Hallo,
sehen wir uns doch zum Vergleich mal an, wie es in Printmedien gehandhabt wird.
Das kann man nicht vergleichen. Oder anders gesagt: wenn man es tut, dann hinkt der Vergleich.
Im Print gibt es auschließlich die visuelle Hierarchie.
das stimmt nur, wenn du ausschließlich das fertige Druckbild betrachtest - also den Screenshot einer Webseite.
Bei HTML geht es um die logische Hierarchie.
Um die geht es mir beim Erstellen und Bearbeiten eines Word- bzw. Writer-Dokuments auch. Da ist mir das Aussehen auch zunächst egal; stattdessen versuche ich, über sinnvoll benannte Formatvorlagen dem Dokument eine Struktur zu geben. Genau wie HTML ohne CSS.
Erst ziemlich zum Schluss gehe ich daran, den Formatvorlagen auch ihre individuellen Merkmale zu geben. Also ziemlich die gleiche Arbeitsweise wie beim Erstellen von Webseiten.
Auf Webseiten wird daraus mittels CSS die visuelle Hierarchie generiert, das ist aber für das HTML ohne Belang.
Genauso wie es für die Struktur eines Word- oder Writer-Dokuments egal ist, wie die verwendeten Formatvorlagen im Druckbild aussehen.
Und aus diesem Überlegungen heraus finde ich den Vergleich durchaus passend.
So long,
Martin
Aloha ;)
Bei HTML geht es um die logische Hierarchie. Auf Webseiten wird daraus mittels CSS die visuelle Hierarchie generiert, das ist aber für das HTML ohne Belang.
Die logische Hierarchie aber wird durch die Spec bestimmt, und die sieht eine Outline-Logik vor, die explizit mehrere h1 in sinnvoller logischer Struktur vorsieht, und propagiert das afair auch in Beispielen.
Für mich ist die Spec maßgeblich. Du darfst das gerne anders sehen.
Grüße,
RIDER
@@Camping_RIDER
Die logische Hierarchie aber wird durch die Spec bestimmt, und die sieht eine Outline-Logik vor, die explizit mehrere h1 in sinnvoller logischer Struktur vorsieht, und propagiert das afair auch in Beispielen.
Ist ja schön, dass die Spec das so vorsieht. Wäre auch schön, wenn es denn so funktionieren würde.
Fakt ist aber: Der HTML5-Outline-Algorithmus ist in keinem Browser implementiert.
Für mich ist die Spec maßgeblich. Du darfst das gerne anders sehen.
Das tue ich. Maßgeblich ist, was für Nutzer rauskommt.
Wenn du dich auf den HTML5-Outline-Algorithmus berufst, der nirgendwo implementiert ist, kommt für Nutzer ein Dokument mit einer völlig verhunzten Struktur raus.
Da kannst du noch so mit den Füßen trampeln und „Die Spec sagt aber …“ rufen.
LLAP 🖖
Aloha ;)
Die logische Hierarchie aber wird durch die Spec bestimmt, und die sieht eine Outline-Logik vor, die explizit mehrere h1 in sinnvoller logischer Struktur vorsieht, und propagiert das afair auch in Beispielen.
Ist ja schön, dass die Spec das so vorsieht. Wäre auch schön, wenn es denn so funktionieren würde.
Fakt ist aber: Der HTML5-Outline-Algorithmus ist in keinem Browser implementiert.
Ja, eben. Die Browser-Entwickler so: Mensch, ist das ein unbequemes Feature. Lass ma aussitzen, das verschwindet dann von selbst wenn es keiner verwendet weils nicht funktioniert.
Und du jetzt so: Lass das nicht verwenden, weils in keinem Browser funktioniert.
Browser, die durch ihre Achtung oder Missachtung von Standards direkten Einfluss darauf haben, ob der Standard aufrechterhalten oder wieder aufgegeben wird.
Ich finde das nicht gut. Du betontest die logische Struktur, und, dass die rein vom HTML ausgeht. Dein Beitrag hört sich allerdings nicht so an, als ginge die logische Struktur nur vom HTML aus - denn so, wie du das formulierst, wird die logische Struktur für dich eigentlich gar nicht durch HTML und Spec definiert, sondern durch das Interpretationsverhalten der Browser...
Grüße,
RIDER
@@Camping_RIDER
Und du jetzt so: Lass das nicht verwenden, weils in keinem Browser funktioniert.
Und du jetzt so? Lass uns mal gap für Flexbox verwenden? Dann kleben zwar die Flexitems in allen Browsern außer Firefox aneinander, sollten sie aber laut Spec nicht. Im Zweifel für die Spec, nicht für die Nutzer?
Browser, die durch ihre Achtung oder Missachtung von Standards direkten Einfluss darauf haben, ob der Standard aufrechterhalten oder wieder aufgegeben wird.
Ich finde das nicht gut.
Die Browserhersteller sind genau diejenigen, die die Standards festlegen. Ob du das nun gutfindest oder nicht.
wie du das formulierst, wird die logische Struktur für dich eigentlich gar nicht durch HTML und Spec definiert, sondern durch das Interpretationsverhalten der Browser...
Das Interpretationsverhalten der Browser ist die HTML-Spec.
LLAP 🖖
Aloha ;)
Das Interpretationsverhalten der Browser ist die HTML-Spec.
Gut, dass wir darüber gesprochen haben. Wir könnten uns nicht uneiniger sein.
Grüße,
RIDER
@@Camping_RIDER
Das Interpretationsverhalten der Browser ist die HTML-Spec.
Gut, dass wir darüber gesprochen haben. Wir könnten uns nicht uneiniger sein.
Da schwelgst wohl in der Vergangenheit.
Bis Version 4 wurde HTML über eine Grammatik (DTD) definiert. Ich fand das auch gut.
HTML5 wird nicht über eine Grammatik, sondern über den Algorithmus definiert, wie Browser den Code zu interpretieren haben.
LLAP 🖖
Aloha ;)
HTML5 wird nicht über eine Grammatik, sondern über den Algorithmus definiert, wie Browser den Code zu interpretieren haben.
Du widersprichst dir selbst. Der Algorithmus, wie Browser den Code zu interpretieren haben, ist der Outline-Algorithmus. Meine Rede, von Anfang an…
Grüße,
RIDER
@@Camping_RIDER
Du widersprichst dir selbst.
Inwiefern?
Der Algorithmus, wie Browser den Code zu interpretieren haben, ist der Outline-Algorithmus. Meine Rede, von Anfang an…
Und meine Rede ist: Entscheidend für Nutzer ist nicht, was in der Spec steht, sondern wie Browser es tatsächlich umsetzen.
LLAP 🖖
Aloha ;)
Der Algorithmus, wie Browser den Code zu interpretieren haben, ist der Outline-Algorithmus. Meine Rede, von Anfang an…
Und meine Rede ist: Entscheidend für Nutzer ist nicht, was in der Spec steht, sondern wie Browser es tatsächlich umsetzen.
Ich kann keinen Schaden für Nutzer erkennen, der dadurch entsteht, dass man sich beim Entwickeln am Outline-Algorithmus orientiert, auch wenn dieser nicht durch die Browser interpretiert wird. Marc sieht auch keinen.
Und spätestens dann, wenn Nutzer-Interessen gar nicht direkt positiv oder negativ betroffen sind, sollte der Anspruch der Entwicklung der sein, die Spec zu erfüllen, und nicht Erfüllungsgehilfe der Browserhersteller zu sein.
Grüße,
RIDER
@@Camping_RIDER
Ich kann keinen Schaden für Nutzer erkennen, der dadurch entsteht, dass man sich beim Entwickeln am Outline-Algorithmus orientiert, auch wenn dieser nicht durch die Browser interpretiert wird.
Eine völlig verhunzte Dokumentstruktur ist für dich kein erkennbarer Schaden?
Marc sieht auch keinen.
Und Steve Faulkner ist eine Größe. (Sorry, Marc.)
Und spätestens dann, wenn Nutzer-Interessen gar nicht direkt positiv oder negativ betroffen sind, sollte der Anspruch der Entwicklung der sein, die Spec zu erfüllen, und nicht Erfüllungsgehilfe der Browserhersteller zu sein.
Da schon die Prämisse nicht zutrifft, müsste man sich um den zweiten Teil eigentlich nicht kümmern. Für dich aber nochmal: Die Spec wird (zum Großteil) von den Browserherstellern geschrieben.
LLAP 🖖
Hej Gunnar,
Ich kann keinen Schaden für Nutzer erkennen, der dadurch entsteht, dass man sich beim Entwickeln am Outline-Algorithmus orientiert, auch wenn dieser nicht durch die Browser interpretiert wird.
Eine völlig verhunzte Dokumentstruktur ist für dich kein erkennbarer Schaden?
Marc sieht auch keinen.
Da gab es wohl ein Missverständnis. Ich sehe keinen Schaden, wenn man mehr als eine h1 verwendete (was der Standard zulässt), aber HTML5-Outline ist ein no-go in der Barrierefreiheit. Das sehe ich so wie du, @Gunnar Bittersmann und wie Steve Faulkner.
Und Steve Faulkner ist eine Größe. (Sorry, Marc.)
Stört mich nicht. Ich frage mich nur gerade, wieso du Größe als Argument verwendest.
Steve hat recht, Heydon nicht. Aber nicht weil Steve "größer" ist, sondern weil er die Argumente auf seiner Seite hat. Alles andere ist irrelevant.
Marc
Hej Gunnar,
Marc sieht auch keinen.
Und Steve Faulkner ist eine Größe. (Sorry, Marc.)
Steve hat sein Beispiel doch genauso aufgebaut, wie ich. Meines zeigt 1:1 dasselbe…
Marc
Aloha ;)
Und Steve Faulkner ist eine Größe. (Sorry, Marc.)
Da ist es wieder, das Autoritätsargument. Ich sollte mal ein Sophismen-Bingo führen.
Grüße,
RIDER
@@Camping_RIDER
Und Steve Faulkner ist eine Größe. (Sorry, Marc.)
Da ist es wieder, das Autoritätsargument.
So war es nicht nicht gemeint. Ich wollte nur deiner Rückfrage „Steve wer?“ vorbeugen.
LLAP 🖖
Aloha ;)
Und Steve Faulkner ist eine Größe. (Sorry, Marc.)
Da ist es wieder, das Autoritätsargument.
So war es nicht nicht gemeint. Ich wollte nur deiner Rückfrage „Steve wer?“ vorbeugen.
Es hörte sich so an. Keine Sorge, ich fragte ja auch nicht "Heydon wer?"... 😂
Wenn ich jemanden nicht kenne, ecosiae ich ihn/sie. Steve Faulkner kannte ich.
Grüße,
RIDER
Hej Camping_RIDER,
Der Algorithmus, wie Browser den Code zu interpretieren haben, ist der Outline-Algorithmus. Meine Rede, von Anfang an…
Und meine Rede ist: Entscheidend für Nutzer ist nicht, was in der Spec steht, sondern wie Browser es tatsächlich umsetzen.
Ich kann keinen Schaden für Nutzer erkennen, der dadurch entsteht, dass man sich beim Entwickeln am Outline-Algorithmus orientiert, auch wenn dieser nicht durch die Browser interpretiert wird. Marc sieht auch keinen.
Man kann seine Dokumente so erstellen, dass diese mit und ohne outline-Algorhythmus funktionieren. Sie wie in dem Beispiel, auf das du verweist.
Sollte der Algorithmus mal implementiert werden, wird das Beispiel funktionieren.
Es funktioniert aber auch jetzt schon, weil die Überschriften-Struktur so angelegt ist, als würden Browser den Algorithmus noch nicht unterstützen (was ja definitiv nicht mal absehbar ist).
Marc
Aloha ;)
Man kann seine Dokumente so erstellen, dass diese mit und ohne outline-Algorhythmus funktionieren. Sie wie in dem Beispiel, auf das du verweist.
Sollte der Algorithmus mal implementiert werden, wird das Beispiel funktionieren.
Es funktioniert aber auch jetzt schon, weil die Überschriften-Struktur so angelegt ist, als würden Browser den Algorithmus noch nicht unterstützen (was ja definitiv nicht mal absehbar ist).
Ja, das ist meine bevorzugte Vorgehensweise. Dem Nutzer keinen Schaden einhandeln, aber in diesem Rahmen die Spec hochhalten.
Grüße,
RIDER
Hej Camping_RIDER,
Ich kann keinen Schaden für Nutzer erkennen, der dadurch entsteht, dass man sich beim Entwickeln am Outline-Algorithmus orientiert, auch wenn dieser nicht durch die Browser interpretiert wird. Marc sieht auch keinen.
Sehe gerade, dass da explizit folgendes im Artikel steht:
Ein ursprünglich einmal angedachter HTML-Outline-Algorithmus sah vor, dass alle Sektionen mit einer Überschrift 1. Ordnung überschrieben werden könnten und sich die Hierarchie durch die Verschachtelung der übergeordneten und untergeordneten Sektionen ergibt. Der Outline-Algorithmus wurde allerdings weder in Browsern noch in assistiven Technologien implementiert, sodass man die Hierarchie der Überschriften mit h1–h6 angeben muss.
😉
Ich formuliere mal um: Die Spec sieht einen HTML-Outline-Algorithmus, demzufolge alle Überschriften...
Marc
Hallo Gunnar,
Womöglich ist es ja so, dass alle, die sich damit auskennen, wie Webseiten in AT umgesetzt werden, diese Meinung teilen; während andere, die davon keine Ahnung haben, diese Meinung nicht teilen.
AT? Das erklärt vieles… scnr 😉
Aber im Ernst, nur wel jemand lieber mit Stäbchchen isst, bedeutet das nicht dass er nicht weiß wie eine Gabel funktioniert.
Zum Thema, meine Ansicht ist da noch viel lockerer. Diese Versuche seit Jahren klare Strukturen zu erzwingen (strikt, xhtml, etc…) um am Ende sowas wie XML rauszubekommen, hat sich bisher gottseidank nicht durchgesetzt, und das ist gut so. Ich gehe sogar so weit, so was z.b. zu machen:
<h1>Headline</h1>
<h3>Artikel</h3>
<h5>Details</h5>
Warum? Weil ich es liebe, dass eine Seite auch ohne CSS einigermaßen nett aussieht und die Standardstylesheets der Browser geben den Weg für mich vor.
Gruss
Henry
Hej Gunnar,
h1sollte nur genau einmal auf einer Seite vorkommenDas ist (d)eine subjektive Meinung. Ich weiß, dass andere die teilen.
Gestern bei Gelegenheit Heydon gefragt. Seine Antwort: nur eine
h1pro Seite. Aber auch nur eine subjektive Meinung. 🤷♂️
Man kann das so machen - wenn die h1 nicht über dem Artikel steht. Und das ist sicher nicht, was Heydon meinte. Man kann auf einer typischen Webseite keine objektiv logisch nachvollziehbare Seitenstruktur aufbauen, wenn man nur mit einer einzigen h1 arbeitet, die sich über dem Haupttext befindet.
Und bitte sag mir mal, was der Grund dafür sein sollte. Welchen Vorteil (und welchen Nachteil) hat beispielsweise ein Sehender, der ein eigenes CSS benutzt?
Womöglich ist es ja so, dass alle, die sich damit auskennen, wie Webseiten in AT umgesetzt werden, diese Meinung teilen; während andere, die davon keine Ahnung haben, diese Meinung nicht teilen.
Wo ist das Argument?
Wie kommst du auf die Idee, dass Barrierefreiheit sich auf die Unterstützung von AT beschränkt? Welche Vor- und Nachteile hat eine h1 für die diversen Nutzergruppen?
Wäge das doch mal gegeneinander ab, bitte. Ich kenne lediglich eine Aussage zu diesem Thema: Nutzer von Screenreadern finden es praktisch, wenn sie mit einem statt mit drei Tastendrücken zum Hauptinhalt kommen.
Das können Sie ohnehin schon, wenn sie das main-Element direkt anspringen. Nicht nur, dass es keine Hürde ist, wenn es mehrere h1 in einem Dokument gibt: es bringt auch überhaupt gar keinen Vorteil.
Wenn du aber Argumente hast, dann bringe die statt: Heydon hat Ahnung, marctrix nicht.
Ich mag Heydon wirklich gern und er hat viel Ahnung von Barrierefreiheit, aber wie wir alle ist er nur ein Mensch und ich habe den Eindruck, dass er das mit den Überschriften nicht bis in die letzte Konsequenz durchdacht hat.
Darüber hinaus weiß ich ein paar Dinge aus seinen Texten, Vorträgen und persönlicher Kommunikation:
Dein Denkfehler liegt in Bezug zu den Überschriften darin aus
viele Nutzer von AT wünschen sich das so
ein
das darf nicht anders sein zu machen.
Das ist in der Ausschließlichkeit schlicht und einfach falsch und kann hier nicht einfach so unter einer Anfängerfrage als Behauptung (und implizite Forderung) unwidersprochen stehen bleiben.
Hier kommt noch hinzu, dass ich ausnahmsweise darüber hinaus der Meinung bin, dass auch Heydon falsch liegt. Unter anderem ignoriert er die erste Überschriften-Ebene: den Titel des Dokumentes der sich im title-Element verbirgt
Das folgend ist nicht objektiv logisch nachvollziehbar
title: Lebensraum des Wolfes
main (kann direkt angesprungen werden über AT-Funktion und über Skiplinks) article
So ist es nicht richtig!
Übrigens erfahre ich so nicht aus der Überschriften-Struktur auf wessen Seite ich gelandet bin. Ist schon ein kleiner Unterschied, ob die russischen Nachwölfe (Ночные Волки) über Wölfe schreiben oder der NABU…
Marc
@@marctrix
Und was lesen wir heute im Adventskalender?
“Each page should have one page heading (<h1>), with all subsequent subheadings used to group chunks of related sub-content.”
Wieder irgendeine Meinung von irgendwem …
LLAP 🖖
Hej Gunnar,
@@marctrix
Und was lesen wir heute im Adventskalender?
“Each page should have one page heading (<h1>), with all subsequent subheadings used to group chunks of related sub-content.”
Wieder irgendeine Meinung von irgendwem …
Eher eine Behauptung, hier fehlt ja gleich jegliche Begründung.
Was wichtiger ist: welches meiner Argumente wird im Artikel entkräftet? Die Adresse des Seitenbetreibers gehört nun mal logisch nicht zum Hauptartikel und sollte mit einer dem Hauptartikel gleichwertigen Überschrift überschrieben sein.
Das steckt meiner Meinung nach auch in dem von dir zitierten Satz drin, der fordert, dass alle Gruppen von "related sub-content" mit Unterüberschriften zu strukturieren sind - was ist also mit dem Inhalt, der nicht "sub-content" des Hauptartikels ist, sondern beispielsweise "Weiterführende Information"?
Die Antwort gibt der Autor nicht, aber ich: der darf logisch nicht dem Hauptartikel zugeschlagen werden.
So lange du nichts sachlich neues präsentierst, sind diese Postings irrelevant.
Was der Artikel zudem nicht macht (jedenfalls nicht an der Stelle, die du zitierst, habe den Rest nicht gelesen): er fordert nicht, dass es nur eine h1 geben darf. Insofern steht er nicht einmal im Widerspruch zu meiner Aussage: ja, man kann den Hauptartikel mit einer h1 überschrieben, aber dann braucht man auf den allermeisten Seiten merere h1 - und das ist es ja wo du dich gegen vehement wehrst.
Also hör bitte auf so zu tun, als würde ich als einziger eine total absurde Meinung vertreten und haufenweise Links zu posten, die "beweisen" sollen, dass ich unrecht habe, obwohl in deinen Links auf meine Argumentation nicht eingegangen wird und die auch gar nicht im Widerspruch zu dem von mir Gesagten stehen…
Es gibt einen wunsch von blinden nutzern, die eine sehr gute Lobby und eine sehr laute Stimme in der a11y-Szene haben. Die wünschen sich aus Bequemlichkeit die Möglichkeit, mit einem einzigen Tastatur-Befehl zusätzlich zur Skipnavi und dem main-element auch noch per Sprung zur ersten h1 beim Hauptinhalt landen zu können.
Aber selbst dieser Wunsch wäre erfüllt, wenn du großzügigerweise erlauben würdest, danach weitere h1 zu verwenden.
Das ist schon kein Beharren auf Prinzipien (die ja sinnvoll sein können), sondern Dogmatismus, der von keiner Spezifikation und keinem Test-Verfahren gedeckt wird.
Das ist nicht einmal mehr Usability, sondern Unterstützung von übertrieben fordernden Blinden auf Kosten von anderen Nutzergruppen, die du von jedem Entwickler barrierefreier Webseiten hier verlangen möchtest.
Das ganze geht so weit ich mich erinnere auf eine Äußerung von Leonie Watson zurück, die gesagt hat, sie würde sich eine h1 über dem Hauptartikel wünschen…
Seiher geistert das durch die Szene und ich möchte mal bitte eine solche Seite sehen, die Prüfschritt 1.3.1a HTML-Strukturelemente für Überschriften erfüllt.
Da heißt es unter anderem
Teilweise erfüllt:
Es werden HTML-Strukturelemente für Überschriften eingesetzt, die Verschachtelung der Hierarchie-Ebenen ist aber irreführend, entspricht nicht der inhaltlichen Gliederung.
Das ist der Fall, wenn Inhalte nach dem Hauptartikel, die nciht zu diesem gehören nicht mindestens dieselbe Hierarchie haben, wie der Hauptartikel.
Und wenn du diese Mindestanforderungen (WCAG Level A) an Barrierefreiheit nicht erfüllst, brauchen wir über dein "nice-to-have" (nicht einmal im Level AAA der Spezifikation zu finden) gar nicht erst zu reden. 😉
Kommen wir zur WCAG: Da steht als Beispiel für Überschriften in einem dreispaltigen Layout ein Beispiel, was meiner Meinung nach absichtlich untypisch gewählt ist, damit es funktioniert:
Man hat da eine h2 vor dem Hauptartikel für die Navi (was ich als Screenreader-Nutzer doof fände, weil ich dann die wichtige Hauptnavigation leicht "übersehe").
Dann kommt der Hauptartikel (h1 - so weit unstrittig) und dann kommt die Maginalspalte absichtlich mit related Links überschrieben. Hier findet sich aber häufig nicht zugehöriger Inhalt, wie der Hinweis auf ein Produkt, das nichts mit dem Artikel zu tun hat oder sogar Werbung mit einem Link nicht einmal zu einer anderenSeite der Site sondern zur Site des Werbetreibenden. Wenn das Beispiel eine bei echten Webseiten in der Regel anzutreffende inhaltliche Struktur hätte, müsste die Marginalspalte also mit "unrelated content" überschrieben sein, und dann wäre klar, dass dieser Inhalt wieder eine h1 benötigt. Denn das gehört dann selbstverständlich nicht zum Hauptartikel und das muss durch die Überschriftenstruktur klar werden, sonst ist man weder BITV-konform, noch WCAG compliant, noch tut man Nutzern einen Gefallen!
Man muss die Beispiele der WCAG vielleciht auch mit dem Hintergrund lesen, dass man vielleciht beim Verfassen darauf gehofft hat, dass irgendwann der HTML-Outline-Algorhytmus noch von den Browser-Herstellern implementiert wird - dann wäre das alles weit weniger kritisch. Aber daruf brauchen wir wohl nciht mehr zu hoffen…
Ich hätte nicht gedacht, dass es so kompliziert sein kann, jemandem die Überschriften-Hierarchien zu erklären.
Gut, dass du meine Kurse nicht besuchst. du hättest mich wohl zur Verzweiflung getrieben und die restliche Teilnehmer säßen gelangweilt und frustriert rum… 😉
Marc
Guten Tag,
eine kleine Anmerkung: Wenn Du ausbesserst, kannst Du ja gleich noch einen kleinen Fehler mit ausbessern:
Beim zweiten <header> fehlt der Schrägstrich...
Gruss Ingrid
Hallo Ingrid,
eine kleine Anmerkung: Wenn Du ausbesserst, kannst Du ja gleich noch einen kleinen Fehler mit ausbessern:
Beim zweiten <header> fehlt der Schrägstrich...
Es ist ein Wiki. Jeder darf. Auch ohne Anmeldung.
Bis demnächst
Matthias
Hallo Matthias,
Beim zweiten <header> fehlt der Schrägstrich...
Es ist ein Wiki. Jeder darf. Auch ohne Anmeldung.
ich kann da im Moment keinen Bezug zum Wiki erkennen. Ingrid meinte vermutlich:
in Gunnars Posting.
Ich hab das da mal korrigiert.
Ciao,
Martin
Hallo Matthias,
Es ist ein Wiki. Jeder darf. Auch ohne Anmeldung.
Ehrlich gesagt, ich fühle mich zu unsicher, um da irgend etwas zu verändern - selbst wenn ich mir so gut wie sicher bin.
Wenn ich den Organisatoren des Forums etwas vorschlagen könnte, dann wäre es Folgendes: eine Funktion, mit der man (damit meine ich insbesondere Laien wie mich) auf der jeweiligen Wikiseite auf vermutliche Fehler hinweisen könnte, ohne dass der Text dadurch gleich definitiv abgeändert wird. Da könnten dann die Spezialisten hinterherschauen (damit meine ich alle, die sich selbst als solche fühlen, und nicht nur die Organisatoren) und müssten die Korrekturen nur noch bestätigen oder gegebenenfalls ablehnen.
Einen schönen Abend noch Ingrid
Guten Abend,
Es ist ein Wiki. Jeder darf. Auch ohne Anmeldung.
Ehrlich gesagt, ich fühle mich zu unsicher, um da irgend etwas zu verändern - selbst wenn ich mir so gut wie sicher bin.
okay, das kann ich nachvollziehen. Und wenn man schon unsicher ist, finde ich es auch gut, wenn man sich eher zurückhält.
Wenn ich den Organisatoren des Forums etwas vorschlagen könnte, dann wäre es Folgendes: eine Funktion, mit der man (damit meine ich insbesondere Laien wie mich) auf der jeweiligen Wikiseite auf vermutliche Fehler hinweisen könnte, ohne dass der Text dadurch gleich definitiv abgeändert wird.
Dafür ist das Forum hier eigentlich der perfekte Ort. Hier hast du die Gewissheit, dass dein Hinweis auch gelesen wird. Am einfachsten geht das mit dem Link "Fragen", der in der Headerzeile aller(?) Wiki-Artikel steht.
Ciao,
Martin
Hallo Der Martin,
Am einfachsten geht das mit dem Link "Fragen", der in der Headerzeile aller(?) Wiki-Artikel steht.
Aller.
Allerdings nicht einfach genug. Die Funktion, die Betreff, problematische Seite und Tags setzt, ist noch für die V4-Version. Vielleicht kann @Christian Kruse mal schauen, wie das geändert werden muss?
Bis demnächst
Matthias
Hallo Matthias,
Allerdings nicht einfach genug. Die Funktion, die Betreff, problematische Seite und Tags setzt, ist noch für die V4-Version. Vielleicht kann @Christian Kruse mal schauen, wie das geändert werden muss?
Wenn der @Matthias Apsel mir die nochmal zukommen lässt? 😉
Freundliche Grüße,
Christian Kruse
Hallo Christian Kruse,
Wenn der @Matthias Apsel mir die nochmal zukommen lässt? 😉
Na gern doch 😀
Bis demnächst
Matthias
Danke für den Hinweis.
Noch ein Tipp an Euch:
Wenn man auf die Seite "Bearbeiten" gerät, wird man abgeschreckt davon, wie endgültig das sein könnte (auch wenn untenstehend Jürgen mich gerade beruhigt hat). Vielleicht könntet Ihr diese Information oben in Eure Erklärungsseiten für die Bearbeitungsfunktion erwähnen?
Also in etwa: "Seid Ihr Euch wirklich nicht sicher, ob Eure Korrekturen richtig sind, dann habt Ihr auch die Möglichkeit, den Link "Fragen" zu verwenden, der in der Headerzeile aller(?) Wiki-Artikel steht."
Gruss Ingrid
Hallo Ingrid,
Vielleicht könntet Ihr diese Information oben in Eure Erklärungsseiten für die Bearbeitungsfunktion erwähnen?
Welche Seite meinst du? Kannst du bitte mal eine verlinken oder einen Screenshot machen, wo du die Stelle kenntlich machst.
"Seid Ihr Euch wirklich nicht sicher, ob Eure Korrekturen richtig sind, dann habt Ihr auch die Möglichkeit, den Link "Fragen" zu verwenden, der in der Headerzeile aller(?) Wiki-Artikel steht."
Aller.
Bis demnächst
Matthias
Ich greife jetzt einmal eine willkürliche Seite heraus (in Wirklichkeit habe ich auf dieser Seite keine Fehler festgestellt):
https://wiki.selfhtml.org/wiki/Grafik/Farbkonzept
Ich drücke auf "Bearbeiten" und gelange auf die Seite: https://wiki.selfhtml.org/index.php?title=Grafik/Farbkonzept&action=edit§ion=1
Und da steht oben:
Sie bearbeiten diese Seite unangemeldet. Wenn Sie Ihre Änderungen speichern, wird Ihre aktuelle IP-Adresse in der Versionsgeschichte aufgezeichnet und ist damit unwiderruflich öffentlich einsehbar. Wenn Sie ein Benutzerkonto anlegen, bleibt Ihre IP-Adresse verborgen.
Ich würde vorschlagen, dass Ihr im Anschluss daran noch einen Absatz einfügt, der in etwa wie folgt lauten könnte:
Sind Sie sich wirklich nicht sicher, ob Ihre Korrekturen richtig sind, dann haben Sie auch die Möglichkeit, den Link "Fragen" zu verwenden, der in der Headerzeile aller Wiki-Artikel steht.
Schönen Abend noch
Hallo Ingrid,
deine Sorgen verstehe ich, aber wenn du mal etwas „falsch“ korrigieren solltest, wird das schnell bemerkt. Wegen Vandalismus und Spam ist das Wiki unter „Beobachtung“. Ich z.B. versuche mir einmal am Tag die letzten Änderungen anzusehen.
Gruß
Jürgen
in der verlinkten Page ist <article> ein "Unterelement" von <section>. Unter https://wiki.selfhtml.org/wiki/HTML/Seitenstrukturierung/article ist es jedoch (imho richtig) genau andersrum.
Was ist den nun korrekt?
<article> ist ein weitestgehend eigenständiger Abschnitt der Seite. Du könntest diesen Abschnitt also aus der Seite rausnehmen, ohne dass er - wie es ja immer heisst - aus dem Zusammenhang gerissen wird.
<section> ist einfach nur ein Abschnitt.
Welches Element du wo benutzt, musst du selbst entscheiden, denn nur du kennst die Inhalte und kannst ihnen eine Bedeutung zuerkennen. Insbesondere ist es keines dem anderen per se über- oder untergeordnet.
Im Unterschied zu <p> (und erst recht <div>) sollten aber sowohl <article> als auch <section> eine Überschrift haben.
Im Original ist das eigentlich recht gut beschrieben: