Die Stichprobe umfasst 50 Figma-Dateien aus 28 Produktteams aus den Bereichen SaaS, Einzelhandel, Fintech, öffentlicher Sektor und Edtech. Der Nur-Ansicht-Zugang wurde auf Basis der Nicht-Zuordnung ausgehandelt: Nichts in diesem Artikel identifiziert eine Marke, ein Team oder einen Designer. Die Dateien wurden ausgewählt, um das widerzuspiegeln, was ein Entwickler bei der Übergabe tatsächlich erhält — nicht eine ausgearbeitete Fallstudie von einer Portfolio-Seite — daher wurde jedes Team gebeten, die Datei zu teilen, aus der das jüngste Feature geliefert wurde, nicht die Datei, auf die sie am stolzesten waren. Zwölf der Dateien stammten von Teams mit einer dedizierten Design-System-Praxis; die anderen 38 waren Produktebenen-Dateien, die eine Systembibliothek importierten oder eigene Komponenten inline rollten.

Jede Datei wurde auf fünf Barrierefreiheitseigenschaften untersucht: Fokus-Zustand-Design an jeder interaktiven Komponente, Alternativtext-Annotationen an jedem Bild oder nicht dekorativem Symbol, Dokumentation der Lesereihenfolge im gesamten Layout, Umgang mit Bewegungspräferenzen für jedes animierte oder transitierende Element sowie Dunkelmodus-Kontrast-Spezifikation für jede Komponente, die in Hell- und Dunkelmodus ausgeliefert wird. Für jede Eigenschaft erhielt eine Datei die Bewertung „dokumentiert“ nur dann, wenn ein kompetenter Entwickler das Design implementieren könnte, ohne die Antwort selbst erfinden zu müssen. „In einem Haftzettel erwähnt“ zählte nicht. „Hex in einem einzigen Hover-Zustand angegeben“ zählte nicht. Die Messlatte war: Liegt die Entscheidung in der Datei in einer Form vor, auf die der Entwickler ohne Rückfragen handeln kann?

Der Hauptbefund ist, dass die Übergabe nach diesem Maßstab die Barrierefreiheitsentscheidungen weit häufiger vermisst als beinhaltet. Fokus-Zustand-Design erschien bei ca. 40 % der interaktiven Komponenten im Korpus. Alternativtext-Annotationen erschienen bei etwa 22 % der Bilder, die sie benötigten. Die Lesereihenfolge war in 16 % der Dateien explizit dokumentiert. Bewegungspräferenzen wurden in 10 % berücksichtigt. Dunkelmodus-Kontrast — für die 31 Dateien, die beide Themen liefern — war für 30 % der Komponenten angegeben. Die Lücke liegt nicht in einer einzigen Eigenschaft. Sie liegt in allen fünf, und der Entwickler bleibt damit, sie ein Urteil nach dem anderen zu schließen.

Von den ca. 1.800 interaktiven Komponenten, die im Korpus berührt wurden — Schaltflächen, Links, Eingaben, Kontrollkästchen, Schalter, Tabs, Comboboxen, Menüelemente, Karten-als-Schaltfläche, alles, was ein Tastaturnutzer erreichen kann — lieferten etwa 40 % einen entworfenen Fokus-Zustand. Die anderen 60 % lieferten einen Standard-, einen Aktiv- und einen Hover-Zustand und hörten dann auf. Der Entwickler, der die Komponente aufbaut, wählt einen Fokus-Umriss zum Implementierungszeitpunkt, normalerweise durch Kopieren des Browser-Standards, normalerweise ohne zu prüfen, ob der Standard ein 3:1-Kontrastverhältnis gegen die Oberfläche der Komponente in beiden Hell- und Dunkelmodi hat, die die Datei liefert.

