`<output>` タグ

 (denodell.com)
4 ポイント 投稿者 GN⁺ 2025-10-12 | 1件のコメント | WhatsAppで共有
  • <output> タグはWeb開発者にはあまり知られていないが、動的な結果表示とスクリーンリーダーのアクセシビリティを標準で提供する
  • HTML仕様にかなり前から存在しており、role="status" に自動でマッピングされ、視覚障害者向け支援技術に変更内容を通知する
  • <output> は 入力値に応じて計算された結果 を伝えるときに使い、多くのチュートリアルやライブラリで見過ごされている
  • for="" 属性のサポート など優れたアクセシビリティを備え、JavaScriptフレームワークとの互換性も高い
  • さまざまな実プロジェクトで 電卓、スライダー値のフォーマット、フォーム検証フィードバック などに便利に活用できる

HTMLに隠された宝石: <output> タグ

すべての開発者は <input> 要素をよく知っており、これはWebの中核となる入力手段である

しかし <output> 要素は、ほとんどの人が使ったことがなく、存在すら知らない場合も多い

これは惜しいことで、その理由は、これまで <div> とARIAでその場しのぎに実装してきた 動的な結果表現とアクセシビリティ を <output> が標準で解決してくれるからである

このタグはHTML仕様にかなり前から存在していたが、いまだに広く知られていない

HTML5仕様での定義

HTML5仕様によれば

<output> 要素は、アプリケーションで計算された結果、またはユーザーの操作の結果を表す

アクセシビリティツリー上では role="status" にマッピングされるため、値が変更されるたびにスクリーンリーダーが内容全体を自動的にユーザーへ案内する
これは、基本的に aria-live="polite" aria-atomic="true" が適用されているのと同じである

この挙動はユーザーの流れを妨げず、内容全体を穏やかに読み上げる特徴を持つ
必要に応じて開発者がARIA属性を別途指定して動作を変更することもできる

<output> の使い方

シンプルに次のように使える

<output>ここに動的な値を表示</output>

これだけでも 組み込みの支援技術サポート を受けられ、追加の属性や覚えにくいAPIは不要で、純粋なHTMLだけでアクセシビリティを実現できる

発見の瞬間

筆者はアクセシビリティのプロジェクトで 多段階フォームのスコア表示 を扱う中で <output> の価値を発見した

フォームのスコア変化は画面上では見えていたが、スクリーンリーダー利用者には変化が分からない状況だった
ARIA live regionで解決はできたものの、より明確な意味を持つHTMLを使うほうが望ましいと考えた

仕様を調べるうちに、フォームとは別に使えて自動的に結果を案内してくれる <output> を見つけ、最もシンプルな解決策がすでに仕様に含まれていたことに気づいた

あまり使われていない理由

忘れられたタグであり、大半のチュートリアルやコンポーネントライブラリでは扱われず、GitHubの公開リポジトリでも使用例はほとんどない

そのため知識の欠落が繰り返され、あまり使われないという悪循環が続いている

知っておくとよい点

  • <output> にも <label> と同様に for="" 属性 がある
    • 結果がどの入力値に依存するのか、対応する id を空白区切りで明示できる
  • 見た目には変化がないが、アクセシビリティツリー上では意味的に入力と結果が結び付けられる
  • <form> 要素がなくても、ユーザー入力に応じて動的に変化するテキストならどこでも活用できる
  • 既定ではインライン要素なので、レイアウト目的に応じて <span> や <div> のようにスタイリングが必要
  • 2008年から仕様に含まれており、ブラウザおよびスクリーンリーダーのサポート は非常に優れている
  • React、Vue など すべてのJSフレームワークとの互換性 も高い
  • 2025年10月時点では一部のスクリーンリーダーが更新を読み上げない場合があり、その場合は role="status" 属性の追加が推奨される

重要:
<output> は、ユーザー入力と明確に結び付いた 計算結果またはアクション結果 に適しており、
全体通知（例: トーストメッセージ）には使わず、システムフィードバックには role="status" や role="alert" を使うべきである

実際の使用例

電卓アプリケーション

シンプルな電卓を作るとき、結果表示を <output> にすると、追加のARIAロールなしで 結果値が自動で案内される という利点がある

スライダー値のフォーマット（Volvo Carsの事例）

スライダーで内部値（例: 10000）を調整し、<output> に見やすい形式（10,000 miles/year）で表示する
コンテナに role="group" と共有ラベルを付与することで、アクセシビリティやReactコンポーネントの合成に活用できる

フォーム検証フィードバック

パスワード強度などのリアルタイム検証メッセージも <output> によって 支援技術の利用者へ即座に案内 できる

サーバー計算結果の表示

送料、税金、サーバーAPIから得た推奨値など、サーバーで計算された値 にも <output> は適している

以下のReact例のように、サーバーから金額を受け取り、<output> に即座に表示できる

ネイティブ要素を使う満足感

