Barrierefreiheit in Sparks

Sparks orientiert sich an WCAG 2.1 Level AA, EN 301 549 und den Anforderungen des European Accessibility Act (EAA). Diese Seite fasst zusammen, was Interessenten aus Beschaffung, IT und Fachbereichen heute konkret erwarten können – ehrlich zum Ist-Stand, mit Verweis auf Einstellungen in der App.

Stand: 9. Juli 2026 (Vista-Teams-Docs & Vistameet-Teams ACCESSIBILITY_STATUS)

Zielstandards

Die Produktentwicklung richtet sich an gängige europäische Anforderungen. Umfang und Qualität hängen von Browser, Betriebssystem, Tarif und Organisationsrichtlinien ab.

  • WCAG 2.1 Level AA

    Web Content Accessibility Guidelines – Orientierung für wahrnehmbare, bedienbare und verständliche Oberflächen.

  • EN 301 549 V3.2.1

    Harmonisierte Anforderungen für IKT-Produkte und -Dienste im Beschaffungskontext (EU).

  • European Accessibility Act (EAA)

    Rahmen für zugängliche digitale Dienste – relevant für Anbieter und öffentliche Auftraggeber.

Transparenz zum Ist-Stand

Sparks verfolgt WCAG-orientierte Muster (Landmarks, ARIA, Tastatur, i18n in Deutsch und Englisch). Es gibt keine vollständige WCAG-Zertifizierung; der Stand ist heterogen – App-Shell, Account-Oberfläche und Meeting-Raum sind am weitesten, viele Feature-Bereiche punktuell abgesichert. Automatisierte Axe-Tests laufen derzeit nur auf öffentlichen Routen (/login, /join-meeting), nicht auf dem gesamten eingeloggten Produkt.

Überblick: Wo Sie was finden

In der Sparks-App (nach Anmeldung) steuern Nutzer Barrierefreiheit vor allem über Einstellungen. Die öffentliche Barrierefreiheitserklärung mit Feedback-Formular liegt unter der Route /accessibility in der App.

Thema In Sparks
Lesbarkeit & Kontrast Einstellungen → Darstellung (Schriftgröße, Dichte, Hell/Dunkel/System)
Tastatur & Kurzbefehle Einstellungen → Tastenkürzel; globale Suche Ctrl+K / Cmd+K
Orientierung Skip-Link „Zum Hauptinhalt springen“; Landmarks (header, navigation, main)
Sprache der Oberfläche Einstellungen → Allgemein; html lang passt sich bei Sprachwechsel an
Live-Untertitel Einstellungen → Barrierefreiheit; Start der Transkription im Meeting (Moderator)
Erklärung & Feedback Route /accessibility in der App oder Link im Tab Barrierefreiheit

Einstellungen → Barrierefreiheit

Diese Optionen werden lokal im Browser gespeichert und gelten für Meetings auf diesem Gerät.

Einstellung Wirkung
In Live-Untertiteln identifizieren Aus: eigene Untertitelzeilen erscheinen als neutraler „Sprecher“, nicht mit Ihrem Namen – in Live-Anzeige und Mitschrift.
Untertitel immer anzeigen An: Live-Untertitel sind beim Meeting-Start sichtbar, sobald Untertitel verfügbar sind.

Tarif: Live-Transkription und Untertitel

Organisatoren können zusätzlich Termin-Meetingoptionen setzen (Untertitel/Mitschrift erlauben).

Aspekt Starter / Free Kostenpflichtige Pläne
Live-Transkription starten Nur im Demo-Fenster (typisch erste 10 Minuten nach Verbindungsaufbau) Jederzeit im Meeting (Moderator), sofern vom Server erlaubt
Einstellungen (identifizieren / immer anzeigen) Wirken nur, während Live-Untertitel laufen Immer, sobald Untertitel verfügbar sind
Nach Demo-Ende Transkription stoppt; Hinweis in der UI —

Meetings

Der Meeting-Raum nutzt ARIA, Live-Regionen und Tastaturbedienung – Details in der technischen Dokumentation (ACCESSIBILITY_MEETING_ROOM).

  • Toolbar & Steuerung

    Buttons mit aria-label; Status (z. B. Bildschirmfreigabe) über Live-Region; Escape schließt Flyouts und setzt Fokus zurück.

  • Dialoge

    Teilnehmerliste, Whiteboard, Wartesaal: role="dialog", aria-modal; Ansichtsmodus als Radio-Gruppe.

  • Video-Kacheln

    Lade- und Status-Texte in Deutsch/Englisch; video-Elemente mit beschreibendem aria-label (Teilnehmer, lokal/remot, Bildschirmfreigabe).

  • Live-Untertitel & Mitschrift

    Moderatoren starten/stoppen Transkription; Anzeige und Mitschriftpanel an accessibilityStore angebunden.

