Por qué, cómo y cuándo usar HTML semántico y ARIA | Programar Plus

El HTML semántico y las aplicaciones de Internet enriquecidas accesibles (ARIA) ayudan a crear interfaces que funcionan para todos de la manera más eficaz, sólida y sencilla posible. Agregan un significado esencial a su contenido, lo que permite que los navegadores web, los motores de búsqueda, los lectores de pantalla, los lectores de RSS y, en última instancia, los usuarios lo entiendan.

Y, sin embargo, mucha gente todavía no los usa. Quería saber por qué, así que configuré una encuesta de Twitter. La razón más común que dieron las personas fue la falta de conocimiento y comprensión de los beneficios de usar HTML semántico y ARIA.

Veamos los beneficios de usar HTML y ARIA, por qué comenzar con HTML semántico es el camino a seguir y por qué ARIA debería ser el último recurso.

Comenzando con texto sin formato

El <body> elemento de un documento HTML contiene el contenido principal que un usuario ve en una página. Si el contenido se coloca dentro del cuerpo sin ningún elemento adicional, el navegador no tiene forma de diferenciar entre diferentes tipos de contenido, como párrafos y encabezados.

<body>
A Study of Butterflies

Butterflies are little bugs with cute wings.

Butterfly Habitats

Butterflies live in flower houses and hang out at dank coffeeshops.
</body>

Si el navegador no puede diferenciar entre piezas de contenido, entonces no puede presentar ese contenido al usuario de una manera significativa. Eso significa:

  • No podemos diseñar los encabezados de manera diferente a los párrafos.
  • Es más difícil para los motores de búsqueda interpretar el contenido, lo que significa que es probable que se clasifique mal y sea difícil de encontrar para los usuarios.
  • Los lectores de pantalla y otras tecnologías de asistencia no pueden comunicárselo correctamente al usuario.

Sin mencionar que es más que un poco incómodo visualmente:

Una captura de pantalla del HTML representado en la parte frontal, que se muestra como una sola línea de texto.

Agregar algo de estructura con HTML

Para proporcionar algo de estructura, podríamos envolver las líneas de texto aquí en divs como este:

<div>A Study of Butterflies.</div>
<div>Butterflies are little bugs with cute wings.</div>
<div>Butterfly Habitats</div>
<div>Butterflies live in flower houses and hang out at dank coffeeshops.</div>

Esto es un poco mejor porque cada pieza de contenido se muestra en el navegador en su propia línea en lugar de una línea de texto larga e ininterrumpida.

Una captura de pantalla del HTML representado en el front-end que muestra el contenido en cuatro líneas, una para cada div.

Pero todavía hay una clara falta de significado.

¿Cuáles son títulos y cuáles párrafos? Es difícil saberlo e imposible de determinar para la tecnología de asistencia. Esto se debe a que los encabezados y los párrafos están envueltos en divisiones que no tienen sentido por sí mismas. En este ejemplo, los navegadores, CSS, motores de búsqueda y lectores de pantalla aún no son más sabios.

Comunicar significado con estilos

Podríamos agregar estilo a los divs porque se pueden orientar con CSS. Esto nos permite mejorar la apariencia visual para proporcionar significado, contexto y jerarquía.

ver la pluma
Demostración de HTML no semántico por Geoff Graham (@geoffgraham)
en CodePen.

Aquí, el CSS apunta al primer y tercer div para aplicar estilos de encabezado. Esto no se puede mantener porque otro párrafo agregado después, por ejemplo, se diseñaría como un encabezado.

Podríamos dar a cada div un atributo único, como una ID o un nombre de clase, para tener más control de estilo, como este:

<div class="heading1">A Study of Butterflies</div>
<div class="paragraph">Butterflies are little bugs with cute wings.</div>
<div class="heading2">Butterfly Habitats</div>
<div class="paragraph">Butterflies live in flower houses and hang out at dank coffeeshops.</div>

Explico por qué debería usar clases en lugar de ID para diseñar en mi libro en línea, MantenibleCSS.

Ahora podemos apuntar a los diferentes elementos con CSS de esta manera:

.heading1 { /* styles here */ }
.paragraph { /* styles here */ }
.heading2 { /* styles here */ }

