Zunächst einmal: Barrierefreiheit im Internet bedeutet, dass Websites und Apps so gestaltet werden, dass (im Idealfall) alle Menschen sie uneingeschränkt – gegebenenfalls unter Zuhilfenahme assistiver Technologien – nutzen können. Vorrangig denkt man bei Barrierefreiheit vielleicht an Menschen mit Behinderung. Daneben profitieren aber auch eine steigende Anzahl älterer Nutzer und auch Menschen mit Verständnisschwierigkeiten aufgrund von sprachlichen Barrieren von einer möglichst barrierefreien Gestaltung von Angeboten im Netz.

Ein Großteil dessen, was es braucht, um Websites und Anwendungen barrierefrei zu machen, besteht darin, sauberes HTML zu schreiben. Der Rest sind inhaltliche Anpassungen. Unter anderem folgende Punkte gehören zu sauberem HTML:

• Native HTML-Elemente nutzen, statt wie häufig alles über <div>-Elemente zu lösen.
• Einen semantisch sinnvollen und gut sichtbaren Tastaturfokus zu haben.
• Den alt-Tag bei Bildern für eine Beschreibung dessen, was auf dem Bild zu sehen ist, zu nutzen.

Testen könnt ihr das zum Beispiel mit Tools wie Tenon.io oder den Chrome-Browser-Extensions Axe, Lighthouse und dem WCAG Accessibility Audit Developer UI.

Ansonsten geht es vor allem Dingen um die generelle Usability. Neben einem durchdachten Design und sauberem Code kann (und sollte) man nach Bedarf

• Untertitel bei Videos hinzufügen,
• Videos mit Gebärdendolmetschern einbinden,
• Inhalte im High-Contrast-Mode anzeigbar machen,
• PDF durch Websites ersetzen (oder durch barrierefreie PDF).

Versucht einfach mal, nur mit Tabulator, den Pfeiltasten und Shift durch eure Website zu navigieren. Wenn ihr immer sehen könnt, wo ihr euch gerade befindet und in der Lage seid, alle interaktiven Elemente – gemeint sind Formelemente wie Input oder Select, Buttons oder Anchors – anzusteuern, ist das gut.

Wenn nicht, hier einige Fast Fixes für euch:

• Grundsätzlich: verwendet native HTML-Elemente, wo möglich und nutzt CSS für deren Styling.
• Der standardmäßige Tastaturfokus richtet sich nach der Reihenfolge der HTML-Elemente in eurem Code. Oft reicht es schon, wenn ihr die Reihenfolge der Elemente im Code ändert und dann mithilfe von CSS das entsprechende Styling macht.
• Das Standard-Styling des Tastaturfokus variiert von Browser zu Browser. Bei manchen hat das fokussierte Element eine blaue Außenlinie. Bei anderen, wie zum Beispiel Firefox, hat es eine gepunktete Linie, die leider oft kaum wahrnehmbar ist. Verlasst euch deshalb nicht auf den Standard-Style, vergebt lieber einen eigenen.

Verwendet eine Überschrift erster Ordnung <h1> je Unterseite – und zwar nur eine. Nur auf der Startseite darf die <h1> das Logo oder den Namen der Seite enthalten. Auf allen anderen Seiten ist <h1> idealerweise der Seitentitel. „t3n | digital pioneers – das Magazin für digitales Business“ wäre auf unserer Startseite als <h1> super, auf allen weiteren aber nicht. Bei Blogposts sollte <h1> äquivalent zum Titel sein, bei Webarchiven dem Titel des Archivs entsprechen. Die anderen Überschriften – <h2> bis <h6> – solltet ihr nutzen, um den Content eurer Seiten zu gliedern, ähnlich wie ihr das in einem Textverarbeitungsprogramm machen würdet. Das heißt nicht unbedingt, dass alle Überschriftenelemente, die ihr verwendet, zwingend eine Überschrift sein müssen. Achtet darauf, keine Überschriften-Level zu überspringen. Überschriftenelemente sind nicht dazu gedacht, Schriftgrößen anzupassen, dafür gibt es die CSS-Eigenschaft font-size. <strong> oder <em>-Tags werden von Screenreadern nicht als Gliederungshinweise interpretiert, zur Kennzeichnung neuer thematischer Abschnitte sind sie deshalb nicht geeignet.

