Determinar si tu sitio web o aplicación es accesible puede parecer una tarea abrumadora. Si te acercas a la accesibilidad por primera vez, la amplitud del tema puede hacerte preguntarte por dónde empezar. Después de todo, trabajar para adaptarse a una amplia variedad de capacidades significa que hay una variedad de problemas correspondientes que se deben tener en cuenta.
En esta publicación, se analizan estos problemas en un proceso lógico y paso a paso para revisar la accesibilidad de un sitio existente.
Comienza con el teclado
Para los usuarios que no pueden usar un mouse o que deciden no hacerlo, la navegación con el teclado es el medio principal para acceder a todo lo que aparece en la pantalla. Este público incluye a usuarios con discapacidades motoras, como una lesión por esfuerzo repetitivo (LER) o parálisis, así como a usuarios de lectores de pantalla.
Para que la experiencia del teclado sea positiva, intenta tener un orden de tabulación lógico y estilos de enfoque claramente discernibles.
Para comenzar, usa la tecla Tab para desplazarte por tu sitio. El orden en el que se enfocan los elementos debe seguir el orden del DOM. Si no sabes qué elementos deben recibir el enfoque, consulta el módulo del curso Learn Accessibility sobre el enfoque. La práctica recomendada es que cualquier control con el que un usuario pueda interactuar o proporcionar entradas debe poder enfocarse y mostrar un indicador de enfoque (como un anillo de enfoque).
Los controles interactivos personalizados deben ser enfocables. Si usas JavaScript para convertir un
<div>en un menú desplegable elegante, no se insertará automáticamente en el orden de tabulación. Para que un control personalizado pueda enfocarse, agrégale untabindex="0". Los valores detabindexsuperiores a 0 cambian el orden de tabulación y pueden ser confusos para los usuarios de lectores de pantalla.Haz que solo el contenido interactivo sea enfocable. Agregar
tabindexa elementos no interactivos, como los encabezados, ralentiza a los usuarios del teclado que pueden ver la pantalla y no ayuda a los usuarios de lectores de pantalla porque el lector de pantalla ya sabe que debe anunciarlos.Si agregas contenido nuevo a una página, dirige la atención del usuario a ese contenido primero para que pueda realizar acciones en él. Consulta Cómo administrar el enfoque a nivel de la página para ver ejemplos.
Diseña tu sitio de modo que el usuario siempre pueda enfocar el siguiente elemento cuando así lo desee. Ten cuidado con los widgets de autocompletado y otros contextos que puedan atrapar el enfoque del teclado. Puedes atrapar el enfoque temporalmente cuando quieras que el usuario interactúe con un elemento modal y no con el resto de la página, pero siempre debes proporcionar una forma accesible para el teclado para escapar del elemento modal. Consulta Ventanas modales y trampas del teclado para ver un ejemplo.
Cómo hacer que tu control de enfoque sea utilizable
Si compilaste un control personalizado, permite que los usuarios accedan a todas sus funciones solo con el teclado. Lee Cómo administrar el enfoque en los componentes para conocer las técnicas que te permitirán mejorar el acceso del teclado.
Cómo administrar el contenido fuera de la pantalla
Muchos sitios tienen contenido fuera de pantalla que está presente en el DOM, pero que no está visible, como vínculos dentro de un menú de panel lateral responsivo o un botón dentro de una ventana modal que todavía no se muestra. Si dejas esos elementos en el DOM, la experiencia con teclado puede ser confusa, en especial para los lectores de pantalla, ya que anunciarán el contenido fuera de pantalla como si fuese parte de la página.
Consulta Cómo controlar el contenido fuera de pantalla para obtener sugerencias relacionadas con esos elementos.
Prueba con un lector de pantalla
Mejorar la compatibilidad general con el teclado sienta las bases para el siguiente paso, que es verificar la página en busca de etiquetado y semántica adecuados, y cualquier obstrucción para la navegación del lector de pantalla.
Si no conoces cómo la tecnología de accesibilidad interpreta el marcado semántico, lee Estructura del contenido.
- Verifica que todas las imágenes tengan el texto
altcorrecto. La excepción a esta práctica es cuando las imágenes son principalmente para fines de presentación y no son elementos de contenido esenciales. Para indicar que los lectores de pantalla deben omitir una imagen, establece el valor en una cadena vacía:alt="". - Verifica si hay una etiqueta en todos los controles. En el caso de los controles personalizados, es posible que se requiera el uso de
aria-labeloaria-labelledby. Consulta Etiquetas y relaciones de ARIA para ver ejemplos. - Verifica todos los controles personalizados para ver si tienen un
roleadecuado y los atributos ARIA necesarios que comuniquen su estado. Por ejemplo, una casilla de verificación personalizada necesita unrole="checkbox"y unaria-checked="true|false"para transmitir correctamente su estado. Consulta Introducción a ARIA para obtener una descripción general de cómo ARIA puede proporcionar la semántica faltante para los controles personalizados. - Haz que el flujo de información de tu página tenga sentido. Debido a que los lectores de pantalla navegan por la página en orden DOM, anunciarán todos los elementos que hayas reubicado visualmente con CSS en un orden sin sentido. Si necesitas que algo aparezca antes en la página, muévelo físicamente antes en el DOM.
- Intenta admitir la navegación del lector de pantalla para todo el contenido de la página. Asegúrate de que ninguna sección del sitio esté oculta o bloqueada de forma permanente para el acceso de los lectores de pantalla.
- Si el contenido debe ocultarse de un lector de pantalla, por ejemplo, si está fuera de la pantalla o solo es de presentación, configúralo como
aria-hidden="true". Para obtener una explicación más detallada, consulta Cómo ocultar contenido.
- Si el contenido debe ocultarse de un lector de pantalla, por ejemplo, si está fuera de la pantalla o solo es de presentación, configúralo como
Familiarízate con los lectores de pantalla
Si bien aprender a usar un lector de pantalla puede parecer abrumador, en realidad es fácil de usar. En general, la mayoría de los desarrolladores pueden desenvolverse con algunos comandos clave simples.
Si usas una Mac, mira este video sobre VoiceOver, el lector de pantalla que viene con Mac OS. Si usas una PC, mira este video sobre NVDA, un lector de pantalla de código abierto para Windows financiado con donaciones.
aria-hidden no evita el enfoque del teclado.
Es importante comprender que ARIA solo puede afectar la semántica de un elemento; no tiene efecto en el comportamiento del elemento. Puedes ocultar un elemento para los lectores de pantalla con aria-hidden="true", pero eso no cambia el comportamiento de enfoque de ese elemento. En el caso del contenido interactivo fuera de la pantalla, usa el atributo inert para asegurarte de que se quite realmente del flujo del teclado. Para navegadores más antiguos, combina aria-hidden="true" con tabindex="-1".
Los elementos interactivos deben indicar su propósito y estado.
Proporcionar sugerencias visuales, o indicadores visuales, sobre lo que hará un control ayuda a una gran variedad de personas que usan una gran variedad de dispositivos a operar y navegar por tu sitio.
- Los elementos interactivos, como los vínculos y los botones, deben distinguirse de los elementos no interactivos. Es difícil para los usuarios navegar por un sitio o una app cuando no pueden saber si se puede hacer clic en un elemento. Existen muchas formas válidas de indicar elementos interactivos. Una práctica común es subrayar los vínculos para diferenciarlos del texto que los rodea.
- Al igual que el requisito de enfoque, los elementos interactivos, como los vínculos y los botones, requieren un estado
hoverpara indicarles a los usuarios del mouse cuándo su puntero está sobre algo en lo que se puede hacer clic. Sin embargo, para que otros métodos de entrada puedan acceder a estos elementos, deben poder distinguirse sin un estadohover.
Aprovecha los encabezados y los puntos de referencia
Los encabezados y los elementos de referencia le proporcionan a tu página una estructura semántica y aumentan en gran medida la eficiencia de navegación de los usuarios de tecnología de accesibilidad. Muchos usuarios de lectores de pantalla informan que, cuando llegan por primera vez a una página que no conocen, suelen intentar navegar por los encabezados.
De manera similar, los lectores de pantalla también ofrecen la posibilidad de saltar a puntos de referencia importantes, como <main> y <nav>. Por estos motivos, es importante considerar cómo se puede usar la estructura de tu página para guiar la experiencia del usuario.
- Usa la jerarquía
h1-h6. Piensa en los encabezados como herramientas para crear un esquema para tu página. No dependas del diseño integrado de los encabezados. En su lugar, trátalos como si todos fueran del mismo tamaño y usa el nivel semánticamente adecuado para el contenido principal, secundario y terciario. Luego, usa CSS para que los encabezados coincidan con tu diseño. - Usa elementos y roles de punto de referencia para que los usuarios puedan omitir el contenido repetitivo. Muchas tecnologías de accesibilidad proporcionan atajos para saltar a partes específicas de la página, como las que definen los elementos
<main>o<nav>. Estos elementos tienen roles de punto de referencia implícitos. También puedes usar el atributorolede ARIA para definir regiones de la página de forma explícita, como en<div role="search">. Consulta Semántica y navegación de contenido para ver más ejemplos. - Evita
role="application", a menos que tengas experiencia trabajando con él. El rol de punto de referenciaapplicationle indica a la tecnología de accesibilidad que inhabilite sus combinaciones de teclas y que pase todas las pulsaciones de teclas a la página. Esto significa que las teclas que suelen usar los usuarios de lectores de pantalla para moverse por la página ya no funcionan, y deberás implementar todo el control del teclado por tu cuenta.
Cómo revisar los encabezados y los puntos de referencia con un lector de pantalla
Los lectores de pantalla, como VoiceOver y NVDA, proporcionan un menú contextual para omitir regiones importantes de la página. Cuando realices pruebas de accesibilidad, puedes usar estos menús para obtener una descripción general de la página y determinar si los niveles de encabezado son adecuados y qué puntos de referencia se están usando.
Para obtener más información, consulta estos videos instructivos sobre los aspectos básicos de VoiceOver y NVDA.
Automatiza el proceso
Probar manualmente la accesibilidad de un sitio puede ser tedioso y propenso a errores. Es beneficioso automatizar las pruebas tanto como sea posible. Puedes usar extensiones del navegador y pruebas de accesibilidad de la línea de comandos.
- ¿La página aprueba todas las pruebas de las extensiones de navegadores
aXe
o WAVE? Hay otras opciones disponibles, pero estas extensiones pueden ser una adición útil a cualquier proceso de prueba manual, ya que pueden detectar problemas sutiles, como proporciones de contraste deficientes y atributos ARIA faltantes.
- Si prefieres trabajar en la línea de comandos, axe-cli proporciona las mismas funciones que la extensión del navegador aXe, pero se puede ejecutar desde la terminal.
- Para evitar regresiones, especialmente en un entorno de integración continua, incorpora una biblioteca como axe-core en tu suite de pruebas automatizadas. axe-core es el mismo motor que potencia la extensión de Chrome de aXe, pero en una utilidad de línea de comandos.
- Si usas un framework o una biblioteca, ¿proporcionan sus propias herramientas de accesibilidad? Por ejemplo, protractor-accessibility-plugin para Angular. Aprovecha las herramientas disponibles siempre que sea posible.
Usa Lighthouse para probar AWP
Lighthouse es una herramienta que mide el rendimiento de tu app web progresiva (AWP). Además, usa la biblioteca axe-core para potenciar sus pruebas de accesibilidad.
Si ya usas Lighthouse, busca pruebas de accesibilidad que fallan en tu informe. Corrige los errores para mejorar la experiencia general del usuario en tu sitio.