Integration von Barrierefreiheit in ein arbeitsflächenbasiertes Produkt

Ähnlich wie bei einem Videospiel übernimmt die Figma-Arbeitsfläche das Rendern vom Browser, um die Leistung zu maximieren. Dies ermöglicht es uns, leistungsstarke Funktionen wie unendliches Zoomen und Multiplayer in Echtzeit bereitzustellen. Da wir jedoch auf herkömmliches HTML und DOM verzichten, um die Figma-Arbeitsfläche darzustellen, erhalten wir keine der standardmäßig in den Browser integrierten Barrierefreiheitsfunktionen.

Damit Figma für mehr Menschen nutzbar ist, haben wir eine Mirror-DOM-Struktur entwickelt, die mit jedem Figma-Design synchronisiert werden kann. Hier werfen wir einen Blick hinter die Kulissen und zeigen, wie wir es geschafft haben, dass alle mit einem Screenreader durch eine Figma-Datei navigieren, Änderungen sofort hören kann, sobald sie angesagt werden, und den Editor über die Tastatur bedienen können.

Mehr erfahren über die Verbesserungen bei der Barrierefreiheit von Figma in Bezug auf Tastatur und Screenreader.

Das DOM synthetisieren

Browser-Engines kennen ein Konzept namens „Barrierefreiheitsbaum“: eine aus dem Dokument abgeleitete Datenstruktur, die die nicht-visuellen Informationen enthält, die für die Funktion von assistiven Technologien erforderlich sind. Wenn ein*e Screenreader-Benutzer*in den Befehl „Gehe zum nächsten Formularfeld“ ausführt, teilt der Barrierefreiheitsbaum dem Screenreader mit, wohin er gehen soll. Der Browser baut diesen Baum aus DOM, semantischem HTML, ARIA-Attributen und einigen zusätzlichen berechneten Zuständen auf.

In einer typischen Web-App hat jede Komponente ihr eigenes DOM-Element, wie <button>, <p> oder <img>. Da Figma für die Darstellung aber kein HTML verwendet, gibt es auf der Arbeitsfläche nur ein <input> Element, das den Fokus behält – egal, wie viele Ebenen das Design enthält. Das bedeutete, dass der Barrierefreiheitsbaum des Browsers für eine Figma-Datei praktisch leer war.

Um dieses Problem zu lösen, haben wir synthetische DOM-Elemente für die Arbeitsfläche hinzugefügt, damit Bildschirmleser Dateien navigieren und bearbeiten können.

So funktioniert das System

Hinter der Arbeitsfläche, für sehende Benutzer*innen unsichtbar, rendern wir DOM-Elemente, die die Teile des Szenenbaums spiegeln, die für unterstützende Technologien wichtig sind. Es gibt vier kooperierende Systeme:

• Ein Figma-interner „Barrierefreiheitsbaum“, der die Barrierefreiheitsdetails jeder Designebene zwischenspeichert und bei Änderungen gezielte Aktualisierungen vornimmt, anstatt alles von Grund auf neu zu erstellen.
• Eine React-Komponente vom Typ „Spiegel-DOM“, die dafür zuständig ist, Elemente tatsächlich in das DOM einzufügen, wobei sie den internen Barrierefreiheitsbaum als Referenz nutzt.
• Ein bidirektionales Synchronisationssystem für die Auswahl. Wenn du einen Knoten auf der Arbeitsfläche auswählst, erhält das entsprechende DOM-Element den Fokus. Umgekehrt aktualisieren wir die Auswahl auf der Leinwand, wenn Screenreader-Tools zur Navigation im Spiegel-DOM verwendet werden.
• Ein Benachrichtigungssystem, das die Benutzer*innen auf Bearbeitungen und andere nicht navigationsbezogene Änderungen hinweist – wie das Verschieben von Elementen, den Wechsel von Tools und alles andere, was für sehende Benutzer*innen offensichtlich sein könnte.

Der interne Barrierefreiheitsbaum

Zur Festlegung, welche DOM-Elemente wie dargestellt werden sollen, sind wir rückwärts vorgegangen und haben uns daran orientiert, was der Browser wissen muss, um seinen Barrierefreiheitsbaum aufzubauen. Also haben wir unseren eigenen internen Barrierefreiheitsbaum erstellt, der die nicht-visuellen Informationen erfasst, die Screenreader für ein beliebiges Figma-Dokument benötigen würden.

