鍵盤互動

  • 發行項

keyboard hero image

了解如何設計和最佳化您的 Windows 應用程式，以便為鍵盤進階使用者和殘障人士以及有其他輔助功能需求的使用者，盡可能提供最佳的體驗。

在不同裝置上，鍵盤輸入是整個 Windows 應用程式互動體驗的重要組成部分。 精心設計的鍵盤體驗可讓使用者有效率地瀏覽應用程式的 UI 並存取其完整功能，而無需將手從鍵盤上移開。

keyboard and gamepad image

鍵盤和遊戲板之間共用常見的互動模式

在本主題中，我們特別關注電腦上鍵盤輸入的 Windows 應用程式設計。 但是，精心設計的鍵盤體驗對於支援 Windows 講述人等輔助工具、使用觸控鍵盤和螢幕鍵盤 (OSK) 等軟體鍵盤以及處理其他輸入裝置類型 (例如遊戲手把) 非常重要或遠端控制。

此處討論的許多準則和建議 (包括焦點視覺效果、存取金鑰和 UI 瀏覽) 也適用於這些其他場景。

注意雖然硬體和軟體鍵盤都用於文字輸入，但本主題的焦點是瀏覽和互動。

內建支援

與滑鼠一樣，鍵盤是電腦上最常用到的周邊裝置，因此也是電腦體驗的基本組成部分。 電腦使用者期望系統和單一應用程式在回應鍵盤輸入時，獲得全面且一致的體驗。

所有 UWP 控制項都內建對豐富鍵盤體驗和使用者互動的支持，而平台本身為建立最適合自訂控制和應用的鍵盤體驗，提供了廣泛的基礎。

keyboard with phone image

UWP 支援任何裝置的鍵盤

基本體驗

Focus based devices

如前所述，遊戲手把和遙控器等輸入裝置以及朗讀程式等輔助工具共享大部分瀏覽和命令的鍵盤輸入體驗。 這種跨輸入類型和工具的共同體驗最大限度地減少了您的額外工作，並有助於實現通用 Windows 平台的「建置一次，隨處執行」的目標。

如有必要，我們將確定您應注意的關鍵差異，並描述您應考慮的任何緩解措施。

以下是本主題中討論的裝置和工具：

裝置/工具 描述
鍵盤 (硬體和軟體) 除了標準硬體鍵盤之外，Windows 應用程式還支援兩種軟體鍵盤：觸控 (或軟體) 鍵盤和螢幕鍵盤。
遊戲手把和遙控器 遊戲手把和遙控器是 10 英尺體驗中的基本輸入裝置。 關於 Windows 對遊戲手把和遙控器支援的具體詳細資訊，請參閱遊戲手把和遙控器互動。
螢幕閱讀器 (朗讀程式) 朗讀程式是 Windows 的內建螢幕閱讀器，提供獨特的互動體驗和功能，但仍依賴基本的鍵盤瀏覽和輸入。 如需朗讀程式的詳細資料，請參閱開始使用朗讀程式。

自訂體驗和有效率的鍵盤功能

如前所述，鍵盤支援對於確保您的應用程式適合具有不同技能、能力和期望的使用者來說是不可或缺的。 我們建議您優先考慮以下事項。

  • 支援鍵盤瀏覽和互動
    • 確保可操作的項目被標識為定位停駐點 (而不可操作項目則不是)，且瀏覽順序符合邏輯且可預測 (請參閱定位停駐點)
    • 將初始焦點設定在最符合邏輯的元素上 (請參閱初始焦點)
    • 為「內部瀏覽」提供方向鍵瀏覽 (請參閱瀏覽)
  • 支援鍵盤快速鍵
    • 提供加速鍵以進行快速操作 (請參閱加速器)
    • 提供存取鍵來瀏覽應用程式的 UI (請參閱存取金鑰)

焦點視覺效果

