Neu im Team: Tine

Warum Tine, warum jetzt

Wir bauen viel Software für Menschen, die nicht wie wir am Rechner sitzen: Sekretariate, Kanzleien, Shops, Buchungsstrecken. Bisher haben wir Barrierefreiheit nachgerüstet, wenn es jemand angesprochen hat. Das ist teuer, und es ist die falsche Reihenfolge.

Tine bringt genau das mit, was uns gefehlt hat: Sie hat lange in Projekten gearbeitet, in denen blinde Nutzer:innen jeden Tag mit der Software arbeiten. Sie weiß, wie sich ein Formular mit Screenreader anhört, und wo man mit einer Bildschirmlupe hängen bleibt. Ab jetzt ist sie bei unseren Kundenprojekten im Kick-off dabei.

Was wir im Workshop gelernt haben

Der Workshop hatte drei Teile: Warum, Was, Wie. Dazu ein Live-Test einer unserer eigenen Apps, nur mit der Tastatur. Das war der lehrreichste Teil, und auch der unangenehmste.

1. Fast jeder ist irgendwann betroffen

Behinderung betrifft alle Sinne: Sehen, Hören, Motorik, Lernen und Verstehen, Sprache. Und sie ist nicht immer dauerhaft. Wer sich die Hand bricht, kann ein paar Wochen keine Maus benutzen. Wer von Geburt an betroffen ist, kennt seine Umwege. Wer es plötzlich ist, kennt sie nicht. Dazu kommt das Alter. Barrierefreiheit ist also kein Randthema, sondern eine Frage der Zeit.

2. Das Recht verweist fast immer auf die WCAG

Gesetze in Deutschland und der EU verweisen fast immer auf die Web Content Accessibility Guidelines (WCAG). Wer die einhält, deckt meist alles andere mit ab. Seit dem 28.06.2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) für viele Angebote an Verbraucher, etwa Online-Shops und Buchungen. Interne Firmensoftware ist meist freiwillig. Neben der Pflicht gibt es gute Gründe: mehr Zielgruppe, besseres SEO, mehr Talente, die mitarbeiten können.

3. So nutzen Menschen das Web wirklich

4. Die dunkle Bibliothek

Tines Bild für gute Oberflächen: Du stehst in einer dunklen Bibliothek und suchst ein Buch.

1. Den Lichtschalter erwartest du neben der Tür. Also Standards einhalten: Login-Aufbau wie überall, Schließen-Knopf oben rechts im Modal, native Formularfelder statt Eigenbau.
2. Die Regale brauchen Beschriftungen. Also sinnvolle Bereiche und Überschriften: nav, main, search, eine saubere Reihenfolge von h1 bis h3.
3. Der Feueralarm piept und blinkt. Also Wichtiges über mehrere Sinne: Ein Formularfehler bekommt roten Rahmen, Text unter dem Feld und je nach Gewicht einen kurzen Ton.

Standard schlägt Eigenbau.

5. Einmal nur mit der Tastatur

Tine hat eine unserer Apps live nur mit Tab, Enter und Esc bedient. Nach wenigen Minuten hatte sie gefunden, was wir monatelang übersehen hatten:

• Der Fokus wanderte hinter das offene Modal. Man tippte im Dunkeln auf der Seite darunter.
• Manche Buttons hatten zwei Fokus-Stopps, weil Elemente ineinander verschachtelt waren.
• Ein Button bestand nur aus einem Icon, ohne Namen. Der Screenreader sagt dann nur „Schaltfläche“.
• Der Fokusrahmen war kaum zu sehen.

Die Regel daraus: Nach jedem fertigen Screen einmal komplett mit Tab durch. Folgt der Fokus der Lesereihenfolge? Bleibt er im Modal? Springt er nach dem Schließen zurück auf den Button, der es geöffnet hat? Das natürliche Werkzeug dafür ist das HTML-Element <dialog> mit showModal(). Es hält den Fokus im Dialog und schließt mit Esc.

6. Fokus, den man sieht

Tines Muster: Der Button bleibt, wie er ist. Dann kommen 2 px Abstand und ein 3 bis 4 px kräftiger Rahmen, mit derselben Rundung, auf der ganzen Seite gleich. Diese Seite nutzt genau das. Drück Tab und vergleich:

:focus-visible {
  outline: 3px solid currentColor;  /* kräftig, mind. 3:1 zum Hintergrund */
  outline-offset: 2px;              /* 2 px Luft zum Element */
}

7. Kontrast mit Ziel

8. Kleine Regeln mit großer Wirkung

