♿ A11Y Lutèce #6 bei Upfast: Barrierefreiheit als Prozess, nicht als Backlog-Punkt

vom 16. September 2026

Das sechste [A11Y Lutèce]-Treffen (https://www.meetup.com/a11y-lutece/) fand am Mittwoch, dem 16. September 2026, in den Räumlichkeiten von Upfast in der Rue Blondel 7 in Paris statt. Ein Jahr nach der Gründung der Gruppe durch Jean-Pierre Gay und Sébastien Bénard findet das Treffen nun alle zwei Monate statt: sechs Veranstaltungen, ein gut gefüllter Saal und ein einfaches Format – eineinhalb Stunden Vorträge, gefolgt von einem Austausch bei einem Drink.

Der Einlass beginnt um 18:40 Uhr, die Vorträge um 19:10 Uhr. Auf der Meetup-Seite wird es ganz klar gesagt: Es gibt zwar einen Aufzug, aber weder einen barrierefreien Zugang noch barrierefreie Toiletten. Bei einem Meetup zum Thema Barrierefreiheit sollte diese Information als wesentliche Angabe behandelt werden, nicht als Fußnote.

Upfast, eine Personalvermittlungsagentur für IT-Freiberufler, richtet die Veranstaltung aus. Der Gastgeber drückt es ohne Marketing-Jargon aus: Seit dem European Accessibility Act ist Barrierefreiheit kein Punkt mehr, den man ans Ende des Backlogs schiebt, „wenn man Zeit hat“. Sie ist zu einer Verpflichtung geworden und damit zu einer Kompetenz, nach der bei der Personalbeschaffung gesucht wird. TF1, BNP, Sanofi, Accor: Die im Saal genannten Kunden sind zum Teil auch im Publikum vertreten.

Drei Vorträge, drei Ebenen. Nicolas Barcacci berichtet, wie ein mobiles Team den Screenreader in den Entwicklungsprozess der All Accor-App integriert hat. Bertrand Keller geht näher auf die rechtliche Rolle des Referenten und auf die Reifegradindikatoren bei Sopra Steria ein. Guillaume Barbier geht zurück auf die HTML-Ebene: Eine „geschichtete“ Tabelle kann semantisch korrekt sein und dennoch für Screenreader unbrauchbar sein.

Der rote Faden ist nicht „man muss Barrierefreiheit schaffen“. Es ist schwieriger: Spezifizieren reicht nicht aus. Ein Prozess, ein Schema, ein headers-Attribut sind Absichten. Die Umsetzung – Sprint, Governance, Laufzeit des Screenreaders – entscheidet darüber, ob die Absicht die Person erreicht, die sie benötigt.

Umsetzung der Barrierefreiheit in der All Accor-App

• Referenten: Nicolas Barcacci (LinkedIn)
• Art: Erfahrungsbericht
• Sprache: Französisch
• Termin: 16.09.2026 · Upfast, Paris

Ein Vortrag über mobile Entwicklung, keine Erklärung zur Barrierefreiheit. Nicolas Barcacci, Senior-Android-Entwickler bei Accor, erzählt, wie das Team der All Accor-App den Weg von einer im Nachhinein festgestellten technischen Schuld zu einem Prozess gefunden hat, bei dem der Screenreader einen festen Platz im Design, in den Abnahmekriterien und im Sprint einnimmt.

Umsetzung der Barrierefreiheit in der All Accor-App

Die All Accor-App ist ein Produkt für die breite Öffentlichkeit: Hotelbeschreibungen, Bewertungen, Treueprogramm. Für jemanden, der VoiceOver oder TalkBack nutzt, ist jeder Bildschirm eine Abfolge von Fokuspunkten, keine visuelle Komposition. Der Vortrag geht von dieser Diskrepanz aus und davon, wie ein Mobile-Team versucht hat, sie für alle sichtbar zu machen – auch für Designer.

Was der Vortrag behandelt

Der Ausgangspunkt ist kein von oben verordnetes RGAA-Audit. Es ist eine Rückmeldung: Zu viele Barrierefreiheitsprobleme in der App, niemand hatte eine Methode. Das Team beginnt mit einem wöchentlichen einstündigen Workshop. Wir bauen Kompetenzen auf, recherchieren, korrigieren. Dann wird uns klar, dass es nicht ausreicht, Bildschirm für Bildschirm zu korrigieren. Wir müssen das erwartete Verhalten des Screenreaders so darstellen, dass Sehende Anmerkungen dazu machen können.

Daraus ergeben sich drei Schritte, die in dieser Reihenfolge vorgestellt werden: eine visuelle Konvention zur Annotation der Entwürfe, eine Prozessänderung, um keine technische Schulden mehr zu produzieren, und schließlich eine Reihe konkreter Fälle – Bilder, Gruppierungen, Bildschirmtitel, Backend-Inhalte.

Wichtige technische Punkte

Den Screenreader kommentieren, nicht nur den Bildschirm

Das Team erstellt Screenshots und versieht sie mit Anmerkungen. Das in der Sitzung vorgestellte Farbschema ist kein öffentliches Designsystem; es handelt sich um eine interne Sprache, um zu beschreiben, was die Barrierefreiheits-Laufzeitumgebung tun soll:

• blau: Schnellnavigationsstruktur – Überschriften/Orientierungspunkte, das „Inhaltsverzeichnis“, mit dem man einen Block überspringen und den Bildschirm anders als Knoten für Knoten durchlaufen kann;
• grün: Elemente, die weniger strukturierend sind als eine Überschrift, aber in einem einzigen Block vorgelesen werden müssen;
• grau: für sehende Nutzer vorgesehenes Verhalten, das für blinde Nutzer nicht unverändert wiedergegeben wird.

Der Nutzen ist nicht rein kosmetischer Natur. Solange der Screenreader eine unsichtbare API bleibt, kann das Design ihn nicht überprüfen. Eine Anmerkung verwandelt eine Absicht der Barrierefreiheit in ein Designelement, genau wie ein Ablauf oder ein Ladezustand.

Den Prozess ändern, bevor das Backlog aufgebraucht ist

Das Beheben der Barrierefreiheits-Schulden neben der Auslieferung – eine Stunde pro Woche – hat eine offensichtliche Grenze: Man verbringt seine Zeit damit, das zu reparieren, was der Prozess weiterhin produziert. Das Team nimmt daher die Barrierefreiheit in die Abnahmekriterien auf. Eine User Story gilt erst dann als „abgeschlossen“, wenn die Mockups angepasst wurden, einschließlich der Barrierefreiheit.

Hinzu kommen identifizierte Ansprechpartner:

• Barrierefreiheitsbeauftragte auf iOS- und Android-Seite, die zum Tech-Team gehören und nicht in einer separaten Abteilung arbeiten;
• die Anforderung einer ISO-konformen Benutzererfahrung zwischen Unteranwendungen sowie zwischen iOS und Android;
• Sprint-Kapazität, die für bereichsübergreifende Themen reserviert ist – nicht nur für das aktuelle Ticket.

Der Ansprechpartner hier ist nicht der gesetzlich vorgeschriebene Ansprechpartner des Mehrjahresplans (Thema des nächsten Vortrags). Es handelt sich um eine Teamrolle: Man weiß, an wen man sich wenden kann, und das Wissen wird nicht auf drei Slack-Kanäle und ein totes Wiki verteilt.

Bilder: dekorativ oder aussagekräftig

Ein einfacher Fall, der in der Produktion bereits weitgehend nicht mehr funktioniert. Viele Bilder in der Benutzeroberfläche dienen nur der Dekoration. Sie im Barrierefreiheitsbaum zu belassen, überfrachtet eine ohnehin schon lange Lesepassage. Man ignoriert sie.

Manche Bilder enthalten Informationen. Das Beispiel des Zimmers ist die Hotelbewertung: eine „5“ neben grafischen Sternen. Vor der Korrektur verkündete der Screenreader in etwa „Hotel 5“ – die Zahl, nicht die Einheit. Sehende Menschen sehen fünf Sterne. Andere erhalten diese Information nicht. Die Korrektur ist universell und sprachunabhängig: eine Beschreibung (content description / accessibility label), damit der Fokus „5-Sterne-Hotel“ ansagt “.

Knoten gruppieren, ohne den Bildschirm zu verschlingen

Ein mobiler Screenreader bewegt sich Knoten für Knoten vorwärts, wischt nach rechts, wischt nach links. Ohne Bearbeitung ist eine Hotelbeschreibung ein Haufen einzelner Elemente: Name, Stadt, Typ, „ 5“, Sternenbild, Bewertung. Das in der Sitzung gezeigte Beispiel ähnelt einer Sofitel-Karte: Jede Geste, um um ein Atom weiterzukommen. Personen, die die Sprachsynthese beschleunigen, verlieren bei diesen Mikroblöcken noch mehr Zeit.

Die Lösung besteht darin, das, was zusammengehört, zusammenzufassen. „Hotel“ + „5“ + „Sterne“ ergibt als ein einziger Satz Sinn. Der gesamte Bildschirm in einem einzigen Block ergibt keinen Sinn: Wenn ich wissen möchte, ob das Hotel zum ALL-Programm – Accor Live Limitless – gehört, darf ich nicht bis zum Ende einer endlosen Beschreibung warten.

Auf Android ist die dargestellte Eigenschaft die Gruppierung von Nachkommen – mergeDescendants in Compose; die Idee ist in klassischem Vue dieselbe: eine Gruppe, ein Fokus, eine Beschriftung. Der technische Aspekt ist nicht die API. Es geht um die Entscheidung: Was soll gruppiert werden, was nicht?

Bildschirmtitel, Laden, Backend

Drei weitere, eher strukturelle Mängeln:

• Viele Bildschirme haben keinen Titel. Ein sehender Nutzer überfliegt den Inhalt. Ein Nutzer mit einem Bildschirmleseprogramm durchläuft ihn. Ein Bildschirmtitel fasst die Seite zusammen und ist für assistive Technologien aktiv, auch wenn er visuell nicht „hervorgehoben“ wird.
• Ein Ladevorgang muss angekündigt werden. Andernfalls bleibt die Benutzeroberfläche einfach stumm, während die Anwendung arbeitet.
• Solange der Text auf der App-Seite erzeugt wird, kann das Team ihn überarbeiten. Sobald der Inhalt aus dem Backend stammt – CMS, Fachbegriffe, Texte, die nicht unter eigener Kontrolle stehen –, kann das Frontend nichts mehr daran ändern. Nicolas spricht das Thema offen an: Das Backend muss barrierefreie Texte liefern, nicht nur die für Sehende sichtbaren Zeichenfolgen.

Die Demo während der Sitzung dient dazu, das Ergebnis in der Anwendung zu zeigen, nicht dazu, einen API-Katalog durchzugehen.

Was man sich merken sollte

Mobile Barrierefreiheit ist kein Abhaken von Checklisten am Ende eines Tickets. Bei All Accor beginnt sie damit, den Screenreader im Design sichtbar zu machen, und ihn anschließend in die „Definition of Done“ aufzunehmen. Lokale Korrekturen – Sternchen, Gruppierungen, Überschriften – sind nur dann nachhaltig, wenn der Prozess keine neuen Schulden mehr verursacht und das Backend keine Inhalte mehr sendet, die das Frontend nicht barrierefrei darstellen kann.

Überlegungen von Darkwood

Hier handelt es sich eher um ein Koordinationsproblem als um ein Problem mit Widgets. Das Team verfügte über Mitarbeiter, eine Stunde pro Woche und eine Liste mit Fehlern. Das war kein Workflow: keine Eingangskriterien, keine „Definition of Done“, keine Ansprechpartner, keine reservierte Kapazität. Sobald Barrierefreiheit zu einem fest definierten Schritt im Lieferprozess wird – genau wie der Dark Mode oder die große Schriftart im Designprozess –, hört sie auf, ein „Freitagabend-Heldenprojekt“ zu sein.

Das Gruppieren von Knoten vermittelt dieselbe Lektion auf der Ebene der Laufzeit: Zu viel Granularität, und der Nutzer zahlt für jede Geste; zu viel Aggregation, und nützliche Informationen gehen unter. Es ist ein Problem der Schrittgrenze, nicht um „mehr ARIA“. KI-Agenten, die Bildschirme ohne diese Abwägung generieren, werden die atomisierte Hotelbeschreibung nur noch schneller reproduzieren. Wenn dieBarrierefreiheit nicht Teil des Designprozesses ist – kommentiertes Mockup, Akzeptanzkriterien, Prompt-Skill –, wird sie aus dem generierten Code verschwinden, genau wie sie aus dem Backlog verschwunden ist.

Veranstaltungsseite

Erfahrungsbericht zur Barrierefreiheitsstrategie bei Sopra Steria: Entwicklung von Steuerungsindikatoren

• Referenten: Bertrand Keller (Website · LinkedIn)
• Art: Erfahrungsbericht / Strategie
• Sprache: Französisch
• Termin: 16.09.2026 · Upfast, Paris

Bertrand Keller hat den Titel während des Vortrags geändert. Weg vom Slogan des Meetups, hin zur eigentlichen Frage: Bewertungspflicht, Fähigkeit zur Weiterentwicklung, Strategie. Der Vortrag verspricht kein Audit-Kit. Er beschreibt, was das Gesetz von einem Referenten verlangt, warum ein einzelner Referent dies nicht bewältigen kann und warum der Durchschnitt der RGAA-Werte kein Indikator für den Reifegrad ist.

Bewertungspflicht: der Beauftragte, das Schema und was die RGAA-Werte nicht messen

Bertrand Keller nimmt häufig an DevFests teil. Er sagt es gleich zu Beginn: Das Thema Barrierefreiheit landet dort oft in einem kleinen Raum. Hier ist der Saal bereits umgestaltet. Er kann also über Governance sprechen, ohne zwanzig Minuten damit zu verbringen, die Relevanz des Themas zu begründen.

Was der Vortrag behandelt

Zwei Konzepte, die konsequent durchgezogen werden. Muss man planen, bevor man handelt? Nicht immer – aber für einen Referenzrahmen lautet die Antwort des Gesetzes eher „Ja“. Und was ist ein Referenzrahmen für Barrierefreiheit konkret? was ist das eigentlich?

Die Position ist gesetzlich verankert. Digitale Barrierefreiheit ist einer der wenigen Bereiche, die verbindlich vorgeschrieben sind: öffentliche Dienste und Unternehmen, die die für Verpflichtungen im öffentlichen Dienst vorgesehene Umsatzschwelle überschreiten (Bertrand nennt 250 Millionen Euro). Der European Accessibility Act fügt eine weitere Regelung hinzu; der Vortrag geht nicht im Detail auf die Gesetzestexte ein. Der operative Kern ist jedoch klar:

1. ein Mehrjahresplan (Steuerung, Ziele, maximal drei Jahre);
2. jährliche Aktionspläne;
3. Bewertungen.

Das ist kein internes Qualitätsritual. Es ist der Zyklus, den das Gesetz aus einem internationalen Funktionsmodell übernimmt: Konzept, Plan, Bewertung – und erst die Bewertung gibt die Mittel frei. Bertrands bewusst ungewöhnliche Analogie bezieht sich auf Geldgeber und Gleichstellungsindikatoren: Man zwingt Ihnen nicht die Matrix eines anderen Kontexts auf; man fordert Sie auf, Ihre eigenen zu entwickeln, um eine zunehmende Reife unter Beweis zu stellen.

Der Mehrjahresplan von Sopra Steria 2025–2027 ist das Ergebnis dieses Auftrags: der erste von der Gruppe veröffentlichte Plan, ein benannter Ansprechpartner, Zuordnung zu CSR / verantwortungsvoller Digitalisierung.

Wichtige technische Punkte

Der Beauftragte ist kein Auditor mit einem Titel

Der Plan ist nicht frei gestaltbar. Das Gesetz legt die wesentlichen Teile fest – Bertrand spricht von obligatorischen „H2“-Punkten. Der Beauftragte muss dann, oft allein, folgende Aufgaben wahrnehmen:

• die Steuerung des Plans (Umfang, Befugnisse, Name);
• die Beschaffung: In einem großen Konzern werden 80 bis 90 % der Produkte eingekauft; das Gesetz zielt auch auf interne Tools (Urlaub, Personalwesen, Intranet) ab, nicht nur auf das, was verkauft wird;
• die kommerziellen Angebote, wenn man mit Dienstleistern zusammenarbeitet;
• die Personalabteilung: digitalisierter Einstellungsprozess, aber auch die physische Begrüßung (Barrierefreiheit, Lärm, Farbgestaltung);
• die Schulung des gesamten Unternehmens, nicht nur der Entwickler – einschließlich E-Learning, das selbst barrierefrei und manchmal mehrsprachig sein muss;
• die Budgets, die oft fehlen;
• die Audits und der Aufbau von Fachkompetenz.

Das ist sehr vielfältig. Eine Person, die gleichzeitig anhand all dieser Aspekte bewertet wird, „fällt durch“, sobald ein Aspekt nicht zu ihrer persönlichen Geschichte passt. Eine barrierefreie interne Fortbildung aufzubauen, kann eine Vollzeitbeschäftigung sein. Doch da bleibt noch alles andere. Der Ansprechpartner arbeitet mit der Personalabteilung, der Kommunikation und den Inhalten zusammen. Er ist der IT-Abteilung, der Kommunikationsabteilung oder der Geschäftsleitung zugeordnet – und sein Vorgesetzter kennt sich oft nicht mit Barrierefreiheit aus.

Sopra Steria: Beginnen Sie mit dem Konzept, nicht mit dem Durchschnitt der Audits

Sopra Steria, in den Worten von Bertrand: „ein kleines Unternehmen“ mit ~5 Milliarden Umsatz, ~20.000 Mitarbeitern in Frankreich, ~50.000 weltweit, darunter eine indische Tochtergesellschaft. Die Herausforderung betraf nicht „den französischen Konzern“. Es ging um den gesamten Konzern. Das Thema fällt unter den Bereich CSR, genauer gesagt unter den Aspekt der verantwortungsvollen Digitalisierung, im Kontext der CSRD: Die betroffenen Unternehmen müssen Sozialdaten veröffentlichen, und das französische Gesetz von 2016 sah bereits einen Beauftragten vor.

Die organisatorische Falle liegt auf der Hand. Die Ansprechpartner betrachten Barrierefreiheit als eine Kette von Audits. Das Gesetz schreibt Erklärungen vor, also Audits, also „muss“ der Beauftragte „auditen“. Bertrand kehrt dies um: Seine Aufgabe ist das Konzept. Aktionspläne und Bewertungen folgen erst danach. Ohne Rahmenkonzept sammelt man nur Bewertungen an.

Reifegradmodelle lassen sich nicht einfach kopieren

Es gibt mehrere Modelle. Bertrand stellt im Raum mindestens drei davon vor:

• das W3C Accessibility Maturity Model, das eher auf Praktiken ausgerichtet ist, mit Stufen wie „Launch“ / „Integrate“;
• ein eher organisatorisches Modell (Integration in das Unternehmen);
• ein eher Design-/Produkt-orientiertes Modell (das in der Sitzung erwähnte Akronym DAM/AMM bezeichnet diese Modellfamilie neben dem Microsoft-Modell).

Jedes dieser Modelle hat großes Gewicht – es umfasst etwa 150 Kriterien, teilweise auf 5 Stufen (nicht eingeführt, reaktiv, vorausschauend, proaktiv, flächendeckend) und 7 Dimensionen, die sich nicht überschneiden. Ein einzelner Referent kann das nicht einfach „abhaken“. Universitäten verfügen über Matrizen, die die Studierenden einbeziehen. Eine kleine Organisation benötigt eine Matrix, die auf ihre Größe zugeschnitten ist. Microsoft, Hersteller von Betriebssystemen und Geräten, misst nicht dasselbe wie ein IT-Dienstleistungsunternehmen.

Man kann Fähigkeiten, Praktiken und Ergebnisse messen. Das ist nicht austauschbar. Das Gesetz, so wie Bertrand es versteht, verlangt, eigene Indikatoren zu entwickeln – und nicht, eine Vorlage zu übernehmen.

Der tatsächliche Umfang geht über öffentliche Websites hinaus: unternehmensinterne soziale Netzwerke, E-Mails, PowerPoint-Präsentationen, interne PDF-Dateien. All das sollte barrierefrei sein. Hier geht es also um Prozesse und Kultur. Das deutlichste Hindernis, das im Vortrag angesprochen wurde: Die Führungskräfte sind weit von der Praxis entfernt, kennen sich mit Barrierefreiheit nicht aus und entscheiden sich oft für KI oder Barrierefreiheit, nicht für beides.

Der RGAA-Durchschnitt ist kein Steuerungsinstrument

Alle betroffenen Websites, Apps und Intranets müssen über eine Erklärung verfügen, also ein Audit durchlaufen haben. Die RGAA ermittelt eine Punktzahl. Was Organisationen tun: auflisten, prüfen, den Durchschnitt berechnen, 100 % anstreben.

Bertrand ist eindeutig: Das funktioniert nicht. Damit wird eine vorgeschriebene Konformität gemessen, nicht die Reife. Reife kann nicht gesetzlich vorgeschrieben werden, da sie organisationsspezifisch ist. Messen um des Messens willen gibt keinen Aufschluss darüber, was sich weiterentwickelt. Die Rolle des Beauftragten besteht darin, zu wissen, was vorankommt, und nicht darin, einen Durchschnittswert anzugeben.

KI bricht mit den Barrierefreiheitsritualen der alten Welt

Das letzte Drittel ist das aktuellste. Alles, was für die Barrierefreiheit konzipiert wurde – Audits, Checklisten, Schulungen für Entwicklerteams – zielt auf die Welt von früher ab. Heute ist „der Entwickler ein Typ, der in eine Box spricht“ und der dem Modell einen wachsenden Anteil der Software überträgt.

Fragen, die bewusst offen gelassen werden:

• Wo steht die Barrierefreiheit in diesem Ablauf?
• Was misst der Referenzwert?
• Braucht es einen zusätzlichen Teil im Mehrjahresschema?
• Bezieht die Eingabeaufforderung die Barrierefreiheit mit ein?
• Gibt es eine entsprechende Kompetenz, und gerät diese im Laufe des Gesprächs in Vergessenheit?
• Können die langsamen Nutzertests mit dem sehr schnellen KI-Code mithalten?

Die organisatorische Schlussfolgerung: Ein einziger Ansprechpartner, ohne Budget, ohne Experten und mit einer falschen Auslegung des Gesetzes, kommt nicht voran. Das ist kein Geheimnis. Es ist ein unterfinanziertes System.

Was man sich merken sollte

Der Ansprechpartner ist nicht der dienstliche Prüfer. Das Gesetz verlangt ein Konzept, Pläne, Bewertungen – einen Reifegradzyklus, keinen Durchschnitt der RGAA-Bewertungen. Die W3C- und Hersteller-Matrizen dienen als Inspiration, nicht als Checklisten, die man im Alleingang abarbeiten kann. Und das für Teams konzipierte Barrierefreiheitsverfahren, die den Code von Hand schreiben, lässt sich heute nicht auf automatisierte Arbeitsabläufe übertragen.

Überlegungen von Darkwood

Dies ist der Vortrag, der dem am nächsten kommt, was Darkwood als Workflow bezeichnet. Das mehrjährige Konzept ist eine Orchestrierung: benannte Schritte, Verantwortliche, Kennzahlen, Fehlschläge. Der klassische Fehler von Organisationen – mit dem Audit zu beginnen, weil es das sichtbare Ergebnis ist – ist derselbe wie zehn Agenten loszuschicken, ohne die „Definition of Done“ festzulegen. Man erhält Aktivität (Werte, Spuren) ohne Durchsatz (Reife).

Die KI vergrößert diese Lücke noch. Ein Agent, der schnell programmiert, verzichtet auf das zeitaufwendige Ritual des Benutzertests. Wenn Barrierefreiheit kein Schritt im Ablaufdiagramm ist – Eingabeaufforderung, Skill, Überprüfung, Test – nicht als Schritt im Ablaufdiagramm enthalten ist, existiert sie nicht, genau wie sie im Backlog unter „Das sehen wir später“ nicht existierte. Wer sich nur an den RGAA-Kriterien orientiert, wird diese Lücke nicht erkennen: Der Wert von gestern sagt nichts über den heute Morgen generierten Code aus.

Mehrjahresplan Sopra Steria 2025–2027

Wenn Tabellen kaputtgehen: geschichtete Tabellen

• Referenten: Guillaume Barbier (Paris Web · 24 jours de web)
• Art: Technischer Vortrag
• Sprache: Französisch
• Termin: 16.09.2026 · Upfast, Paris

Guillaume Barbier, Business Analyst bei Razorfish, kehrt zum zweiten Mal zur A11Y Lutèce zurück. Sein Spezialgebiet: CMS, die nicht zu viele Barriereprobleme verursachen, wenn die Autoren nicht geschult sind. Komplexe Tabellen waren, wie er selbst zugibt, ein wiederkehrendes Problem. Der Vortrag greift ein bestimmtes Muster heraus: die in Ebenen unterteilte Tabelle.

Wenn Tabellen versagen: Tabellen in Ebenen

Eine Datentabelle ist kein Excel-Raster, das einfach auf eine Seite geklebt wurde. Es handelt sich um eine Struktur aus Kopfzeilen, die den Zellen einen Sinn verleiht. Das „geschichtete“ Muster erscheint auf den ersten Blick einfach: Titelbalken, die die Tabelle in Gruppen unterteilen. Für einen Screenreader sind diese Balken jedoch oft implizite Elemente, die nicht berücksichtigt werden.

Was der Vortrag behandelt

Die Fallstudie lässt sich in einem Raster darstellen. Drei Spalten – Name, Position, Vorgesetzter – sieben Zeilen. Vier Mitarbeiter sowie zwei Zeilen in „voller Breite“: Abteilung für Informationssysteme (DSI), gefolgt von der Marketingabteilung. Optisch erkennt man auf einen Blick, dass Abdel Cherif, Entwickler, zu Nathalie Nguyen und zur IT-Abteilung gehört; Samia Réno, Systemadministratorin, zur gleichen Abteilung.

Nichts davon steht in den Zellen der Mitarbeiter. Es handelt sich um eine räumliche Zuordnung. Um diese im Code nachzubilden, verknüpft Guillaume jede Zelle mit ihren Überschriften: Spalte „Name“, Ebene „IT-Abteilung“, Spalte „Beruf“ und den Hinweis, dass der Entwickler Abdel Cherif ist. In HTML ist das die umständliche Methode: id für die Kopfzeilen, headers für die Zellen. Er bittet die Anwesenden, ihm bei der Markierung zu vertrauen. Dann startet er den Bildschirmleser.

Es funktioniert nicht.

Wichtige technische Punkte

Das visuell Selbstverständliche ist nicht im Baum enthalten

Sehende Nutzer verbinden unbewusst die oberen Spalten mit dem Schichtbereich. Der Screenreader erhält nur das, was ihm der Barrierefreiheitsbaum liefert. Diese Zuordnung neu zu programmieren, ist die eigentliche Arbeit – nicht „eine Tabelle zu erstellen“. Guillaume lehnt den 20-minütigen HTML-Kurs ab. Das Thema ist funktional: Habe ich explizit gemacht, was mein Auge von selbst tut?

Es ist dasselbe Problem wie bei den Accor-Sternen, nur auf der Ebene eines Rasters: Die Information steckt im Layout.

Selbst korrekte Markup-Auszeichnung kann zur Laufzeit noch versagen

Die Demo ist der Höhepunkt des Vortrags. Der Reader kündigt eine Tabelle mit 3 Spalten und 7 Zeilen an und ordnet der ersten Zelle dann Überschriften zu, die Guillaume nicht verknüpft hat – IT-Abteilung und Marketingabteilung auf einen Schlag. Weiter unten wird Samia Réno „wie eine Ermittlung“ an die IT-Abteilung geklebt. Solange man in einer Spalte bleibt, funktioniert es mehr oder weniger. Sobald man die Zeile wechselt, geht die Darstellung durcheinander.

Die Feststellung, ohne große Effekthascherei: Die semantische Struktur ist vorhanden, der Screenreader findet sich darin nicht zurecht. Guillaume hat keine Zeit, die technischen Hintergründe (Browser, Accessibility-Tree, AT-Kombinationen) zu erklären. Daraus zieht er die technische Lehre: Ab einem bestimmten Muster ist „gutes HTML“ keine Garantie für die korrekte Darstellung. Zu komplexe Tabellen brechen zusammen, selbst wenn sie korrekt spezifiziert sind.

Ausführlicher dokumentiert ist dies in seinem Artikel Sind komplexe Datentabellen barrierefrei möglich? (24 Tage Web, 2025). Das Meetup ist die demonstrierte Version davon, am Beispiel von „Strates“.

Zwei Ansätze: vereinfachen oder aufteilen

Anstatt immer mehr id/headers zu stapeln, sollte man einen Schritt zurücktreten: Brauchen wir diese Komplexität wirklich? Dieselbe Information lässt sich robuster darstellen.

Abflachen. Die Schichten werden wieder zu einer Spalte wie jede andere – „Service“. Man verliert die sofortige visuelle Gruppierung. Man gewinnt ein regelmäßiges Raster, das Screenreader durchlaufen können.

Aufteilen. Eine Tabelle pro Ebene. Ein <caption> verweist auf den Dienst (IT, Marketing), wie der Screenreader beim Aufrufen der Tabelle ankündigt. Weniger kompakt. Einfacher. Zwei unabhängige Datensätze mussten vielleicht gar nicht in einem einzigen Raster koexistieren.

In beiden Fällen fordert man die Barrierefreiheits-Laufzeitumgebung nicht mehr auf, eine Choreografie auszuführen, die die Browser nicht unterstützen.

Was man sich merken sollte

Eine tabellarische Darstellung in Ebenen ist angenehm für das Auge, aber für Screenreader unfreundlich, selbst wenn sie gut markiert ist. Die Lösung besteht nicht darin, mehr Attribute hinzuzufügen. Es handelt sich um eine andere Form: eine Service-Spalte oder mehrere Tabellen mit Überschriften. Visuelle Komplexität ist keine geschäftliche Konstante.

Überlegungen von Darkwood

Noch einmal: Die Spezifikation ist nicht die Ausführung. headers und id sind ein Vertrag. Der Screenreader ist die Laufzeitumgebung. Wenn die Laufzeitumgebung den Vertrag nicht einhält, ist das System für den Nutzer fehlerhaft, unabhängig davon, ob die Spezifikation eingehalten wird.

Es ist dieselbe Diagnose wie bei Flow oder einem Agenten: Zu feine Schritte oder ein zu dichtes Diagramm führen zu einer unlesbaren Ablaufverfolgung. Das Zusammenführen (eine weitere Spalte) oder das Aufteilen (zwei Workflows) sind architektonische Entscheidungen. CMS, die es den Autoren erlauben, Zellen zusammenzuführen, „damit es hübsch aussieht“, führen von Natur aus zu Barrierefreiheit – Guillaume sagt das schon seit zehn Jahren. Mitarbeiter, die aus einer Excel-Datei <table> generieren, tun dasselbe, nur schneller – es sei denn, der Workflow verbietet dieses Vorgehen.

Guillaume leitet am 24. September 2026 bei Paris Web den Workshop Das Implizite denken, das Unsichtbare denken. Das Meetup war bereits ein Vorgeschmack darauf: Das visuelle Implizite ist, sobald es unausgesprochen bleibt, eine Barriere.

Artikel „24 Tage Web“

Was den Abend zusammenhält

Drei Ebenen, eine einzige Kluft.

Bei Accor gab es den Screenreader im Prozess noch nicht: Wir haben ihn sichtbar gemacht (Anmerkungen), dann verbindlich vorgeschrieben (DoD) und schließlich mit den entsprechenden Werkzeugen ausgestattet (Ansprechpartner, ISO für iOS/Android, Sprint-Fähigkeit). Bei Sopra Steria gab es zu viele Audits: Wir mussten zum Grundkonzept und zu den Reifegradindikatoren zurückkehren und einsehen, dass ein Referent allein nicht für Einkauf, Personalwesen, Schulung und KI ausreicht. Bei Guillaume gab es zu viel HTML: Das „Strates“-Muster ist „korrekt“, aber fehlerhaft.

Die Barrierefreiheit kommt mangels Checkliste nicht voran. Sie kommt voran, wenn man aufhört, Aktivität und Ergebnis zu verwechseln: RGAA-Durchschnitt, festgelegte Attribute, geschlossene Tickets. Das Ergebnis ist eine Person, die die Hotelbeschreibung versteht, die einstellen kann, die eine Tabelle lesen kann. Der Rest ist Inszenierung.

KI ist in den drei Vorträgen kein Bonuskapitel. Sie ist die neue Laufzeitumgebung der Software. Wenn man Barrierefreiheit nicht in den Ablauf einbindet – Entwurf, Kriterium, Aufforderung, Fertigkeit, Nutzertest –, wird sie so generiert, wie man früher Tabellen in Schichten generierte: schön, implizit und stumm.

Vielen Dank an Jean-Pierre Gay, Sébastien Bénard, an Upfast für die Gastfreundschaft und an die drei Referenten. Die Gruppe trifft sich weiterhin alle zwei Monate; Vorschläge für Vorträge sind weiterhin willkommen. Pizza, Chips, Bier: Networking ist kein Nebenschauplatz. Hier werden die Kompetenzen rekrutiert, die die EAA zu unverzichtbaren Voraussetzungen gemacht hat.

Meetup #6 A11Y bei Upfast