Bueno, mejor, excelente: desenredando el complejo mundo de los patrones accesibles

Marc Benioff declaró memorablemente que la única constante en la industria de la tecnología es el cambio. Después de haber trabajado en tecnología durante más de 15 años, puedo confirmarlo. Otros dinosaurios tecnológicos pueden dar fe de que la forma en que funcionaba la web en los primeros días es drásticamente diferente de lo que muchos de nosotros podríamos haber imaginado.

Si bien este cambio constante en la industria de la tecnología ha llevado a la innovación y los avances que vemos hoy, también ha introducido el concepto de elección. Si bien la elección, en la superficie, puede parecer algo intrínsecamente positivo, no siempre es igual a arcoíris y rosas. La afluencia del cambio tecnológico también trae consigo la fragmentación de los lenguajes de codificación y los sabores interminables de la "calor" de la programación. A veces, esta abundancia de opciones se convierte en un exceso de opciones, un deterioro cognitivo bien estudiado en el que las personas tienen dificultades para tomar una decisión debido a que tienen demasiadas opciones.

En este artículo, intentaremos desenredar el complejo mundo de los patrones accesibles, paso a paso. Comenzaremos revisando los patrones y bibliotecas accesibles actuales, luego consideraremos nuestras necesidades generales de patrones y las posibles restricciones y, por último, realizaremos una serie de ejercicios de pensamiento crítico para aprender a evaluar mejor los patrones de accesibilidad.

Qué enmarañada red tejemos

Overchoice se ha infiltrado en todos los aspectos de la tecnología, incluidos los patrones y las bibliotecas que usamos para crear nuestras creaciones digitales, desde la simple casilla de verificación hasta el modal dinámico complejo y todo lo demás. Pero, ¿cómo sabemos qué patrón o biblioteca es la correcta cuando hay tantas opciones? ¿Es mejor usar patrones/bibliotecas establecidos que los usuarios encuentran todos los días? ¿O es mejor crear patrones completamente nuevos para una experiencia de usuario más placentera?

Con la gran cantidad de opciones disponibles, podemos quedar paralizados rápidamente por la sobreabundancia de opciones. Pero si damos un paso atrás y consideramos por qué construimos nuestros productos digitales en primer lugar (es decir, el usuario final), ¿no tiene sentido elegir el patrón o la biblioteca que puede agregar el mayor valor para la mayor cantidad de personas? ?

Si pensabas que elegir un patrón o una biblioteca ya era un proceso lo suficientemente desalentador, este podría ser el punto en el que comiences a preocuparte. Pero no hay necesidad de preocuparse: elegir un patrón/biblioteca accesible no es ciencia espacial. Como todo lo demás en tecnología, este viaje comienza con un poco de conocimiento, una gran cantidad de prueba y error, y la comprensión de que no existe un patrón/biblioteca perfecto que se adapte a cada usuario, situación o marco.

¿Cómo sé esto? Bueno, he pasado los últimos cinco años investigando, creando y probando diferentes tipos de patrones accesibles mientras trabajaba en la Guía de estilo A11y, la biblioteca de patrones ARIA de Deque y evaluaba patrones SVG populares. Pero también he revisado muchos patrones y bibliotecas de clientes en todos los marcos/plataformas imaginables. En este momento, puedo decir sin reparos que existe una jerarquía innata para la accesibilidad de patrones que comienza a desarrollarse cuando miras lo suficiente. Y aunque ocasionalmente hay patrones que se deben evitar a toda costa, no siempre es tan claro. Cuando se trata de accesibilidad, diría que la mayoría de los patrones caen en gradientes de bueno, mejor, mejor. La parte difícil es saber qué patrón pertenece a qué categoría.

Pensando críticamente sobre patrones

Entonces, ¿cómo sabemos qué patrones son buenos, mejores y mejores en lo que respecta a la accesibilidad? Depende. Esta frase a menudo invocada por la comunidad de accesibilidad digital no es una excusa, sino una forma abreviada de "necesitamos más contexto para poder darle la mejor respuesta". Sin embargo, el contexto no siempre es claro, así que cuando construyo y evalúo la accesibilidad de un patrón, algunas preguntas fundamentales que hago incluyen:

• ¿Existe ya un patrón accesible establecido que podamos usar?
• ¿Qué navegadores y dispositivos de tecnología de asistencia (AT) admitimos?
• ¿Existen limitaciones de marco u otras integraciones/factores a considerar?

Por supuesto, sus preguntas específicas pueden variar de las mías, pero el punto es que debe comenzar a usar sus habilidades de pensamiento crítico al evaluar patrones. Puede hacer esto primero observando, analizando y luego clasificando cada patrón según su accesibilidad antes de tomar una decisión final. Pero antes de llegar a eso, profundicemos un poco más en las preguntas iniciales.

¿Ya existe un patrón accesible establecido?

¿Por qué parece que con cada nuevo marco obtenemos un nuevo conjunto de patrones? Esta reinvención constante de la rueda con nuevas opciones de patrones puede confundir y frustrar a los desarrolladores, especialmente porque generalmente no es necesario hacerlo.

¿No me crees? Bueno, piénselo de esta manera: si nos suscribimos al sistema de diseño atómico, entendemos que varios "átomos" pequeños de código se unen para crear un producto digital más grande. Pero en el mundo científico, los átomos no son el componente más pequeño de la vida. Cada átomo está hecho de muchas partículas subatómicas como protones, neutrones y electrones.

Esa misma lógica se puede aplicar a nuestros patrones. Si observamos más profundamente todos los patrones disponibles en los diversos marcos que existen, la estructura subatómica central es esencialmente la misma, independientemente del lenguaje de codificación real utilizado. Es por eso que aprecio las bibliotecas de codificación optimizadas con patrones accesibles que podemos desarrollar en función de las necesidades tecnológicas y de diseño.

Nota : algunas fuentes de buena reputación incluyen Componentes Inclusivos, Componentes Accesibles y el Sistema de Diseño Gov.UK, además de la lista de patrones accesibles que Smashing Magazine publicó recientemente (además de una lista más detallada de patrones y bibliotecas al final del artículo) .

¿Qué navegadores y dispositivos de tecnología de asistencia (AT) admitimos?

Después de investigar algunos patrones básicos que podrían funcionar, podemos pasar a la cuestión del navegador y la compatibilidad con dispositivos de tecnología de asistencia (AT). Por sí solo, el soporte del navegador no es una broma. Cuando agrega dispositivos AT y especificaciones ARIA a la mezcla, las cosas comienzan a complicarse... no es imposible, solo requiere mucho más tiempo, esfuerzo y proceso de pensamiento para resolverlo todo.

Pero no todo son malas noticias. Hay algunos recursos fabulosos como la accesibilidad de HTML5 y el soporte de accesibilidad que nos ayudan a comprender mejor el navegador actual + el soporte de dispositivos AT. Estos sitios web describen los diferentes subelementos de patrones HTML y ARIA disponibles, incluyen pruebas comunitarias de código abierto y proporcionan algunos ejemplos de patrones, tanto para navegadores de escritorio como móviles/dispositivos AT.

¿Existen limitaciones del marco de trabajo u otras integraciones/factores a tener en cuenta?

Una vez que hayamos elegido algunos patrones base accesibles y tengamos en cuenta la compatibilidad del navegador/dispositivo AT, podemos pasar a preguntas contextuales más detalladas sobre el patrón y su entorno. Por ejemplo, si usamos un patrón en un sistema de administración de contenido (CMS) o tenemos consideraciones de código heredado, habrá ciertas limitaciones de patrón. En este caso, un puñado de opciones de patrones se puede reducir rápidamente a uno o dos. Por otro lado, algunos marcos son más indulgentes y están abiertos a aceptar cualquier patrón, por lo que podemos preocuparnos menos por las restricciones del marco y centrarnos más en elegir el patrón más accesible que podamos.

Además de todo lo que hemos discutido hasta ahora, hay muchas consideraciones adicionales que se deben tener en cuenta al elegir un patrón, como rendimiento, seguridad, optimización de motores de búsqueda, traducción de idiomas, integración de terceros y más. Sin duda, estos factores influirán en su elección de patrón accesible, pero también debe pensar en las personas que crean el contenido. El patrón accesible que elija debe construirse de una manera lo suficientemente sólida como para manejar cualquier posible limitación en torno al contenido generado por el editor o el usuario.

