Cómo escalar la accesibilidad en Webflow

Webflow ocupa una posición única como plataforma de marketing web con capacidad de acción, ya que tenemos una doble responsabilidad en cuanto a accesibilidad. Debemos hacer que nuestra propia plataforma sea accesible y, además, ayudar a garantizar que los sitios que alojamos sean accesibles para sus millones de visitantes diarios.

En esta entrada de blog, compartiremos una visión interna de nuestros procesos y prácticas de accesibilidad en Webflow.

Comenzaremos con algunos de los beneficios de la accesibilidad. Luego, exploraremos cómo hemos creado una base sólida de accesibilidad en nuestro sistema de diseño interno y cómo esto impulsa la productividad en toda la organización de ingeniería. A continuación, describiremos algunas de nuestras estrategias para compartir conocimientos y elevar nuestro nivel colectivo en materia de accesibilidad. Por último, analizaremos el impacto que esto tiene en nuestra plataforma de marketing web y en nuestros usuarios, y cerraremos con algunos consejos sobre cómo tú también puedes escalar los esfuerzos de accesibilidad en tu empresa.

Beneficios de la accesibilidad

La Organización Mundial de la Salud (OMS) estima que el 16% de la población mundial vive con algún tipo de discapacidad. Eso es una de cada seis personas, una proporción mucho mayor de lo que la mayoría imagina. Estas discapacidades pueden ser visuales, auditivas, motoras, cognitivas, entre otras.

También es importante recordar que la accesibilidad beneficia a todo el mundo. Incluso si crees que tu base de usuarios no tiene muchas personas con discapacidad (¡probablemente te equivoques!), considera los siguientes ejemplos:

Admitir la navegación por teclado ayuda a los usuarios que dependen exclusivamente de él, así como a aquellos que se consideran "usuarios avanzados" y prefieren usar el teclado para navegar más rápido. Seguro que tú o alguien que conoces prefiere usar la tecla Tab para pasar de un campo a otro al rellenar un formulario en lugar de hacer clic en cada entrada con el ratón.

Usar un buen contraste de color ayuda a los usuarios que pueden ser daltónicos o tener baja visión, y también hace que la plataforma sea más fácil de usar en diversas condiciones de iluminación o con diferentes monitores. Además, a nadie le gusta entrecerrar los ojos para leer texto blanco sobre un fondo amarillo.

Proporcionar botones y áreas de clic con el tamaño adecuado facilita que los usuarios con discapacidades motoras interactúen con los elementos de la página. Además, es más cómodo para todos en general. Cualquiera que haya experimentado la frustración de cerrar un menú por accidente porque el cursor se salió de un elemento estrecho al mover el ratón puede dar fe de esta mala experiencia de usuario.

Recuerda que las discapacidades pueden ser permanentes, temporales o situacionales. Alguien que normalmente no se considera discapacitado, pero que ha sufrido una lesión en la muñeca, los dedos, los ojos o los oídos, agradecerá enormemente las tecnologías accesibles mientras se recupera.

La accesibilidad tiene una gran superposición con la usabilidad y las buenas prácticas de diseño. Cuando hablamos de hacer que una aplicación sea accesible, a menudo nos referimos a seguir prácticas recomendadas de experiencia de usuario bien fundamentadas.

Ahora que hemos establecido la importancia de la accesibilidad, veamos cómo implementamos estas mejores prácticas en nuestra organización de ingeniería.

Bases accesibles

En Webflow, hemos invertido mucho tiempo y energía en nuestro sistema de diseño interno. Para quienes no estén familiarizados con los sistemas de diseño, pueden pensar en ellos como una biblioteca de componentes con bloques de construcción reutilizables para crear una aplicación. Es una simplificación excesiva, porque un sistema de diseño es mucho más que eso, pero no entraremos en detalles por ahora.

Lo principal es que un sistema de diseño proporciona a los diseñadores e ingenieros todo lo que necesitan para diseñar y construir su aplicación.

