Wann gehört ein Footer zur falschen Section? Wenn er keine Überschrift hat.

Was passiert hier eigentlich?

Stell dir eine typische Unternehmenswebsite vor: Hero, drei Sections mit je einer Überschrift zweiter Ordnung, dann ein Footer mit Überschriften dritter Ordnung für „Rechtliches", „Social Meida", „Kontakt".

Visuell ist alles nachvollziehbar und verständlich. Jede Sektion hat eine sichtbare Überschrift, die Links in der Fußzeile sind mit Überschriften gruppiert. Kein offensichtliches Problem, oder?

Genau diese Seite war es, durch die Jana navigiert ist. Sie hat kein technisches Problem bemerkt. Sie hört zuerst die Überschrift  - “Referenzen, Ebene zwei” - und dann - “Rechtliches, Ebene drei” - und diese dort eingeordnet, wo eine Überschrift dritter Ebene normalerweise hingehört: als Kind der letzten zweiten Ebene “Referenzen”.  

Das ist die Information, die ihr Screenreader korrekt ausgegeben hat.

Der Grund: HTML kennt keine räumliche Information. Eine Überschrift gehört nicht zu der Sektion, in der sie visuell steht, sondern zur letzten Überschrift höherer Ordnung im Code davor.

Schaut man sich nur die Hierarchie der Überschrifte an, so wie sie im Code stehen, ergibt sich folgendes Bild:

Geht man strikt von der Hierarchie der Überschriften aus, sind die Überschriften „Rechtliches", „Navigation"  und „Kontakt" Kinder von „Referenzen". Janas Screenreader hat sich nicht vertan, er hat die Informationen wiedergegeben, die er auf der Seite gefunden hat, die so im Code stehen.

Beim Betrachten der Seite entsteht bei Jana ein visuelles Modell der Seite, das Layout kommuniziert, dass die Überschriften  “Rechtliches", „Navigation"  und „Kontakt" dem Footer zugeordnet sind. 

Jedoch, dass was ihr Screenreader ihr vorliest, erzeugt ein ganz anderes Bild der Seite. Das, was vorgelesen wird, erzeugt bei Jana ein mentales Modell, dass die drei Überschriften den Referenzen zugeordnet sind. 

Die beiden Modelle unterscheiden sich, das erzeugt Verwirrung. 
Viele Nutzende navigieren per Screenreader unter anderem über die Überschriften-Hierarchie. Es ist nicht unwahrscheinlich, dass sie dabei genau dort landen, wo Jana gelandet ist.

Doch wie löst man das Problem?

Die Lösung ist eine Zeile HTML

Das naheliegende ist, dass zwischen den Überschriften "Referenzen" und “Rechtliches” eine weitere Überschrift hinzugefügt wird. Eine zusätzliche Überschrift zweiter Ordnung.

Die naheliegende Intuition ist die richtige. Der Footer bekommt eine eigene <h2>,visuell unsichtbar, jedoch strukturell vorhanden. Sie schließt die Hierarchie korrekt ab, statt sie offen zu lassen: 

Die Hierarchie sieht danach wie folgt aus:

Die Links “Rechtliches”, “Navigation” und “Kontakt”, werden jetzt richtig als Kinder von der Überschrift "Fußzeile" angezeigt und nicht mehr von “Referenzen”. Würde Jana heute wieder im Footer landen, wüsste sie anhand der Überschriften, wo sie ist.

Eine native <h2> ist hier eine naheliegendste Lösung.  <div role=”heading” aria-level=”2”> wäre semantisch gleichwertig. Ein Screenreader würde beides identisch ankündigen. Jedoch ist natives HTML hier robuster: Es funktioniert auch, wenn ARIA-Attribute aus irgendeinem Grund nicht greifen. Die erste Regel von ARIA lautet: keine ARIA-Attribute benutzen, wenn natives HTML dieselbe Aufgabe übernehmen kann. 

Warum sr-only und nicht sichtbar?

Die sr-only CSS-Klasse ist keine Notlösung, sondern eine bewusste Entscheidung. Visuell braucht ein Footer keine Überschrift, seine Position auf der Seite ist Kontext genug, für alle, die die Seite visuell wahrnehmen. Jedoch existiert die Information nur visuell. Für Jana und für andere, die einen Screenreader benutzen, ist die visuelle Position der Überschriften kein ausreichender Kontext. Warum?  Weil mit assistiven Technologien die Seite sequenziell oder per Überschriften-Navigation erlebt wird.   

Mit einer Überschrift <h2 class=”sr-only”> wird dieser Unterschied ausgeglichen. Sie macht für den einen Sinneskanal die Gruppierung der Überschriften explizit, was für den anderen implizit ist. Beide Wege führen am Ende zum gleichen Verständnis des Aufbaus der Seite. 

Warum kein Tool das findet

Automatische Tools sind ein guter Anfang. Sie sind gut darin, Regeln zu prüfen. Ist ein alt -Attribut vorhanden? Haben Buttons einen zugänglichen Namen? Ist der Kontrast ausreichend? Diese Fragen lassen sich maschinell gut beantworten.

Was solche Tools nicht können: verstehen, ob eine Struktur den Erwartungen der Nutzenden entspricht.

Eine fehlende <h2>  im Footer ist keine Hierarchie-Verletzung, die ein automatisiertes Tool finden würde.  Die <h3> Elemente sind technisch korrekte Kinder der letzten <h2> auf der Seite. Das erzeugt keine Warnung, keinen Fehler. 

Ein weiterer Grund, warum Tools hier versagen: Sie prüfen Seiten, keine Nutzungswege.  Jana navigiert nicht von oben nach unten durch den Quellcode. Sie springt von Überschrift zu Überschrift. Sie hört zu – und vergleicht dabei, was sie hört, mit dem was sie sieht. Im Footer weichen die beiden voneinander ab. Das simuliert kein automatisches Tool.

Der Fehler im Footer ist nicht strukturell falsch. Er ist semantisch unvollständig. Und das ist der Unterschied zwischen einer Fehlerliste und einem Verständnis dafür, was Nutzer wirklich erleben.

Nachgedanke 

Jana hat ihr Vorstellungsgespräch am nächsten Tag geschafft. Die paar Sekunden Verwirrung im Footer waren am Ende nur das: ein paar Sekunden. Kein Drama, keine Katastrophe. 

Jedoch genau das macht es einfach, sie zu übersehen. Niemand merkt sich einen Footer, der kurz verwirrend war. Niemand beschwert sich über zehn Sekunden Irritation um 23 Uhr. Diese Art von Reibung hinterlässt keine Spuren, außer bei den Menschen, die sie jeden Tag aufs Neue erleben, auf jeder Seite, bei jedem Footer, der seine Überschrift vergessen hat.

Denn Barrierefreiheit, die nur Fehler vermeidet, ist keine Barrierefreiheit. Es ist eine Checkliste.