UWP 支援單焦點視覺設計，適用於所有輸入類型和體驗。 Focus visual

焦點視覺效果：

  • 當 UI 元素從鍵盤和/或遊戲手把/遙控器接收焦點時顯示
  • 呈現為 UI 元素周圍突出顯示的邊框，以指示可以執行操作
  • 幫助使用者在應用程式 UI 中瀏覽而不會迷路
  • 可為您的應用程式進行自訂 (請參閱高可見度焦點視覺效果)

注意UWP 焦點視覺與朗讀程式焦點矩形不同。

定位停駐點

若要透過鍵盤使用控制項 (包括瀏覽元素)，該控制項必須具有焦點。 控制項接收鍵盤焦點的一種方法是透過選項卡瀏覽將其識別為應用程式選項卡順序中的選項卡停止位，使其可透過選項卡瀏覽進行存取。

對於要包含在 Tab 鍵順序中的控制項，IsEnabled 屬性必須設為 true，並且 IsTabStop 屬性必須設為 true。

要從定位順序中明確排除某個控制項，請將 IsTabStop 屬性設定為 false。

預設情況下，定位順序反映了 UI 元素的建立順序。 舉例來說，如果 StackPanel 包含 Button、Checkbox 和 TextBox，定位順序是 Button、Checkbox 和 TextBox。

您可以藉由設定 TabIndex 屬性來覆寫預設定位順序。

定位順序應該是邏輯且可預測的

精心設計的鍵盤瀏覽模型，使用邏輯且可預測的定位順序，使您的應用程式更加直觀，並幫助使用者更有效率地探索、發現和存取功能。

所有互動式控制項都應具有定位停駐點 (除非它們位於群組中)，而非互動式控制項 (例如標籤) 則不應具有定位停駐點。

避免使用會使焦點在應用程式中跳躍的自訂定位順序順序。 例如，表單中的控制項清單應該有從上到下和從左至右移動的定位順序 (視地區設定而定)。

如需自訂定位停駐點的詳細資訊，請參閱鍵盤輔助功能。

嘗試協調定位順序和視覺順序

協調定位順序和視覺順序 (也稱為閱讀順序或顯示順序) 有助於減少使用者瀏覽應用程式 UI 時的混淆。

請嘗試先以定位順序和視覺順序來排名和呈現最重要的命令、控制項和內容。 但是，實際顯示位置可能取決於上層配置容器以及影響配置的子元素某些屬性。 具體來說，使用網格隱喻或表格隱喻的配置，可以具有與定位順序完全不同的視覺順序。

注意視覺順序也相依於地區設定和語言。

初始焦點

初始焦點指定首次啟動或啟動應用程式或頁面時接收焦點的 UI 元素。 使用鍵盤時，使用者從該元素開始與應用程式的 UI 互動。

針對 UWP app，初始焦點會設定為可接收焦點的最高 TabIndex 元素。 容器控制項的子元素將被忽略。 在繫結中，視覺樹中的第一個元素接收焦點。

將初始焦點設定為最邏輯元素

將初始焦點設定在使用者啟動應用程式或瀏覽到頁面時最有可能執行的第一個或主要操作的 UI 元素上。 這些範例包含：

  • 一個照片應用程式，其中焦點設置為資源庫中的第一項
  • 焦點設定為播放按鈕的音樂應用程式

不要將最初的注意力集中在可能帶來潛在負面，甚至災難性結果的元素上

這個功能層級應該是使用者的選擇。 將初始焦點設為具有重大結果的元素可能會導致意外的資料遺失或系統存取。 例如，瀏覽到電子郵件時不要將焦點設定到刪除按鈕。

如需覆寫定位順序的詳細資訊，請參閱焦點瀏覽。

通常透過定位順序和方向鍵支援鍵盤瀏覽。

tab and arrow keys

