バッジ API

W3C 作業草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2025/WD-badging-20251006/
最新公開バージョン:
https://www.w3.org/TR/badging/
最新編集者草案:
https://w3c.github.io/badging/
履歴:
https://www.w3.org/standards/history/badging/
コミット履歴
編集者:
Jay Harris (Brave Software, Inc.)
Marcos Cáceres (Apple Inc.)
Diego González (Microsoft)
以前の編集者:
Matt Giuca (Google Inc.) - まで
フィードバック:
GitHub w3c/badging (プルリクエスト, 新しい課題, オープン課題)

概要

この仕様は、インストール済みウェブアプリケーション がアプリケーションバッジを設定できるAPIを定義します。アプリケーションバッジは通常、デバイスのホーム画面やアプリケーションドックでアプリのアイコンの隣に表示されます。

この文書のステータス

このセクションは、本書が公開された時点でのステータスを示します。現在の W3C の出版物一覧や、この技術レポートの最新改訂版は W3C 標準と草案のインデックスでご覧いただけます。

本仕様は作業途中です。

この文書は、Web Applications Working Group によって 勧告トラックを利用して作業草案として公開されました。

作業草案として公開されたことは、W3C およびその会員による支持を意味するものではありません。

この文書はドラフトであり、今後随時更新、差し替え、または廃止される可能性があります。進行中の作業以外として引用することは不適切です。

この文書は、 W3C 特許ポリシーのもとで運営されるグループによって作成されました。 W3C本グループによる特許開示の公開リスト を管理しており、そのページには特許を開示するための指示も含まれています。ある個人が、必要クレームを含むと認識する特許について事実を知っている場合は、W3C 特許ポリシー第6節に従い情報を開示しなければなりません。

この文書は 2025年8月18日 W3C プロセス文書に従って管理されています。

1. バッジの適切な使用

このセクションは規範的ではありません。

バッジは一部のユーザーに通知疲れを引き起こす可能性があります。そのため、 著者は本当にユーザーの注意やアクションを必要とする状態のみにバッジを使用し、 マーケティングやエンゲージメント目的の安易な利用は避けてください。

気を散らす要因や認知負荷を高めるような、頻繁に変化する値の表示は避けてください。

バッジを認知できない、あるいはシステムレベルでバッジを無効にしているユーザーをサポートするために、 著者は同じ状態をアプリケーションUI上にアクセシブルなパターン(例:明確にラベル付けされたアプリ内ステータス表示)で提示するよう推奨されます。

2. 利用例

このセクションは規範的ではありません。

1: アプリのアイコンに未読数を表示する
async function updateMailBadge() {
  // APIがサポートされているか確認します。
  if (!navigator.setAppBadge) return;

  const unreadCount = await getUnreadMailCount();

  // アプリバッジの設定を試みます。
  try {
    await navigator.setAppBadge(unreadCount);
  } catch (e) {
    // バッジがサポートされていない場合や、ユーザーがバッジ設定を拒否した場合
  }
}

バッジはオペレーティングシステム上のアプリケーションのアイコンに表示される場合があります。同じアプリケーション内で複数回APIを使ってバッジを設定 またはクリアした場合、最新のものが有効となり、アプリケーションが閉じられた後でも表示が継続することがあります。

2: アプリのアイコンに準備状態を表示する
async function showPlayerTurn(playerTurnId) {
  if (playerTurnId === localPlayerId)
    await navigator.setAppBadge();
  else
    await navigator.clearAppBadge();
}

一部のオペレーティングシステムでは、バッジを設定するにはユーザーの許可が必要な場合があります。この場合、開発者は "notifications" 権限の状態を確認してからバッジを設定する必要があります。許可が与えられていない場合、開発者は Notification.requestPermission() を使って許可を求める必要があります。

3: 権限の確認
async function checkPermission() {
  permission = await navigator.permissions.query({
    name: "notifications",
  });
  const button = document.getElementById("permission-button");
  if (permission.state === "prompt") {
    // ユーザーに許可を求めるダイアログを表示します。
    button.hidden = false;
    button.addEventListener("click", async () => {
      await Notification.requestPermission();
      checkPermission();
    }, { once: true });
    return;
  }
  button.hidden = true;
}

3. モデル

badgeは、インストール済みのWebアプリケーションが、ユーザーに注意を促す必要のある新しいアクティビティがあることを通知したり、未読数などの少量の情報を示すためのメカニズムとして意図されています。

badgeは、次のvaluesのいずれかを持つことができます。

特別な値 "nothing":
現在バッジが設定されていないことを示します。badgeがこの値を持つ場合、ユーザーに視覚的なインジケーターは表示されません。
特別な値 "flag":
バッジが設定されており、ユーザーに表示されるべきであることを示しますが、特定の数値は含まれません。これは"nothing"とは異なり、バッジの存在を示す視覚的インジケーターがユーザーに表示されます。
number値:
バッジが数値に設定されており、その値が0より大きいことを示します。

インストール済みのウェブアプリケーションには、関連付けられたbadgeがあり、初期値は"nothing"です。オペレーティングシステムがバッジ値を保存・管理し、ユーザーエージェントがOSへのバッジ変更通知の仲介役を担います。

ユーザーエージェントは任意で(再)アプリケーションのバッジを "nothing"に設定してもよい(例えば、システムの慣例に従う場合など)。

4. バッジの表示

アプリケーションのバッジが設定されている場合、ユーザーエージェントまたはオペレーティングシステムは推奨 アプリケーションのバッジを、ユーザーのオペレーティングシステム上のアプリケーションの主なアイコン表示と並べて表示するべきです(例: デバイスのホーム画面でアプリケーションのアイコン上に小さなオーバーレイとして表示するなど)。

ユーザーエージェントは任意でユーザーから明示的な許可を得て バッジを設定することができます。ユーザーエージェントがそのような 許可を必要とする場合は、 推奨として "通知"の許可と関連付けるべきです。

バッジ"flag"に設定されている場合、ユーザーエージェントまたはオペレーティングシステムは推奨として 非特定のシンボル(例: 色付きの円)でインジケーターを表示するべきです。プラットフォームが"flag"バッジの表示に対応していない場合、ユーザーエージェント推奨として バッジの存在を示す最も近い表現(例: 値 "1" など)で表示し、バッジを完全にクリアしないことが望ましいです。

バッジの値が"nothing"に設定された場合、 ユーザーエージェントまたはオペレーティングシステムは 推奨としてクリアし、バッジの表示をやめるべきです。

バッジ数値に設定された場合、numberユーザーエージェントまたはオペレーティングシステムは以下を行うべきです:

4.1 プラットフォームの制限に関する実装上の考慮事項

オペレーティングシステムごとにバッジ表示の能力は異なります。最終的な表示動作はOSによって制御され、ユーザー設定やシステム慣習によってさらに変更される場合があります。OSにバッジ情報を通知する際、ユーザーエージェント推奨としてバッジ要求の意味的な意図を保持するべきです:

5. NavigatorWorkerNavigator インターフェースの拡張

WebIDL[SecureContext]
interface mixin NavigatorBadge {
  Promise<undefined> setAppBadge(
    optional [EnforceRange] unsigned long long contents
  );
  Promise<undefined> clearAppBadge();
};

Navigator includes NavigatorBadge;
WorkerNavigator includes NavigatorBadge;

アプリケーションバッジを表示しないユーザーエージェントは含めるべきではありません include NavigatorBadge

5.1 setAppBadge() メソッド

setAppBadge() メソッドが 呼び出されたとき、ユーザーエージェントは必須アプリケーションバッジを設定する必要があります。 thiscontents 引数の値に。

5.2 clearAppBadge() メソッド

clearAppBadge() メソッド が呼び出されたとき、ユーザーエージェントは必須アプリケーションバッジを設定する必要があります。 this の値を 0 に。

6. アプリケーションバッジの設定

プラットフォームオブジェクト context のアプリケーションバッジを、オプションの unsigned long long contents の値に設定するには、次の手順を実行します。

  1. globalcontext関連グローバルオブジェクトとする。
  2. globalWindow オブジェクトの場合:
    1. documentglobal関連付けられた Documentとする。
    2. document完全にアクティブでない場合、拒否された promise を "InvalidStateError" DOMException で返す。
    3. document関連設定オブジェクトオリジン が、this関連設定オブジェクトトップレベルオリジン同一オリジンドメインでない場合、拒否された promise を "SecurityError" DOMException で返す。
  3. promise新しい promiseとする。
  4. 並列で:
    1. ユーザーエージェント明示的な許可を アプリケーションバッジの設定に必要とする場合:
      1. permissionState を "notifications" で 現在の権限状態を取得した結果とする。
      2. permissionState が "granted" でない場合、 グローバルタスクをキューし、 ユーザー操作タスクソース globalpromiseを拒否し、 NotAllowedError でこのアルゴリズムを終了する。
    2. contents に応じて分岐する:
      contents が渡されなかった場合:
      バッジ"flag" に設定する。
      contents が 0 の場合:
      バッジ"nothing" に設定する。
      contents の場合:
      バッジcontents に設定する。
    3. グローバルタスクをキューし、 DOM操作タスクソースglobalpromiseを解決undefined を返す。
  5. promise を返す。

7. プライバシーに関する考慮事項

このAPIは設計上書き込み専用です。サイトが以前に設定したバッジの値を読み戻す方法はなく、アプリケーションバッジがストレージやフィンガープリント手段として利用されるのを防ぎます。

8. セキュリティに関する考慮事項

ユーザーエージェントやオペレーティングシステムは任意で バッジクリアすることができ、 システムの慣例(例:システムリセット時)に従って行うことがあります。

ユーザーエージェントは、バッジの設定クリアをレート制限することができる(MAY)。これは、注意をそらすアニメーションを防ぎ、リソース使用量を低減するためです。しかし、ユーザーエージェントは一般的にレート制限をオペレーティングシステムに任せるべき(SHOULD)です。オペレーティングシステムの方が、システム負荷、ユーザー設定、アクセシビリティの観点から適切な制限を判断できるためです。

9. アクセシビリティに関する考慮事項

アプリケーションバッジは、ユーザーの注意を要するステータスを伝えます。 バッジはしばしばウェブコンテンツ領域外(たとえば、ドック内のアプリアイコン上など)で表示されるため、 ユーザーエージェントは、情報がプラットフォームのアクセシビリティ機能やユーザーの設定を通じて アクセス可能かつ制御可能な状態を保つ必要があります。

9.1 スクリーンリーダーとの互換性

ユーザーエージェントは現在のvalue"flag"number の区別を含む)をプラットフォームのアクセシビリティAPI経由で公開し、 支援技術が必要に応じて(たとえば、ユーザーがアプリアイコンにフォーカスした際など)提示できるようにすべきです(SHOULD)

ユーザーエージェントはバッジの変更を自動的に通知すべきではありません(SHOULD NOT)。 その代わり、予期しない中断を避けるためにプラットフォームの慣習に従うべきです(SHOULD)

9.2 視覚的アクセシビリティ

このセクションは規範的ではありません。

バッジは通常、基盤となるプラットフォームによって描画されるため、 視覚的な工夫も基本的にそこで対処されます。それでもなお、ユーザーエージェントやプラットフォームは次の点を考慮する必要があります:

9.3 プラットフォーム統合とユーザー設定

ユーザーエージェントはプラットフォームのアクセシビリティ設定やテーマと統合すべきです(SHOULD)

ユーザーエージェントはOSレベルのアプリごとのバッジ設定(たとえば、OSがアプリのバッジを無効化している場合など)を反映すべきです(SHOULD)

10. 適合性

非規範と明記されているセクションだけでなく、この仕様書のすべての著作ガイドライン、図、例、および注記も非規範です。それ以外の内容はすべて規範的です。

この文書中のキーワード MAYMUSTMUST NOTSHOULDSHOULD NOT は、すべて大文字で記載されている場合に限り BCP 14 [RFC2119] および [RFC8174] の定義に従って解釈されます。

A. 参考文献

A.1 規定参照

[appmanifest]
Web Application Manifest。Marcos Caceres; Kenneth Christiansen; Diego Gonzalez-Zuniga; Daniel Murphy; Christian Liebel。W3C。 2025年9月3日。W3Cワーキングドラフト。URL: https://www.w3.org/TR/appmanifest/
[html]
HTML Standard. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. リビングスタンダード. URL: https://html.spec.whatwg.org/multipage/
[infra]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. リビングスタンダード. URL: https://infra.spec.whatwg.org/
[notifications]
Notifications API Standard. Anne van Kesteren. WHATWG. リビングスタンダード. URL: https://notifications.spec.whatwg.org/
[permissions]
Permissions。Marcos Caceres、Mike Taylor。W3C。2025年9月26日。W3C作業草案。URL: https://www.w3.org/TR/permissions/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. 1997年3月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. 2017年5月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[WEBIDL]
Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. リビングスタンダード. URL: https://webidl.spec.whatwg.org/