App, Tastatur und Betriebssystem

  • ✓

    Skip-Link & Landmarks

    „Zum Hauptinhalt springen“ bei Tastaturfokus sichtbar; header, aside (Navigation), main mit id main-content.

  • ✓

    Tastaturkürzel

    Teams-orientierte Liste unter Einstellungen, anpassbar und in localStorage gespeichert.

  • ✓

    Reduzierte Bewegung

    Bei prefers-reduced-motion werden Animationen in der App stark reduziert.

  • ✓

    Zoom & Touch

    Viewport blockiert Zoom nicht (maximum-scale=5); Account-App: Touch-Ziele mind. 44×44 px auf Mobilgeräten.

  • ✓

    Screenreader & OS

    Erzähler, VoiceOver, TalkBack mit aktuellem Browser (Chrome, Firefox, Safari, Edge); OS-Kontrast und Vergrößerung wirken auf die gesamte App.

Chat, Kanäle und weitere Bereiche

  • •

    Matrix-Chat

    Nachrichtenbereich role="log", aria-live; Lade- und Fehlerzustände mit status/alert; E2EE-Assistent mit Fokusführung.

  • •

    Teams-/Matrix-Kanäle

    Analog Chat mit Live-Regionen; MS-Channels teilweise mit ARIA – nicht durchgängig auditiert.

  • •

    Kalender, Planner, KI

    role="main" und punktuelle Live-Regionen; komplexe UI (z. B. Drag-and-drop im Planner) ohne vollständig dokumentierte Tastatur-Alternative.

Entwicklungsstand nach Bereich

Bereich Stand Anmerkung
App-Shell (Navigation, Skip-Link) Gut AppLayout mit Landmarks und fokussierbarem Hauptinhalt
Account-App (Registrierung, Profil) Geprüft Skip-Link, semantische Überschriften, 44 px Touch-Ziele
Meeting-Raum Teilweise ARIA, Toolbar, Tiles i18n; Immersive View mit Lücken
Einstellungen & Erklärung Vorhanden Tab Barrierefreiheit, /accessibility, Feedback-Formular
Automatisierte Tests Begrenzt Axe E2E nur /login und /join-meeting

Bekannte Grenzen

  • Eingebettete Tabs, Custom Tabs und Microsoft-Teams-Apps (iframe): Barrierefreiheit der externen Website.
  • Immersive View (Together Mode): vor allem visuell; keine Screenreader-Beschreibung pro Teilnehmer-Slot auf dem Canvas.
  • Admin-Oberfläche und Outlook-Add-in: nicht in der A11y-Dokumentation erfasst.
  • Kein globaler Fokus-Trap im Gast-Wartesaal (optional geplant).

Qualitätssicherung

Im Vistameet-Teams-Projekt: npm run test:e2e:a11y (Playwright + axe-core, WCAG 2.0/2.1 Level A & AA Tags). Manuelle Screenreader-Tests (NVDA, VoiceOver) für den gesamten eingeloggten Umfang sind empfohlen, aber nicht als Dauerprozess dokumentiert.

Feedback und Barrierefreiheitserklärung

Konkrete Barrieren helfen bei der Priorisierung. Bitte Browser, Betriebssystem und Schritte zur Reproduktion angeben.

accessibility@vistameet.eu

Erklärung in der App

Eingeloggte Nutzer finden unter /accessibility die Barrierefreiheitserklärung mit Feature-Übersicht und Feedback-Formular (Touch-Höhe 44 px, aria-describedby). Der Text beschreibt Ziel-Features; der Ist-Stand kann in Einzelbereichen zurückbleiben – siehe Transparenz oben.

Normen und weiterführende Quellen

Externe Referenzen zu Standards; Produktdetails siehe docs.sparks.team (Hilfe Barrierefreiheit).

Häufige Fragen

Ist Sparks vollständig nach EN 301 549 zertifiziert?
Nein. Sparks arbeitet an WCAG-orientierter Umsetzung und dokumentiert den Stand transparent. Für Ausschreibungen liefern wir diese Seite, die Erklärung in der App und auf Anfrage vertiefende Angaben zum Betrieb.
Wie testen wir Sparks mit unserem Screenreader?
Empfohlen: aktueller Browser, DE oder EN in den Einstellungen, Skip-Link per Tab erreichen, Meeting als Gast oder mit Testaccount über /join-meeting. Für Live-Untertitel einen kostenpflichtigen Plan oder das 10-Minuten-Demo-Fenster im Free-Tarif nutzen.
Wo melden wir Barrieren?
Per E-Mail an accessibility@vistameet.eu oder über das Feedback-Formular unter /accessibility in der App.

Sparks im Feature-Vergleich (Zeile Barrierefreiheit) → Sicherheit & Compliance →

Barrierefreiheit im Einsatz besprechen