Für jede Ebene im Dokument erstellen wir eine „zugängliche Zusammenfassung“, die von Screenreadern vorgelesen wird. Diese Zusammenfassung kann vom Kontext und der Art der Anwendung abhängen, in der sich die Benutzer*innen befinden. In Prototypen können wir beispielsweise die meisten Bearbeitungsfunktionen weglassen und lediglich den Inhalt für die Endbetrachter*innen emulieren: nur den Text von Textfeldern oder eine Schaltflächenrolle für ein Element mit einer Klickinteraktion. Andererseits müssen automatische Layout-Frames, die im Zugänglichkeitsbaum für Prototypen ausgeschlossen werden, einbezogen werden, wenn Benutzer*innen ein Dokument bearbeiten.

Nachdem wir die Ebenen einzeln zusammengefasst haben, durchlaufen wir den Baum von oben nach unten und glätten alle ausgelassenen Knoten. Während wir beim ersten Laden eines Dokuments unseren internen Barrierefreiheitsbaum vollständig aufbauen, überwachen wir im weiteren Verlauf der Sitzung alle Änderungen, damit wir unseren Baum punktgenau aktualisieren können und so aufwendige Überarbeitungen vermeiden.

Das Spiegel-DOM

Mit unserem fertigen Barrierefreiheitsbaum können wir das DOM generieren. Dies wird von einer React-Komponente gehandhabt, die sich rekursiv rendert, wobei jede Instanz dieser Komponente Änderungen im Barrierefreiheitsbaum für eine spezifische Entwurfsebene abonniert.

function ScreenReaderElement({ layerId }: { layerId: string }) {
  const { label, role, children } = useAccessibleSummary(layerId);
  return <div role={role} ariaLabel={label}>
    {children.map((c) => <ScreenReaderElement key={c} layerId={c}>)}
  </div>
}

Da wir minimale, inkrementelle Änderungen am Barrierefreiheitsbaum vornehmen, um Bearbeitungen nachzuverfolgen, verlassen wir uns auf React, um unsere DOM-Änderungen ebenfalls minimal zu halten.

Ein Detail des Spiegel-DOM, das überraschend sein könnte, ist, dass wir nicht typische visuell versteckte Stile für diesen zugänglichen, aber visuell versteckten Inhalt verwenden. Während solche Techniken es Assistenztechnologien ermöglichen, Inhalte zu interpretieren, ohne das Layout der Seite zu beeinflussen, benötigen wir tatsächlich, dass Mirror DOM-Elemente angeordnet werden. Der Grund ist, dass das räumliche Layout eines Figma-Dokuments kritisch für seine Bedeutung ist, und selbst ohne visuelle Anzeige wird die Position dieser Elemente in Assistenztechnologien einbezogen – Bildschirmvergrößerungen könnten verschieben, um das fokussierte Element im Blick zu behalten; Screenreader rendern einen hochkontrastierten Umriss für sehbehinderte Benutzer; Sprachsteuerungswerkzeuge könnten auch Hinweise auf dem Bildschirm anzeigen.

Diese Positionsberechnung umfasst einige Schritte. Jede Ebene in einem Figma-Design hat eine affine Transformation: eine Datenstruktur fester Größe, die Versatz, Skalierung und Rotation verfolgt. Affinene Transformationen sind ein leistungsfähiges Tool für Computergrafiken, da jede Sequenz von Transformationen in eine einzige Transformation zusammengeführt werden kann. Wir verwenden diese Fähigkeiten, um Elemente im Spiegel-DOM mithilfe von CSS zu positionieren, einschließlich aller Drehungen oder Schrägstellungen.

Fokus und Auswahl im Einklang halten

Mit den obigen Funktionen können wir die Navigation von Prototypen und anderen „veröffentlichten“ Inhalten mit einem Bildschirmleser unterstützen. Der nächste Schritt war die Unterstützung bei der Navigation von „bearbeitenden“ Anwendungen in Figma. Dazu mussten wir eine weitere Sache hinzufügen, die Browser normalerweise für uns erledigen: Auswahl- und Fokus-Semantiken, in die assistierende Technologien eingreifen können.

Beim Navigieren auf der Figma-Arbeitsfläche ändert die Tab-Taste den ausgewählten Knoten, ohne den systemweiten Tastaturfokus zu ändern. Dies bedeutete, dass die Arbeitsfläche für Screenreader wie ein großes Navigationsziel aussah. Wir mussten sicherstellen, dass der Fokus auf den ausgewählten Knoten innerhalb der Arbeitsfläche verschoben wird, so wie es die Benutzer*innen erwarten.

Daher haben wir eine bidirektionale Synchronisation zwischen der Canvas-Auswahl und der Systemtastaturfokussierung in unser Spiegel-DOM-System integriert. Wenn du auf die Arbeitsfläche klickst, wird das richtige Element für den Screenreader fokussiert, und wenn eine Aktion des Screenreaders den Fokus verschiebt, aktualisieren wir die sichtbaren Markierungen der Auswahl. Dank dieses Systems können sogar Screenreader-Steuerelemente wie der VoiceOver-Rotor Knoten auf der Figma-Arbeitsfläche auswählen.

