Passende Überschrift hier einsetzen

Viele Hilfsmittel und Browser bieten entsprechende Funktionen, um Überschriften aus Seiten herauszuziehen und aufzulisten und ermöglichen es so dem Nutzer, diese gezielt per Tastendruck anzuspringen. Dies entspricht in etwa dem visuellen Überfliegen einer Seite durch sehende Nutzer und eröffnet eine gleichwertige Orientierung im Inhalt. Die Aufnahme der Informationen z.B. in Punktschrift über eine Braille-Zeile geht viel schneller, wenn man nicht die gesamte Seite von oben bis unten durchlesen muss, nur um sich einen Überblick zu verschaffen:

»… nur ein schön gegliedertes Dokument ist auch angenehm zum Lesen aber auch zum Betrachten. Aber da ich eben als Blinder mit den Ohren und Händen sehe, ist es für mich um so wichtiger, wenn eine Internetseite schön ordentlich mit Überschriften versehen ist. Denn stellen Sie sich mal vor, Sie hätten lediglich Fliesstext, überall wäre die selbe Schriftgrösse, Schriftfarbe und Schriftart. Das wäre doch alles andere als angenehm, oder etwa nicht?«

Selamet Aydogdu im Access-for-all-Blog: »Die Bedeutung der Überschriftenauszeichnung im Web«

Entwickler von Webseiten sollten diese Nutzungsweisen beim Aufbau der Inhalte berücksichtigen: beim Auszeichnen von Text, der mit Überschriften strukturiert ist, muss man die hierfür vorgesehenen Elemente H1 bis H6 benutzen; und irgendeine Headline ist allemal besser als <font size=”6” color=”#f00”><b> … </b></font>. Deshalb ist die dazugehörige Technik »H42: Using h1-h6 to identify headings« in den WCAG bei den absoluten Muss-Kriterien unter Level A einsortiert.

Leider besteht kein Konsens, ob ein Dokument immer mit einer Überschrift vom Range einer H1 anfangen muss, ob mehrere H1 in einem Dokument erlaubt sind oder ob nun auf eine H1 eine H3 folgen darf oder zwangsläufig eine H2 kommen muss, ob vor der H1 eine H4 stehen darf, und so weiter und so fort. Einer der Gründe, warum die entsprechende Technik »G141: Organizing a page using headings« in den WCAG 2.0 erst bei den Kann-Kriterien in Level AAA angesiedelt ist.

Also dann so …

Die eine Denkschule empfiehlt: »… in der Regel drei Überschriften der Ebene 1 (h1) zu verwenden um die gesamte Site zu strukturieren« – so Markus Riesch im Access-for-all-Blog; er sagt aber auch gleichzeitig: »Es gibt hier nicht ein eindeutige Lösung. Es kommt natürlich immer auf den Aufbau der Site an.« So sind durchaus Fälle denkbar, wo keine der verschiedenen Ebenen von H1-H6 überhaupt sinnvoll erscheint, weil schon genügend andere strukturierende Elemente in der Seite vorhanden sind (wie zum Beispiel in Formular-Anwendungen durch die Kombination aus <fieldset> und <legend>).

Ein weiterer Nachteil dieses Ansatzes ist, dass in vielen Anwendungsfällen den derart mit H1 ausgezeichneten Bereichskennungen damit eine Wichtigkeit zugeschrieben wird, die sie streng genommen nicht haben. So ist zum Beispiel bei der Einzelansicht eines Beitrags in einem Weblog die Überschrift des eigentlichen Textes sicher eine H1 oder H2 wert, die nebenstehende Navigation ist jedoch garantiert nicht gleichwertig und eher als Beiwerk und somit in der Hierarchie niedriger einzuordnen.

Oder doch so …

Daher die andere Denkschule, die Struktureinheiten eine entsprechend niedriger angesiedelte Überschrift zuweisen will, wenn diese nichts mit dem wesentlichen Inhalt der Seite zu tun haben. So empfiehlt Jan Eric Hellbusch in einem Beitrag bei MAIN-web:

»Persönlich ziehe ich die H6 für die strukturelle Navigation vor. Das hat auch bestimmte Gründe: Die H6 wird im Inhaltsbereich eigentlich nie benutzt. Es gibt deshalb keine Verwechselungsgefahr. Die H6 ist klar außerhalb der inhaltlichen Hierarchie.«

Jan Eric Hellbusch: »Strukturelle Navigation: Beispiel der Gebrauchstauglichkeit«

