Mehr als nur Semantik  

Das Nutzungsszenario für <nav> und Co.

Stilisiertes Beispiel eines Seitenaufbaus von identifizierten Regionen mit dem nav-Element

Wer sich mit HTML5 beschäftigt, trifft auf etliche Elemente, die es in HTML 4.01 nicht gab. Die neueren Elemente besitzen fast immer eine eigene Semantik und oft zahlreiche weitere Features (um die es hier aber nicht geht). In diesem Beitrag geht es um die Semantik von fünf HTML5-Elementen zur Auszeichnung von Regionen auf einer Webseite, die in der Webentwicklung völlig unterschätzt werden.

Eine gut gemeinte Empfehlung

In meiner Time-Line bei Twitter ist mir ein Link auf die Seite von Peter Kröner aufgefallen – ein bekannter HTML5-Spezialist. Schon im ersten Absatz ging es um Barrierefreiheit:

Zitat: “ Ob man sich mit der Verletzung dieser Regeln wirklich einen wahrnehmbaren Nachteil einhandelt, steht freilich auf einem anderen Blatt. Jenseits aller semantischer Theorie besteht der Hauptunterschied zwischen den neuen semantischen HTML5-Elementen und dem guten alten <div> in den bei den neuen Elementen eingebauten Barrierefreiheits-Features →. Ob man auf diese nun gesteigerten Wert legt oder nicht - es spricht nichts dagegen, diese einfach mitzunehmen und statt die <div>-Suppen mit ein paar <nav>- und <section>-Elementen zu dekorieren. Es kostet schließlich nichts.“

Als ich die Anmerkungen zu HTML5 und Barrierefreiheit las, war ich etwas verdutzt. Der Einsatz von semantischen HTML5-Elementen sollte doch vorsichtiger geplant werden und – wenn sie nach dem Gießkannenprinzip gestreut werden – kann das durchaus die Barrierefreiheit kosten. Darauf musste ich antworten:

Danach entstanden eine kleine Diskussion und schließlich dieser Beitrag, denn mit 140 Zeichen pro Tweet wurde mir die Unterhaltung doch zu kleinteilig.

HTML5-Elemente für die strukturelle Navigation

Ich möchte die nachstehenden Ausführungen auf einige wenige HTML5-Elemente beschränken:

  • <aside>
  • <footer>
  • <header>
  • <main>
  • <nav>

Diese Elemente haben vor dem Hintergrund der Barrierefreiheit folgende gemeinsame Merkmale:

  1. Es handelt sich um Elemente, die eine Region einer Webseite semantisch kennzeichnen.
  2. Die Regionen werden von Browsern an den Accessibility-Tree des jeweiligen Betriebssystems übertragen.
  3. Anhand des Accessibility-Trees erstellen Hilfsmittel wie Screenreader ein Bedienkonzept für die Navigation per Tastatur.
  4. Anhand des Accessibility-Trees erzeugen Screenreader zusätzlichen Text zur Identifizierung des Elements.

Wo Webentwickler aufpassen müssen

Bei den genannten HTML5-Elementen kann es zu Problemen mit der Barrierefreiheit kommen, auch wenn die Elemente standardkonform eingesetzt werden. Das hat verschiedene Ursachen:

  1. Nicht alle Browser übertragen Informationen korrekt an den Accessibility-Tree des Betriebssystems
  2. Nicht alle Hilfsmittel verarbeiten Informationen im Accessibility-Tree korrekt.
  3. HTML5 wird nicht so eingesetzt, dass Browser und Screenreader sinnvolle Datenstrukturen für Nutzer vorbereiten können.

Diese Aspekte können lange debattiert werden. Unter dem Strich stehen wir mitten in einer sehr langen Transitionsphase. Am Anfang stand die Idee von Accessible Rich Internet Applications (ARIA), die im letzten Jahr in einen Webstandard mündete und Eingang in die HTML5-Spezifikation fand. Vor etwa 5 Jahren konnten einige ARIA-Attribute genutzt werden und in 2014 konnte mit der Veröffentlichung der HTML5-Spezifikation behauptet werden, dass einige Browser-Screenreader-Kombinationen die Barrierefreiheit der neuen HTML5-Elemente unterstützen. Aber ARIA 1.1 und HTML 5.1 stehen bereits in der Pipeline mit weiteren Anforderungen, sodass der Übergang von HTML 4.01 über mehr Semantik bis zu barrierefreien Webanwendungen noch viele Jahre dauern wird.

Die wahre Bedeutung der Semantik

Das Problem beim „Hineinstreuen“ von neueren HTML5-Elementen in eine Webseite liegt darin, dass der Webentwicklung oft gar nicht bewusst ist, wie sehr dadurch die Nutzbarkeit einer Webseite in einem Screenreader beeinflusst wird. Das möchte ich anhand eines simplen Seitenaufbaus aufzeigen. Dabei sind die Aussagen auf Internet Explorer 11 in Verbindung mit dem Screenreader JAWS 15 beschränkt, wohlwissend, dass andere Browser (mit anderen Accessibility-APIs) und andere Screenreader andere Ergebnisse liefern können.

