Creación de páginas web accesibles

Una página accesible permite obtener información y completar tareas con las herramientas que cada persona usa. Estas herramientas pueden incluir un teclado, un lector de pantalla, una lupa o control por voz. Una página puede parecer terminada mientras su código sigue impidiendo que estas personas la usen.

Qué reciben las tecnologías de apoyo

El navegador lee el HTML y construye el DOM, su modelo del documento. A partir de él deriva un árbol de accesibilidad que describe los objetos significativos a las tecnologías de apoyo. Un control necesita un rol, un nombre y los estados o propiedades pertinentes. Por ejemplo, una casilla de verificación puede tener el rol «casilla de verificación», el nombre «Ofertas por correo» y el estado «marcada».

Un lector de pantalla lee el contenido en voz alta o lo envía a una línea braille. NVDA y JAWS funcionan en Windows; Narrator está integrado en Windows, VoiceOver en macOS e iOS y TalkBack en Android. Los lectores de pantalla pueden navegar por encabezados, enlaces y controles sin leer cada línea. Algunos también pueden comunicar los ajustes de fuente o color. Las lupas muestran la página visual ampliada, por lo que la claridad visual también importa.

El control por voz permite decir el nombre de un control, por ejemplo, «haz clic en Buscar». Los dispositivos de pulsadores pueden enviar comandos similares a los del teclado. Por tanto, la compatibilidad con teclado y los nombres precisos ayudan a varios grupos de usuarios, no solo a quienes escuchan la lectura.

Empieza con el elemento adecuado

Compara estas dos formas de crear un control para guardar:

<button type="button">Save</button>
<div class="btn" onclick="save()">Save</div>

El botón ya expone su rol y su nombre. Recibe el foco con Tab y responde a Intro y Espacio. CSS puede hacer que la segunda línea parezca idéntica, pero un div no tiene ninguno de esos comportamientos de botón. Un lector de pantalla puede activar su controlador de clic en modo de lectura, pero no anuncia el elemento como botón. Una persona que navega con Tab no puede llegar a él.

El HTML semántico consiste en elegir un elemento por lo que significa el contenido o el control. Usa CSS para controlar su aspecto. Esto proporciona al navegador un punto de partida sólido y evita tener que reconstruir el comportamiento nativo con scripts.

Conoce el objetivo

El W3C publica las Pautas de Accesibilidad para el Contenido Web, o WCAG. Sus criterios de conformidad son requisitos comprobables, cada uno identificado por un número, un nombre y un nivel. Por ejemplo, 1.4.3 Contraste (mínimo) es de nivel AA. WCAG 2.2 se convirtió en recomendación en octubre de 2023 y se actualizó en diciembre de 2024.

La conformidad con el nivel AA exige todos los criterios de nivel A y de nivel AA. No basta con superar unas pocas comprobaciones de nivel AA. El nivel AAA añade más requisitos. WCAG 2.2 añade nueve criterios a la versión 2.1, seis de nivel A o AA, y elimina el criterio obsoleto 4.1.1 Procesamiento.

La accesibilidad también incluye texto ampliado legible, subtítulos para personas sordas o con dificultades auditivas, instrucciones claras y mensajes de error útiles. Incorporar estas funciones a la página desde el principio evita tener que sustituir HTML inadecuado una vez terminada la disposición.

Una estructura de página útil ofrece varias formas de orientarse. Un título descriptivo identifica la página, los puntos de referencia identifican sus regiones y los encabezados revelan el esquema. Estas funciones necesitan significado HTML real, incluso cuando el diseño visual ya parece claro.

Identifica la página y su idioma

Define el idioma principal en el elemento raíz, por ejemplo, <html lang="en-US">. Los lectores de pantalla lo usan para elegir las reglas de pronunciación. Marca un cambio dentro de la página en el elemento correspondiente: <span lang="fr">bon appétit</span>. Esto ayuda a cumplir 3.1.1 Idioma de la página (A) y 3.1.2 Idioma de las partes (AA).

Da a cada página un <title> único y descriptivo. «Pedir una tarta de cumpleaños – Panadería Green Leaf» es más útil en pestañas, marcadores y anuncios de lectores de pantalla que «Panadería Green Leaf – Página 4». Pon primero el tema específico para que los usuarios puedan distinguir rápidamente pestañas similares.

Divide la página en regiones

Usa <main> para el contenido principal, <nav> para la navegación y <aside> para el contenido complementario. Un <header> de página proporciona el punto de referencia banner y un <footer> de página proporciona información sobre el contenido. Los elementos de cabecera y pie anidados dentro de regiones de sección no se convierten en esos puntos de referencia de página.

Usa un solo <main> visible. Si hay dos regiones de navegación, distínguelas con nombres como <nav aria-label="Main"> y <nav aria-label="Breadcrumb">. El rol ya indica «navegación», por lo que la etiqueta puede ser breve. Un <section> o <form> solo se convierte en punto de referencia cuando tiene un nombre accesible.

Crea un esquema antes de elegir tamaños de fuente

Para la página de pedidos de la panadería, un esquema claro podría ser:

<h1>Order a birthday cake</h1>
<h2>Choose a size</h2>
<h2>Choose a flavor</h2>
<h3>Chocolate</h3>
<h3>Lemon</h3>
<h2>Pickup or delivery</h2>

Usa un h1 para el tema principal, h2 para las secciones principales y h3 para sus partes. Evita saltar niveles al descender. Elige los niveles de encabezado según la estructura y ajusta su tamaño con CSS. Un párrafo en negrita no entra en la lista de encabezados del lector de pantalla. A la inversa, envolver una introducción corriente en h2 añade una sección que el contenido no tiene.

Conserva la agrupación y el orden de lectura

Usa <ul> para elementos no ordenados, <ol> para pasos ordenados y <dl> para pares de término y descripción. Los lectores de pantalla pueden anunciar el tamaño de una lista, lo que ayuda a calcular cuánto contenido sigue. Los enlaces de navegación pueden estar en un ul dentro de nav. En Safari, quitar las viñetas con list-style: none puede impedir que VoiceOver anuncie las listas; role="list" en esa lista restablece el anuncio.

Escribe el HTML en un orden de lectura lógico. La propiedad flex order, la dirección flex invertida, la colocación en cuadrícula y el posicionamiento absoluto cambian lo que se ve sin cambiar el orden del DOM. Una fila que visualmente empieza por «Iniciar sesión», pero a la que Tab llega al final, es más difícil de seguir. Corrige el orden del código fuente antes de organizar la disposición.

Trabaja con la estructura básica de una página

El sitio de una panadería tiene un menú principal y un segundo conjunto de enlaces de migas de pan. Da nombres distintos a las regiones y mantén disponibles ambos conjuntos de enlaces:

<nav aria-label="Main">
  <ul><li><a href="/bread">Bread</a></li></ul>
</nav>
<nav aria-label="Breadcrumb">
  <ol><li><a href="/">Home</a></li></ol>
</nav>
<main>
  <h1>Order a loaf</h1>
  <h2>Choose your bread</h2>
</main>

Inspecciona la lista de puntos de referencia: Main y Breadcrumb identifican distintas finalidades de navegación, seguidas del contenido principal. Después inspecciona la lista de encabezados: debe mostrar el tema de la página y su primera sección. Estas dos listas ofrecen distintas rutas por el mismo documento; ninguna depende de los colores del menú ni del tamaño de fuente de los encabezados.

El elemento de un control indica a los usuarios qué pueden esperar. Un enlace promete un destino; un botón promete una acción. Los controles nativos y los elementos de tabla también proporcionan relaciones que serían difíciles de recrear a partir de cajas genéricas con estilos.

Elige entre navegación y acción