Nuestro sistema de diseño contiene muchos componentes diferentes, tales como:

• Controles de formulario: Autocomplete, Button, Checkbox, FormLabel, Radio, Select, Switch, TextInput, TextArea
• Tipografía: Link, Text
• Contenido tipo ventana emergente: Menu, Modal, Popover, Toast, Tooltip
• Contenido de presentación: Accordion, Avatar, Badge, Banner, Note, RowItem, Table

Esta es una lista no exhaustiva de componentes, pero esperamos que puedas apreciar la amplitud de necesidades que cubre nuestro sistema de diseño.

Para cada uno de estos componentes, nos tomamos el tiempo necesario para garantizar que sean accesibles desde el primer momento. La ventaja es que cada ingeniero que utiliza nuestro sistema de diseño no necesita saber nada sobre cómo funcionan los componentes por dentro.

Por ejemplo, considera todo lo que implica hacer que un cuadro de diálogo modal sea accesible:

• El foco del teclado debe enviarse al cuadro de diálogo cuando este se abre
• El foco del teclado debe quedar atrapado dentro del cuadro de diálogo mientras este esté abierto
• Los lectores de pantalla solo deben poder acceder al contenido dentro del cuadro de diálogo mientras este esté abierto
• Los usuarios de ratón solo deben poder acceder al contenido dentro del cuadro de diálogo mientras este esté abierto
• La tecla Escape debe cerrar el cuadro de diálogo
• El foco del teclado debe volver al botón que activó el cuadro de diálogo cuando este se cierre
• Los cuadros de diálogo deben usar atributos y roles ARIA adecuados, como role="dialog", aria-modal="true", y ya sea aria-label o aria-labelledby para hacer referencia al título del cuadro de diálogo

(Hay muchos matices en algunos de los puntos anteriores. La Guía de prácticas de autoría WAI ARIA es un recurso excelente para consultar al considerar las mejores prácticas para cualquier tipo de componente de interfaz de usuario.)

Nos hemos tomado el tiempo necesario para asegurar que nuestro cuadro de diálogo modal tenga en cuenta todas estas consideraciones de accesibilidad. Esto significa que cuando un ingeniero necesita usar un diálogo para la función que está creando, simplemente puede usar el componente Modal sin tener que preocuparse por gestionar a dónde va el foco cuando el diálogo se abre o se cierra, ni por atrapar el foco dentro del diálogo o añadir el marcado ARIA correcto. Todo eso se gestiona por ellos, para que puedan concentrarse únicamente en el trabajo de la función.

No nos cansaremos de repetir los beneficios de un sistema de diseño en este aspecto.

En primer lugar, nuestro sistema de diseño aumenta la productividad de toda nuestra organización de ingeniería. Si podemos crear un componente una vez y reutilizarlo 50 veces en nuestra aplicación, nos ahorramos el problema de reinventar la rueda y construir el componente desde cero cada vez. Esto es especialmente importante para los componentes más complejos que requieren más tiempo para construirse correctamente.

En segundo lugar, nuestro sistema de diseño nos permite lograr coherencia en nuestra interfaz y experiencia de usuario. Si todos utilizan el mismo conjunto de componentes, estos se verán y se comportarán igual en todas partes.

En tercer lugar, nuestro sistema de diseño nos permite realizar mejoras y optimizaciones de manera eficiente. Supongamos que tenemos 50 instancias de un componente en nuestra aplicación. Si las 50 instancias utilizan el componente de nuestro sistema de diseño, podemos corregirlo en un solo lugar y aplicar esa mejora a todas las instancias en toda la aplicación. Esto es crucial para todo tipo de cambios: corrección de errores, nuevas funciones y mejoras de accesibilidad.

Formación continua

