Accessibility und barrierefreies Design -- Warum dein Startup niemanden ausschliessen sollte

1,7 Millionen Menschen in Österreich leben mit einer Behinderung. Dazu kommen Millionen mit temporären Einschränkungen -- ein gebrochener Arm, eine Augenentzündung, oder einfach eine helle Sonne auf dem Display. Wenn dein Produkt nicht barrierefrei ist, schliesst du all diese Menschen aus.

Aber Accessibility ist nicht nur eine moralische Verpflichtung. Ab dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BaFG) in Österreich -- die nationale Umsetzung des European Accessibility Act. Für viele digitale Produkte und Dienstleistungen wird Barrierefreiheit damit zur Pflicht.

In diesem Beitrag zeige ich dir, was du als Startup wissen und tun musst -- ohne Fachjargon und mit sofort umsetzbaren Tipps.

Was bedeutet Accessibility im digitalen Kontext?

Digitale Accessibility (oft als "a11y" abgekürzt -- 11 Buchstaben zwischen dem "a" und dem "y") bedeutet, dass dein Produkt von allen Menschen genutzt werden kann, unabhängig von ihren Fähigkeiten.

Arten von Einschränkungen:

Das zeigt: Accessibility betrifft nicht "die anderen" -- es betrifft uns alle. Jeder von uns ist irgendwann in einer Situation, in der barrierefreies Design den Unterschied macht.

Die rechtliche Lage in Österreich

Das Barrierefreiheitsstärkungsgesetz (BaFG)

Seit dem 28. Juni 2025 müssen viele digitale Produkte und Dienstleistungen in Österreich barrierefrei sein:

Betroffene Bereiche:

• E-Commerce-Websites und -Apps
• Bankdienstleistungen und Zahlungsterminals
• Telekommunikationsdienste
• E-Books und E-Reader
• Transportdienste (Ticket-Buchung, Fahrgastinformation)

Wichtig für Startups:

• Kleinstunternehmen (unter 10 Mitarbeiter UND unter 2 Mio. EUR Umsatz) mit Dienstleistungen sind teilweise ausgenommen
• Aber: Produkte (z.B. Software, Apps) sind NICHT ausgenommen
• Bei Nicht-Einhaltung drohen Strafen bis zu 80.000 EUR
• Unabhängig vom Gesetz: Barrierefreiheit ist ein Wettbewerbsvorteil

WCAG -- der Standard

Die Web Content Accessibility Guidelines (WCAG) sind der internationale Standard für digitale Barrierefreiheit. Es gibt drei Stufen:

Das BaFG verlangt in der Regel die Einhaltung von WCAG 2.1 Level AA.

Die 4 Prinzipien der WCAG (POUR)

1. Perceivable (Wahrnehmbar)

Inhalte müssen so präsentiert werden, dass alle Nutzer sie wahrnehmen können.

Konkret:

• Alternativtexte für Bilder: Jedes informative Bild braucht einen alt-Text
• Untertitel für Videos: Für hörbeeinträchtigte Nutzer
• Farbkontrast: Mindestens 4.5:1 für normalen Text, 3:1 für grossen Text
• Keine Information nur durch Farbe: "Rote Felder sind Pflichtfelder" -- was ist mit farbenblinden Nutzern?
• Anpassbare Textgrösse: Nutzer müssen den Text vergrössern können

Kontrast-Checkliste:

2. Operable (Bedienbar)

Alle Funktionen müssen mit verschiedenen Eingabemethoden bedienbar sein.

Konkret:

• Tastatur-Navigation: Alles muss mit Tab, Enter und Pfeiltasten bedienbar sein
• Kein Zeitdruck: Nutzer müssen genug Zeit haben (oder Timeouts verlängern können)
• Keine Inhalte, die Anfälle auslösen: Keine blinkenden Elemente mit mehr als 3 Blitzen/Sekunde
• Skip-Links: "Zum Hauptinhalt springen" für Screenreader-Nutzer
• Klare Fokus-Indikatoren: Sichtbarer Fokusring bei Tastatur-Navigation

Der häufigste Fehler: Entwickler entfernen den Browser-Standard-Fokusring (outline: none) aus ästhetischen Gründen. Tu das nicht! Gestalte stattdessen einen schönen, gut sichtbaren Fokusring:

/* Statt: */
:focus { outline: none; }

/* Besser: */
:focus-visible {
  outline: 2px solid #2563EB;
  outline-offset: 2px;
  border-radius: 4px;
}