Un elemento de anclaje sin href no es un enlace normal que pueda recibir el foco del teclado. Un elemento de anclaje con href="#" y un controlador de clic que abre un menú anuncia navegación aunque realice una acción. Usa un botón para ese menú. Dentro de un formulario, asigna type="button" a los botones que no deban enviarlo; de lo contrario, su comportamiento predeterminado puede enviar el formulario.

Deja claros los destinos

Un lector de pantalla puede reunir los enlaces de la página en una lista. En ella es difícil distinguir enlaces repetidos que dicen «Leer más». «Más información sobre los cursos de masa madre» nombra directamente el destino. WCAG 2.4.4 Propósito de los enlaces (en contexto) (A) permite que el contexto cercano explique un enlace, pero un texto de enlace significativo también funciona cuando se escucha por sí solo.

Informa en el texto del enlace de si se descarga un archivo o se abre una pestaña nueva: «Lista de precios (PDF, 2 MB)» o «Formulario de reserva (se abre en una pestaña nueva)». Una pestaña nueva cambia el funcionamiento del botón Atrás. Usa una descripción en lugar de una URL larga sin descripción cuando sea posible.

Todos los enlaces y botones necesitan un nombre accesible. Un enlace al carrito que solo contiene una imagen necesita texto que indique su destino; una imagen sin alternativa puede dejar un enlace sin nombre o identificado por un nombre de archivo. Darle un nombre es tan necesario como elegir el rol correcto.

Conserva el comportamiento integrado

Usa casillas de verificación, botones de opción y controles select nativos. Incorporan uso con teclado y estados que se anuncian. Un control sencillo para mostrar y ocultar contenido puede usar solo HTML:

<details>
  <summary>Delivery options</summary>
  <p>We deliver within 10 km.</p>
</details>

El resumen recibe el foco del teclado y el control expone su estado abierto o cerrado. Una fila personalizada con un icono triangular necesitaría implementar esas funciones por separado.

Asocia los datos de la tabla a sus encabezados

Usa tablas para datos con relaciones entre filas y columnas. Un título da nombre al conjunto de datos; th identifica los encabezados; scope indica al navegador qué celdas describe un encabezado.

<table>
  <caption>Shop opening hours</caption>
  <tr><th scope="col">Day</th><th scope="col">Opens</th></tr>
  <tr><th scope="row">Saturday</th><td>08:00</td></tr>
</table>

Una persona que llegue a la celda de la hora puede oír el día y el encabezado de columna asociados. Una cuadrícula CSS de elementos div pierde esas relaciones integradas. Para maquetar la página, usa flexbox o cuadrículas; una tabla de maquetación puede crear una navegación por tabla engañosa donde no existe una relación real entre datos.

El texto alternativo proporciona la información útil o la función de una imagen a quien no puede verla. Decide qué aporta la imagen en esa página concreta antes de describir su aspecto. Una misma fotografía puede necesitar textos distintos en contextos diferentes.

Elige según la finalidad

Para una fotografía informativa de un producto, alt="Round sourdough loaf with a dark, cracked crust" describe lo que necesita saber un comprador. En una página sobre fallos de horneado, la característica importante podría ser una corteza quemada. Imagina que lees la página por teléfono: incluye la información que de otro modo quien escucha se perdería.

Para una imagen que solo aporta decoración, usa alt="". Una alternativa vacía indica a los lectores de pantalla que omitan la imagen. Omitir el atributo es distinto: un lector de pantalla puede anunciar un nombre de archivo como «IMG guion bajo 4032 punto jpg». Un fondo puramente decorativo también puede ponerse en CSS.

Nombra una función, no una forma

Cuando una imagen es el único contenido de un enlace o botón, su alternativa proporciona el nombre del control. Un enlace al inicio puede ser:

<a href="/">
  <img src="logo.svg" alt="Green Leaf Bakery home">
</a>

Para un botón de búsqueda, usa «Buscar», no «Lupa». El usuario necesita saber qué hará el control al pulsarlo. Si un enlace de producto ya contiene las palabras visibles «Pan de centeno», una foto en ese mismo enlace puede usar alt="" para que el nombre del enlace no se repita.

Trata el texto y los gráficos complejos

Una imagen de texto necesita las mismas palabras en su alternativa. Una imagen promocional que dice «Rebajas de verano: 20 % de descuento en todo el pan» necesita esas palabras, no «Imagen de rebajas». Prefiere texto HTML real con estilos CSS cuando sea posible. Puede cambiar de tamaño, traducirse y redistribuirse; WCAG 1.4.5 Imágenes de texto (AA) exige texto real cuando la tecnología lo permite, con excepciones como los logotipos.

Un gráfico, diagrama o mapa suele contener demasiada información para una alternativa breve. Dale una identificación breve y después proporciona una descripción más completa cerca. Por ejemplo, alt="Bar chart of monthly website visitors, January to June" identifica el gráfico. El texto cercano puede explicar que las visitas aumentaron de 1200 a 3000, mientras que una tabla de datos proporciona los valores individuales cuando se necesitan. Un <figure> con <figcaption> puede agrupar el gráfico y su explicación.

Revisa los detalles útiles

Mantén el texto alternativo habitual en una frase u oración concisa. Los lectores de pantalla ya identifican una imagen, por lo que empezar con «Imagen de» normalmente no añade contenido útil. Elimina las palabras repetidas del texto adyacente y las palabras clave de búsqueda que no ayudan a comprender la página.

WCAG 1.1.1 Contenido no textual (A) exige una finalidad equivalente, no una descripción de cada detalle visible. El atributo title no es un sustituto fiable: no siempre se anuncia ni está disponible al usar teclado o interacción táctil. Pon la alternativa de una imagen en alt y mantén cualquier explicación más larga en la propia página.

Un icono, un diagrama y un vídeo necesitan distintos tipos de alternativas. Empieza por identificar la información o la acción que aporta cada uno. Después coloca el equivalente donde tanto el navegador como la persona que usa la página puedan encontrarlo.

Da nombre al control que contiene el icono

El texto visible junto a un icono suele ser lo más claro. Si un botón debe contener solo un icono, proporciona texto oculto visualmente o una etiqueta en el botón:

<button type="button" aria-label="Close">✕</button>

Cuando un icono esté junto al texto visible de un botón, oculta el icono decorativo con aria-hidden="true". No ocultes todo el botón. Un span o div simple tiene un rol genérico al que está prohibido asignar un nombre; poner ahí aria-label no es una forma fiable de dar nombre a un icono.

El texto oculto visualmente sigue estando disponible para los lectores de pantalla. Una clase CSS reutilizable puede usar posicionamiento absoluto, un ancho y alto de 1 px, desbordamiento oculto, clip-path: inset(50%) y white-space: nowrap. A diferencia de display: none o visibility: hidden, mantiene el texto en el árbol de accesibilidad.

Para un SVG en línea que transmite significado, usa role="img" y un nombre, por ejemplo, aria-labelledby="rating-title", que hace referencia a <title id="rating-title">Rated 4 out of 5 stars</title> dentro de él. Un SVG decorativo usa aria-hidden="true". Un SVG cargado mediante img obtiene su alternativa de alt, como otras imágenes. Mantén las advertencias significativas en HTML; los fondos CSS y el contenido generado no son lugares fiables para información esencial.

Elige la alternativa adecuada para el contenido multimedia

Los subtítulos para personas sordas sincronizan con el vídeo el habla, los sonidos importantes y la identificación de los hablantes. Los subtítulos transcriben o traducen el diálogo para personas que pueden oír pero necesitan ayuda para entender el idioma. Una transcripción es un relato textual independiente; no sigue el tiempo de reproducción.

<video controls src="bread.mp4">
  <track kind="captions" src="bread-en.vtt"
         srclang="en" label="English">
</video>

