Wie barrierefrei ist das deutsche Internet im Sommer 2024?

In einem früheren Artikel zum Barriere­freiheits­stärkungs­gesetz hatte ich zwei Untersuchungen verlinkt, laut denen bis zu 90% der deutschen Internetseiten momentan noch nicht barrierefrei seien. Zwar hatte ich mit einem ähnlichen Ergebnis gerechnet, aber derart hohe Zahlen haben mich dann doch verblüfft. Vor allem aber haben sie mich dazu motiviert, selbst zu verifizieren, wie es im Sommer 2024 um die Barrierefreiheit beliebter Internetseiten in Deutschland steht. Ist die Lage wirklich so schlimm?

Um das herauszufinden, habe ich einen Test durchgeführt, der zwei Teile beinhaltet:

1. Wir prüfen 50 die meistbesuchten Webseiten in Deutschland mit einem Skript automatisiert auf Barrierefreiheits-Verstöße.
2. Wir schauen uns die Ergebnisse an und überprüfen sie stichprobenartig, indem wir ausgewählte Webseiten manuell auf Barrieren testen.

Teil 1: Der automatisierte Test

Zunächst benötigen wir eine Liste der 50 meistbesuchten Webseiten in Deutschland im Juli 2024. Diese gibt es z.B. auf der Webseite von Semrush. Aus der Liste habe ich doppelte Domains, die auf dasselbe Angebot zeigen (z.B. twitter.com und x.com) sowie nicht legale und nicht jugendfreie Angebote entfernt. Aus Gründen der Einfachheit testen wir jeweils nur die Startseite der Angebote. In der Regel ist davon auszugehen, dass auf anderen Unterseiten mehr Barrieren zu finden sind als auf der Startseite, etwa bei Formularen, Karten oder Medieninhalten.

Für die 50 URLs führen wir die Kommandozeilen-Programme Lighthouse and Axe aus. Lighthouse prüft verschiedenste Aspekte einer Webseite und vergibt jeweils einen Score von 0 bis 100. Uns interessiert nur der Accessibility-Score. Axe listet eine Reihe von Barrierefreiheits-Verstößen samt Schweregrad auf. Für beide Tools gibt es jeweils ein NPM-Package (lighthouse bzw. @axe-core/cli).

Wir gehen nun die Liste der Seiten durch, rufen beide Programme mit der entsprechenden URL auf und speichern die Ergebnisse. Das tun wir jedoch nicht von Hand, sondern automatisieren es mit einem Skript, in unserem Fall in der Sprache JavaScript. Das Skript können wir entweder von Hand schreiben oder z.B. ChatGPT für uns schreiben lassen. Ich habe letzteres gewählt und das Skript dann an manchen Stellen von Hand erweitert und optimiert. Das erzeugt nicht unbedingt den schönsten Code, ist aber funktional und war in wenigen Minuten erledigt.

Wir führen das Skript mit der Liste von URLs aus und speichern die Ergebnisse beider Tools zur späteren Nachvollziehbarkeit jeweils in einer JSON-Datei.

Aus den Ergebnissen für jede Webseite extrahieren wir die Punktezahl von Lighthouse und die Anzahl der Verstöße in Axe und schreiben diese in eine Tabelle.

Hier können Sie das verwendete Skript sehen, um den Test selbst nachzustellen:

const { promisify } = require('util');
const exec = promisify(require('child_process').exec);
const fs = require('fs');

// source: https://de.semrush.com/trending-websites/de/all (data from July 2024)
const websites = [
    "google.de",
    "youtube.com",
    "amazon.de",
    "wikipedia.org",
    "facebook.com",
    "instagram.com",
    "bing.com",
    "duckduckgo.com",
    "kleinanzeigen.de",
    "reddit.com",
    "twitch.tv",
    "bild.de",
    "ebay.de",
    "weather.com",
    "paypal.com",
    "spiegel.de",
    "wetter.com",
    "tagesschau.de",
    "x.com",
    "chatgpt.com",
    "n-tv.de",
    "msn.com",
    "zdf.de",
    "dhl.de",
    "t-online.de",
    "focus.de",
    "kicker.de",
    "tiktok.com",
    "wetteronline.de",
    "whatsapp.com",
    "netflix.com",
    "web.de",
    "mydealz.de",
    "welt.de",
    "gmx.net",
    "ardmediathek.de",
    "kicktipp.de",
    "ecosia.org",
    "yahoo.com",
    "idealo.de",
    "linkedin.com",
    "transfermarkt.de",
    "bahn.de",
    "chip.de",
    "immobilienscout24.de",
    "zeit.de",
    "openai.com",
    "microsoft.com",
    "mobile.de",
    "merkur.de"
];