• Icon-Buttons brauchen einen Namen für den Screenreader (aria-label) und einen sichtbaren Tooltip. Steht schon Text daneben, kein extra Label, sonst hört man „Speichern Speichern“.
• Wiederholte Elemente mit Kontext: Fünf Schalter heißen nicht fünfmal „an/aus“, sondern „Benachrichtigungen an/aus“.
• Keine Labels, die verschwinden. Steht „Straße“ nur als Platzhalter im Feld, weiß nach dem Tippen niemand mehr, ob es Straße oder Hausnummer war.
• Farbe nie allein. Ein farbiger Punkt bekommt zusätzlich Text oder Tooltip.
• Animation sparsam und abschaltbar. Blinken kann epileptische Anfälle auslösen.
• Verständliche Sprache, kein Entwickler-Jargon in Fehlermeldungen.

9. Zustände, auf die man sich verlassen kann

Nicht zu wissen, was gespeichert ist, ist die größte Fehlerquelle.

Tines Muster fürs Speichern: Beim Klick wird der Text im Button zum Ladekreis, das Formular ist kurz gesperrt. Ist alles gespeichert, gibt es eine kurze Meldung oder einen Ton, und das Formular ist wieder frei. Und bevor man baut, sammelt man mit dem ganzen Team alle denkbaren Fehler und sortiert sie:

10. Testen: zwei Drittel Tool, ein Drittel Mensch

Prüftools finden ungefähr zwei Drittel der Probleme: fehlende Alt-Texte, zu wenig Kontrast. Tines Favorit ist WAVE, ein Browser-Add-on mit einer guten Liste zum Abarbeiten. Was kein Tool prüft, ist der Kontext: Sagt der Alt-Text das Richtige? Fehlt ein Button für den eigentlichen Zweck?

• Screenreader selbst ausprobieren: VoiceOver am Mac, NVDA unter Windows, Orca unter Linux.
• Videos von blinden Nutzer:innen ansehen, bevor man in die Technik geht. Das erklärt das Warum besser als jede Checkliste.
• Betroffene einbeziehen und bezahlen. Eine Expertin ersetzt keine Person, die jeden Tag damit lebt.
• Think-Aloud-Test: Eine Person bekommt eine Aufgabe und denkt laut, ohne Einweisung. Vorher sagen: Wir testen die Software, nicht dich. Was ohne Briefing klappt, ist selbsterklärend. Der Rest gehört ins Training oder in die Oberfläche. Diesen Test machen wir jetzt bei einer Fachsoftware aus einem Kundenprojekt.

11. Barrierefreiheit in KI-Chats

Wir bauen viele Oberflächen, in denen ein KI-Agent im Chat antwortet. Unsere Frage an Tine: Wie macht man das barrierefrei? Ihre Regeln:

• Während die Antwort entsteht, bleibt der Fokus im Eingabefeld.
• Screenreader-Nutzer:innen brauchen sofort ein Signal, dass etwas lädt.
• Die Antwort nicht Wort für Wort vorlesen, während sie gestreamt wird, sondern erst, wenn sie fertig ist.
• Bei Agenten mit vielen Zwischenschritten bewusst auswählen, welcher Status wirklich wichtig ist.

Technisch heißt das: eine Statusregion mit aria-live="polite" und aria-busy während des Streamings. Die WCAG nennt das Status Messages.

Was wir ab jetzt anders machen

• Kick-off mit Tine: Bei Kundenprojekten klären wir am ersten Tag, für wen wir bauen, welcher rechtliche Rahmen gilt und ob das Projekt öffentlich wird.
• Tastatur-Test nach jedem Screen. Fünf Minuten, findet die größten Fehler.
• Ein Fokusrahmen für alles, global über :focus-visible.
• Barrierefreiheit als KI-Kontext: Wir arbeiten viel mit KI beim Programmieren. Deshalb wird aus dem Workshop eine Checkliste, die bei jedem neuen Projekt automatisch mitläuft. Die Regeln legen wir gemeinsam mit Tine fest.
• Die vier Prüffragen der WCAG bei jedem Element:

Willkommen im Team, Tine. Wir freuen uns auf die nächsten Kick-offs.

Häufige Fragen

New on the team: Tine

Tine joins the VARTAKT design team in Berlin, focusing on UX and accessibility. Her kick-off workshop taught us to stick to standards, test every screen with the keyboard alone, keep focus inside modals and return it afterwards, aim for 7:1 contrast where information matters (4.5:1 is the WCAG AA minimum), never rely on colour alone, use think-aloud tests, and design AI chats so screen reader users get an instant loading signal and the answer only once it is complete.