Evaluación de patrones de accesibilidad

El código a menudo habla más fuerte que las palabras, pero antes de pasar a todo eso, una nota rápida de que los siguientes ejemplos de patrones no son los únicos patrones disponibles para cada situación, ni el que se considera "mejor" en el grupo es la mejor opción en el todo un mundo de patrones accesibles.

Para las demostraciones de patrones a continuación, debemos imaginar una situación hipotética en la que estamos comparando cada grupo de patrones contra sí mismos. Si bien esta no es una situación realista, realizar estos ejercicios de pensamiento crítico y evaluar los patrones de accesibilidad debería ayudarlo a estar más preparado cuando se encuentre con la elección de patrones en el mundo real.

Patrones de botones accesibles

El primer grupo de patrones que revisaremos para la accesibilidad son omnipresentes en casi todos los sitios web o aplicaciones: los botones. El primer patrón de botón usa la función del botón ARIA para imitar un botón, mientras que el segundo y el tercer patrón de botón usan el elemento HTML <button> . El tercer patrón también agrega aria-describedby y CSS para ocultar cosas visualmente.

Bien: role="button"

 <a role="button" href="[link]">Sign up</a>

Mejor: <button>

 <button type="button">Sign up</button>

Mejor: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

Si bien los primeros patrones parecen simples a primera vista, evocan algunas preguntas de accesibilidad. Por ejemplo, en el patrón del primer botón, vemos que ARIA role="button" se usa en el patrón "bueno" en lugar de un elemento HTML <button> . Pensando en términos de accesibilidad, dado que sabemos que el elemento HTML <button> se introdujo en HTML4, podemos especular razonablemente que es totalmente compatible con las últimas versiones de todos los principales navegadores y funcionará bien con la mayoría de los dispositivos AT. Pero si profundizamos y observamos el soporte de accesibilidad para ARIA role=“button”, vemos una ligera ventaja desde la perspectiva de la tecnología de asistencia, mientras que al elemento HTML <button> le faltan algunas áreas de cobertura del navegador + AT, especialmente cuando consideramos soporte de control de voz.

Entonces, ¿por qué el patrón ARIA no está en la categoría "mejor"? ¿ARIA no lo hace más accesible? No. De hecho, en casos como este, los profesionales de la accesibilidad a menudo recitan la primera regla de ARIA: no use ARIA. Esta es una forma irónica de decir usar elementos HTML siempre que sea posible. ARIA es realmente poderosa, pero en las manos equivocadas puede hacer más daño que bien. De hecho, el informe de WebAIM Million afirma que "las páginas con ARIA presente promediaron un 60 % más de errores que las que no". Como tal, debe saber lo que está haciendo cuando usa ARIA.

Otro problema en contra del uso de ARIA en esta situación es que la funcionalidad del botón que necesitamos debería construirse para el patrón role="button" , mientras que esa funcionalidad ya está preconfigurada en el elemento <button> . Teniendo en cuenta que el elemento <button> también es 100 % compatible con el navegador y es un patrón fácil de implementar, avanza ligeramente en la jerarquía cuando se evalúan los dos primeros patrones. Con suerte, esta comparación ayuda a acabar con el mito de que agregar ARIA hace que un patrón sea más accesible; a menudo, lo contrario es cierto.

El tercer patrón de botón muestra el elemento HTML <button> junto con aria-describedby vinculado a un elemento ID que se oculta visualmente con CSS. Si bien este patrón es un poco más complejo, agrega mucho en términos de contexto al crear una relación entre el botón y el propósito. En caso de duda, siempre que podamos agregar más contexto a la situación, mejor, por lo que podemos suponer que si está codificado correctamente, es el mejor patrón al comparar solo estos patrones de botones específicos.

Patrones de enlaces contextuales accesibles

El segundo grupo de patrones que revisaremos son los enlaces contextuales. Estos patrones ayudan a brindar más información a los usuarios de AT que la que se ve en la pantalla. El primer patrón de enlace utiliza CSS para ocultar visualmente la información contextual adicional. Mientras que los patrones de enlace segundo y tercero agregan atributos ARIA a la mezcla: aria-labelledby y aria-label , respectivamente.