Nuestro sistema de diseño proporciona una base técnica excelente sobre la cual construir, pero no es suficiente por sí solo. No podemos permitirnos que solo un puñado de diseñadores e ingenieros sepan sobre accesibilidad. Necesitamos que todos en la organización de ingeniería, producto y diseño comprendan los fundamentos de la accesibilidad y sean capaces de aplicarlos en su trabajo.

Una de las herramientas más eficaces para la mejora continua de habilidades ha sido nuestro canal de Slack #accessibility. En este canal, las personas pueden hacer preguntas, aprender juntas y compartir logros en materia de accesibilidad.

Cada día laborable publicamos un "Consejo de accesibilidad del día", algo que llevamos haciendo más de un año. Hemos publicado más de 200 consejos y seguimos adelante. Estos consejos suelen estar más enfocados a la ingeniería y han cubierto temas como texto alternativo, contraste de color, indicadores de foco, navegación por teclado, navegación con lector de pantalla, diseño de componentes, atributos y roles ARIA, HTML semántico, patrones de diseño, herramientas automatizadas y más.

Lo divertido de estos consejos no es solo la amplitud de temas que hemos podido cubrir, sino que ayudan a mantener la accesibilidad presente de una forma que las sesiones de formación anuales no logran.

Integrado en nuestro proceso

Hasta ahora hemos cubierto nuestro sistema de diseño y nuestros esfuerzos de formación continua. ¿Qué hay de cómo abordamos la accesibilidad a lo largo del ciclo de vida del desarrollo de software?

La accesibilidad está integrada en nuestro proceso en cada paso del camino.

Cuando se diseñan nuevas funciones, las propuestas pasan por una revisión de diseño en la que se pueden identificar carencias, incluidos posibles problemas de accesibilidad. También contamos con un horario de atención específico para el sistema de diseño, donde ayudamos a desenredar esas dudas que son un verdadero quebradero de cabeza.

Cuando se desarrollan nuevas funciones, cada cambio en el código pasa por nuestra canalización de CI automatizada. Utilizamos linters como el paquete eslint-plugin-jsx-a11y y ejecutamos pruebas unitarias de accesibilidad con el paquete jest-axe. Estos comprobadores de análisis estático automatizados son útiles, pero es importante tener en cuenta que solo detectan un pequeño porcentaje de los problemas de accesibilidad, generalmente estimado en torno al 30 %. También necesitamos contar con la intervención humana.

Durante las revisiones de código y las sesiones de detección de errores, también evaluamos la accesibilidad de las funciones que estamos creando. Es en ese momento cuando realizamos pruebas manuales con teclado y lector de pantalla para asegurarnos de que las funciones puedan ser utilizadas por una persona de carne y hueso.

Más allá del ciclo de vida típico del desarrollo de software, también realizamos auditorías periódicas de nuestra aplicación, centrándonos en diferentes áreas, flujos de trabajo y temas de accesibilidad. Cualquier problema detectado se registra como un ticket en Jira para que podamos solucionarlo. Las Pautas de Accesibilidad para el Contenido Web (WCAG) son el estándar universalmente reconocido para la accesibilidad web, y Webflow se esfuerza por cumplir con las WCAG 2.2 AA.

También tenemos otro canal interno de Slack llamado #ux-paper-cuts para informar sobre pequeños problemas de UX que pueden solucionarse fácilmente y ser retomados por ingenieros que tengan un hueco entre sprints o estén esperando revisiones de código. No todos los problemas reportados son de accesibilidad, pero como hemos comentado antes, existe una coincidencia significativa entre accesibilidad y usabilidad. Lo mejor de este canal es que los problemas reportados son pequeños, por lo que es fácil arreglarlos rápidamente una vez identificados.

