Accesibilidad para desarrolladores: Construir código inclusivo
Los desarrolladores son los arquitectos de la accesibilidad a nivel de implementación. Mientras los diseñadores establecen las bases visuales y de interacción, es el código el que en última instancia determina si un sitio web funciona con la navegación por teclado, se comunica correctamente con los lectores de pantalla y mantiene la accesibilidad en diferentes navegadores y dispositivos.
La buena noticia es que la mayoría de las buenas prácticas de accesibilidad se alinean con las buenas prácticas generales de código limpio, semántico y conforme a estándares. Escribir código accesible no consiste en añadir complejidad — consiste en escribir código correctamente desde el principio.
Primero, HTML semántico
Lo más impactante que puedes hacer por la accesibilidad es utilizar correctamente los elementos HTML semánticos. HTML5 proporciona un rico vocabulario de elementos que llevan consigo significado inherente y funcionalidades de accesibilidad. Un elemento <button> es automáticamente enfocable, activable con el teclado y anunciado como un botón por los lectores de pantalla. Un <div> con un controlador onclick no tiene ninguna de estas características sin un trabajo adicional significativo.
Utiliza <nav> para regiones de navegación, <main> para el contenido principal, <header> y <footer> para sus respectivas secciones, <section> y <article> para áreas de contenido, <h1> a <h6> para encabezados en orden jerárquico correcto, <ul> y <ol> para listas, <table> con <th> para datos tabulares, <label> con atributos for para controles de formulario, y elementos nativos <button> y <a> para controles interactivos.
Estos elementos crean un árbol de accesibilidad que las tecnologías de asistencia utilizan para presentar tu contenido a los usuarios. Cuando los usas correctamente, gran parte de la accesibilidad se gestiona automáticamente.
Estructura de encabezados
Los encabezados crean el esquema estructural de tu página. Los usuarios de lectores de pantalla navegan frecuentemente por encabezados para comprender la organización del contenido y encontrar secciones específicas. Cada página debe tener exactamente un <h1>, y los encabezados deben seguir una jerarquía lógica sin saltar niveles — un <h3> no debería seguir a un <h1> sin un <h2> entre ellos.
Nunca utilices elementos de encabezado para dar estilo visual. Si necesitas texto grande y en negrita que no es un encabezado, utiliza CSS en un elemento diferente. A la inversa, si un contenido funciona como encabezado, márcalo como tal independientemente de su presentación visual.
Accesibilidad por teclado
Toda funcionalidad debe ser operable únicamente a través de una interfaz de teclado. Esto significa que cada elemento interactivo — enlaces, botones, controles de formulario, menús, modales, deslizadores, pestañas — debe ser accesible mediante la tecla Tab (o Shift+Tab para la dirección inversa), activable con Enter o Espacio, y cerrable cuando sea apropiado.
Nunca crees trampas de teclado donde los usuarios puedan tabular hacia un elemento pero no puedan salir de él. Los diálogos modales deben atrapar el foco dentro del diálogo mientras esté abierto y devolver el foco al elemento que lo activó cuando se cierre, pero pulsar Escape siempre debe cerrar el diálogo.
Asegúrate de que el orden de foco siga una secuencia lógica que coincida con la disposición visual. El orden del DOM generalmente debe coincidir con la presentación visual. Evita utilizar valores positivos de tabindex, que anulan el orden natural de foco y crean confusión. Utiliza tabindex="0" para hacer enfocables los elementos no interactivos cuando sea necesario, y tabindex="-1" para elementos que solo deben ser enfocables programáticamente.
Idioma de la página
Establece el idioma predeterminado de cada página utilizando el atributo lang en el elemento <html>. Esto indica a los lectores de pantalla qué reglas de pronunciación utilizar. Si el idioma cambia dentro del contenido — por ejemplo, una frase en francés dentro de una página en español — marca el cambio con un atributo lang en el elemento contenedor.
Accesibilidad de formularios
Los formularios son el lugar donde los usuarios proporcionan información, y son una fuente frecuente de fallos de accesibilidad. Cada control de formulario debe tener una etiqueta asociada programáticamente, normalmente utilizando el elemento <label> con un atributo for que coincida con el id del control. Agrupa los controles relacionados utilizando <fieldset> y <legend>.
Cuando se detecten errores de entrada, identifica el campo con error y describe el error en texto. Proporciona sugerencias de corrección cuando sea posible. Para campos que aceptan formatos específicos, proporciona instrucciones claras sobre el formato esperado. Utiliza el atributo autocomplete para habilitar el autocompletado del navegador en campos comunes como nombre, correo electrónico, dirección y número de teléfono.
Los mensajes de estado que no reciben foco — como "artículo añadido al carrito" o "3 resultados encontrados" — deben anunciarse a los usuarios de lectores de pantalla a través de regiones en vivo ARIA o roles de estado.
Texto alternativo
Toda imagen no decorativa debe tener un texto alternativo significativo que describa su contenido o función. Para imágenes informativas, describe lo que transmite la imagen. Para imágenes funcionales (como un logotipo que enlaza a la página de inicio), describe la función. Para imágenes decorativas que no aportan información, utiliza un atributo alt vacío (alt="") para que los lectores de pantalla las omitan por completo.
Las imágenes complejas como gráficos, diagramas o infografías pueden necesitar descripciones más extensas proporcionadas mediante un pie de foto, texto adyacente o una descripción detallada enlazada.
WAI-ARIA
La especificación Accessible Rich Internet Applications proporciona semántica adicional para situaciones en las que el HTML nativo es insuficiente. ARIA permite comunicar roles, estados y propiedades a las tecnologías de asistencia para widgets personalizados y contenido dinámico.
Sin embargo, ARIA debe usarse con prudencia. La primera regla de ARIA es: si puedes utilizar un elemento HTML nativo que tenga la semántica y el comportamiento que necesitas, hazlo. ARIA no añade funcionalidad — solo añade semántica. Un <div role="button"> sigue necesitando JavaScript para la gestión del teclado, mientras que un <button> nativo lo gestiona automáticamente.
Utiliza roles landmark de ARIA (o sus equivalentes HTML5) para definir las regiones de la página. Utiliza aria-label y aria-labelledby para proporcionar nombres accesibles cuando el texto visible sea insuficiente. Utiliza aria-expanded, aria-selected, aria-checked y otros atributos de estado para comunicar el estado actual de los widgets interactivos. Utiliza regiones aria-live para anunciar actualizaciones de contenido dinámico.
Diseño responsive y reflujo
El contenido debe poder presentarse sin pérdida de información a 320 píxeles CSS de ancho sin requerir desplazamiento horizontal. Esto garantiza que los usuarios que amplíen al 400 % en una pantalla de escritorio estándar puedan seguir accediendo a todo el contenido. Diseña tus disposiciones para que el contenido refluya en una sola columna en anchos estrechos en lugar de requerir desplazamiento en dos dimensiones.
Skip links
Proporciona un mecanismo para que los usuarios de teclado puedan omitir bloques repetidos de contenido, como menús de navegación, y saltar directamente al contenido principal. La implementación más común es un enlace "Saltar al contenido principal" que es el primer elemento enfocable de la página y se hace visible cuando recibe el foco.
Lista de verificación de pruebas para desarrolladores
Antes de desplegar cualquier funcionalidad, verifica: toda la funcionalidad opera solo con el teclado; el orden de foco es lógico; el foco es visible en todos los elementos interactivos; todas las imágenes tienen texto alternativo apropiado; todos los controles de formulario tienen etiquetas; el idioma de la página está definido; la jerarquía de encabezados es correcta; ARIA se utiliza correctamente y solo cuando es necesario; el contenido refluye a 320px de ancho; y las actualizaciones de contenido dinámico se anuncian a los lectores de pantalla.
En esta sección
¿Es accesible tu sitio web?
Escanea tu sitio web gratis y obtén tu puntuación WCAG en minutos.
Escanea tu sitio gratis