La Web es Tu A11y — Construyendo Aplicaciones Web Accesibles Usando la Plataforma

Quiero hablar sobre accesibilidad, y más específicamente, quiero hablar sobre accesibilidad web y cómo construir más accesible en la web simplemente usando la plataforma. Y lo que quiero decir con eso es que quiero mostrar ejemplos prácticos de cómo usar HTML y CSS modernos para obtener muchas de esas cosas de accesibilidad de manera predeterminada simplemente usando HTML correctamente.

Quiero comenzar con lo básico para que todos estén en la misma página. Espero que la mayoría de las personas que vean esto ya estén en la mentalidad de que la accesibilidad es importante y por qué, pero también sé que muchas personas luchan por convencer a otros miembros de su equipo o en su empresa u otros interesados de esa importancia y por qué necesita ser considerada como parte de la construcción de su aplicación web. Personalmente, creo que es bastante sorprendente y triste ver con qué frecuencia las conversaciones sobre accesibilidad terminan rápidamente en como el rincón de la mayoría de nuestros usuarios como que realmente no, no se ven afectados por la discapacidad, por lo que no es una gran prioridad para nosotros, así que no realmente lo estamos considerando.

Esto es frustrante en múltiples niveles. Puede que hayas visto este número antes, a menudo se menciona cuando se habla de accesibilidad. Es de estudios recientes de la OMS que encontraron que se estima que 1.3 mil millones de personas en el mundo experimentan discapacidades significativas, eso es uno de cada seis de todas las personas en el mundo. Y básicamente decir como nuestros usuarios, si no experimentan eso, es decir que activamente no quieres que ninguno de esos 16% sea parte de tu mercado potencial, lo cual es una locura. Pero incluso ignorando eso, realmente no muestra la imagen completa porque este número del 16% realmente solo habla de lo que llamaríamos discapacidades permanentes. Así que eso es personas con discapacidades visuales o de movimiento, tal vez discapacidades cognitivas como dislexia y TDAH.

Pero hay al menos dos categorías más de las que deberíamos hablar. Una son las discapacidades temporales, por lo que generalmente están relacionadas con alguna forma de lesión. Así que tal vez te has roto la pierna o te has roto el brazo y tu movilidad está temporalmente limitada o has tenido una cirugía ocular y tu visión está temporalmente afectada. Y luego tenemos discapacidades situacionales. Tal vez estás sosteniendo algo como un bebé, lo que significa que no puedes usar tu laptop o tu teléfono de la misma manera que lo harías normalmente o estás afuera y el sol brilla sobre tu dispositivo y el resplandor del sol hace que sea realmente difícil ver el contraste, este tipo de cosas. Todas ellas, las tres categorías te afectan de manera similar.

La diferencia realmente es solo cuán rápido ese efecto desaparece, si es que lo hace. Pero muestra como estas dos últimas categorías definitivamente afectan a todos de alguna forma o manera en algunas partes de su vida. Así que toda la discusión en torno al 16% se mueve muy rápidamente en mi opinión si miras eso porque muestra que si construyes para la accesibilidad, construyes para todos, no solo para el 16%.

También me gusta mucho la definición del equipo de Mozilla que han puesto en la documentación para desarrolladores en su sitio web, que dice que la accesibilidad es la práctica de hacer que tus sitios web sean utilizables por la mayor cantidad de personas posible. Y me gusta por múltiples razones. Por un lado, lo llama una práctica. Así que señala que no es algo que se hace una vez y se termina. Tienes que pensar activamente en ello y hacerlo.

Y cambia el lenguaje de accesibilidad a usabilidad, lo cual encontré que hace que sea mucho más fácil cuando hablas con otras personas en un equipo o interesados y hacer que entiendan por qué te importan tanto estos esfuerzos. Y creo que es triste que tengamos que hacer eso. Pero como conclusión de esto, si estás en esta situación donde estás tratando de abogar por más prácticas de accesibilidad, tal vez intenta cambiar tu lenguaje para ayudar a otros a entender cuál es tu motivación detrás de ello.