El archivo WebVTT contiene señales de texto temporizadas, como 00:00:01.000 --> 00:00:04.000, seguidas del texto del subtítulo. Comprueba los nombres, las palabras técnicas y la puntuación de los subtítulos automáticos antes de publicar.

Si una demostración muestra en silencio un ajuste del horno, los subtítulos del habla no lo transmiten. La audiodescripción narra la información visual importante en las pausas o en una versión audiodescrita. Una alternativa textual completa que incluya la información visual es una opción en el nivel A; el vídeo pregrabado necesita audiodescripción en el nivel AA según 1.2.5.

Mantén utilizable la reproducción

Usa controls nativo en audio y vídeo, y da a los marcos insertados un title descriptivo, como «Mapa de la ubicación de nuestra tienda». Evita el sonido que se reproduce automáticamente. El audio que empieza automáticamente y dura más de 3 segundos necesita controles para pausarlo, detenerlo o ajustar su volumen independientemente del volumen general del sistema.

Asocia el nombre oculto y el texto temporizado

Para un botón compacto de eliminación, mantén sus palabras en el documento:

<button type="button">
  <img src="trash.svg" alt="">
  <span class="visually-hidden">Delete item</span>
</button>

La imagen se omite porque el texto ya indica la acción. Aplica la clase de ocultación sin eliminar ese texto del árbol de accesibilidad:

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
}

En cambio, un archivo de subtítulos asocia las palabras al tiempo de reproducción. Un breve ejemplo de WebVTT es:

WEBVTT

00:00:01.000 --> 00:00:03.000
[Mixer whirring]

00:00:03.000 --> 00:00:06.000
Today we bake rye bread.

La primera señal transmite un sonido relevante sin diálogo. La segunda transmite el habla durante su propio intervalo. Mira el vídeo con la pista activada y comprueba que cada señal aparece cuando se produce su sonido.

Quienes usan el teclado necesitan un recorrido para toda la tarea: llegar a un control, reconocerlo, usarlo y continuar. Los controles HTML estándar ya permiten este recorrido. Los problemas suelen aparecer cuando los estilos o los controles personalizados interfieren con el comportamiento del navegador.

Usa las teclas esperadas

Tab avanza por los elementos interactivos; Mayús+Tab retrocede. Intro sigue enlaces y activa botones. Espacio activa botones y cambia el estado de las casillas de verificación. En un grupo de botones de opción, Tab entra o sale del grupo y las teclas de flecha se mueven entre las opciones. Las teclas de flecha también funcionan en los controles de selección nativos. Escape cierra cuadros de diálogo y muchos menús.

Los enlaces con href, los botones, los campos de entrada, los controles de selección, las áreas de texto, los resúmenes y los elementos multimedia con controles pueden recibir el foco de forma predeterminada. Los párrafos, encabezados, imágenes, contenedores genéricos y elementos de anclaje sin href no son paradas normales de Tab. Un lector de pantalla tiene comandos de lectura independientes para el texto, por lo que añadir cada encabezado a la secuencia de Tab ralentiza la navegación con teclado.

En macOS, activa la navegación con teclado para hacer pruebas. La opción «Pulsar Tab para resaltar cada elemento de una página web» de Safari controla si la navegación normal con Tab llega a los enlaces; Opción+Tab puede llegar a ellos cuando esa opción está desactivada.

Mantén sencillos los valores de tabindex

Los valores positivos son difíciles de mantener porque crean un segundo sistema de ordenación. Escribe el HTML en un orden lógico y evítalos. Un encabezado que deba recibir el foco después de una actualización puede usar -1 sin convertirse en una parada cada vez que se recorre la página.

Comprueba juntos el significado y el comportamiento

<div role="button" tabindex="0">Save</div>

Esto expone un rol de botón y recibe el foco, pero sigue necesitando un script para Intro y Espacio, una acción y un estilo de foco visible. Sustituirlo por <button type="button">Save</button> proporciona activación nativa con teclado sin tener que reconstruirla. ARIA por sí solo no puede crear la interacción.

CSS también puede alterar la navegación. Si el orden del código fuente es logotipo, menú, búsqueda y enlace de inicio de sesión, order: -1 de CSS puede mostrar el inicio de sesión primero mientras Tab sigue llegando a él al final. Mueve el contenido en el HTML cuando sea necesario cambiar el orden de lectura. WCAG 2.4.3 Orden del foco (A) exige un orden que preserve el significado y la capacidad de uso.

Elimina las trampas y las paradas ocultas

Comprueba si el foco puede salir de todos los componentes mediante el teclado. Un mapa o reproductor que acepta el foco pero no ofrece una salida con teclado crea una trampa de teclado, prohibida por 2.1.2 Sin trampas de teclado (A).

Un menú cerrado desplazado fuera de la pantalla o al que se ha aplicado opacity: 0 puede seguir conteniendo enlaces que reciben el foco. Usa hidden, display: none o inert para el contenido que no debe estar disponible mientras está cerrado. Sin embargo, permite que un enlace de salto fuera de la pantalla reciba el foco: tiene una regla intencionada que lo hace visible al recibirlo.

El foco es la posición actual de quien usa el teclado. Un anillo visible indica qué control activará Intro o Espacio. El anillo debe seguir siendo visible frente a la página y el control con foco debe permanecer a la vista.

Mantén un indicador claro

Los navegadores proporcionan un contorno de foco predeterminado. Eliminarlo con outline: none hace perder una indicación esencial, salvo que se proporcione un sustituto adecuado. Usa :focus-visible para mostrar un anillo cuando el navegador considere que es útil, incluida la navegación con teclado y los campos de texto:

:focus-visible {
  outline: 3px solid #1A73E8;
  outline-offset: 2px;
}

El azul tiene un contraste de 4,51:1 frente al blanco. Comprueba los colores adyacentes reales del diseño; un anillo que funciona sobre blanco puede confundirse con un panel azul. WCAG 2.4.7 Foco visible (AA) exige un foco de teclado visible, mientras que 1.4.11 Contraste no textual (AA) se aplica a la información visual que identifica un estado personalizado, incluido un indicador de foco personalizado, con una relación de 3:1.

Un contorno es una opción útil para los temas de contraste de Windows. Los colores forzados pueden sustituir los fondos y eliminar las sombras de caja, mientras que los contornos siguen disponibles. Por tanto, una sombra por sí sola puede desaparecer en un modo del que depende una persona.

Mantén a la vista el control con foco

Las cabeceras adhesivas, los avisos y los controles de chat pueden cubrir el foco. Según 2.4.11 Foco no oculto (mínimo) (AA), el contenido creado por el autor no debe ocultar completamente el componente con foco. Mantener visible todo el componente facilita su uso; el requisito de que ninguna parte quede oculta pertenece al nivel AAA.

Para una cabecera adhesiva de 5 rem de alto, deja espacio de desplazamiento:

html { scroll-padding-top: 5rem; }

Después recorre la página real con Tab. Comprueba ambas direcciones y prueba cuando haya un aviso de cookies. La regla CSS es un punto de partida; debe funcionar con la cabecera y los tamaños del área de visualización reales de la página.

Da también espacio a quienes usan el puntero

Tamaño del área de activación (mínimo), 2.5.8 (AA), exige áreas de activación del puntero de al menos 24 por 24 px CSS, con excepciones. Un área menor puede cumplir si un círculo de 24 px de diámetro centrado en ella no se cruza con otra área de activación ni con el círculo de otra área pequeña. También están exentos los enlaces dentro de una frase, los controles cuyo tamaño predeterminado del navegador no se ha modificado y las áreas que tienen un control equivalente que cumple el criterio en la página. Una presentación esencial o exigida por ley también puede estar exenta.

En el caso de tres botones con iconos de 16 por 16 px separados por espacios de 4 px, los círculos se solaparían. Añadir 4 px de relleno en todos los lados hace que cada área de activación mida 24 por 24 px. Mide toda el área sobre la que se puede hacer clic, no solo el icono dibujado dentro de ella.