Si bien este enfoque es un poco mejor, solo comunica el significado para los usuarios videntes. No proporciona significado a los motores de búsqueda, lectores de RSS y lectores de pantalla. En otras palabras, no es semántico y, como resultado, no es muy accesible.

Introduciendo HTML semántico

HTML proporciona muchos elementos que están diseñados para dar significado al contenido, incluidos elementos para encabezados y párrafos. Entonces, en lugar de depender de divs con clases nombradas por el desarrollador, podemos usar elementos HTML predefinidos en su lugar.

<h1>A Study of Butterflies</h1>
<p>Butterflies are little bugs with cute wings.</p>
<h2>Butterfly Habitats</h2>
<p>Butterflies live in flower houses and hang out at dank coffeeshops.</p>

¡Mucho mejor! Con HTML semántico como este, el contenido heredará los estilos predeterminados del navegador (también conocido como Agente de usuario). Incluso podemos usar otros elementos HTML semánticos, como <b> que le dice al navegador que “llame la atención” al poner el texto en negrita.

Una captura de pantalla del HTML representado en la parte frontal que muestra el contenido con una jerarquía más clara de Título 1, párrafo, Título 2 y párrafo, gracias al HTML semántico.

Crucialmente, usar HTML semántico también significa:

  • Podemos usar CSS para agregar nuestro propio estilo.
  • Los motores de búsqueda pueden indexar el contenido para que se clasifique lo suficientemente bien como para que los usuarios puedan encontrarlo.
  • Los lectores de RSS pueden analizar y diseñar los elementos de forma adecuada.
  • Los lectores de pantalla y otras tecnologías de asistencia pueden comunicar elementos adecuadamente al usuario.

Si bien no es muy importante en estos breves ejemplos, el código también es más conciso, lo que marca una gran diferencia cuando se considera un sitio completo.

El HTML semántico está basado en estándares y es estable. Esto significa que cualquier procesador HTML en el futuro podrá entenderlo y presentarlo correctamente a los usuarios. También ayudará a los autores de códigos posteriores si necesitan realizar cambios.

Beneficios adicionales del HTML semántico

Además de los beneficios que hemos cubierto hasta ahora, algunos navegadores agregan mejoras útiles al HTML semántico de forma gratuita.

Por ejemplo, usando la entrada de teléfono HTML (<input type="tel">) proporcionará a los usuarios un teclado específico para el teléfono en algunos navegadores móviles.

Identificar una entrada de formulario como un campo de teléfono producirá un teclado específico de teléfono en iOS. Sin embargo, tenga cuidado, porque es solo para números de teléfono y no para cualquier número, como tarjetas de crédito.

Otros navegadores brindan a los usuarios la opción de cambiar a una vista simplificada de la página, como el modo Lector de Safari. Sin HTML semántico, el modo lector produciría algo muy parecido a la cadena de texto de una línea con la que comenzamos. Pero, al usar HTML semántico, obtenemos una experiencia de lectura limpia sin ningún estilo adicional de nuestra parte:

La página Acerca de en mi sitio web personal vista con el Modo Lector de Safari, comparando HTML no semántico (izquierda) con HTML semántico (derecha).

Puede leer más sobre esto en el artículo de Mandy Michael sobre la creación de sitios web para Safari Reader Mode y otras aplicaciones de lectura.

Cuando ARIA mejora las cosas

Al igual que el HTML semántico, ARIA es un estándar W3 que ayuda a que las interfaces sean más accesibles para las personas que usan lectores de pantalla y otras tecnologías de asistencia para consumir contenido.

Error de mensajes son un buen ejemplo. Si un usuario deja un campo de formulario obligatorio en blanco, el HTML del error podría verse así:

<label for="first-name">First name</label>
<span>Enter your first name</span> 
<input type="text" name="first-name" id="first-name">

Un usuario vidente podrá ver el error encima del campo. Pero cuando un lector de pantalla se enfoca en la entrada, el error no se anunciará porque el mensaje de error no está vinculado a la entrada.

ARIA se puede usar para asociar el error con la entrada de esta manera:

<label for="first-name">First name</label>
<span id="first-name-error">Enter your first name</span>
<input type="text" name="first-name" id="first-name" aria-describedby="first-name-error">

Ahora el mensaje de error se anuncia cuando la entrada está enfocada.

