RampCheck

Barrierefreiheits-Audit

www.w3.org · 15. September 2026 · 6 Seiten geprüft

Beispielbericht: eine echte Prüfung der absichtlich nicht barrierefreien Demo-Website des W3C (w3.org/WAI/demos/bad). Ihr Bericht hat denselben Aufbau – für Ihre eigene Website.

Ergebnis

5/100

Kritisches Risiko

10 verschiedene Probleme an 354 Elementen gefunden.

Geschätzter Aufwand für die Behebung: 5 Entwicklertage

Was dieses Audit abdeckt – und was nicht

Dies ist ein automatisiertes Audit. Automatisierte Tests erkennen zuverlässig etwa 30–40 % der WCAG-Erfolgskriterien – die maschinell prüfbaren, etwa fehlende Alternativtexte, Farbkontraste, Formularbeschriftungen und die Gültigkeit von ARIA.

Sie können nicht beurteilen, ob Alternativtexte sinnvoll sind, ob die Fokus-Reihenfolge logisch ist, ob eine Seite mit einem echten Screenreader funktioniert oder ob Inhalte verständlich sind. Dafür sind manuelle Tests mit Hilfstechnologien nötig.

Eine gute Bewertung ist keine Konformitätsbescheinigung, und dieses Dokument ist keine Rechtsberatung. Es ist eine technische Arbeitsliste: Jeder gemeldete Punkt ist ein echter, reproduzierbarer Mangel, dessen Behebung sich lohnt – ein notwendiger, aber kein hinreichender Schritt zur Konformität mit EN 301 549 / WCAG 2.2 AA und dem BFSG.

Hier anfangen: 4 Quick Wins

Folgenreiche Probleme mit geringem Behebungsaufwand. Sie bringen die größte Risikominderung pro investierter Stunde.

  1. Bilder ohne Textalternative Blockierend < 1 Std.
    155 Elemente auf 5 Seiten · vermutlich eine einzige Korrektur im Template
  2. Links ohne erkennbaren Text Blockierend < 1 Std.
    26 Elemente auf 5 Seiten · vermutlich eine einzige Korrektur im Template
  3. Auswahllisten ohne zugänglichen Namen Blockierend < 1 Std.
    6 Elemente auf 5 Seiten · vermutlich eine einzige Korrektur im Template
  4. Seite gibt ihre Sprache nicht an Schwerwiegend < 1 Std.
    5 Elemente auf 5 Seiten · vermutlich eine einzige Korrektur im Template

Befunde nach Priorität

Sortiert nach den Folgen für Nutzer, dem Anteil der betroffenen Website und der Zahl der betroffenen Elemente.

1 Bilder ohne Textalternative

Blockierend Schnell erledigt · < 1 Std. Seitenweites Template-Problem WCAG A

155 Elemente betroffen auf 5 Seiten · 1.1.1 Nicht-Text-Inhalt

Wen es betrifft

Blinde und sehbehinderte Menschen, die einen Screenreader nutzen – und alle, bei denen Bilder wegen einer langsamen Verbindung nicht laden.

Warum es wichtig ist

Der Screenreader liest nichts vor oder nur den Dateinamen. Ist das Bild ein Produktfoto, ein Logo oder eine Schaltfläche, geht diese Information vollständig verloren. Es ist der am häufigsten beanstandete Mangel, weil er sich besonders leicht nachweisen lässt.

So beheben Sie es

Geben Sie jedem <img> ein alt-Attribut. Beschreiben Sie den Zweck, nicht das Motiv: alt="In den Warenkorb" statt alt="Einkaufswagen-Symbol". Rein dekorative Bilder erhalten alt="" (leer, nicht fehlend), damit Hilfstechnologien sie überspringen.

