Enlaces de accesibilidad

Austin Gil ha iniciado el primero de una serie de cinco partes sobre “Formularios HTML correctos” y comienza con la semántica. Se trata de hablarle a la multitud que “construimos nuestras interfaces con JavaScript”. El primer bloque de código es un ejemplo de envío de un formulario Ajax donde los datos enviados se recopilan a través de la API de JavaScript FormData.

¿Por qué es eso tan vital? Bueno, sin formetiqueta, no FormData. ¿Por qué más utilizar un formulario (aparte del envío con la tecla Intro)?

“Pero Austin, estoy construyendo un SPA . Por lo tanto, si el usuario ve el formulario, significa que JavaScript DEBE estar habilitado”. Y estarías en lo cierto. Aunque, si se trata de una forma importante, es posible que desees considerar admitir un mundo sin JS. Puede llegar el día en que desee implementar la RSS.

La renderización del lado del servidor (SSR) será cada vez más fácil de realizar a medida que sus beneficios se vuelvan cada vez más obvios. Google nos dice que una página representada por el lado del cliente tiene una cola de una semana para ser indexada y reindexada según los cambios. Sin mencionar que es casi seguro que SSR será mucho más rápido de cargar.

Inclusive Inputs de Oscar Braunert es una buena lectura de seguimiento, ya que comienza con un formulario HTML que está muy cerca de ser correcto, pero dolorosamente no lo es. (Pista: falta la etiqueta/conexión de entrada). Luego se adentra en patrones interesantes, como cómo marcar de manera accesible los campos obligatorios y los campos con errores. Como:

div  label for="password"    Password    span aria-hidden="true"*/span    spanrequired/span  /label  input     type="password"       name="password"    aria-describedby="desc_pw"    pYour password needs to have at least eight characters./p/div

Amber Wilson ingresa a los elementos HTML accesibles con la ventaja de evitar cualquier uso de ARIA:

Quizás sepa que los roles ARIA se utilizan a menudo con elementos HTML. No he escrito sobre ellos aquí, ya que es bueno ver cómo se puede seguir accediendo al HTML escrito sin ARIA.

Preguntad por dl.

Sarah Higley entra en ARIA en Roles y relaciones , pero nos advierte que tengamos mucho cuidado desde el principio:

[…] un practicante de accesibilidad en ciernes podría encontrarse experimentando con roles más serios como menu, listboxo incluso treegrid. Estos son patrones tentadores y poderosos que le permiten crear experiencias que no son compatibles únicamente con HTML básico. Desafortunadamente, también son frágiles; Incluso los pequeños errores en el uso de estos roles pueden llevar al usuario a un mal viaje.

Hable con sus hijos sobre ARIA antes de que sea demasiado tarde.

Lo ideal es no utilizar ARIA en absoluto. Pero si la accesibilidad se estropea hasta el punto de que no se puede arreglar en el nivel DOM, Sarah hace algunos trucos. Por ejemplo, se utiliza role="presentation"para eliminar esencialmente la función predeterminada de un elemento (cuando está en el camino).

Hablando de ARIA y de no usarlo a menos que sea necesario, una de las cosas que puedes hacer con ARIA son controles de etiquetas. Adrian Roselli tiene ideas sobre la mejor manera de hacerlo:

Esta es la prioridad que sigo al asignar un nombre accesible a un control:

1. Técnicas HTML nativas
2. aria-labelledbyApuntar a texto visible existente
3. Contenido visiblemente oculto que todavía se encuentra en la página
4.aria-label