5 pasos para diseñar aplicaciones teniendo en cuenta la accesibilidad del teclado

Cuando pensamos en el usuario "promedio", tendemos a imaginarlo usando un mouse o un trackpad cuando está en su computadora. Pero, ¿y si su opción preferida o única fuera usar un teclado? ¿Ha considerado diseñar sus aplicaciones teniendo en cuenta la accesibilidad del teclado?

Hay muchas razones por las que alguien podría no querer, o no ser capaz de operar un mouse o trackpad para usar su computadora. Pueden tener condiciones permanentes, crónicas o temporales que limitan su destreza o control muscular, causando sensibilidad en sus muñecas o manos, o dificultando el seguimiento del cursor del mouse en una pantalla. También podrían ser "usuarios avanzados" que buscan más atajos para optimizar sus flujos de trabajo. En cualquiera de estos casos, los teclados pueden ser el medio preferido o necesario de un individuo para interactuar con la tecnología.

En este artículo, aprenderá acerca de las pautas de accesibilidad del teclado, así como cinco pasos a tener en cuenta al diseñar aplicaciones para asegurarse de que sean accesibles desde el teclado.

¿Cómo funciona la accesibilidad del teclado?

Si se puede acceder a una aplicación con el teclado, eso significa que las personas tienen la opción de usar solo un teclado para operar los elementos de control . Los elementos de control son cualquier componente interactivo en la página, como botones, enlaces, entradas de formulario, videos y otro contenido interactivo.

Conceptos básicos de navegación del teclado

Estas son algunas de las teclas básicas que se utilizan para la navegación con el teclado:

• Navegar al siguiente elemento de control: Tabulador (o la tecla de flecha hacia la derecha o hacia abajo para botones de radio relacionados y opciones de selección)
• Navegación al elemento de control anterior: Mayús + Tabulador (o la tecla de flecha izquierda o arriba para botones de radio relacionados y opciones de selección)
• Al hacer clic en un elemento de control: Entrar y/o barra espaciadora
• Navegar entre botones de radio relacionados o seleccionar opciones: Teclas de flecha

orden de enfoque

La secuencia en la que los elementos de control pueden responder a los eventos del teclado se conoce como orden de enfoque . Cuando un elemento está enfocado, puede interactuar con él usando ciertos controles del teclado. Cuando un elemento pierde el foco, se vuelve borroso. Los navegadores representan estados de enfoque predeterminados para ayudar a los usuarios a realizar un seguimiento de qué elemento está actualmente enfocado.

También te puede interesar: Diseño universal: 11 consejos prácticos para que tus sitios y aplicaciones sean más accesibles.

Accesibilidad del teclado y las Pautas de accesibilidad al contenido web (WCAG)

Las Pautas de accesibilidad al contenido web (WCAG) describen tres niveles de cumplimiento (Nivel A, Nivel AA y Nivel AAA) que se han adoptado como estándares para las leyes de accesibilidad web regionales o nacionales en todo el mundo.

La accesibilidad del teclado es uno de los criterios de éxito para el cumplimiento del Nivel A. Los criterios del nivel A describen características imprescindibles para todo el contenido web. También se consideran los más fáciles de implementar.

"La accesibilidad del teclado también es fácil de equivocarse si no tenemos cuidado".

Dicho esto, la accesibilidad del teclado también es fácil de equivocarse si no tenemos cuidado. Estos son ejemplos de problemas comunes de accesibilidad del teclado que se encuentran en la web:

• Estados de enfoque imperceptibles
• Orden de enfoque incorrecto
• Elementos interactivos que no pueden recibir el foco
• Componentes complejos que no captan las interacciones del teclado

Afortunadamente, hay muchas técnicas que podemos usar para tener en cuenta a los usuarios del teclado y evitar cometer estos errores en nuestras propias aplicaciones.

5 pasos para crear aplicaciones accesibles desde el teclado

1. Diseña interacciones intuitivas

Cuando renderizamos elementos de control simples sin comportamientos personalizados, generalmente podemos aprovechar sus funciones de accesibilidad de teclado integradas. Pero, si no conocemos los comportamientos estándar del teclado asociados con botones, enlaces o entradas, podemos crear experiencias confusas para los usuarios del teclado sin darnos cuenta.

"Si no conocemos los comportamientos estándar del teclado asociados con botones, enlaces o entradas, podemos crear experiencias confusas para los usuarios del teclado sin darnos cuenta".

Por ejemplo, los desarrolladores a veces usan CSS para ocultar botones de radio HTML nativos a favor de imágenes más estilizadas. No es obvio que las entradas sean botones de radio detrás de escena, por lo que los usuarios del teclado pueden no darse cuenta de que deben usar las teclas de flecha, no la tecla Tabulador, para cambiar el enfoque entre las opciones relacionadas.