const outputDir = `./results/${new Date().toJSON().replaceAll(':', '-')}`;

function getJsonFilePath(hostname, tool) {
    return `${outputDir}/${encodeURIComponent(hostname)}-${tool}.json`;
}

async function auditWebsite(hostname) {
    const lighthouseCommand = `lighthouse https://${hostname} --only-categories=accessibility --chrome-flags="--headless" --output=json --output-path=${getJsonFilePath(hostname, 'lighthouse')}`;
    const axeCommand = `axe https://${hostname} --save ${getJsonFilePath(hostname, 'axe')}`;

    try {
        await Promise.all([
            exec(lighthouseCommand),
            exec(axeCommand)
        ]);
    } catch (err) {
        console.error(`Audit error for ${hostname}: ${error.message}`);
        throw err;
    }
}

function getResults(hostname) {
    const readJsonFileSync = (service) => JSON.parse(fs.readFileSync(getJsonFilePath(hostname, service), { encoding: 'utf-8' }));

    const lighthouseResult = readJsonFileSync('lighthouse');
    const axeResult = readJsonFileSync('axe');

    const lighthouseScore = lighthouseResult.categories.accessibility.score * 100;
    const axeViolations = ["minor", "moderate", "serious", "critical"].reduce((violations, impact) => {
        const findings = axeResult[0].violations.filter(violation => violation.impact === impact).length;
        return { ...violations, [impact]: findings };
    }, {});

    return { lighthouseScore, axeViolations };
}

function resultsToTable(resultsEntries = []) {
    return `<table>
    <caption>Accessibility score rankings</caption>
    <thead>
        <tr>
            <th rowspan="2" scope="col">Website</th>
            <th rowspan="2" scope="col">Lighthouse Score</th>
            <th colspan="4" scope="colgroup">Axe Violations</th>
        </tr>
        <tr>
            <th scope="col">critical</th>
            <th scope="col">serious</th>
            <th scope="col">moderate</th>
            <th scope="col">minor</th>
        </tr>
    </thead>
    <tbody>
${resultsEntries.map(([site, { lighthouseScore, axeViolations }]) => `        <tr>
            <th scope="row">${site}</th>
            <td>${lighthouseScore}</td>
            <td>${axeViolations.critical}</td>
            <td>${axeViolations.serious}</td>
            <td>${axeViolations.moderate}</td>
            <td>${axeViolations.minor}</td>
        </tr>`).join('\n')}
    </tbody>
</table>`
}

if (!fs.existsSync(outputDir)) {
    fs.mkdirSync(outputDir, { recursive: true });
}

(async () => {
    const results = new Map();

    for (let website of websites) {
        try {
            console.log(`auditing ${website}...`);
            await auditWebsite(website);
            results.set(website, getResults(website));
            console.log(`auditing ${website} completed.`);
        } catch (error) {
            console.error(`Audit failed for ${website}`);
            console.error(error);
        }
    }
    console.log('Audits completed.');
    const resultsEntries = results.entries();

    fs.writeFileSync(`${outputDir}/results.json`, JSON.stringify(Object.fromEntries(resultsEntries), null, 2), { encoding: 'utf-8' });
    fs.writeFileSync(`${outputDir}/results.html`, resultsToTable(Array.from(resultsEntries)), { encoding: 'utf-8' });

    console.log('Results written.');
})();

npm install -g lighthouse @axe-core/cli
node audit-websites.js

Wie aussagekräftig sind die Ergebnisse?

Natürlich handelt es sich hier nicht um einen vollständigen Barrierefreiheits-Test, sondern nur um einen automatisierten Test, der die technische Implementierung der Webseite auf Barrierefreiheits-Verstöße testet. Die Ergebnisse reichen nicht aus, um eine vollständige Aussage über die Barrierefreiheit der Angebote zu treffen, denn die Tools können nur den technischen Aufbau einer Webseite erfassen, aber nicht deren Inhalte verstehen.

Selbst eine Webseite mit voller Punktzahl und keinen Verstößen in automatisierten Barrierefreiheits-Checkern kann z.B. assistiven Technologien wie Screen Readern Informationen vorenthalten oder sinnfreie Inhalte ausgeben. Solche semantischen Barrieren kann diese Art von Tools nicht erkennen. Auch einige visuelle Barrieren wie mangelnde Kontraste durch halbtransparente Elemente oder unlesbaren Text auf Bildern werden von entsprechenden Tools nicht erfasst.

