應用程式中的控制項應該組織，以協助螢幕助讀程式使用者循序瀏覽。 合乎邏輯的順序也可減少鍵盤使用者的混淆，並協助他們提高工作效率。
有意義的網名
載入畫面時，螢幕助讀程式將會念出它的名稱。 選擇一個有意義的名稱來引導用戶。
您可以在 Power Apps Studio 的控制項樹狀結構或屬性面板中變更螢幕名稱。 選取畫面，然後選取 [ ![選取手寫筆圖示] 以編輯名稱。](media/accessible-apps-structure/pencil-icon.png "選擇筆圖示以編輯名稱"){kind=icon}
以重新命名螢幕。
螢幕上的第一個元素是它的名稱。 它在視覺上是隱藏的，只有螢幕閱讀器使用者才能存取。
載入新畫面時，Power Apps 會聚焦螢幕名稱。 如果您在載入畫面時立即使用 SetFocus，則不會讀取畫面名稱。 請考慮建立可見標題，並將其設為 即時區域 ，以在內容中宣告變更。
邏輯控制順序
螢幕助讀程式使用者可以循序瀏覽內容。 順序由控制項的位置決定，從上到下，然後從左到右。 控制項的大小並不重要，只有其 X 和 Y 屬性才重要。
在此範例中，A 在序列中最先出現，因為它最接近頂端。 B 和 C 具有相同的垂直位置，但由於 B 更靠近左側，因此它出現在 C 之前。D 最後出現，因為它離頂部最遠。
備註
- 在編輯應用程式時，在 預覽 模式下，基於效能原因，控制順序不會更新。 當應用程序發布和運行時，順序將是正確的。
- 控制項順序與 Power Apps Studio 中 控制項的樹狀檢視 中顯示的順序不同。 樹狀結構檢視會根據控制項新增至應用程式的時間來排序控制項。 它不會影響應用程式執行時的控制順序。
- 當控制項的 X 或 Y 值設定為運算式時，當運算式的結果變更時，控制項順序不會更新。 儲存應用程式時，會計算並固定順序，使用應用程式的初始狀態來評估運算式。
- 如果您因為隱藏或顯示其他控制項而變更其位置，您可以使用 自動版面配置容器 來管理 X 和 Y 。
- 您也可以以邏輯方式放置所有控制項，而不論運算式值為何。 例如，如果控制項 A 應始終低於控制項 B，而 B 有時可能會隱藏，請將 A 的 Y 設定為
If(B.Visible, B.Y + B.Height, B.Y + 1)。 加1可確保A始終低於B，即使B被隱藏。
分組控制項
預設順序適用於隔離內容，但不適用於群組內容。 考慮兩個相鄰的圖塊，使用 Rectangle 控制項繪製。 每個圖塊都有一個標題。 標題下方是兩個垂直堆疊的按鈕：A 和 B 代表第一個圖塊，C 和 D 代表另一個圖塊。
預設順序是從上到下，然後從左到右。 因此，控制的順序為：
- 左 矩形
- 右 矩形
- 左標題
- 右標題
- A
- C
- B
- D
這種結構並不傳達 A 和 B 在一起，同樣，C 和 D 在一起。
使用 容器 將相關內容分組。 容器中的所有控制項都會依序一起顯示。 在容器內，控制項會以相同的規則排序：從上到下，然後從左到右。
將上一個範例的 矩形 取代為 容器，控制順序現在對螢幕助讀程式使用者來說是合乎邏輯的：
- 左側 容器
- 左標題
- A
- B
- 正確的 容器
- 右標題
- C
- D
表單卡和資源庫中的所有控制項都會自動分組，因此您不必使用容器。 不過，如果有子群組，您仍應使用 容器 。
在此範例中， 「圖庫」 列左側有一個縮圖和兩段文字。 右側有兩個按鈕。 從視覺和邏輯上來說，應該將兩組控制項分組。 這可確保螢幕助讀程式使用者會先遇到左群組，然後再遇到右群組。
邏輯鍵盤導覽順序
鍵盤導航是任何應用程序的一個重要方面。 對許多人來說，鍵盤比使用觸控或滑鼠更有效率。 導覽順序應該：
- 請遵循控件的視覺化流程。
- 可先直觀地橫跨 ，再依 「Z」 順序向下，或先向下，再依「倒 N」順序執行。
- 在互動式控制項上只有一個索引標籤。
AcceptsFocus 會指定鍵盤是否可以存取控制項。 針對傳統控制項，對等屬性是 TabIndex。
導覽順序遵循 控制順序：從左到右，然後從上到下，以「Z」模式。 您可以像使用控制順序一樣自訂它。 例如，容器、表單卡和圖庫中的控制項會自動分組。 Tab 鍵將瀏覽容器內的所有元素，然後再繼續到容器外部的下一個控制項。
如果導覽順序出乎意料，您應該先檢查應用程式結構是否合乎邏輯。
備註
當控制項在畫面上動態移動時，例如，根據 Power Fx 運算式變更其 X 或 Y 值，則不會更新導覽順序。
自訂索引標籤順序的因應措施
對於鍵盤導覽順序應該與視覺順序不同的罕見案例，您可以仔細放置容器控制項，以產生相同的效果。
在下面的範例中，按鈕 A 位於按鈕 B 上方。自然標籤導覽順序是 A，然後是 B。
若要反轉索引標籤導覽順序，請將 B 放在 Container 控制項中。 將容器的 Y 值設定為高於 A。應用程式結構現在在 A 之前具有容器 （和 B），因此，索引標籤導覽順序是 B，然後是 A。
透過這種技術，螢幕閱讀器使用者在沒有 Tab 鍵的情況下導航時也會遇到 B 先於 A。
自訂索引標籤順序（已停用的功能）
自訂標籤索引數值必須大於零。 不再支援它們。 所有大於零的 TabIndex 值都會被視為零。
自訂索引標籤順序幾乎總是設計不良的跡象。 有更好的替代方案，例如建立適當的應用程式結構或使用 SetFocus 來變更焦點。
自訂標籤索引的一些問題：
可及性
擁有自訂標籤索引是一個嚴重的無障礙功能問題。 螢幕助讀程式使用者會使用應用程式的邏輯結構來瀏覽應用程式。 自訂標籤索引會忽略該結構。 由於螢幕閱讀器使用者也可以使用 Tab 鍵進行導航，因此當他們獲得與其他導航方法不同的順序時，他們會感到困惑。
Usability
當某些項目似乎被略過時，用戶可能會感到困惑。 當焦點以不可預測的順序移動時，他們可能會迷失方向。 這對於有認知障礙的用戶來說更是成問題。
Maintenance
每當插入新控件時，應用程序製造商都必須手動更新多個控件的 TabIndex 。 很容易錯過更新或訂單錯誤。
Performance
若要支援自訂索引標籤索引，Power Apps 系統必須檢查頁面上的所有控制項並計算適當的順序。 這個計算是一個密集的過程。 像 Gallery 這樣的容器控制項對於 TabIndex 如何用於子控制項有複雜的規則。 系統會將應用程式製作者所需的 TabIndex 對應至不同的值，以遵守這些規則。 這就是為什麼即使所有控制項的 TabIndex 設定為零，實際的 HTML tabindex 也會是一些正數。
與其他組件集成
自訂索引僅適用於內建控制項。 未整合到 Power Apps 的索引系統中的控件將具有非預期的導航順序。 這可能是 程式碼元件的問題。 這些元件的開發人員必須追蹤互動式元素並在其上設定標籤索引。 他們可能會使用第三方函式庫，這甚至可能無法提供自訂標籤索引的方法。 另一方面，當所有索引標籤索引都是 0 或 -1 時，就不需要涉及 Power Apps 的索引標籤索引系統。 應用程式中嵌入的任何第三方元件都會自動取得正確的標籤順序。
另一方面，當畫布應用程式內嵌在另一個網頁中時，自訂標籤索引將無法運作。 例如，在 自訂頁面中。 Power Apps 無法控制畫布應用程式外部的元素，因此整體索引標籤導覽順序將不合邏輯。