Elegir recorridos
Incluya entrada, navegación, formulario, confirmación y error. Pruebe móvil y zoom elevado.
GUÍA / PROTOCOLO
Auditar la accesibilidad de un recorrido web
La accesibilidad se evalúa en una tarea completa: encontrar, comprender, actuar y recuperarse de un error.
Respuesta directa
¿Cómo realizar una auditoría de accesibilidad útil?
Seleccione recorridos y estados críticos. Combine inspección del código, navegación por teclado y tecnologías de apoyo. Vincule cada defecto con una tarea bloqueada, un requisito WCAG, pruebas y una nueva comprobación.
01 / Método de control
Método de control
Usar el teclado
Revise orden y visibilidad del foco, controles, menús, diálogos y salida de componentes. Detecte bloqueos.
Comprobar el significado
Revise títulos, nombres accesibles, etiquetas, alternativas de imágenes, estructura, contraste y avisos de error con lector de pantalla.
Priorizar y repetir
Clasifique por tarea y gravedad, corrija componentes compartidos y repita el recorrido y otras páginas afectadas.
EN LA PRÁCTICA
Verificar un recorrido, no solo una captura
Una pantalla legible puede bloquear acciones. Pruebe un objetivo completo: localizar sección, usar control, comprender resultado y volver. Registre el primer obstáculo y su efecto.
¿Qué comprobar primero?
Elija la situación observada. Cada opción indica un primer control, la prueba útil y su límite.
Funciona con ratón, pero no con teclado
- Primer control
- Repita una tarea con Tab, Mayús+Tab, Intro y las teclas esperadas del componente. Siga el foco y compruebe cómo entra y sale de menús o diálogos.
- Prueba que conservar
- Paso, tecla, control activo, estado abierto o cerrado y punto exacto de bloqueo o confusión.
- Límite que recordar
- Un orden de foco lógico no certifica toda la accesibilidad. Revise también nombres, estados anunciados y lectura del contenido.
Un formulario rechaza datos sin explicar el motivo
- Primer control
- Provoque un error y revise etiqueta, formato esperado y mensaje asociado. Compruebe que pueda corregirse sin perder los demás valores útiles.
- Prueba que conservar
- Campo, valor de prueba no sensible, mensaje, relación con el campo, foco y resultado corregido.
- Límite que recordar
- Un mensaje visible puede no estar asociado al campo ni anunciarse a tiempo. Pruebe también envío, confirmación e indisponibilidad.
El texto desborda o cuesta leerlo
- Primer control
- Reduzca la anchura, amplíe el texto y repita la tarea. Identifique qué componente obliga a desplazar toda la página horizontalmente y sepárelo de una tabla que necesita dos dimensiones.
- Prueba que conservar
- Anchura, zoom, idioma, componente, texto oculto y necesidad real de desplazamiento en dos direcciones.
- Límite que recordar
- Una captura móvil no cubre todos los zooms, idiomas y estados. La excepción de una tabla no justifica desbordar toda la página.
Para ampliar
| Situación | Evitar | Corrección útil |
|---|---|---|
| Navegación | Probar solo con ratón. | Recorrer con teclado y mantener foco visible. |
| Formulario | Depender del texto provisional del campo. | Mantener etiqueta visible y relacionar error y campo. |
| Resultado dinámico | Cambiar una cifra sin contexto. | Mostrar resultado, unidad y cambio realizado. |
Localizar
¿El título describe la tarea?
Actuar
¿El control es accesible y comprensible?
Comprender
¿Son explícitos resultado y siguiente acción?
Control final
Repita el recorrido con Tab, Mayús+Tab y Entrar, y después con zoom al 200 %. Compruebe que el encabezado fijo no oculta por completo el control enfocado. Abra y cierre el menú con el teclado, provoque un error de formulario y compruebe que puede corregirlo. Anote página, acción y obstáculo; estas pruebas no son una certificación WCAG.
Referencias documentales
Consultado el .
Taller de lectura
Probar el ciclo completo de un diálogo modal
El caso ficticio DEMO-A23 observa apertura, estado desactivado, fondo y cierre de un diálogo de revisión.
Datos y registros ficticios para aprender: ninguno de estos resultados procede de una consulta en directo.
Confirmar una elección después de leer
El diálogo contiene título, casilla «lectura terminada», Confirmar inicialmente desactivado y Cancelar. El activador sigue presente tras cerrar.
Abrir con teclado
- Observación del caso
- El foco llega al título por leer
- Qué establece
- La tarea empieza dentro, no detrás.
- Acción siguiente
- Comprobar nombre anunciado y lectura de instrucciones.
Recorrer el estado inicial
- Observación del caso
- Tab alcanza casilla y Cancelar; Confirmar desactivado
- Qué establece
- La acción no disponible no debe ejecutarse.
- Acción siguiente
- Marcar con teclado, verificar Confirmar y repetir recorrido.
Probar el fondo
- Observación del caso
- La página sigue visible pero inactiva
- Qué establece
- El fondo no recibe acción ni foco durante la modalidad.
- Acción siguiente
- Probar Tab/Shift+Tab y un destino detrás; oscurecer no basta.
Cerrar sin confirmar
- Observación del caso
- Escape cierra y devuelve foco al activador
- Qué establece
- La persona retoma su tarea inicial.
- Acción siguiente
- Repetir también Cancelar y reapertura.
Probar el ciclo de foco en un diálogo modal
Al abrir, el foco llega al título. Tab alcanza la casilla; Confirmar sigue desactivado hasta marcarla. El comando del fondo debe permanecer inactivo mientras el diálogo esté abierto. Escape o Cancelar devuelve el foco a Abrir.
La demostración interactiva no está disponible en esta configuración; el caso detallado sigue siendo legible.
Demostración preparada: no se envían datos.
Este ejemplo usa un diálogo modal nativo. Ilustra una tarea y no evalúa la accesibilidad de su sitio. La casilla no es una autorización ni una protección del servidor.
¿Basta aria-modal para aceptar el componente?
Abra cada propuesta para comparar su diagnóstico. Pueden seguir siendo necesarios otros controles.
Sí, aporta todo el comportamiento.
No: deben comprobarse acciones y ciclo del foco.
Sí, si el fondo está oscuro.
No: la apariencia no demuestra inactividad.
No; probar el ciclo con la casilla marcada y sin marcar.
Adecuado. Conservar defectos y condiciones; un componente correcto no certifica el sitio.
Registro de la tarea con teclado
Caso: DEMO-A23 Apertura: foco en el título Estado inicial: casilla vacía; Confirmar desactivado Recorrido: casilla y Cancelar; retorno interior Tras marcar: Confirmar disponible Fondo: ninguna acción ni fuga de foco esperada Escape: cierre y regreso al activador
Conserve teclas, estados, nombre anunciado y foco antes/después del cierre. Repita con las tecnologías de apoyo incluidas realmente en el alcance.
Documentación de las reglas, separada de los ejemplos ficticios
02 / Pruebas que conservar
Pruebas que conservar
Escenario y entorno
URL, dispositivo, navegador, tecnología de apoyo, zoom y acción intentada.
Reproducción
Pasos exactos, captura o DOM y resultados observado y esperado.
Criterio e impacto
Criterio WCAG, personas o tareas afectadas y gravedad razonada.
Nueva prueba
Corrección, versión, fecha y resultado con teclado y lector.
Comparar otras situaciones y ejercicios
PUNTO DE CONTROL
Antes de concluir
Una interpretación errónea frecuente y la comprobación que ayuda a evitarla.
Conclusión precipitada
Una buena puntuación automática no garantiza un recorrido utilizable; comprensión, foco y anuncios de error requieren revisión humana.
Comprobación decisiva
Completar tareas clave con teclado y tecnología de asistencia, registrar el bloqueo y vincular cada corrección a un criterio verificable.
TRAS LA REVISIÓN
Decidir según el hallazgo
El menú se ve pero no funciona con teclado
Detenga la aprobación, corrija el componente común y pruebe apertura, navegación y cierre en sus páginas.
Pasa el control automático pero la instrucción no se entiende
Conserve el resultado, documente la tarea fallida y reescriba la instrucción antes de repetir la prueba.
Decisión y trazabilidad
Decisión y trazabilidad
Qué debe permitir decidir la comprobación y qué conservar para revisar esa decisión.
Prueba suficiente
Recorra con teclado tareas, errores y estados dinámicos; anote URL, elemento, tecnología de apoyo y resultado esperado. La puntuación automática no basta.
Siguiente decisión
Priorice bloqueos del recorrido. Corrija el componente común y pruebe la tarea completa en móvil e idiomas afectados.
Casos de control detallados
Situaciones tipo para preparar un control. No describen misiones realizadas ni observaciones reales.
Una tabla legible visualmente pierde sus encabezados
Qué examinar
Compruebe las asociaciones entre celdas y encabezados, la lectura lineal y la navegación con teclado. Una presentación visual correcta no demuestra que cada valor sea comprensible mediante otra forma de lectura.
Decisión y acción
Corrija estructura y etiquetas y repita una tarea concreta de consulta. Distinga el resultado del analizador automático del recorrido realmente realizado.
Prueba que conservar
Conserve la tabla, las celdas afectadas, el modo de lectura y la secuencia para localizar un valor.
El foco desaparece bajo una franja fija
Qué examinar
Recorra enlaces, abra y cierre menús y cambie el tamaño de ventana. Observe dónde queda el foco, si su destino es visible y si el cierre devuelve el control al elemento que abrió el menú.
Decisión y acción
Ajuste posición, desplazamiento o restitución del foco. Repita todo el recorrido, incluso tras un error de formulario, sin limitarse a la primera pulsación del tabulador.
Prueba que conservar
Anote tamaño de ventana, teclas utilizadas, componente y posiciones del foco antes y después de corregir.
Se pierde el foco tras interactuar
Qué examinar
Usar filtro, menú y formulario con teclado y revisar el foco tras cambios.
Decisión y acción
Hacer accesible el siguiente paso y comprensible el resultado.
Prueba que conservar
Secuencia de teclado, estado, foco y corrección.
Revisión antes de decidir
Estas preguntas completan el método. Ayudan a determinar lo respaldado sin eliminar las reservas del registro.
Tarea con teclado
¿Se completa la tarea con teclado sin trampas, con foco visible y sin controles ocultos por zonas fijas? Conserve recorrido y navegador probados.
Ver una decisión comentada
Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.
- Observación ficticia
- El botón recibe foco con teclado pero queda totalmente oculto tras la cabecera fija.
- Estado declarado
- Discrepancia observada
- Decisión y próximo control
- Corrija posición o desplazamiento y repita todo el recorrido. No basta con que el foco exista en el DOM.
Errores comprensibles
¿Tienen los campos nombres explícitos y explican los errores cómo continuar? Complete pruebas automáticas con zoom y lector de pantalla en los recorridos elegidos.
Ver una decisión comentada
Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.
- Observación ficticia
- Un campo inválido se vuelve rojo; el mensaje no identifica el campo ni explica la corrección.
- Estado declarado
- Discrepancia observada
- Decisión y próximo control
- Añada un error textual vinculado al campo y pruebe la recuperación con teclado y lector de pantalla.
Lectura con zoom
¿Siguen siendo utilizables etiquetas, tablas y acciones con zoom? Examinar relaciones entre encabezados y celdas, además del desbordamiento.
Documentación consultada : W3C · WCAG 2.2 ·
Ver una decisión comentada
Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.
- Observación ficticia
- En la tabla probada con zoom, cada valor conserva sus cabeceras de fila y columna; la zona se maneja con teclado.
- Estado declarado
- Verificado en este alcance
- Decisión y próximo control
- Conserve navegador, zoom y tabla probada. El éxito no evalúa otras tablas ni todo el sitio.
HERRAMIENTAS / REGISTROS
Información que registrar
Repita la tarea con teclado y tecnología de asistencia. Registre elemento, criterio y obstáculo concretos; una herramienta automática no demuestra por sí sola la conformidad.
- Fecha de consulta y zona horaria
- URL exacta
- Tarea / etapa del recorrido
- Dispositivo / navegador
- Criterio de validación
- Resultado observado
- Decisión / próxima acción
- Responsable del control
- Próximo control
03 / FAQ
Preguntas frecuentes
¿Basta una herramienta automática?
No. Detecta ciertos errores de código, pero no siempre el orden lógico o la realización de una tarea.
¿Qué probar primero?
Componentes comunes y recorridos esenciales como navegación, búsqueda, solicitud o contacto.
¿Hay que probar cada idioma?
Sí en las pantallas clave: idioma declarado, etiquetas, errores y orden de lectura varían.
¿Cuándo cerrar un fallo?
Cuando el escenario original funciona con los modos de acceso pertinentes sin romper otros estados.
¿Puede una interfaz sin error automática permanecer bloqueada?
Sí sí. Los controles automáticos detectan ciertos defectos, pero la ejecución de las interacciones sigue siendo necesaria para observar obstáculos de navegación, comprensión o validación.
04 / Referencias oficiales
Referencias oficiales
Describir un contexto
Del objetivo a una intervención definida
Algunas intervenciones pertinentes para este tema. Cada importe cubre el alcance de referencia indicado; el presupuesto confirma prioridades y tareas que se solapan.
Diagnóstico de accesibilidad
Teclado, formularios, contraste y lectura; plan de corrección.
Plantillas : 3 · 6 h
Desde 480 € sin IVA / 576 € IVA incl.
Preparación y criterios de entrega
- Qué preparar
- Páginas y componentes representativos, tareas y referencia de evaluación acordada.
- Proceso propuesto
- Definir tareas, observar obstáculos y repetir los mismos controles tras los cambios.
- Entrega que acordar
- Hallazgos reproducibles, criterios revisados y límites del diagnóstico; sin certificación implícita.
- Control de este servicio
- Repetir los controles de teclado acordados y documentar elementos, criterios y límites examinados.
- Límites del alcance
- Una muestra de páginas o tareas no permite concluir sobre todos los usos del sitio.
Alcance orientativo que se confirma en el presupuesto.
Correcciones móviles y adaptables
Desbordamientos, componentes e interacciones táctiles.
Plantillas : 3 · 4 h
Desde 320 € sin IVA / 384 € IVA incl.
Preparación y criterios de entrega
- Qué preparar
- Componentes afectados, anchos objetivo, textos largos e idiomas utilizados.
- Proceso propuesto
- Definir tareas, observar obstáculos y repetir los mismos controles tras los cambios.
- Entrega que acordar
- Correcciones de diseño, zoom e interacción en las dimensiones acordadas.
- Control de este servicio
- Comprobar anchos acordados, textos largos y ausencia de desbordamiento en las páginas incluidas.
- Límites del alcance
- Una muestra de páginas o tareas no permite concluir sobre todos los usos del sitio.
Alcance orientativo que se confirma en el presupuesto.
CTA y conversión de formularios
Propuesta, etiquetas, errores y confirmación.
Recorridos : 1 · 4 h
Desde 320 € sin IVA / 384 € IVA incl.
Preparación y criterios de entrega
- Qué preparar
- Acción esperada, campos actuales, errores frecuentes y criterio de cualificación de solicitudes.
- Proceso propuesto
- Definir tareas, observar obstáculos y repetir los mismos controles tras los cambios.
- Entrega que acordar
- Etiquetas, errores y confirmación revisados, con recorrido de comprobación.
- Control de este servicio
- Probar una solicitud válida y un error, y comprobar las instrucciones y confirmación mostradas.
- Límites del alcance
- Una muestra de páginas o tareas no permite concluir sobre todos los usos del sitio.
Alcance orientativo que se confirma en el presupuesto.
Preparar y validar un servicio
Estas pautas permiten definir la solicitud y revisar la entrega. El presupuesto fija el trabajo acordado, los volúmenes y el calendario.
SXO, UX, accesibilidad y rendimiento
Reducir obstáculos en un recorrido útil, especialmente en móvil y con teclado.
- Qué preparar
- Facilitar los recorridos prioritarios, los dispositivos previstos y los errores observados.
- Proceso propuesto
- Definir tareas, observar obstáculos y repetir los mismos controles tras los cambios.
- Entrega que acordar
- Acordar un registro de obstáculos, su contexto y las correcciones verificadas.
- Límites del alcance
- Una muestra de páginas o tareas no permite concluir sobre todos los usos del sitio.
Comprobación de aceptación
Incluya errores, confirmaciones, menús y banners fijos en la prueba de teclado. Documente foco oculto y excepciones de tamaño; medir el icono no basta.
Ver alcance y tarifasREFERENCIAS DOCUMENTADAS
WCAG 2.2: distinguir tamaño de objetivo, foco y nivel
Indique versión WCAG y nivel antes de evaluar un recorrido. 24 y 44 son píxeles CSS, no píxeles físicos. Estas comprobaciones no establecen por sí solas la conformidad global.
| Referencia | Valor o forma | Qué identifica |
|---|---|---|
| 2.5.8 | AA · 24 × 24 CSS px | Tamaño mínimo AA, con excepciones por separación, control equivalente, enlaces en texto, controles nativos sin modificar y presentación esencial. |
| 2.5.5 | AAA · 44 × 44 CSS px | Criterio reforzado AAA con excepciones propias; 44 × 44 no es la obligación general del nivel AA. |
| 2.4.11 | AA | El componente con foco de teclado no debe quedar totalmente oculto por contenido del autor, como un banner fijo. |
| 2.4.12 | AAA | El criterio reforzado exige que ninguna parte del componente con foco quede oculta por contenido del autor. |
| 2.5.7 | AA | Las funciones de arrastre necesitan una alternativa de puntero sin arrastrar, salvo función esencial o control nativo sin modificar. |
| 3.3.7 | A | En un mismo proceso debe poder reutilizarse o seleccionarse información ya introducida, con excepciones por seguridad, invalidez o necesidad. |
Qué conservar en el expediente
Mida el área interactiva, no solo el icono. Documente excepciones y pruebe estados abiertos, errores y confirmaciones con teclado. Una herramienta automática no evalúa todos los obstáculos del foco ni procesos completos.
Documentación primaria
- W3C · WCAG 2.2 Recommendation, 12 December 2024
- W3C WAI · Target Size (Minimum)
- W3C WAI · Focus Not Obscured (Minimum)
Documentación consultada el .
REFERENCIAS DOCUMENTADAS
Campo de formulario: separar etiqueta, ayuda, restricción y error
Para un código postal, 00123 puede ser una cadena que conservar en vez de una cantidad que sumar. El control se elige por el significado esperado. La tabla ofrece comprobaciones separadas; ningún atributo aislado acredita la validez de una solicitud ni la conformidad de todo el recorrido.
| Referencia | Valor o forma | Qué identifica |
|---|---|---|
| label[for] / id | association | Asocie la etiqueta visible al control: for debe apuntar a su id, único en el documento. name nombra los datos enviados, pero no crea esa asociación. |
| placeholder / aria-describedby | instructions | El placeholder desaparece al introducir un valor. Mantenga las instrucciones necesarias en texto persistente; aria-describedby puede vincularlo al control. |
| type / inputmode | semantics / keyboard | inputmode sugiere un modo de entrada sin imponer por sí solo una sintaxis. type=number sirve para cantidades, no para todo identificador formado por cifras. |
| pattern | whole value | En un campo de texto apropiado, pattern restringe el valor completo. Un campo opcional vacío no se vuelve obligatorio por tener pattern. |
| required / aria-required | constraint / state | required exige un valor en controles aplicables. aria-required anuncia un estado; no crea por sí solo el bloqueo nativo del envío. |
| aria-invalid / error text | state / explanation | Tras detectar un problema, aria-invalid puede exponer su estado. Añada texto que identifique el campo y explique el problema; un borde rojo no basta. |
| WCAG 3.3.1 / 3.3.3 | identification / suggestion | Sugerir una corrección es distinto de identificar el error. Hágalo cuando se conozca y no comprometa la seguridad ni la finalidad del contenido. |
| client / server | two checks | La validación del navegador ayuda, pero se puede eludir. El servidor debe validar los datos y aplicar sus reglas de negocio. |
Qué conservar en el expediente
00123 es una cadena de ejemplo, no una dirección verificada. No aplique un formato nacional a todos los países. Las comprobaciones automáticas deben complementarse con teclado, tecnologías de asistencia y pruebas de error y recuperación.
Documentación primaria
- W3C WAI · Labelling controls
- W3C WAI · User notifications
- WHATWG · input types and attributes
- WHATWG · inputmode
- WHATWG · Client-side validation security
- W3C · WCAG 3.3.3
Documentación consultada el .
REFERENCIAS DOCUMENTADAS
Contraste del texto: comparar el cociente antes de redondear
Dos colores distintos pueden ser difíciles de distinguir. WCAG 2.2 compara sus luminancias relativas tras linealizar los componentes sRGB. La herramienta calcula el cociente de dos colores opacos; no toma muestras de una fotografía.
| Referencia | Valor o forma | Qué identifica |
|---|---|---|
| ratio | (Lmax + 0.05) / (Lmin + 0.05) | La luminancia más clara ocupa el numerador. Intercambiar texto y fondo no cambia el resultado. |
| WCAG 1.4.3 · AA | 4.5:1 | El umbral AA para texto normal es 4,5:1 donde se aplica el criterio 1.4.3. |
| WCAG 1.4.3 · AA · large | 3:1 | El umbral AA del texto grande es 3:1. La definición incluye 18 puntos o 14 puntos en negrita, con precisiones sobre las fuentes. |
| WCAG 1.4.6 · AAA | 7:1 / 4.5:1 | El criterio reforzado 1.4.6 fija 7:1 para texto normal y 4,5:1 para texto grande dentro de su ámbito. |
| 4.499:1 | < 4.5:1 | Un cociente inferior a 4,5 no alcanza el umbral porque se muestre redondeado como 4,50. La comparación debe preceder al redondeo. |
Calcular contraste sRGB
Dos códigos opacos #RRGGBB. El cociente se muestra con cuatro decimales; los umbrales usan el valor sin redondear.
Dos colores válidos: umbrales comparados.
- Cociente
- 21.0000:1
- AA · texto normal · 4,5:1
- Umbral alcanzado
- AA · texto grande · 3:1
- Umbral alcanzado
- AAA · texto normal · 7:1
- Umbral alcanzado
- AAA · texto grande · 4,5:1
- Umbral alcanzado
s = component / 255 linear = s ≤ 0.04045 ? s / 12.92 : ((s + 0.055) / 1.055)^2.4 L = 0.2126 × R + 0.7152 × G + 0.0722 × B ratio = (max(L1, L2) + 0.05) / (min(L1, L2) + 0.05)
Qué conservar en el expediente
Solo se admiten colores sRGB opacos #RRGGBB, sin transparencia, degradados, imágenes de fondo u otros espacios. No se evalúan excepciones, todas las parejas del sitio ni la conformidad WCAG completa. Para texto sobre fotografías, examine las zonas situadas tras las letras y los distintos encuadres.
Documentación primaria
Documentación consultada el .
PROFUNDIZACIÓN / PRÁCTICA
Examinar los obstáculos de un recorrido de usuario
Un usuario puede leer una página pero no alcanzar su acción principal. El examen debe basarse en navegación, comprensión e interacción, en varias condiciones de uso.
Actualizado el .
Comprobaciones prioritarias
Revisar los elementos en la tecla, comprobar los títulos y observar los mensajes de validación. Controlar la visibilidad del foco, el orden de lectura y el acceso a la información necesaria.
Errores de interpretación
Un control automático no cubre toda la experiencia. Una interfaz visualmente clara puede permanecer difícil de usar con una tecla o tecnología de asistencia.
Documento de trabajo que conservar
Un informe de obstáculos combina el camino, la condición de uso, la etapa bloqueada y la prueba. La corrección debe ser revisada en la condición que permitió identificar el problema.