根據預設，UWP 控制項會遵循下列基本鍵盤行為：

  • TAB 鍵會依定位順序在可採取動作/作用中的控制項之間瀏覽。
  • Shift + Tab 會以反向定位順序瀏覽控制項。 如果使用者已使用方向鍵在控制項內瀏覽，焦點會設定為控制項內的最後一個已知值。
  • 方向鍵公開特定於控制項的「內部瀏覽」 當使用者輸入「內部瀏覽」時，方向鍵不會瀏覽出控制項。 這些範例包含：
    • 向上/向下鍵會在 ListView 和 MenuFlyout 內移動焦點
    • 修改 Slider 和 RatingsControl 目前選取的值
    • 在 TextBox 內移動插入號
    • 展開/折疊 TreeView 內部的專案

使用這些預設行為來最佳化應用程式的鍵盤瀏覽。

提供方向鍵瀏覽至一組相關控制項，可強化其在應用程式 UI 整體組織內的關聯性。

例如，此處顯示的 ContentDialog 控制項預設為水平行按鈕提供內部瀏覽 (對於自訂控制項，請參閱控制項組部分)。

dialog example

使用箭號鍵瀏覽更容易與相關按鈕集合的互動

如果項目顯示在單一資料行中，向上/向下鍵會瀏覽專案。 如果項目顯示在單一資料列中，向右/向左鍵會瀏覽專案。 如果專案有多個資料行，則所有 4 個方向鍵都會瀏覽。

透過為一組相關或互補的控制項定義單一定位停駐點，您可以最大限度地減少應用程式中總體定位停駐點的數量。

例如，下列影像顯示兩個堆疊 ListView 控制項。 左側的影像顯示了與定位停駐點一起使用的方向鍵瀏覽在 ListView 控制項之間進行瀏覽，而右側的影像顯示如何透過消除使用 Tab 鍵瀏覽上層控制項的需要來使子元素之間的瀏覽變得更容易且更有效率。

arrow and tab arrow only

透過消除定位停駐點並僅使用方向鍵瀏覽，可以使與兩個堆疊的 ListView 控制項的互動變得更容易且更有效率。

請瀏覽控制群組一節，了解如何將最佳化範例套用至您的應用程式 UI。

互動和命令

控制項擁有焦點之後，使用者可以與其互動，並使用特定的鍵盤輸入叫用任何相關聯的功能。

文字輸入

對於專為 TextBox 和 RichEditBox 等文字輸入而設計的控制項，所有鍵盤輸入都用於輸入或瀏覽文字，這會優先於其他鍵盤命令。 例如，AutoSuggestBox 控制項的下拉式功能表無法將空白鍵辨識為選擇指令。

text entry

空白鍵

當不在文字輸入模式中時，空白鍵會叫用與焦點控制項相關聯的動作或命令 (就像點選觸控或按兩下滑鼠)。

space key

Enter 鍵

輸入鍵可以執行各種常見的使用者互動，視焦點的控制項而定：

  • 啟動命令控制項，例如 Button 或 Hyperlink。 為了避免使用者混淆，輸入鍵也會啟動類似 ToggleButton 或 AppBarToggleButton 命令控制項的控制項。
  • 顯示 ComboBox 和 DatePicker 等控制項的選擇器 UI。 輸入鍵也會認可並關閉選擇器 UI。
  • 啟動清單控制項，例如 ListView、GridView 與 ComboBox。
    • 輸入 鍵會執行選取動作，做為清單和網格線專案的空白鍵，除非有與這些專案相關聯的其他動作 (開啟新視窗)。
    • 如果其他動作與控制項相關聯，輸入鍵會執行其他動作，而空白鍵會執行選取動作。

注意輸入鍵和空白鍵並不總是執行相同的操作，但通常會執行相同的操作。

enter key

Esc 鍵

Esc 鍵可讓使用者取消暫時性 UI (以及該 UI 中的任何進行中動作)。

