Barrierefreiheit und i18n: Inklusive mehrsprachige Anwendun…

Barrierefreiheit und i18n: Inklusive mehrsprachige Anwendungen entwickeln

Barrierefreiheit und Internationalisierung (i18n) werden in der Softwareentwicklung häufig als getrennte Belange behandelt – von verschiedenen Teams in unterschiedlichen Phasen des Projektlebenszyklus angegangen. Diese Trennung ist ein Fehler: Beide Disziplinen verfolgen dasselbe grundlegende Ziel – Software für alle nutzbar zu machen, unabhängig von ihren Fähigkeiten oder ihrer Sprache.

Wenn Sie Barrierefreiheit und i18n von Anfang an gemeinsam berücksichtigen, entwickeln Sie Anwendungen, die globale Nutzer mit unterschiedlichen Bedürfnissen wirklich bedienen. Behandeln Sie sie als nachträgliche Gedanken, entstehen zwei Mengen technischer Schulden, die sich gegenseitig verstärken.

Warum Barrierefreiheit und i18n eng miteinander verbunden sind

Die Schnittpunkte zwischen Barrierefreiheit und i18n sind umfangreicher, als die meisten Entwickler erkennen:

Screenreader und Sprache: Screenreader nutzen Text-to-Speech-Synthese. Wenn die Seitensprache falsch (oder gar nicht) deklariert ist, werden Wörter falsch ausgesprochen – der Inhalt wird für blinde Nutzer in nicht-englischen Sprachen unverständlich.

RTL und räumliche Navigation: Right-to-Left-Layouts beeinflussen nicht nur das visuelle Design, sondern auch die Tastaturnavigationsreihenfolge und das Fokusmanagement. Eine falsche Fokusreihenfolge beeinträchtigt gleichzeitig die Screenreader-Navigation und die reine Tastaturnavigation.

Schriftarten-Barrierefreiheit über Schriftsysteme hinweg: Hochkontrast-Themes und legasthenikerfreundliche Schriftarten müssen alle in Ihrer Anwendung verwendeten Schriftsysteme unterstützen – nicht nur lateinische Zeichen.

Lokalisierung von Alternativtexten: Bilder benötigen Alt-Text in jeder Sprache, die Ihre Anwendung unterstützt. Ein englischer Alt-Text nützt einem japanischen Screenreader-Nutzer nichts.

Audiodeskriptionen: Zugängliche Videoinhalte erfordern Audiodeskriptionen. In mehrsprachigen Anwendungen müssen diese übersetzt und zeitlich auf das lokalisierte Video abgestimmt werden.

Kognitive Last und Übersetzungsqualität: Prinzipien der einfachen Sprache – kurze Sätze, klare Struktur, einfaches Vokabular – verbessern sowohl die Barrierefreiheit (für Nutzer mit kognitiven Einschränkungen) als auch die Übersetzbarkeit. Komplexes, idiomatisches Englisch ist für Nicht-Muttersprachler schwerer zu verstehen und schwerer präzise zu übersetzen.

WCAG 2.1-Anforderungen mit i18n-Implikationen

WCAG 2.1 (Web Content Accessibility Guidelines) definiert Anforderungen nach vier Prinzipien: Wahrnehmbar, Bedienbar, Verständlich und Robust. Mehrere Kriterien haben direkte i18n-Implikationen.

3.1.1 Sprache der Seite (Stufe A)

Anforderung: Die Standardsprache jeder Webseite muss programmatisch bestimmt werden können.

i18n-Implikation: Das lang-Attribut am <html>-Element muss mit der aktuellen Sprache der Seite übereinstimmen. In einer mehrsprachigen App muss dies dynamisch aktualisiert werden, wenn der Nutzer die Sprache wechselt.

<!-- Korrekt: lang stimmt mit der tatsächlichen Inhaltssprache überein -->
<html lang="ar" dir="rtl">
  <!-- Arabischer Inhalt -->
</html>

<!-- Falsch: Englisches lang bei japanischem Inhalt -->
<html lang="en">
  <p>日本語のコンテンツ</p>
</html>

