Organizar controis en aplicacións de lenzo accesibles
Os controis nunha aplicación deben organizarse para axudar aos usuarios do lector de pantalla a navegar secuencialmente. Unha orde lóxica tamén reduce a confusión para os usuarios de teclados e axuda a ser máis produtivos.
Nome de pantalla significativo
Cando se cargue unha pantalla, os lectores de pantalla dirán o seu nome. Escolla un nome significativo para orientar aos usuarios.
Pode cambiar o nome da pantalla na árbore de controis ou no panel de propiedades de Power Apps Studio. Seleccione a pantalla e logo seleccione 
para renomear a pantalla.
O primeiro elemento dunha pantalla é o seu nome. Está oculto e só é accesible para os usuarios de lectores de pantalla.
Cando se carga unha nova pantalla, Power Apps centra o nome da pantalla. Se usa SetFocus inmediatamente cando se carga a pantalla, o nome da pantalla non se lerá. Considere a posibilidade de crear un título visible e convertelo nunha rexión activa para anunciar o cambio de contexto.
Orde de control lóxica
Os usuarios de lectores de pantalla poden navegar polo contido secuencialmente. A orde está determinada pola posición dos controis, comezando de arriba a abaixo e logo de esquerda a dereita. O tamaño do control non importa, só importan as propiedades X e Y.
Neste exemplo, A aparece primeiro na secuencia xa que está máis preto da parte superior. B e C teñen a mesma posición vertical, pero dado que B está máis preto da esquerda, polo tanto, aparece antes que C. D aparece de último dado que está máis lonxe da parte superior.
Nota
- No modo Vista previa cando se edita unha aplicación, a orde de control non se actualiza por motivos de rendemento. A orde será correcta cando se publique e execute a aplicación.
- A orde de control non é a mesma que se mostra na vista en árbore dos controis dentro de Power Apps Studio. A vista en árbore ordena os controis segundo cando se engadiron á aplicación. Non afecta á orde dos controis cando se executa a aplicación.
- Cando o valor X ou Y dun control se establece nunha expresión, a orde de control non se actualiza cando o resultado dos cambios de expresión. A orde calcúlase e arranxa cando se garda a aplicación, utilizando o estado inicial da aplicación para avaliar expresións.
- Se estás a cambiar a súa posición porque se están ocultando ou mostrando outros controis, podes utilizar contedores de deseño automático para xestionar X e Y para ti.
- Tamén pode situar todos os controis dun xeito lóxico independentemente dos valores de expresión. Por exemplo, se o control A debe estar sempre por debaixo do control B e ás veces B pode ocultarse, establece Y para que sexa
If(B.Visible, B.Y + B.Height, B.Y + 1). A suma de 1 garante que A estea sempre por debaixo de B, aínda que B estea oculto.
Controis agrupados
A orde predeterminada é adecuada para contido illado pero non para contido agrupado. Coloque dous mosaicos un ao lado doutro, debuxados con controis Rectangulares. Cada mosaico ten unha cabeceira. Debaixo do título hai dous botóns colocados verticalmente: A e B para o primeiro mosaico e C e D para o outro.
A orde predeterminada vai de arriba a abaixo, e de esquerda a dereita. Polo tanto, a orde dos controis é:
- Rectángulo esquerdo
- Rectángulo dereito
- Cabeceira esquerda
- Cabeceira dereita
- A
- C
- B
- D
Esta estrutura non significa que A e B estean xuntos e, do mesmo xeito, C e D estean xuntos.
Use Contedores para agrupar contido relacionado. Todos os controis dun Contedor aparecerán xuntos en secuencia. Dentro dun contedor, os controis ordénanse coa mesma regra: de arriba a abaixo e logo de esquerda a dereita.
Se se substitúen os Rectángulos do exemplo anterior por Contedores, a orde de control agora é lóxica para os usuarios do lector de pantalla:
- Contedor esquerdo
- Cabeceira esquerda
- A
- B
- Contedor dereito
- Cabeceira dereita
- C
- D
Todos os controis dunha Tarxeta de formulario e Galería agrúpanse automaticamente, polo que non ten que empregar un Contedor. Non obstante, se hai subgrupos, aínda debería empregar Contedores para eles.
Neste exemplo, unha fila de Galería ten unha miniatura e dous anacos de texto á esquerda. Á dereita hai dous botóns. Os dous conxuntos de controis deben agruparse visual e loxicamente. Isto garante que os usuarios do lector de pantalla atoparán primeiro o grupo esquerdo antes que o dereito.
Orde lóxica de navegación por teclado
A navegación por teclado é un aspecto importante de calquera aplicación. Para moitos, o teclado é máis eficiente que usar a función táctil ou o rato. A orde de navegación debería ser:
- Siga o fluxo visual dos controis.
- Siga unha orde intuitiva e despois unha orde en "Z" ou unha orde cara a abaixo e despois unha orde en "N inversa".
- Faga que só un separador se deteña en controis interactivos.
AcceptsFocus especifica se se pode acceder aos controis mediante o teclado. Para os controis clásicos, a propiedade equivalente é TabIndex.
A orde de navegación segue a orde de control: de esquerda a dereita, despois de arriba a abaixo, nun patrón "Z". Podes personalizalo do mesmo xeito que coa orde de control. Por exemplo, controis en Contedores, Formulario Cartóns e Galerías agrúpanse automaticamente. A tecla Tab navegará por todos os elementos dentro do contedor antes de pasar ao seguinte control fóra do contedor.
Se a orde de navegación é inesperada, primeiro debería comprobar se a estrutura da aplicación é lóxica.
Nota
Cando os controis se moven de forma dinámica na pantalla, por exemplo, cando o seu valor X ou Y cambia segundo a Power Fx expresión, a orde de navegación non se actualizará.
Solución alternativa para a secuencia de pestanas personalizada
En casos raros nos que a orde de navegación do teclado debería ser diferente da orde visual, pode colocar controis de contedor coidadosamente para que teñan o mesmo efecto.
No exemplo de abaixo, o botón A está enriba do botón B. A orde natural de navegación das pestanas é A, despois B.
Para inverter a orde de navegación por pestanas, coloque B nun control de contedor. Estableza o valor Y do Contedor para que estea por riba de A. A estrutura das aplicacións agora ten o Contedor (e B) antes de A. Polo tanto, a orde de navegación das pestanas é B e despois A.
Con esta técnica, os usuarios de lectores de pantalla tamén atoparán B antes que A cando navegan sen a tecla Tab.
Índices de pestanas personalizados (función retirada)
Os índices de pestanas personalizados son aqueles que son maiores que cero. Xa non se admiten. Todos os TabIndex valores superiores a cero trataranse como cero.
Os índices de pestanas personalizados son case sempre un sinal de mal deseño. Hai mellores alternativas como crear unha estrutura de aplicacións adecuada ou usar SetFocus para cambiar o foco.
Algúns problemas cos índices de pestanas personalizados:
Accesibilidade
É un problema serio de accesibilidade ter índices de pestanas personalizados. Os usuarios de lectores de pantalla navegan nunha aplicación usando a súa estrutura lóxica. Os índices de pestanas personalizados ignoran esa estrutura. Xa que os usuarios do lector de pantalla tamén poden navegar usando a tecla Tab, confundiranse cando obteñan unha orde diferente a outros métodos de navegación.
Usabilidade
Os usuarios poden confundirse cando parece que se omiten algúns elementos. Poden estar desorientados cando o foco se move nunha orde imprevisible. Isto é aínda máis problemático para os usuarios con discapacidade cognitiva.
Mantemento
Os creadores de aplicacións teñen que actualizar manualmente TabIndex de varios controis sempre que se insira un novo. É fácil perder unha actualización ou facer un pedido incorrecto.
Desempeño
Para admitir índices de pestanas personalizados, o sistema Power Apps ten que examinar todos os controis da páxina e calcular a orde adecuada. Este cálculo é un proceso intensivo. Controis de contedores como Galería teñen regras complicadas sobre como funciona TabIndex para controis secundarios. O sistema mapea o TabIndex desexado polo creador da aplicación a un valor diferente para obedecer estas regras. É por iso que aínda que TabIndex estea configurado en cero para todos os controis, o HTML real tabindex será algún número positivo.
Integración con outros compoñentes
Os índices de pestanas personalizados só funcionan con controis integrados. Controis que non están integrados no sistema de índice de pestana de Power Apps terá unha orde de navegación inesperada. Isto pode ser un problema para compoñentes do código. Os desenvolvedores destes compoñentes teñen que facer un seguimento dos elementos interactivos e establecer un índice de pestanas neles. Poden usar bibliotecas de terceiros, que nin sequera proporcionan unha forma de personalizar os índices de pestanas. Por outra banda, cando todos os índices de pestanas son 0 ou -1, non hai que implicar o sistema de índice de pestanas de Power Apps. Calquera compoñente de terceiros incorporado na aplicación obterá automaticamente a secuencia de pestanas correcta.
Na outra dirección, cando as aplicacións de lenzo están incrustadas noutra páxina web, os índices de pestanas personalizados non funcionan. Por exemplo, en páxinas personalizadas. Power Apps non pode controlar os elementos fóra da aplicación de lenzo, polo que a orde xeral de navegación das pestanas será ilóxica.
Pasos seguintes
Cores accesibles en Power Apps