這種經驗的範例包括：

  • 使用者開啟 ComboBox 具有選定值的視窗，並使用方向鍵將焦點選擇移至新值。 按下 Esc 鍵會關閉 ComboBox，並將選取的值重設為原始值。
  • 使用者會叫用電子郵件的永久刪除動作，並以 ContentDialog 提示您確認動作。 使用者確定這不是預期的操作，並按 Esc 鍵關閉對話方塊。 由於 Esc 鍵與取消按鈕關聯，因此對話方塊將關閉並且操作將被取消。 Esc 鍵僅影響短暫的 UI，它不會關閉或向後瀏覽應用程式 UI。

Esc key

Home 和 End 鍵

首頁和結束鍵可讓使用者捲動到 UI 區域的開頭或結尾。

這種經驗的範例包括：

  • 對於 ListView 和 GridView 控制項，Home 鍵將焦點移動到第一個元素並將其捲動到檢視中，而 End 鍵將焦點移動到最後一個元素並將其捲動到檢視中。
  • 對於 ScrollView 控制項，Home 鍵會捲動到區域的頂端，而 End 鍵則捲動到區域底部 (焦點不會變更)。

home and end keys

Page Up 或 Page Down 鍵

Page 鍵可讓使用者以離散增量捲動 UI 區域。

例如，對於 ListView 和 GridView 控制項，Page up 鍵將區域向上捲動頁面 (通常是檢視區高度) 並將焦點移動到區域的頂部。 或者，Page down 鍵會向下捲動區域，並將焦點移至區域的底部。

page up and down keys

鍵盤快速鍵

鍵盤快捷方式可讓您的應用程式更容易使用，方法是為鍵盤使用者提供輔助功能增強的支援和提升效率。

除了在應用程式中支援鍵盤瀏覽和啟用之外，也建議您提供應用程式功能的快捷方式。 選項卡瀏覽提供了良好的基本鍵盤支持，但對於更複雜的 UI，您可能還需要添加對快捷鍵的支援。

快捷鍵是一種鍵盤組合，透過為使用者提供存取應用程式功能的有效方法來提高工作效率。 快捷鍵有兩種：

  • 加速器是呼叫應用程式命令的捷徑。 您的應用程式可能或可能不會提供對應至命令的特定UI。 加速鍵通常由 Ctrl 鍵和字母鍵組成。
  • 存取金鑰是將焦點設定到應用程式中特定 UI 的快捷鍵。 存取金鑰通常是由 Alt 鍵加上字母金鑰所組成。

提供一致的鍵盤快捷鍵來支援跨應用程式的類似任務，使它們更加有用和強大，並幫助使用者記住它們。

加速器

加速器可協助使用者更快、更有效率地在應用程式中執行常見操作。

加速器的範例：

  • 在郵件應用程式中的任意位置按 Ctrl + N 鍵會啟動新郵件項目。
  • 在 Microsoft Edge (以及許多 Microsoft Store 應用程式) 中的任意位置按 Ctrl + E 鍵可啟動搜尋。

加速器具有下列特性：

  • 它們主要使用 Ctrl 和 Function 鍵序列 (Windows 系統快速鍵也使用 Alt + 非字母數字鍵和 Windows 標誌鍵)。
  • 它們僅分配給最常用的命令。
  • 它們的目標是被記住，並且僅記錄在功能表、工具提示和幫助中。
  • 如果支援的話，它們會在整個應用程式中發揮作用。
  • 它們應該被一致地分配，因為它們是被記憶，而非直接記錄。

Access keys

有關支援 UWP 存取金鑰的更深入資訊，請參閱訪問鍵頁面。

存取金鑰可幫助有運動功能障礙的使用者一次按一個鍵，就能對 UI 中的特定項目進行操作。 此外，存取金鑰可用來傳達其他快速鍵，協助進階使用者快速執行動作。