Gefundene Beispiele

  • /WAI/demos/bad/before/home.html img[src$="border_left_top.gif"]
    <img src="./img/border_left_top.gif" width="10px" height="10px">
  • /WAI/demos/bad/before/home.html img[src$="border_top.gif"]
    <img src="./img/border_top.gif" height="10px">
  • /WAI/demos/bad/before/home.html img[src$="border_right_top.gif"]
    <img src="./img/border_right_top.gif" width="10px" height="10px">
  • /WAI/demos/bad/before/home.html img[src$="border_left.gif"]
    <img src="./img/border_left.gif" width="10px">

Technische Referenz (englisch): https://dequeuniversity.com/rules/axe/4.13/image-alt?application=axeAPI

2 Links ohne erkennbaren Text

Blockierend Schnell erledigt · < 1 Std. Seitenweites Template-Problem WCAG A

26 Elemente betroffen auf 5 Seiten · 2.4.4 Linkzweck (im Kontext), 4.1.2 Name, Rolle, Wert

Wen es betrifft

Screenreader-Nutzer, die sich häufig über eine Liste aller Links einer Seite orientieren.

Warum es wichtig ist

Ein unbeschrifteter Link wird nur als „Link“ angesagt – die Linkliste wird damit unbrauchbar. Typische Ursachen sind reine Symbol-Links zu sozialen Netzwerken und Bild-Links in Kacheln.

So beheben Sie es

Geben Sie dem Link echten Text oder ein aria-label, wenn das Design nur ein Symbol zeigen soll. Vermeiden Sie mehrfach wiederholte Linktexte wie „hier klicken“ oder „mehr“, die ohne Kontext nichts aussagen.

Gefundene Beispiele

  • /WAI/demos/bad/before/home.html #home > a[onfocus="blur();"]
    <a href="javascript:location.href='home.html';" onfocus="blur();"><img name="nav_home" src="./img/nav_home.gif" width="88" height="27" hspace="15" border="0px"></a>
  • /WAI/demos/bad/before/home.html #news > a[onfocus="blur();"]
    <a href="javascript:location.href='news.html';" onfocus="blur();"><img src="./img/nav_news.gif" name="nav_news" width="90" height="21" hspace="12" border="0px"></a>
  • /WAI/demos/bad/before/home.html #tickets > a[onfocus="blur();"]
    <a href="javascript:location.href='tickets.html';" onfocus="blur();"><img name="nav_facts" src="./img/nav_facts.gif" width="105" height="23" hspace="9" border="0px"></a>
  • /WAI/demos/bad/before/home.html #survey > a[onfocus="blur();"]
    <a href="javascript:location.href='survey.html';" onfocus="blur();"><img src="./img/nav_survey.gif" name="nav_survey" width="107" height="32" hspace="8" border="0px"></a>

Technische Referenz (englisch): https://dequeuniversity.com/rules/axe/4.13/link-name?application=axeAPI

3 Auswahllisten ohne zugänglichen Namen

Blockierend Schnell erledigt · < 1 Std. Seitenweites Template-Problem WCAG A

6 Elemente betroffen auf 5 Seiten · 4.1.2 Name, Rolle, Wert

Wen es betrifft

Screenreader-Nutzer beim Ausfüllen von Auswahllisten wie Land, Größe oder Menge.

Warum es wichtig ist

Der Nutzer hört die Optionen, erfährt aber nie, wofür die Auswahl ist – das bricht häufig Bestell- und Buchungsprozesse.

So beheben Sie es

Verknüpfen Sie ein <label> mit dem <select> oder ergänzen Sie aria-label.

Gefundene Beispiele

  • /WAI/demos/bad/before/home.html select
    <select onchange="location.href = this.value;">
  • /WAI/demos/bad/before/annotated/home.html select
    <select onchange="location.href = this.value;">
  • /WAI/demos/bad/before/news.html select
    <select onchange="location.href = this.value;">
  • /WAI/demos/bad/before/tickets.html select
    <select onchange="location.href = this.value;">

Technische Referenz (englisch): https://dequeuniversity.com/rules/axe/4.13/select-name?application=axeAPI

