Depuración, validación y coevaluación

Tres horas. Media hora para entender qué ve cada herramienta de comprobación y qué no ve ninguna, y dos horas y media diagnosticando un documento roto, cerrando tu proyecto y auditando el de otra persona.

Se explica

25 minutos · conceptos y demostración

La unidad cierra donde empezó: una página que se ve bien no demuestra nada. Hoy se añaden las herramientas que sí dictaminan, y se delimita con precisión lo que ninguna de ellas puede ver.

Una web no se hace solo para nosotros

Una web no debería funcionar únicamente para una persona que ve perfectamente, usa ratón, tiene una pantalla grande y navega exactamente como nosotros.

La buena noticia es que HTML bien utilizado proporciona buena parte de la accesibilidad automáticamente. No constituye una capa que se incorpore al final, sino el resultado del trabajo de toda la unidad:

1. Usa el elemento correcto. <button>Comprar</button> es mejor punto de partida que <div>Comprar</div> si representa una acción.
2. Mantén una jerarquía lógica de encabezados, sin saltos. Es el índice por el que se navega:

h1
    h2
        h3
    h2

3. Describe las imágenes con un alt informativo, funcional o vacío según su función. Nunca ausente.
4. Etiqueta los formularios con label asociado, no solo con placeholder.
5. Usa HTML semántico: nav, main, header, footer, section y article permiten recorrer el documento por zonas.

ARIA no es el punto de partida

Encontrarás código como este:

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

ARIA

Un conjunto de atributos para describir el papel, el estado y las propiedades de un elemento cuando HTML no llega. Puede ser necesaria en componentes complejos.

No debe emplearse, sin embargo, para reconstruir manualmente algo que HTML ya proporciona. Ese div con role="button" necesita además que le programes la activación con Enter y con espacio, el foco, y el estado. Un <button> trae todo eso.

1. HTML nativo
2. Si de verdad no llega, ARIA

Volvemos a la frase de la sesión 1

Que una página se vea bien no demuestra que su HTML esté bien.

Los navegadores se recuperan de casi cualquier error para no fallar delante del usuario. Eso es cómodo y, a la vez, es lo que oculta el código incorrecto. Necesitamos herramientas que no perdonen.

1. El navegador · solo delata lo que no consigue disimular
2. HTMLHint · avisa mientras escribes, dentro del editor
3. El validador del W3C · dictamina si el documento cumple la especificación
4. Tu criterio · lo único que juzga si el marcado significa lo correcto

Ante cada aviso de HTMLHint, tres preguntas: qué elemento lo provoca, qué regla se incumple y cómo debería solucionarse. El flujo completo de depuración es este:

1. Escribir
2. Previsualizar
3. Revisar el panel Problems
4. Validar en el W3C
5. Entender los errores
6. Corregir

Válido no significa correcto

Un documento entero hecho de <div>, sin un solo encabezado y con todas las imágenes con alt="foto", pasa el validador con cero errores. Es válido y es malo. La validez es el suelo, no el techo.

Revisar código ajeno

Una revisión útil no dice «está mal». Dice tres cosas: qué, por qué y qué harías tú.

Una regla mantiene su validez durante toda la vida profesional: se revisa el código, no a la persona. «Este enlace apunta a tu disco» y «no sabes hacer enlaces» describen el mismo hecho, y solo uno sirve para algo.

Se trabaja

150 minutos · diagnóstico, cierre del proyecto y revisión por pares

Los dos primeros pasos diagnostican: primero tu sitio sin ratón, después un documento roto a propósito. Los tres últimos cierran la unidad.

Paso 1 · La prueba del teclado sobre tu sitio · 20 min

Suelta el ratón. Recorre tus cuatro páginas usando solo:

Tab          avanzar
Shift + Tab  retroceder
Enter        activar
Espacio      marcar casillas y pulsar botones

Responde a continuación:

Corrige lo que encuentres. Casi todo se arregla cambiando un elemento por el que tocaba.

Paso 2 · HTML forense · 45 min

Es el trabajo central de la sesión. Este documento contiene veinte fallos deliberados. Cópialo en forense.html:

<html>
<head>
<title>PixelStore
</head>
<body>
<div class="cabecera">
<img src="C:\Users\pixel\logo.png">
<div class="menu">
<a href="C:\Users\pixel\web\index.html">Inicio</a>
<a href="productos.html">Productos</a>
<a href="https://proveedor.example.com" target="_blank">Proveedor</a>
</div>
</div>