存取金鑰具有下列特性：

  • 他們會使用 Alt 鍵和字母數字鍵。
  • 它們主要適用於輔助功能。
  • 它們透過關鍵提示直接記錄在 UI 中，靠近控制項。
  • 它們只會在目前視窗中生效，並瀏覽至對應的功能表項或控制項。
  • 盡可能將存取金鑰一致地指派給常用的命令 (特別是認可按鈕)。
  • 它們已當地語系化。

常用鍵盤快速鍵

下表是常用鍵盤快速鍵的小範例。

動作 鍵盤命令
全選 Ctrl+A
連續選擇 Shift + 方向鍵
儲存 Ctrl+S
Find Ctrl+F
列印 Ctrl+P
複本 Ctrl+C
剪下 Ctrl+X
貼上 Ctrl+V
復原 Ctrl+Z
下一個索引標籤 Ctrl+Tab
關閉索引標籤 Ctrl+F4 或 Ctrl+W
語意式縮放 Ctrl++ 或 Ctrl+-

有關 Windows 系統快捷方式的完整清單，請參閱 Windows 鍵盤快捷方式。 如需常見的應用程式快捷方式，請參閱 Microsoft 應用程式的鍵盤快捷方式。

高級體驗

在本部分中，我們將討論 UWP 應用程式支援的一些更複雜的鍵盤互動體驗，以及在不同裝置和不同工具上使用應用程式時應注意的一些行為。

控制項群組

您可以將「控制項群組」 (或方向區域) 中的一組相關或互補控制項分組，以使用方向鍵啟用「內部瀏覽」。 控制項群組可以是單一定位停駐點，也可以指定控制項群組內的多個定位停駐點。

方向鍵瀏覽

當使用者在 UI 區域中有一組類似的相關控制項時，使用者預期支援方向鍵瀏覽：

  • CommandBar 中的 AppBarButtons
  • ListItems 或 ListView 內的 GridItems 或 GridView
  • ContentDialog 內的 Buttons

UWP 控制項預設支援方向鍵瀏覽。 針對自訂版面配置和控制項群組，請使用 XYFocusKeyboardNavigation="Enabled" 來提供類似的行為。

請考慮在使用下列控制項時新增方向鍵瀏覽的支援：

Dialog buttons

對話框按鈕

Radio buttons

RadioButtons

AppBar buttons

AppBarButtons

List and Grid items

ListItems 和 GridItems

定位停駐點

根據應用程式的功能和控制群組的最佳瀏覽選項可能是帶有指向子元素的箭頭瀏覽的單一定位停駐點、多個定位停駐點或某種組合。

針對按鈕使用多個定位停駐點和方向鍵

輔助功能使用者依賴完善的鍵盤瀏覽規則，這些規則通常不使用方向鍵來瀏覽按鈕集合。 然而，沒有視覺障礙的使用者可能會覺得這種行為很自然。

在這裡案例中，預設 UWP 行為的範例是 ContentDialog。 雖然方向鍵可用來在按鈕之間瀏覽，但每個按鈕也是定位停駐點。

將單一定位停駐點指派給熟悉的 UI 模式

如果您的配置遵循眾所周知的控制項群組 UI 模式，則為該群組指派單一定位停駐點可以提高使用者的瀏覽效率。

範例包含：

  • RadioButtons
  • 多個 ListViews 看起來和行為都像單一 ListView
  • 任何外觀和行為都類似於圖塊網格的 UI (例如開始功能表磚)

指定控制項群組行為

使用以下 API 支援自訂控制組行為 (本主題後面將更詳細地討論所有這些行為)：

下圖顯示相關聯單選按鈕控制項群組的直覺式鍵盤瀏覽行為。 在這種情況下，我們建議控制組使用單一定位停駐點，使用方向鍵在單選按鈕之間進行內部瀏覽，將 Home 鍵繫結到第一個單選按鈕，將 End 鍵繫結到最後一個單選按鈕。

putting it all together

