Zusammenfassung

  • Das W3C veröffentlichte am 27. August 2026 einen neuen Working Draft der SVG Accessibility API Mappings. Als vorige Ausgabe nennt das Dokument den 10. Mai 2018; dazwischen liegen 3.031 Tage und der neue Entwurf verzeichnet substanzielle technische Änderungen.
  • In der öffentlichen Überarbeitung der nächsten SVG-Charter verlangte ein Kommentar vom 4. Juli einen konkreten Meilenstein und eine Testzusage. Der übernommene Patch ersetzte „unbestimmt“ durch „mit dem Ziel, bei den Tests voranzukommen“.
  • Die Formulierung benennt eine Priorität, aber weder maßgebliche Revision und Funktionsinventar noch Test-Commit, Abdeckung, unabhängige Implementierungen, Verantwortliche oder Wiedervorlage. Ihr Abschluss lässt sich nicht prüfen.
  • Der Charterentwurf besitzt bereits tragfähige allgemeine Kriterien: offene Tests, frühe Testplanung und zwei unabhängige interoperable Implementierungen, bevor eine Spezifikation über Candidate Recommendation hinausgeht. Es fehlt ihre Bindung an SVG AAM.
  • Der W3C Process verlangt voraussichtliche Meilensteindaten nur, soweit sie verfügbar sind. Ein fehlendes Datum belegt daher weder einen Prozessverstoß noch Aufgabe oder böse Absicht.
  • Ein schlanker, versionierter Nachweis zum Testmeilenstein könnte Veröffentlichung, Testabdeckung, Implementierungserfahrung und Reifeentscheidung trennen, ohne eine neue Genehmigungsinstanz zu schaffen.

Drei öffentliche Zustände, die nicht dasselbe bedeuten

Die Zahl 3.031 lädt zu einer zu einfachen Erzählung ein: Acht Jahre sei nichts geschehen, dann sei die Spezifikation wiedererwacht. Der öffentliche Befund trägt das nicht. Ein datierter /TR-Stand kann alt bleiben, während Redaktionsentwürfe und Repositorien weiterlaufen.

Die aktive SVG-Charter von 2024 begann am 27. Juni 2024 und endet am 30. September 2026. Sie führt SVG Accessibility API Mappings als am 10. Mai 2018 übernommenen Working Draft und bezeichnet die erwartete Fertigstellung als unbestimmt. Damit ist der Charterstand belegt, nicht die Abwesenheit jeder Arbeit seit 2018.

Die nächste Charter wurde öffentlich in W3C Strategy Issue 559 verfeinert. Am 4. Juli verwies ein öffentlicher Kommentar auf den Entwurf von 2018 und den unbestimmten Abschluss, forderte dann einen konkreten Meilenstein und ein Bekenntnis zu Tests. Am 18. August meldete der Teamkontakt den Abschluss der Überarbeitung und die Übernahme von Vorschlägen.

Der unveränderliche Commit 806338 zeigt, was tatsächlich übernommen wurde. Drei Zeilen änderten sich: ein Link wurde korrigiert, die Koordination mit WHATWG erweitert und für SVG AAM „unbestimmt“ durch „aiming at progressing on testing“ ersetzt. Die Charter an diesem Commit verwies weiterhin auf den Entwurf von 2018.

Neun Tage später kam der Working Draft vom 27. August 2026. Er nennt den Working Draft vom 10. Mai 2018 ausdrücklich als letzte veröffentlichte Fassung. Der Abstand beträgt exakt 3.031 Tage.

Die neue Ausgabe ist mehr als ein administrativer Zeitstempel. Sie dokumentiert Änderungen unter anderem an der Berechnung zugänglicher Namen, SVG-Rollen, der Abbildung von Elementen und Attributen sowie an verborgenem und rein präsentierendem Inhalt. Prüfer und Implementierer erhalten einen neuen festen Bezugspunkt.

Doch der Statusabschnitt erklärt ebenso deutlich, dass ein Working Draft keine Billigung durch das W3C oder seine Mitglieder bedeutet und noch verändert, ersetzt oder verworfen werden kann. Die Veröffentlichung beweist die Existenz eines neuen prüfbaren Textes. Sie beweist nicht automatisch, dass seine normativen Funktionen getestet sind, dass unabhängige Produkte interoperieren oder dass eine höhere Reifestufe gerechtfertigt ist.

Eine Absicht kennt kein Abnahmekriterium

Die neue Charterformulierung ist nützlicher als ein nacktes „unbestimmt“. Sie signalisiert, dass Tests Aufmerksamkeit erhalten sollen, und erfindet kein Datum, das bei unsicheren Ressourcen oder Implementiererzusagen kaum belastbar wäre.

Ein Meilenstein beantwortet jedoch eine andere Frage: Welcher beobachtbare Zustand beendet eine Prüfphase? „Bei Tests vorankommen“ nennt weder die maßgebliche Spezifikationsrevision noch die Menge normativer Funktionen. Die Formulierung legt keinen Test-Commit fest, beschreibt keine Abdeckung und sagt nicht, welche Resultate eine Reifeentscheidung tragen könnten.