<h1>PixelStore</h1>
<h4>Novedades del catálogo</h4>

<p id="destacado">Portátil Nova 14 <b><i>en oferta</b></i></p>
<p id="destacado">Teclado para Programación avanzada</p>

<img src="grafico-consumo.webp">

<table>
<tr><td>Modelo</td><td>RAM</td><td>Precio</td></tr>
<tr><td>Básico</td><td>8 GB</td><td>19 €</td></tr>
</table>

<form>
Correo: <input type="text">
<div onclick="enviar()">Enviar</div>
</form>

<p>© 2026 PixelStore
</body>
</html>

Tu trabajo, en este orden:

1. Ábrelo en el navegador y anota qué se ve mal antes de mirar el código. Fíjate en si algún texto aparece con caracteres extraños.
2. Pásale HTMLHint y anota qué encuentra.
3. Pásalo por validator.w3.org y anota qué encuentra que HTMLHint no encontró.
4. Localiza al menos quince de los veinte fallos y repáralos.
5. Entrega una tabla justificativa:

La columna «quién lo detectó» es la importante: al terminar tendrás la prueba, escrita por ti, de que las herramientas encuentran menos de la mitad.

Estoy atascado · llevo ocho y no encuentro más

Recorre el documento con una lista en la mano, en este orden, en lugar de buscar «a ver qué veo»:

1. El esqueleto: ¿están las cinco piezas de la sesión 1?
2. Los enlaces: ¿alguna ruta describe tu disco duro? ¿Algún target="_blank" sin protección?
3. Las imágenes: ¿todas tienen alt?
4. Los encabezados: ¿empiezan en h1 y bajan de uno en uno?
5. Los identificadores: ¿hay algún id repetido?
6. La anidación: ¿se cierran en orden inverso al que se abrieron?
7. La tabla: ¿tiene caption, thead, th y scope?
8. El formulario: ¿etiquetas, name, tipos y botón de verdad?
9. La estructura: ¿hay header, nav, main y footer, o solo div?

Ver los veinte fallos

Esqueleto

1 · Falta <!doctype html>. · 2 · Falta lang="es". · 3 · Falta <meta charset="UTF-8">: por eso «Programación» se ve mal. · 4 · Falta <meta name="viewport">. · 5 · <title> sin cerrar.

Enlaces e imágenes

6 · src de la primera imagen con ruta de disco local. · 7 · href del enlace de inicio con ruta de disco local. · 8 · target="_blank" sin rel="noopener noreferrer". · 9 · La primera imagen no tiene alt. · 10 · La segunda tampoco, y además es un gráfico: su alt debe llevar los datos.

Texto y estructura

11 · Salto de jerarquía: de h1 a h4. · 12 · id="destacado" duplicado. · 13 · Anidación cruzada: <b><i>…</b></i>. · 14 · Último <p> sin cerrar. · 15 · Cabecera y menú son div: deberían ser <header> y <nav> con una lista. · 16 · No hay <main> ni <footer>.

Tabla y formulario

17 · La tabla no tiene <caption>, ni <thead>/<tbody>, ni <th scope>. · 18 · El campo de correo no tiene <label>. · 19 · No tiene name y usa type="text" en vez de type="email". · 20 · El botón de envío es un <div onclick>.

El validador del W3C detecta la sintaxis: el doctype que falta, la codificación no declarada, el <title> abierto, las imágenes sin alt, el id duplicado y la anidación cruzada. No dice nada de la jerarquía de encabezados, ni de la tabla muda, ni del falso botón, ni de la sopa de div. Poco más de la mitad la tienes que ver tú.

Paso 3 · La lista de comprobación final · 30 min

Tu proyecto debe tener una organización parecida a esta:

mi-web/
│
├── index.html
├── productos.html
├── acerca.html
├── contacto.html
│
└── img/
    └── ...

Antes de recorrer la lista, formatea las cuatro páginas con Shift + Alt + F, o desde la paleta con Format Document. Las dos versiones siguientes son idénticas para el navegador, y solo una es legible para una persona:

<main><section><h2>Productos</h2><p>Texto</p></section></main>

<main>
    <section>
        <h2>Productos</h2>

        <p>
            Texto
        </p>
    </section>
</main>

El código también se escribe para personas: para tu compañero de revisión, para el profesor y para ti dentro de tres semanas.

Recorre después la lista entera. Cada línea que no puedas marcar es trabajo pendiente de hoy.

