Crate a11y_dom 

Dokumentmodell-Abstraktion für Accessibility-Regeln.

Regeln werden einmal geschrieben und laufen über drei sehr verschiedene Substrate: statisches HTML aus einem Build, ein per CDP ferngesteuerter Chrome, und der DOM einer laufenden Seite. Dieses Crate definiert, was diese drei gemeinsam haben — und, wichtiger, wie sie sich unterscheiden.

Der Baum ist DOM-förmig

Node bildet Tags, Attribute, Text und Hierarchie ab, nicht Rollen und Accessible Names. Das ist bewusst: Die Mehrzahl der Regeln braucht Attribute (tabindex, id, role, alt, for), und der native Accessibility-Tree des Browsers gibt die gar nicht her — tabindex etwa taucht dort nicht auf. Rolle und Name kommen als eigene Fähigkeit obendrauf.

Fähigkeiten statt Optionen

Die drei Substrate unterscheiden sich nicht in der Darstellung derselben Daten, sondern darin, welche Daten überhaupt existieren. Ein flaches Trait mit Option-Rückgaben würde dazu führen, dass Regeln je nach Host stillschweigend nicht laufen. Stattdessen gibt es Semantics, Rendering und Interaction als eigene Traits, die ein Host implementiert oder eben nicht — und eine Regel, deren Tier nicht erfüllt ist, meldet UNTESTED statt zu schweigen.

use a11y_dom::{elements, subtree_text, Arena, Document, Node};

let doc = Arena::builder()
    .open("html").attr("lang", "de")
        .open("body")
            .open("h1").text("Bericht").close()
            .open("img").attr("src", "logo.png").close()
        .close()
    .close()
    .build();

let img = elements(&doc).find(|n| n.local_name() == "img").unwrap();
assert!(img.attr("alt").is_none());

let h1 = elements(&doc).find(|n| n.local_name() == "h1").unwrap();
assert_eq!(subtree_text(h1), "Bericht");

Structs

Arena

Ein Dokument als flache Knotenliste.

ArenaBuilder

Baut eine Arena auf. Elemente werden geöffnet und geschlossen, Text wird in das gerade offene Element gelegt.

ArenaNode

Ein Handle auf einen Arena-Knoten. Copy, wie das Trait es verlangt.

Caps

Was ein Host liefern kann. Tier::Structure ist immer dabei — ohne Baum gäbe es nichts zu prüfen.

Color

sRGB mit Alpha, Kanäle 0–255.

ComputedStyle

Die berechneten Stilwerte, die Accessibility-Regeln tatsächlich brauchen. Bewusst keine vollständige CSSOM-Abbildung.

NodeId

Stabile Kennung eines Knotens innerhalb eines Dokuments. Der Host bestimmt, was sie bedeutet — Arena-Index, AXTree-Backend-ID, laufende Nummer beim Parsen. Für die Regeln ist sie nur ein Rückbezug für den Befund.

Rect

Ein Rechteck in CSS-Pixeln, Ursprung links oben im Dokument.

Enums

NameSource

Woher ein Accessible Name stammt. Nur der native Accessibility-Tree kennt das; berechnende Hosts lassen es bei None.

NodeKind

Welche Art von Knoten. Kommentare, Processing Instructions und Doctype kommen nicht vor — für Accessibility-Regeln sind sie ohne Bedeutung, und sie wegzulassen spart bei großen Dokumenten spürbar Arbeit.

Tier

Welche Datenschicht eine Regel braucht.

Traits

Document

Ein Dokument: gibt Zugriff auf die Wurzel.

Interaction

Tier 4 — Fokus, Ereignisse, veränderlicher DOM.

Node

Ein Knoten im Baum des Hosts.

Rendering

Tier 3 — berechnete Stile und Geometrie.

Semantics

Tier 2 — Rolle und Accessible Name.

Functions

ancestors

Alle Vorfahren, vom Elternknoten aufwärts.

closest

Der nächste Vorfahre mit diesem Tagnamen, den Knoten selbst eingeschlossen.

descendants

Alle Nachfahren in Dokumentreihenfolge, ohne den Knoten selbst.

elements

Alle Elemente des Dokuments in Dokumentreihenfolge.

has_text

Ob der Teilbaum sichtbaren Text enthält — billiger als subtree_text, weil beim ersten Treffer abgebrochen wird.

self_and_descendants

Der Knoten selbst und alle Nachfahren, in Dokumentreihenfolge.

subtree_text

Der zusammengesetzte Text des gesamten Teilbaums.