Das `<output>`-Tag

• Das <output>-Tag ist Webentwicklern wenig bekannt, bietet aber die Anzeige dynamischer Ergebnisse und Screenreader-Barrierefreiheit von Haus aus
• Es existiert schon lange in der HTML-Spezifikation und wird automatisch auf role="status" gemappt, sodass Änderungen von assistiven Technologien für sehbehinderte Nutzer angekündigt werden
• <output> wird verwendet, um auf Basis von Eingabewerten berechnete Ergebnisse mitzuteilen, wird aber in den meisten Tutorials und Bibliotheken übersehen
• Es bietet hervorragende Barrierefreiheit, darunter Unterstützung für das for=""-Attribut, und ist auch mit JavaScript-Frameworks sehr gut kompatibel
• In verschiedenen realen Projekten lässt es sich nützlich für Rechner, formatierte Slider-Werte und Feedback bei Formularvalidierung einsetzen

---

Das versteckte Juwel in HTML: das <output>-Tag

Alle Entwickler kennen das <input>-Element gut, es ist eines der zentralen Eingabemittel des Webs.

Aber das <output>-Element haben die meisten nie verwendet, und viele wissen nicht einmal, dass es existiert.

Das ist schade, denn <output> löst die Darstellung dynamischer Ergebnisse und Barrierefreiheit, für die bisher mit <div> und ARIA Behelfslösungen gebaut wurden, direkt ab Werk.

Dieses Tag ist schon lange Teil der HTML-Spezifikation, aber noch immer nicht weithin bekannt.

Definition in der HTML5-Spezifikation

Laut der HTML5-Spezifikation

Das <output>-Element stellt das in einer Anwendung berechnete Ergebnis oder das Resultat einer Benutzeraktion dar

Im Accessibility Tree wird es auf role="status" gemappt, sodass der Screenreader bei jeder Wertänderung automatisch den vollständigen Inhalt an den Nutzer ausgibt.
Das ist so, als wäre standardmäßig aria-live="polite" aria-atomic="true" gesetzt.

Dieses Verhalten unterbricht den Ablauf des Nutzers nicht und zeichnet sich dadurch aus, dass der vollständige Inhalt ruhig vorgelesen wird.
Falls nötig, können Entwickler das Verhalten durch eigene ARIA-Attribute anpassen.

Verwendung von <output>

Einfach so:

<output>여기에 동적 값 표시</output>

Schon so erhält man eingebaute Unterstützung für assistive Technologien; zusätzliche Attribute oder schwer zu merkende APIs sind nicht nötig, und Barrierefreiheit lässt sich allein mit reinem HTML erreichen.

Der Moment der Entdeckung

Der Autor entdeckte den Wert von <output> bei einem Accessibility-Projekt während der Anzeige der Bewertung in einem mehrstufigen Formular.

Die Änderung der Formularbewertung war auf dem Bildschirm sichtbar, aber Nutzer von Screenreadern konnten die Veränderung nicht erkennen.
Das ließ sich zwar mit einer ARIA Live Region lösen, aber semantisch klares HTML zu verwenden erschien sinnvoller.

Beim Blick in die Spezifikation stieß er auf <output>, das sich auch unabhängig vom Formular verwenden lässt und Ergebnisse automatisch ankündigt, und erkannte, dass die einfachste Lösung bereits Teil der Spezifikation war.

Warum es kaum verwendet wird

Es ist ein vergessenes Tag, das in den meisten Tutorials oder Komponentenbibliotheken nicht behandelt wird; auch in öffentlichen Repositories auf Github gibt es fast keine Beispiele dafür.

Dadurch wiederholt sich diese Wissenslücke, und der Kreislauf der geringen Nutzung setzt sich fort.

Wissenswertes

• <output> besitzt wie <label> ein for=""-Attribut
  • Damit kann angegeben werden, von welchen Eingabewerten das Ergebnis abhängt, indem die betreffenden ids durch Leerzeichen getrennt aufgelistet werden
• Visuell ändert sich nichts, aber im Accessibility Tree entsteht semantisch eine Verbindung zwischen Eingabe und Ergebnis
• Es kann auch ohne <form>-Element überall eingesetzt werden, wo sich Text dynamisch aufgrund von Benutzereingaben ändert
• Standardmäßig ist es ein Inline-Element, daher ist je nach Layout eine Gestaltung wie bei <span> oder <div> nötig
• Es ist seit 2008 Teil der Spezifikation, daher ist die Browser- und Screenreader-Unterstützung sehr gut
• Hervorragende Kompatibilität mit allen JS-Frameworks wie React und Vue
• Stand Oktober 2025 lesen einige Screenreader Aktualisierungen teils noch nicht vor; in diesem Fall wird empfohlen, zusätzlich role="status" zu setzen