Seit HTML5 gibt die Gliederungselemente <section>, <nav>, <header> und <footer>, die zusätzliche Orientierung bieten. Wo weitere Hinweise mittels ARIA-Attributen (steht für Accessible Rich Internet Applications) gegebenenfalls angebracht sind, gehört zu den Fragen, die euch kein Testing-Tool beantworten wird. Schaut euch euer HTML-Markup an: Ansetzen könnt ihr überall da, wo sich semantische Strukturen aus der visuellen Repräsentation eurer Website ergeben, die euch ein Blick auf den Code aber nicht verrät. Dabei helfen zum Beispiel die Bookmarklets des Accessibility Developer Guide (ADG).

Der ADG bietet eine Menge Vorschläge, wie ihr eure Formulare barrierefreier machen könnt, alle Tipps zu beherzigen, würde aber in den meisten Fällen viel Zeit kosten. Die folgenden zwei Punkte könnt ihr mit minimalem Aufwand befolgen:

• Sowieso Best Practice: Fügt ein <required>-Attribut zu jedem zwingend auszufüllenden Feld hinzu, um das für den Screenreader erkennbar zu machen. Das dafür gängige Symbol * erkennen Screenreader nicht.
• Verseht eure Formelemente mit Labels <label>, die ihre Funktion beschreiben.

Listen können unordered (Bulletpoints), ordered (nummeriert) oder description lists (Begriffe mit Beschreibung) sein. Passt auf, dass ihr keine Listen – welcher Art auch immer – in eurem Code habt, die nur ein Kindelement haben. Ihr wärt auch verwirrt, wenn euch jemand eine Liste ankündigt und dann nur ein Item vorliest.

Im Sinne der Barrierefreiheit sollten interaktive Elemente nach Möglichkeit anchors, buttons und Formelemente sein, keine Container-Elemente mit einem Click-Handler.

In gewinnorientierten Unternehmen hat das Thema oft wenig Priorität, viele Entscheider sehen keinen wirtschaftlichen Mehrwert darin. Entwickler glauben oft, aus zeitlichen Gründen nicht die Möglichkeit zu haben, sich mit Accessibility zu befassen.

Lies auch: Warum digitale Barrierefreiheit für Unternehmen wichtig ist

Eigentlich erübrigen sich viele dieser Punkte oft von selbst, wenn man darauf achtet, sauberes HTML zu schreiben. In der Praxis – vor allem, wenn mit Frameworks wie Vue, React oder Angular gearbeitet wird – ist das dann aber leider nicht mehr ganz so selbstverständlich, weil oft einfach alles in zahllose Containerelemente verpackt wird. Ob eine Website barrierefrei gestaltet ist, entscheiden am Ende sowieso immer die Nutzer. Es ist auch klar, dass so gut wie nie Kapazitäten da sind, alle Dinge zu beachten, die die Nutzer assistiver Technologien bemängeln könnten. Vielleicht helfen unsere Tipps aber, deren User-Experience – und damit auch die aller anderen Nutzer – ein bisschen angenehmer zu machen. Das bringt noch weitere Vorteile: Barrierearme Websites haben oft ein besseres Ranking bei Suchmaschinen und fördern zwangsläufig eine Kultur des Clean Codes.

Weiterlesen könnt ihr im Accessibility Developer Guide oder den Web Content Accessibility Guidelines. Auch bei Medium.com oder A List Apart gibt es viele nützliche Beiträge zum Thema.