El área de activación de 44 por 44 px CSS del criterio 2.5.5 y el requisito de tamaño del área de foco del criterio 2.4.13 son requisitos AAA. Son mejoras útiles, pero mantén su nivel separado del mínimo AA al comunicar un hallazgo.

Los menús repetidos no deberían obligar a las personas a repetir el mismo recorrido en cada página. Un enlace de salto proporciona una ruta corta al contenido principal. Cuando una interacción cambia la página, gestionar el foco de forma intencionada también ayuda a mantener el lugar.

Crea y prueba un enlace de salto

Coloca el enlace de salto antes de los controles repetidos de la cabecera:

<a class="skip-link" href="#main">Skip to main content</a>
<main id="main" tabindex="-1">
  <h1>Order a birthday cake</h1>
</main>

El enlace apunta a la región principal, y tabindex="-1" ayuda a que esa región reciba el foco sin añadir una parada normal de Tab. La navegación por puntos de referencia ayuda a quienes usan lectores de pantalla; el enlace de salto también ayuda a quienes usan el teclado y ven la pantalla a evitar bloques repetidos, según 2.4.1 Evitar bloques (A).

Mantén el enlace disponible para el teclado cuando esté oculto visualmente:

.skip-link { position: absolute; left: -9999px; }
.skip-link:focus { left: 1rem; top: 1rem; }

No uses display: none ni visibility: hidden, que impiden que reciba el foco. Vuelve a cargar la página, pulsa Tab una vez y comprueba que aparece el enlace. Pulsa Intro y luego Tab de nuevo: la navegación debe continuar en el primer enlace o control del contenido principal, no en el menú de la cabecera.

Elige una posición siguiente lógica cuando cambie el contenido

Si una fila del carrito y su botón Eliminar con foco desaparecen juntos, el foco puede volver al principio de la página. Muévelo de forma intencionada al botón Eliminar del siguiente artículo o a un encabezado del carrito que tenga tabindex="-1". Elige un lugar que permita continuar la tarea. Desplazarse hasta una región no garantiza por sí solo que el foco del teclado se haya movido allí.

Usa un cuadro de diálogo modal nativo

Un cuadro de diálogo abierto con showModal() mueve el foco a su interior y vuelve inerte el resto de la página. Tab permanece dentro mientras el cuadro está abierto; Escape lo cierra. Al cerrarse, el foco normalmente vuelve al elemento que lo abrió, si este sigue existiendo.

<button type="button"
  onclick="document.getElementById('hours').showModal()">Opening hours</button>
<dialog id="hours" aria-labelledby="hours-title">
  <h2 id="hours-title">Opening hours</h2>
  <p>Tuesday to Saturday, 08:00–17:00.</p>
  <form method="dialog"><button>Close</button></form>
</dialog>

El script de una línea encuentra el cuadro de diálogo por su ID y lo abre de forma modal. El formulario del cuadro lo cierra sin otro script. Su encabezado proporciona su nombre. Una capa superpuesta hecha a mano necesita que se recreen todas estas reglas de interacción; oscurecer el fondo no impide que el foco del teclado llegue a él.

Espera una acción intencionada

Recibir el foco no debe abrir una página nueva ni cambiar el contexto de otro modo. Cambiar una selección tampoco debe hacerlo de forma inesperada; se debe avisar a los usuarios de antemano si ocurre ese comportamiento. Un botón «Ir» después de un selector de destino da tiempo para revisar y cambiar la selección antes de navegar. Estos comportamientos ayudan a cumplir 3.2.1 Al recibir el foco (A) y 3.2.2 Al recibir entradas (A).

El contraste mide con qué claridad destaca la información de primer plano frente a su fondo. Un color que parece legible en una pantalla puede resultar difícil de ver para una persona con baja visión o bajo una luz intensa. Mide la pareja de colores en lugar de evaluarla a simple vista.

Aplica el mínimo correcto

El texto grande tiene al menos 18 puntos, equivalentes a 24 px CSS, o al menos 14 puntos en negrita, unos 18,7 px CSS en negrita. Un encabezado de 20 px con grosor normal sigue necesitando 4,5:1. El texto de marcador de posición, del pie de página y de los estados de puntero encima y de foco no está exento del contraste de texto. Hay excepciones para logotipos, controles inactivos y texto incidental o puramente decorativo.

Comprende la relación

La luminancia relativa expresa la luminosidad en una escala de 0 para el negro a 1 para el blanco. Con la luminancia más clara como L1 y la más oscura como L2, la relación es:

Los extremos son 1:1 para colores idénticos y 21:1 para negro frente a blanco. Una herramienta de comprobación de contraste calcula la luminancia a partir de los canales de color y compara la relación con el umbral correspondiente.

Para el gris #767676, cada canal es el valor hexadecimal 76, o 118. Divide entre 255 para obtener aproximadamente 0,4627. Como está por encima de 0,04045, conviértelo a luz lineal:

Los tres canales son iguales, por lo que su luminancia ponderada también es aproximadamente 0,1812. El blanco tiene una luminancia de 1. Mantener toda la precisión durante el cálculo da 4,54:1, que cumple el requisito para texto normal. Usa una herramienta para las parejas de colores reales, de modo que los valores intermedios redondeados no afecten a un resultado cercano al umbral.

Nunca redondees un fallo hasta convertirlo en un resultado conforme

El gris #777777 sobre blanco da 4,48:1. Mostrarlo con un decimal como 4,5 no hace que cumpla el requisito. Del mismo modo, #949494 sobre blanco da 3,03:1 y cumple para texto grande; #959595 da 2,99:1 y no cumple para texto grande.

El blanco sobre #0066CC da 5,57:1. Sobre el ámbar #FFC107, el texto blanco solo da 1,63:1, mientras que el negro da 12,88:1. Elegir un fondo de botón brillante no indica si su texto debe ser claro u oscuro.

Comprueba los límites y todos los fondos

Un borde de campo necesario para identificarlo debe cumplir el contraste no textual. #CCCCCC frente al blanco da 1,61:1 y no cumple; #949494 da 3,03:1 y sí cumple. La misma regla de 3:1 se aplica a iconos significativos, líneas de gráficos e indicadores de foco personalizados. Hay excepciones para controles inactivos y controles predeterminados del navegador sin modificar.

El texto sobre una fotografía o un degradado debe cumplir el requisito en el punto más débil de su fondo. Añade un panel sólido o suficientemente opaco, o mueve el texto. Comprueba los colores resultantes con las herramientas de desarrollo o una herramienta de comprobación de contraste. WCAG 1.4.3 cubre el texto y 1.4.11 cubre la información no textual; los umbrales AAA para texto son más altos: 7:1 para texto normal y 4,5:1 para texto grande.

Comprueba por separado las partes de un botón

Supongamos que un botón tiene texto blanco de tamaño normal sobre #0066CC, está en una página blanca y usa un anillo de foco personalizado #CCCCCC. Comprueba cada relación:

1. La etiqueta frente al botón azul da 5,57:1, por encima del mínimo de 4,5:1 para texto.
2. El botón azul frente a la página blanca también da 5,57:1, por lo que su límite se distingue.
3. El anillo de foco gris claro frente a la página blanca solo da 1,61:1. Ese indicador de estado no cumple el requisito aunque la etiqueta sí lo cumpla.

Sustituye el anillo por un color que alcance 3:1 frente a su fondo adyacente y vuelve a medir. Una medición de la etiqueta del botón no mide también todos los límites o estados de interacción. Comprueba el texto, el componente y el estado personalizado como parejas de colores separadas.

El color puede llamar la atención, pero no puede ser la única pista visible de significado. Las personas pueden tener una deficiencia de la visión del color, usar escala de grises o ajustes de contraste, o escuchar el contenido mediante un lector de pantalla que no anuncia los colores. Combina el color con texto, formas, patrones u otra indicación clara.