Hay otro principio más que quiero explicar como parte de la transición de esto a cómo todo esto se aplica a la web y eso es affordances. Así que en su libro diseño de cosas cotidianas, Don Norman define una gama de cinco patrones diferentes que determinan si los objetos cotidianos están bien diseñados o no. Y dos de esos son relevantes para nosotros, que son affordances y signifiers. Y básicamente dice que los affordances te dicen solo con mirar un objeto qué acciones están disponibles.

dice que los affordances te dicen solo con mirar un objeto qué acciones están disponibles. Y luego los signifiers te dicen cómo realizar esas acciones correctamente. Y como ejemplo, si tienes una tetera, solo la forma de la tetera te dice que se supone que debes verter algún tipo de líquido en ella. Y luego la forma de la boquilla te dice que la acción del dispositivo es verter ese líquido en otros objetos.

Y esa es la idea detrás de esto, que los objetos te dicen para qué se usan y cómo usarlos solo a través de su diseño. Y creo que esto se traduce en la web porque tenemos estos affordances y signifiers en el lenguaje en HTML para nosotros. Y para mí, hay tres capas para eso. La primera es landmarks. Así que tenemos estos elementos de landmarks como header y main site. Usualmente no vienen con funcionalidad, pero le dicen al navegador dónde estás en tu aplicación.

Y esto ayuda a tecnologías asistivas como lectores de pantalla o extensiones de navegador, ese tipo de cosas, a navegar por tu sitio web de manera mucho más eficiente y mucho más rápida. La segunda capa es lo que llamaríamos elementos de HTML semántico. Así que esa es la esencia donde tenemos elementos HTML que realmente tienen funcionalidad, patrones comunes de UX integrados en ellos. Y luego hay una tercera capa de atributos de área donde podemos aplicar atributos a cualquier elemento para describir más qué son, cómo usarlos y en qué estado podrían estar y ese tipo de cosas. Así que esta tercera capa es lo que la gente usualmente piensa inmediatamente cuando empiezas a hablar sobre accesibilidad. Pero creo que es importante pensar en las tres capas como una especie de lista de prioridades. Cuando estás construyendo algo, comienza a pensar si esto es un landmark.

Si no, ¿la funcionalidad que estás tratando de implementar ya está cubierta por elementos HTML semánticos? Incluso si no es completamente, pero como si pudieras usarlo como base y luego construir sobre eso, ya obtienes mucha funcionalidad gratis esencialmente. Y solo si eso no es cierto, recurre a los atributos de área porque los atributos de área usualmente no vienen con ninguna funcionalidad en absoluto. Solo te ayudan a describir cuál es el comportamiento deseado. Y todavía depende de ti implementar realmente ese comportamiento.

Y para mostrar eso, pasemos por algunos ejemplos. Y de hecho, comencemos con un ejemplo que, con suerte, muestra cuán poderosos pueden ser los elementos HTML semánticos. Y para esto, tenemos un botón muy básico aquí. Pero es un div, pero tiene un controlador de unclick. Así que unclick, queremos aumentar el contador. Y solo a primera vista, esto parece estar bien, ¿verdad? Como que hace lo que quiero que haga. Pero si miras un poco más profundo, rápidamente se desmorona. Como la primera cosa que podría querer intentar es usar controles de teclado y tabular en este botón.

Pero no puedo porque el botón es un div y por defecto, los divs no son enfocables. Pero conozco mi HTML básico, sé que hay un atributo de rol que puedo poner en él para decirle al navegador que esto es un botón. Pero como dije, estos atributos no vienen realmente con funcionalidad. Así que todavía no puedo enfocar el botón. Para eso, realmente necesito agregar un índice de tabulación. Porque ahora tiene un rol para los lectores de pantalla y otras tecnologías saben que es un botón y lo anuncian como un botón. Ahora también puedo enfocarlo para que ese anuncio realmente ocurra. Así que si ahora intento tabular en el botón, eso funciona.