Wie sieht „kein Fokus-Zustand-Design“ in der Praxis aus? Es sieht aus wie eine Schaltflächen-Komponente mit drei Varianten auf der Leinwand — Ruhezustand, Hover, Gedrückt — und keiner vierten Variante. Es sieht aus wie ein Eingabefeld mit einem gestalteten Rahmen und ohne zweiten Rahmenstil für den fokussierten Zustand. Es sieht aus wie ein Kontrollkästchen-Primitiv mit einem Fokusring nur in der Ruhezustand-Variante, wobei dem Entwickler überlassen bleibt zu raten, ob derselbe Ring in der markierten oder unbestimmten Variante erscheinen soll. Das Muster wiederholt sich über Komponenten, über Teams, über Sektoren hinweg. Es ist die einzige größte Barrierefreiheitslücke im Korpus und die einzige, die am einfachsten einzudesignen wäre.

Die Teams, die Fokus-Zustände gut entworfen haben, hatten eines von zwei Dingen für sich. Das erste war eine explizite Design-System-Regel: jede interaktive Komponente muss eine Variante liefern, deren Name mit focus- beginnt, und die Komponente wird erst dann in die Bibliothek freigegeben, wenn diese Variante existiert. Das zweite war eine Figma-Komponenteneigenschaft namens state mit focus, focus-visible und focus-within als enumerierten Werten, sodass der Komponentenbrowser der Datei die fehlenden Varianten visuell anzeigt. Teams ohne eines dieser beiden Gerüste überließen den Fokus-Zustand dem Entwickler etwa neun von zehn Mal.

Von den Dateien im Korpus, die Inhaltsbilder enthielten — Produktfotos, Hero-Illustrationen, Nur-Symbol-Schaltflächen, infografische Figuren — hatten 78 % keine Alternativtext-Annotationen an den Bildebenen. Das Bild wurde platziert, skaliert und gestaltet; das textliche Äquivalent, das der Entwickler an das gerenderte <img> setzen sollte, war nicht in der Datei. Acht der 50 Dateien hatten Alternativtext bei einigen Bildern, aber nicht bei allen, normalerweise mit der Hero-Illustration annotiert und den Inhaltsbildern im Fließtext leer. Drei Dateien hatten Alternativtext bei jedem Bild. Der Entwickler sollte in 47 von 50 Dateien den Alternativtext erfinden — und übernahm ihn in der Praxis häufig aus dem Dateinamen, der Bildunterschrift oder welcher Zeichenkette auch immer in den visuellen Rhythmus passte.

Die Lücke ist strukturell im Bild-Primitiv von Figma begründet. Es gibt keine native „alt“-Eigenschaft bei einer Bildfüllung oder einer Bildebene; Alternativtext muss als Ebenename, Kommentar, Haftzettel, separates Spec-Dokument oder plugin-hinzugefügtes Feld übermittelt werden. Keines davon wird standardmäßig durch das Inspect-Panel übertragen, sodass der Entwickler, der die Datei in der Inspect-Ansicht liest, den Alternativtext nicht sieht, selbst wenn der Designer ihn anderswo geschrieben hat. Teams, die die Lücke konsequent schlossen, verwendeten einen von drei Workarounds: plugin-verwaltete Alternativtext-Felder an jeder Bildvariante, eine dokumentierte Konvention, dass der Ebenename der Alternativtext ist, oder eine separate Alternativtext-Tabelle, die auf Bilddateinamen verweist und neben der Datei geliefert wurde.

Nur-Symbol-Schaltflächen waren ein Unterversagen in diesem Fehlermodus. In 41 von 50 Dateien hatten Symbol-Schaltflächen — das Suchlupenglas, das Menü-Hamburger-Symbol, das Schließen-X, der Teilen-Pfeil — keine barrierefreien Namen-Annotationen, sodass der Entwickler aria-label=“Suche” aus dem visuellen Kontext heraus schreiben musste, ohne Bestätigung, dass „Suche“ das richtige Wort in der Markensprache war (war es „Finden“? war es „Nachschlagen“? war es nichts, weil die Schaltfläche ein anderswo bezeichnetes Panel öffnet?). Symbol-Benennung ist genau die Art von Micro-Copy-Entscheidung, die von einem Designer-Stift profitiert, und genau die Art, die die Übergabe verliert.

