Comprobador de encabezamientos WCAG

¿Qué es un verificador de encabezados WCAG?

Un verificador de encabezados WCAG valida que los elementos de encabezado en una página web (h1, h2, h3, h4, h5, h6) formen una jerarquía lógica que los lectores de pantalla y otras tecnologías de asistencia puedan navegar. Los encabezados son la forma en que los usuarios ciegos y con baja visión navegan por una página: usan un atajo de lector de pantalla para saltar de encabezado a encabezado, construyendo una tabla de contenidos mental en segundos. Si los encabezados están ausentes, fuera de orden o usados decorativamente, esa navegación colapsa. El Criterio de Éxito WCAG 2.2 1.3.1 (Información y Relaciones) y 2.4.6 (Encabezados y Etiquetas) requieren que los encabezados transmitan la estructura correctamente.

Las reglas son simples de enunciar y fáciles de violar. Debe haber exactamente un h1 por página (el título de la página). Cada encabezado subsiguiente debe estar como máximo un nivel más profundo que su padre (un h2 puede ser seguido por otro h2 o por un h3, pero no directamente por un h4). Los encabezados no deben estar vacíos. Los niveles de encabezado deben describir la estructura del documento, no el tamaño visual (no use h4 solo porque quiere texto más pequeño). La mayoría de las auditorías de accesibilidad marcan los problemas de jerarquía de encabezados como lo primero a corregir porque son comunes, fáciles de verificar y de alto impacto para los usuarios de lectores de pantalla.

Esta herramienta analiza el HTML que pega (sin carga, sin viaje al servidor), recorre los elementos de encabezado en orden de documento e informa los problemas: h1 faltante, múltiples h1, niveles omitidos, encabezados vacíos y un esquema de la estructura de la página. La salida es texto plano que describe cada problema. Ejecútelo en cualquier página durante el desarrollo, antes del lanzamiento, o como parte de un ciclo regular de auditoría de accesibilidad. La salida es en lenguaje sencillo, no una puntuación numérica; el objetivo es darle problemas específicos para corregir, no una calificación aprobatoria para perseguir.

Qué hay dentro de la herramienta

La parte superior de la página es un área de texto donde pega su HTML. Puede pegar un documento completo (DOCTYPE, html, head, body) o un fragmento (solo el contenido del body). La herramienta extrae todos los elementos h1 a h6 en orden de documento usando un DOMParser de navegador estándar, por lo que el análisis coincide con lo que un navegador real haría. El área de texto maneja entrada de cualquier tamaño; los documentos muy grandes (decenas de miles de líneas) funcionan pero toman una fracción de segundo más para analizar.

Haga clic en Verificar Encabezados y los resultados aparecen a continuación. La primera sección es el esquema de encabezados: cada encabezado en orden, sangrado por nivel, para que pueda leer la estructura como una tabla de contenidos. La segunda sección es la lista de problemas: cada problema con su ubicación específica, qué está mal y una breve explicación de por qué importa. Los problemas se clasifican por severidad: errores (deben corregirse para cumplir con WCAG) y advertencias (mejor práctica pero no fallas estrictas).

La salida permanece en el navegador; nada se carga. Puede pegar el mismo HTML muchas veces con ediciones entre medias para iterar sobre las correcciones. La herramienta intencionalmente no verifica nada fuera de la estructura de encabezados (no verifica texto alt, contraste, orden de foco, ARIA o cualquier otro criterio WCAG). Para esos, use esta herramienta junto a una herramienta de auditoría completa como axe DevTools, Lighthouse o WAVE.

Historia y contexto

Encabezados HTML desde el principio (1991)

Tim Berners-Lee introdujo HTML en 1991 con los elementos h1 a h6 como parte de las 18 etiquetas originales. La intención semántica original siempre fue la estructura del documento, no el estilo visual. La jerarquía de encabezados de la Web proviene de una tradición mucho más antigua: los documentos impresos (libros, artículos, informes gubernamentales) han usado niveles de sección numerados durante siglos para transmitir estructura. HTML heredó ese modelo directamente. A pesar de 35 años de semántica estable, el mal uso de encabezados es uno de los errores de accesibilidad más comunes en la web moderna porque los diseñadores a menudo estilizan por tamaño visual primero y verifican la estructura después.