Der Begriff Test kann außerdem sehr verschiedene Tätigkeiten meinen. Ein Repository anzulegen ist Aufbauarbeit. Einen Regressionstest hinzuzufügen ist ein Beitrag. Einen Testplan zu verabschieden ist ein Gruppenbeschluss. Normative Anforderungen mit Assertions zu verknüpfen erzeugt eine Abdeckungskarte. Die Suite in einer konkreten Umgebung auszuführen schafft Implementierungsevidenz. Vergleichbare Resultate zweier wirklich unabhängiger Systeme können Interoperabilität belegen. Ein Implementierungsbericht bündelt diese Belege für eine Entscheidung.

Alle Schritte sind wertvoll, aber sie sind nicht austauschbar. Eine höhere Testzahl kann denselben bereits abgedeckten Bereich vertiefen. Breite Abdeckung kann auf nur einer Engine beruhen. Zwei Produkte können scheinbar bestehen, ohne dass Versionen, Betriebssystem-Zugänglichkeitsschicht, assistive Technik und Konfiguration eine Reproduktion zulassen.

Die Charterzeile kann deshalb Tätigkeit ankündigen. Sie kann nicht feststellen, wann aus Tätigkeit ein erreichter Meilenstein geworden ist.

Die allgemeinen Erfolgskriterien müssen nicht neu erfunden werden

Der Charterentwurf behandelt Tests keineswegs als Nebensache. Er sieht eine Testsuite und einen Implementierungsbericht als Ergebnisse vor. Die allgemeinen Erfolgskriterien verlangen offene Tests für alle Funktionen, Testplanung ab frühen Entwürfen und mindestens zwei unabhängige interoperable Implementierungen jeder Funktion, bevor eine Spezifikation über Candidate Recommendation hinausgeht.

Diese Passagen sind ein wichtiges Gegenargument gegen die Behauptung, Tests würden ignoriert. Sie passen zur W3C-Process-Darstellung der Implementierungserfahrung. Dort zählt nicht nur eine Erfolgsquote. Gefragt wird, ob Funktionen implementiert sind, ob Systeme interoperieren, ob Implementierer unabhängig sind, ob es mehr als experimentelle Nutzung gibt, welche Ebenen des Ökosystems erfasst sind und welche Probleme gemeldet wurden. Frühe Testplanung gilt häufig als besonders wirksam.

Was fehlt, ist die konkrete Instanz dieser Regeln. „Tests für jede Funktion“ braucht ein versioniertes SVG-AAM-Funktionsinventar als Nenner. „Zwei unabhängige Implementierungen“ braucht Namen, Versionen, Umgebungen und eine Begründung der Unabhängigkeit. Eine öffentliche Suite braucht einen festen Commit, wenn ein früheres Resultat später nachvollziehbar bleiben soll.

Ein weiterer abstrakter Anspruch würde daran nichts ändern. Ein direkter Evidenzverweis in der Zeile des konkreten Ergebnisses schon.

„Soweit verfügbar“ schützt vor Scheingenauigkeit

Die Chartervorgaben des W3C Process verlangen Geltungsbereich, Erfolgskriterien, Dauer, Ergebnisse und erwartete Meilensteindaten, soweit diese verfügbar sind. Die Einschränkung ist bindend. Aus dem fehlenden Datum für SVG AAM lässt sich mit dem eingefrorenen Befund kein Prozessbruch ableiten.

Das ist vernünftig. Tests können Fehler im Normtext zeigen, Prioritäten von Implementierern können sich ändern, Mitwirkende können fehlen. Ein Kalenderdatum, das nur Vollständigkeit darstellen soll, fördert womöglich einen verkürzten Umfang oder eine voreilige Erfolgsmeldung.

Ein unbekanntes Enddatum verhindert aber keinen bekannten Zwischenstand. Die Gruppe kann festhalten, welche Fassung kontrolliert, wie das Funktionsinventar versioniert ist, welche Suite und welcher Commit genutzt wurden, welche Ergebnisse vorliegen und welche fehlen. Ist selbst ein Prüftermin nicht planbar, kann der Nachweis den Grund und das auslösende Ereignis nennen: eine neue Veröffentlichung, ein Implementierergebnis oder die Klärung strittiger Normsprache.

Die angemessene Reparatur ist deshalb keine erzwungene Frist. Sie ist eine präzise Beschreibung dessen, was trotz offener Zeitachse geprüft werden kann.

Zwischen Dokument und funktionierendem System liegen mehrere Tore

Lu Hengs Text über den Vorrang funktionierenden Codes bietet hier eine Governance-Linse, keine Tatsachenquelle über SVG oder ARIA: Veröffentlichung, Empfehlung, Implementierung, Validierung und Nutzung sollen getrennte Zustände bleiben.