Pero no puedo activarlo. Como que no puedo presionar enter o barra espaciadora para activar el onclick. Así que para eso, realmente necesito tener manualmente un controlador de onkeydown que escuche todas las pulsaciones de teclas, verifique si es un enter o un espacio, y luego ejecute el onclick. Así que ahora si tabulo en este botón, puedo presionar enter y espacio y simplemente funciona.

Ahora, hay muchas más preocupaciones que vienen con esto. Si quiero deshabilitar el botón, no puedo simplemente usar una propiedad disabled, tengo que deshabilitarlo con ARIA. Nuevamente, ARIA no viene con funcionalidad. Así que tengo que agregar una verificación real en mi controlador de clic, solo ejecutar el controlador si no está deshabilitado. Tampoco por especificación, no quiero poder enfocar botones deshabilitados.

Así que ahora necesito usar ese estado para también verificar, como, ¿necesito establecer el índice de tabulación en menos uno o cero? Podría seguir y seguir con esto. Espero que esto muestre cuánto esfuerzo realmente se necesita para intentar construir cualquiera de estos elementos HTML semánticos desde cero, donde podríamos simplemente usar en este caso, el elemento button y nos da todo eso gratis.

Y ha estado disponible ampliamente desde 1997. ¿No es increíble? Así que sí, de nuevo, esto podría parecer un ejemplo muy extremo al mismo tiempo. Estoy seguro de que muchos de nosotros realmente hemos visto esto en el mundo real. Y solo muestra que vale la pena confiar en estos elementos especificados que han pasado por años de especificación donde personas muy inteligentes han pensado en preocupaciones, incluida la accesibilidad.

Muy bien. Ahora quiero mirar un par de otros elementos que quizás no conozcas porque son más nuevos o los has conocido, pero como que no los has usado mucho. Así que realmente no sabes cómo usarlos. El primero es el componente de diálogo. Así que de nuevo, un patrón UX muy común donde tenemos esta cosa de diálogo que queremos abrir y cerrar y diálogos que básicamente bloquean el resto de la página para que no se pueda interactuar con ella.

Así que no queremos poder interactuar con nada en el fondo mientras el diálogo está abierto. Y esto solía hacerse con mucho JavaScript, pero desde hace un tiempo ahora hemos tenido los elementos de diálogo. Y con él vienen dos nuevos atributos en el elemento button que nos ayudan a interactuar con el diálogo sin ningún JavaScript en absoluto. Así que en el diálogo, le damos un ID para identificarlo. Y luego en el button, tenemos un comando de mostrar más diálogo. Y en el comando para, simplemente apuntamos al diálogo que queremos abrir.

Y en el comando para, simplemente apuntamos al diálogo que queremos abrir. Y eso es todo lo que se necesita para obtener esa primera interacción. Y en el diálogo, tenemos un botón de comando close que nos ayuda a cerrar el diálogo. Y como todo es HTML, podemos usar CSS para apuntar a cosas específicas para personalizar el aspecto y el comportamiento de ciertas cosas. Así que podemos estilizar el fondo. Así que si quisiéramos hacerlo verde, por ejemplo, podemos fácilmente hacerlo. Pero también podemos hacer cosas como cosas más avanzadas como animaciones. Como podemos animar el diálogo dentro y fuera, especialmente incluso si añadimos dinámicamente el elemento DOM a él, podemos usar animaciones discretas y estilos de inicio para definir dónde debería comenzar la transición en cualquier caso dado. Y en este caso, queremos escalarlo dentro y desde opacidad cero a uno, y podemos hacerlo fácilmente para dentro y fuera, lo cual es realmente poderoso. Y si no has mirado los diálogos debido a estas restricciones, todo esto está disponible desde 2024, así que desde hace bastante tiempo.