鍵盤和朗讀程式

朗讀程式是一種 UI 輔助功能工具，適用於鍵盤使用者 (也支援其他輸入類型)。 但是，朗讀程式功能超出了 UWP 應用支援的鍵盤互動，因此在為朗讀程式設計 UWP 應用程式時需要格外小心。 (朗讀程式基本概念頁面會引導您完成朗讀程式使用者體驗。)

UWP 鍵盤行為與朗讀程式所支持的差異包括：

  • 用於瀏覽至未透過標準鍵盤瀏覽公開的 UI 元素的額外組合鍵，例如用於讀取控制項標籤的 Caps lock + 方向鍵。
  • 瀏覽至停用的專案。 預設情況下，停用的項目不會透過標準鍵盤瀏覽公開。
  • 控制「檢視」，以根據 UI 粒度快速瀏覽。 使用者可以瀏覽到項目、字元、單字、行、段落、連結、標題、表格、地標和建議。 標準鍵盤瀏覽將這些物件公開為平面清單，這可能會使瀏覽變得麻煩，除非您提供快捷鍵。

案例研究 – AutoSuggestBox 控制項

使用製表符和方向鍵的標準鍵盤瀏覽無法存取 AutoSuggestBox 的搜尋按鈕，因為使用者可以按 輸入鍵提交搜尋查詢。 不過，當使用者按下 Caps Lock + 方向鍵時，可透過朗讀程式存取它。

autosuggest keyboard focus

使用鍵盤，使用者按 Enter 鍵提交搜尋查詢

autosuggest narrator focus

使用朗讀程式時，使用者按下 Enter 鍵以提交搜尋查詢

autosuggest narrator focus on search

使用朗讀程式，使用者還可以使用 Caps Lock + 向右方向鍵，然後按空白鍵來存取搜尋按鈕

鍵盤、遊戲板和遙控器

遊戲板和遙控器支援許多 UWP 鍵盤行為和體驗。 然而，由於鍵盤上缺乏各種可用的按鍵選項，遊戲手把和遙控器缺乏許多鍵盤最佳化 (遙控器比遊戲手把更有限)。

有關 UWP 對遊戲手把和遠端控制輸入支援的更多詳細資訊，請參閱遊戲手把和遠端控制互動。

以下顯示鍵盤、遊戲板和遠端控制之間的一些按鍵對應。

鍵盤 遊戲板 遠端控制
Space A 按鍵 選取按鈕
Enter A 按鍵 選取按鈕
ESC 鍵 B 按鍵 返回按鈕
Home/End N/A N/A
Page Up/Down 垂直捲動 Trigger 按鈕，水平捲動 Bumper 按鈕 N/A

設計 UWP app 以搭配遊戲板和遙控器使用時，您應該注意的一些主要差異包括：

  • 文字輸入需要使用者按下 A 以啟動文字控制項。

  • 焦點瀏覽不限於控制組，使用者可以自由瀏覽到應用程式中任何可聚焦的 UI 元素。

    注意焦點可以移至按鍵按下方向的任何可焦點 UI 元素，除非它位於重疊 UI 或焦點參與中，否則會防止焦點進入/離開區域，直到與 A 按鈕互動/脫離為止。 有關詳細資訊，請參閱方向瀏覽部分。

  • D 鍵和左桿按鈕可用來在控制項之間移動焦點，以及用於內部瀏覽。

    注意遊戲板和遙控器只會瀏覽至與按下方向鍵相同的視覺順序的專案。 當沒有可以接收焦點的後續專案時，瀏覽會以該方向停用。 視情況而定，鍵盤使用者不一定會有該條件約束。 有關詳細資訊，請參閱內建鍵盤最佳化部分。

瀏覽方向

方向瀏覽由 UWP 焦點管理器可幫助程式類別管理，該類別按下方向鍵 (方向鍵、方向鍵) 並嘗試將焦點移動到相應的視覺方向。