Aktionen und Änderungen ankündigen

Die internen Barrierefreiheitsbaum- und Spiegel-DOM-Systeme legen die Inhalte von Figma-Dateien für Assistenztechnologien offen. Diese Tools allein sind jedoch für das Bearbeiten nicht ausreichend, wo die Anwendung die Aktionen von Benutzer*innen an diese zurückbestätigen muss. Gesten wie das Antippen, deren Ergebnisse für sehende Benutzer*innen offensichtlich sind, müssen auch einen textuellen Kontext bieten, der akustisch angesagt werden kann. Es gibt wirklich nur eine Möglichkeit, dies zu tun: Wir verlassen uns auf Live-Bereiche, die von Webbrowsern im Rahmen des ARIA-Standards bereitgestellt werden.

Unsere Implementierung fügt jeder Toast-Meldung im Produkt Markups für „Live-Regionen“ hinzu und unterstützt unsichtbare Meldungen für Ereignisse, die von sehenden Benutzer*innen wahrscheinlich als überflüssiges Rauschen wahrgenommen würden – z. B. würden die meisten Benutzer*innen es wahrscheinlich nicht hilfreich finden, bei jeder Bewegung mit den Pfeiltasten ein Toast-Popup zu sehen, aber diese Benachrichtigungen sind wichtig für die Barrierefreiheit. Wir kümmern uns auch um das automatische „Zusammenführen“: Wenn mehrere Ereignisse derselben Kategorie kurz nacheinander auftreten, können wir sie zusammenfassen. Nehmen wir wieder die kleinen Verschiebungen mit den Pfeiltasten als Beispiel: Wenn du fünfmal hintereinander um jeweils ein Pixel verschiebst, können wir eine einzige Meldung senden, die bestätigt: „Fünf Pixel verschoben“, anstatt fünfmal „Ein Pixel verschoben“ zu wiederholen.

Was ist vorhanden, und was kommt als nächstes

Unsere Bemühungen, Figma barrierefreier zu gestalten, haben sich über mehrere Jahre hinweg weiterentwickelt und wurden durch das Feedback von Benutzer*innen assistiver Technologien im Rahmen unserer Partnerschaft mit Fable geprägt. Es begann 2022 mit dem Prototypen-Viewer, dann folgte 2023 FigJam, und schließlich haben wir im Laufe der Jahre 2024 und 2025 erhebliche Fortschritte erzielt: Wir haben die Einstellung „Inhalte für Screenreader anpassen“ für „Design“, den „Dev Mode“ und „Folien“ eingeführt, die erste Version der Arbeitsflächen-Tastatursteuerelemente veröffentlicht, den erweiterten Kontrastmodus hinzugefügt und mehr als 15 weitere Verbesserungen im Bereich Barrierefreiheit vorgenommen.

Wir integrieren Barrierefreiheit in die Art und Weise, wie wir neue Produkte entwerfen, bauen und bereitstellen. Jede neue Funktion wird auf Barrierefreiheit überprüft, und unser Team investiert auch in interne Tools, wie einen KI-Agenten, der mit Figma-spezifischem Kontext und Anleitung vom Designsystem-Team ausgestattet ist, um den zugänglichen Kontext in der gesamten Figma-Produktentwicklungsorganisation zu skalieren.

Wir möchten es den Menschen auch erleichtern, barrierefreie Produkte in Figma zu erstellen. Heute kannst du im Farbwähler feststellen, ob eine Farbkombination den Barrierefreiheitsrichtlinien entspricht, und sichtbare Ebenen umbenennen, damit diese Namen an Bildschirmleseprogramme weitergegeben werden. Außerdem haben wir kürzlich Designs prüfen eingeführt, eine neue Funktion in Figma Design, mit der Designer*innen ihre Entwürfe anhand ihres Designsystems vergleichen können, um Abweichungen aufzudecken und diese mit einem Klick zu beheben – darunter das Markieren von geringem Kontrast und das Vorschlagen von WCAG 2.0 AA- oder AAA-konformen Farben, bevor die Entwürfe an die Entwickler*innen weitergegeben werden.

Barrierefreiheitsarbeit ist nie wirklich abgeschlossen. Jede Verbesserung hilft dabei, eine weitere Barriere zu beseitigen, damit mehr Menschen am kreativen Prozess teilnehmen, ihre Ideen teilen und die Produkte gestalten können, die wir alle nutzen. Wir werden weiterhin zuhören, lernen und auf eine Zukunft ohne Barrieren hinarbeiten.