Separa dos comprobaciones

El contraste pregunta si un primer plano se distingue de su fondo. El uso del color, WCAG 1.4.1 (A), pregunta si la información sigue siendo comprensible sin reconocer el color. Una etiqueta de color rojo oscuro sobre blanco podría cumplir el contraste y aun así no explicar qué campo tiene un error.

Empieza por el mensaje. Si la página dice «Elige una opción verde», da también a cada opción un nombre útil. Si un punto rojo significa que una tienda está cerrada, añade «Cerrado ahora» a su lado. El texto transmite el estado, mientras que el color ayuda a que se vea.

Mantén reconocibles los enlaces

La forma más sencilla de identificar un enlace en un párrafo es el subrayado. Ofrece una indicación incluso cuando el enlace y el texto que lo rodea se ven en escala de grises.

Una diferencia basada solo en el color respecto al texto circundante necesita al menos 3:1 de contraste entre los dos colores de texto y una indicación adicional, como un subrayado, al situar el puntero encima y al recibir el foco. El texto del enlace también debe cumplir el contraste de texto frente a su fondo. Son comparaciones distintas; un azul que cumple frente al blanco puede ser demasiado parecido al texto oscuro del párrafo que lo rodea.

Explica los errores y los campos obligatorios

Para un error de correo electrónico, muestra «Error: introduce una dirección de correo electrónico con el formato nombre@ejemplo.com» junto al campo. Un contorno rojo puede permanecer como indicación adicional. El texto identifica el problema e indica al usuario cómo corregirlo, mientras que el código lo asocia al campo.

Para los campos obligatorios, usa una etiqueta como «Dirección de correo electrónico (obligatorio)». Un asterisco también funciona cuando al principio del formulario se explica que «* significa obligatorio». Añade el atributo nativo required para que el requisito esté disponible para las tecnologías de apoyo y la validación del navegador. El texto rojo de una etiqueta por sí solo no proporciona una explicación visual adecuada ni un requisito expresado en el código.

Da a los gráficos una segunda forma de comunicar

Un gráfico de ventas con dos series necesita algo más que una línea roja y una verde. Las etiquetas directas, los distintos estilos de línea o los patrones permiten seguir cada serie sin identificar su color. Usa estas indicaciones tanto en el gráfico como en su leyenda para que coincidan.

Comprueba la página con la emulación de escala de grises o de visión del color en las herramientas de desarrollo. Inspecciona los enlaces dentro del texto, los errores, los campos obligatorios, los gráficos y los indicadores de disponibilidad. Pregúntate qué pista visible queda para cada distinción. Si una distinción desaparece, añade una indicación que exprese o represente su significado; aumentar solo la saturación no proporcionará la información que falta.

Ampliar una página debería facilitar su uso sin ocultar controles ni cortar frases. Las personas pueden aplicar zoom a toda la página, ampliar solo el texto o aplicar su propio espaciado. Las disposiciones flexibles permiten que estas opciones funcionen juntas.

Prueba el tamaño del texto y la redistribución

WCAG 1.4.4 Cambio de tamaño del texto (AA) exige que el texto se amplíe hasta el 200 % sin pérdida de contenido ni funcionalidad. El zoom del navegador usa Ctrl y más en Windows o Cmd y más en macOS. Prueba también un tamaño de fuente predeterminado mayor, que cambia el texto sin ampliar todo lo demás de la misma forma.

WCAG 1.4.10 Redistribución del contenido (AA) exige que el contenido ordinario funcione con un ancho de 320 px CSS sin desplazamiento en dos direcciones. Una ventana de 1280 px CSS de ancho con un zoom del 400 % proporciona ese ancho efectivo. Los párrafos deben ajustarse en una columna estrecha, con todas las funciones disponibles. Hay excepciones para tablas de datos, mapas y otros contenidos cuyo significado necesita dos dimensiones.

Deja que la disposición crezca con el texto

Usa unidades de fuente relativas como rem y em para que el texto siga el ajuste de fuente predeterminado del usuario. El texto en píxeles CSS sigue respondiendo al zoom del navegador, pero no sigue ese ajuste predeterminado de la misma manera. Los contenedores flexibles y max-width permiten que las líneas se ajusten; los puntos de ruptura en em pueden adaptarse a medida que crece el texto.

Una altura fija puede cortar contenido sin que sea evidente:

/* Problem when larger text needs more space */
.card { height: 200px; overflow: hidden; }

/* Content can grow beyond the minimum */
.card { min-height: 200px; }

Deja que el contenido determine su altura. Con anchos reducidos, apila la navegación u ofrece un control accesible para mostrarla y ocultarla en lugar de eliminar enlaces. Deja que una cabecera adhesiva demasiado grande se desplace fuera de la pantalla si consume demasiado espacio de la vista utilizable.

Mantén disponible el zoom en móviles

Usa una declaración del área de visualización que siga el ancho del dispositivo:

<meta name="viewport" content="width=device-width, initial-scale=1">

No añadas maximum-scale=1 ni user-scalable=no. Intentan bloquear el zoom mediante el gesto de pellizco, que las personas con baja visión pueden necesitar. Algunos navegadores ignoran esas restricciones, pero los usuarios no deberían tener que depender de ese comportamiento.

Aplica el espaciado del usuario

WCAG 1.4.12 Espaciado del texto (AA) exige que no haya pérdida de contenido ni solapamientos cuando los usuarios establecen la altura de línea en 1,5 veces el tamaño de fuente, el espaciado entre párrafos en 2 veces, el espaciado entre letras en 0,12 veces y el espaciado entre palabras en 0,16 veces. Son ajustes de prueba, no valores de diseño predeterminados obligatorios. Usa una herramienta de espaciado del texto y comprueba etiquetas, tarjetas, menús y botones, además de los párrafos.

Una comprobación práctica combina una prueba de texto al 200 %, una prueba de redistribución a 320 px CSS y la modificación del espaciado. Busca líneas cortadas, etiquetas solapadas, desplazamiento horizontal de párrafos y funciones que hayan desaparecido. Corrige el contenedor o la disposición que causa el problema; reducir el texto que el usuario ha ampliado elimina el beneficio que buscaba.

Una etiqueta visible indica qué debe introducir una persona y da al campo un nombre accesible. Las etiquetas de grupo añaden la pregunta a la que responden varias opciones. Las asociaciones deben existir en el HTML, incluso cuando las etiquetas y los campos ya aparecen cerca unos de otros.

Asocia una etiqueta a un control

Una etiqueta explícita usa for para hacer referencia al id único del control:

<label for="email">Email address</label>
<input id="email" name="email" type="email">

El navegador puede anunciar «Email address» cuando el campo recibe el foco. Hacer clic en el texto también da el foco al campo, lo que proporciona a los usuarios un área de activación mayor. El atributo name identifica los datos enviados; no sustituye al id que usa la etiqueta.

Una etiqueta implícita envuelve su campo de entrada: <label>Email address <input type="email" name="email"></label>. Esto funciona cuando ambos caben dentro del mismo elemento de etiqueta. Con contenedores de disposición separados, la asociación explícita es más fácil de mantener.

Un texto de marcador de posición desaparece al escribir y suele tener poco contraste. Mantén visible la etiqueta y coloca cerca los ejemplos o las indicaciones de formato. «Campo 1» es técnicamente un nombre, pero no describe la finalidad. WCAG 2.4.6 Encabezados y etiquetas (AA) exige una redacción descriptiva.

Conserva las palabras visibles en el nombre