Y todos los navegadores principales definitivamente échale un vistazo de nuevo y dale otra oportunidad. Un patrón muy similar son los popovers, donde la principal diferencia es con los elementos popover, todavía aparecen, pero no deberían bloquearnos de interactuar con el resto de la página. Para eso, no es un elemento dedicado. Es solo un atributo popover que se puede poner en cualquier elemento, pero el patrón es el mismo. Le damos un identificador único y luego tenemos un atributo de objetivo popover en el botón, que le dice al navegador si hago clic en este botón, eso es lo que quiero abrir. Pero por defecto, simplemente se abre en el medio de la página, lo cual no es realmente lo que quieres con los popovers. Los popovers, quieres posicionarlos en relación con su disparador. Y podemos hacer eso con anclas CSS. Así que eso ha estado finalmente disponible desde principios de este año. Así que de nuevo, definitivamente échale un vistazo si no lo has hecho. Básicamente nos permite en los elementos disparadores, en este caso el botón, podemos darle al botón un nombre de ancla. Y luego en el propio popover, podemos decir posición absoluta y posición relativa a esa ancla. Y luego podemos usar el área de posición para decir como dónde en relación con el ancla queremos posicionarlo. Así que ahora mismo, centro inferior, si cambiamos eso a superior, va al centro superior. Y se encarga de toda la magia de colisión por nosotros. Así que calcular si hay suficiente espacio, de lo contrario empujarlo un poco o voltearlo al otro lado.

El navegador hace todo esto por nosotros, pero tenemos control total a través de CSS, lo cual es bastante genial. Y cuando hablamos de popovers, lo siguiente que probablemente pienses son los tooltips. Porque tienen un comportamiento muy similar, solo en diferentes interacciones. Así que usualmente quieres activar los tooltips cuando pasas el ratón sobre un elemento, y no puedes hacer eso con la API de popover.

y no puedes hacer eso con la API de popover. Así que para eso, esto es muy experimental. Esto es Chrome jugando con cosas. Tenemos un nuevo atributo que es interest for. Todavía usa el popover como su objetivo, pero es un nuevo atributo en el botón que le dice que, oye, cada vez que este evento de interés ocurra, que por defecto es el evento hover, abre este popover. Y luego tenemos nuevas habilidades de CSS para especificar comportamientos alrededor de estos eventos de interés. Así que tener un retraso de 300 milisegundos antes de que realmente lo muestres porque usualmente con tooltips, no quieres mostrarlos inmediatamente para que no se vuelvan realmente distractores. Pero cuando sigo pasando el ratón, aparece y nos da esa habilidad.

Así que todo esto es para decir, mantén un ojo en ese espacio. De nuevo, esto es muy experimental, pero con suerte este espacio evoluciona hacia una API que otros navegadores también estén felices de comenzar a adoptar y construir alrededor. Lo siguiente es un favorito personal mío. Son los acordeones. Creo que hemos tenido las etiquetas details y summary desde hace mucho tiempo, pero no creo que la gente las use lo suficiente. Y para mí, hay dos razones principales por las que deberías usarlas, especialmente si construyes como documentación y software, las usas mucho para ocultar más contenido hasta que sea necesario. Así que básicamente lo que esto te da es ese estilo de acordeón, puedes hacer clic en él y expande el contenido que está oculto dentro de él. Obviamente, se encarga de la gestión de estado por ti. Así que no se necesita JavaScript. Tienes el estado de encendido y apagado. Tienes toda la accesibilidad con ello también. De nuevo, puedes enfocarte en él, usar el teclado, etcétera. Pero más que eso, se ocupa de otras preocupaciones como la descubribilidad. Así que lo tengo cerrado ahora mismo, pero si busco y lo que estoy buscando está en el contenido del acordeón, se expandirá automáticamente y saltará a ese lugar por mí. Y esto es muy difícil o imposible de implementar manualmente en CSS, en JavaScript. Así que de nuevo, usando el poder del HTML y CSS incorporados, esto es realmente genial aquí.

Si una de tus preocupaciones era, en realidad quiero el comportamiento donde solo uno de un grupo de acordeones esté abierto a la vez, esto está recién disponible desde 2024 con un atributo de nombre. Así que si hago clic en el segundo primero, se cierra automáticamente, ¿verdad? Otro elemento que probablemente sea más emocionante para el público más amplio aquí es select. Así que los selects han sido un dolor desde que comencé como desarrollador. Y esto es realmente emocionante para mí poder comenzar a personalizar completamente el aspecto y la sensación de los selects. Así que este es nuestro select estándar que conocemos y odiamos en las mejores partes. Podemos personalizar como el disparador hasta ciertos puntos, pero el menú, no podemos.

