HTML

Qué es, en una frase

HTML es el lenguaje con el que se marca el contenido de una página para decir qué es cada cosa: esto es un encabezado, esto es un párrafo, esto es una lista, esto es un enlace, esto es un campo de formulario.

Fíjate en que ahí no hay nada sobre colores ni tamaños. El HTML no dice cómo se ve una página; dice de qué está hecha. La apariencia es trabajo del CSS. Esa separación no es un capricho de programadores: es lo que permite que la misma página funcione en un móvil, en un portátil, en un navegador con el texto agrandado y en un programa que la lee en voz alta.

Marcar no es maquetar

La palabra clave de todo esto es semántica: usar el elemento que corresponde al significado del contenido, no el que casualmente se ve parecido.

Un ejemplo que sale en casi todas las auditorías que hago. Dos formas de poner un título de sección:

• Un <h2> con el texto dentro.
• Un <div> con el texto en negrita y grande.

En pantalla pueden verse idénticos. Para cualquiera que no vea la pantalla, son cosas radicalmente distintas: el primero es un título por el que se puede navegar y el segundo es texto suelto. Lo mismo pasa con un <button> frente a un <div> al que le han enganchado un clic: el botón de verdad se enfoca con el tabulador, se activa con la barra espaciadora y se anuncia como «botón». La imitación no hace nada de eso salvo que alguien lo reconstruya a mano, y casi nunca se reconstruye entero.

Esto es lo que llamamos «HTML semántico», y es la razón por la que hay elementos como <nav>, <main>, <header>, <footer>, <table>, <label> o <fieldset>. No están para adornar el código: cada uno le da al navegador y a las tecnologías de apoyo una información que de otra forma se pierde.

Por qué le importa a quien tiene una web

Por dos motivos que en realidad son el mismo.

Accesibilidad. Un lector de pantalla no ve tu diseño: recorre el HTML. Sus usuarios navegan saltando de encabezado en encabezado, listando los enlaces de la página o yendo directamente al contenido principal. Todo eso solo existe si el HTML lo declara. Cuando una web está hecha de <div> y <span>, esa persona se queda con un texto plano sin estructura por el que hay que bajar leyéndolo entero. Es la diferencia entre un índice y un ladrillo. Y es también el motivo por el que buena parte de las WCAG se cumplen sin escribir una sola línea extra: basta con usar el elemento correcto.

Buscadores. Google no lee tu página como la ves tú, la lee como código. La jerarquía de encabezados le dice de qué va cada bloque, un enlace con texto descriptivo le dice a dónde lleva, y una tabla marcada como tabla se entiende como datos. A eso se suman los datos estructurados, que son una capa aparte para describir entidades, pero que no arreglan un HTML mal puesto: lo complementan.

Dicho corto: la misma decisión —usar la etiqueta que toca— sirve a la vez para las personas que usan tecnología de apoyo y para el robot que rastrea la página. No hay que elegir. Es de las poquísimas cosas en este oficio donde hacer lo correcto no tiene coste.

Lo que veo en las auditorías

Llevo años abriendo webs ajenas y el patrón se repite. El fallo dominante no es gente que no sepa HTML: es HTML generado por herramientas visuales o por plantillas donde el título de una sección se elige por su tamaño en un desplegable. La persona quería «texto grande» y el editor le puso un <h1>. Resultado: páginas con cinco <h1>, saltos de <h2> a <h5> y bloques importantes marcados como texto normal.

Mi forma de comprobarlo es aburrida y funciona: recorrer la página solo con el teclado, y después mirar el árbol de encabezados. Si con el tabulador llego a todo lo que se puede pulsar y en el orden en que se lee, y si la lista de encabezados se parece a un índice del contenido, la base está bien. Si al tabular el foco desaparece o salta a sitios raros, hay componentes falsos montados sobre elementos que no eran.

En este sitio la estructura de cada página está pensada así desde el principio, no parcheada después. Es mucho más barato: reconstruir la accesibilidad de una web terminada cuesta bastante más que haberla marcado bien desde el primer día, como cuento en el área de accesibilidad.

Errores frecuentes

Elegir el encabezado por su tamaño. El nivel de un encabezado indica jerarquía, no tipografía. Si un <h2> te parece demasiado grande, se cambia con CSS. Bajarlo a <h4> para que se vea más pequeño rompe el índice de la página para todo el mundo, incluido Google.

Usar <div> para lo que ya existe. Botones, enlaces, casillas, desplegables. El navegador te regala teclado, foco y anuncio correcto si usas el elemento nativo. Reimplementarlo con ARIA es posible, es mucho trabajo y casi siempre queda peor.

Formularios sin <label>. Un campo cuyo texto explicativo es solo un párrafo al lado, o un marcador de posición dentro de la caja, es un campo que se anuncia como «campo de texto, en blanco». Además, el <label> bien asociado amplía la zona pulsable, lo que ayuda a cualquiera con un móvil en la mano.

Tablas para maquetar y <div> para datos. El intercambio clásico, y en los dos sentidos. Una tabla sirve para datos con filas y columnas relacionadas, y entonces necesita sus encabezados de fila y columna marcados. Para colocar cosas en pantalla está el CSS.

Creer que ARIA arregla el HTML malo. La primera regla de ARIA es no usar ARIA si existe un elemento HTML que ya hace el trabajo. Añadir roles encima de un marcado equivocado suele empeorar la experiencia: acaba anunciándose una cosa que se comporta como otra.