Una persona que usa control por voz puede decir «haz clic en Enviar» después de ver un botón Enviar. Si aria-label="Submit form" prevalece sobre el texto de ese botón, su nombre accesible deja de contener las palabras visibles. WCAG 2.5.3 Etiqueta en el nombre (A) exige que se incluyan esas palabras, preferiblemente al principio. Usa el propio texto visible cuando sea posible: <button type="submit">Send message</button>.

Un campo de búsqueda aislado puede tener una etiqueta oculta visualmente si un botón Buscar cercano deja clara su finalidad visualmente. Las etiquetas ocultas no son un sustituto general de las instrucciones visibles en todo un formulario.

Agrupa las opciones bajo su pregunta

<fieldset>
  <legend>Delivery method</legend>
  <input type="radio" id="pickup" name="delivery" value="pickup">
  <label for="pickup">Pick up in store</label>
  <input type="radio" id="courier" name="delivery" value="courier">
  <label for="courier">Courier delivery</label>
</fieldset>

La leyenda proporciona la pregunta del grupo; cada botón de opción sigue necesitando su propia etiqueta. Los lectores de pantalla pueden anunciar el contexto del grupo junto con una opción. Usa el mismo name para opciones excluyentes y leyendas breves que sigan siendo útiles cuando se repitan. Las casillas de verificación relacionadas también pueden usar un fieldset y una legend.

Elige los tipos y comprueba las asociaciones

Usa email, tel, url y date para los datos correspondientes. Los tipos de correo electrónico y URL proporcionan una comprobación de formato; los campos de teléfono pueden ofrecer un teclado móvil adecuado, pero no validan los formatos de número de teléfono. Usa number para cantidades como el número de invitados, no para identificadores como números de teléfono o de tarjeta.

Haz clic en cada etiqueta para comprobar su asociación. Si el campo equivocado recibe el foco, busca ID duplicados o un for que no coincida. Inspecciona también el nombre calculado en las herramientas de desarrollo; la proximidad visual por sí sola no puede asociar una etiqueta.

Las instrucciones ayudan más cuando llegan antes de que se produzca un error. Un buen formulario explica qué datos se esperan, muestra qué campos son obligatorios y admite las herramientas del navegador para introducir información personal. También evita que los usuarios repitan trabajo innecesariamente.

Asocia un texto de ayuda sin sustituir la etiqueta

<label for="pw">Password (required)</label>
<input id="pw" type="password" required
       autocomplete="new-password" aria-describedby="pw-hint">
<p id="pw-hint">At least 12 characters.</p>

La etiqueta da nombre al campo. El párrafo visible explica su requisito y aria-describedby añade ese texto como descripción. Los lectores de pantalla pueden anunciarlo después del nombre. Para varias descripciones, enumera sus ID separados por espacios, como en aria-describedby="pw-hint pw-error".

Marca los campos obligatorios visualmente y con required. Puedes escribir «(obligatorio)» o explicar un asterisco al principio del formulario. El atributo nativo required permite la validación del navegador e informa a las tecnologías de apoyo; no necesita un aria-required="true" adicional.

Identifica la finalidad de los datos personales

Según 1.3.5 Identificar el propósito de la entrada (AA), los campos que recogen información del usuario necesitan identificadores de autocomplete adecuados. Algunos ejemplos son name, given-name, family-name, email, tel, street-address, postal-code, country-name y bday. Los campos de inicio de sesión pueden usar username y current-password; una contraseña nueva usa new-password y un código de verificación puede usar one-time-code.

Estos identificadores permiten que los navegadores, los gestores de contraseñas y las herramientas de apoyo reconozcan la finalidad de un campo. Usa el identificador correspondiente a la persona cuyos datos se están introduciendo. Marcar la dirección de contacto de un amigo como el correo propio del usuario para el rellenado automático puede introducir datos equivocados.

Reduce la necesidad de memorizar y volver a introducir datos

Permite pegar en los campos de contraseña y código de verificación y admite gestores de contraseñas. WCAG 3.3.8 Autenticación accesible (mínimo) (AA) permite pruebas cognitivas durante el inicio de sesión solo si se ofrece una alternativa o ayuda que cumpla el criterio, o si se aplican las excepciones especificadas de reconocimiento de objetos o contenido personal. Bloquear el pegado crea una barrera cuando obliga a recordar o transcribir datos y no existe otro método de inicio de sesión que cumpla el criterio.

En un pedido de varios pasos, conserva la información ya introducida. Una opción «La dirección de facturación es la misma que la de entrega» evita volver a escribirla. WCAG 3.3.7 Entrada redundante (A) permite excepciones cuando la repetición es esencial, necesaria por seguridad o la información anterior ya no es válida.

Proporciona una salvaguarda para envíos con consecuencias

Un pedido puede crear un compromiso financiero. Antes de completarlo, ofrece un paso de revisión que permita corregir los datos. Según 3.3.4 Prevención de errores (legales, financieros, de datos) (AA), los envíos pertinentes deben poder revertirse, comprobarse y corregirse, o revisarse y confirmarse con la posibilidad de corregirlos. El alcance también incluye cambiar o eliminar datos almacenados que controla el usuario y enviar respuestas de pruebas.

Mantén la disposición del formulario fácil de seguir cuando se amplíe: las etiquetas directamente encima de los campos y una sola columna principal reducen la distancia entre una instrucción y el lugar donde se aplica.

Distingue el formato de la finalidad de los datos personales

El tipo de entrada y el identificador de autocompletado responden a preguntas distintas. El tipo identifica la clase de valor y puede proporcionar una comprobación de formato. El identificador identifica la información personal del usuario para el rellenado automático:

<label for="your-email">Your email address (required)</label>
<input id="your-email" name="email" type="email"
       required autocomplete="email">
<label for="guest-email">Guest's email address</label>
<input id="guest-email" name="guest-email" type="email">

Ambos campos aceptan direcciones de correo electrónico, pero solo el primero pide el correo del usuario actual. El segundo no debe marcarse como el correo de ese usuario para el rellenado automático. Las etiquetas visibles mantienen la distinción para quienes introducen los valores por sí mismos. Cambiar un identificador no cambia lo que comprueba el tipo de correo electrónico.

Un mensaje de error debe ayudar a recuperarse sin perder el trabajo ya realizado. Un mensaje de estado debe comunicar un cambio sin hacer que la persona pierda su lugar. Ambos necesitan una redacción visible y la asociación correcta en el código.

Indica el problema y una corrección útil

«Entrada no válida» ayuda poco. «Error: introduce una dirección de correo electrónico con el formato nombre@ejemplo.com» identifica lo que necesita atención y sugiere una solución. WCAG 3.3.1 Identificación de errores (A) exige que los errores detectados se describan en texto; 3.3.3 Sugerencia de corrección de errores (AA) exige ofrecer las correcciones conocidas cuando no comprometan la seguridad ni la finalidad del formulario.

<label for="email">Email address</label>
<input id="email" type="email" aria-invalid="true"
       aria-describedby="email-error">
<p id="email-error">Error: Enter an email address in the format name@example.com</p>

Establece aria-invalid="true" solo después de comprobar el campo y encontrar un error. El atributo comunica el estado no válido; la descripción explica el motivo. Un borde rojo por sí solo no proporciona ni la explicación textual ni la asociación.

Ayuda a encontrar varios errores

Después del envío, un formulario largo puede mostrar un resumen de errores en la parte superior. Dale un encabezado como «Hay 2 problemas con tu pedido» y añade enlaces a los campos afectados. Permite que el resumen reciba el foco con tabindex="-1" y haz que el script se lo dé. Añadir «Error: » al principio del título de la página también ayuda a identificar el cambio de estado de la página.

Mantén también los mensajes de cada campo junto a sus entradas y conserva todo lo que ya se haya introducido. Un enlace del resumen lleva a la persona al campo; la explicación junto a él ayuda mientras lo corrige. Vaciar todos los campos obliga a repetir el trabajo ya realizado correctamente.