Los lectores de pantalla aprenden a navegar por encabezados (1996 en adelante)

JAWS (Job Access With Speech) fue lanzado por Henter-Joyce en 1989 y agregó navegación de encabezados de páginas web a medida que la Web se hizo popular a finales de los años 90. Presionar la tecla H en JAWS salta al siguiente encabezado; las teclas numeradas 1 a 6 saltan a ese nivel de encabezado específico. Cada lector de pantalla importante desde entonces (NVDA en 2006, VoiceOver en 2005, TalkBack en Android) ha copiado este atajo. La Encuesta Anual de Usuarios de Lectores de Pantalla de WebAIM encuentra consistentemente que del 67 al 70 por ciento de los usuarios de lectores de pantalla navegan por encabezados como su método principal para entender una página. La jerarquía de encabezados rota no es, por lo tanto, un problema cosmético.

WCAG 1.0 y el surgimiento de los estándares de accesibilidad (1999)

Las Pautas de Accesibilidad para el Contenido Web 1.0 fueron publicadas por W3C en mayo de 1999, el primer estándar internacional para accesibilidad Web. WCAG 1.0 requería explícitamente que los encabezados se usaran para la estructura del documento (Punto de Verificación 3.5). WCAG 2.0 (2008) lo refinó en el Criterio de Éxito 1.3.1 (Información y Relaciones, Nivel A) y 2.4.6 (Encabezados y Etiquetas, Nivel AA). WCAG 2.1 (2018) y 2.2 (2023) mantuvieron estos criterios sin cambios porque el requisito subyacente es sólido. La mayoría de las leyes de accesibilidad en todo el mundo (ADA en EE. UU., EAA en Europa, AODA en Ontario) ahora citan WCAG 2.1 AA como la base legal.

Sectionamiento HTML5 y esquema del documento (2014)

HTML5 (Recomendación W3C 2014) introdujo elementos de seccionamiento (article, section, nav, aside) y un algoritmo de esquema que se suponía derivaría la jerarquía de encabezados de la profundidad de anidación. El algoritmo nunca se implementó en ningún navegador o lector de pantalla y se desaprobó formalmente en 2022. La guía práctica es: use niveles de encabezado explícitos (h1 a h6) y trate los elementos de seccionamiento como agrupación semántica, no como un sustituto de la profundidad del encabezado. El HTML Living Standard ahora indica claramente que los niveles de encabezado deben establecerse explícitamente.

Roles ARIA y aria-level (2014 en adelante)

WAI-ARIA 1.1 (Recomendación W3C 2017) proporciona role="heading" con aria-level="N" como forma alternativa de marcar encabezados, útil cuando no puede usar los elementos nativos h1-h6 (por ejemplo, en un componente de framework que necesita renderizar diferentes niveles de encabezado en diferentes contextos). Los lectores de pantalla tratan role="heading" idénticamente al elemento nativo. La mejor práctica es usar elementos nativos cuando sea posible; use ARIA solo cuando la semántica nativa no esté disponible. Esta herramienta verifica tanto los elementos de encabezado nativos como los elementos con role="heading".

Demandas de accesibilidad y el caso de negocio (2017 en adelante)

Domino's Pizza vs. Robles (Corte Suprema de EE. UU. 2019) estableció que la Ley de Estadounidenses con Discapacidades (ADA, 1990) se aplica a sitios web comerciales. Cientos de demandas similares han seguido cada año (más de 4,000 demandas web ADA presentadas solo en 2024). La Ley Europea de Accesibilidad (EAA, en vigor en junio de 2025) hace de la accesibilidad equivalente a WCAG un requisito legal para la mayoría de sitios web orientados al consumidor en toda la UE. La estructura de encabezados fallida es uno de los problemas más fáciles para que los demandantes identifiquen y documenten, lo que hace que las verificaciones básicas de encabezados sean un paso de cumplimiento de alto apalancamiento.

Flujos de trabajo prácticos

Verificación pre-lanzamiento en nuevas páginas y plantillas

Antes de que cualquier nueva página o plantilla se envíe, ejecute el HTML a través de este verificador. Los problemas de estructura de encabezados son los errores de accesibilidad más fáciles de introducir (especialmente en contenido manejado por CMS donde los editores eligen niveles de encabezado basados en tamaño visual) y los más fáciles de corregir. Detectarlos antes del lanzamiento es mucho más barato que después, cuando las correcciones requieren coordinación con los propietarios del contenido. Para agencias, incorpore esta verificación en la lista de verificación QA; para equipos internos, ejecútela como parte de la revisión de código o antes de fusionar a main.