In React mit next-i18next oder ähnlichem:

// pages/_document.tsx
import { Html } from 'next/document';

export default function Document({ locale }) {
  return (
    <Html lang={locale} dir={locale === 'ar' || locale === 'he' ? 'rtl' : 'ltr'}>
      {/* ... */}
    </Html>
  );
}

3.1.2 Sprache von Teilen (Stufe AA)

Anforderung: Die Sprache jedes Abschnitts oder Satzes im Inhalt muss programmatisch bestimmt werden können.

i18n-Implikation: Wenn Ihre Seite Text in mehreren Sprachen enthält (z. B. ein englischer Satz innerhalb einer deutschen Seite), muss der Sprachwechsel markiert werden:

<p lang="de">
  Wir bieten auch <span lang="en">premium support</span> an.
</p>

1.3.4 Ausrichtung (Stufe AA)

i18n-Implikation: Einige Schriftsysteme (wie das Mongolische) werden traditionell vertikal geschrieben. Ausrichtungsbeschränkungen können mit schriftsystemspezifischen Lesekonventionen in Konflikt geraten.

1.4.5 Bilder von Text (Stufe AA)

i18n-Implikation: In Bilder eingebetteter Text kann nicht lokalisiert werden. Diese Anforderung fördert die Verwendung von echtem Text (lokalisierbar) anstelle von bildbasiertem Text.

2.4.2 Seite mit Titel (Stufe A)

i18n-Implikation: Seitentitel müssen in jeder Sprache übersetzt sein. Nicht übersetzte Seitentitel sind sowohl ein Barrierefreiheitsfehler (Screenreader lesen Seitentitel vor) als auch ein Lokalisierungsfehler.

ARIA-Labels müssen übersetzt werden

ARIA-Labels sind für Screenreader-Nutzer entscheidend – und sie müssen lokalisiert werden. Jeder String, der an ein ARIA-Attribut übergeben wird, muss aus Ihrem Übersetzungssystem stammen, nicht als englischer Festwert im Code stehen.

// Falsch: hart codiertes englisches ARIA-Label
<button aria-label="Close dialog">X</button>

// Korrekt: übersetztes ARIA-Label
import { useTranslation } from 'react-i18next';

function CloseButton() {
  const { t } = useTranslation();
  return (
    <button aria-label={t('dialog.close')}>
      <CloseIcon />
    </button>
  );
}

Dies gilt für alle ARIA-Attribute: aria-label, aria-description, aria-placeholder, aria-roledescription und alle aria-live-Regionsinhalte.

Für eine tiefergehende Behandlung von React i18n-Mustern lesen Sie unseren React i18n-Leitfaden.

Dynamische Inhalte und Live-Regionen

ARIA-Live-Regionen kündigen dynamische Inhaltsänderungen für Screenreader-Nutzer an. In mehrsprachigen Apps gilt:

Ankündigungen in Live-Regionen müssen in der aktuellen Seitensprache erfolgen
Ladezustände von Übersetzungen müssen barrierefrei kommuniziert werden
Die UX für Sprachwechsel muss den Sprachenwechsel für Screenreader ankündigen

function LanguageSwitcher() {
  const { i18n, t } = useTranslation();
  const [announcement, setAnnouncement] = useState('');

  const changeLanguage = async (locale) => {
    await i18n.changeLanguage(locale);
    setAnnouncement(t('language.changed', { language: locale }));
  };

  return (
    <>
      <select onChange={(e) => changeLanguage(e.target.value)}>
        {/* ... Optionen */}
      </select>
      {/* Barrierefreie Live-Region für Screenreader-Ankündigung */}
      <div aria-live="polite" aria-atomic="true" className="sr-only">
        {announcement}
      </div>
    </>
  );
}

RTL und Tastaturnavigation

RTL-Layouts kehren die visuelle Reihenfolge der Seite um. Die Tastaturnavigation (Tab, Shift+Tab, Pfeiltasten) sollte die visuelle Reihenfolge widerspiegeln – was bedeutet, dass die DOM-Reihenfolge oder tabindex für RTL-Layouts angepasst werden müssen.