Dass die 5 HTML5-Elemente <aside>, <footer>, <header>, <main> und <nav> einer Seite mehr Semantik beifügen als beispielsweise ein <div>, ist unbestritten. Aber was bedeutet der Begriff „Semantik“ im Zusammenhang mit HTML5? Im Falle der 5 Elemente zur Abbildung von Regionen auf einer Webseite bedeutet es insbesondere,

  1. dass Screenreader das direkte Ansteuern der Region ermöglichen sollen. In JAWS kann die nächste Region mit der Taste R angesprungen werden (in früheren Versionen von JAWS war es die Taste Ö).
  2. dass Screenreader die Region identifizieren. Vor einer Region mit <nav> fügt JAWS 15 den Text „Navigation Region“ und dahinter den Text „Navigation Region Ende“ ein. Diese Identifizierung ist unabhängig davon, wie ein JAWS-Nutzer navigiert (z.B. Taste R oder Pfeiltasten).

Der folgende Seitenaufbau ist standardkonform, müsste aber für die barrierefreie Nutzung verbessert werden:

<header>
    <p>Inhalt des Banners</p>
</header>
<nav>
    <nav>
        <p>Inhalt der Hauptnavigation</p>
    </nav>
    <nav>
        <p>Inhalt einer sekundären Navigation</p>
    </nav>
</nav>
<div>
    <p>Irgendein Text</p>
</div>
<main>
    <H1>Überschrift der Seite</h1>
    <p>Erster Absatz der Seite.</p>
</main>
<footer>
    <p>Eine Fußzeile</p>
</footer>

In JAWS 15 in Verbindung mit Internet Explorer 11 erhält der Nutzer folgenden Inhalt:

Inhalt des Banners
Navigation Region
Navigation Region
Inhalt der Hauptnavigation
Navigation Region Ende
Navigation Region
Inhalt einer sekundären Navigation
Navigation Region Ende
Navigation Region Ende
Irgendein Text
Haupt Region
Überschrift Ebene 1 Überschrift der Seite
Erster Absatz der Seite.
Haupt Region Ende
Eine Fußzeile

Hinweis: In JAWS 15 können mit der Taste R im Internet Explorer 11 nur die drei Navigationselemente sowie der Hauptinhalt angesprungen werden.

Strukturelle Navigation in JAWS: Liste der Regionen (3 mal Navigation und 1 mal Haupt)

Lösungen

Im Einzelnen stellt diese Aufteilung der Seite in Regionen folgende Probleme dar:

  • Das <header>-Element wird nicht identifiziert und ist in der strukturellen Navigation nicht ansteuerbar. Es ist auf die ARIA-Rolle „banner“ zurückzugreifen.
  • Die Verschachtelung von Regionen wie bei den <nav>-Elementen führt zu redundanter Semantik und überflüssigen Regionen in der strukturellen Navigation. Für die barrierefreie Nutzung sollte im Allgemeinen auf Verschachtelungen verzichtet werden (auch wenn es Ausnahmen gibt). Das umfassende <nav>-Element sollte mit einem generischen <div>-Element ersetzt werden.
  • Die Navigationsregionen sind in der strukturellen Navigation nicht unterscheidbar. Mindestens eines der beiden übriggebliebenen <nav>-Elemente sollte beschriftet werden, was z.B. mit dem aria-label-Attribut geht.
  • Texte, die nicht in einer Region stehen, werden bei der strukturellen Navigation eines Screenreaders übersprungen. Sämtliche Inhalte einer Webseite sollten innerhalb einer identifizierenden Region stehen. Hier können wir das <aside> statt des <div>-Elements einsetzen.
  • Das <main>-Element wird identifiziert und kann mit der strukturellen Navigation angesprungen werden. Die ARIA-Rolle „main“ kann vorsichtshalber zur Seitenstruktur hinzugefügt werden (für diese Browser-Screenreader-Kombination ist das nicht erforderlich).
  • Das <footer>-Element verhält sich genauso wie das <header>-Element. Hierfür gibt es keine Rolle in ARIA 1.0 (die Rolle „contentinfo“ ist nicht für Fußzeilen vorgesehen), sodass ein <nav>-Element mit einer Beschriftung genutzt werden sollte.

Hinweis: Die Semantik der HTML5-Elemente im Beispiel ist durch Rollen aus der ARIA-Spezifikation vorgegeben. Über den Zusammenhang von HTML5 und ARIA hatte ich im letzten Jahr geschrieben: Die Vergabe von Rollen mit ARIA funktioniert in vielen Fällen besser als mit HTML5.

Ergebnis

Wenn das HTML überarbeitet wird, dann kann der Seitenaufbau wie folgt aussehen:

<header role="banner">
    <p>Inhalt des Banners</p>
</header>
<div>
    <nav>
        <p>Inhalt der Hauptnavigation</p>
    </nav>
    <nav aria-label="Persönliches Menü">
        <p>Inhalt einer sekundären Navigation</p>
    </nav>
</div>
<aside>
    <p>Irgendein Text</p>
</aside>
<main role="main">
    <H1>Überschrift der Seite</h1>
    <p>Erster Absatz der Seite.</p>
</main>
<nav aria-label="Fußzeile">
    <p>Eine Fußzeile</p>
</nav>

Das Ergebnis in JAWS 15 ist jetzt deutlich besser.

Liste der Regionen in JAWS: Banner, Navigation, Persönliches Menü Navigation, Ergänzende Information, Haupt, Fußzeile Navigation

