Dos artículos publicados exactamente el mismo día:
- Bruce Lawson en Smashing Magazine: por qué debería elegir HTML5
<article>
Encima<section>
- Adam Laki en Pine: la diferencia entre
<section>
y<div>
Elemento
Están comparando cosas ligeramente diferentes, pero ambas involucran la <section>
elemento.
Lo encuentro bastante claro cuando buscas un <div>
: Cuando quieres que ese elemento sea esencialmente sin sentido. Solo lo está usando para fines de peinado.
Siempre pienso en RSS cuando pienso en <article>
: ¿Tendría sentido este pequeño detalle como entrada (que no necesariamente tiene que ser el contenido completo del artículo)? Si es así, use <article>
; si no, no lo hagas.
Bruce tiene una respuesta:
[…] pensar en <article>
no solo como un artículo de periódico o una publicación de blog, sino como una prenda de vestir, una entidad discreta que se puede reutilizar en otro contexto. Entonces tus pantalones son un artículo y puedes usarlos con un atuendo diferente; tu camisa es un artículo y se puede usar con diferentes pantalones; Tus botas stiletto de charol hasta la rodilla son un artículo.
Más importante aún, tiene algunas funciones reales. Bruce menciona que Apple WatchOS lo usa específicamente para buscar contenido en las páginas.
Pero <section>
es más nebuloso. En un momento, se suponía que debías pensar en las secciones como lugares donde tu <h1>
–<h6>
los encabezados se restablecían, pero eso nunca llegó a buen término porque requería algo llamado “Esquema HTML5” que no admiten navegadores.
Entonces deberíamos usar <section>
¿en absoluto? Según Bruce, ¡a veces! El diseño de los artículos de Smashing Magazine tiene un resumen al principio del artículo. Visualmente, eso es bastante claro, pero no tanto para los usuarios de lectores de pantalla. La solución fue envolver el resumen en un elemento con un aria-label
para dejar eso en claro. Pero se supone que no debes usar aria-label a menos que ese elemento también tenga un role
. Podrías aplicar un rol a un <div>
, pero <section>
ya tiene un buen rol predeterminado, entonces:
<section aria-label="quick summary">
Summary text
</section>
El artículo de Adam (lo siento, Adam) es muy vago en los puntos.
La principal diferencia proviene de la semántica. Si tiene una parte en su sitio o aplicación que tiene su lógica, debe utilizar la <section>
etiqueta para declararlo …
… usar <section>
cuando sea lógicamente correcto hacer que una parte de su sitio o aplicación sea legible para la tecnología de asistencia. Es un enfoque excelente si se tienen en cuenta los lectores de pantalla.
Entonces obtienes un role="region"
automáticamente para las secciones, pero no estoy seguro de que eso haga nada por los lectores de pantalla, sin la etiqueta. En una prueba rápida (Chrome para escritorio con VoiceOver habilitado), un <section>
sin un aria-label
simplemente no estaba en la sección de Puntos de referencia del Web Rotor, pero apareció una vez que tuvo un aria-label
.
El punto es: no solo use <section>
y suponga que está haciendo algo bueno por la accesibilidad. Su propósito es bastante limitado y solo es útil para establecer puntos de referencia. Incluso entonces, no estás ayudando mucho. Leonie Watson en los comentarios:
Cuando la elección es entre un encabezado visualmente oculto y un elemento de sección con un nombre accesible, hay un par de cosas a considerar antes de decidir qué enfoque es el correcto.
Cuando un elemento de sección tiene un nombre accesible, se convierte en un elemento de referencia navegable, por lo que un usuario de lector de pantalla puede usar la tecla de acceso directo de su lector de pantalla para navegar de uno a otro, al igual que puede hacer con los encabezados.
Sin embargo, según la encuesta más reciente de usuarios de lectores de pantalla de WebAIM, el 68% de los usuarios de lectores de pantalla prefieren navegar por encabezados en comparación con el 2,9% que prefieren puntos de referencia.
Entonces, desde un punto de vista estricto de accesibilidad, probablemente podría quitar el encabezado, pero desde un punto de vista de usabilidad realmente desea mantener el encabezado, al menos hasta que más usuarios de lectores de pantalla expresen su preferencia por usar puntos de referencia para navegar por el contenido.