3 Gründe, warum auch Web-Entwickler:innen von Barrierefreiheit profitieren

Erstellt am 27.11.2022

Web-Barrierefreiheit ist ein ethisches Gebot und wirtschaftlich sinnvoll. Ihr unterstützt die Inklusion von Menschen mit Behinderung und erreicht damit potenziell mehr Kund:innen. Dennoch, als Web-Entwickler:in denkt ihr euch vielleicht: „Das ist super für meine Firma und die ganze Gesellschaft. Aber für mich heißt es noch mehr Arbeit!“

Ich kann euch verstehen! Das Thema Barrierefreiheit kann am Anfang ganz schön überwältigen. Und ich gebe zu, manche Sachen wie ARIA Live-Regionen bereiten tatsächlich etwas mehr Arbeit. Doch ich verrate euch ein kleines Geheimnis: Barrierefreier Code wird euer Leben als Web-Entwickler:in einfacher machen und euch langfristig viel Zeit sparen!

Eine Web-Entwicklerin sitzt am Arbeitsplatz mit drei Monitoren. Auf einem Bildschirm sind Code-Zeilen zu sehen. Foto: © ThisIsEngineering / pexels.com

Ihr glaubt mir nicht? Dann lest einfach die folgenden drei Gründe, warum mit Barrierefreiheit alles besser ist.

1. Semantisches Markup ist leicht lesbar und wartbar

Semantisches Markup vermittelt Informationen über die Bedeutung von Elementen nicht nur an assistive Technologien. Es vermittelt diese Bedeutung auch den Entwickler:innen, die den Code lesen, bearbeiten und umgestalten.

Stellt euch vor, ihr seid neu im Team und wollt euch in die Code-Basis einlesen. Würdet ihr vor Freude Luftsprünge machen, wenn ihr solchen Code vorfindet?

<div class="fixed-header" role="banner">
    <div id="header-logo" role="img" aria-label="Logo Example Page"></div>
    <div role="navigation" aria-label="Main Navigation">
        <div role="list">
            <div role="listitem"><a href="/">Home</a></div>
            <div role="listitem"><a href="/about">About</a></div>
        </div>
    </div>
</div>
<div role="main">
    <div role="heading" aria-level="1">Best Pizza in Town</div>
    <div role="heading" aria-level="2">Pizza Salami</div>
    <div id="pizza-salami" role="img" aria-label="Pizza with salami slices"></div>
    <div>Some text</div>
    <div role="heading" aria-level="2">Pizza Capricciosa</div>
    <div id="pizza-capri" role="img" aria-label="Pizza with baked ham, mushroom and artichoke"></div>
    <div>Some text</div>
</div>

Puh, das sind schon verdammt viele div Tags! Irgendwie schwer zu verstehen. Tja, dann würdet ihr euch über folgenden Code wohl mehr freuen:

<header>
    <img src="/header-logo.svg" alt="Logo Example Page">
    <nav aria-label="Main Navigation">
        <ul>
            <li><a href="/">Home</a></li>
            <li><a href="/about">About</a></li>
        </ul>
    </nav>
</header>
<main>
    <h1>Best Pizza in Town</h1>
    <h2>Pizza Salami</h2>
    <img src="/pizza-salami.jpg" alt="Pizza with salami slices">
    <p>Some text</p>
    <h2>Pizza Capricciosa</h2>
    <img src="/pizza-capri.jpg" alt="Pizza with baked ham, mushroom and artichoke">
    <p>Some text</p>
</main>

Ah, das ist besser! Auf dieser Basis könnt ihr euch im Team sinnvoll über den HTML-Code austauschen. Notiz am Rande: Beide Code-Beispiele bereiten den Inhalt barrierefrei für Screenreader-Nutzer:innen auf. Aber nur das zweite Beispiel ist vorteilhaft für Entwickler:innen.

Wenn ihr jetzt denkt: „Boah, der übertreibt ja völlig mit dieser Spaghetti-Code-Hölle!“ Dann kann ich nur antworten, dass ich Variationen davon schon auf unzähligen Websites gesehen habe. Einfach nur traurig.

2. Native Bedienelemente sind standardmäßig tastaturbedienbar

HTML-Elemente wie a, button, input type="checkbox" oder input type="radio" sind alle von Haus aus barrierefrei. Zum Beispiel können Nutzer:innen mit der Tab-Taste von Schaltfläche zu Schaltfläche springen und diese mit der Enter- oder Leertaste aktivieren.

Stellt euch vor, ihr wollt eine Schaltfläche mit dem div Element implementieren – warum auch immer. Damit dieses Monstrum mit der Tastatur bedienbar wird, müsstet ihr folgende Schritte unternehmen:

tabindex="0" setzen, um das Div in die Tab-Reihenfolge aufzunehmen.
Einen gut sichtbaren Fokus-Indikator setzen, der vermittelt wann das Div den Fokus hat.
Mit einem keydown Event-Handler die Aktivierung des „Buttons“ mit Enter- und Leertaste ermöglichen.

Das Folgende ist zu tun, wenn ihr stattdessen das native button Element verwendet:

Nichts!

Buttons sind standardmäßig tastaturbedienbar und lösen automatisch das click Event aus, wenn die Enter- oder Leertaste gedrückt wird. Weiters könnt ihr das Styling sehr einfach mit CSS anpassen. Das trifft auch auf die meisten Formularelemente zu. Lest dazu meinen Artikel über Web-Formulare.

3. Zustandsbezogene, semantische CSS-Selektoren sind aussagekräftiger und robuster

Ihr könnt die semantischen Tag-Namen und ARIA-Attribute für aussagekräftige und leicht verständliche CSS-Selektoren nutzen. Zum Beispiel: header nav > ul { ... } oder button[aria-expanded="true" ] { ... }.

Indem die CSS-Regeln alleine auf HTML-Tags und -Attributen aufbauen, braucht ihr keine zusätzlichen CSS-Klassen, die dynamisch mit JavaScript gesetzt werden. Stattdessen könnt ihr euch darauf konzentrieren, die Geschäftslogik alleine im HTML-Code abzubilden (etwa indem aria-expanded auf „true“ oder „false“ gesetzt wird).

Weitere Beispiele und eine ausführliche Auseinandersetzung mit dem Konzept bietet der Artikel „Style with Stateful, Semantic Selectors“ von Ben Myers.

Nützliche Links

Update am 16.12.2022

Abschnitt über zustandsbezogene, semantische CSS-Selektoren wurde überarbeitet.