Paso 4 · Matriz de coevaluación · 30 min

Intercambia el proyecto con otro alumno y audita el suyo con el formato qué / por qué / qué harías:

Después, el autor recibe la matriz, decide qué acepta y qué no, y anota su decisión. Rechazar una observación justificándola bien también forma parte del ejercicio: la revisión propone, no manda.

Paso 5 · Cerrar la entrega · 25 min

Se entrega:

• A · El sitio. Cuatro páginas enlazadas, sin CSS, validadas en el W3C.
• B · La tabla forense del paso 2, con las correcciones justificadas.
• C · La matriz de coevaluación del proyecto de tu compañero.
• D · Tus decisiones, en media página: las tres decisiones de estructura de las que estás más seguro, y por qué.

Tu proyecto debe incluir, cuando tenga sentido en tu tema: estructura completa y metadatos, navegación entre páginas, jerarquía de encabezados, párrafos y elementos de énfasis, los tres tipos de lista, enlaces internos y externos, imágenes con figure, estructura semántica, una tabla de datos, un formulario completo con varios tipos de campo y validación, y algún elemento moderno como details o time.

Dedica los últimos minutos a preparar la defensa. Dispones de unos 3 minutos y respondes a cuatro preguntas:

• ¿Qué parte de tu estructura te costó más decidir y cómo la resolviste?
• Enseña un sitio donde estuviste tentado de usar un div y no lo hiciste.
• ¿Qué fallo encontraste en el proyecto de tu compañero que también tenías tú?
• Si mañana llega el CSS, ¿qué parte de tu HTML tendrías que tocar? (La respuesta correcta es «ninguna».)

Durante la defensa se preguntará por una decisión concreta de tu proyecto. No se evalúa que hayas usado muchas etiquetas distintas, sino que sepas decir por qué elegiste cada una. Un sitio sencillo y bien justificado vale más que uno lleno de elementos puestos por si acaso.

Ampliación si has completado el trabajo

Primero termina la entrega. Los dos retos invierten el ejercicio de la sesión: en lugar de encontrar fallos ajenos, se trata de fabricarlos y de medir cuántos deja pasar una herramienta.

Reto 1 · Fabrica tu propio documento forense

Parte de una copia limpia de una de tus páginas e introduce ocho fallos deliberados, repartidos así:

• dos que el validador del W3C detecte sin ninguna duda;
• dos que detecte HTMLHint mientras se escribe;
• dos que no detecte ninguna herramienta y solo se vean leyendo el significado;
• dos que solo se manifiesten al recorrer la página con el teclado.

Guarda aparte la solución, con la categoría de cada fallo. Entrégale el documento a un compañero y quédate con el suyo. Al devolvérselo, comparad dos cifras: cuántos encontró y en qué categoría se le escaparon. Casi siempre son las dos últimas, y esa es la conclusión de la unidad entera.

Reto 2 · Cuántos errores tiene una web que usas todos los días

Pasa por validator.w3.org la portada de tres sitios conocidos, usando la opción de validar por dirección.

Después responde:

1. ¿Alguno da cero errores? ¿Cuántos pasan de cincuenta?
2. Elige el error más repetido de uno de ellos y explica qué consecuencia real tiene, o si no tiene ninguna.
3. Busca en esos mismos sitios un fallo que el validador no señale y que tú sí sepas ver: un salto de encabezado, un falso botón, un alt inútil.
4. Las tres páginas funcionan y las usan millones de personas. Formula en dos líneas qué conclusión sacas sobre la relación entre validez, calidad y funcionamiento.

Cierre

5 minutos · comprobación y recuerdo

Ver respuestas

1 · Por ejemplo: navegación por encabezados, salto entre zonas con los landmarks, botones alcanzables con teclado, campos anunciados por su etiqueta, imágenes sustituidas por su alt. Bastan tres.

2 · Porque hay que reconstruir a mano el foco, la activación con teclado y el estado, y cualquiera de esas piezas se puede olvidar. El button las trae todas.

3 · Cuando construyes un componente para el que HTML no tiene un elemento equivalente. Nunca para sustituir uno que sí existe.

4 · Por ejemplo, usar div donde tocaba un elemento semántico, o un alt que no describe nada.

5 · Porque la validez comprueba la sintaxis, no el significado.

6 · Escribir, previsualizar, revisar Problems, validar, entender y corregir. El que no se puede saltar es entender.

---