Eine andere gängige (und auch hier bei EfA teilweise angewendete) Praxis ist es, Bereiche im Beiwerk wie z.B. die Navigation mit einer H2 oder H3 zu kennzeichnen. Schaut man sich diese Seite dann jedoch durch ein Werkzeug an, dass die Struktur auswertet (z.B. der W3C-Validator mit aktivierter Option ›Show Outline‹ oder dem Semantic Data Extractor, dann wundert man sich, dass die Navigation nun ein Unterpunkt eines Artikels sein soll – was in den weitaus meisten Fällen nicht zutreffend sein wird.

In einem Word-Dokument oder einem Buch mag diese Betrachtungsweise legitim sein: hier gibt es nur eine oberste Überschrift und alles Folgende ordnet sich dieser unter. Ebenso bei Seiten, die ausschließlich ein Thema beinhalten und eigenständige Dokumente wie in den Anfangstagen des Webs sind, als es hauptsächlich noch um ›Papers‹ von Kernphysikern am CERN ging. Ein Beispiel hierfür ist die Dokumentation des Prüfverfahrens zum BIENE-Wettbewerb (hier ein Beispiel für die Outline outline-biene09.html bzw. direkt im Semantic Data Extractor) – der Titel des Dokuments steht selbstverständlich in einer <h1>, die Kriteriengruppen beginnen mit einer <h2>, die Kriterien selbst stehen in einer <h3> und die Prüfschritte folgerichtig in einer <h4>.

Im Netz sind jedoch die meisten Seiten schon lange keine klassischen Dokumente mehr, sondern Anwendungen oder andere Dinge, die sich nicht mehr oder nur unzureichend mit H1-H6 beschreiben lassen. Klassische Überschriften-Elemente sind hier ein Teil der Struktur, aber Teile der Dokumente benötigen eigentlich etwas anderes als ›normale‹ Überschriften. Sie sind in der jetzigen Form nur ein Notbehelf, da sie zwar zur Strukturierung von (Text-)Inhalten hervorragend geeignet sind, aber nie für die darüber hinaus gehende Strukturierung der Seite gedacht waren, in die der Inhalt eingebettet ist. Der Fehler liegt hier beim Prüfwerkzeug, das versucht eine monohierarchische Struktur abzubilden, die es so gar nicht geben kann, und nicht beim Autoren der Seite, dem nur unzureichende Mittel zur Verfügung stehen, um echte Polyhierarchien zu bauen.

Lücken in HTML

Die Ursache der Diskussion und damit der Kern des Problems ist, wie so oft, ein Mangel bzw. ein Versäumnis in der HTML4-Spezifikation: dort wurden zwar eine ganze Reihe neuer Elemente eingeführt, leider jedoch keines, dass von seiner Bedeutung her einem Navigationsmenü entsprechen würde. Semantisch naheliegend wäre noch das MENU-Element, das aber von seiner Definition her redundant zu UL ist und folgerichtig abgeschafft wurde (im W3C-Sprech: »deprecated«).

Was fehlt sind also Elemente, mit dem man einem User Agent sagen könnte, dass er bitte die Navigation, die Suche oder die Kopf- bzw. Fußzeile anspringen soll. Auch bei den üblicherweise verwendeten Listen von Menüpunkten würde dies auf ein Ratespiel für den User Agent hinauslaufen, da diese Navigationslisten im Markup durch nichts von anderen Auflistungen im Text einer Seite zu unterscheiden sind.

Eine Lösung dieses Problems ist (neben den ARIA Landmark Roles) durch das seit 2004 in der Entwicklung befindliche HTML5 zu erwarten: durch die Definition von eigenständigen Elementen zur Auszeichnung von Seitenbereichen wie Kopf- und Fußbereiche, Seitenleisten und Navigationselementen entfällt hier die Notwendigkeit, diese noch zusätzlich mit Überschriften zu versehen.

Fehler in der Matrix

HTML5 wird noch ein weiteres gravierendes Problem lösen, um dass sich in Blogs und Foren seit Jahren gestritten wird: darf man Überschriften-Ebenen auslassen oder müssen diese immer streng hierarchisch und ohne Lücken aufgebaut sein?

Der Tipp, dass man in Streitfällen erstmal in die Spezifikation schauen sollte, hilft hier nicht – diese ist nämlich nicht nur in diesem Punkt ausgesprochen schwammig. Im HTML4-Standard selbst steht nichts zu dieser Frage, und im informativen Teil des Abschnittes zu Überschriften steht lediglich:

»Manche werten das Überspringen von Überschriftsebenen als schlechten Stil. Sie akzeptieren H1 H2 H1, aber nicht H1 H3 H1, weil die Überschriftsebene H2 übersprungen wird.«

»HTML 4.01-Spezifikation – Deutsche Übersetzung«

In der Praxis hilft das nicht weiter, zumal sich die Frage stellt, was Formulierungen wie »Manche werten …« (im englischen Original: »Some people consider …«) in einer technischen Spezifikation verloren haben.

Die WCAG 1.0 sind in diesem Punkt deutlicher:

»Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not ›skip‹ levels (e.g., H1 directly to H3).«

»HTML Techniques for Web Content Accessibility Guidelines 1.0«

Die aktuelleren WCAG in der Version 2.0 gehen dieses Thema auch nicht entspannter an:

»To facilitate navigation and understanding of overall document structure, authors should use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.)«