Zum einen lassen sich alle Regionen mit der strukturellen Navigation anspringen (Taste R) und zum anderen sind die einzelnen Regionen besser unterscheidbar. Wenn das Dokument vollständig gelesen wird, erhält der Nutzer folgende Inhalte:

Banner
Inhalt des Banners
Banner Ende
Navigation Region
Inhalt der Hauptnavigation
Navigation Region Ende
Persönliches Menü Navigation Region
Inhalt einer sekundären Navigation
Persönliches Menü Navigation Region Ende
Ergänzung
Irgendein Text
Ergänzung Ende
Haupt Region
Überschrift Ebene 1 Überschrift der Seite
Erster Absatz der Seite.
Haupt Region Ende
Fußzeile Navigation Region
Eine Fußzeile
Fußzeile Navigation Region Ende

Wandel der Zeit

Obwohl das Web sich angeblich rasant entwickelt, ist die Implementierung von Webstandards und insbesondere die Barrierefreiheit doch ein langsamer Prozess. Bereits 2009 konnte man lesen, dass ARIA den Durchbruch bald schaffen würde, aber nach meiner Beobachtung ist die Unterstützung in Browsern immer noch nicht vollständig. Gleiches gilt für HTML5 und die Barrierefreiheit. Die Ursachen sind – wie immer – vielfältig; aber bis heute überträgt kein Browser die Semantik in HTML5 vollständig an den Accessibility-Tree.

Was in diesem Komplex noch gar nicht erwähnt wurde, sind ältere Screenreader und andere Hilfsmittel wie die unterstützende Sprachausgabe eines Vergrößerungssystems oder die Spracheingabe, die deutlich weniger Unterstützung für ARIA und HTML5 bieten als aktuelle Screenreader. Dass Hilfsmittel den Webstandards hinterherhängen und dass Nutzer nicht immer auf den aktuellen Stand der Technik sind, muss leider ebenfalls immer wieder festgestellt werden.

Anleitungen und Dokumentationen im Web zum barrierefreien Einsatz von HTML5-Elementen gibt es nicht viele. Die erste Anlaufstelle (wenn es nicht die HTML5-Spezifikation selbst sein soll) ist www.html5accessibility.com. Und, obwohl die Informationen dort regelmäßig aktualisiert werden und die Aussagen vertraut werden können, sind dort Abweichungen zur realen Zugänglichkeit festzustellen:

HTML5-Unterstützung von Eingabehilfen in gängigen Browsern, hier aufgeführt  der Bereich: „nav“. Safari 8, Chrome 43 und Firefox 38 unterstützen, IE11 unterstützt nicht. Für den Browser Edge ist keine Angabe vorhanden.
Stand: 15. Juni 2015

In dieser Tabelle wird dokumentiert, dass die fünf HTML5-Elemente für Regionen vom Internet Explorer nicht unterstützt werden. Demnach müsste das <nav>-Element mit der Rolle „navigation“ ergänzt werden:

<nav role="navigation"> … </nav>

Richtig ist, dass der Internet Explorer die Informationen nicht an den Accessibility-Tree überträgt. Trotzdem unterstützt JAWS zusammen mit dem Internet Explorer Regionen seit vielen Jahren – sowohl die Identifizierung als auch die strukturelle Navigation, nur leitet JAWS die Datenstrukturen offenbar direkt aus dem Browser ab. Gleichzeitig muss auch festgestellt werden, dass die Semantik der HTML5-Elemente zur Festlegung von Regionen in Webkit-Browsern trotz „formaler Unterstützung“ in der Praxis nicht richtig funktioniert.

Die verfügbaren Informationen zur Barrierefreiheit von HTML5-Elementen sind nicht immer vollständig an einer Stelle im Web zu finden. Es ist daher nicht verwunderlich, dass Webentwickler kein klares Bild von der Barrierefreiheit haben. Es sollte aber auch deutlich sein, dass Barrierefreiheit beispielsweise nicht mal eben mit ein paar HTML5-Elementen im Code einfach „mitgenommen“ werden kann, denn die Zugänglichkeit und Nutzbarkeit hängt doch von vielen weiteren und teilweise nicht offensichtlichen Aspekten ab.

Nichts desto trotz kann und soll HTML5 zur Anreicherung einer Webseite mit semantischen Informationen eingesetzt werden, denn die Vorteile überwiegen – es geht immerhin um die Nutzbarkeit der Webseite. Allerdings muss die Semantik mit Bedacht eingesetzt werden, denn es geht um deutlich mehr als leichter lesbaren Code. Mit dem sinnvollen Einsatz von HTML5-Elementen kann die Barrierefreiheit heute in Teilen und für die Zukunft zunehmend sichergestellt werden.