Diese Trennung verhindert zwei Übertreibungen. Es wäre falsch, den Entwurf von 2026 kleinzureden, weil er noch keinen Interoperabilitätsnachweis darstellt. Ein fester Text organisiert Prüfung und Implementierung. Ebenso falsch wäre es, die neue Veröffentlichung als Ersatz für Produktbelege zu verwenden. Ein Dokument führt seine Regeln nicht selbst aus.

Auch innerhalb der Testkette sind die Tore verschieden. Ein vorhandener Test belegt eine codierte Assertion. Eine Zuordnung zu einer normativen Funktion zeigt beabsichtigte Abdeckung. Ein Lauf dokumentiert Verhalten in einer bestimmten Umgebung. Unabhängige, vergleichbare Läufe können Interoperabilität stützen. Ein Implementierungsbericht ordnet alles einer Reifeentscheidung zu.

Bei SVG AAM kann die beobachtete Kette Browser-Engine, Zugänglichkeitsschicht des Betriebssystems und assistive Technik umfassen. Versionen und Konfigurationen können das Ergebnis prägen. Dieser Text schreibt weder eine Pflichtmatrix vor noch behauptet er, welche Kombinationen heute bestehen. Er verlangt nur, dass eine öffentliche Schlussfolgerung die Umgebungen benennt, auf denen sie beruht.

SVG und ARIA teilen sichtbare Verantwortung

Der öffentliche Aktenstand erscheint an mehreren organisatorischen Orten. Die Veröffentlichungsseite der ARIA Working Group führt den Entwurf vom 27. August und nennt ARIA als ausliefernde Gruppe. Die vorgeschlagene SVG-Charter sieht die Entwicklung in Zusammenarbeit mit ARIA vor. 2024 verschob ein Commit im früheren Repository die Spezifikationsarbeit in das ARIA-Monorepo, ließ das alte Repository für Issues offen und bewahrte die Adresse des Editor’s Draft. Das heutige SVG-AAM-Verzeichnis im ARIA-Repository macht den redaktionellen Ort sichtbar.

Das belegt weder Streit noch eine unzulässige Kompetenzverlagerung. Zusammenarbeit und Repositorywechsel sind normal. Sie machen lediglich ein Feld im Meilensteinnachweis unverzichtbar: Für jede nächste Handlung muss eine Gruppe oder eine benannte Person zuständig sein. Charteraufsicht, Redaktion, Testprüfung und Ergebnislieferung dürfen verteilt bleiben; sie dürfen nicht unauffindbar werden.

Zehn Felder genügen

Die Lösung muss kein neues Gremium und keine große Plattform sein. Eine versionierte Seite oder ein Issue, direkt aus der Ergebniszeile verlinkt, reicht aus.

Sie sollte die maßgebliche Spezifikations-URL und unveränderliche Revision nennen, das normative Funktionsinventar mit Version, das Repository und den kontrollierenden Commit der Testsuite sowie die Zuordnung von Funktionen zu Tests. Die Zustände sollten vollständig, teilweise, ungetestet, ausgenommen und blockiert unterscheiden.

Hinzu kommen Identität und Version der Implementierungen samt Umgebung, reproduzierbare Interoperabilitätsresultate, bekannte Fehler, Ausnahmen und offene Punkte. Jede Folgehandlung erhält eine verantwortliche Gruppe oder Person. Der Nachweis nennt einen Wiedervorlagetermin oder erklärt ausdrücklich dessen Nichtverfügbarkeit und das auslösende Ereignis. Zuletzt bezeichnet er die Reife- oder Veröffentlichungsentscheidung, die das Evidenzpaket unterstützen kann.

Neue Fassungen sollten alte nicht löschen. Ein Fehler kann behoben, eine Funktion entfernt, eine Implementierung zurückgezogen werden. Nur die Abfolge erklärt, worauf eine Entscheidung zu ihrem Zeitpunkt beruhte.

Der Working Draft vom 27. August verdient Anerkennung als substanzielle Rückkehr in das Veröffentlichungsregister. Er braucht keine geliehene Behauptung über künftige Interoperabilität. Der Testmeilenstein braucht umgekehrt kein künstliches Datum. Er braucht einen überprüfbaren Stand, der offen sagt, was belegt ist, was fehlt und welche Entscheidung als Nächstes ansteht.

Quellen

  1. SVG-AAM-Verzeichnis im ARIA-Repository
  2. Vorgeschlagene SVG-Charter bei Commit 806338
  3. Commit 806338 zur Übernahme von Vorschlägen
  4. W3C Strategy Issue 559
  5. Kommentar mit der Forderung nach einem Testmeilenstein
  6. Kommentar zum Abschluss der Überarbeitung
  7. Commit zum Umzug der SVG-AAM-Arbeit ins ARIA-Monorepo
  8. Lu Heng, Running-Code Primacy
  9. Aktive SVG-Charter von 2024
  10. Veröffentlichungen der ARIA Working Group
  11. W3C Process: Gruppencharter
  12. W3C Process: Implementierungserfahrung
  13. SVG Accessibility API Mappings Working Draft vom 10. Mai 2018
  14. SVG Accessibility API Mappings Working Draft vom 27. August 2026