Para evitar este problema, debemos mostrar algo que al menos se asemeje al elemento HTML nativo para brindar indicaciones visuales a cualquier persona que quiera o necesite interactuar con él usando un teclado.

2. Cree su aplicación para que un teclado pueda hacer todo lo que un mouse puede hacer

Tenga en cuenta los elementos que no vienen con funciones de accesibilidad de teclado integradas. Los elementos de diseño, las listas, las tablas, los encabezados, los párrafos y las etiquetas HTML no semánticas no admiten métodos abreviados de teclado de forma predeterminada. Y, sin embargo, se utilizan con frecuencia para crear componentes más complejos, como pestañas, listas de arrastrar y soltar o modales.

JavaScript nos permite agregar detectores de eventos que hacen que los elementos que no son de control respondan a los clics o gestos del mouse. En React, por ejemplo, podemos usar el complemento onClick para agregar interactividad a un elemento de lista.

Cada vez que agregamos interactividad a elementos que no son de control, debemos establecer su atributo tabIndex en 0 . Esto permitirá que el elemento reciba el enfoque en el orden de enfoque correcto cuando se presiona la tecla Tabulador. También necesitamos implementar manejadores de eventos de pulsación de tecla o pulsación de tecla para registrar "clics" a través de la tecla Intro y/o la barra espaciadora (se puede hacer clic en los enlaces usando ambas, mientras que los botones solo admiten la tecla Intro).

Podemos evitar parte de este trabajo adicional utilizando controles como etiquetas de anclaje o elementos de botón en su lugar. Siempre podemos usar CSS para anular los estilos predeterminados de enlaces y botones, y hacer que el elemento interactivo abarque todo el ancho de su padre no interactivo para maximizar el área de destino.

Ya sea que usemos o no elementos de control para funciones no nativas, es posible que aún necesitemos agregar detectores de eventos para las teclas de flecha (para navegar entre pestañas en un componente de pestaña) o la tecla Escape (para cerrar una superposición) para hacer nuestro componente 100 porcentaje de teclado accesible.

Si implementamos comportamientos de teclado no estándar para un componente más complejo, es útil proporcionar instrucciones visibles que describan los controles de teclado que las personas pueden usar para interactuar con el componente.

3. Haga el trabajo adicional al anular el orden de enfoque predeterminado

El orden de enfoque es otro requisito de las WCAG que está estrechamente relacionado con la accesibilidad del teclado. Para cumplir con los criterios del Nivel A, el orden de enfoque debe ser consistente con la secuencia visual de los elementos interactivos en la página. Los usuarios de teclado deberían poder navegar a través de los elementos de control en la pantalla de arriba a abajo y en la misma dirección horizontal que su contenido de texto (de izquierda a derecha o de derecha a izquierda).

La forma más fácil de cumplir con este criterio es dejar el orden de enfoque predeterminado, que está determinado por la secuencia en la que se organizan los elementos en el marcado , tal como está. Corremos el riesgo de no cumplir con este criterio cuando introducimos discrepancias entre el orden visual de los elementos de control y la forma en que están dispuestos en el código fuente.

También te puede interesar: Creación de una navegación de migas de pan accesible con Liquid y Shopify.

Si usamos la captura de pantalla anterior como ejemplo, supongamos que queremos que la tarjeta "Actualizar etiquetas" cambie de posición con la tarjeta "Actualizar descripción" cuando se apilan para ventanas de visualización más estrechas. Si las tarjetas se representan como elementos flexibles, podríamos considerar usar la propiedad order CSS para cambiar su secuencia en un punto de interrupción específico.

Si bien la propiedad order afecta la secuencia visual de los elementos flexibles, no actualiza su disposición en el código fuente. Como resultado, cuando un usuario presiona la tecla Tab para navegar entre cada botón, el botón "Actualizar etiquetas" aún recibirá el foco antes de "Actualizar descripción", aunque se muestren en orden inverso en la pantalla. Esto hace que el enfoque se desplace inesperadamente hacia arriba y hacia abajo en la página, creando una experiencia desorientadora para el usuario.

Una forma de evitar este problema es representar dos versiones de las tarjetas en el marcado: una en el orden esperado para anchos de ventana más amplios y otra en el orden deseado para anchos de ventana más estrechos. Podemos usar la propiedad de display para alternar entre ellos en ciertos puntos de interrupción.

Si no queremos mantener dos versiones en el marcado, necesitaremos usar JavaScript para actualizar los atributos tabIndex de las tarjetas a medida que se apilan en la página. Dependiendo de la cantidad de elementos de control que estemos renderizando, este enfoque podría ser más difícil de lograr que mantener diferentes versiones de las tarjetas en el marcado.

4. Al personalizar los estados de enfoque, diseñe para los usuarios que más los necesitan