3. Understandable (Verständlich)

Inhalte und Bedienung müssen verständlich sein.

Konkret:

• Klare Sprache: Einfache Sätze, keine unnötige Fachsprache
• Vorhersagbares Verhalten: Gleiche Aktionen, gleiches Ergebnis
• Fehlervermeidung: Validierung vor dem Absenden
• Hilfreiche Fehlermeldungen: Was ist falsch und wie kann der Nutzer es beheben?
• Sprachattribut: lang="de" im HTML-Tag setzen

4. Robust (Robust)

Inhalte müssen mit verschiedenen Technologien funktionieren.

Konkret:

• Semantisches HTML: <button> für Buttons, <nav> für Navigation, <main> für Hauptinhalt
• ARIA-Attribute: Wenn semantisches HTML nicht reicht, nutze ARIA (aber: "No ARIA is better than bad ARIA")
• Valides HTML: Fehlerhaftes HTML verwirrt Screenreader
• Kompatibilität: Mit verschiedenen Browsern und assistiven Technologien testen

Accessibility Quick Wins für Startups

Diese Massnahmen kannst du sofort umsetzen -- sie decken die häufigsten Probleme ab:

1. Farbkontrast prüfen und korrigieren (30 Minuten)

Nutze den WebAIM Contrast Checker und prüfe alle Text-Hintergrund-Kombinationen. Die häufigsten Problemstellen:

• Hellgrauer Text auf weissem Hintergrund
• Primärfarbe als Text auf dunklem Hintergrund
• Placeholder-Text in Formularfeldern

2. Alt-Texte hinzufügen (1 Stunde)

Geh durch alle Bilder in deinem Produkt:

3. Tastatur-Navigation testen (30 Minuten)

Schliesse die Maus an und navigiere nur mit der Tastatur durch dein Produkt:

• Tab: Zum nächsten interaktiven Element
• Shift+Tab: Zum vorherigen Element
• Enter: Element aktivieren
• Escape: Modal/Dropdown schliessen
• Pfeiltasten: In Listen und Menüs navigieren

Notiere, wo du hängen bleibst oder wo der Fokus verschwindet.

4. Semantisches HTML verwenden (laufend)

Ersetze generische <div>- und <span>-Elemente durch semantische Alternativen:

5. Formulare richtig auszeichnen (1 Stunde)

<!-- Schlecht -->
<input placeholder="E-Mail">

<!-- Gut -->
<label for="email">E-Mail-Adresse</label>
<input id="email" type="email"
       aria-describedby="email-help"
       autocomplete="email">
<span id="email-help">
  Wir senden dir eine Bestaetigungsmail.
</span>

Jedes Formularfeld braucht ein sichtbares Label, das programmatisch verknüpft ist.

Accessibility-Testing für Startups

Automatisierte Tests (Finden ~30% der Probleme)

Manuelle Tests (Finden die restlichen ~70%)

1. Tastatur-Test: Navigiere ohne Maus durch das gesamte Produkt
2. Screenreader-Test: Nutze VoiceOver (Mac) oder NVDA (Windows, kostenlos)
3. Zoom-Test: Vergrössere auf 200% -- funktioniert noch alles?
4. Farb-Test: Nutze einen Farbenblindheits-Simulator (z.B. in Chrome DevTools)
5. Reduzierte Bewegung: Teste mit prefers-reduced-motion aktiviert

Screenreader testen -- so startest du

VoiceOver (Mac -- bereits installiert):

1. Aktiviere VoiceOver: Cmd + F5
2. Navigation: Ctrl + Option + Pfeiltasten
3. Interaktion: Ctrl + Option + Space
4. Deaktivieren: Cmd + F5

NVDA (Windows -- kostenlos):

1. Herunterladen von nvaccess.org
2. Starten und durch dein Produkt navigieren
3. Tab für interaktive Elemente, Pfeiltasten für Inhalte

Tipp: Die ersten 10 Minuten mit einem Screenreader sind überfordernd. Bleib dran -- nach einer Stunde Übung hast du ein völlig neues Verständnis für dein Produkt.

Accessibility im Design System verankern

Wenn du ein Design System hast (wie in Post 280 beschrieben), integriere Accessibility von Anfang an:

Für jede Komponente dokumentieren:

• Tastatur-Interaktion (welche Tasten, welches Verhalten)
• ARIA-Rollen und -Attribute
• Farbkontrast-Werte
• Fokus-Management
• Screenreader-Ankündigungen

So ist jede Komponente, die aus deinem Design System kommt, automatisch barrierefrei.

Accessibility und Conversion

Barrierefreiheit verbessert nicht nur die Nutzbarkeit für Menschen mit Behinderungen -- sie verbessert die UX für alle:

Studien zeigen:

• Barrierefreie Websites haben durchschnittlich 50% weniger Bounce Rate
• Accessibility-Verbesserungen steigern die Conversion um 15-30%
• SEO profitiert direkt von semantischem HTML und Alt-Texten

ARIA -- die Basics

ARIA (Accessible Rich Internet Applications) erweitert HTML um Barrierefreiheits-Informationen. Aber Vorsicht: ARIA falsch einzusetzen ist schlimmer als gar kein ARIA.

Die wichtigsten ARIA-Attribute:

<!-- Rollen -->
<div role="alert">Fehler beim Speichern!</div>
<div role="dialog" aria-label="Bestaetigung">...</div>

<!-- Zustaende -->
<button aria-expanded="false">Menue</button>
<input aria-invalid="true" aria-describedby="error-msg">
<span id="error-msg">Bitte gib eine gueltige E-Mail ein</span>

<!-- Labels -->
<button aria-label="Schliessen">X</button>
<nav aria-label="Hauptnavigation">...</nav>

Die erste Regel von ARIA: Nutze kein ARIA, wenn es ein HTML-Element gibt, das den Job erledigt. <button> ist besser als <div role="button">.

Accessibility-Roadmap für Startups

Phase 1: Quick Wins (Woche 1)

• Automatisierten Accessibility-Test durchführen (Lighthouse, axe)
• Kritische Kontrast-Probleme beheben
• Alt-Texte für alle Bilder hinzufügen
• lang="de" im HTML-Tag setzen
• Skip-Link hinzufügen

Phase 2: Foundations (Woche 2-3)

• Semantisches HTML überall verwenden
• Tastatur-Navigation sicherstellen
• Fokus-Indikatoren implementieren
• Formulare korrekt auszeichnen
• Fehlermeldungen verbessern

Phase 3: Fortgeschritten (Woche 4-6)

• ARIA-Attribute für komplexe Komponenten
• Screenreader-Testing durchführen
• Animationen mit prefers-reduced-motion steuerbar machen
• Dark Mode anbieten
• Accessibility in CI/CD-Pipeline integrieren

Phase 4: Ongoing (laufend)

• Jedes neue Feature auf Accessibility prüfen
• Regelmässige Audits (quartalsweise)
• Nutzertests mit Menschen mit Behinderungen
• Team-Schulungen
• Accessibility-Statement auf der Website

Ressourcen

• WCAG 2.1 Quick Reference: w3.org/WAI/WCAG21/quickref
• WebAIM: webaim.org -- praxisnahe Anleitungen und Tools
• A11y Project: a11yproject.com -- Community-getriebene Checklisten
• Inclusive Design Principles: inclusivedesignprinciples.org
• Österreichische Kontaktstelle für barrierefreie IT: accessible-it.at

Dein nächster Schritt

Bei Startup Burgenland unterstützen wir dich dabei, dein Produkt barrierefrei zu gestalten -- rechtssicher und nutzerfreundlich. Hol dir jetzt den Gründungszuschuss und mach dein barrierefreies Design zum Wettbewerbsvorteil.

Weiterführende Artikel

• UX-Design Grundlagen für Startups -- So gestaltest du Produkte, die Nutzer lieben
• User Research mit kleinem Budget -- So verstehst du deine Nutzer ohne teures Labor
• Mobile-First Design für Apps -- So erreichst du die Mehrheit deiner Nutzer
• Usability Testing durchführen -- So findest du die Schwachstellen deines Produkts
• Wireframing und Prototyping -- Vom ersten Entwurf zum testbaren Produkt

Dieser Beitrag ist Teil der Serie "UX, UI und Design" auf Startup Burgenland. Alle Beiträge findest du in unserem Blog.

Über den Autor: Felix Lenhard ist Program Director und Startup Coach bei Startup Burgenland. Zuvor Managing Director beim 360 Innovation Lab, Innovation Manager bei RHI Magnesita und Serial Entrepreneur mit internationalen Exits. Über 15 Jahre Erfahrung in Innovation und Unternehmensaufbau.