Bueno: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Mejor: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

Lo mejor: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

Si bien los tres patrones de enlaces contextuales tienen el mismo aspecto, cuando inspeccionamos el código o los probamos con dispositivos AT, hay algunas diferencias obvias. El primer patrón utiliza una técnica CSS para ocultar el contenido visualmente para los usuarios videntes, pero aún muestra el contenido oculto para los usuarios de AT no videntes. Y aunque esta técnica debería funcionar en la mayoría de los casos, no se forma una relación real entre el enlace y la información adicional, por lo que la conexión es, en el mejor de los casos, tentativa. Como tal, el primer patrón de enlace es una buena opción, pero no es el patrón de enlace más sólido de los tres.

Los siguientes dos patrones de enlace son un poco más difíciles de evaluar. De acuerdo con las especificaciones de ARIA del W3C “El propósito de aria-label es el mismo que el de aria-labelledby . Proporciona al usuario un nombre reconocible del objeto”. Entonces, en teoría, ambos atributos deberían tener la misma funcionalidad básica.

Sin embargo, las especificaciones también señalan que los agentes de usuario dan prioridad a aria-labelledby sobre aria-label al decidir qué nombre accesible transmitir al usuario. La investigación también ha mostrado problemas relacionados con la traducción automática y los atributos de etiqueta aria. Entonces eso significa que deberíamos usar aria-labelledby , ¿verdad?

Bueno, no tan rápido. Las mismas especificaciones de ARIA continúan diciendo: "Si la interfaz es tal que no es posible tener una etiqueta visible en la pantalla (o si una etiqueta visible no es la experiencia de usuario deseada), los autores deben usar aria-label y no use aria-labelledby ”. Hablando de confusión, entonces, ¿qué patrón deberíamos elegir?

Si tuviéramos necesidades de traducción a gran escala, podríamos decidir cambiar el aspecto visual y escribir los enlaces con el contexto completo que se muestra (por ejemplo, " Lea más sobre esta cosa increíble ") o decidir usar aria-labelledby . Sin embargo, supongamos que no teníamos necesidades de traducción a gran escala o que no podíamos abordar esas necesidades de una manera razonable/accesible, y no queríamos cambiar lo visual, ¿entonces qué?

Según las recomendaciones actuales de ARIA 1.1 (con la promesa de traducción de aria-label en ARIA 1.2) más el hecho de que aria-label es un poco más fácil de implementar para los desarrolladores en comparación aria-labelledby , podríamos decidir ponderar aria-label sobre aria-labelledby en nuestra evaluación de patrones. Este es un claro ejemplo de cuando el contexto pesa mucho en nuestra elección de patrones accesibles.

Patrones <svg> accesibles

Por último, pero no menos importante, investiguemos un grupo de patrones de imágenes SVG para accesibilidad. Los SVG son una representación visual del código, pero código al fin y al cabo. Esto significa que un dispositivo AT puede pasar por alto una imagen SVG no decorativa a menos que se agregue el role="img" al patrón.

Asumiendo que los siguientes patrones SVG son de naturaleza informativa, se ha incluido un role="img" en cada uno. El primer patrón SVG utiliza <title> y <text> junto con CSS para ocultar visualmente el contenido de los usuarios videntes. Los siguientes dos patrones SVG involucran los elementos <title> y <desc> , pero con un atributo aria-labelledby agregado al último patrón.

Bueno: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

Mejor: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

Mejor: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

Primero veamos el primer patrón usando <title> y <text> y CSS oculto visualmente. A diferencia del texto anterior visiblemente oculto en los patrones, existe una relación inherente entre los elementos <title> y <text> , ya que están agrupados bajo el mismo paraguas de elementos SVG. Sin embargo, esta relación no es muy fuerte. De hecho, si mira hacia atrás en mi investigación sobre patrones SVG, vemos que solo 3 de 8 combinaciones de navegador/AT escucharon el mensaje completo. (Nota: el patrón de cerdo n.º 1 es equivalente al patrón de bombilla n.º 7).

