Comprender la navegación accesible

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

• Enumerar estrategias para proporcionar a los usuarios información de navegación y acción.
• Explicar a importancia de la gestión del enfoque en el desarrollo de aplicaciones web.

Introducción

Los usuarios deben siempre saber dónde están en una aplicación y qué acciones pueden llevar a cabo después. Proporcione a los usuarios información de navegación y acción:

• Utilizando elementos de navegación coherentes.
• Aplicando anidado y orden de encabezado apropiados.
• Etiquetando regiones de punto de referencia.
• Utilizando un orden de ficha lógica que coincide con el orden de lectura (en idiomas de izquierda a derecha, izquierda a derecha, de arriba a abajo; en idiomas de derecha a izquierda, derecha a izquierda).
• Utilizando indicadores de enfoque visibles para todos los elementos interactivos.

Cambios de contexto

Cuando se trata de cambios de contexto, considere las siguientes reglas generales:

1. Los usuarios deben esperar un cambio en el contexto, ya sea porque lo solicitaron, o de lo contrario se les explicó que se aproxima un cambio.
2. Cuando sucede el cambio, los usuarios deben saber dónde están en una página.

Considere el botón Mostrar más en la imagen de una navegación de Reporte o Carpetas a continuación. 

Cuando un usuario hace clic en Mostrar más, tiene algunas opciones para alertarlo acerca del nuevo contenido que se introdujo.

1. Puede enfocar el primer elemento del nuevo contenido. ¿Es esta la mejor opción? Posiblemente, pero los botones leen, “Mostrar más”,no “Llevarme a más”.
2. Puede utilizar una región aria-live para anunciar a lectores de pantalla que se agregaron más elementos de navegación a la página.
3. Puede cambiar el texto del botón para leer, “Mostrar menos”. Esta es la mejor opción porque el éxito del usuario está implicado en el nuevo texto del botón: “Puedo mostrar menos,pero ahora se está mostrando más.”

La pregunta para el usuario de un lector de pantalla ahora es, “¿Dónde está el ‘más’ que se introdujo?” Colocando el nuevo contenido delante del usuario, encontrar la respuesta a esta pregunta es simple.

En algunos casos de uso, mover el enfoque de un usuario o utilizar una región aria-live es apropiado. Conocer qué técnica utilizar en una situación concreta se reduce a comprender las expectativas del usuario. 

Por ejemplo, imagine un botón Modificar que inicia un modal. 

Una vez iniciado, el botón Modificar se ocultará por el modal, de modo que no tiene sentido mantener el enfoque en el botón. En este ejemplo, movemos el enfoque al modal en si. Como regla general, nunca debe mover el enfoque de un usuario a menos que el usuario haya actuado de forma explícita. En este caso, cuando el usuario hace clic en Modificar, el enfoque debe moverse naturalmente al contexto de modificación.

Es también importante mover el enfoque de forma lógica cuando el usuario realiza una acción en algo y ese algo desaparece. Continuando con este ejemplo, ¿dónde debe ir el enfoque del usuario cuando el modal está cerrado? El enfoque debe ir a algo, y no solo la parte superior de la página. Una opción lógica,en este caso, es volver al botón Modificar que inició el modal inicialmente. 

Podrá obtener más información acerca de los cambios de contexto, incluidas las regiones aria-live, en la sección Recursos que aparece a continuación.

Gestión de enfoque

La gestión apropiada del enfoque es uno de los factores clave del desarrollo de aplicaciones web accesibles. En general, los usuarios pueden mover el enfoque a través de una página pulsando Tabulación para avanzar y bajar en la página, y Mayús+Tabulación para retroceder y hacer una copia de seguridad de la página. Esto se aplica a elementos HTML que reciben el enfoque de forma nativa, como delimitadores, botones y controles de formulario.

Los componentes complejos, como cuadrículas interactivas, menús,cuadros combinados y conjuntos de fichas se navegan con las teclas de flecha. La programación de estas interacciones avanzadas es parte del compromiso que toma con usuarios cuando utiliza atributos de función de ARIA.

Platiquemos acerca de cómo gestionar el enfoque cuando cambia el contexto de un usuario. ¿Qué debe sucede en el enfoque de un usuario cuando: 

• Navega a una nueva página?
• Abre o cierra un diálogo de modal?
• Elimina un registro?
• Realizar una operación de arrastrar y soltar?

Las respuestas a estas preguntas y mucho más están en las Directrices de enfoque global de SLDS. 

Más allá de estas directrices, considere lo siguiente:

1. Los usuarios con cierta discapacidad, incluyendo usuarios invidentes, navegan normalmente hacia delante y hacia abajo en la página cuando interactúan con una aplicación. Si su diseño introduce nuevo contenido en la página, asegúrese de que se agrega el nuevo contenido frente al elemento que desencadenó el cambio. Por ejemplo, cuando el usuario hace clic en un botón que introduce un formulario en línea en la página, el formulario debe estar después del botón en el orden de DOM. Los usuarios esperan encontrar el formulario conforme avanzan, hacia abajo en la página,no cuando retroceden.
2. No robe el enfoque en la inicialización de componentes, a menos que sea parte de la especificación del componente. Se supone que un diálogo de modal, por ejemplo, robe el enfoque cuando se inicialice.
3. No cree una trampa de enfoque. Permita a los usuarios salir de sus componentes. A menos, de nuevo, que sea parte del comportamiento previsto del componente, como con un modal.
4. Gestione la carga infinita con cuidado. No fuerce los usuarios solo de teclado a cargar y navegar por todas unas noticias en tiempo real, toda una lista o toda una tabla con el fin de llegar a contenido en el otro lado. Por ejemplo, nuestras noticias en tiempo real de Chatter tienen todas un vínculo “Omitir estas noticias en tiempo real” al inicio de las noticias en tiempo real.

A continuación, echaremos un vistazo a la redacción de componentes accesibles. 

Recursos

Ayuda de Salesforce: Directrices de enfoque global de Lightning Design System

Técnicas W3C para WCAG 2.0: ARIA19: Uso de ARIA role=alert o regiones Live para identificar errores