Auditar un sitio existente para cumplimiento de accesibilidad

Para una auditoría de accesibilidad (pre-litigio, cumplimiento EAA, requisito contractual), recorra las páginas más visitadas y ejecute el HTML de cada una a través de este verificador. Documente los hallazgos: qué páginas tienen problemas de encabezados, de qué tipo, cómo corregir. Combine con axe DevTools o Lighthouse para los otros criterios WCAG. Los hallazgos de estructura de encabezados generalmente son los más fáciles de remediar y forman una sección sólida de ganancias rápidas del informe de auditoría.

Capacitación de editores CMS y plantillas

El contenido manejado por CMS (WordPress, Drupal, Contentful, Sanity) a menudo da a los editores un menú desplegable de encabezados con opciones H1 a H6. Los editores que no conocen las reglas eligen niveles por tamaño visual. Demuestre este verificador a los editores para que puedan ver lo que producen sus elecciones de encabezados. Para plantillas, ejecute la salida renderizada a través del verificador después de cada cambio de diseño para confirmar que las elecciones de encabezados del editor todavía producen jerarquía válida. Existen muchos plugins CMS que advierten a los editores al momento de escribir; esta herramienta sirve al paso de verificación.

Validar plantillas de correo electrónico y boletines HTML

Los correos electrónicos HTML leídos por lectores de pantalla deben seguir la misma jerarquía de encabezados que las páginas web. Ejecute el HTML de su plantilla de correo electrónico a través de este verificador antes de enviar a una lista grande. Problemas comunes de plantillas de correo electrónico: múltiples h1 (cuando cada sección tiene su propio titular), h1 faltante (cuando el diseño comienza directamente con h2) y h4 decorativos usados puramente para encabezados pequeños. Corríjalos antes de enviar; los usuarios de tecnología de asistencia en su lista lo notarán.

Validar conversiones de PDF a HTML

Cuando convierte PDFs a HTML para accesibilidad (para que puedan ser leídos por lectores de pantalla con navegación de encabezados), el convertidor tiene que mapear las etiquetas de estructura PDF a niveles de encabezado HTML. El resultado a menudo está roto: los PDFs sin etiquetado adecuado producen HTML plano sin encabezados, e incluso los PDFs etiquetados a veces producen salida todo-h1 o todo-h2. Ejecute el HTML convertido a través de este verificador para detectar el problema antes de publicar la página convertida.

Incorporación de nuevos desarrolladores y diseñadores

Los desarrolladores front-end junior y los diseñadores se benefician de ver ejemplos concretos de jerarquía de encabezados rota y la experiencia de lector de pantalla resultante. Empareje esta herramienta con una demostración de lector de pantalla (NVDA en Windows es gratuito, VoiceOver en Mac está integrado) para mostrar cómo los encabezados impulsan la navegación del lector de pantalla. La conexión entre las reglas abstractas de encabezado y la experiencia concreta del usuario suele ser lo que hace que la lección se quede.

Errores comunes

Elegir el nivel de encabezado por tamaño visual

El error más común: usar un h4 porque quiere texto más pequeño, o saltar de h2 a h4 porque no hay un h3 dimensionado correctamente en el diseño. Los niveles de encabezado son estructurales, no visuales; use CSS para controlar el tamaño y use el nivel que coincide con la jerarquía del documento. Si su sistema de diseño no tiene un estilo visual para cada nivel necesario, agregue uno (o anule con nombres de clase) en lugar de elegir el nivel incorrecto.

Múltiples h1 por página

Una página debe tener exactamente un h1 representando el título de la página. Errores comunes: un logo del sitio envuelto en h1 más un título de artículo también en h1 (dos h1), una página de inicio con cada sección hero usando h1 (múltiples h1), o ningún h1 porque el diseño comienza con h2. La corrección es estructural: elija el contenido más importante en la página como el único h1 y rebaje todo lo demás a h2 o por debajo. Herramientas como axe y Lighthouse advierten sobre múltiples h1 por esta razón.