Wichtig:
<output> eignet sich für berechnete Ergebnisse oder Aktionsresultate, die klar mit einer Benutzereingabe verbunden sind.
Für globale Benachrichtigungen, etwa Toast-Messages, sollte es nicht verwendet werden; System-Feedback sollte stattdessen mit role="status" oder role="alert" behandelt werden.

Praktische Einsatzbeispiele

Rechner-Anwendung

Beim Bau eines einfachen Rechners hat die Ausgabe des Ergebnisses mit <output> den Vorteil, dass der Ergebniswert ohne zusätzliche ARIA-Rollen automatisch angekündigt wird.

Formatierung von Slider-Werten (Beispiel Volvo Cars)

Ein Slider verändert einen internen Wert (z. B. 10000), der in <output> in einer besser lesbaren Form angezeigt wird (10,000 miles/year).
Dem Container werden role="group" und ein gemeinsames Label gegeben, was für Barrierefreiheit und die Komposition von React-Komponenten genutzt wird.

Feedback bei Formularvalidierung

Auch Echtzeit-Validierungsmeldungen wie zur Passwortstärke lassen sich über <output> sofort an Nutzer assistiver Technologien vermitteln.

Anzeige serverseitig berechneter Ergebnisse

Auch für serverseitig berechnete Werte wie Versandkosten, Steuern oder über eine Server-API erhaltene Empfehlungen ist <output> geeignet.

Wie im folgenden React-Beispiel kann ein vom Server empfangener Betrag direkt in <output> angezeigt werden.

Die Freude an der Verwendung nativer Elemente

Indem ein reines HTML-Element wie von der Spezifikation vorgesehen korrekt verwendet wird,
steigt die Barrierefreiheit, der Code wird einfacher,
und Wert und Einsatzmöglichkeiten des wenig bekannten <output>-Tags lassen sich neu entdecken.

Das deutet darauf hin, dass in HTML noch viele weitere verborgene Juwelen stecken.

Aktuelles Update: Bob Rudis hat passend zu diesem Artikel eine Beispielseite zum Ausprobieren veröffentlicht

[GN⁺]

Hacker-News-Kommentare

• Das Problem des <output>-Elements ist, dass seine Funktionalität nur halb umgesetzt ist, sodass es sich in der Praxis fast nutzlos anfühlt.
  Ich denke, mit einem type-Attribut wie bei input wäre es viel praktischer.
  Ich habe in meinem Sciter mit output|type experimentiert und folgende Typen ergänzt:

  • type="text": Standardwert, ohne Formatierung
  • type="number": Zahlenformatierung nach dem Gebietsschema des Nutzers
  • type="currency": Währungsformatierung nach dem Gebietsschema des Nutzers
  • type="date": Anzeige als Datum, ohne Zeitzonenumrechnung
  • type="date-local": lokales Datumsformat, UTC-Datetime wird lokal dargestellt
  • type="time": Anzeige als Uhrzeit
  • type="time-local": lokale Uhrzeit, der Wert wird als UTC-Datetime behandelt
    Auf diese Weise kann der Server Daten liefern, ohne das Gebietsschema des Nutzers zu kennen.

  • Wie im Artikel und in der Spezifikation beschrieben, ist <output> dafür gedacht, in Apps das Ergebnis einer Berechnung oder einer Benutzeraktion anzuzeigen.
    Die ARIA-Semantik ist dabei wichtig, und wenn die Seite aktualisiert wird, liest der Screenreader das Ergebnis vor.
    Innerhalb von <output> kann man die gewünschte Typdarstellung selbst einfügen.
    text ist der Standardtyp, und für Datum oder Uhrzeit kann man das <time>-Tag verwenden.
    Derzeit gibt es noch kein Tag nur für Zahlenformatierung, aber seit der Einführung von Intl gibt es dafür viele Anfragen.
    Zum Beispiel:
    <output>The new date is <time datetime="2025-10-11">Oct 11</time></output>
    Das heißt, <output> muss nicht alle Typen selbst abdecken; HTML als Ganzes sollte Typen ausdrücken.

  • Ich stimme der Aussage zu, dass es wegen seiner halbfertigen Funktionalität fast nutzlos ist.
    Selbst 2025 gibt es davon leider immer noch viel zu viele Fälle.
    Ich denke, zu einem großen Teil ist Safari daran schuld.
    Das extremste Beispiel ist <input type="date">.
    Man sagt zwar, man könne es direkt in Produktion einsetzen, aber wegen browserübergreifender Probleme greift man dann doch öfter zu einem JS-Date-Picker, was sich ziemlich seltsam anfühlt.

  • Mein persönlicher Wunsch wäre, dass <output> direkt an <input> gekoppelt werden kann und das Ergebnis anzeigt.
    Zum Beispiel: <input type="range" id="example_id" name="example_nm" min="0" max="50"> <output name="example_result" for="example_id"></output> Es wäre gut, wenn der Input-Wert so direkt angezeigt würde.
    Schön wäre auch, wenn ein type-Bezeichner hinzukäme und sich Inhalte in CSS mit ::before oder ::after über content: ändern ließen.
    Ich denke, solche Formatierungsfunktionen wären für viele verschiedene <input>-Typen nützlich.
    Besonders praktisch wäre es bei type="tel", wenn sich Eingaben schön formatiert anzeigen ließen.
    Es ließe sich für checkbox, color, date, datetime-local, file, month, number, radio, range, tel, time, url, week und weitere verwenden.
    Auch textbasierte Typen könnten unter bestimmten Bedingungen nützlich sein.
    Und ich fände es gut, wenn das Attribut for="" mehr Rollen übernehmen könnte.
    Derzeit verwenden die meisten Beispiele eher Abwandlungen wie <output name="result"><form oninput="result.value=...">.

  • Es ist der falsche Ansatz, bei <output> spiegelbildlich zu <input> an Typen zu denken.
    Output ist nicht so etwas wie ein typisierter Eingabewert, sondern konzeptionell ein Container auf der Seite, dessen Inhalt sich ändert.

  • Ich bevorzuge eher eine Form wie diese: <output for=input> <!-- eigene time-locale-Komponente eingefügt --> <time is=time-locale datetime=2001-02-03>2001-02-03</time> </output> Es wäre gut, wenn diese Komponente den Wert je nach Gebietsschema anpasst.
    Mit HTML/CSS künstliche Inhalte zu erzeugen, führt leicht zu allerlei Problemen.
    Zum Beispiel beim Kopieren von mit CSS ::before/:after eingefügten Inhalten oder bei Unterschieden zwischen .innerText und dem tatsächlichen inneren Text.
    Über solche Dinge müsste man zwar Entscheidungen treffen, aber wenn man zu viele Funktionen in ein einziges Tag packt, wird es am Ende zu einer DSL nur für dieses Tag.
    Dann werden Wertarten (absolut/relativ), Begleitdaten (etwa die Währung) und Teile der HTML-Verarbeitung darin eingebettet, sodass sich das Ganze nicht mehr flexibel mit JS ändern lässt.