Los atributos de validación nativos, como required, type="email" y minlength, pueden proporcionar mensajes del navegador. Un sistema personalizado puede usar novalidate y mostrar los suyos. En ambos casos, los errores necesitan texto que los usuarios puedan localizar y asociar al campo correspondiente.

Anuncia un cambio sin mover el foco

Una actualización del carrito suele producirse mientras el foco debe permanecer en el botón Añadir. Usa una región viva que ya esté presente en el documento:

<p role="status" id="cart-status"></p>

Cuando se añade un artículo, un script cambia su texto a «Se ha añadido 1 pan de masa madre a tu carrito». role="status" es cortés: permite que el lector de pantalla termine lo que está diciendo antes de anunciar la actualización. Esto ayuda a cumplir 4.1.3 Mensajes de estado (AA).

Reserva role="alert", un anuncio asertivo, para los mensajes urgentes. Las interrupciones continuas dificultan las compras habituales. Inserta la región vacía antes de actualizar su contenido; crear la región y su mensaje a la vez no se anuncia de forma fiable en muchas combinaciones. Mantén el foco en la tarea para las actualizaciones habituales y muévelo de forma intencionada en situaciones como un resumen de errores que el usuario necesita revisar.

ARIA añade información al árbol de accesibilidad cuando HTML necesita ayuda para expresar un nombre, una relación o un estado. No crea la interacción en sí. Antes de añadir un atributo, comprueba qué proporciona ya el elemento nativo y qué falta realmente.

Trata un rol como una promesa

WAI-ARIA significa Aplicaciones de Internet Enriquecidas Accesibles. La versión 1.2 se convirtió en recomendación del W3C en junio de 2023. Sus roles, estados y propiedades influyen en lo que se comunica a las tecnologías de apoyo. Un rol como button promete un comportamiento de botón, pero no crea la capacidad de recibir el foco, la activación con teclado ni los estilos.

Un div con role="button" sigue necesitando gestión del teclado y capacidad de recibir el foco. Un button real ya las proporciona. El principio de la guía ARIA Authoring Practices Guide «es mejor no usar ARIA que usarlo mal» advierte de que la información incorrecta puede confundir a los usuarios sobre lo que hace un control.

Conserva el significado nativo

Usa primero elementos y atributos nativos: nav, button, un campo de casilla de verificación y el atributo nativo required. Evita repetir roles implícitos como role="main" en main o role="button" en button. Una excepción útil es role="list" en una lista cuyas viñetas eliminadas afectan a los anuncios de VoiceOver.

No sustituyas el significado de un encabezado por un rol de botón. Anida un botón dentro de él:

<h2>
  <button type="button" aria-expanded="false">Shipping</button>
</h2>

El encabezado sigue apareciendo en la navegación por encabezados y su botón expone la acción. El script debe hacer que el contenido mostrado y el estado expandido coincidan.

Nunca pongas aria-hidden="true" en un control que pueda recibir el foco ni en un antecesor que lo contenga. El foco podría llegar a algo eliminado del árbol de accesibilidad. role="presentation" y role="none" funcionan de otra forma: eliminan la semántica, no el contenido. Los navegadores ignoran esos roles en elementos que pueden recibir el foco, por lo que no pueden usarse para convertir un enlace activo en texto simple.

Encuentra la fuente de un nombre

Para los controles habituales de esta sección, comprueba las fuentes del nombre en este orden de prioridad:

1. aria-labelledby, que hace referencia a texto mediante un ID.
2. aria-label, que proporciona una cadena de texto.
3. La fuente nativa, como una etiqueta, el texto de un botón o el texto alternativo de una imagen.
4. title, como último recurso cuando corresponda.

aria-describedby añade una descripción después del nombre; no establece el nombre. Una sustitución puede ocultar accidentalmente palabras visibles útiles. <button aria-label="Close dialog">Cancel</button> se anuncia como «Close dialog», aunque la persona ve «Cancel». Prefiere el texto visible o inclúyelo al principio de un nombre ampliado que sea necesario.

Los sitios básicos suelen necesitar ARIA para nombres de puntos de referencia repetidos, botones con iconos, textos de ayuda y errores de campos, controles para mostrar y ocultar contenido, enlaces a la página actual y actualizaciones en vivo. Una gran cantidad de atributos ARIA no es una medida de calidad. Inspecciona el rol y el nombre calculados y usa el teclado para verificar el comportamiento que promete el rol.

Sigue las fuentes de nombre que compiten

Considera un botón con varios atributos que proporcionan un nombre:

<h2 id="options-title">Delivery options</h2>
<button type="button" aria-labelledby="options-title"
        aria-label="Choose delivery">Show pickup options</button>

Sigue primero aria-labelledby: el texto al que hace referencia proporciona «Delivery options». El aria-label de menor prioridad y el texto visible del botón no prevalecen. Por tanto, eliminar solo aria-label deja el mismo nombre calculado.

Para que «Show pickup options» dé nombre a este botón, elimina ambas sustituciones innecesarias. El rol de botón permanece igual en todo momento; solo cambia la fuente de su nombre. Inspecciona el nombre calculado después de cada edición para saber qué atributo causó la discrepancia. Añadir una descripción no corregiría el nombre equivocado, porque una descripción es una información independiente.

Una interfaz que cambia debe comunicar lo mismo visualmente y mediante el código. Si un panel está abierto pero su botón sigue indicando «contraído», quien usa un lector de pantalla recibe información falsa. Actualiza el estado cada vez que cambie la interfaz.

Mantén sincronizado un control para mostrar y ocultar contenido

<button type="button" aria-expanded="false"
        aria-controls="main-menu">Menu</button>
<ul id="main-menu" hidden>
  <li><a href="/bread">Bread</a></li>
</ul>

Cuando se abre el menú, el script elimina hidden y establece aria-expanded del botón en true. Cuando se cierra, el script restablece hidden y establece el estado en false. El estado pertenece al botón que realiza el cambio. aria-controls identifica el elemento afectado; su compatibilidad varía, por lo que no puede sustituir al estado expandido ni al comportamiento real de ocultación.

Elige el estado adecuado para el control

Para el enlace de la página actual, aplica estilos al mismo atributo en CSS, como una fuente en negrita y un borde inferior en a[aria-current="page"]. Esto mantiene el resaltado visual vinculado al estado anunciado. aria-selected corresponde a componentes como pestañas y opciones de cuadros de lista, no a enlaces normales de navegación entre páginas.

Un botón de alternancia puede mantener la etiqueta «Silenciar» y cambiar aria-pressed entre false y true. Otro diseño válido cambia la etiqueta de un botón de acción normal entre «Silenciar» y «Activar sonido» sin un estado pulsado. No combines una etiqueta de acción cambiante con el patrón de estado de alternancia, que puede producir anuncios confusos como «Activar sonido, pulsado».

Distingue entre ocultar y deshabilitar

aria-hidden="true" elimina un elemento y sus descendientes del árbol de accesibilidad, pero los deja visibles. Úsalo para iconos decorativos o contenido visual redundante. No impide el acceso con teclado. Usa hidden o display: none cuando una región deba estar indisponible para todo el mundo.

El atributo nativo disabled impide la interacción normal con un control nativo. aria-disabled="true" comunica un estado no disponible, pero no bloquea los clics ni la activación con teclado. Si ese atributo se usa para que un control deshabilitado pueda recibir el foco y ofrecer una explicación, el script debe impedir su acción. Prefiere también los atributos nativos checked y required en campos de entrada nativos.

Prueba ambas direcciones

Abre y cierra el control con el teclado mientras observas los atributos en las herramientas de desarrollo. Inspecciona el estado calculado y escucha su anuncio. Un cambio visual correcto por sí solo no demuestra que se haya actualizado el estado, y un atributo cambiado por sí solo no demuestra que el panel se haya vuelto visible o utilizable.