Nichtsdestotrotz bieten die Ergebnisse der Tools für unseren Zweck eine hohe Aussagekraft:

1. Eine Webseite, die die volle Punktzahl und keine technischen Verstöße aufweist, ist zwar nicht automatisch barrierefrei, aber eine Webseite, bei der die Tools Fehler finden, ist es mit hoher Sicherheit nicht.

2. Um allein eine technische Barrierefreiheit zu gewährleisten, muss bereits ein gewisses Interesse und Kompetenz seitens des Anbieters vorhanden sein. Digitale Barrierefreiheit passiert nicht aus Versehen. Sie entsteht in der Regel durch absichtliche Anstrengungen mehrere Personen verschiedener Disziplinen. Selbst die ambitioniertesten Entwickler:innen können keine barrierefreie Webseite erstellen, wenn das Design bereits nicht barrierefrei ist. Da eine barrierefreie Umsetzung eines Features meist mit einem zeitlichen Mehraufwand verbunden ist, braucht man in der Regel auch den Buy-In seitens des Produktmanagements.

Somit spiegeln die Ergebnisse der Tools durchaus ziemlich realitätsnah die Anstrengungen der Firmen hinter den Webseiten wider.

Die Ergebnisse im Detail

Hier sind die Ergebnisse des Tests am 11. August 2024:

Die Ergebnisse geben uns verschiedene Informationen:

Zunächst einmal ist es bemerkenswert, dass keine einzige Webseite komplett fehlerfrei zu sein scheint. Bei jedem Angebot hat mindestens eines der beiden Tools ein oder mehrere Probleme gefunden, die für bestimmten Nutzergruppen eine Barriere darstellen können. Dabei ist es kein unmöglicher Aufwand, die technische Fehlerfreiheit sicherzustellen, sofern man weiß, was man tut und regelmäßig testet. Bei der Webseite, auf der Sie gerade diesen Artikel lesen, ist das z.B. der Fall.

Die konkreten Ergebnisse geben uns einen Anhaltspunkt, wo es sich besonders lohnt, die Webseiten händisch zu überprüfen.

Teil 2: Manuelle Tests ausgewählter Webseiten

Exemplarisch habe ich vier Angebote aus der Liste ausgewählt, die inhaltlich verschiedene Themen abdecken und eine Mischung aus staatlichen und privatwirtschaftlichen Angeboten darstellen. Diese habe ich einem kurzen händischen Test unterzogen und geschaut, wo ich auf Probleme stoße. Tatsächlich hat es nicht lange gedauert, welche zu finden.

Angeschaut habe ich die Seiten dhl.de, gmx.net, welt.de und zdf.de, jeweils auf einem Android Smartphone (Google Pixel 8) mit dem Chrome-Browser und dem Screen Reader TalkBack sowie auf einem MacBook mit dem Safari-Browser und dem Screen Reader VoiceOver, beides jeweils am 11. August 2024.

In der Praxis würde man die Seiten noch mit einigen weiteren Plattformen testen, aber für einen Überblick reichen beide aus.

Der Endgegner: Datenschutz-Dialog

Sofort aufgefallen ist, dass es bei einigen der Angebote bereits daran scheitert, am Datenschutz-Dialog vorbei und auf die eigentliche Seite zu gelangen:

• Beim ZDF haben Elemente im Datenschutz-Dialog keinerlei Fokusrahmen, sodass man per Tastaturnavigation nicht sehen kann, ob man einen Button (z.B. „Akzeptieren“ oder „Ablehnen“) ausgewählt hat und welchen.
• Auf der DHL-Seite liest TalkBack unter Android als erstes automatisch den kompletten Datenschutz-Text vor, wenn man die Webseite öffnet. Das können geübte Nutzer:innen abbrechen, ist aber nervig.
• Bei DHL, Welt.de und ZDF wird der Tastaturfokus im Datenschutz-Dialog nicht eingefangen, so dass man jeweils in der Webseite per Tastatur navigieren kann, obwohl der Datenschutz-Dialog noch geöffnet ist (dann aber nichts von der Webseite sehen kann).
• Unter Welt.de wurde der Datenschutz-Dialog unter TalkBack beim Laden der Seite nicht fokussiert, so dass erst z.B. die Seitennavigation vorgelesen wurde.
• Bei GMX werden der deutsche Datenschutztext und die Bedienelemente mit englischer Aussprache vorgelesen; hier ist anscheinend die Seitensprache falsch oder noch nicht gesetzt.
• Bei GMX trat mit Android und TalkBack manchmal der Fall auf, dass der Datenschutz-Dialog als „ohne Inhalt“ interpretiert wurde, obwohl der Inhalt visuell vorhanden war. Es gab also gar keine Möglichkeit, Cookies zu akzeptieren, um überhaupt auf die Seite zu gelangen.