• <output>? Ich habe es auch noch nie benutzt.
  Heute habe ich zum ersten Mal davon erfahren und es meiner TIL-Liste hinzugefügt.
  Selbst bei einer Suche in öffentlichen GitHub-Repositories taucht es kaum auf — wenn es niemand lehrt, benutzt es auch niemand.
  Dabei kam mir spontan der Gedanke, ob LLMs dieses Tag bei der Codegenerierung tatsächlich praktisch einsetzen oder ob es ihnen gar nicht richtig beigebracht wurde.

  • Ich mache mir auch Sorgen, dass KI die Dokumentation (die Spezifikation) nicht liest.
    Was, wenn eine neue W3C-Spezifikation erscheint und die meisten einfach nur „Vibe Coding“ betreiben?
    Wenn KI aktuelle Spezifikationen nicht widerspiegelt und stattdessen nur alte Code-Muster wiederholt, könnte die Verbreitung von Spezifikations-Updates sogar noch schwieriger werden als heute.

  • Ich habe das <output>-Tag zum ersten Mal entdeckt, weil Claude mir Code dafür generiert hat.

  • LLMs lesen Standarddokumente nicht direkt, sondern erzeugen Code auf Basis statistischer Muster in riesigen Datenmengen aus bestehenden Projekten.
    Wenn dieses Tag in realem Code fast nie verwendet wird, taucht es folglich auch in LLM-generiertem Code fast nie auf.

• Update vom 7. Oktober 2025: Einige Screenreader erkennen Aktualisierungen des <output>-Tags noch immer nicht, daher kann es vorerst besser sein, das role-Attribut explizit zu setzen: <output role="status">
  Ich frage mich, ob wir wirklich einfach nur warten müssen, bis die Unterstützung für ein 17 Jahre altes Tag besser wird.

  • Unter Windows werden Issues im NVDA-Repository oft ziemlich gut bearbeitet.
    https://github.com/nvaccess/nvda

  • Trotz 17 Jahren Standard braucht es offenbar noch Arbeit, um das Problem zu beheben, dass Screenreader das Tag ignorieren.
    Meiner Meinung nach ist das ganz klar ein Problem auf Seiten der Screenreader.

• Ich habe mehrere Kurse zu Frontend-Web-Accessibility gemacht, aber das <output>-Tag dabei nie gesehen.
  Danke fürs Teilen dieser guten Information.