Usando ARIA y JavaScript juntos

ARIA es más útil cuando se trata de JavaScript. Por lo general, se requiere JavaScript para crear interacciones más complejas y dinámicas, como ocultar, mostrar y cambiar elementos sin actualizar la página. Piense en alternar menús, acordeones, pestañas, autocompletar, tablas ordenables, cargar contenido y guardar, enviar u obtener datos. Mejorar interfaces como esta a menudo rompe la experiencia de los usuarios de lectores de pantalla.

Tome un botón que, cuando se selecciona, revela otro contenido. En el estado original, un usuario vidente verá inicialmente un botón y ningún contenido y, cuando se hace clic en el botón, aparece el contenido.

Sin embargo, un usuario con discapacidad visual con un lector de pantalla, por lo general, se basa en señales habladas mientras navega a través de una interfaz. Pero cuando un lector de pantalla se enfoca en el botón, no hay nada que le indique si el contenido está actualmente a la vista y necesita ser leído.

El aria-expanded El atributo se puede agregar al botón, y JavaScript puede alternar su valor entre verdadero (se muestra el contenido) y falso (el contenido está oculto). Esto ayuda a cumplir con el Principio de diseño inclusivo n.° 1 y brinda una experiencia comparable a los usuarios de lectores de pantalla.

<button aria-expanded="false">Toggle content</button>
<div hidden>Some content</div>

Trate de evitar el uso de ARIA para corregir HTML no semántico

Los atributos ARIA se pueden usar para hacer que el HTML no semántico sea más accesible para los usuarios de lectores de pantalla. Por ejemplo, un desarrollador que tiene dificultades para diseñar una casilla de verificación nativa en varios navegadores podría decidir usar un div y algo de JavaScript para emular uno.

Podemos agregar una función de casilla de verificación para hacer que el div se identifique como una casilla de verificación para los usuarios de lectores de pantalla:

<div role="checkbox"></div>

También debemos usar el aria-checked atributo para indicar si la casilla de verificación está marcada o no de esta manera:

<div role="checkbox" aria-checked="false"></div>

Pero, esto todavía no es suficiente para que se comporte como una casilla de verificación porque los divs no son enfocables por teclados como <input type="checkbox"> es. Podríamos hacerlos enfocables agregando tabindex="0":

<div role="checkbox" aria-checked="false" tabindex="0"></div>

Pero incluso entonces, una casilla de verificación real, cuando se envía como parte de un formulario, enviará su valor. Debido a que esta no es una casilla de verificación real, no enviará su valor sin usar JavaScript.

Y si eso no fuera suficiente, los usuarios pueden marcar o desmarcar una casilla de verificación real presionando la tecla Espacio. Y, el formulario al que pertenece la casilla de verificación se puede enviar presionando Entrar cuando la casilla de verificación está enfocada. Pero la casilla de verificación div-version no hará esto sin aún más JavaScript.

Esto no solo implica más trabajo y más código, sino que el enfoque solo funciona para las personas que usan tecnología que comprende estos atributos ARIA particulares. Eso es mucho esfuerzo, mucho código y muchos problemas que podemos evitar por completo si solo usamos HTML semántico:

<input type="checkbox">

No se puede negar que ARIA es útil en ciertas situaciones, pero comenzar con HTML semántico y accesible siempre que sea posible es infinitamente más simple y confiable. Por eso la primera regla de ARIA es no usarlo.

Conclusión

El diseño inclusivo se trata de proporcionar la mejor experiencia posible a la gama más amplia de usuarios. El HTML semántico ayuda a las tecnologías y, por lo tanto, a los usuarios a comprender el contenido de la web. Las mejoras que ofrecen algunos navegadores y dispositivos significan que los usuarios obtienen una experiencia aún mejor integrada.

Y cuando el HTML semántico por sí solo no es suficiente, ARIA puede proporcionar más contexto para los usuarios de tecnologías de asistencia, pero utilícelo con precaución. No es una cura dura y rápida para el marcado no semántico y puede volverse complicado, como vimos en el último ejemplo.

En resumen, haga el trabajo duro para que las cosas sean inclusivas. Es una victoria para usted y una victoria para la web.

(Visited 7 times, 1 visits today)