En resumen
Qué se comprueba
que exista una zona de contenido principal declarada y que las listas usen marcado de lista.
Qué dice la norma
la estructura que se percibe mirando debe poder determinarse también en el código (criterio 1.3.1 de las WCAG, nivel A).
Por qué importa
quien navega con lector de pantalla o solo con teclado usa esa estructura para saltar; si no está, recorre la página entera.
Severidad en Wakaris
Mejora. Aparece en el 29,9 % de las páginas analizadas por el checker.
Qué es y qué mide este hallazgo
La estructura semántica es la parte del código que dice qué es cada cosa, no cómo se ve. Un menú de navegación, el cuerpo del artículo, una lista de características: para quien mira la pantalla, todo eso se distingue por la posición, el tamaño y las viñetas. Para quien no la mira, solo existe si está escrito en el marcado.
Este hallazgo mira dos piezas de esa estructura. La primera es la zona de contenido principal: la parte que contiene el contenido propio de la página, separada de la cabecera, el menú y el pie que se repiten en todas. La segunda es la estructura de las listas: si lo que se ve como una lista está construido con los elementos de lista del HTML o solo lo parece.
Las dos responden al mismo criterio de las WCAG, el 1.3.1, de nivel A: la información, la estructura y las relaciones que se transmiten visualmente tienen que poder determinarse desde el código.
Cómo se comprueba
Wakaris analiza la URL que le indiques y te devuelve dos resultados independientes: si la página declara o no su zona de contenido principal, y cuántos problemas de estructura encuentra en sus listas. Es la vía directa para tenerlo sin instalar nada ni crear cuenta.
El segundo resultado se lee por tramos. Un solo problema de lista ya produce hallazgo, y a partir de diez el resultado escala. Esa diferencia orienta el arreglo: un caso suelto suele ser un bloque concreto mal escrito, mientras que una decena o más apunta a la plantilla o al editor con el que se redacta el contenido.
Sobre el alcance conviene ser preciso en dos puntos. La comprobación se hace sobre una dirección concreta, así que describe esa página; si la plantilla es común, lo más probable es que el resultado se repita, pero eso no lo afirma este análisis. Y lo que se comprueba es el marcado, no la intención: una lista visual construida con guiones y saltos de línea se ve como una lista para quien mira, y desde el código no hay nada que la delate como tal.
Por qué importa
El motivo es que la estructura es la que permite moverse rápido. La documentación del W3C lo dice sin rodeos al justificar el criterio de saltar bloques repetidos: quien usa lector de pantalla evita así tener que escuchar toda la cabecera y decenas de enlaces de navegación en cada página antes de llegar al contenido, y quien navega solo con teclado llega con muchas menos pulsaciones.
Con las listas pasa algo parecido a menor escala. El W3C señala que algunas ayudas técnicas permiten navegar de lista en lista o de elemento en elemento, y saltarse un grupo de enlaces si el usuario quiere. Una lista que solo lo parece pierde esa capacidad: se lee como un párrafo largo y ni se anuncia ni se puede esquivar.
Hay además un efecto que va más allá de la accesibilidad: un documento cuyo código distingue el contenido propio del que se repite es más fácil de interpretar para cualquier sistema que lo lea sin verlo, buscadores incluidos.
Causas comunes
Lo habitual no es un error, sino una omisión: el diseño se resuelve con contenedores genéricos y estilos, y nadie llega a declarar qué es cada bloque.
En la zona principal, la causa más frecuente es una plantilla construida entera con contenedores neutros, donde el contenido se distingue por su posición y sus clases pero ningún elemento dice «esto es lo principal». También aparece cuando la plantilla original sí lo declaraba y una personalización posterior lo sustituyó.
En las listas, el origen suele estar en el contenido más que en la plantilla. Textos pegados desde un procesador de textos que traen guiones o asteriscos al principio de cada línea y saltos de línea entre ellas. Listas convertidas en cuadrículas de tarjetas, donde cada tarjeta es un contenedor suelto. Y menús o galerías donde se han colado elementos que no son de lista dentro del contenedor de la lista, algo que el HTML no admite: sus únicos hijos permitidos son los elementos de lista.
Cómo solucionarlo
Los dos arreglos son de esfuerzo muy distinto, y el orden importa. Wakaris te dice cuál de los dos resultados ha fallado, y con eso ya sabes por dónde empezar.
Declarar la zona principal es casi siempre un cambio de una línea en la plantilla: envolver el contenido propio de la página en el elemento que el HTML reserva para eso. Dos reglas que conviene respetar: solo puede haber una zona principal visible por documento, y dentro va el contenido propio, no la cabecera, el menú ni el pie. Es el arreglo más rentable del hallazgo, y además habilita el enlace de salto al contenido que agradece quien navega con teclado.
Con las listas el trabajo es de repaso. Convierte en listas reales lo que se ve como una lista, con la variante ordenada cuando el orden significa algo. Revisa que dentro del contenedor solo haya elementos de lista. Y si el problema viene del contenido, el arreglo duradero está en cómo se redacta: usar el botón de lista del editor en lugar de guiones.
Esquema de una página con la cabecera, el menú y el pie atenuados y la zona de contenido principal resaltada
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Esquema de una página con la cabecera, el menú y el pie atenuados y la zona de contenido principal resaltada. Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía. Formato: 16:9, 1440 píxeles de ancho. Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen. Sin logotipos reales ni marcas de terceros. Sin personas reconocibles. Etiquetas: estructura, semántica, esquema, página, cabecera, menú, pie, atenuados
Pregúntale a tu IA
Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.
Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Estructura semántica. Significa que mi página no declara en su código la estructura que sí se ve en pantalla. Se comprueban dos cosas: si existe una zona de contenido principal declarada, y si las listas están construidas con marcado de lista. Referencia: el criterio 1.3.1 de las WCAG 2.2, de nivel A, pide que la estructura que se percibe visualmente pueda determinarse también desde el código. Pega aquí el resultado de Wakaris: si te ha fallado la zona de contenido principal, cuántos problemas de listas te ha contado y en qué página. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir. Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde: a) ¿En qué plataforma está tu web? (WordPress, Shopify, web a medida, otra) b) ¿Cuál de los dos resultados te ha fallado: la zona de contenido principal, las listas, o los dos? c) Si son las listas, ¿cuántos problemas te ha contado: uno o dos, o más de diez? d) ¿El contenido de la página lo escribís con un editor visual, o va en plantilla? e) ¿Usáis una plantilla comprada o hecha a medida? ¿La habéis personalizado? f) Si hay que tocar la plantilla, ¿lo harías tú, un técnico interno o una agencia? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso. 4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes medir, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. 5. No me propongas cambios técnicos irreversibles o de riesgo (tocar la plantilla directamente en producción, reemplazar bloques de contenido) sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba. 6. No me propongas añadir marcado semántico decorativo por acumulación. Si me sugieres marcar algo, dime qué es exactamente ese bloque y por qué ese marcado lo describe. 7. Si necesitas un dato que solo se obtiene analizando la web (confirmar el recuento real, en qué bloques está o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se comprueba, no se adivina. 8. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 9. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Fuente de este hallazgo: https://www.wakaris.com/es/guias/accesibilidad/estructura-semantica Para comprobarlo o volver a comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: Estructura semántica. Consiste en que la página no declare en su código la estructura que se ve en pantalla: que no marque cuál es su zona de contenido principal, o que sus listas no estén hechas con marcado de lista. Referencia: el criterio 1.3.1 de las WCAG 2.2, de nivel A. Todavía NO sé si mi web lo tiene: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se comprueba mirando el código de la página, y tú no puedes analizar mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema: a) ¿En qué plataforma está tu web y con qué plantilla? (WordPress, Shopify, web a medida, otra; o no lo sé) b) ¿La plantilla es la original o la habéis personalizado bastante? c) ¿El contenido lo escribís en un editor visual o lo maqueta un técnico? d) Cuando escribís listas, ¿usáis el botón de lista del editor o escribís guiones al principio de cada línea? e) ¿Tenéis bloques que se ven como listas pero son tarjetas o columnas de diseño? f) ¿Alguien ha revisado alguna vez la accesibilidad de la web? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga y cuál de las dos partes sería la sospechosa, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dirá si falta la zona de contenido principal, cuántos problemas de listas hay y de paso el estado de las otras áreas. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo. 6. Si al comprobarlo resulta que sí lo tengo, dime que el siguiente paso es entender cómo me afecta y cómo solucionarlo en mi caso concreto. 7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este hallazgo: https://www.wakaris.com/es/guias/accesibilidad/estructura-semantica Para comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Puedo tener varias zonas de contenido principal? +
No. La documentación de MDN es explícita: un documento no debe tener más de una zona principal que no esté oculta. Si tu plantilla declara varias, el resultado deja de ser útil, porque ya no identifica un único destino al que saltar.
¿Una lista de tarjetas cuenta como lista? +
Depende de cómo esté construida, no de cómo se vea. Si cada tarjeta es un contenedor suelto, no hay lista para quien no mira la pantalla. Si van dentro de un contenedor de lista y cada tarjeta es un elemento de lista, sí, aunque el diseño sea una cuadrícula.
¿Qué pasa si escribo las listas con guiones? +
Que se ven como una lista y se leen como un párrafo. El W3C describe justo ese caso: poner un símbolo al principio de cada línea y separarlas con saltos de línea no crea una lista, y quien usa una ayuda técnica pierde la posibilidad de recorrerla o de saltársela.
¿Esto afecta al posicionamiento? +
No de forma directa ni declarada. Su efecto es de accesibilidad y de comprensión: un código que distingue el contenido propio del repetido es más fácil de interpretar para cualquier sistema que lea la página sin verla. Trátalo como calidad estructural, no como una palanca de posiciones.
Fuentes citadas
- w3.orgUnderstanding Success Criterion 1.3.1: Info and Relationships, W3C: el criterio de nivel A que exige que la estructura percibida visualmente pueda determinarse desde el código.
- w3.orgUnderstanding Success Criterion 2.4.1: Bypass Blocks, W3C: el coste de no poder saltar los bloques repetidos, en escucha para el lector de pantalla y en pulsaciones para el teclado.
- w3.orgH48: Using ol, ul and dl for lists or groups of links, W3C: la navegación de lista en lista y de elemento en elemento, y el caso de las listas hechas con símbolos y saltos de línea.
- developer.mozilla.org<main>: The Main element, MDN: qué contiene la zona principal, la regla de una sola por documento y el enlace de salto al contenido.
- developer.mozilla.org<ul>: The Unordered List element, MDN: los únicos hijos permitidos dentro del contenedor de una lista.
Actualizado: 8 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.