Aprende a auditar las 12 reglas críticas de accesibilidad web: ARIA labels, contraste de color, etiquetas de formulario, landmarks HTML y touch targets. Guía técnica con criterios WCAG, ejemplos de código y checklist accionable para mejorar el SEO y la experiencia de usuario.
Resumen: La accesibilidad web no es un trámite legal ni una casilla que marcar: es el equipamiento que decide si todos los usuarios pueden recorrer tu web o si algunos se quedan tirados a mitad de ruta. Google lo sabe y lo mide: las webs accesibles tienen mejor experiencia de usuario, menores tasas de rebote y señales de calidad que impulsan el posicionamiento. Esta guía detalla las 12 reglas que debes auditar para garantizar que tu web cumple con los estándares WCAG 2.1 — desde los ARIA labels hasta los touch targets — y que ningún usuario ni ningún bot de búsqueda encuentra un camino cortado.
Solicitar auditoría SEO gratuita → Ver servicios SEO →
Hay un malentendido frecuente sobre la accesibilidad web: que es una obligación legal para grandes empresas pero irrelevante para el SEO del día a día. Es un error que frena a muchos proyectos a mitad de ascenso.
La relación entre accesibilidad y posicionamiento tiene varias capas:
Capa 1 — Las señales de experiencia de usuario. Google mide el comportamiento real de los usuarios en las SERPs y en la página: tasa de rebote, tiempo en página, porcentaje de scroll, clics en CTAs. Una web inaccesible penaliza a los usuarios con discapacidades visuales, motrices o cognitivas — y eso se traduce en señales de calidad negativas que Google incorpora a sus decisiones de ranking.
Capa 2 — La arquitectura semántica. Muchas de las prácticas de accesibilidad web son las mismas que hacen que Googlebot entienda mejor tu contenido: una jerarquía de encabezados correcta, landmarks HTML que delimitan las secciones de la página, texto alternativo en imágenes, etiquetas de formulario bien asociadas. Un bot de búsqueda y un lector de pantalla procesan el HTML de formas muy similares — ambos dependen de la semántica del marcado.
Capa 3 — Core Web Vitals e interacción. Las métricas de interactividad y estabilidad visual (INP, CLS) están directamente ligadas a prácticas de accesibilidad como los touch targets correctos, la ausencia de contenido que se desplaza inesperadamente y los tiempos de respuesta de los controles de la interfaz.
Capa 4 — El marco legal y reputacional. En España, la Ley General de derechos de las personas con discapacidad (Real Decreto Legislativo 1/2013) obliga a las webs de entidades públicas a cumplir con WCAG 2.1 nivel AA. La Directiva Europea de Accesibilidad Web (2016/2102) amplía esta obligación. Las empresas privadas que se anticipan a este requisito reducen riesgo legal y posicionan su marca como inclusiva — un diferencial cada vez más valorado.
En resumen: la accesibilidad web es SEO técnico con valor añadido. Cada regla que auditas y corriges beneficia simultáneamente a los usuarios con necesidades especiales, a los usuarios estándar y a la visibilidad de tu web en Google.
No existe un «factor de ranking de accesibilidad» documentado y aislado en el algoritmo de Google. Lo que sí existe es el impacto indirecto, que es sustancial:
Antes de entrar en las 12 reglas, necesitas conocer el estándar que las sustenta: las WCAG (Web Content Accessibility Guidelines), actualmente en versión 2.1 y con la versión 2.2 ya publicada.
Las WCAG están organizadas en cuatro principios (el acrónimo POUR):
| Principio | Descripción | Criterios clave |
|---|---|---|
| Perceptible | El contenido debe poder ser percibido por todos los sentidos | Alt text, contraste de color, captions de vídeo |
| Operable | Los controles e interfaz deben ser manejables por todos | Navegación por teclado, focus visible, touch targets |
| Understandable | El contenido y la UI deben ser comprensibles | Etiquetas de formulario, jerarquía de headings, error messages |
| Robust | El contenido debe funcionar con tecnologías asistivas | ARIA correctamente implementado, landmarks, semántica HTML |
Cada criterio WCAG tiene tres niveles de cumplimiento: A (básico, obligatorio), AA (estándar de la industria, requerido por la mayoría de normativas) y AAA (óptimo, no siempre alcanzable). El objetivo para una web comercial estándar es cumplir con el nivel AA.
Las 12 reglas de esta guía cubren los criterios WCAG 2.1 más relevantes y más frecuentemente incumplidos, que además son los que tienen mayor impacto en el SEO y en la experiencia de usuario.
El primer grupo de reglas aborda la semántica del marcado: cómo los elementos de tu página comunican su propósito a los lectores de pantalla, a los motores de búsqueda y a cualquier tecnología asistiva. Son las reglas que más se solapan con las buenas prácticas de SEO on-page.
ID de regla: a11y-aria-labels Criterio WCAG: 4.1.2 — Nombre, rol, valor (Nivel AA)
Los ARIA labels (atributos aria-label, aria-labelledby y aria-describedby) son la forma en que los elementos interactivos — botones, iconos, menús, campos — se comunican con los lectores de pantalla cuando el texto visible no es suficiente o no existe.
El problema más frecuente: iconos sin texto. Un botón que muestra solo un icono de hamburguesa para el menú móvil, o una flecha de siguiente sin texto, es incomprensible para un usuario con lector de pantalla si no tiene un aria-label que lo describa.
Ejemplo del problema:
<!-- ❌ Botón sin texto ni ARIA label — lector de pantalla dirá "botón" -->
<button>
<svg><!-- icono de hamburguesa --></svg>
</button>
<!-- ✅ Con ARIA label — lector de pantalla dirá "Abrir menú de navegación" -->
<button aria-label="Abrir menú de navegación">
<svg aria-hidden="true"><!-- icono de hamburguesa --></svg>
</button>Nota el aria-hidden="true" en el SVG: si el botón ya tiene un aria-label, el icono debe ser invisible para los lectores de pantalla para evitar duplicar la información.
Los escenarios más comunes donde falla esta regla:
aria-label o aria-labelledby que describan qué controlanrole="dialog", role="tabpanel") y labels correspondientesImpacto SEO: Los botones y controles sin ARIA labels también afectan a la accesibilidad de tus CTAs para usuarios de teclado. Un CTA inaccesible es un CTA que convierte menos.
✅ Cómo auditarlo: Herramientas como Lighthouse (en Chrome DevTools → Pestaña Audits) detectan automáticamente los elementos interactivos sin nombre accesible. También puedes usar la extensión axe DevTools o revisar manualmente con el inspector ARIA del navegador (F12 → pestaña Accessibility en Chrome).
ID de regla: a11y-link-text Criterio WCAG: 2.4.4 — Propósito del enlace en contexto (Nivel AA) / 2.4.9 — Propósito del enlace solo (Nivel AAA)
El texto de un enlace debe describir su destino o acción de forma que tenga sentido incluso fuera del contexto del párrafo que lo rodea. Los usuarios de lectores de pantalla frecuentemente navegan saltando de enlace en enlace, escuchando solo el texto de cada uno. Si tus enlaces dicen «aquí», «leer más», «click aquí» o «ver», son completamente inútiles en ese modo de navegación.
Ejemplo del problema:
<!-- ❌ Texto de enlace genérico — incomprensible fuera de contexto -->
<p>Consulta nuestra guía de SEO técnico. <a href="/seo-tecnico/">Leer más</a></p>
<!-- ✅ Texto de enlace descriptivo — comprensible por sí solo -->
<p>Consulta nuestra <a href="/seo-tecnico/">guía de SEO técnico</a></p>Más allá de la accesibilidad: el impacto SEO directo
El texto ancla de los enlaces internos es una señal explícita de relevancia temática para Google. Un enlace con el texto «leer más» no transmite ninguna información sobre el contenido al que enlaza. Un enlace con el texto «guía de robots.txt y sitemap.xml» le dice a Google exactamente de qué trata la página de destino — y refuerza el posicionamiento de esa página para esas keywords.
Esta regla es, simultáneamente, una regla de accesibilidad y una práctica de SEO de enlazado interno. Corregirla beneficia en ambas dimensiones.
Excepciones válidas: Los CTA de botones («Solicitar presupuesto», «Descargar guía gratuita») son descriptivos por su contexto visual y por el texto que incluyen. La regla aplica principalmente a los enlaces en texto corrido y a los botones con solo iconos.
✅ Cómo auditarlo: En Chrome DevTools → F12 → Console, ejecuta document.querySelectorAll('a') y revisa los textos. Herramientas como WAVE o axe marcan automáticamente los enlaces con texto genérico. En SEOmator, la regla a11y-link-text te indica cuántos enlaces tienen texto no descriptivo.
ID de regla: a11y-heading-order Criterio WCAG: 1.3.1 — Información y relaciones (Nivel A)
La jerarquía de encabezados (H1 → H2 → H3 → H4) no es solo una convención de maquetación: es la estructura semántica que permite a los usuarios de lectores de pantalla navegar por el contenido de la página saltando entre secciones, igual que un índice de contenidos.
Un orden correcto de encabezados significa: nunca saltar niveles hacia abajo (de H1 a H3 sin H2 intermedio), y no usar encabezados por su tamaño visual sino por su posición semántica en la jerarquía del contenido.
Los errores más frecuentes:
<!-- ❌ Salto de nivel — de H2 directamente a H4 -->
<h2>Servicios SEO</h2>
<h4>Auditoría técnica</h4> <!-- Falta H3 -->
<!-- ❌ Múltiples H1 — solo debe haber uno por página -->
<h1>Agencia SEO en Almería</h1>
<h1>Nuestros servicios</h1>
<!-- ✅ Jerarquía correcta -->
<h1>Agencia SEO en Almería</h1>
<h2>Nuestros servicios</h2>
<h3>Auditoría técnica SEO</h3>
<h3>Posicionamiento orgánico</h3>
<h2>Por qué elegirnos</h2>El doble impacto en SEO
La jerarquía de encabezados es uno de los factores on-page más directamente correlacionados con el posicionamiento. Google usa los encabezados para entender la estructura temática de la página y para generar featured snippets. Un H1 correcto + H2s con las keywords de la página bien estructurados contribuyen directamente al ranking.
La accesibilidad y el SEO coinciden aquí al 100%: lo que es bueno para los lectores de pantalla es exactamente lo que Google necesita para entender el contenido.
✅ Cómo auditarlo: En Chrome, instala la extensión HeadingsMap o usa WAVE para visualizar la jerarquía de headings de cualquier página. En Lighthouse (Chrome DevTools), la sección «Accessibility» marca los problemas de jerarquía de encabezados.
El segundo grupo de reglas aborda la percepción visual: que el contenido y los controles sean visibles en todas las condiciones — incluyendo baja visión, daltonismo y navegación por teclado.
ID de regla: a11y-color-contrast Criterio WCAG: 1.4.3 — Contraste mínimo (Nivel AA)
El contraste entre el color del texto y el color del fondo determina si el texto es legible para personas con baja visión, daltonismo o en condiciones de luz adversas (pantalla con sol directo, pantalla de baja calidad).
Los ratios mínimos exigidos por WCAG 2.1 nivel AA son:
| Tipo de texto | Ratio mínimo |
|---|---|
| Texto normal (< 18pt / < 14pt negrita) | 4,5:1 |
| Texto grande (≥ 18pt / ≥ 14pt negrita) | 3:1 |
| Texto decorativo o en logotipos | Sin requisito |
| Componentes de UI (iconos, bordes de input) | 3:1 |
Los colores más problemáticos en la práctica:
El gris claro sobre blanco es el offender más frecuente: muchos diseños usan texto secundario en #999999 sobre fondo blanco, que tiene un ratio de 2,85:1 — por debajo del mínimo de 4,5:1. Los tonos marca también fallan frecuentemente: un azul claro corporativo puede tener un contraste insuficiente sobre fondo blanco.
Herramienta de cálculo: El Contrast Checker de WebAIM te permite introducir dos colores y ver el ratio resultante en tiempo real.
Ejemplo de valores que pasan y fallan:
| Texto | Fondo | Ratio | ¿Pasa AA? |
|---|---|---|---|
#000000 (negro) | #FFFFFF (blanco) | 21:1 | ✅ |
#333333 | #FFFFFF | 12,63:1 | ✅ |
#767676 | #FFFFFF | 4,54:1 | ✅ (justo) |
#999999 | #FFFFFF | 2,85:1 | ❌ |
#0066CC | #FFFFFF | 5,74:1 | ✅ |
#6699CC | #FFFFFF | 2,99:1 | ❌ |
✅ Cómo auditarlo: Lighthouse detecta automáticamente los fallos de contraste en la pestaña Accessibility. La extensión axe DevTools va más allá e identifica incluso elementos con contraste insuficiente en estados hover y focus. En SEOmator, la regla a11y-color-contrast escanea la página y reporta los elementos con ratio insuficiente.
ID de regla: a11y-focus-visible Criterio WCAG: 2.4.7 — Foco visible (Nivel AA) / 2.4.11 — Apariencia del foco (Nivel AA en WCAG 2.2)
Cuando un usuario navega por tu web usando el teclado (Tab, Shift+Tab, Enter, teclas de flecha), el navegador muestra un indicador visual del elemento que está activo en ese momento — el «foco». Por defecto es el anillo azul que ves alrededor de los botones y enlaces al tabular.
El problema: muchos diseñadores y desarrolladores eliminan este indicador con outline: none o outline: 0 en el CSS porque «queda feo». El resultado es que los usuarios de teclado — personas con dificultades motrices, usuarios de tecnologías asistivas, usuarios de teclados mecánicos — pierden completamente la referencia de dónde están en la página.
/* ❌ Elimina el foco — trampa para usuarios de teclado */
:focus {
outline: none;
}
/* ✅ Foco personalizado que respeta la marca y es visible */
:focus-visible {
outline: 2px solid #005FCC;
outline-offset: 2px;
border-radius: 2px;
}La solución no es restaurar el foco por defecto (que puede no encajar con el diseño): es diseñar un indicador de foco que sea a la vez visible y acorde con la identidad visual. El pseudo-selector :focus-visible es especialmente útil porque solo muestra el foco cuando la navegación es por teclado, no cuando se hace clic con el ratón — lo que elimina el problema estético sin sacrificar la accesibilidad.
Los elementos que más frecuentemente tienen el foco eliminado:
tabindex="0" para elementos personalizados✅ Cómo auditarlo: La forma más rápida es abrir tu web en Chrome, ir a la URL y empezar a pulsar Tab. El indicador de foco debe ser visible en cada elemento interactivo. Si no ves ningún indicador o este es muy tenue, tienes un problema. Lighthouse también lo detecta en la sección Accessibility.
El tercer grupo de reglas garantiza que los datos estructurados — formularios y tablas — son comprensibles para todos los usuarios, con o sin tecnologías asistivas.
ID de regla: a11y-form-labels Criterio WCAG: 1.3.1 — Información y relaciones (Nivel A) / 3.3.2 — Etiquetas o instrucciones (Nivel A)
Un formulario accesible requiere que cada campo (<input>, <select>, <textarea>) tenga una etiqueta (<label>) programáticamente asociada al campo — no solo visualmente adyacente.
La diferencia es importante: una <label> que está cerca de un <input> visualmente no equivale a una <label> correctamente asociada. La asociación correcta se hace mediante el atributo for en la etiqueta y el id en el campo, o envolviendo el campo dentro del <label>.
Ejemplo del problema:
<!-- ❌ Label visible pero no asociada — lector de pantalla no la lee con el input -->
<label>Tu email</label>
<input type="email" name="email">
<!-- ✅ Asociación correcta con for/id -->
<label for="email-contacto">Tu email</label>
<input type="email" id="email-contacto" name="email">
<!-- ✅ Alternativa: label envolvente -->
<label>
Tu email
<input type="email" name="email">
</label>El caso del placeholder como sustituto de label
Un error muy frecuente en formularios con diseño minimalista: usar el placeholder del input como única indicación del campo, sin ninguna <label>. El problema es múltiple: el placeholder desaparece cuando el usuario empieza a escribir (confusión en formularios largos), el contraste de color del placeholder suele ser bajo, y los lectores de pantalla no siempre lo leen de forma consistente como identificador del campo.
<!-- ❌ Placeholder como único label — inaceptable para accesibilidad -->
<input type="text" placeholder="Nombre completo">
<!-- ✅ Label real + placeholder complementario -->
<label for="nombre">Nombre completo</label>
<input type="text" id="nombre" placeholder="Ej: María García">Las implicaciones para los formularios de contacto y generación de leads
Un formulario de contacto inaccesible no solo penaliza a los usuarios con lectores de pantalla: también tiene tasas de conversión más bajas porque genera fricción para todos los usuarios. Formularios bien etiquetados convierten más.
✅ Cómo auditarlo: En Chrome DevTools → F12 → Elements, selecciona un <input> y comprueba en el panel Accessibility (lateral derecho) si tiene un «Name» y un «Label» correctamente asignados. Si aparecen vacíos, el campo no tiene etiqueta asociada.
ID de regla: a11y-table-headers Criterio WCAG: 1.3.1 — Información y relaciones (Nivel A)
Las tablas de datos requieren encabezados (<th>) con el atributo scope correcto para que los lectores de pantalla puedan asociar cada celda de datos con su encabezado correspondiente. Sin esta asociación, una tabla de datos es prácticamente imposible de procesar con un lector de pantalla.
<!-- ❌ Tabla sin encabezados semánticos -->
<table>
<tr>
<td>Servicio</td>
<td>Precio</td>
<td>Plazo</td>
</tr>
<tr>
<td>Auditoría SEO</td>
<td>497€</td>
<td>5 días</td>
</tr>
</table>
<!-- ✅ Tabla con encabezados correctos -->
<table>
<thead>
<tr>
<th scope="col">Servicio</th>
<th scope="col">Precio</th>
<th scope="col">Plazo</th>
</tr>
</thead>
<tbody>
<tr>
<td>Auditoría SEO</td>
<td>497€</td>
<td>5 días</td>
</tr>
</tbody>
</table>El atributo scope es clave: scope="col" indica que el encabezado aplica a toda la columna, scope="row" indica que aplica a toda la fila. Para tablas complejas con encabezados anidados, el atributo headers en cada <td> permite asociaciones más precisas.
Tablas de presentación vs. tablas de datos
Una aclaración importante: las tablas usadas solo para maquetación (práctica desaconsejada pero que persiste en algunos CMS) deben marcarse con role="presentation" para que los lectores de pantalla no intenten interpretarlas como datos. Si usas tablas para datos reales (precios, comparativas, métricas), los encabezados son obligatorios.
✅ Cómo auditarlo: WAVE y axe marcan las tablas sin encabezados como error. En Chrome DevTools, selecciona la tabla e inspecciona si las celdas de encabezado usan <th> en lugar de <td>.
El cuarto grupo de reglas aborda la arquitectura de navegación: cómo los usuarios con tecnologías asistivas pueden moverse eficientemente por la estructura de la página sin tener que escuchar o tabular por todo el contenido desde el principio.
ID de regla: a11y-landmark-regions Criterio WCAG: 1.3.6 — Identificar el propósito (Nivel AAA) / Buenas prácticas ARIA nivel AA
Los landmark regions son los elementos HTML semánticos que delimitan las grandes secciones de una página: <header>, <nav>, <main>, <aside>, <footer>, y <section> con aria-label. Estos elementos permiten a los usuarios de lectores de pantalla saltar directamente a cualquier sección de la página con un atajo de teclado — sin tener que tabular por todo el contenido.
La estructura de landmarks recomendada para una página completa:
<body>
<header role="banner">
<nav aria-label="Navegación principal">
<!-- Menú de cabecera -->
</nav>
</header>
<main id="main-content">
<article>
<!-- Contenido principal -->
</article>
<aside aria-label="Artículos relacionados">
<!-- Contenido complementario -->
</aside>
</main>
<footer role="contentinfo">
<nav aria-label="Navegación del pie de página">
<!-- Links del footer -->
</nav>
</footer>
</body>Los errores más frecuentes:
<div> para estructurar la página sin ningún elemento semántico<nav> sin aria-label que los distinga (el usuario no sabe cuál es la navegación principal)<main> — o usarlo en múltiples lugares cuando debe ser único<main>El beneficio para el SEO
Google usa los landmarks para entender la arquitectura de la página: qué es navegación, qué es contenido principal, qué es contenido secundario. Un <main> bien delimitado le indica a Google dónde está el contenido de valor, lo que puede influir en cómo valora la calidad del contenido.
✅ Cómo auditarlo: La extensión HeadingsMap (Chrome) también muestra los landmarks de la página. En el inspector de accesibilidad de Chrome DevTools, puedes ver el árbol de accesibilidad con todos los landmarks identificados. Lighthouse y axe reportan las páginas sin landmarks principales.
ID de regla: a11y-skip-link Criterio WCAG: 2.4.1 — Evitar bloques (Nivel A)
El skip link (enlace de salto) es un enlace oculto visualmente que aparece al primer Tab en la página y permite a los usuarios de teclado saltar directamente al contenido principal, evitando tabular por todo el menú de navegación cada vez que cargan una página nueva.
Es la regla más fácil de implementar de las 12 — y la que más frecuentemente falta, incluida en nuestra propia auditoría de escala14.com (donde aparece como advertencia).
Implementación correcta:
<!-- En el <body>, antes que cualquier otro contenido -->
<a href="#main-content" class="skip-link">Saltar al contenido principal</a>
<header>
<nav><!-- Menú --></nav>
</header>
<main id="main-content">
<!-- Contenido -->
</main>/* Oculto visualmente pero visible al recibir el foco */
.skip-link {
position: absolute;
top: -40px;
left: 0;
background: #005FCC;
color: white;
padding: 8px;
text-decoration: none;
z-index: 1000;
}
.skip-link:focus {
top: 0;
}Con este patrón, el skip link es invisible para los usuarios que usan el ratón pero aparece inmediatamente al primer Tab para los usuarios de teclado. Es el comportamiento estándar que los usuarios de tecnologías asistivas esperan en cualquier web bien construida.
Por qué importa aunque tu menú sea pequeño
Incluso con un menú de 5 elementos, un usuario de teclado que visita 10 páginas de tu web debe tabular por esos 5 elementos en cada carga de página antes de llegar al contenido. Con un skip link, el primer Tab lleva directamente al contenido — una mejora significativa en la experiencia de navegación.
✅ Cómo auditarlo: Abre tu web y pulsa Tab una vez. ¿Aparece un skip link? Si no, falta. La herramienta SEOmator detecta esta regla automáticamente y la marca como advertencia cuando el <main> existe pero no hay skip link que apunte a él.
El quinto y último grupo de reglas aborda la interacción en dispositivos móviles y el acceso a contenido multimedia — dos áreas críticas dada la prevalencia del tráfico móvil y el creciente uso de vídeo en la web.
ID de regla: a11y-touch-targets Criterio WCAG: 2.5.5 — Tamaño del objetivo (Nivel AAA) / 2.5.8 — Tamaño mínimo del objetivo (Nivel AA en WCAG 2.2)
Los touch targets son los elementos interactivos que los usuarios tocan en dispositivos táctiles: botones, enlaces, iconos, checkboxes. Para ser usables de forma fiable, necesitan un área táctil suficientemente grande — especialmente para usuarios con temblor de manos, dedos grandes o dificultades motrices.
Los tamaños recomendados:
| Estándar | Tamaño mínimo del área táctil |
|---|---|
| WCAG 2.2 nivel AA (2.5.8) | 24 × 24 píxeles |
| WCAG 2.1 nivel AAA (2.5.5) | 44 × 44 píxeles |
| Apple Human Interface Guidelines | 44 × 44 puntos |
| Google Material Design | 48 × 48 dp |
El tamaño recomendado para una UX óptima es 44 × 44 píxeles o mayor. El mínimo absoluto según WCAG 2.2 AA es 24 × 24 píxeles, con suficiente espacio de separación alrededor.
Los elementos que más frecuentemente fallan:
/* ❌ Enlace de texto pequeño en el footer — área táctil mínima */
.footer-link {
font-size: 12px;
padding: 2px;
}
/* ✅ Touch target ampliado con padding, sin cambiar el diseño visual */
.footer-link {
font-size: 12px;
padding: 12px 8px; /* Área táctil aumentada con padding */
display: inline-block;
}La conexión con Core Web Vitals: El INP (Interaction to Next Paint) se mide desde el primer toque en pantalla hasta la respuesta visual. Los touch targets demasiado pequeños provocan toques accidentales en elementos incorrectos, lo que aumenta el tiempo de interacción percibido y puede impactar negativamente el INP.
✅ Cómo auditarlo: Chrome DevTools → Lighthouse en modo Mobile incluye comprobaciones de touch targets. En el inspector de elementos, selecciona un botón o enlace y en la pestaña Computed verifica las dimensiones rendered. Los elementos con área inferior a 44×44px son candidatos a revisión.
ID de regla: a11y-video-captions Criterio WCAG: 1.2.2 — Subtítulos para contenido pregrabado (Nivel A) / 1.2.4 — Subtítulos para contenido en vivo (Nivel AA)
Todo vídeo con contenido de audio (diálogos, narración, efectos de sonido relevantes) debe tener subtítulos sincronizados — no solo una transcripción separada, sino subtítulos integrados que aparecen en sincronía con el audio.
Los formatos de subtítulos estándar para web:
<!-- Subtítulos con elemento <track> -->
<video controls>
<source src="/videos/auditoria-seo.mp4" type="video/mp4">
<track
kind="subtitles"
src="/videos/auditoria-seo.es.vtt"
srclang="es"
label="Español"
default>
</video>El formato WebVTT (.vtt) es el estándar para web. Plataformas como YouTube generan subtítulos automáticos, pero es importante revisarlos y corregirlos — los subtítulos generados por IA tienen una tasa de error de entre el 5% y el 15%, especialmente con terminología técnica, nombres propios y acentos regionales.
El valor SEO de los subtítulos
Los motores de búsqueda no pueden «ver» el vídeo, pero sí pueden indexar el texto de los subtítulos y las transcripciones. Un vídeo con subtítulos es contenido textual que Google puede rastrear e indexar — lo que significa que el contenido de tu vídeo puede posicionarse en búsquedas de texto. Además, las páginas con transcripciones de vídeo tienen una densidad de contenido significativamente mayor.
El contexto social: más del 85% de los vídeos en redes sociales se consumen sin sonido. Los subtítulos no son solo accesibilidad — son una necesidad para el consumo de vídeo moderno.
✅ Cómo auditarlo: Revisa manualmente todos los vídeos <video> de tu web y verifica que tienen un elemento <track kind="subtitles"> o <track kind="captions"> asociado. Para vídeos embebidos de YouTube o Vimeo, verifica que los subtítulos están activados y son precisos.
ID de regla: a11y-zoom-disabled Criterio WCAG: 1.4.4 — Cambio de tamaño del texto (Nivel AA)
Esta regla verifica que la página no incluye la directiva user-scalable=no o maximum-scale=1 en la etiqueta <meta name="viewport">, que bloquea la capacidad del usuario para hacer zoom en la página.
El código que bloquea el zoom — y que debes evitar:
<!-- ❌ Bloquea el zoom del usuario — inaceptable para accesibilidad -->
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
<!-- ✅ Permite el zoom del usuario -->
<meta name="viewport" content="width=device-width, initial-scale=1">El zoom del navegador es una herramienta esencial para los usuarios con baja visión: les permite ampliar el texto y los elementos visuales hasta un tamaño que puedan leer cómodamente. Bloquearlo elimina esa posibilidad de forma unilateral.
El argumento habitual para bloquearlo — y por qué no es válido
«Bloqueamos el zoom porque nuestro diseño se rompe al ampliar». Este argumento indica un problema de diseño, no un argumento a favor del bloqueo del zoom. La solución correcta es diseñar un layout responsive que funcione correctamente cuando el usuario amplía al 200% — que es el requisito WCAG. Un layout que se rompe al hacer zoom es un layout defectuoso desde el punto de vista de la accesibilidad.
Nota sobre iOS Safari: Históricamente, iOS Safari ignoraba el bloqueo de zoom definido en el viewport meta. A partir de iOS 10, Apple empezó a respetar user-scalable=no de forma más consistente. Esto hizo que el problema se volviera más real para los usuarios de iPhone y iPad.
✅ Cómo auditarlo: Busca en el código fuente de tu web <meta name="viewport"> y comprueba que no contiene user-scalable=no ni maximum-scale=1. En SEOmator, la regla a11y-zoom-disabled lo detecta automáticamente.
| Regla | ID | Nivel WCAG | Impacto SEO | Prioridad |
|---|---|---|---|---|
| Zoom bloqueado | a11y-zoom-disabled | AA | Penaliza UX móvil y Mobile Usability | 🔴 Crítica |
| Contraste de color | a11y-color-contrast | AA | CTR, tiempo en página | 🔴 Crítica |
| Etiquetas de formulario | a11y-form-labels | A | Conversiones, UX | 🔴 Crítica |
| ARIA labels | a11y-aria-labels | AA | Usabilidad, señales de UX | 🟠 Alta |
| Texto de enlaces | a11y-link-text | AA | Enlazado interno, CTR | 🟠 Alta |
| Jerarquía de encabezados | a11y-heading-order | A | On-page SEO directo | 🟠 Alta |
| Landmark regions | a11y-landmark-regions | AA | Semántica para bots | 🟠 Alta |
| Foco visible | a11y-focus-visible | AA | Navegación por teclado | 🟡 Media |
| Touch targets | a11y-touch-targets | AA (WCAG 2.2) | INP, UX móvil | 🟡 Media |
| Skip link | a11y-skip-link | A | Navegación por teclado | 🟡 Media |
| Encabezados de tabla | a11y-table-headers | A | Comprensión de datos | 🟡 Media |
| Subtítulos de vídeo | a11y-video-captions | A | Indexación de vídeo | 🟡 Media |
Grupo A: Semántica ARIA y estructura (Reglas 1–3)
a11y-aria-labels): todos los elementos interactivos (botones, iconos, controles) tienen un nombre accesible mediante aria-label, aria-labelledby o texto visiblea11y-link-text): todos los <a> tienen texto descriptivo que comunica el destino del enlace sin depender del contextoa11y-heading-order): los headings (H1-H6) siguen un orden jerárquico sin saltos de nivel; hay exactamente un H1 por páginaGrupo B: Percepción visual (Reglas 4–5)
a11y-color-contrast): el contraste entre texto y fondo supera 4,5:1 para texto normal y 3:1 para texto grandea11y-focus-visible): el indicador de foco de teclado es visible en todos los elementos interactivos; nunca se usa outline: none sin alternativaGrupo C: Formularios y datos tabulares (Reglas 6–7)
a11y-form-labels): todos los campos de formulario tienen <label> asociado mediante for/id o envoltura; no se usa placeholder como único identificadora11y-table-headers): las tablas de datos tienen <th scope="col"> o <th scope="row"> en sus encabezadosGrupo D: Arquitectura de navegación (Reglas 8–9)
a11y-landmark-regions): la página usa <header>, <nav>, <main>, <footer> correctamente; múltiples <nav> tienen aria-label distintoa11y-skip-link): la página incluye un enlace «Saltar al contenido principal» como primer elemento enfocable, que apunta al <main> con idGrupo E: Interacción móvil y multimedia (Reglas 10–12)
a11y-touch-targets): los elementos interactivos tienen área táctil mínima de 44×44px o suficiente padding para alcanzar ese tamañoa11y-video-captions): todos los vídeos con audio tienen subtítulos sincronizados en formato WebVTT o equivalentea11y-zoom-disabled): el <meta name="viewport"> no contiene user-scalable=no ni maximum-scale=1Actualmente, la obligación legal de cumplir con WCAG 2.1 nivel AA en España aplica principalmente a las administraciones públicas y entidades del sector público (conforme al Real Decreto 1112/2018). Sin embargo, la Directiva Europea de Accesibilidad (European Accessibility Act, EAA), transpuesta en España como parte de la Ley de Accesibilidad de junio de 2025, amplía gradualmente los requisitos al sector privado, especialmente a empresas con más de 10 empleados o facturación superior a 2 millones de euros. El incumplimiento puede acarrear sanciones y, en algunos sectores, demandas.
WCAG 2.2 (publicado en octubre de 2023) añade 9 nuevos criterios de éxito sobre la base de WCAG 2.1. Los más relevantes para las 12 reglas de esta guía son: 2.4.11 Focus Appearance (el indicador de foco debe tener un área mínima y contraste suficiente, no solo ser «visible»), 2.5.7 Dragging Movements (cualquier acción que requiera arrastrar debe tener alternativa de un solo punto) y 2.5.8 Target Size Minimum (que establece 24×24px como mínimo AA para touch targets). WCAG 2.2 es backwards compatible: si cumples 2.1 AA, ya cumples la mayoría de 2.2 AA.
No existe una penalización explícita y directa por incumplimiento de WCAG. Lo que sí existe es un impacto negativo indirecto: las webs inaccesibles suelen tener peores métricas de experiencia de usuario (mayor rebote, menor tiempo en página, peor INP), que Google incorpora como señales de calidad en sus decisiones de ranking. Además, la mala accesibilidad semántica (ARIA ausente, landmarks incorrectos, jerarquía de headings rota) reduce la capacidad de Googlebot para interpretar correctamente el contenido de la página, lo que puede limitar la visibilidad en búsquedas semánticas y featured snippets.
Depende del punto de partida de tu web. Si usas un CMS como WordPress con un tema bien construido, muchas reglas pueden resolverse con configuración y pequeños ajustes de CSS — entre 1 y 3 días de trabajo. Si tu web está construida con código personalizado sin atención a la accesibilidad, la implementación completa puede llevar de 1 a 3 semanas. Las reglas de mayor ROI por rapidez de implementación son: el skip link (30 minutos), el zoom desbloqueado (5 minutos), los ARIA labels en iconos (1-2 horas) y las etiquetas de formulario (1-2 horas).
Las principales opciones gratuitas son: Google Lighthouse (Chrome DevTools → Lighthouse → Accessibility) para una puntuación general y los problemas principales; axe DevTools (extensión Chrome gratuita) para un análisis más detallado con menos falsos positivos que Lighthouse; WAVE (web.ait.iastate.edu/wave/index.html o extensión Chrome) para una vista visual de los errores sobre la página; HeadingsMap (extensión Chrome) para visualizar la jerarquía de headings y landmarks; y SEOmator para auditar las 12 reglas de forma automática junto con el resto de factores SEO de la web.
No, y este es uno de los malentendidos más frecuentes. La primera regla del uso de ARIA dice explícitamente: «Si puedes usar un elemento HTML nativo con la semántica que necesitas, úsalo». ARIA debe ser el complemento del HTML semántico, no su sustituto. Un <button> con role="button" es redundante — y <div role="button"> es un antipatrón que requiere implementar a mano la funcionalidad que un <button> nativo ya incluye (foco por teclado, activación con Enter/Space, comportamiento en formularios). El HTML semántico nativo es siempre más robusto, compatible y fácil de mantener que el HTML no semántico con ARIA.
La accesibilidad web no es la cima más glamorosa del SEO técnico, pero es una de las más rentables. Cada regla que corriges amplía el universo de usuarios que pueden recorrer tu web sin obstáculos: usuarios con discapacidades visuales, motrices y cognitivas; usuarios en dispositivos móviles; usuarios que navegan por teclado; y, en definitiva, el propio Googlebot.
Las 12 reglas de esta guía representan el equipamiento básico de una web accesible. No son el techo de lo que puedes lograr — WCAG 2.1 tiene más de 50 criterios de éxito — pero son el punto de partida más impactante, el que te da el mayor beneficio con el menor esfuerzo.
La buena noticia: si tu web pasa estas 12 reglas, ya está en el percentil superior de accesibilidad de la web española. La mayoría de las webs fallan en varias de ellas. Empezar por las críticas — contraste de color, etiquetas de formulario, zoom desbloqueado — y avanzar hacia las de impacto medio es la ruta más eficiente hacia una web que no deja a nadie en el campamento base.
Si quieres saber exactamente en cuántas de las 12 reglas falla tu web — y cuál es la ruta más corta para corregirlas — podemos hacer la auditoría juntos.
Solicitar auditoría SEO gratuita → Ver nuestros servicios SEO →
Audita las 10 reglas de internacionalización SEO: atributo lang correcto, validación de hreflang, return links, conflictos y mismatches. Guía técnica con ejemplos de código y herramientas.
Aprende a detectar y corregir los 5 problemas móviles que Google comprueba en tu web: tamaños de fuente, scroll horizontal, intersticiales intrusivos y configuración del viewport. Guía técnica con checklist.
Una redirección mal configurada puede costar posiciones, link equity y rastreabilidad. Audita las 8 reglas de redirects SEO: bucles, tipos 301/302, meta refresh, JavaScript redirects y más.
/ Volver al campamento
Más de 20 artículos publicados sobre SEO, diseño web y marketing digital, con datos reales y reglas auditables.