»G141: Organizing a page using headings«

Regelrechte Regelverstöße

Nun gibt es eine ganze Reihe Gründe, von dieser Vorgabe abzuweichen. Ob vor einer höherwertigen Überschrift eine niederwertigere Überschrift stehen darf ist jedoch nicht nur eine philosophische Frage, sondern gängige Praxis z.B. im Zeitungslayout und hat durchaus seine Berechtigung bei der Auszeichnung entsprechender Artikel für Online-Medien.

Daneben gibt es noch weitere Gründe, von der streng hierarchischen Struktur abzuweichen: in vielen CMS-basierten Seiten stehen die Überschriften hartcodiert im Content. Sie haben somit nicht mehr die nötige Flexibilität, mal als <h3> und mal als <h4> ausgegeben zu werden. Wenn ein Artikel nun innerhalb der Website in unterschiedlichen Kontexten auftaucht, dann kann und wird es passieren, dass der Artikel mit seinen hartverdrahteten Überschriften die Überschriften-Hierarchie durcheinanderwirbelt.

Hier im EfA-Blog ist dies zum Beispiel der Fall, wenn ein Blogpost statt in der Einzelansicht auf einer Übersichtsseite angezeigt wird, in der als zusätzliche Zwischenüberschrift ein ordnendes Datum hinzukommt. Nun könnte man zwar serverseitig die Überschriften-Ebenen umschreiben und je nach Kontext rauf oder runter setzen – dann hat man aber das Problem, dass nun die Style Sheets nicht mehr bzw. an der falschen Stelle greifen, da die ehemalige Regel #inhalt h3 {…} nun eine #inhalt h4 {…} ist. Dem könnte man begegnen, indem man im HTML zusätzliche Klassen einfügt oder weitere Templates erstellt und im CSS weitere Kontext-Selektoren definiert, aber spätestens an der Stelle darf man getrost die Frage nach der Praktikabilität und Sinnhaftigkeit des ganzen stellen.

Diesem Paradoxon begegnet HTML5 nun, indem innerhalb der neuen Strukturelemente beliebig viele Überschriften-Hierarchien aufgebaut werden können, die alle mit H1 anfangen und sich trotzdem übergeordneten Überschriften unterordnen. Browser und auch Hilfsmittel wie z.B. Screenreader sind dann dafür verantwortlich, die Überschriften entsprechend umsortiert zu präsentieren. So wird im folgenden Beispiel:

<h1> … </h1>
<section>
 <h1> … </h1>
 <p> … </p>
  <h2> … </h2>
</section>

aus der zweiten H1 (innerhalb von <section>) automatisch eine H2. In HTML5 zählt nicht das Markup, sondern das Document Object Model (DOM), welches der Browser daraus generiert. Da Browser angehalten sind, die Überschriften-Ebenen entsprechend anzupassen ergibt sich somit aus dem folgenden Beispiel:

<h1> … </h1>
<p> … </p>
 <h2> … </h2>
 <p> … </p>
 <section>
  <h1> … </h1>
  <p> … </p>
   <h2> … </h2>
   <p> … </p>
 </section>

ein Baum mit den Knoten H1, P, H2, P, H3, P, H4, P. Dies löst für Web-Entwickler das Problem, dass Inhalte aus unterschiedlichen oder im Ernstfall unbekannten Quellen (z.B. Mashups) nun nicht mehr ihrer jeweiligen Position in der Hierarchie entsprechend umgeschrieben werden müssen. Wenn sie als eigenständige <section>…</section> gekapselt sind liegt es nun am Browser, diese entsprechend zu interpretieren. Dass dies zurzeit nur von wenigen Browsern und nach unserem Kenntnisstand von keinem Screenreader unterstützt wird sollte allerdings kein Anlass zur Sorge sein: bei Innovationen kommt es immer zwangsläufig zu Brüchen mit den dann veralteten Techniken.

Bis HTML5 aber tatsächlich in der Praxis einsetzbar ist bleibt nur die Empfehlung für Web-Entwickler, sämtliche Empfehlungen in diesem Bereich zu ignorieren und selbst nach der für das jeweilige Webangebot optimalen Lösung zu suchen.