不同於鍵盤，當應用程式退出退出滑鼠模式時，方向瀏覽會套用到遊戲板和遙控器的整個應用程式。 如需方向瀏覽最佳化的詳細資訊，請參閱遊戲板和遠端控制互動。

注意使用鍵盤 Tab 鍵的瀏覽不會被視為方向瀏覽。 如需詳細資訊，請參閱定位停駐點一節。

directional navigation

支援方向瀏覽
使用方向鍵 (鍵盤箭頭、遊戲手把和遙控器方向鍵)，使用者可以在不同的控制項之間瀏覽。

no directional navigation

不支援方向瀏覽
使用者無法使用方向鍵在不同控制項之間瀏覽。 在控制項之間瀏覽的其他方法 (Tab 鍵) 不會受到影響。

內建鍵盤最佳化

根據所使用的版面配置和控制項，UWP 應用程式可以特別針對鍵盤輸入進行最佳化。

下列範例顯示已指派給單一定位停駐點的清單專案、方格專案和功能表項群組 (請參閱定位停駐點區段)。 當群組獲得焦點時，將使用方向方向鍵按照相應的視覺順序執行內部瀏覽 (請參閱瀏覽部分)。

single column arrow key navigation

單資料行方向鍵瀏覽

single row arrow key navigation

單一資料列方向鍵瀏覽

multiple column and row arrow key navigation

多個資料行/資料列方向鍵瀏覽

包裝同類清單和網格檢視+項

方向瀏覽不一定是瀏覽 List 和 GridView 專案之多個資料列和資料行的最有效率的方式。

注意功能表項目通常是單列清單，但在某些情況下可能適用特殊的焦點規則 (請參閱 Popup UI)。

您可以使用多個資料列和資料列來建立清單和 Grid 物件。 這些通常按資料列優先 (其中項目在填充下一行之前先填充整個資料列) 或資料行優先 (其中項目在填充下一列之前首先填充整個資料行) 順序。 資料列或資料行的主要順序取決於捲動方向，您應確保專案順序不會與此方向衝突。

以列為主順序 (項目依序由左至右、由上至下填入)，當焦點位於列中的最後一個項目上，按下向右鍵時，焦點會移至下一列中的第一個項目。 反之亦會發生此相同行為：當焦點設定至列中的第一個項目上，按下向左鍵時，焦點移至上一列的最後一個項目。

以欄為主順序 (項目依序由上至下、由左至右填入)，當焦點位於一欄中的最後一個項目上並按下向下鍵時，焦點會移至下一欄中的第一個項目。 反之亦會發生此相同行為：當焦點設定至欄中的第一個項目上，按下向上鍵時，焦點移至上一欄的最後一個項目。

row major keyboard navigation

資料列主要鍵盤瀏覽

column major keyboard navigation

資料行主要鍵盤瀏覽

如前所述，您應該嘗試確保定向瀏覽與應用程式 UI 中控制項的視覺順序相對應。

某些控制項 (例如內容功能表、CommandBar 溢位功能表和 AutoSuggest 功能表) 會在相對於主控制項和可用螢幕空間的位置和方向 (預設向下) 顯示彈出式功能表。 請注意，開啟方向可能會受到執行階段的各種因素影響。

command bar opens down with down arrow key command bar opens up with down arrow key

對於這些控制項，當首次開啟功能表時 (且使用者尚未選擇任何項目)，向下鍵始終將焦點設為第一個項目，而向上鍵則始終將焦點設為功能表上的最後一個項目。

如果最後一項具有焦點，並且按下向下方向鍵，則焦點將移至功能表上的第一項。 同樣，如果第一個項目具有焦點並且按下向上鍵，焦點將移至功能表上的最後一個項目。 此行為稱為循環，對於瀏覽可能以不可預測的方向打開的彈出式功能表非常有用。

注意