4 Formularfelder ohne zugeordnete Beschriftung

Blockierend Mittel · 1–4 Std. WCAG A

11 Elemente betroffen auf 1 Seite · 4.1.2 Name, Rolle, Wert

Wen es betrifft

Screenreader-Nutzer, Sprachsteuerungs-Nutzer und Menschen mit kognitiven Einschränkungen, die auf dauerhaft sichtbare Beschriftungen angewiesen sind.

Warum es wichtig ist

Ohne programmatisch verknüpfte Beschriftung hört der Nutzer nur „Eingabefeld, leer“ und weiß nicht, was er eintragen soll. Platzhaltertext ist kein Ersatz: Er verschwindet beim Tippen und hat meist zu wenig Kontrast. Unbeschriftete Felder in Kasse und Kontaktformular kosten direkt Umsatz.

So beheben Sie es

Verknüpfen Sie ein <label for="id"> mit der id des Feldes oder umschließen Sie das Feld mit dem Label. Behalten Sie die sichtbare Beschriftung bei, statt nur einen Platzhalter zu verwenden.

Gefundene Beispiele

  • /WAI/demos/bad/before/survey.html input[value="1"]
    <input class="align" type="radio" name="res" value="1">
  • /WAI/demos/bad/before/survey.html input[value="2"]
    <input class="align" type="radio" name="res" value="2">
  • /WAI/demos/bad/before/survey.html input[value="3"]
    <input class="align" type="radio" name="res" value="3">
  • /WAI/demos/bad/before/survey.html input[value="4"]
    <input class="align" type="radio" name="res" value="4">

Technische Referenz (englisch): https://dequeuniversity.com/rules/axe/4.13/label?application=axeAPI

5 Seite gibt ihre Sprache nicht an

Schwerwiegend Schnell erledigt · < 1 Std. Seitenweites Template-Problem WCAG A

5 Elemente betroffen auf 5 Seiten · 3.1.1 Sprache der Seite

Wen es betrifft

Screenreader-Nutzer, besonders in mehrsprachigen Ländern.

Warum es wichtig ist

Ohne Sprachangabe rät der Screenreader – und liest deutsche Inhalte oft mit englischer Stimme vor, was kaum verständlich ist. Eine Korrektur in einer Zeile und ein sehr sichtbarer Mangel in jedem Audit.

So beheben Sie es

Setzen Sie auf jeder Seite <html lang="de"> (oder den passenden Code), auch auf Fehlerseiten.

Gefundene Beispiele

  • /WAI/demos/bad/before/home.html html
    <html>
  • /WAI/demos/bad/before/annotated/home.html html
    <html>
  • /WAI/demos/bad/before/news.html html
    <html>
  • /WAI/demos/bad/before/tickets.html html
    <html>

Technische Referenz (englisch): https://dequeuniversity.com/rules/axe/4.13/html-has-lang?application=axeAPI

6 Zu geringer Kontrast zwischen Text und Hintergrund

Schwerwiegend Mittel · 1–4 Std. WCAG AA

12 Elemente betroffen auf 3 Seiten · 1.4.3 Kontrast (Minimum)

Wen es betrifft

Die mit Abstand größte Gruppe: alle mit Sehschwäche, Farbenfehlsichtigkeit oder altersbedingt nachlassendem Sehvermögen – und jeder, der im Sonnenlicht auf dem Smartphone liest.

Warum es wichtig ist

Etwa jeder zwölfte Mann hat eine Farbenfehlsichtigkeit, und zu geringer Kontrast ist der häufigste Mangel im gesamten Web. Er lässt sich außerdem mit einem einzigen Screenshot belegen. Typische Ursachen sind hellgraue Platzhaltertexte und blasse Markenfarben auf Weiß.

So beheben Sie es

Fließtext braucht ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund, großer Text (ab 18 pt bzw. 14 pt fett) mindestens 3:1. Meist genügt es, eine Markenfarbe in Ihren CSS-Variablen abzudunkeln – das behebt alle Vorkommen auf einmal.