Niveles de encabezado omitidos

Ir de h2 directamente a h4 rompe el esquema del documento. Los usuarios de lectores de pantalla moviéndose de encabezado a encabezado esperan que cada h4 esté anidado bajo un h3, y el h3 faltante confunde la estructura. La corrección es insertar el nivel intermedio faltante o rebajar el h4 a h3. La causa más común es copiar el diseño de una maqueta donde la jerarquía visual usa tres tamaños pero el sistema de diseño usa cuatro niveles de encabezado; vuelva a verificar después de cada actualización de componente.

Encabezados vacíos

Un h2 sin contenido de texto (a menudo porque un widget JavaScript eliminó el texto pero mantuvo el elemento) aparece en la lista de encabezados del lector de pantalla como un encabezado sin etiquetar, lo cual es confuso e inútil. O bien popule el encabezado con texto, o elimine el elemento de encabezado por completo. Esto es común en aplicaciones de página única donde los elementos de marcador de posición se renderizan antes de que se carguen los datos; renderice el encabezado solo cuando haya contenido para poner en él.

Encabezados dentro de envoltorios no semánticos

Un encabezado envuelto en un div con role="presentation" o aria-hidden="true" se elimina del árbol de accesibilidad, lo que puede ocultar un encabezado de otro modo correcto de los lectores de pantalla. Audite los elementos padres de cada encabezado para asegurarse de que no eliminen el encabezado del árbol de accesibilidad. CSS display:none y visibility:hidden también eliminan el encabezado; solo úselos intencionalmente y nunca en contenido que debe ser visible para el lector de pantalla.

Usar ARIA cuando el HTML nativo serviría

Agregar role="heading" aria-level="2" a un div en lugar de usar un elemento h2 funciona para la accesibilidad pero es complejidad innecesaria. Los elementos nativos h1-h6 obtienen semántica de encabezado gratis, se renderizan correctamente en los estilos de navegador predeterminados, y sobreviven mejor a los errores de lectores de pantalla que las anulaciones ARIA. La primera regla de ARIA (según las prácticas de autoría WAI-ARIA) es: no use ARIA cuando el HTML nativo proporciona la misma semántica. Use elementos de encabezado nativos a menos que una restricción de framework realmente fuerce ARIA.

Privacidad y manejo de datos

El HTML que pega permanece en su navegador durante toda la verificación. El DOMParser que extrae los encabezados se ejecuta en JavaScript en su máquina; los resultados se renderizan en la página debajo del área de texto. No hay paso de carga, no hay procesamiento remoto, y no hay telemetría sobre qué HTML pegó. Esto importa porque el HTML que más quiere verificar (plantillas pre-lanzamiento, sitios de clientes bajo NDA, páginas de administración internas) es exactamente lo que no debería pegar en un validador SaaS de terceros.

Una vez que la página está cargada, la herramienta funciona sin conexión. Puede desconectarse de internet, pegar HTML, ejecutar la verificación y revisar los resultados sin que su marcado toque jamás otra máquina. La mayoría de los verificadores de accesibilidad en la nube (PowerMapper, Tenon, Site Improve) requieren cargar la URL o HTML de la página; para páginas confidenciales esa es precisamente la falla a evitar.

Cuándo no usar esta herramienta

Para auditorías WCAG completas (use una herramienta completa)

La estructura de encabezados es uno de docenas de criterios WCAG. Para una auditoría completa, use axe DevTools (extensión gratuita de Chrome/Firefox de Deque), Lighthouse (integrado en Chrome), WAVE (herramienta gratuita de WebAIM), o una solución de pago como Tenon o PowerMapper. Estos verifican contraste de color, texto alt, uso de ARIA, etiquetas de formulario, orden de foco y muchos más. Ejecute esta herramienta junto a, no en lugar de, las completas.

Para contenido dinámico (pruebe el DOM renderizado)

Si sus encabezados son generados por JavaScript (React, Vue, Svelte, Angular), la fuente HTML estática no contiene los encabezados finales. Necesita pegar el DOM renderizado después de que JavaScript se ejecute. Use las DevTools del navegador: abra la página, abra DevTools, pestaña Elements, haga clic derecho en el body o main, Copiar outerHTML, luego pegue eso en este verificador. O use una extensión de navegador que recorra el DOM en vivo directamente.