Ein Grund für diese erheblichen Probleme könnte darin liegen, dass ein Großteil der Webseiten ihre Datenschutz-Dialoge von Drittanbietern einbinden und somit nur begrenze Konfigurationsmöglichkeiten und Einfluss auf die Bedienbarkeit haben. Selbst wenn den Webseitenbetreibern die Barrierefreiheits-Probleme also bewusst sein sollten, können sie sie nicht selbst zeitnah beheben.

Schauen wir nun, was auffällt, wenn man es am Datenschutz-Dialog vorbei geschafft hat. Die folgenden Listen beinhalten nicht alle Probleme der Seiten, sondern nur solche, die mir sofort nach dem Öffnen der Seiten aufgefallen sind. In der Praxis dürften noch manche dazukommen.

GMX

• Das Hauptmenü auf der Desktop-Seite lässt sich nicht per Tastatur erreichen.
• Die meisten Elemente der Seite haben keinen sichtbaren Tastaturfokus. Selbst wenn man sie per Tastatur erreichen könnte, sieht man also nicht, wann dies der Fall ist.
• Das Suchfeld der Seite ist für nicht-sehende Nutzer:innen nicht als solches zu erkennen, denn es ist nicht als Such-Input ausgezeichnet, hat kein Label und der Platzhalter-Text („Suchen mit GMX“ im Bild oben) ist nicht standardkonform umgesetzt. Der Suchbutton hat nur ein Icon ohne Textbeschreibung. Ein Screen Reader würde hier nur „Textfeld“ vorlesen (nicht etwa „Suche“) sowie „Schaltfläche“ (ohne Angabe, was die Schaltfläche macht, anstelle von „Suchen“).
• Ich würde vermuten, viele Menschen wollen bei GMX primär ihre E-Mails lesen. Das Login-Formular befindet sich auf der Desktop-Seite jedoch erst in der Mitte der Startseite nach Dutzenden News-Artikeln (nach insgesamt 32-maligen Drücken der Tab-Taste am Seitenanfang). Ein Sprunglink zum Login gibt es nicht. Ein Überschrift, zu der man springen könnte, hat es auch nicht. Der Login-Bereich selbst hat auch keinen Namen, zu dem man über Landmarks der Seite springen könnte.
• Auf der mobile Webseite ist der Login auf einer eigenen Unterseite. Auf dieser öffnet sich sofort eine vollflächige Werbung für die GMX-App, die die komplette Seite überdeckt. Den Schließen-Button erreicht man per Screen Reader erst, nachdem man sich durch die komplette von der Werbung verdeckte Seite navigiert hat.
• Rechts auf der Seite spielt eine Werbung von eBay automatisch ein Video ab, selbst wenn man in den Systemeinstellungen „Bewegung reduzieren“ ausgewählt hat. Ungewollte Bewegungen auf einer Seite können bei bestimmten Personengruppen zu Aufmerksamkeitsproblemen oder sogar zu Übelkeit führen. Auf die eingespielte Werbung haben Webseitenbetreiber allerdings oft nur begrenzte Kontrolle.

DHL

• Auch bei DHL hat der Suchbutton nur ein Icon ohne Label.
• Die Fokus-Stile bei Tastaturnavigation auf der sind Seite sind nicht einheitlich. Es wirkt, als seien diese ohne Absprache von verschiedenen Teams umgesetzt worden.
• Die Inhalte mancher Tooltips sind nicht per Tastatur erreichbar (z.B. für Sperrgut beim Porto-Rechner).
• Man kann auf dem Android-Smartphone nicht per Fingergeste in die Seite hineinzoomen, um z.B. kleine Texte besser lesen zu können.

Welt.de