Las comprobaciones automáticas encuentran rápidamente muchos problemas de código en una página renderizada. Usa sus resultados para localizar barreras y verificar las correcciones. Sus reglas pueden inspeccionar algunas relaciones y valores, pero decidir si el contenido tiene sentido sigue requiriendo una persona.

Elige una herramienta e inspecciona sus hallazgos

Axe DevTools usa el motor axe-core. WAVE coloca marcadores en la página para que los hallazgos puedan verse en contexto. Lighthouse, en las herramientas de desarrollo de Chrome, da una puntuación de accesibilidad mediante una selección de comprobaciones de axe-core. Accessibility Insights proporciona otro proceso de pruebas. El servicio de validación de marcado del W3C comprueba problemas de HTML como ID duplicados y elementos sin cerrar.

Según sus reglas y el contexto, las herramientas pueden detectar atributos alt ausentes, controles sin nombre, campos sin etiqueta, bajo contraste de texto sobre fondos lisos, ausencia del idioma de la página y ARIA no válido. Algunos problemas de niveles de encabezado aparecen como advertencias. Lee la explicación del hallazgo e inspecciona el elemento que identifica.

Una alerta o un resultado de «necesita revisión» requiere juicio. Un texto en negrita señalado como posible encabezado podría ser un título de sección real escrito como párrafo o simplemente dar énfasis a una frase. Examina su finalidad antes de cambiar su marcado.

Comprende lo que el análisis no puede decidir

Una herramienta puede ver alt="photo" sin saber que la alternativa es inútil. No puede juzgar de forma fiable si el texto de un enlace es claro, los subtítulos son precisos, el orden de foco es lógico o un mensaje de error ayuda a recuperarse. Una capa visual superpuesta puede atrapar el teclado de una forma que el análisis actual no detecte. El texto sobre una fotografía también necesita una comprobación manual del contraste.

Una puntuación de 100 significa que las reglas probadas no encontraron fallos. No es un veredicto de conformidad con las WCAG. Sigue probando las tareas y los significados que esas reglas no pueden evaluar.

Prueba los estados que usan las personas

Un análisis examina el estado renderizado en ese momento. Ejecuta las comprobaciones en cada plantilla de página y repítelas con menús y cuadros de diálogo abiertos, después de errores de formulario y con anchos reducidos. Un componente cerrado puede ocultar problemas que solo aparecen durante su uso.

Supongamos que un informe de una panadería encuentra una imagen principal destacada sin alt, un campo del boletín sin etiqueta y texto de pie de página #999999 sobre blanco. Decide primero si la imagen informa o decora. Añade una alternativa útil o alt="" según corresponda. Asocia el campo de correo a una etiqueta visible. La pareja de colores del pie de página tiene un contraste de 2,85:1; sustituir el color del texto por #595959 da 7,00:1 sobre blanco.

Corrige las causas y verifica los resultados

Prioriza las barreras según su efecto en la tarea. Una trampa de teclado o un control obligatorio sin nombre pueden impedir por completo un pedido. Corrige un campo o componente de pie de página compartido en su origen para que mejoren todas las páginas que lo usan. Después vuelve a ejecutar el análisis en el mismo estado y repite la prueba manual pertinente. Una menor cantidad de errores es una prueba útil, pero la corrección también debe permitir que la persona complete la tarea.

Las pruebas manuales muestran cómo se comporta una página durante una tarea real. Combina el uso del teclado, las vistas ampliadas, las comprobaciones con lector de pantalla y la inspección directa del árbol. Registra suficiente detalle para que otra persona pueda reproducir un problema y confirmar su corrección.

Sigue una tarea con teclado de principio a fin

Deja el ratón a un lado. Empieza en la barra de direcciones y recorre la página con Tab. Llega a todos los enlaces y controles, usa Intro y Espacio cuando corresponda y retrocede con Mayús+Tab. Comprueba que el foco siga visible y no quede cubierto por una región adhesiva.

Usa el enlace de salto, abre y cierra menús, cierra un cuadro de diálogo con Escape y verifica adónde vuelve el foco. Busca paradas invisibles en componentes cerrados y trampas en reproductores o mapas insertados. En un Mac, activa la navegación con teclado y la navegación completa con Tab de Safari antes de considerar que los controles omitidos son un defecto de la página.

Amplía y redistribuye la página

Prueba con una ampliación del 200 % sin perder texto ni funcionalidad. Después usa una ventana de 1280 px CSS de ancho con un zoom del 400 %, equivalente a 320 px CSS de ancho disponible. Comprueba que los párrafos no tengan desplazamiento horizontal, solapamientos ni cortes. Mantén todas las funciones disponibles en la disposición estrecha. Aplica los valores de espaciado del texto con una herramienta e inspecciona los controles además del texto principal.

Escucha la estructura y los nombres

NVDA en Windows usa Insert como tecla NVDA predeterminada; Bloq Mayús es una alternativa opcional. En modo de lectura, H recorre los encabezados, D los puntos de referencia, K los enlaces, F los campos, T las tablas y B los botones. NVDA+F7 abre la lista de elementos. Tab sigue recorriendo los controles interactivos.

En macOS, Cmd+F5 activa o desactiva VoiceOver. Su modificador VO es Control+Opción; VO+Flecha derecha lee el siguiente elemento y VO+U abre el rotor. En iPhone, deslizar a la derecha lleva al siguiente elemento de VoiceOver. TalkBack ofrece una lectura táctil similar en Android.

Escucha si hay un título y un esquema útiles, nombres claros para los controles, roles correctos, alternativas útiles para las imágenes y etiquetas de campo comprensibles. Los estados obligatorios, los textos de ayuda y los errores deben estar disponibles en los campos correspondientes. Abre un control para mostrar y ocultar contenido y escucha el cambio de estado. Añade un artículo y escucha si se anuncia una actualización de estado sin que salte el foco.

Inspecciona, registra y vuelve a probar

El panel Accesibilidad de Chrome y el Inspector de accesibilidad de Firefox muestran los roles, nombres y estados calculados. Ayudan a averiguar por qué una etiqueta es incorrecta incluso antes de ejecutar un lector de pantalla.

Un informe útil indica la ubicación, los pasos, el comportamiento observado, los usuarios afectados, el criterio relacionado y la corrección sugerida. Por ejemplo: «Campo del boletín en el pie de página: usa Tab para llegar al campo; se anuncia sin etiqueta. Quienes usan lectores de pantalla y control por voz no pueden identificar su finalidad. Añade una etiqueta asociada de dirección de correo electrónico; comprueba 1.3.1, 3.3.2 y 4.1.2».

Vuelve a probar con el método que detectó el problema. Las combinaciones habituales incluyen NVDA con Firefox o Chrome, JAWS con Chrome y VoiceOver con Safari. Las pruebas con personas que usan tecnologías de apoyo a diario pueden revelar barreras que un desarrollador que las usa ocasionalmente pasa por alto.

Haz reproducible un fallo de estado

Un informe sobre un control para mostrar y ocultar contenido puede registrar una prueba breve y completa:

1. En la página del pan, usa NVDA con Firefox y llega con Tab a «Opciones de entrega».
2. Pulsa Intro una vez. El panel se vuelve visible, pero el botón sigue anunciándose como contraído.
3. Inspecciona el botón: aria-expanded sigue siendo false.

Se informa al usuario afectado de que el panel visible sigue cerrado. Registra 4.1.2 Nombre, función, valor (A) y sugiere actualizar el estado del botón cuando cambie el panel. Tras la corrección, repite la apertura y el cierre con las mismas teclas y la misma combinación. Comprueba que la visibilidad del panel y el estado expandido anunciado coincidan en ambas direcciones; inspeccionar solo el estado inicial contraído no detectaría este fallo.