Para pipelines CI/CD automatizados (use una biblioteca Node)

Si quiere que las verificaciones de encabezados se ejecuten automáticamente en cada commit o pull request, integre axe-core, Pa11y o jest-axe en su suite de pruebas. Ejecutan verificaciones de encabezados (y muchas otras verificaciones WCAG) sin cabeza en CI. Esta herramienta de navegador es para uso interactivo durante el desarrollo y revisión, no para automatización. Ambas tienen su lugar; use la herramienta de navegador para auditorías puntuales y la biblioteca CI para validación continua.

Para accesibilidad de documentos PDF o Word

Los PDFs y documentos Word tienen sus propios sistemas de etiquetado de accesibilidad (PDF/UA, los estilos de encabezado de Word). No usan encabezados HTML, por lo que esta herramienta no se aplica. Para accesibilidad PDF, use el Verificador de Accesibilidad de Adobe Acrobat Pro o PAC 2024 (gratuito, enfocado en PDF/UA). Para Word, use el Verificador de Accesibilidad integrado (pestaña Revisar). Convierta primero a HTML si quiere usar esta herramienta, pero la conversión en sí puede introducir problemas de encabezado.

Más preguntas

¿Está bien alguna vez omitir un nivel de encabezado?

No en contenido de documento directo. WCAG 2.2 SC 1.3.1 implica que los encabezados deben formar una secuencia jerárquica. El caso común donde parece un salto es el esquema de la página comenzando en h1 luego h2 dentro del área de contenido principal, mientras que una barra lateral o navegación también tiene h2; eso está bien porque ambos son hermanos bajo el h1 de la página. La regla real es: no salte niveles dentro de un flujo de contenido contiguo. El verificador marca solo los saltos reales.

¿Qué pasa si mi framework solo admite un nivel de encabezado?

Algunas bibliotecas de componentes renderizan encabezados en un nivel fijo (siempre h2, sin importar la anidación). La corrección es exponer una prop de nivel en el componente de encabezado (h2, h3, etc.) y hacer que los padres pasen el valor apropiado. Frameworks como React lo hacen comúnmente; si el suyo no, agregue un aria-level al componente y use role="heading" como una solución temporal hasta que pueda refactorizar. A largo plazo, cada componente de encabezado reutilizable debe aceptar una prop de nivel.

¿La herramienta verifica roles ARIA como role="heading"?

Sí. Cualquier elemento con role="heading" y un atributo aria-level válido (1 a 6) se trata como un encabezado en el nivel indicado. Los elementos nativos h1-h6 siempre son preferidos, pero los encabezados marcados con ARIA son igualmente válidos para lectores de pantalla y se verifican junto con los nativos.

¿Qué tan importante es la jerarquía de encabezados comparada con otros criterios WCAG?

Muy. La Encuesta Anual de Usuarios de Lectores de Pantalla de WebAIM encuentra consistentemente que del 67-70% de los usuarios de lectores de pantalla navegan por encabezados como su forma principal de entender una página. Los encabezados malos bloquean efectivamente uno de los métodos principales de navegación de accesibilidad. En el análisis anual WebAIM Million de WebAIM, los problemas de encabezado están entre las cinco fallas de accesibilidad más comunes en toda la web. La combinación de alto impacto en el usuario y detección fácil los convierte en una prioridad principal.

¿Cada página debe tener un h1?

Sí, con raras excepciones. Cada documento HTML completo debe tener exactamente un h1 que represente el título de la página. La excepción son fragmentos que se insertan explícitamente en una página más grande (una firma de correo electrónico, un widget incrustado en otra página); la página host proporciona el h1 y el fragmento comienza en h2 o inferior. Para páginas independientes, h1 faltante es una falla clara de accesibilidad.

¿Puedo confiar en esta herramienta para auditorías de cumplimiento legal?

Para la estructura de encabezados específicamente, sí: las reglas son precisas y la herramienta las implementa con precisión. Para el cumplimiento general de WCAG, ninguna herramienta automatizada por sí sola es suficiente; las pruebas manuales con tecnología de asistencia, revisión experta y pruebas de usuario con usuarios discapacitados son requeridas para auditorías de grado legal. Use esta herramienta como una de varias entradas en su auditoría, no como la única fuente de verdad para el cumplimiento.