Die verbleibenden drei Eigenschaften hatten unterschiedliche Fehlermuster. Die Lesereihenfolge — die Reihenfolge, in der ein Screenreader die Seite vorliest, die in modernen responsiven Layouts nicht mehr zwingend der visuellen Oben-nach-unten-Reihenfolge entspricht — war in 16 % der Dateien dokumentiert. Die Dokumentation, wo sie existierte, war normalerweise eine nummerierte Überlagerung auf der Leinwand (1, 2, 3 …), die mit einem Plugin hinzugefügt wurde. Die anderen 84 % überließen dem Entwickler die Zuordnung der Lesereihenfolge aus der DOM-Reihenfolge, die er zufällig schrieb, was in einem CSS-Grid-Layout mit expliziter Zeilen-und-Spalten-Platzierung um eine gesamte Spalte von der visuellen Anordnung abweichen kann.

Bewegungspräferenzen schnitten am schlechtesten ab. Zehn Prozent der Dateien erwähnten prefers-reduced-motion überhaupt. Die verbleibenden 90 % spezifizierten Animationen und Übergänge — Modal-Eintritte, Akkordeon-Erweiterungen, Snackbar-Gleitbewegungen, Seitenübergänge — ohne anzugeben, was dieselbe Komponente tun soll, wenn der Nutzer reduzierte Bewegung aktiviert hat. Der Entwickler baute den reduzierten Bewegungsfall zur Implementierungszeit (oft ohne visuelle Referenz) oder lieferte dieselbe Animation an alle, was der Standard ist und was WCAG 2.3.3 (Animation aus Interaktionen) für Nutzer verletzt, die die Einstellung gesetzt haben.

Dunkelmodus-Kontrast wurde für 30 % der Komponenten in Dateien spezifiziert, die beide Themen lieferten. Die anderen 70 % spezifizierten den Hellthema-Kontrast — normalerweise mit einer Stark- oder Kontrast-Prüfer-Annotation in der Datei — und veröffentlichten dann das dunkle Thema mit einer hex-umgekehrten Palette, wobei der Entwickler prüfen sollte, ob das umgekehrte Paar noch 4,5:1 bei Fließtext und 3:1 bei UI-Komponenten einhält. In etwa einem Fünftel der 31 Dual-Thema-Dateien fiel mindestens eine Komponente im dunklen Thema unter den Kontrast-Schwellenwert, weil die dunkle Oberfläche und der dunkle Text beide für die Kontrastmathematik des hellen Themas, nicht des dunklen Themas, abgestimmt waren.

Die zwei Plugins, die im Korpus am häufigsten auftauchen, sind Stark und Able. Beide sind ausgereift, beide sind gut angesehen, und beide liefern Funktionen, die mehrere der oben dokumentierten Lücken schließen. Stark fügt einen Kontrast-Prüfer, eine Fokus-Reihenfolge-Überlagerung, eine Reduzierte-Bewegung-Vorschau und ein Alternativtext-Annotationsfeld an Bildebenen hinzu. Able fügt einen Farbkontrast-Inspektor, eine Sehsimulations-Überlagerung und einen Touch-Target-Prüfer hinzu. Jedes Plugin, wenn es konsequent in einer Datei verwendet wird, würde diese Datei aus dem untersten Quartil des Korpus herausheben.

Konsequent verwendet ist die entscheidende Formulierung. Über die 50 Dateien hinweg war Stark in 18 installiert und sichtbar verwendet, Able in 11. In den Dateien, in denen das Plugin verwendet wurde, wurde es normalerweise an der Hero-Komponente und dem primären CTA verwendet — den Komponenten, die am wahrscheinlichsten auf der Leinwand sind, wenn der Designer das Plugin öffnete — und nur selten anderswo. Sechs Dateien verwendeten Stark in einem globalen Durchgang; eine verwendete Able in einem globalen Durchgang. Das Muster ist: Plugins existieren, Designer wissen von ihnen, sie werden für Stichprobenprüfungen herangezogen, und dann hört die Stichprobenprüfung bei den Komponenten auf, die der Designer gerade betrachtete, als das Plugin geöffnet war.