仕様で意図された通りに 純粋なHTML要素を正しく使う ことで、
アクセシビリティを高め、コードを簡素化し、
あまり知られていない <output> タグの価値と活用法をあらためて発見できる

HTMLには今なお隠れた宝石のような要素が多くあることを示している

最新アップデート: Bob Rudis がこの記事に対応する 動作デモページ を公開した

関連記事

1件のコメント

 
GN⁺ 2025-10-12
Hacker Newsのコメント

  • <output> 要素の問題は、機能が中途半端にしか実装されておらず、実際にはほとんど役に立たないと感じることです。
    input のように type 属性があれば、ずっと実用的になると思います。
    自分の Sciter で output|type を試してみて、次のようにいくつかの型を追加しました。

    • type="text": デフォルト値、フォーマットなし
    • type="number": ユーザーのロケールに合わせた数値フォーマット
    • type="currency": ユーザーのロケールに合わせた通貨フォーマット
    • type="date": 日付として表示、タイムゾーン変換なし
    • type="date-local": ローカルの日付フォーマット、UTC datetime をローカルに変換
    • type="time": 時刻として表示
    • type="time-local": ローカル時刻、値は UTC datetime として扱う
      こういう方式なら、サーバーがユーザーのロケールを知らなくてもデータを渡せます。

    • 記事や仕様にある通り、<output> はアプリで計算結果やユーザー操作の結果を表示するためのものです。
      ARIA セマンティクスが重要な部分で、ページが更新されるとスクリーンリーダーで結果が読み上げられます。
      <output> の中には、望む型表現を自分で直接入れられます。
      "text" がデフォルトで、日付や時刻には <time> タグが使えます。
      現在は数値フォーマット専用のタグはありませんが、Intl 導入後は要望が増えています。
      たとえば:
      <output>The new date is <time datetime="2025-10-11">Oct 11</time></output>
      つまり、<output> がすべての型を扱う必要はなく、HTML 全体で型を表現すべきです。

    • 中途半端な機能のせいでほとんど役に立たない、という意見には同感です。
      2025年の今でもこういうケースが多すぎるのは残念です。
      かなりの部分で Safari に責任があると思います。
      最も極端な例は <input type="date"> です。
      本番でそのまま使ってよいはずなのに、ブラウザ間の問題のせいで結局 JS の date picker の方を使うことが多く、妙な感じがします。

    • 個人的には、<output> が <input> に直接結びついて結果を表示してくれるといいと思います。
      たとえば: <input type="range" id="example_id" name="example_nm" min="0" max="50"> <output name="example_result" for="example_id"></output> こんなふうに input の値をそのまま表示してくれるとよいです。
      "type" 指定子も追加されて、::before や ::after の CSS で content: によって内容が変わることもできればいいと思います。
      さまざまな <input> 型に対してこうしたフォーマット機能があれば実用的だと思います。
      特に type="tel" のように、入力値を見やすく整形して表示できると便利です。
      'checkbox, color, date, datetime-local, file, month, number, radio, range, tel, time, url, week' などにも全部使えます。
      テキスト系でも条件次第では役立つかもしれません。
      それに for="" 属性がもっと多様な役割を持ってくれるとよいです。
      今はほとんどの例が <output name="result"><form oninput="result.value=..."> のように変形して使っています。

    • <output> を input と対称的に型を持たせようと考えるのは、誤ったアプローチです。
      output は入力値のように型を持つものではなく、ページ上で内容が変わるコンテナという考え方です。

    • 私は次の形の方が好きです。 <output for=input>

      <!-- カスタム time-locale コンポーネントを入れる -->

      <time is=time-locale datetime=2001-02-03>2001-02-03</time> </output> このコンポーネントがロケールに応じて値を変えてくれるとよいです。
      HTML/CSS で見せかけの内容を作ると、いろいろな問題を起こしやすいです。
      たとえば CSS ::before/:after で注入したものをコピーするときや、.innerText と実際の inner text の差異などが生じます。
      こうした点について判断は必要ですが、1つのタグに機能を詰め込みすぎると、結局そのタグ専用の DSL のようになってしまいます。
      値の種類（絶対/相対）、付随データ（通貨の種類など）、HTML 処理の一部になってしまい、JS で柔軟に変更できなくなります。

  • <output>？ 私も使ったことがありません。
    今日初めて知ったので、TIL（今日学んだこと）のリストに追加しました。
    GitHub の公開リポジトリで検索してもほとんど出てこない理由は、誰も教えなければ誰も使わないからでしょう。
    ここでふと思ったのは、LLM がコード生成するときにこのタグを実際に活用しているのか、それともそもそも学習されていないのかという疑問です。

    • 私も AI がドキュメント（spec）を読まない点は心配です。
      もし新しい W3C 仕様が登場しても、みんなが「vibe coding」ばかりしていたらどうなるのか。
      AI が最新仕様を反映せず、昔のコードパターンばかり繰り返すなら、仕様更新の普及は今よりむしろ難しくなるでしょう。

    • 私は Claude がコードを生成してくれたことで、<output> タグを初めて知りました。

    • LLM は標準文書を直接読んでいるのではなく、既存プロジェクトから得た膨大なデータの統計的パターンに基づいてコードを生成しています。
      実際のコードでこのタグがほとんど使われていなければ、LLM のコード出力にもほとんど現れなくなります。

  • 2025年10月7日更新: 一部のスクリーンリーダーはまだ <output> タグの更新を認識できないため、当面は role 属性を明示した方がよいかもしれません: <output role="status">
    17年も前からある古いタグのサポートが改善されるまで、ただ待つしかない状況なのか疑問です。

    • Windows 環境では、NVDA リポジトリに issue を上げるとかなりしっかり対応してくれる方です。
      https://github.com/nvaccess/nvda

    • 17年の標準であるにもかかわらず、スクリーンリーダーがタグを無視する問題を改善するには努力が必要です。
      これは明らかにスクリーンリーダー側の問題だと思います。

  • フロントエンドのウェブアクセシビリティ講座をいくつも受けましたが、<output> タグを一度も見たことがありませんでした。
    良い情報を共有してくれてありがとうございます。

  • <output> にも <label> のように for="" 属性がありますが、実際にスクリーンリーダー利用者にとって意味があるのか気になります。
    現在のウェブではほとんど使われていないので、スクリーンリーダー利用者も慣れていないかもしれませんが、結局はソフトウェアの UX 次第だと思います。

    • 私は実際にスクリーンリーダーを使っているわけではありませんが、テスト用としてよく扱ってきました。
      これが支援技術にきちんと露出されるかは疑問です。
      今はPCの前にいないので、すぐにはテストできません。
      個人的には、むしろ output の値を明確にラベル付けした方がずっとよいと思います。
      たとえば: <label for="output">Total</label> <output id="output">£123.45</output> こうすればスクリーンリーダーでは「Total、£123.45」と読まれ、文脈が把握しやすくなります。

  • セマンティック HTML は初心者向けの罠にすぎないと思います。
    深く考えず、aria-live のような実際に動作する解決策を使うべきです。
    こういう要素で遊ぶことはできますが、開発者としての責任は、ユーザーに実際に動く構造を提供することだと思います。
    広く使われていないセマンティックタグより、ブラウザと既存エコシステムが期待しているものを使う方が正しいです。

    • HTML はブラウザのためだけのものではありません。
      epub の作業をたくさんしてきた立場から言うと、セマンティックなページ構成の方が全体としてずっと簡単で良いものになります。

  • <output> がウェブページのアクセシビリティ、特にスクリーンリーダー対応のためのタグだと知りました。
    ARIA は Accessible Rich Internet Applications の略で、障害のある人のアクセシビリティを高める HTML 属性群です。

    • React の下で JavaScript が何かを説明するようなものですね。
      アクセシビリティの基本を知らなくても恥ずかしいことではありませんが、だからといって読者が知らないことを不思議がるような反応をする必要もないと思います。

    • MDN に関連ドキュメントがよくまとまっています。
      （記事の著者も同じ指針を強調しています）
      「ARIA を使う際の第一のルールは、必要なセマンティクスや振る舞いを満たすネイティブ HTML 要素または属性がすでに存在するなら、ARIA の role や state、property を追加して再利用しようとせず、そのネイティブなものをそのまま使うことです」
      https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

    • 説明ありがとうございます。
      実は自分でもググれたのですが、ぼんやりした土曜の午後にあなたのコメントを読む方が楽でした。
      改めてありがとうございます。

  • この記事のタイトルだけを見たときは、<output> が誤用されている話かと思いましたが、読んでみたらとても驚きました。
    （特に一番上の怪しげな GenAI calculator の画像を見て、もっとひどい失敗談を想像していましたが、結局内容がとても良くて、読み終えてからやっとその画像を思い出したほどです）

    • その怪しげな GenAI calculator の画像は本当に笑えます。
      足し算、掛け算、割り算はできるのに、引き算はできません。

    • その怪しげな GenAI calculator の画像について言うと、AI が登場する前に私たち人間が作っていた、もっと雑な画像のことを忘れがちだと思います。
      AI のおかげで、今では少なくとも恥ずかしくない程度の画像をすぐ作れるようになりました。
      今回の場合は（主観的には）ヴィンテージでレトロな IT 感がよく出ていて意味があると思います。
      すべての AI 活用がプロのアーティストの仕事を代替するわけではないと思います。

  • こういう話題を見るたびにうれしくなります。
    もう1つのコツは、form の名前をバックエンドのデータ構造に合わせて付けることです。そうすれば、JS で値を取り出したりデータを組み直したりする必要が減ります。
    たとえばこんなふうに: <input name=“entity[id]”> <input name=“entity[relation]”> こうしておけば、JS で面倒なデータを別途作らなくても、フォーム送信だけでそのまま欲しいデータになります。