Gefundene Beispiele

  • /WAI/demos/bad/before/home.html tr[height="25px"]:nth-child(2) > td[bgcolor="#A9B8BF"][width="150px"] > font[color="#41545D"][size="2"] > b
    <b>Free Penguins</b>
  • /WAI/demos/bad/before/home.html tr[height="25px"]:nth-child(7) > td[bgcolor="#A9B8BF"][width="150px"] > font[color="#41545D"][size="2"] > b
    <b>More City Parks</b>
  • /WAI/demos/bad/before/annotated/home.html tr[height="25px"]:nth-child(2) > td[bgcolor="#A9B8BF"][width="150px"] > font[color="#41545D"][size="2"] > b
    <b>Free Penguins</b>
  • /WAI/demos/bad/before/annotated/home.html tr[height="25px"]:nth-child(7) > td[bgcolor="#A9B8BF"][width="150px"] > font[color="#41545D"][size="2"] > b
    <b>More City Parks</b>

Technische Referenz (englisch): https://dequeuniversity.com/rules/axe/4.13/color-contrast?application=axeAPI

7 Inhalte außerhalb von Seitenbereichen (Landmarks)

Mäßig Mittel · 1–4 Std. Seitenweites Template-Problem Empfehlung (Best Practice)

115 Elemente betroffen auf 6 Seiten

Wen es betrifft

Screenreader-Nutzer, die nach Seitenbereichen navigieren.

Warum es wichtig ist

Inhalte außerhalb von Bereichen sind bei strukturierter Navigation schwer zu finden – und deuten darauf hin, dass die Seite aus generischen divs statt aus semantischem HTML besteht.

So beheben Sie es

Verwenden Sie <header>, <nav>, <main>, <footer> und <aside>, sodass alle Inhalte in einem Bereich liegen.

Gefundene Beispiele

  • /WAI/demos/bad/before/home.html #logos
    <p id="logos"><a href="https://www.w3.org/" title="W3C Home"><img alt="W3C logo" src="../img/w3c.png" height="48" width="72"></a><a href="https://www.w3.org/WAI/" title="WAI Home"><img alt="Web Accessibility Initiative (WAI) logo" src="../img/wai.png" height="48"></a></p>
  • /WAI/demos/bad/before/home.html h1
    <h1><span class="subhead">Inaccessible Home Page</span><span class="hidden"> -</span> Before and After Demonstration</h1>
  • /WAI/demos/bad/before/home.html .subline
    <p class="subline">Improving a Web site using Web Content Accessibility Guidelines (WCAG) 2.0</p>
  • /WAI/demos/bad/before/home.html #mnav
    <div id="mnav" class="inaccessible">

Technische Referenz (englisch): https://dequeuniversity.com/rules/axe/4.13/region?application=axeAPI

8 Touch-Ziele sind zu klein

Mäßig Mittel · 1–4 Std. WCAG AA

17 Elemente betroffen auf 6 Seiten · 2.5.8 Zielgröße (Minimum)

Wen es betrifft

Menschen mit motorischen Einschränkungen oder Zittern – und alle, die ihr Smartphone mit einer Hand bedienen.

Warum es wichtig ist

Kleine oder eng gesetzte Bedienelemente führen zu Fehlklicks. Die Anforderung kam mit WCAG 2.2 hinzu – viele Websites, die WCAG 2.1 erfüllten, bestehen deshalb nicht mehr.

So beheben Sie es

Machen Sie interaktive Ziele mindestens 24×24 CSS-Pixel groß oder lassen Sie entsprechenden Abstand um sie herum.