Verwenden Sie in CSS logische Eigenschaften anstelle von richtungsbezogenen:

/* Falsch: kodiert links/rechts-Richtungen fest */
.card {
  margin-left: 16px;
  padding-right: 24px;
  border-left: 2px solid var(--accent);
}

/* Korrekt: verwendet logische Eigenschaften, passt sich der Schreibrichtung an */
.card {
  margin-inline-start: 16px;
  padding-inline-end: 24px;
  border-inline-start: 2px solid var(--accent);
}

Einen umfassenden Leitfaden zur RTL-Implementierung finden Sie unter RTL-Unterstützung in CSS und React.

Schriftarten-Überlegungen für Barrierefreiheit und Schriftsystemunterstützung

Barrierefreie Typografie erfordert:

Mindestschriftgrößen (16px für Fließtext ist weit verbreitet empfohlen)
Ausreichende Kontrastverhältnisse (4,5:1 für normalen Text, 3:1 für großen Text gemäß WCAG 2.1 AA)
Unterstützung der Schriftgrößenpräferenzen der Nutzer (relative Einheiten: rem statt px)

Beim Unterstützen mehrerer Schriftsysteme müssen die gewählten Schriftarten:

Alle erforderlichen Unicode-Bereiche abdecken
Lesbare Proportionen über Schriftsysteme hinweg beibehalten (CJK-Zeichen wirken bei für lateinischen Text ausgelegten Größen klein)
Variable Schriftstärken und Größenskalierung für Barrierefreiheitsfunktionen unterstützen

System-Schriftstapel funktionieren für Barrierefreiheit und i18n kombiniert oft gut:

font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Noto Sans,
             Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji';

Noto Sans ist speziell dafür ausgelegt, alle Unicode-Schriftsysteme abzudecken – nützlich, wenn Sie nicht vorhersagen können, welche Schriftsysteme Nutzer benötigen werden.

Farbe und kulturelle Bedeutung

WCAG verlangt, dass Farbe nicht das einzige Mittel zur Informationsvermittlung sein darf (1.4.1). Diese Regel überschneidet sich mit kulturellen Farbbedeutungen:

Rot bedeutet in westlichen Kontexten „Stopp" oder „Gefahr", in chinesischen Kontexten hingegen Glück
Sich allein auf Farbe für Gewinn-/Verlustindikatoren zu verlassen (Rot = Verlust, Grün = Gewinn) verstößt sowohl gegen WCAG als auch gegen kulturübergreifende Nutzbarkeit

Verwenden Sie für wichtige Statusindikatoren Farbe plus Textbeschriftungen plus Symbole:

function PriceChange({ value, locale }) {
  const isPositive = value > 0;
  return (
    <span 
      className={isPositive ? 'gain' : 'loss'}
      aria-label={`${isPositive ? t('price.gain') : t('price.loss')}: ${formatCurrency(value, locale)}`}
    >
      {isPositive ? '▲' : '▼'} {formatCurrency(value, locale)}
    </span>
  );
}

Formularvalidierung und Fehlermeldungen

Barrierefreie Formularvalidierung erfordert:

Fehlermeldungen, die über aria-describedby mit ihren Feldern verknüpft sind
Fokusverwaltung, die bei fehlgeschlagener Formularübermittlung zu den Fehlern wechselt
Klare, handlungsorientierte Fehlersprache

Alle Fehlermeldungen müssen übersetzt sein. Stellen Sie in Validierungsbibliotheken wie Zod, yup oder react-hook-form sicher, dass Ihre Fehlermeldungsstrings aus Ihrem i18n-System stammen:

// Falsch: hart codierter englischer Fehler
const schema = z.object({
  email: z.string().email('Please enter a valid email address'),
});

// Korrekt: übersetzte Fehlermeldungen
function useFormSchema() {
  const { t } = useTranslation();
  return z.object({
    email: z.string().email(t('validation.email.invalid')),
  });
}

Barrierefreiheit mit mehrsprachigem Inhalt testen

Das Testen von Barrierefreiheit in mehrsprachigen Apps erfordert Tests in jeder unterstützten Sprache:

Screenreader-Tests: Testen Sie jede Sprache mit einer geeigneten TTS-Stimme. VoiceOver (macOS/iOS), NVDA (Windows), TalkBack (Android). Überprüfen Sie die Aussprache von Schlüsselbegriffen und dass Sprachwechsel angekündigt werden.

Tastaturnavigationstests: Überprüfen Sie die logische Tab-Reihenfolge sowohl in LTR- als auch in RTL-Layouts. Fokusindikatoren müssen in allen Farbthemen sichtbar sein.

Automatisierte Tests: Tools wie axe-core, Lighthouse und Pa11y können viele WCAG-Verstöße automatisch erkennen. Führen Sie sie im CI für jede Locale aus. Integrationsmuster finden Sie unter i18n-Testwerkzeuge, Strategien und Automatisierung.

Farbkontrast-Überprüfung: Überprüfen Sie Kontrastverhältnisse in allen Themes (Hell, Dunkel, Hochkontrast) für allen Text, einschließlich Text in nicht-lateinischen Schriftsystemen.

Rechtliche Anforderungen: Barrierefreiheit über Locales hinweg

Gesetze zur Barrierefreiheit variieren je nach Land und Branche:

Region	Gesetz	Anforderung
USA	ADA, Section 508	WCAG 2.1 AA für Bundesbehörden und öffentliche Einrichtungen
EU	European Accessibility Act (2025)	WCAG 2.1 AA für Produkte/Dienstleistungen in der EU
UK	PSBAR, Equality Act	WCAG 2.1 AA für den öffentlichen Sektor
Kanada	AODA (Ontario), ACA	WCAG 2.0 AA, Weiterentwicklung zu 2.1
Australien	Disability Discrimination Act	WCAG 2.1 AA empfohlen

Für mehrsprachige Anwendungen, die diese Märkte bedienen, ist die Einhaltung der Barrierefreiheit eine gesetzliche Anforderung in der Sprache der bedienten Nutzer. Eine barrierefreie englische Oberfläche erfüllt nicht die ADA-Anforderungen für spanischsprachige Nutzer, wenn die spanische Oberfläche die Barrierefreiheitsstandards nicht erfüllt.

Grundlagen:

lang-Attribut für jede Sprache korrekt gesetzt
dir-Attribut für RTL-Sprachen gesetzt
Aller Text aus dem i18n-System (nichts hart codiert)
ARIA-Labels und -Beschreibungen übersetzt

Visuelles Design:

Logische CSS-Eigenschaften verwendet (nicht richtungsbezogene)
Farbe nicht das einzige Mittel zur Informationsvermittlung
Ausreichender Kontrast in allen Farbthemes
Schriftart unterstützt alle erforderlichen Schriftsysteme
Relative Schriftgrößen für Nutzerpräferenzen

Interaktion:

Tastaturnavigation in LTR und RTL logisch
Fokusindikatoren in allen Themes sichtbar
Dynamischer Inhalt über ARIA-Live-Regionen angekündigt
Sprachwechsel für Screenreader angekündigt

Formulare:

Fehlermeldungen übersetzt und mit Feldern verknüpft
Formularbeschriftungen übersetzt
Platzhaltertext übersetzt
Validierungsrückmeldung in der Sprache des Nutzers

Tests:

axe-core/Lighthouse im CI für jede Locale
Manueller Screenreader-Test in wichtigen Sprachen
RTL-Tastaturnavigation überprüft
Farbkontrast über alle Themes und Schriftsysteme überprüft

Machen Sie Ihre App mit better-i18n global

better-i18n kombiniert KI-gestützte Übersetzungen, git-native Workflows und globale CDN-Auslieferung in einer entwicklerorientierten Plattform. Hören Sie auf, Tabellenkalkulationen zu verwalten, und fangen Sie an, in jeder Sprache zu veröffentlichen.

Kostenlos loslegen → · Funktionen entdecken · Dokumentation lesen

Barrierefreiheit und i18n: Inklusive mehrsprachige Anwendungen entwickeln