• Der Datenschutz-Dialog befindet sich am Ende der Seite; um diesen per Tastatur finden und schließen zu können, muss man entweder durch die komplette Seite springen, vom Seitenende rückwärts gehen oder das kryptisch benannte Rahmenelement in den Landmarks der Seite finden. Äußerst mühsam.
• Die Fokusrahmen im Datenschutz-Dialog sind so unscheinbar, dass ich den „Akzeptieren“-Button per Tastatur erst im dritten Versuch gefunden habe.
• Es gibt auf der Seite einen KI-Assistenten „WELTgo!“. Der Button, der dorthin führt, reagiert aber nur auf Mausklicks. Per Tastaturnavigation bzw. Screen Reader kann man die Seite nicht erreichen.
• Auch unter Welt.de kann man auf dem Android-Smartphone nicht per Fingergeste in die Seite hineinzoomen.

ZDF

• Das ZDF bietet auf den ersten Blick insgesamt eine vorbildliche Umsetzung, sofern man es am Datenschutz-Dialog vorbei geschafft hat. Es gibt Sprunglinks, der Tastaturfokus ist überall sichtbar, die Seite hat ausreichende Kontraste und auch komplexere Eingabeelemente wie Suchfilter sind per Screen Reader und Tastatur bedienbar.

Abgleich mit den automatisierten Tests

Die Abgleich der gefundenen Probleme der automatisierten Tools mit den Ergebnissen der händischen Tests bringt noch einmal interessante Erkenntnisse zu Tage:

Viele der gefundenen Probleme im manuellen Test wurden von den automatisierten Tools nicht gefunden, z.B. Probleme mit nicht sichtbarem Tastaturfokus oder fehlenden Auszeichnungen von Formularelementen. Andererseits haben die Tools auf manchen Seiten Probleme identifiziert, die mir im manuellen Test nicht aufgefallen sind, aber z.B. für Nutzer:innen anderer Browser oder assistiven Technologien Barrieren darstellen können.

Es ist folglich wichtig, immer auf beide Arten zu testen, um alle Probleme zu identifizieren, im Optimalfall mit verschieden Personen mit verschiedener Hardware und Software.

Auch ist interessant, wie weit entfernt die Ergebnisse der automatisierten Tools von den Ergebnissen der manuellen Tests entfernt sind. So haben die Webseiten von GMX und ZDF den gleichen Lighthouse-Score erreicht (88 von 100 Punkten) und beim ZDF fand Axe mehr Verstöße als bei GMX. Im manuellen Test fielen bei GMX jedoch wesentlich mehr Probleme auf als beim ZDF. Somit können die Ergebnisse der Tools nur als ungefährer Anhaltspunkt dienen, sie eignen sich hingegen nicht für eine Vergleichbarkeit der Barrierefreiheit verschiedener Webseiten.

Fazit

Wie befürchtet fielen die Ergebnisse des Tests ernüchternd aus. Die erste Überraschung hingegen war bereits, dass keine der 50 meistbesuchten Webseiten in Deutschland komplett fehlerfrei war. Ebenso überraschend war es, wie schnell bei den Webseiten aus der Stichprobe bereits nach wenigen Sekunden deutliche Barrieren aufgefallen sind.

Hier scheint bei keinem Anbieter ausreichend regelmäßig und systematisch getestet zu werden. Umso schlimmer wiegt das, da man viele der Angebote gewissermaßen als Infrastruktur betrachten kann, die die digitale Teilhabe an der Gesellschaft überhaupt erst ermöglicht. Ohne E-Mail-Adresse funktioniert heute nicht mehr viel, ein Paket werden die meisten Menschen zumindest gelegentlich verschicken und der Zugang zu Nachrichten ist ebenfalls elementar für die Teilhabe an der Gesellschaft.

Dennoch kann man die Angebote nicht über einen Kamm scheren: Beim ZDF war die Umsetzung der Webseite bis auf den Datenschutz-Dialog vorbildlich und auch zahlreiche Inhalte liegen in barrierefreien Ausgabemöglichkeiten wie Untertiteln, Audiodeskription oder Gebärdensprache vor. Bei GMX hingegen wirkt es so, als ob die Webseite noch nie bewusst auf Barrierefreiheit getestet oder gar optimiert wurde.

Es zeigt sich im Test auch nochmals die Wichtigkeit des regelmäßigen Testens, da selbst ein einziger Fehler dafür sorgen kann, dass ein ansonsten barrierefreies Angebot für bestimmte Personengruppen unzugänglich wird.

Spannend wird nochmals, ob und wie sich die Lage bis zum nächsten Sommer bessert. Unser Skript zum automatisierten Testen der Angebote können wir nun regelmäßig ausführen, um zu prüfen, ob es in den nächsten Monaten Bewegung in der Barrierefreiheit der jeweiligen Angebote gibt.