在非快顯 UI 中，應該避免循環循環，使用者可能會覺得被困在無休止的迴圈中。

建議您在自訂控制項中模擬這些相同的行為。 如需如何實作此行為的程式碼範例，請參閱程式設計焦點瀏覽文件。

測試您的應用程式

使用所有支援的輸入裝置測試您的應用程式，以確保可以以連貫且直觀的方式瀏覽到 UI 元素，並且不會出現意外元素幹擾所需的 Tab 鍵順序。

附錄

軟體鍵盤

軟體鍵盤會顯示在畫面上，而不是使用實體鍵盤輸入資料，並使用觸控、滑鼠、手寫筆/手寫筆或其他指向裝置輸入和輸入資料。 在遊戲裝置上，必須藉由移動焦點視覺效果或使用遊戲板或遙控器上的快捷鍵來選取個別按鍵。

觸控式鍵盤

Windows 11 touch keyboard

Windows 11 觸控式鍵盤

根據裝置的不同，當文字欄位或其他可編輯文字控制項獲得焦點時，或當使用者透過通知中心手動啟用它時，會出現觸控鍵盤：

Screenshot of the touch keyboard icon in the notification center.

如果您的應用程式以程式設計方式將焦點設定為文字輸入控制項，則不會叫用觸控式鍵盤。 這消除了非使用者直接發起的意外行為。 不過，當焦點以程式設計方式移至非文字輸入控制項時，鍵盤會自動隱藏。

當使用者在表單中的控制項之間瀏覽時，觸控鍵盤通常保持可見。 此行為可能會根據表單中的其他控制項類型而有所不同。

以下是非編輯控制項的清單，這些控制項可以在使用觸控鍵盤進行文字輸入會話期間接收焦點，而無需關閉鍵盤。 觸控鍵盤不會不必要地擾亂 UI 並可能使使用者迷失方向，而是保持在視野中，因為使用者可能會在這些控制項和使用觸控鍵盤進行文字輸入之間來回切換。

  • 核取方塊
  • 組合方塊
  • 選項按鈕
  • 捲軸
  • 樹狀結構
  • 樹狀結構項目
  • 功能表
  • 功能表列
  • 功能表項目
  • 工具列
  • 清單​​
  • 清單項目

以下是觸控鍵盤不同模式的範例。 第一個影像是預設配置，第二個影像是擴展配置 (可能不適用於所有語言)。

Screenshot of the touch keyboard in default layout mode.

預設版面配置模式中的觸控式鍵盤

Screenshot of the touch keyboard in expanded layout mode.

擴展配置模式下的觸控鍵盤

成功的鍵盤互動使使用者僅使用鍵盤即可完成基本的應用場景；也就是說，使用者可以存取所有互動元素並啟動預設功能。 許多因素都會影響成功程度，包括鍵盤瀏覽、輔助功能的存取鍵以及進階使用者的加速鍵 (或快速鍵)。

螢幕小鍵盤

與觸控鍵盤一樣，螢幕鍵盤 (OSK) 是一種視覺軟體鍵盤，用於取代實體鍵盤，使用觸控、滑鼠、筆/手寫筆或其他指點裝置 (不需要觸控螢幕) 輸入並輸入資料。 OSK 是為沒有實體鍵盤的系統或身體有障礙而無法使用傳統實體輸入裝置的使用者提供的。 OSK 可模擬硬體鍵盤的大部分功能 (如果不是全部功能)。

可以從設定 > 輕鬆存取中的鍵盤頁面開啟 OSK。

注意OSK 優先於觸控式鍵盤，如果 OSK 存在，則不會顯示此觸控式鍵盤。

Screenshot of the On-Screen Keyboard.

螢幕小鍵盤

Screenshot of the Xbox One On-Screen Keyboard.

Xbox One 螢幕小鍵盤

有關更多詳細資訊，請參閱使用螢幕鍵盤輸入。