Por último, no nos olvidemos de nuestros maravillosos clientes y socios. Contamos con mecanismos para que los usuarios nos envíen comentarios, ya sean problemas que están encontrando o solicitudes de nuevas funciones. Nuestro programa de pruebas alfa fue especialmente impactante durante la renovación de la interfaz de usuario que lanzamos hace casi un año en la Webflow Conf 2023. En el tiempo previo a la renovación y en los meses posteriores, escuchamos a nuestros clientes para abordar varias preocupaciones de accesibilidad relacionadas con el contraste de color, el tamaño de fuente y el tamaño de los objetivos de clic. Estos comentarios dieron lugar a mejoras significativas en el lanzamiento inicial de la renovación de la interfaz, así como a la idea de la función de Ajustes de Apariencia en el Designer.

Impacto en nuestro producto

Como hemos comentado, lo más destacado fue el lanzamiento de nuestra renovación de la interfaz en octubre de 2023. A eso le siguieron los Ajustes de Apariencia en enero de 2024. Poco después, mejoramos la navegación por teclado del sistema de paneles de la barra lateral izquierda en febrero de 2024. Y eso no es todo.

A medida que aumenta la adopción de nuestro sistema de diseño, también lo hace la accesibilidad de nuestro producto, especialmente en el Designer. Nos hemos centrado mucho durante los últimos meses en aumentar la accesibilidad mediante teclado del Designer, y seguiremos trabajando en ello. Una mejor accesibilidad mediante teclado sienta las bases para la accesibilidad con lectores de pantalla.

Herramientas para ayudar a los creadores de Webflow

Webflow también ha desarrollado varias herramientas para ayudar a nuestros usuarios a crear sitios más accesibles.

Contamos con el Panel de Auditoría, que puede revisar tu sitio en busca de elementos como texto alternativo faltante en imágenes, contenido de enlaces poco descriptivo, niveles de encabezado omitidos o ID duplicados en la página.

Disponemos de una vista previa de visión, que te permite emular cómo se ve tu sitio para usuarios con varios tipos de daltonismo o visión borrosa.

También tenemos un comprobador de relación de contraste de color para ayudarte a elegir colores de primer plano y fondo que tengan un contraste adecuado.

Además de las herramientas integradas que hemos creado, también hemos elaborado una Lista de verificación de accesibilidad que puedes seguir para ayudar a que tu contenido cumpla con los estándares WCAG 2.2 AA.

Consejos para escalar la accesibilidad en tu empresa

¡Hoy hemos cubierto mucho terreno! Si tú también eres un defensor de la accesibilidad, quizás te estés preguntando: "Todo esto suena genial, pero ¿cómo puedo implementar estas cosas en mi empresa?".

Tu situación particular, las necesidades de tu empresa y su tamaño pueden ser diferentes a los nuestros, pero te dejamos tres consejos:

Primero, céntrate en tu sistema de diseño, los bloques de construcción de tu aplicación. Si tienes un sistema de diseño, dedica tiempo a hacer que tus componentes sean accesibles. Si utilizas uno de terceros, asegúrate de que el sistema que elijas priorice la accesibilidad. Los ingenieros que utilizan tu sistema de diseño intentan alcanzar sus propios objetivos mientras crean sus funciones, así que haz que la opción más fácil sea la correcta.

Segundo, integra la accesibilidad en cada aspecto del ciclo de vida de desarrollo de tu software. Adelanta el trabajo todo lo que puedas. Céntrate en la prevención, no solo en la corrección. Es mucho más fácil evitar que los problemas de accesibilidad entren en tu aplicación desde el principio que arreglarlos más adelante.

‍Tercero, hay aliados de la accesibilidad en todas partes. Si sientes que te cuesta conseguir apoyo para tus iniciativas de accesibilidad, empieza por quienes se muestran entusiasmados con el tema. No te preocupes por los escépticos que se resistan a incluir tareas de accesibilidad en sus sprints por ahora. Consigue pequeñas victorias, compártelas con quienes te rodean y deja que el entusiasmo se extienda por toda tu organización.

Por último, gracias por leer y gracias por ser un aliado de la accesibilidad.