Así que todo lo demás se elimina. Ahora, de nuevo, esto es experimental. Esto es solo para Chromium en este momento, pero la idea es construir sobre el elemento select existente y simplemente agregar una nueva apariencia que podamos aplicar. Y cuando lo configuramos en base select, el navegador sabe, oye, no lo renderices como algo normal. Renderiza esto de una manera nueva y personalizable. Y lo que esto nos permite hacer es realmente renderizar HTML dentro de nuestras opciones del menú select. Y esto lo hace realmente poderoso mientras seguimos obteniendo mucho comportamiento del navegador de forma gratuita, manteniendo el seguimiento de tu estado seleccionado, etcétera.

También viene con este elemento de contenido seleccionado, y podemos renderizar un botón dentro del componente select, que luego es un elemento disparador totalmente personalizable. Así que reemplaza el disparador incorporado. Y podemos hacer lo que queramos con esto, como "te elijo a ti". Y este contenido seleccionado es solo un ayudante que automáticamente toma como el HTML de la opción actualmente seleccionada. Y luego aún podemos apuntar a eso con CSS y estilizarlo más y hacer lo que queramos dentro del disparador. Así que de nuevo, muy experimental. Definitivamente habrá muchos cambios, pero se siente mucho más avanzado que intentos previos de selects personalizables. Y estoy realmente esperanzado y deseando que esto se convierta en un estándar en todos los navegadores.

Ahora, el último del que quiero hablar es de los carruseles, porque de nuevo, muy similar. Es un patrón de UX muy común. Tenemos este contenedor desplazable, pero queremos dar más como affordances al usuario para navegar por este contenedor. Así que lo que ya podemos hacer desde hace mucho tiempo es tener comportamiento de desplazamiento y snap de desplazamiento. Esto nos permite forzar al navegador a ajustar a ciertas posiciones de desplazamiento. Así que nuestros elementos de carrusel siempre están centrados, lo cual es agradable. Pero aún quiero más elementos de navegación para ayudar al usuario a navegar el carrusel en primer lugar. Y para eso, de nuevo, experimental. De nuevo, solo Chromium. Pero hay dos propuestas que ayudarán con eso. La primera es el pseudo selector de botón de desplazamiento, que se aplica al carrusel en sí y nos permite pasar en qué dirección queremos que este botón de desplazamiento active el desplazamiento. Y luego podemos estilizarlo completamente como queramos, pero el navegador se encargará automáticamente de activar el desplazamiento por nosotros en combinación con el snap. Esto es realmente agradable en ese sentido de acordeón, pero también se encargará del estado deshabilitado. Así que deshabilitará automáticamente estos botones cuando te desplaces hasta un extremo u otro y los habilitará de nuevo. Y es totalmente accesible, así que accesible con teclado, desde el principio, sin que tengas que siquiera pensar en eso.

La segunda parte son los marcadores de desplazamiento. Así que si quiero mostrar dónde estás en el carrusel y cuántos elementos de carrusel hay, podemos usar el grupo de marcadores de desplazamiento, que se aplica al carrusel, que solo define este contenedor. Y luego en cada elemento del carrusel definimos el marcador de desplazamiento que se inserta en ese grupo. Y de nuevo, totalmente personalizable, pero no solo pueden permitirme mostrar dónde estás, sino que también son interactuables. Así que puedo hacer clic en los marcadores y desplazará el contenedor a ese punto para mí. Y de nuevo, es accesible con teclado, así que puedo enfocarlos y luego usar las teclas de flecha para navegar. Vale la pena estar atento, vale la pena estar generalmente atento, más y más de estos patrones comunes de UX están siendo adoptados a través de especificaciones en el núcleo de HTML y CSS, lo cual es bastante genial de ver.