Gefundene Beispiele

  • /WAI/demos/bad/before/home.html .inaccessible > .report[href$="home.html"]
    <a href="./reports/home.html" class="report"><span class="hidden">Inaccessible Home Page </span> Report</a>
  • /WAI/demos/bad/before/home.html .accessible > .report[href$="home.html"]
    <a href="../after/reports/home.html" class="report"><span class="hidden">Accessible Home Page </span> Report</a>
  • /WAI/demos/bad/before/reports/home.html .inaccessible > .page[href$="home.html"]
    <a href="../home.html" class="page"><span class="hidden">Inaccessible </span>Home Page</a>
  • /WAI/demos/bad/before/reports/home.html .accessible > .page[href$="home.html"]
    <a href="../../after/home.html" class="page"><span class="hidden">Accessible </span>Home Page</a>

Technische Referenz (englisch): https://dequeuniversity.com/rules/axe/4.13/target-size?application=axeAPI

9 Seite hat keinen Hauptbereich (main)

Mäßig Schnell erledigt · < 1 Std. Seitenweites Template-Problem Empfehlung (Best Practice)

6 Elemente betroffen auf 6 Seiten

Wen es betrifft

Screenreader-Nutzer, die direkt zum Hauptinhalt springen.

Warum es wichtig ist

Ohne <main>-Element müssen Nutzer auf jeder Seite erst den gesamten Kopfbereich und die Navigation durchlaufen.

So beheben Sie es

Umschließen Sie den Hauptinhalt jeder Seite mit genau einem <main>-Element.

Gefundene Beispiele

  • /WAI/demos/bad/before/home.html html
    <html>
  • /WAI/demos/bad/before/reports/home.html html
    <html lang="en">
  • /WAI/demos/bad/before/annotated/home.html html
    <html>
  • /WAI/demos/bad/before/news.html html
    <html>

Technische Referenz (englisch): https://dequeuniversity.com/rules/axe/4.13/landmark-one-main?application=axeAPI

10 Leere Tabellenüberschriften

Mäßig Schnell erledigt · < 1 Std. Empfehlung (Best Practice)

1 Element betroffen auf 1 Seite

Wen es betrifft

Screenreader-Nutzer beim Lesen von Tabellen.

Warum es wichtig ist

Eine leere Überschrift gibt den Zellen der Spalte oder Zeile beim Vorlesen keinen Kontext.

So beheben Sie es

Geben Sie jedem <th> einen aussagekräftigen Text. Ist die Zelle rein dekorativ, machen Sie sie zu einem <td>.

Gefundene Beispiele

  • /WAI/demos/bad/before/tickets.html th
    <th style="padding-bottom:10px;"><img src="./img/headline_ticket_prices.gif" border="0"></th>

Technische Referenz (englisch): https://dequeuniversity.com/rules/axe/4.13/empty-table-header?application=axeAPI

Geprüfte Seiten

In dieses Audit einbezogene Seiten und die Zahl der jeweils gefundenen Problemarten
SeiteTitelProblemarten
/WAI/demos/bad/before/home.html Welcome to CityLights! [Inaccessible Home Page] 8
/WAI/demos/bad/before/reports/home.html Inaccessible Home Page Report 3
/WAI/demos/bad/before/annotated/home.html Welcome to CityLights! [Annotated Inaccessible Home Page] 8
/WAI/demos/bad/before/news.html Welcome to CityLights! [Inaccessible News Page] 7
/WAI/demos/bad/before/tickets.html Welcome to CityLights! [Inaccessible Tickets Page] 9
/WAI/demos/bad/before/survey.html Welcome to CityLights! [Inaccessible Survey Page] 8

Entwurf: Erklärung zur Barrierefreiheit

Das Barrierefreiheitsstärkungsgesetz (§ 14 und Anlage 3 BFSG) verpflichtet Anbieter erfasster Dienstleistungen, darüber zu informieren, wie ihre Dienstleistung die Barrierefreiheitsanforderungen erfüllt. Unten finden Sie einen Entwurf auf Grundlage Ihrer Ergebnisse. Ergänzen Sie die Angaben in [eckigen Klammern], prüfen Sie den Text und veröffentlichen Sie ihn in Ihren AGB oder auf andere deutlich wahrnehmbare Weise – etwa verlinkt im Footer.