11 Gedanken zu “Mehr als nur Semantik – Das Nutzungsszenario für <nav> und Co.

  1. Ein paar Bemerkungen zu der Problemliste:

    > Das <header>-Element wird nicht identifiziert und ist in der strukturellen Navigation nicht ansteuerbar.

    Wie du selbst schon erwaehnst, ist das ein Problem mit Internet Explorer. JAWS mit Firefox erkennt <header>. Fuer IE nutzer, ist der <header> eben genauso „unsemantisch“ wie ein <div>. Der Artikel vom Peter meinte ja nicht, dass diese Elemente Allheilmittel sind, sondern dass es (in guterzogenen browsern) positive „Nebenwirkungen“ gibt, jenseits vom guten „oh ich mach jetzt auf semantisch“. Explizit dann ein role=“banner“ hinzuzufuegen ist eben zur nachtraeglichen unterstuetzung in alten/kaputten Browsern, und hat weniger damit zu tun, ob <header> besser als <div> ist.

    > * Die Verschachtelung von Regionen wie bei den <nav>-Elementen führt zu redundanter Semantik und überflüssigen Regionen in der strukturellen Navigation.

    Das ist dann eher Geschmackssache wuerd ich Sagen. Und genauso problematisch ist es mit jedem anderen HTML element (dreifach verschachtelten Listen, zum Beispiel). Auch hier, nichts neues und nichts was jetzt dem Statement vom Peter zusammenhaengt. Und man kann sich ja auch streiten darueber, ob eine etwas „verbose“ Struktur, die trotzdem aussagt, dass bestimmte Teile zur Navigation gedacht sind, besser ist als eine komplett unsemantische anhaufung von <div>s und <span>s.

    > * Die Navigationsregionen sind in der strukturellen Navigation nicht unterscheidbar. Mindestens eines der beiden übriggebliebenen <nav>-Elemente sollte beschriftet werden, was z.B. mit dem aria-label-Attribut geht.

    Klar, aber wie schon erwaehnt, ist es meiner Ansicht nach wenigstens immer noch besser, dass diese Regionen wenigstens als Navigation gekennzeichnet sind. Diese dann unterscheidbar zu machen macht’s natuerlich besser, aber wie der Artikel schon meint schadet es nicht, wenigstens die „basics“, die mit den strukturellen Elementen mitkommen (dass Screenreader diese als Navigation erkennt), zu benutzen. Immer noch besser als s.

    > Texte, die nicht in einer Region stehen, werden bei der strukturellen Navigation eines Screenreaders übersprungen.

    Ich haette schwoeren koennen, dass die Spezifikation sich dazu in einer „Note“ aeussert…kanns aber auf Anhieb nicht finden.

    > Das <main>-Element wird identifiziert und kann mit der strukturellen Navigation angesprungen werden, aber dieses Element wird erst mit HTML 5.1 offiziell zum Webstandard gehören

    Es scheint mir, dass das <main> Element wohl in HTML5 schon drin ist. http://www.w3.org/TR/html5/grouping-content.html#the-main-element

    > Das <footer>-Element verhält sich genauso wie das <header>-Element.

    Und wie beim <header> ist das ein Problem mit IE, nicht mit dem Standard – andere Browser/AT haben da kein Problem.

    > Hierfür gibt es keine Rolle in ARIA 1.0 (die Rolle „contentinfo“ ist nicht für Fußzeilen vorgesehen)

    Der Spezifikation zu Folge doch http://www.w3.org/TR/html5/dom.html#sec-strong-native-semantics

    1. Deine Ausführungen überraschen mich ein wenig, auch wenn du auf langer Sicht Recht bekommen wirst. Nur:

      * Auch der standardkonforme Einsatz von HTML5 führt manchmal zu nicht brauchbaren Seiten.
      * Du gehst von aktueller Software aus. Das ist Screenreadernutzern oft nicht vergönnt.

      Ich bin mir sicher, dass du diese Aspekte genauso kennst wie ich.

      Zu deinen Anmerkungen:
      „… sondern dass es (in guterzogenen browsern) positive „Nebenwirkungen“ gibt, jenseits vom guten „oh ich mach jetzt auf semantisch“.“

      Kann passieren, aber auch nicht. „Semantisch“ im Code heißt noch lange nicht, dass die Inhalte im Screenreader nutzbar sind. Gerade deswegen gibt es die Web Content Accessibility Guidelines. Wenn Elemente die auslesende Software steuern, sollten sich Webentwickler dessen bewusst sein und nicht z.B. nach ästethischen Maßstäben die Semantik bestimmen.

      „Das ist dann eher Geschmackssache wuerd ich Sagen.“

      Natürlich gibt es immer verschiedene Lösungswege für Code. Auch hier ist meine Aussage aber anders: Semantik hin oder her, wenn zu viel eingesetzt wird, wird es unübersichtlich im Screenreader. Ich beobachte das jeden Tag. Geschmackssache ist das nicht, sondern eine Anforderung an die Frusttoleranz der Nutzer. Außerdem sollten die Strukturen im Code das wiedergeben, was am Bildschirm zu sehen ist:
      http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html

      „besser, dass diese Regionen wenigstens als Navigation gekennzeichnet sind.“

      Ja, das stimmt. Wenn aber mehre gleichartige Regionen auf einer Seite stehen, dann werden an Screenreadernutzer wesentlich höhere Anforderungen gestellt als an sehende Nutzer. Die Bezeichnung von Regionen ist nicht nur Best-Practice
      http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/ARIA13
      sondern auch nicht sonderlich schwer zu vermitteln oder umzusetzen.

      „Ich haette schwoeren koennen, dass die Spezifikation sich dazu in einer „Note aeussert… “

      Vielleicht meinst Du das:
      http://www.w3.org/TR/wai-aria-practices-1.1/#kbd_layout_landmark_XHTML
      Punkt 1 empfiehlt eine Iteration, was in der Tat meine Aussage widerspricht.

      „Es scheint mir, dass das <main> Element wohl in HTML5 schon drin ist.“

      Wo du recht hast, hast du recht. Das habe ich auch schon mal gewusst:
      https://www.barrierefreies-webdesign.de/referenz/html-elemente.html
      Den Text habe ich angepasst.

      „Hierfür gibt es keine Rolle in ARIA 1.0 (die Rolle „contentinfo“ ist nicht für Fußzeilen vorgesehen)“

      Nach der ARIA-Spezifikation
      http://www.w3.org/TR/wai-aria/roles#contentinfo
      soll es nur ein contentinfo pro Seite geben (z.B. für Copyright-Hinweise) und wenn im DOM mehrere Dokumente enthalten sind, sollte mit aria-owns gearbeitet werden. Auf der von dir zitierten Seite

      “ Der Spezifikation zu Folge doch http://www.w3.org/TR/html5/dom.html#sec-strong-native-semantics

      wird darauf hingewiesen, dass die strong native semantics mit role=“presentational“ ggf. zu entfernen sind.

  2. Ihr diskutiert an der Zielgruppe des Ursprungsartikels vorbei. Solche Fragen kommen Peter oft bei Schulungen unter und die hält er meist vor Enterprise-Entwicklern, also Java-Entwicklern, die auch ein wenig Frontend machen müssen. Da ist es schon toll, wenn jemand von Barrierefreiheit gehört hat und Interesse heuchelt. Da ist es auch schon toll, wenn der Sinn hinter der Semantik verstanden wird.

    Diesen Entwicklern kann man auch in meinen Augen sagen, dass man einen Zusatznutzen bekommt, wenn man die neuen Elemente nutzt. Dass es Browser gibt, die damit gut umgehen und welche, die damit schlecht umgehen, ebenso wie manche Screenreader nicht gut sind, ist vollkommen klar. Das interessiert diese Entwickler aber nicht, weil es nicht in ihrem Fokus ist und nie sein wird.

    Wenn man ihnen aber sagt, ihr macht etwas Gutes, wenn ihr die neuen Elemente nutzt, dann ist das Erstens nicht falsch und zweitens schafft es beim Einen oder Anderen Interesse.

    Und Deine Antwort, Jan, zeigt zudem ein Grundproblem, das wir mit Accessibility in Deutschland haben: es muss immer gleich perfekt sein und alle Eventualitäten müssen berücksichtigt werden. Es ist doch nichts gewonnen, wenn alle Welt weiterhin DIVs nutzt, nur weil sie sich nicht zusätzlich zum widerstreitenden Verhalten der ganzen normalen Browser und Smartphone-Browser nicht auch noch mit Browser/Screenreader-Kombinationen auseinandersetzen wollen.

    Das englsiche Wort sagt es schon richtig: eine Seite soll accessible, also zugänglich, sein. Im Deutschen müssen wir wieder einem Überperfektionismus fröhnen und eine Seite barrierefrei machen. Frei von jeglichen Barrieren – welch eine Anmassung und welch ein Blödsinn.

    Nach so vielen Jahren des Trommelns solltest Du eigentlich froh sein, dass man Accessibility nebenbei mit eine Seite einfliessen lassen kann. Wenn dann manche Screenreader das korrekt interpretieren und manche nicht, dann ist das ein Problem der Hersteller. Sollte ein Entwickler Interesse entwickeln, kann er sich ja gerne damit beschäftigen.

    Und vielleicht sollten Leute wie Du Screenreadernutzer dazu aufrufen, bessere Screenreader zu nutzen bzw. bessere Browser/Screenreader-Kombinationen. Die technische Lage wird für Euch nicht besser werden. Ich glaube nicht, dass es eine schwunghafte Verbesserung hin zu einem barrierefreieren Netz geben wird. Dann ist es doch eine Sache der Selbsthilfe, die bessere Software zu nutzen und nicht die, die man schon immer nutzt, die aber schlecht ist.

    1. Den ersten Teil deiner Antwort sehe ich auch so. Im zweiten Teil regst du dich zu Unrecht auf.

      1. Etwas gutes tun. Nun, wenn es richtig gemacht wird, habe ich kein Problem damit. Aber leider entspricht das nicht immer der Realität und oft genug leidet die Zugänglichkeit darunter. Ich kann Dir jenseits dieses Kommentars gerne Beispiele liefern.

      2. Barrierefreiheit und Web Accessibility. Es sind gleichbedeutende Begriffe. Man möchte gerne Barrierefreiheit berücksichtigen – nicht zuletzt wegen der Kundenanforderungen. Aber: Die meisten Webentwickler, die ich hierzulande beobachte, möchten sich vielleicht doch nicht soweit in die Materie vertiefen, damit eine Website accessible ist. Das kannst auch du jeden Tag beobachten. Du verkennst die Situation: Es geht um Minimalanforderungen, nicht Maximalanforderungen.

      3. Froh sein. Stimmt, heute werden Überschriften und einiges mehr eingesetzt. Aber das Web hat sich in den letzten 10 Jahren weiter entwickelt und leider sind die Probleme heute größer als damals. Tabellenlayouts und fehlende Überschriften waren noch zugänglich, Du weißt was ich meine, ja? Heute sind viele Seiten nur zur Hälfte lesbar oder per Tastatur nicht nutzbar. Und dann gibt es die Overkills, die unheimlich viel Semantik produzieren, wo aber rein gar nichts ist. Und das kann ich nicht einmal selbst kontrollieren, denn nur ein Sehender kann bestätigen, dass der Code was vermittelt, das nnicht da ist. Gerade in .de ist die Barrierefreiheit auf einem niedrigen Niveau. Große Anbieter wie Ebay bis Audible sind zugänglich und nutzbar, das stimmt, aber oft sind deutlich einfachere Seiten nicht einmal zugänglich. Und mit Verlaub: Wie kommst Du darauf, dass ich froh sein sollte? Das allermeiste ist doch weniger zugänglich als vor 10 Jahren, und das nach so vielen Jahren des Trommelns.

      4. Screenreadernutzer aufrufen. Was meinst Du, was ich tue? Ich bringe das bei jeder Gelegenheit zur Sprache, in verschiedenen Verbänden, bei verschiedenen Personen, usw. Die Leute müssen auf moderne Software wechseln und vor allem brauchen sie viel Schulung. Das will bezahlt werden, nur leider sinkt bei diesem Thema das Interesse. In den Vereinen habe ich jahrelang Schulungen dieser Art organisiert, aber es ist ehrenamtlich und mehr als zwei solcher Schulungen pro Jahr sind nicht drin. Jetzt mache ich das nicht mehr, weil es unter dem Strich Computerschulungen sind, die nicht nur die Einweisung im Screenreader, sondern auch in ein neues Betriebssystem, neue Office-Anwendungen u.v.m. bedeutet, und an einem Wochenende nicht getan ist. Berufstätige erhalten im Übrigen bis zu drei volle Wochen Schulung vom zuständigen Träger bezahlt, wenn sie sich nach fünf Jahren „upgraden“.

      Jens, ich glaube, Du unterschätzt die Problematik. Deutschland ist in Sachen Barrierefreiheit nachwievor ein Entwicklungsland. Jede Woche veröffentlicht der Bund (!) neue Apps und Webseiten, die nicht einmal mit dem iPhone bedienbar sind. Sogar in der Behindertenszene werden Webseiten veröffentlicht, die den minimalsten Anforderungen (z.B. Überschriften, Alternativtexte) nicht berücksichtigen – es interessiert halt keinen. Und wenn Entwickler ein Paar <div>-Elemente mit &nav>-Elementen ersetzen, wird das bestenfalls ein Tropfen auf dem heißen Stein. Es geht um wesentlich mehr, wenn – wie Du schreibst – Zugänglichkeit erreicht werden soll. Über die Nutzbarkeit können wir vielleicht zu einem späteren Zeitpunkt diskutieren.

      In den Köpfen in .de steckt immer noch der Fürsorgestaat ebenso wie die Haltung, dass man als Mensch mit einer Behinderung über Almosen froh sein soll.

  3. Ich gebe dir Recht, Eric, in Sachen Behindertenpolitik sind „eigentliche Selbstverständlichkeiten“ hierzulande ja immer noch große Aufgaben, für die dann entweder kein Geld oder kein sonstwas vorhanden ist, was fast immer „kein Interesse“ bedeutet. Das hat aber nichts mit deiner ursprünglichen Gegenargumentation zu tun, die HTML5 nicht auf Grund der Standards, sondern auf Grund der Ausgabe bewertet.

    Es geht in weiten Teilen nicht einmal um den „doitschen 100%-Qualitätsanforderungsstandardzwang“, sondern um die Tatsache, dass ein Standard in seiner Interpretation nicht oder nicht standardkonform interpretiert (!) wird. Kurz gesagt: ich möchte und will doch kein – oder sonstiges HTML5-Element in ein zusätzliches DIV zu packen, weil das der IE11 im Zusammenspiel mit JAWS (noch) nicht kann. Nicht aus Kadavergehorsam einem HTML-Standard gegenüber, sondern aus Gründen der Logik und des Verstandes. Ich würde mich ebenso weigern, einen gut verpackten Gegenstand zusätzlich in eine klimadichte Holzkiste zu packen, nur weil das Logistikunternehmen mir mitteilen würde, alle Waren würden bei ihnen nur in offenen Anhängern transportiert werden. Da wäre meine Antwort „Euer Problem“, beziehungsweise ein anderer Anbieter bekäme den Auftrag.

    Die eigentlich Tragik liegt ja darin begründet, dass das Problem der nicht auf neuestem Stand stehenden Screenreader schon vor gut 12 Jahren ein Thema war, als ich begann, mich mit Barrierefreiheit ernsthaft auseinanderzusetzen. Peter hat recht: HTML5 unterstützt Barrierefreiheit besser als die alten Standards. Und er behielte auch dann recht, selbst wenn heute kein einziger Browser oder Screenreader diese Features korrekt interpretieren würden.

    Im Zweifel würde ich die Praxis wie bei allen anderen Aspekten auf das Projekt abstimmen. Weiss ich, dass eine für das Angebot wichtige Zielgruppe mit zudem veralteten Screenreadern das Webangebot nutzen wollte, dann – und nur dann – würde ich auch ein nav-Element in ein DIV packen. Ich würde auch auf HTML5 komplett verzichten, sofern die Zielgruppe hauptsächlich aus Nutzern von alten und uralten IEs mit abgeschaltetem Javascript bestünde. Für den Normalfall, also die absolute Mehrheit der Projekte, werde ich so etwas nicht tun.

    1. Zu Deiner Anmerkung zu einem <nav> in einem <div>:

      Ich habe zwei Screenshots im Beitrag eingefügt, um die strukturelle Navigation zu zeigen. Die „Verweigerung“, die Regionen in einem <div> zu verschachteln, hat nichts mit Kompatibilität zu tun. Die Struktur der Seite wird in einem Screenreader lediglich schlechter dargestellt.

  4. Zum Kontext nochmal: diese ganze Diskussion enstand deswegen, weil Peter nur ganz gutgemeint vorschlug, anstatt immer nur <div>s zu benutzten doch auch mal die semantischen <header> und co. weil sie positive Nebenwirkungen in Sachen Barrierefreiheit haben. … und dann die doch recht arrogante Bemerkung von dir darauf „Für @sir_pepe gehört die Barrierefreiheit nicht zu den Webstandards“ (und dann heute meinen Kommentar oben als „Minimale Anforderung an Webentwickler, maximale Anforderungen an Nutzer“ zusammenzufassen). Es mag ja sein, dass du das nicht so meinst wie es sich liest…aber dann (ohne jetzt auf „tone-police“ zu machen) doch bitte nicht die Worte anderer Leute so versimpeln und verzerren.

  5. Man kann Jans Aussage auf Twitter sicher in den falschen Hals bekommen, so wie sie formuliert war. Persönlich interpretiere ich das aber eher entspannter, da mir klar ist, dass man auf Twitter gerne mal besonders „kurz und knackig“ formuliert – auch um Aufmerksamkeit für einen Gedanken zu bekommen. Daher plädiere ich für Entspannung, ihr gehört doch allesamt zur guten Seite der Macht 😉

    Zum Thema an sich:
    Ich finde Jans Beispiele oben gut und wichtig. Sie zeigen insbesondere unerfahreneren – aber interessierten – Frontend-Entwicklern, wo momentan noch Schwierigkeiten/Schwächen bei der rein semantischen herangehensweise an HTML5-Elemente ist und wie man das beispielhaft verbessern könnte.

    Ich kann mich aber auch sehr gut mit Peters Herangehensweise identifizieren, nach dem Motto „besser ein bisschen, als gar nichts“. Das ist wie das Pflanzen eines kleinen Pflänzchens. Wenn man keine Möglichkeit hat, einen Garten zu pflanzen, dann wenigstens immerhin ein Pflänzchen. Macht die Sache schon mal ein kleines Stück weit besser und ist oft der Einstieg um doch mehr Interesse hervorzurufen.

    Bei Contao wurden deshalb bestimmte Hilfen für die Barrierefreiheit in die Standardausgabe fürs Frontend eingefügt. Die sind nicht perfekt und werden von erfahrenen BF-Nutzern wie mir ggf. sogar wieder entfernt und umgebaut … aber für die tausenden Contao-Seiten da draußen, die von Accessibility unerfahrenen/-interessierten Frontend-Entwicklern gebaut werden, ist es trotzdem eine Verbesserung. Nicht perfekt, aber eben ein Schritt. Parallel versucht man dann immer wieder das Thema anzusprechen (auf Konferenzen, in Workshops, Forenbeiträgen, etc) und die Frontend-Entwickler zusätzlich aufs Thema aufmerksam zu machen.

    Oder auch bei Schulungen: Wenn ich allgemein Online-Redakteure oder Webdesigner schule, ist meist keine Zeit da um das Thema Barrierefreiheit ausführlich anzugehen. Deshalb lasse ich dann zumindest ein paar Punkte hier und da mit einfließen. Einfach um eine Saat auszustreuen.

    Bei Peters Herangehensweise ist es doch so:

    Im schlechtesten Fall, setzen die Zuhörer dann aufgrund fehlenden Interesses/Zuhörens HTML5-Semantik ein und machen dabei ggf. Fehler. Shit happens. Schlimmer als das, was sie vorher gemacht hätten, wird es nicht sein.

    Im normalen Fall, haben sie nach so einem Hinweis zumindest ein klein bisschen Interesse und setzen die HTML5-Semantik halbwegs ein. Dann können diese kleinen Verbesserungen schon reale Vorteile für Besucher der Websites bringen. Nicht perfekt, aber eben hier und da Verbesserungen.

    Im besten Fall regen diese Hinweise 1 oder 2 Entwickler dazu an, sich das Thema doch mal genauer anzusehen und sich tiefer ins Thema reinzugraben. Dann gibt es bessere Ergebnisse und deutliche Accessibility-Vorteile.

    Tatsache ist aber auf jeden Fall: Es wird nicht schlechter. Sondern so oder so ein bisschen besser. Und das in einem Bereich, wo ohne solche Hinweise sonst gar nix passiert wäre.

    Also: Ich votiere ganz klar für Realismus. Wenn man in Branchen agiert, wo man davon ausgehen muss, dass ein großer Teil der Zielgruppe – aus welchen Gründen auch immer – kein Interesse an Barrierefreiheit hat, muss man sie ihnen zumindest stückchenweise hintenrum reinschaufeln. Ist nicht schön, nicht ganz politisch korrekt, aber es erfüllt den Zweck, dass es kleine Verbesserungen im Internet gibt. 😉

  6. Hallo zusammen: Ich wurde gerade auf diese Diskussion von einem Kunden aufmerksam gemacht. Nachdem ich Peters Beitrag, Jan Erics Antwort und die ganzen Kommentare gelesen habe, möchte ich auch noch mein Statement abgeben.

    1. Ich glaube auch, dass die Diskussion sich verselbstständigt hat und mit dem ursprünglichen Beitrag von Peter auf seinem Weblog de facto nichts mehr zu tun hat. Peter adressiert mit seinem gewohnt „locker“ formulierten Text hauptsächlich Leute, die Semantik in der Regel nicht interessiert. Sein Fazit verstehe ich so: Ein bisschen Semantik schadet nicht. Das kann man glaube ich komplett unterschreiben. Wobei ich die Betonung auf „bisschen Semantik“ legen möchte. Und dann eben auch korrekt angewendet.

    2. Jan Erics Ausführungen gehen wie immer deutlich weiter und sind für jeden, der sich ernsthaft mit dem Thema Barrierefreiheit auseinandersetzt Gold wert. Denn die tiefen Einblicke in die Funktionsweise von Screenreadern (und Accessibility-APIs) schaffen Know-how-Transfer, das anderweitig auch für Experten ohne Zugriff auf unterschiedliche assistive Technologien kaum zu bekommen ist. Ich nutze regelmäßig selbst den NVDA Screenreader zum Testen. Aber eben nicht als Poweruser mit sämtlichen Tastaturbefehlen, sondern so wie man eben ein solches Werkzeug benutzt, wenn man nicht täglich darauf angewiesen ist. Ich möchte also Jan Eric (und Co.) an dieser Stelle für seinen ständigen Input danken.

    3. Jan Erics Warnung, so möchte ich es mal nennen, bezieht sich nach meinem Verständnis auf die Gefahr, die besteht, wenn man HTML5 Semantik und ARIA-Anreicherungen in Kombination nach dem Gießkannenprinzip über eine Webseite oder Applikation ausschüttet. Denn mal ehrlich, die wenigsten wissen doch wirklich, was ein Screenreader seinem Benutzer alles an „Meta-Informationen“ – neben dem reinen Content – vorliest. Bis zu einem gewissen Grad sind Strukturinformationen für Screenreader-Nutzer eben hilfreich. Aber ab einer gewissen Überfüllung wird eben tatsächlich das Gegenteil erreicht und eine Seite ist praktisch nicht mehr nutzbar. Viel hilft viel – stimmt eben nicht.
    4. Sind Internetseiten und Applikationen heute durch den Einsatz von HTML5 und ARIA barrierefreier als HTML 4.01 Auftritte der alten Generation, die neben Content-Semantik (Überschriften, Listen, Formulare, Links) kaum Hilfen zur Orientierung geboten haben, und in denen versteckte Überschriften und versteckte Hilfetexte die Lücke gefüllt haben? Eben nicht. Denn die HTML 4.01 Auftritte der alten Generation haben fehlende Struktur-Semantik durch einen in der Regel vergleichsweise einfachen Seitenaufbau kompensiert. Hinzu kam mit Sicherheit eine striktere Trennung von Inhalt und Design als heute (Stichwort: Icon-Fonts, CSS-Background-Images, CSS generierter Content für Pseudo-Elemente, etc). Rich Internet Applikations zu BITV1.0 Zeiten? Gab es doch kaum. DIV-Höllen? Vielleicht, aber solange die Überschriften-Outline Screenreader unterstützte und auf Tastatursteuerung (und auf versteckte Hilfetexte) geachtet wurde, Content-Semantik stringent eingesetzt und Alternativ-Texte sinnvoll vergeben wurde, war doch hinsichtlich Barrierefreiheit schon sehr viel erreicht. Die meisten Internetauftritte waren keine Rich Internet Applikations und relativ linear und für Screenreader-Nutzer vergleichsweise selbsterklärender (hinsichtlich ihres Aufbaus) und strukturell verständlicher (Falls ich mich irre, schlagt mich nicht). Heute lauern Gefahren an so vielen Ecken, dass ich glaube, dass barrierefrei nicht nur kein Selbstläufer ist, sondern durchaus gefährdet ist. Und so verstehe ich auch Jan Erics Ausführungen.

    5. Trotzdem muss ich Jan Eric an einer einzigen Stelle widersprechen. Ich halte es für verkehrt, ein HTML5-Element zu missbrauchen, „nur“ weil ein Screenreader darüber kein Feedback bekommt. Das ist für den Screenreader-Nutzer natürlich unschön, aber für mich kein Grund aus dem <footer>-Element ein <nav>-Element, oder irgendetwas anderes zu machen (Wäre hier stattdessen nicht ein ARIA-Label sinnvoll?). Die Ich-mach-da-mal-ein-NAV-Element-draus-Herangehensweise führt ja auch dazu, dass gelegentlich Formular Elemente in ein <p> gewrappt werden, um dem Formular mehr Semantik zu verleihen. Ich weiß, dass diese Vorgehensweise für Screenreader-Nutzer wohl ganz nützlich sein soll. Trotzdem wird aus einem Formularelement dadurch kein semantischer Paragraph. Ich hoffe, ich lehne mich hier nicht zu weit aus dem Fenster. Ich bin kein W3C-Guru. Beste Grüße aus Düsseldorf.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert