觸控式鍵盤

2012 年 2 月 2 日

這份白皮書提供適用於 Windows 作業系統觸控式鍵盤之啟動和駁回行為的詳細資訊。它為開發人員提供了解觸控式鍵盤如何顯示和隱藏自己的指導方針。

這個資訊適用於下列作業系統:

  • Windows 8
  • Windows Server 2012

免責聲明:這份文件是「依現況」提供。本文件中所表達的資訊與觀點 (包含 URL 及其他網際網路網站參考資料) 如有變更,恕不另行通知。在使用它時請多留意。

這份文件不會給您任何 Microsoft 產品的所有智慧財產法律權利。貴用戶可以複製本文件,但僅限內部參考之用途。

©2012 Microsoft。著作權所有,並保留一切權利。

如需了解此功能的運作情形,請參閱應用程式功能,從開始到完成系列:  使用者互動:觸控輸入...等等

概觀

Windows 8 觸控式鍵盤是一個系統元件,它可以讓觸控式裝置的使用者輸入文字。觸控式鍵盤會在使用者希望輸入文字時出現,不希望用它時就不會出現。啟動和駁回模型的設計目標是確保能在系統內持續得到滿足的這種期望,不論使用者是在何時使用哪一種應用程式,結果都要一致。對 UI 協助工具屬性作出反應的觸控式鍵盤,被當作是一種有豐富定義的方法,對成為焦點的 UI 元素,能決定它是否要接受文字輸入。除了鼓勵設計良好協助工具的做法之外,這個方法還允許觸控式鍵盤定義一組特別的啟動和駁回規則,該組規則根源於使用者與之互動的 UI 元素。

觸控式鍵盤的啟動和駁回行為是在沈浸式環境中,由三種輸入內容所趨動:

  • UI 自動化 (UIA) 的協助工具屬性
  • 使用者點選
  • 焦點變更

UI 自動化是開發人員對特定 UI 元素能否接受文字輸入的溝通機制。您必須確定應用程式已設定了適當的協助工具屬性,如此,觸控式鍵盤才會知道要在特定 UI 元素聚焦時出現。對 Windows 提供的控制項而言,這個動作會自動執行,因為預設就會設定適合的協助工具屬性,但是對於自訂控制項和經驗,您必須另外正確地設定協助工具屬性;注意:觸控式鍵盤會對這些屬性互動。當使用者碰觸聚焦的輸入欄位時,鍵盤就會出現。如果個別應用程式是以程式的方式來設定焦點,這種動作就不會叫用觸控式鍵盤。這是因為使用者絕對不應該被突然顯示鍵盤嚇到。鍵盤在回應程式控制的焦點移動時,會自動隱藏,然而,如果使用者完成了文字項目流程,而且應用程式已將焦點移到其他地方時,鍵盤就會消失。

啟動和駁回邏輯

觸控式鍵盤使用 UIA,將它當作是已存在和妥善定義的方法,用這個方法來決定聚焦的 UI 元素是否為想要做文字項目的目標,如果鍵盤先前是處於隱藏狀態,應該也會造成鍵盤顯示。UIA 也是決定聚焦 UI 元素該不該與觸控式鍵盤互動的方法,如果它顯示出來時,就駁回鍵盤。UIA 是直接透過 .NET 的 XAML 進行公開,它並且可以透過 WWAHost.exe 的無障礙豐富網際網路應用程式 (ARIA) 來存取。一般控制項是由已設定、具備適當 UIA 屬性的 Windows 提供給開發人員,但是對於擁有自訂控制項的開發人員而言,則需要直接設定協助工具屬性。在任何特定的時間,觸控式鍵盤可以處於兩種狀態之一:顯示或隱藏。此外,對任何既定焦點的改變,Windows 都能夠變更鍵盤的可見度狀態,或不做改變。

透過查看有沒有 UIA TextPattern (或 TextChildPattern) 控制項模式以及能否編輯的方式,觸控式鍵盤能決定聚焦的 UI 元素的目標是否為文字項目。如果聚焦元素無法滿足任何的狀況,則不會顯示觸控式鍵盤,並且如果已顯示鍵盤,則會將它隱藏。

還有一組控制項可以在文字項目流程中接受焦點,但它卻不可做編輯 (下拉式方塊是例外,它是編輯欄位和清單的組合,而焦點則是在這兩者之間移動)。觸控式鍵盤會持續顯示在控制項上,不會無意義地變換 UI 讓使用者在流程中感到混淆,因為使用者可能會使用觸控式鍵盤,在控制項和文字項目之間做來回切換。因此,如果已經顯示鍵盤,而且焦點是放在下列清單中其中一種類型的控制項上,就不會隱藏鍵盤。但是如果沒有顯示鍵盤,除非在可編輯的區域內點選,否則不會顯示鍵盤。 例如,請您想像有一位使用者正在某個應用程式中使用它的應用程式列來撰寫一封電子郵件訊息,該應用程式列是用來主控文字編輯控制項,例如粗體字或斜體字。使用者想要讓下一個字變成粗體,於是點選 [粗體] 按鈕。因為功能表列位在觸控式鍵盤保存之控制項的清單中,所以即使使用者點選到輸入欄位之外的區域,也不會隱藏鍵盤。 這種行為可以讓使用者直接返回並輸入文字。

這些是討論中的控制項:

  • 核取方塊
  • 下拉式方塊
  • 選項按鈕
  • 捲軸
  • 樹狀目錄
  • 樹狀目錄項目
  • 功能表
  • 功能表列
  • 功能表項目
  • 工具列
  • 清單
  • 清單項目

設定正確的協助工具屬性

提醒:只有使用自訂控制項的使用者才需要參考本章節。一般由 Windows 提供的控制項都不需要任何額外的工作即可和觸控式鍵盤正常搭配使用。

如果您是一位使用自訂控制項的應用程式開發人員,請確認控制項擁有正確的存取資訊以取得觸控式鍵盤行為。 當您完成這個動作之後,鍵盤就會依據期望的使用者模型來顯示和隱藏。

HTML5 中,這僅僅是設定控制項上正確 ARIA 屬性的動作:role="textbox"。這個控制項當然也必須可以編輯,所以建議您設定 contentEditable="true"。例如,下面的範例建立了一個內容可被編輯的 div,當使用者點選時,它會叫用觸控式鍵盤。

<div contentEditable="true" role="textbox">

如果您使用 C# 或 C++,請使用 AutomationPeer 物件,特別是 TextAutomationPeer。舉一個 Windows 8 的範例便能示範如何在 C# 中完成這個目的。

還記得除了合適的協助工具設定值之外,控制項也必須能夠編輯和接受文字,才能叫用鍵盤。它指示出能接受文字是應該的結果,如果無法這樣做時,將會誤導協助工具和依賴那些工具的使用者。

使用者驅動的叫用

觸控式鍵盤叫用模型的設計目標是要讓使用者能掌控鍵盤。使用者用點選輸入控制項的方式來指出他們想要輸入的系統,而不是要應用程式代替他們作決定。如此可以將意外叫用鍵盤的案例數目降低到零發生,這些意外可能成為 UI 變換的痛苦來源,因為鍵盤功能會佔用 50% 的螢幕,以及明顯影響應用程式的使用者經驗。若要啟用使用者驅動的叫用,我們追蹤最後碰觸事件的座標,並且將它們和目前聚焦之元素週框方塊的位置進行比較。如果該點落在週框方塊內,就叫用觸控式鍵盤。

也就是說,應用程式無法透過操作焦點、程式設計的方式來叫用觸控式鍵盤。過去這裡發生的大問題是網頁—許多網頁會根據預設將焦點放在輸入欄位上,但同時在他們的網頁上,卻還有許多其他瀏覽內容可以提供使用者享用和體驗。msn.com 有一個很好的範例。該網站有許多值得吸收的內容,但它的網頁上方剛好有 Bing 搜尋列,根據預設,成為焦點所在的位置。如果鍵盤是自動叫用時,根據預設,所有在該搜尋列下方的文章都會被阻擋,因而破壞了面板上的網站使用經驗。在某些案例中,這種必須點選以取得鍵盤的方式並不會覺得很好用,例如在使用者已經開始編輯一個新的電子郵件訊息或已經開啟 [搜尋] 窗格時。不過,我們仍覺得要求使用者以點選輸入欄位的方式是一個可以接受的折衷方案。

 

 

顯示:
© 2014 Microsoft