Beispiel-Kundenbericht · 17. Oktober 2026

Agentur-Präsentationswebsite: Barrierefreiheitsprüfung

Northline Studio · northline.example

Fiktive Demonstration. Alle Kunden, Domains, Befunde und Nachweise sind Beispiele. Die Berichte zeigen die Ergebnisstruktur; sie sind keine echten Scans oder Nachweise für Produktergebnisse.

Tarif auswählen

Zusammenfassung

Machen Sie zuerst Anfrageformular und Navigation verständlich. Diese Elemente brauchen Interessenten, um Leistungen zu erkunden und Kontakt aufzunehmen. Prüfen Sie danach die Bildbeschreibung der Fallstudie.

Geprüfte Seiten: 4
Befundtypen: 3
Kritisch: 3
Mittel: 0

Die Zahlen zeigen unterschiedliche Befundtypen im fiktiven Beispiel, nicht betroffene Elemente. Schweregrad bedeutet Prüfpriorität, keine Konformitätsbewertung.

Umfang und Methode

Kundenablauf: Discover services → read a case study → send an inquiry.

Beispielseiten: //services/work/contact

Methode: automatische axe-Prüfung jeder geladenen öffentlichen Seite. Das Beispiel umfasst keine angemeldeten Bereiche, alle Zustände, Tastaturnutzung, Screenreader oder vollständige WCAG-Prüfung. Befunde benötigen menschliche Bestätigung.

Dieser Bericht zeigt automatisierte Barrierefreiheitsbefunde. Er stellt keine Rechtskonformität fest; eine manuelle Bewertung bleibt erforderlich.

Barrierefreiheit: Regeln und Geltungsbereich

Priorisierte Befunde

Priorität	Befund	Seite / Regel	Nächster Schritt
Critical	Email field has no accessible label	`/contact` `label`	Connect a visible label to the email field.
Critical	Menu button has no accessible name	`/` `button-name`	Name the menu control and expose its expanded state.
Critical	Case-study image is missing an alternative	`/work` `image-alt`	Describe the project image or mark it decorative after reviewing its purpose.

Nachweise und Behebung

Zwei Befunde werden erläutert, um die Übergabe zur Umsetzung zu zeigen.

Befund 1 · Critical

Email field has no accessible label

Betroffenes Element: #contact-form input[type="email"] auf /contact

Warum es wichtig ist: A person using a screen reader needs a reliable name for the field. An unnamed input gives no reliable indication of the information expected.

1 · Schematischer Beispielnachweis. Nachgebauter Oberflächenausschnitt, kein Screenshot oder Livescan. Illustrative markup contains an email input with no associated label, aria-label, or aria-labelledby.

Vorgeschlagene Korrektur

Add a visible Work email label, connect it with for/id, and preserve the expected email input type and autofill hint.

Vorher · Beispiel-HTML

<input type="email">

Nachher · vorgeschlagenes HTML

<label for="email">Work email</label>
<input id="email" name="email" type="email"
  autocomplete="email" required>

Korrektur prüfen: Re-run the label rule. Tab into the field and confirm that a screen reader announces Work email, its input type, and required state. Submit an invalid email and review the error message separately.

Befund 2 · Critical

Menu button has no accessible name

Betroffenes Element: header button.menu-toggle auf /

Warum es wichtig ist: An icon alone does not tell a screen reader user what the button does. The expanded state helps people understand whether navigation is open.

1 · Schematischer Beispielnachweis. Nachgebauter Oberflächenausschnitt, kein Screenshot oder Livescan. Illustrative markup contains only an SVG inside a button; the SVG is decorative and supplies no accessible name.

Vorgeschlagene Korrektur

Give the button an accessible name. Update aria-expanded when the menu opens or closes and connect aria-controls to the navigation container.

Vorher · Beispiel-HTML

<button class="menu-toggle">
  <svg aria-hidden="true">…</svg>
</button>

Nachher · vorgeschlagenes HTML

<button class="menu-toggle" aria-label="Menu"
  aria-controls="site-nav" aria-expanded="false">
  <svg aria-hidden="true">…</svg>
</button>

Korrektur prüfen: Re-run the button-name rule, then open and close the menu with Enter and Space. Confirm the state is announced, links are reachable, and focus remains predictable when the menu closes.

Empfohlene Übergabe

Bestätigen Sie Befunde in der echten Oberfläche und vereinbaren Sie Zuständigkeiten und Umfang.
Beheben Sie kritische Befunde zuerst; prüfen Sie jeden Vorschlag im Kontext.
Testen Sie den Kundenablauf mit Tastatur und assistiver Technologie.
Scannen Sie dieselben Seiten erneut, dokumentieren Sie ausstehende manuelle Prüfungen und teilen Sie Änderungen mit dem Kunden.