Die zwei Teams, die das Audit hinsichtlich der Plugin-Nutzung abschlossen, taten eine Sache anders: Sie führten die Audit-Funktion des Plugins als Release-Gate-Schritt auf jeder Seite der Datei aus, bevor die Datei mit dem Engineering geteilt wurde. Das Audit lief in der Datei, erstellte einen Bericht, und der Bericht musste leer sein (oder seine Ausnahmen dokumentiert sein), bevor die Datei von „im Design“ zu „bereit für Engineering“ verschoben wurde. Dies ist Plugin-als-Workflow statt Plugin-als-Stichprobenprüfung, und es ist der Unterschied zwischen 80 % Abdeckung und 20 % Abdeckung in der Stichprobe.

Das Audit ergibt eine Checkliste und einen Vertrag. Die Checkliste ist das, was ein Designer abhaken können sollte, bevor die Datei mit dem Engineering geteilt wird. Der Vertrag ist die Form der Design-Tokens, die neben der Datei mitgeliefert werden, damit der Entwickler Figma-Variablen CSS-Custom-Properties zuordnet, ohne Zwischenwerte zu erfinden. Beides ist absichtlich kurz: jeder Punkt auf der Checkliste ist eine Eigenschaft, die das Audit gemessen hat, und jeder Token im Vertrag ist ein Wert, der eine Lücke im Korpus geschlossen hat.

Das 50-Dateien-Audit schließt mit einem einfachen Befund. Die Übergabe scheitert bei Barrierefreiheit nicht, weil Designer sich nicht kümmern und nicht, weil Entwickler sich nicht kümmern, sondern weil die Datei — die Figma-Datei, das einzelne Artefakt, das jede Partei liest — die Barrierefreiheitsentscheidungen nicht als erstklassige Eigenschaften trägt. Fokus-Zustände, Alternativtext, Lesereihenfolge, Bewegungspräferenzen, Dunkelmodus-Kontrast: jedes davon ist eine Design-Entscheidung, jedes gehört in die Datei, jedes liegt derzeit woanders. In einem Haftzettel, in einer Slack-Nachricht, in einer separaten Tabelle, im Kopf des Entwicklers um 16 Uhr an einem Freitag.

Die Lösung ist kein heroischer Designer oder heroischer Entwickler. Es ist eine Workflow-Änderung auf Teamebene: jede interaktive Komponente liefert eine Fokus-Variante, jedes Bild trägt Alternativtext an einem plugin-verwalteten Ort, die Lesereihenfolge wird bei jeder nicht-trivialen Seite überlagert, Animationen geben ihre Reduzierte-Bewegung-Entsprechung an, der Dunkelmodus-Kontrast wird separat vom Hellmodus geprüft, und die Datei wird neben einem Token-Vertrag geliefert, der jede Variable benennt, an die die Implementierung gebunden ist. Keiner dieser Schritte ist neu, keiner erfordert ein Werkzeug, das noch nicht vorhanden ist, und jedes Team, das sie als Release-Gate-Schritte übernimmt, wird die meisten der gemessenen Lücken in einem einzigen Release-Zyklus schließen.

Der tiefere Befund ist, dass Design-System-Teams dies bereits mit etwa doppelter Rate im Vergleich zu Produktteams tun. Der Auftrieb, den die Design-System-Teams liefern, ist genau der Auftrieb, den die Disziplin des Aufbauens eines Systems auferlegt: Komponenten werden benannt, Eigenschaften werden aufgezählt, Varianten sind sichtbar, Tokens sind explizit. Dieselbe Disziplin auf Produktebenen-Dateien anzuwenden — selbst ohne ein vollständiges Design-System darunter — schließt den Großteil der Übergabelücke. Es ist kein Werkzeugproblem mehr. Es ist eine Workflow-Entscheidung.