Auditoría final, revisión por pares y entrega · Lenguaje de marcas

Hoy · Hoja de ruta

1. Aprende: Cómo se revisa el código de otra persona de forma útil.
2. Haz: Cierra tu proyecto con la lista de comprobación y audita el de un compañero.
3. Entrega: Entrega el proyecto, la matriz de coevaluación y defiende tus decisiones.

Antes de empezar · 5 minutos, sin apuntes

¿Qué diferencia hay entre HTML válido y HTML semánticamente correcto?
¿Qué herramienta usarías primero para un error de anidación y cuál para una decisión de significado?
Encuentra una mejora en este patrón: <div class="boton">Enviar</div>.

Tarea 15 · La lista de comprobación final

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

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

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

Documento

Usa <!doctype html>.
Define correctamente lang.
Incluye charset y viewport.
Cada página tiene un title propio y descriptivo.

Contenido

Existe una jerarquía coherente de encabezados, sin saltos y con un solo h1 por página.
Los párrafos son párrafos, y no hay <br> usados para maquetar.
Las listas se representan con listas reales, y las anidadas están bien anidadas.
Hay elementos de significado textual usados con criterio.

Navegación e imágenes

Todos los enlaces funcionan y las rutas son relativas.
El menú es idéntico en las cuatro páginas y marca la actual.
Todas las imágenes tienen alt adecuado, lleno o vacío según su función.
Se usa figure con figcaption donde tiene sentido.

Semántica, tablas y formularios

Se usan header, nav, main y footer, con un solo main.
section y article están justificados, y no hay div innecesarios.
La tabla solo se usa para datos tabulares, con caption y scope.
Todos los campos tienen etiqueta, tipo apropiado y name.
Hay validación nativa, y fieldset con legend donde hay grupos.
Los botones son elementos button.

Calidad

HTMLHint no muestra errores relevantes.
Las cuatro páginas superan el validador del W3C.
El código está correctamente indentado.
La estructura de carpetas se entiende sin explicación.

Condición de entrega · cero CSS

Ni ficheros .css, ni <style>, ni atributos style. Tu web tendrá un aspecto muy básico, y es intencionado: queremos comprobar si la información sigue estando bien estructurada cuando quitamos toda la presentación.

En la siguiente unidad partiremos de este mismo proyecto para ver cómo CSS transforma su apariencia sin cambiar lo que significa cada elemento.

Revisar código ajeno

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

En vez de escribir	Escribe
«La tabla está mal»	«Faltan los `scope` en los `th`: sin ellos cada celda se anuncia sin su encabezado. Añadiría `scope="col"` arriba y `scope="row"` en la primera columna»
«Los alt no valen»	«El `alt` del gráfico dice “gráfico”: quien no lo vea pierde los datos. Pondría los tres valores que compara»

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.

Tarea 16 · Matriz de coevaluación

Intercambia el proyecto con otro alumno y audita el suyo:

Aspecto auditado	Archivo	Problema detectado	Propuesta de corrección
Validez W3C
Jerarquía de encabezados
Estructura semántica
Navegación y rutas
Imágenes y `alt`
Tablas
Formulario

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.

Producto final

Se entrega:

A · El sitio. Cuatro páginas enlazadas, sin CSS, validadas en el W3C.
B · La tabla forense de la sesión 17, 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.

Presentación

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?
Enséñanos 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».)

Evaluación

Criterio	Puntos
Estructura y validez del documento	2
Jerarquía de encabezados y semántica estructural	2
Navegación y rutas relativas	1,5
Formulario accesible y validado	1,5
Imágenes y textos alternativos	1
Tablas accesibles	1
Auditoría forense y justificación de correcciones	1

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.

Checkpoint · entrega

Las cuatro páginas validan y no contienen un solo estilo.
La tabla forense está entregada y justificada.
Has revisado el proyecto de un compañero con el formato qué / por qué / qué harías.
Has decidido qué observaciones de tu revisor aceptas y cuáles no, y por qué.
Puedes justificar cualquier decisión de estructura de tu sitio.

Demostración final · el HTML ya está preparado para CSS

Observa tu estructura final con tres estilos muy diferentes. Predice qué partes de HTML no deberían tocarse en la UD2 y señala cualquier elemento que todavía dependa de su apariencia.

Microprueba semanal 6 · 10 minutos

Individual, sin IA y sin apuntes. Recibes una página breve que nunca has visto.

Localiza un error de sintaxis, uno de semántica y uno de accesibilidad.
Corrige solo lo imprescindible y explica el orden de diagnóstico.
Realiza un cambio nuevo solicitado por el profesor sin consultar tu proyecto.