• <output> hat wie <label> ebenfalls ein for=""-Attribut, und ich frage mich, ob das für Screenreader-Nutzer in der Praxis überhaupt eine Bedeutung hat.
  Da es im heutigen Web fast nie verwendet wird, sind selbst Screenreader-Nutzer möglicherweise nicht daran gewöhnt, aber letztlich hängt das wohl von der UX der jeweiligen Software ab.

  • Ich nutze selbst keinen Screenreader, habe aber viel zum Testen damit gearbeitet.
    Ich bin nicht sicher, ob das in Hilfstechnologien wirklich korrekt exponiert wird.
    Ich sitze gerade nicht am Rechner und kann es daher nicht sofort testen.
    Persönlich denke ich, dass es viel besser ist, den Output-Wert klar zu beschriften.
    Zum Beispiel: <label for="output">Total</label> <output id="output">£123.45</output> Dann liest der Screenreader so etwas wie „Total, £123.45“ vor, wodurch der Kontext leichter verständlich ist.

• Ich halte semantisches HTML nur für eine Falle für Anfänger.
  Man sollte nicht groß darüber nachdenken, sondern Lösungen wie aria-live verwenden, die tatsächlich funktionieren.
  Solche Elemente können zwar interessant sein, aber als Entwickler hat man die Verantwortung, Nutzern eine Struktur zu bieten, die real funktioniert.
  Statt selten genutzter semantischer Tags sollte man lieber das verwenden, was Browser und das bestehende Ökosystem erwarten.

  • HTML ist nicht nur für Browser da.
    Aus meiner Erfahrung mit viel EPUB-Arbeit wird die gesamte semantische Strukturierung von Seiten deutlich einfacher und besser.

• Ich habe gelernt, dass <output> ein Tag für die Barrierefreiheit von Webseiten ist, besonders für die Unterstützung durch Screenreader.
  „ARIA“ steht für Accessible Rich Internet Applications und bezeichnet eine Sammlung von HTML-Attributen, die die Zugänglichkeit für Menschen mit Behinderungen verbessern.

  • Das wirkt ein bisschen so, als würde man unter React erklären, was JavaScript ist.
    Es ist nicht peinlich, die Grundlagen der Barrierefreiheit nicht zu kennen, aber ich finde auch nicht, dass man seltsam darauf reagieren sollte, wenn Leser etwas nicht wissen.

  • In der MDN ist die zugehörige Dokumentation gut aufbereitet.
    (Auch der Autor des Artikels betont dieselbe Richtlinie.)
    „Die erste Regel bei der Verwendung von ARIA lautet: Wenn es bereits ein natives HTML-Element oder -Attribut gibt, dessen Semantik und Verhalten die gewünschten Anforderungen erfüllen, dann verwende dieses statt ein Element zweckzuentfremden und eine ARIA-Rolle, einen State oder eine Property hinzuzufügen, um es zugänglich zu machen.“
    https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

  • Danke für die Erklärung.
    Eigentlich hätte ich es auch googeln können, aber an einem trüben Samstagnachmittag war es einfach angenehmer, deinen Kommentar zu lesen.
    Nochmals danke.

• Als ich nur den Titel dieses Artikels gesehen habe, dachte ich, <output> sei falsch verwendet worden, aber nach dem Lesen war ich ziemlich überrascht.
  (Vor allem wegen des fragwürdigen GenAI-Rechnerbilds ganz oben hatte ich mit einem deutlich größeren Fehlgriff gerechnet, aber der Inhalt war so gut, dass ich erst nach dem vollständigen Lesen wieder an das Bild dachte.)

  • Dieses fragwürdige GenAI-Rechnerbild ist wirklich urkomisch.
    Es kann addieren, multiplizieren und dividieren, aber nicht subtrahieren.

  • Wenn wir schon über dieses fragwürdige GenAI-Rechnerbild sprechen:
    Es wirkt manchmal so, als würden wir die noch schlampigeren Bilder vergessen, die wir Menschen vor der KI selbst gemacht haben.
    Dank KI kann man inzwischen immerhin sofort Bilder erzeugen, für die man sich nicht schämen muss.
    In diesem Fall finde ich (subjektiv), dass die Vintage-/Retro-IT-Ästhetik gut transportiert wird und das Ganze dadurch seinen Sinn hat.
    Nicht jede Nutzung von KI ersetzt die Arbeit professioneller Künstler.

• Ich freue mich jedes Mal über solche Inhalte.
  Ein weiterer Tipp ist, Formularnamen so zu benennen, dass sie zur Datenstruktur im Backend passen; dann muss man in JS weniger Werte einsammeln oder Daten umstrukturieren.
  Zum Beispiel so: <input name=“entity[id]”> <input name=“entity[relation]”> Dann muss man nicht erst umständlich eigene Daten in JS bauen, sondern kann das Formular einfach absenden und erhält direkt die gewünschte Datenstruktur.