Esto es cierto, aunque las especificaciones SVG del W3C en funcionamiento definen el elemento <text> como “un elemento gráfico que consta de texto... los caracteres que se dibujarán se expresan como datos de caracteres. Como resultado, los datos de texto en el contenido SVG son fácilmente accesibles para las personas con discapacidad visual”. Este primer patrón está bien, pero podemos hacerlo mejor.

El segundo patrón elimina el elemento <text> y lo reemplaza con un elemento <desc> . Las especificaciones W3C SVG establecen:

"El elemento secundario <title> representa una alternativa de texto corto para el elemento... y el elemento <desc> representa información textual más detallada para el elemento, como una descripción".

Lo que significa que los elementos <title> y <desc> en SVG se pueden usar de manera similar al texto alternativo de la imagen y las opciones de descripción larga que se encuentran tradicionalmente en los elementos <img> . Después de agregar el elemento <desc> al segundo SVG, vemos un soporte similar de navegador/AT con 3 de 8 combinaciones que escuchan el mensaje completo. (Nota: el patrón de cerdo n.° 2 es equivalente al patrón de bombilla de luz n.° 10). Si bien los resultados de estas pruebas parecen reflejar el primer patrón, la razón por la que este patrón pasa a la categoría "mejor" es que es un poco más fácil de implementar código. sabio e impacta a más usuarios de AT, ya que funcionó en JAWS, VoiceOver de escritorio y VoiceOver móvil, mientras que el primer patrón admitía combinaciones menos populares de navegador/AT.

El tercer patrón nuevamente usa los elementos <title> y <desc> pero ahora tiene un aria-labelledby plus ID agregado a la mezcla. De acuerdo con las mismas pruebas de SVG, agregar este código adicional significa que podemos admitir completamente 7 de 8 combinaciones de navegador/AT. (Nota: el patrón de cerdo n.º 3 es equivalente al patrón de bombilla de luz n.º 11). De los tres patrones SVG, este tercero es el "mejor", ya que es compatible con la mayoría de los dispositivos AT. Pero este patrón tiene un inconveniente al usar algunas combinaciones de navegador/AT; escuchará contenido de título/descripción de imagen duplicado para este patrón. Si bien es potencialmente molesto para los usuarios, diría que generalmente es mejor escuchar contenido duplicado que nada en absoluto.

Pensamientos finales

Si bien todos valoramos la elección en tecnología, me pregunto si hemos llegado a un punto en el tiempo en el que la sobreabundancia de opciones nos ha dejado paralizados y confundidos sobre qué hacer a continuación. En cuanto a la selección de patrones accesibles, podemos hacer preguntas directas sobre las opciones de patrón/biblioteca, compatibilidad con navegadores/dispositivos AT, limitaciones del marco y más.

Con los datos correctos en la mano, estas preguntas son bastante fáciles de responder. Sin embargo, se vuelve un poco más complicado cuando vamos más allá de los patrones y realmente consideramos a las personas que los usan. Es entonces cuando nos damos cuenta del impacto que tienen nuestras elecciones en la capacidad de éxito de nuestros usuarios. Como afirma elocuentemente el Prof. George Dei:

“La inclusión no es acercar a las personas a lo que ya existe, es crear un nuevo espacio, un espacio mejor para todos”.

Al tomarnos un poco más de tiempo para pensar críticamente sobre los patrones y elegir los más accesibles, sin duda crearemos un espacio más inclusivo para llegar a más usuarios, en sus términos.

Recursos Relacionados

Herramientas

• Soporte de accesibilidad, Michael Fairchild, a11ysupport.io
• Accesibilidad HTML5, Steve Faulkner

Bibliotecas de patrones

• Proyecto de Accesibilidad
• Guía de estilo de accesibilidad
• Componentes accesibles, Scott O'Hara
• Complemento de reordenación de lista accesible drag-and-drop , Harris Schneiderman
• Biblioteca de patrones ARIA de Deque
• Biblioteca de reacción accesible de Deque
• Sistema de diseño GOV.UK
• Componentes inclusivos, Heydon Pickering
• Sistema de diseño web de EE. UU. (USWDS)
• Tutoriales de accesibilidad web