Ahora, quiero hablar muy rápidamente sobre la IA, porque muchas personas esperan que con la IA, la accesibilidad se resolverá en el futuro, porque la IA simplemente construirá aplicaciones accesibles desde el principio y todo lo relacionado. Y una de las grandes esperanzas es que la IA ayudará con las pruebas de accesibilidad, porque uno de los grandes problemas con las pruebas de accesibilidad es que es muy manual, de mucho esfuerzo. Y eso es porque la mayoría de los problemas no pueden ser probados automáticamente. Así que los estudios han demostrado que incluso en las mejores estimaciones con herramientas automatizadas realmente buenas, solo estás detectando del 30 al 40% de los problemas de accesibilidad, lo que significa que hasta el 70% de los problemas permanecerán sin detectar y requerirán pruebas manuales. Así que este es uno de los potenciales que muchas personas dicen que podría ayudar con pruebas automatizadas mejoradas, con lo cual estoy de acuerdo. Especialmente cuanto más podamos dar control a la IA sobre el navegador y dejar que describa cuál es el comportamiento deseado, espero que haya más capacidades. No creo que lo cubra completamente, pero al menos más que esos 30 a 40%. Otras áreas son como la generación automatizada de contenido accesible boutique como texto alternativo. Lo vemos en más y más aplicaciones que si subes imágenes, habrá un texto alternativo generado automáticamente en tus cosas de redes sociales para ti. Soy escéptico de eso. Como sí, esto es bueno si funciona. Si no es correcto, puede hacer más daño que bien. Así que solo ten cuidado con eso. Y luego están las herramientas de generación de código. Y cuanto más usemos herramientas de generación de código, más esas herramientas pueden realmente aplicar accesibilidad al código que estamos generando. Pero aquí es donde para mí están los riesgos. Así que contenido de baja calidad en el que se entrenan los modelos significa que esas herramientas de generación de código que usamos hoy probablemente no sigan las mejores prácticas en torno a la accesibilidad en todos los aspectos. Así que basura entra, basura sale. Si no mejoramos nuestros modelos mejor, si no mejoramos el código que usamos para entrenar esos modelos mejor, no obtendremos mejor código gratis. Esto se relaciona con los sesgos cada vez que entrenamos esos modelos que generan nuestro código. Están entrenados con sesgos, eso es inevitable. Solo significa que necesitamos ser conscientes de ello. Como qué sesgos están entrando en los datos de entrenamiento y cómo afecta la accesibilidad.

Y para mí, el más grande es el primero aquí, y el riesgo, el fenómeno del checkbox. Así que las empresas que ven esas herramientas de IA que te prometen accesibilidad gratuita usarán eso como un argumento para decir, está bien, hemos hecho nuestra parte en torno a la accesibilidad, así que estamos bien, aunque esas herramientas no cumplirán al 100% con lo que necesitamos. Y luego hace que esas conversaciones sobre accesibilidad sean aún más difíciles de lo que son hoy.

Así que quiero dejar una nota final basada en todo esto. No creo que la web esté bien en este momento, y especialmente con la IA y la generación de código cada vez más. Quiero que pienses en la próxima vez que uses una aplicación web, toma un papel y anota cada vez que te encuentres con un problema de accesibilidad. Así que si intentas enfocar un elemento pero no puede ser enfocado porque no es realmente un botón, es solo un div, o puede ser enfocado pero no puedes ver el enfoque porque el diseñador decidió que el anillo de enfoque es feo, así que lo eliminaron.

O intentas abrir un enlace en una nueva pestaña con un comando de clic y no se abre en una nueva pestaña porque no es realmente un atributo de ancla, solo está usando JavaScript para navegar. Todos estos problemas, anótalos, y creo que rápidamente te darás cuenta de lo rota que está la web en este momento y cuánto de ello hemos comenzado a aceptar. Y lo menciono porque todos nosotros, estamos trabajando en la web, así que siento que hay una responsabilidad y una oportunidad aquí, especialmente con la IA, para realmente cambiar esto para mejor.