Dieser Entwurf ist keine Rechtsberatung. Eine automatisierte Prüfung allein kann keine volle Vereinbarkeit belegen – deshalb erklärt der Entwurf sie auch nicht.

Erklärung zur Barrierefreiheit

[Name des Unternehmens] ist bemüht, die Website www.w3.org im Einklang mit dem Barrierefreiheitsstärkungsgesetz (BFSG) barrierefrei zugänglich zu machen.

1. Allgemeine Beschreibung der Dienstleistung

[Beschreiben Sie Ihre Dienstleistung in einfachen Worten, z. B.: „Über diese Website können Verbraucherinnen und Verbraucher Produkte auswählen, bestellen und bezahlen.“]

2. Erläuterungen zur Durchführung der Dienstleistung

[Beschreiben Sie die wesentlichen Schritte, z. B. Produktsuche, Warenkorb, Bestellung, Zahlung, Kundenkonto, Kontakt.]

3. Wie die Dienstleistung die Barrierefreiheitsanforderungen erfüllt

Maßstab ist die harmonisierte europäische Norm EN 301 549, die auf den Web Content Accessibility Guidelines (WCAG) in der Konformitätsstufe AA beruht.

Stand der Vereinbarkeit: Diese Website ist teilweise mit den Anforderungen vereinbar. Eine automatisierte Prüfung von 6 Seiten am 15. September 2026 hat folgende Barrieren ergeben, die wir bis [Datum] beheben werden:

  • Bilder ohne Textalternative (WCAG 1.1.1)
  • Links ohne erkennbaren Text (WCAG 2.4.4, 4.1.2)
  • Auswahllisten ohne zugänglichen Namen (WCAG 4.1.2)
  • Formularfelder ohne zugeordnete Beschriftung (WCAG 4.1.2)
  • Seite gibt ihre Sprache nicht an (WCAG 3.1.1)
  • Zu geringer Kontrast zwischen Text und Hintergrund (WCAG 1.4.3)
  • Touch-Ziele sind zu klein (WCAG 2.5.8)

[Ergänzen Sie bereits umgesetzte Maßnahmen, z. B. Bedienbarkeit per Tastatur, Alternativtexte, ausreichende Kontraste.]

4. Feedback und Kontakt

Ist Ihnen eine Barriere auf unserer Website aufgefallen? Schreiben Sie uns: [E-Mail-Adresse], [Telefonnummer].

5. Zuständige Marktüberwachungsbehörde

Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF AöR), Carl-Miller-Straße 6, 39112 Magdeburg, kontakt@mlbf-barrierefrei.de, www.mlbf-barrierefrei.de

Erstellt am 15. September 2026. [Zuletzt überprüft am …]

Methode

Jede Seite wurde in einem echten Chromium-Browser mit 1366×900 Pixeln geladen, bis zum Abschluss des clientseitigen Renderings abgewartet und mit axe-core geprüft, der Open-Source-Prüfengine, auf der die meisten professionellen Barrierefreiheits-Werkzeuge aufbauen. Geprüft wurden die Regeln für WCAG 2.0, 2.1 und 2.2 auf den Stufen A und AA – die Stufen, auf die EN 301 549 verweist, die harmonisierte europäische Norm hinter dem European Accessibility Act und dem BFSG.

Befunde werden über Seiten hinweg zusammengefasst: Ein Element, das sich in einem gemeinsamen Kopf- oder Fußbereich wiederholt, erscheint einmal – mit der Zahl der betroffenen Seiten – statt einmal pro Seite. Als seitenweit markierte Probleme treten an derselben Stelle auf den meisten geprüften Seiten auf und lassen sich meist mit einer einzigen Änderung an einem gemeinsamen Template oder einer Komponente beheben.

Prüfreferenz: 2026-09-15T14:13:12.899Z · 6 von 18 gefundenen Adressen geprüft · Vorgaben der robots.txt beachtet.