デバイスポスチャAPI

デバイスポスチャとは、デバイスが保持する物理的な姿勢であり、角度に加えてセンサーなどから得られる情報に基づく場合もあります。近年、ポスチャを変化できる機能を持つ新しいタイプのモバイルデバイスが登場しています。最も一般的なのは、画面自体や画面周囲を折り畳めるデバイスであり、物理的な形状を変更できます。デバイスのポスチャを知る主な目的は、レスポンシブデザインによる新しいユーザー体験を可能にすることです。

「折り畳み」デバイスには主に2つの物理的なフォームファクターがあります。1つは1枚の柔軟な画面（シームレス）を持つもの、もう1つは2枚の画面（シームあり）を持つものです。どちらもヒンジ周辺で折り畳みでき、現行仕様は両方のタイプに適用されます。また、シームレス・シームありの両方とも、モバイルやタブレットからラップトップサイズまで様々な寸法があります。さらに、デバイスによってデフォルトの向き（縦向き・横向き）が異なり、折り畳みも縦方向・横方向のいずれかの場合があります。

ウェブサイトの使い勝手を折り目部分を避けて向上させたり、Webで新しいユースケースを実現したりするために、デバイスポスチャを知ることで開発者は各種デバイスに合わせたコンテンツを調整できます。

デバイスが完全に平らでない状態でも、コンテンツは利用・閲覧できます。この場合、開発者はデバイスポスチャの状態に応じて異なるレイアウトを提供したいと考えるかもしれません。

以下の内部スロットが Document インターフェイスに追加される。

[HTML] 仕様は Navigator インターフェイスを定義しており、 本仕様はこれを拡張する:

WebIDL[SecureContext, Exposed=(Window)]
partial interface Navigator {
  [SameObject] readonly attribute DevicePosture devicePosture;
};

WebIDL[SecureContext, Exposed=(Window)]
interface DevicePosture : EventTarget {
  readonly attribute DevicePostureType type;
  attribute EventHandler onchange;
};

enum DevicePostureType {
  "continuous",
  "folded"      
};

この仕様では以下のポスチャ値を定義します：

1. 

   Continuous ポスチャ：Continuousポスチャは 「平らな」状態を指します。これは、異なるポスチャを持たないほとんどのデバイスのデフォルトの状態です。

   折り目やヒンジ、類似の機能を持たないデバイスも含まれます。

   ハードウェア革新の性質上、デュアル、折りたたみ可能、巻き取り可能、または湾曲した画面を持つデバイスも含まれる。ただし、 Document が平面的なレイアウトで 表示されることが期待される姿勢にある場合に限る。

   例：

   • 折り畳みデバイスが平らに完全展開された姿勢
   • 折り畳みデバイスで、ブラウザがヒンジをまたがないウィンドウ/セクションで動作している
   • 2-in-1デバイスがタブレットモードで片面のみ使用している場合
   • 折り畳めないデバイス
   注

   デバイスによっては、物理的には平らでない姿勢で複数アプリが動作していても、ブラウザが複数画面・セクションにまたがっていなければ、そのポスチャはcontinuousとなります。

2. Folded ポスチャ：Foldedポスチャは物理的に折り畳み可能なデバイスを指します。これらのデバイスは柔軟な1枚画面または2枚隣接画面を持つことができます。この姿勢ではディスプレイ/セクション間に「平ら」状態を超えない角度が形成されます。

   例：

   • 折り畳みデバイスが垂直ヒンジで内部画面を「本」姿勢で使用し、内容が両セクションにまたがり、約30°〜170°の角度を形成する場合
   • 折り畳みデバイスが水平ヒンジで「ラップトップ」姿勢で使用されている場合
   注

   折り畳みデバイスが半分折りたたまれた状態（本のような状態）で使われる場合、実装者はテキスト方向や書字モードがレイアウトや表示に与える影響を考慮する必要があります。

   例えば、右から左へ書く言語（アラビア語、ヘブライ語、シリア語など）や、多くの縦書きモード（東アジア言語など）では、英語の本とは逆の順序でページが進み、ページ番号の小さい方が右側になります。

   詳細は 中国語、 日本語、韓国語 の書字モードの違いを参照してください。

API上、ポスチャ値は DevicePostureType 列挙値で表されます。

Document の各インスタンスは内部スロット [[CurrentPosture]] を持ち、これは Document が作成されるときに初期化されるべきであり、そうでない場合、それらは最初に アクセスされるとき、かつその値が読み取られる前に初期化されなければならない（MUST）。ユーザー エージェント は、それを初期化するために、document を Document に設定し、disallowRecursion を true に設定して、デバイス姿勢 変更手順を実行しなければならない（MUST）。

与えられた Document について、現在の姿勢は、 現在のヒンジ角および 画面の向き、 ならびに潜在的にはその他の実装固有のシグナルから導出される。

以下の表は規範的ではありません。

本仕様に関して新たなセキュリティ考慮事項は報告されていません。ただし、文書内で示されている 10. プライバシーに関する考慮事項 を確認することが推奨されます。

1. 折り目・ヒンジ部分にコンテンツ（特にボタン）を配置しないよう設計・実装すること。この部分は曲面のため指での操作が困難または不可能な場合があります。
2. 折り畳み時に、動画や画像など大きな連続コンテンツを折り目・ヒンジ部分にまたがって配置しないよう設計・実装すること。この部分はコンテンツや色が少し歪みます。
3. 画面スペースをより有効活用するため、分割UI（画面セグメントごとにコンテンツを分割表示するUI）を採用し、より強力で差別化されたインターフェースを提供すること。

• UI 要素の配置: ダイアログの典型的な配置ロジックは、 水平方向および垂直方向の中央に配置することであるが、 対称的な折り目で折りたたまれたデバイスでは、それらが折り目領域の中央に配置され、 たとえばボタンをクリックするなどの操作が難しくなる場合がある。 また、歪みや光の反射により、テキストを読みづらくする可能性もある。
• 全画面モード: 全画面で要素のサイズを変更する場合、 典型的なロジックでは、その要素を Window の幅 および高さまで拡張する。 デバイスが折りたたまれている場合、その 要素は折り目をまたいでレイアウトされ、劣ったユーザー 体験につながる。別の方法として、その要素を折り目領域の 上または下のいずれかに表示することができる。
• ユーザー体験の向上: この API により、 デバイスが折りたたまれている場合に、異なる適応されたユーザー体験を 作成することが可能になり、よりよいユーザー体験と改善された アクセシビリティを実現できる。たとえば、動画を視聴中にデバイスが 折りたたまれている場合、動画を折り目の上に表示し、 コメント欄を既定で折り目の下に表示できる。別の 例として、ビデオ会議アプリケーションが動画 フィードを折り目の上に、チャットを折り目の下に表示することがある。
• コンテンツは 1 つの posture だけを前提に設計すべきではない: 折りたたみ可能デバイスの考え方は、 その 汎用性と、ユーザーが望むように姿勢を変更できる能力にある。 向きと同様に、 ユーザーには別のニーズがある可能性があるため、常にユーザーのために 選択するのではなく、ユーザーが自分のニーズにより適した UI を 選択できるようにすることが重要である。 理想的には、UI を構成可能にすることが望ましい。
• 支援機器向けのコンテンツ通知: ARIA live regions を使用して、 重要なレイアウト変更を動的に通知する。 たとえば、折り目によってウェブページのレイアウトが変化した場合、 スクリーンリーダーがこれらの変更をユーザーに通知するようにする。 たとえば、動画プレーヤーが画面上部に移動し、コメントが 下部に移動した場合、「動画プレーヤーは上側の画面に移動し、 コメントは折り目の下に移動しました」のような通知は、ユーザーがよりよく移動する助けになる。
• 支援技術との互換性: さまざまな支援技術で 徹底的なテストを実施し、異なる姿勢に達したときの互換性 および変更の適切な伝達を確保する。

Device Posture API は、インターフェイスを完全に実行するには 物理的なハードウェアデバイスが必要となるため、テスト作成者に課題をもたらす。 この課題に対処するため、この文書は [WEBDRIVER2] の 拡張コマンドを定義し、ユーザーが 報告されるデバイス姿勢を制御し、 実際のデバイスをシミュレートできるようにする。

以下の 拡張コマンドおよびそれらの 8. アルゴリズムとの統合をサポートするため、トップレベル traversables は、次の 内部スロットを持たなければならない:

非規範的と記載されたセクションのほか、著者ガイドライン・図・例・注記はすべて非規範的です。それ以外は規範的です。

この文書におけるキーワード MUST および SHOULD は、 ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] に記述されているとおりに解釈される。

本仕様は、含まれているインターフェースを実装する ユーザーエージェントという単一の製品に対する適合基準を定義します。