Los navegadores usan la propiedad CSS de outline para mostrar algún tipo de indicación visual de que un elemento está enfocado. Los estados de enfoque están destinados a ayudar a los usuarios a identificar qué elemento registrará los eventos del teclado mientras navegan por la página con un teclado.

Es muy común que los diseñadores y desarrolladores reemplacen los estados de enfoque predeterminados representados por los navegadores. Esto podría implicar actualizar el outline predeterminado o eliminarlo por completo y reemplazarlo con otra propiedad de CSS, como background , border , box-shadow , color o transform .

También te puede interesar: Creación de una paginación accesible con Liquid.

Sin embargo, decidimos representar estados de enfoque personalizados en nuestras aplicaciones, debemos asegurarnos de que cumplan con los siguientes requisitos de accesibilidad:

• Contraste de color suficiente: debe haber suficiente contraste entre nuestro estado de enfoque y los colores que lo rodean para que los usuarios con problemas de visión puedan realizar fácilmente un seguimiento de qué elemento está enfocado actualmente.
• Los cambios de color se combinan con otros indicadores visuales: cambiar el color del borde, la fuente o el fondo de un elemento puede no ser perceptible para los usuarios daltónicos. Debe combinarse con otros cambios visuales que no requieran que los usuarios puedan distinguir los colores. Esto también se aplica a los estados de error y desplazamiento que implican cambios de color.
• Visible en temas de alto contraste: algunas propiedades de CSS, incluidos background y box-shadow , se ignoran cuando el modo de alto contraste está habilitado en dispositivos Windows. Es posible que tampoco se registren los cambios de color, por lo que es doblemente importante confiar en indicadores adicionales que sean perceptibles para las personas que necesitan más contraste entre los colores de fondo y de primer plano.

Si bien es aceptable anular la propiedad de outline predeterminada, nunca elimine los estados de enfoque predeterminados sin proporcionar un reemplazo.

5. Proporcione atajos para usuarios de teclado

Si alguien usa un mouse para navegar por una página web, puede desplazarse por el contenido del encabezado extraño cuando se carga la página para llegar a la información que está buscando. El proceso no es tan sencillo para los usuarios de teclado, que pueden necesitar tabular a través de múltiples enlaces de navegación o cualquier otro elemento de control que se encuentre antes del contenido principal de la página.

Como desarrolladores, podemos proporcionar un "enlace de salto" en la parte superior de cada página de nuestra aplicación para permitir que los usuarios del teclado pasen por alto los elementos de control que preceden al contenido principal de la página. El enlace de omisión generalmente está oculto a la vista hasta que recibe el foco. No es visible para las personas que usan un mouse para interactuar con su aplicación, pero será el primer elemento en recibir atención para aquellos que usan un teclado.

Cuando se hace clic en el enlace, el enfoque cambia al contenedor de contenido principal y los usuarios del teclado pueden comenzar a pasar de inmediato por los elementos de control principales de una página.

Saltar enlaces son más que atajos convenientes. Son un ejemplo de bloques de derivación, que deben cumplir con los estándares WCAG de nivel A.

Pruebe su aplicación con frecuencia convirtiéndose usted mismo en un usuario del teclado

Probar la accesibilidad del teclado tiene una curva de aprendizaje relativamente más baja para las personas que no están acostumbradas a usar tecnologías o dispositivos de asistencia. Todo lo que necesita es acceso a un teclado, familiaridad con los comportamientos estándar del teclado y acceso al modo de alto contraste de Windows (ya sea adquiriendo un dispositivo Windows o instalando una máquina virtual).

Aquí hay algunas preguntas para tener en cuenta mientras probamos nuestra aplicación para la accesibilidad del teclado:

• ¿Puedo usar mi teclado para interactuar con cualquier cosa que responda a los clics y gestos del mouse?
• ¿Alguien sabrá cómo interactuar con este elemento cuando reciba el foco?
• ¿El orden de enfoque coincide con la secuencia visual de los elementos interactivos en la página?
• ¿Puedo hacer un seguimiento de qué elemento está actualmente enfocado, incluso si necesito un mayor contraste entre los colores?
• ¿Puedo acceder fácilmente al contenido principal de la página?

Responder "sí" a todas estas preguntas no requiere mucho esfuerzo y puede tener efectos positivos para los usuarios en cualquier circunstancia: ya sea que tengan una discapacidad física, estén buscando formas de ahorrar tiempo o necesiten usar su computadora con una mano.

Las pruebas de accesibilidad son un componente crucial del desarrollo de aplicaciones. Específicamente, la accesibilidad del teclado es tan importante como proporcionar texto alternativo para las personas que usan lectores de pantalla o subtítulos para las personas que no pueden escuchar el contenido de audio. Al final del día, la capacidad de usar un mouse no debería ser necesaria para usar una aplicación si desea que su aplicación sea completamente accesible.