Por qué deberías elegir el artículo HTML5 sobre la sección

Dije mi respuesta habitual: piensa en <article> no sólo como un artículo de periódico, o una entrada de blog, sino como una prenda de vestir – una entidad discreta que puede ser reutilizada en otro contexto. Así, tus pantalones son un artículo, y puedes llevarlos con otra ropa; tu camisa es un artículo, y puede llevarse con otros pantalones; tus botas de tacón de aguja de charol hasta la rodilla son un artículo (no te pondrías sólo una de ellas, ¿verdad?).

La especificación dice:

«El elemento artículo representa una composición completa, o autocontenida, en un documento, página, aplicación o sitio y que es, en principio, distribuible o reutilizable de forma independiente, por ejemplo, en sindicación. Puede tratarse de un post de un foro, un artículo de una revista o un periódico, una entrada de un blog, un comentario enviado por un usuario, un widget o gadget interactivo o cualquier otro elemento de contenido independiente.»

Así que una página de inicio con una lista de entradas de blog sería un elemento <main> que envolvería una serie de elementos <article>, uno por cada entrada de blog. Utilizarías la misma estructura para una lista de vídeos (piensa en YouTube) con cada vídeo envuelto en un <article>, una lista de productos (piensa en Amazon) y así sucesivamente. Cualquiera de esos <article>s es conceptualmente sindicable – cada uno podría estar solo en su propia página dedicada, en un anuncio en otra página, como una entrada en un feed RSS, y así sucesivamente.

El WatchOS de Apple contiene Reader que utiliza el elemento <article> para conocer el contenido principal de su página. Apple dice:

«Hemos llevado Reader a watchOS 5, donde se activa automáticamente al seguir enlaces a páginas web con mucho texto. Es importante asegurarse de que Reader destaque las partes clave de tu página web utilizando el marcado semántico para reforzar el significado y el propósito de los elementos del documento. Veamos un ejemplo. En primer lugar, indicamos qué partes de la página son las más importantes envolviéndolas en una etiqueta de artículo.»

Combinar <article> con microdatos HTML5 ayuda a Reader a construir la visualización óptima para pantallas de reloj pequeñas:

«En concreto, encerrar estos elementos de cabecera dentro del artículo garantiza que todos ellos aparezcan en Reader. Reader también aplica un estilo diferente a cada elemento de cabecera en función del valor de su atributo itemprop. Usando itemprop, podemos asegurar que el autor, la fecha de publicación, el título y el subtítulo aparecen de forma destacada.»

¿Y qué pasa con la <sección>?

Mi consejo habitual continúa: no te molestes con <section> ni te preocupes por su diferencia con <article>. Se inventó como una envoltura genérica de los encabezados para que el navegador pudiera determinar el contorno del documento HTML5.

¿El qué? El algoritmo del esquema del documento es una forma de utilizar una sola etiqueta de encabezado – <h1> – y hacer que se «convierta» mágicamente en el nivel correcto de encabezado (por ejemplo, que se convierta en un <h2><h3>, etc.), dependiendo de la profundidad a la que esté anidado en elementos de seccionamiento de HTML5:<article><section>, etc.

Así que, por ejemplo, esto es lo que has escrito en tu CMS:

<h1>My Fabulous article</h1><p>Lorem Ipsum Trondant Fnord</p>

Esto funciona brillantemente cuando se muestra como un artículo independiente. Pero, ¿qué pasa con su página de inicio, que es una lista de sus últimos artículos?

<h1>My latest posts</h1><article> <h1>My fabulous article</h1> <p>Lorem Ipsum Trondant Fnord</p></article><article> <h1>Another magnum opus</h1> <p>Magnum solero paddle pop</p></article>

En este ejemplo, según la especificación, los <h1>s dentro de los elementos <article> se «convierten» en <h2>s lógicos, porque <article>, al igual que <section>, es un elemento seccionador.

Nota: Esta no es una idea nueva. Ya en 1991, Sir Uncle Timbo escribió:

«De hecho, preferiría, en lugar de <h1><h2>, etc. para los encabezados tener un elemento anidable <SECTION></SECTION>, y un genérico <H></H> que en cualquier nivel dentro de las secciones produciría el nivel requerido de Heading.»

Desgraciadamente, sin embargo, ningún navegador implementa el contorno HTML5, por lo que no tiene sentido utilizar <section>. En un momento dado, el lector de pantalla JAWS intentó implementar el algoritmo de contorno del documento (en IE, pero no en Firefox) pero lo implementó con errores. Parece que a los desarrolladores de navegadores simplemente no les interesa (más detalles sórdidos en la sección de Lecturas Adicionales para los verdaderos anoraks).

«Pero», intervino otro amigo en la conversación, «ahora los navegadores muestran diferentes tamaños de fuente dependiendo de la profundidad a la que el <h1> esté anidado en <section>s», y procedió a probarlo. Una demostración similar. La columna de la izquierda muestra cuatro <h1>s, anidados en secciones; la columna de la derecha muestra un, <h1><h2><h3><h4> sin anidamiento. La captura de pantalla de Firefox muestra que los <h1>s anidados tienen por defecto la misma fuente que las etiquetas tradicionales <h1><h4>:

Los resultados son los mismos en Chrome, en los derivados de Chromium como Edge beta para Mac y en Safari en Mac.

¿Significa esto que todos deberíamos empezar a usar alegremente <h1> como nuestro único elemento de encabezamiento, anidándolo en <section>s?

No. Porque esto es sólo un cambio en el estilo visual de los h1. Si abrimos el inspector de accesibilidad de Firefox en devtools, podemos ver que el texto «nivel 2» está estilizado para que parezca un H2, pero sigue siendo de «nivel 1»: el árbol de accesibilidad no se ha modificado para que sea de nivel 2.

Compare esto con el H2 real en la columna de la derecha:

Esto muestra que el árbol de accesibilidad ha sido correctamente informado de que este es un encabezado de nivel 2. De hecho, Mozilla intentó comunicar el nivel calculado al árbol de accesibilidad:

«Experimentamos un poco con eso… pero tuvimos que revertirlo porque la gente de nuestro equipo de a11y se quejaba de demasiadas regresiones (bajando accidentalmente <h1> los niveles y tal).»

Para los usuarios de tecnologías de asistencia, una jerarquía adecuada de los encabezados es vital. Como muestra la octava encuesta de usuarios de lectores de pantalla de WebAIM,

«La utilidad de las estructuras de encabezamiento adecuadas es muy alta, ya que el 86,1% de los encuestados considera que los niveles de encabezamiento son muy o algo útiles.»

Por lo tanto, debes seguir utilizando <h1> hasta <h6>, e ignorar section.

Nunca digas nunca

«Pero…», estarás ahora balbuceando indignado, «¡hay un elemento <section> justo en esta misma página!». Y tendrías razón, querido lector. El «resumen rápido» está envuelto en un <section>, por razones de accesibilidad. Cuando la usuaria de lectores de pantalla Léonie Watson impartió su webinar «How A Screen Reader User Accesses The Web», señaló un área en la que el marcado de Smashing Magazine podría ajustarse para mejorar su experiencia.

Como puedes ver en la captura de pantalla, los artículos de Smashing van precedidos de un resumen rápido, seguido de una línea horizontal que separa el resumen del artículo propiamente dicho.

Pero el separador es puramente decorativo, por lo que Léonie no podía saber dónde termina el resumen y dónde empieza el artículo. Sugirió una solución: envolvimos el resumen en un elemento <section>:

<section aria-label="quick summary"> Summary text</section>

En la mayoría de los lectores de pantalla, un elemento <section> no se anuncia a menos que tenga un nombre accesible. En este caso, el texto de la etiqueta aria. Ahora, su lector de pantalla anuncia «Región de resumen rápido», y después del resumen «Fin de la región de resumen rápido». Este sencillo marcado también hace posible que un usuario de lector de pantalla pueda saltar el resumen si lo desea.

Podríamos haber utilizado un simple <div> pero entonces, como escribe Marco Zehe,

«Como regla general, si etiquetas algo a través de aria-label o aria-labelledby, asegúrate de que tiene un widget adecuado o un papel de referencia.»

Así que en lugar de usar <div role=”region” aria-label=”quick summary”>, elegimos <section> ya que tiene un rol incorporado de región y se aplica la ley infalible de Bruce de ARIA™: lo incorporado gana a lo atornillado. A lo grande.

Conclusión

Esperemos que hayas salido con estos consejos:

• No uses montones de <h1>s. Haz que <h1> sea el encabezado principal de tu página, luego usa <h2><h3><h4>, etc. en una jerarquía adecuada sin saltar niveles.
• <section> se puede utilizar con aria-label para señalar al usuario de un lector de pantalla dónde empieza y termina una subparte concreta de un artículo. En caso contrario, olvídate de él o utiliza otro elemento, como <aside aria-label=”quick summary”> o <div role=”region” aria-label=”quick summary”>.
• <main><header><footer> y <nav> son muy útiles para los usuarios de lectores de pantalla, y totalmente transparentes para los que no utilizan tecnología de asistencia. Así que úsalas.
• <article> no es sólo para las entradas del blog – es para cualquier cosa autocontenida. También ayuda a WatchOS a mostrar tu contenido correctamente.

Agradezco la ayuda de Léonie Watson en la redacción de este artículo. Cualquier error es totalmente culpa suya.

Lectura adicional

• «Encabezados y secciones», Recomendación HTML 5.2W3C (14 dic. ’17)Observa su advertencia: «Actualmente no se conocen implementaciones nativas del algoritmo de contorno … Por lo tanto, no se puede confiar en el algoritmo de contorno para transmitir la estructura del documento a los usuarios. Los autores deben utilizar el rango de encabezado (h1-h6) para transmitir la estructura del documento».
• «No hay algoritmo de contorno del documento», Adrian RoselliTodos los detalles sangrientos de cómo ha cambiado la especificación del algoritmo de seccionamiento.
• «ARIA en HTML», Borrador del Editor del W3C (19 dic. ’19)Reglas para vivir si te encuentras añadiendo roles y atributos ARIA a HTML.
• El valor práctico del HTML semántico», Bruce LawsonMi propio artículo, que enlaza con los detalles de cómo WatchOS utiliza HTML5 y microdatos.
(ra, il)