Mi Viaje de Accesibilidad: en busca de una Biblioteca de Componentes Accesibles

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Crear aplicaciones web puede ser desafiante. Crear aplicaciones accesibles - aún más. Sin embargo, el verdadero desafío radica en mantener la accesibilidad en tu proyecto, ya que requiere conocimientos y habilidades más allá de los de desarrollo web tradicional. Para lograr esto, debes elegir las herramientas adecuadas para mantener un alto nivel de accesibilidad cuando se refactoriza el código, monitorear el estado de accesibilidad y probarlo automáticamente durante la integración continua. Para abordar estos desafíos, presentaré un enfoque diferente que entrelaza la accesibilidad en el núcleo de la aplicación web mediante la creación de una biblioteca de componentes accesibles en React. Discutiré los principios, herramientas y técnicas que utilizo para probar y mantener el nivel de accesibilidad a lo largo del tiempo, y te proporcionaré la receta inicial para impulsar el cambio de accesibilidad en tu organización.

This talk has been presented at React Advanced 2022, check out the latest edition of this React Conference.

FAQ

La accesibilidad se trata de inclusión y permite que todas las personas, incluidas aquellas con discapacidades, puedan usar aplicaciones y sitios web. Se enfoca en asegurar que todos los usuarios puedan navegar e interactuar con el contenido de manera efectiva.

Es crucial probar la accesibilidad para asegurar que todas las funcionalidades de una aplicación sean usables para personas con diversas capacidades, garantizando una experiencia inclusiva y evitando la exclusión de usuarios con discapacidades.

Una estrategia efectiva incluye hacer accesible cada componente desde el inicio, emplear etiquetas HTML adecuadas, automatizar las pruebas de accesibilidad y mantener un código accesible a lo largo de los cambios y actualizaciones del proyecto.

Se utilizan herramientas como Storybook para visualizar componentes, frameworks como React y TypeScript para la construcción, y Cypress junto con herramientas especializadas como CircusCI para pruebas y despliegue continuo.

Mantener un conjunto de pruebas de accesibilidad actualizado es vital. Esto permite verificar que los niveles de accesibilidad se mantengan altos incluso cuando se realizan grandes modificaciones en los componentes de la aplicación.

El primer paso es descomponer la aplicación en componentes más pequeños, identificar los comunes entre proyectos y comenzar a adaptar cada uno para que cumpla con los estándares de accesibilidad desde su diseño inicial.

La automatización de pruebas de accesibilidad ayuda a identificar y corregir problemas de forma eficiente, asegurando que los componentes cumplan con los requisitos de accesibilidad de manera consistente y sin depender exclusivamente de revisiones manuales.

Asaf Shochet Avida
Asaf Shochet Avida
23 min
24 Oct, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla discute el viaje del orador en la creación de aplicaciones accesibles y la importancia de evitar que se envíe código inaccesible. Explora el proceso de construcción y creación de componentes accesibles, enfatizando el uso de etiquetas HTML apropiadas y realizando pruebas funcionales y de accesibilidad. La charla también destaca los beneficios de la automatización en la prueba y solución de problemas de accesibilidad. En general, enfatiza la importancia de la accesibilidad y proporciona consejos prácticos para incorporarla en el desarrollo de software.

1. Mi Viaje en Accesibilidad

Short description:

La primera vez que tuve una prueba de accesibilidad, fue un éxito en un aspecto, pero un completo fracaso en el otro. Trabajamos duro para hacer que la aplicación fuera accesible, pero cada vez que hacíamos cambios, la accesibilidad quedaba atrás. El código estaba lleno de parches y trucos, no era mantenible a largo plazo.

Hola. La primera vez que tuve una prueba de accesibilidad hace unos años, fue un éxito en un aspecto, pero un completo fracaso en el otro. Teníamos una aplicación y trabajamos muy duro para hacerla accesible, aplicando muchos parches y técnicas específicas de accesibilidad y código accesible, pero cada vez que teníamos que cambiar algo en el código, por ejemplo, un esfuerzo de rebranding, nuevos colores o una nueva interacción, la accesibilidad simplemente se quedaba atrás porque nadie se acordaba de probarla. Por eso, la mayoría de las veces estaba rota, algo así como esto. Quiero decir, el código funcionaba en cuanto a funcionalidad, pero si mirabas bajo el capó, estaba lleno de parches, lleno de trucos, no era algo de lo que estuviéramos muy orgullosos. Y no era algo que se pudiera mantener durante mucho tiempo.

2. Mi Viaje en Accesibilidad: Introducción

Short description:

En mi otro proyecto, hicimos las cosas de manera diferente para hacerlo accesible desde el principio y de manera mantenible. Esta charla trata sobre mi viaje en accesibilidad y la búsqueda de una biblioteca de componentes accesibles. La accesibilidad se trata de inclusión y permitir que todos usen tu aplicación. Queremos evitar que se envíe código inaccesible. Comenzamos probando la accesibilidad paso a paso, como los flujos de inicio de sesión, olvidé mi contraseña, registro, cierre de sesión, compra y contacto de soporte.

Así que por eso, en mi otro proyecto, cuando comenzamos un nuevo proyecto de accesibilidad y en una empresa diferente, hicimos las cosas de manera diferente. Queríamos hacerlo accesible desde el principio y de manera mantenible. Y si estás abordando el mismo problema hoy o estás intentando hacer que tu aplicación sea accesible de una manera que dure, esta charla es para ti.

Así que déjame comenzar. Esta charla se llama mi viaje en accesibilidad, la búsqueda de una biblioteca de componentes accesibles, o como debería ser el nombre completo, mi viaje en accesibilidad, la búsqueda de una biblioteca de componentes accesibles que refleje, rediseñe y sea mantenible y testeable. Son pequeños puntos, pero son muy importantes para nosotros tener código accesible.

Así que déjame presentarme. Soy Asaf. Soy el padre de Sahr, Naziv, y he estado en el campo del desarrollo web durante más de una década en varios roles y actualmente soy el líder técnico de frontend para Avinst, una startup que se especializa en brindar a los desarrolladores excelentes herramientas de desarrollo para accesibilidad. Por ejemplo, tenemos algoritmos basados en visión por computadora y aprendizaje automático que ayudan a detectar y encontrar problemas de accesibilidad. Creamos extensiones para Chrome y otras extensiones para dispositivos móviles que ayudan a los desarrolladores y probadores a encontrar problemas en sus aplicaciones. Y desarrollamos SDK que amplían los marcos de prueba como Cypress o Selenium y les brindan complementos de accesibilidad para sus pruebas. Voy a profundizar en este último punto en breve en esta presentación.

Antes de comenzar, ¿qué es la accesibilidad? La accesibilidad se trata de inclusión. Se trata de permitir que todos entren. Permitir que todas las personas usen tu increíble aplicación. Por ejemplo, una persona con discapacidad física que no puede usar el mouse aún necesitará una forma de navegar por tu sitio web y hacer clic en tu menú desplegable y seleccionar la tercera opción que abre otro submenú, y luego seleccionar la cuarta opción desde allí. Entonces, si tienes algún tipo de navegación o interacción para los usuarios que todos tenemos en nuestras aplicaciones, quieres asegurarte de que esto también sea accesible para alguien que no puede usar el mouse. Y no es trivial. Debería serlo, pero no lo es. Entonces, lo que hacemos es evitar que este tipo de cosas salgan de nuestro código. Queremos enviar solo código que sea accesible desde el principio.

Cuando queremos hacer que nuestra propia aplicación sea accesible, pensamos en dónde deberíamos comenzar este esfuerzo. Tuvimos varias ideas. Todo provino del lado de las pruebas. Quiero decir, estas ideas son muy similares a las discusiones que tuvimos sobre las pruebas. Podemos probar el producto o probar la accesibilidad del flujo del producto. Por ejemplo, podemos cubrir el flujo de inicio de sesión, comenzar con la pantalla de inicio de sesión y luego confirmar que el cuadro de diálogo de inicio de sesión es válido, que el flujo de olvidé mi contraseña funciona y que el registro y el cierre de sesión también funcionan con el teclado y con el lector de pantalla, que es una tecnología accesible, por ejemplo. Lo mismo para el flujo de compra y el flujo de contacto de soporte. Disculpa mi voz. Tengo un poco de resfriado.

3. Building Accessible Components

Short description:

Otra opción es ir página por página y cubrir todo el aspecto de accesibilidad de la página de inicio. Podemos pensar en componentes y descomponer la aplicación en componentes más pequeños. Luego, nos enfocamos en construir cada componente de la manera más accesible posible utilizando las etiquetas HTML adecuadas. Finalmente, automatizamos las pruebas funcionales y las pruebas de accesibilidad.

Gracias por completarlo en tu cabeza. Otra opción es ir página por página. Si vamos página por página, por ejemplo, cubramos todo el aspecto de accessibility de la página de inicio. Asegurémonos de que cada imagen en la página de inicio tenga un texto alternativo. Cada botón puede ser accesible mediante el teclado. Cada formulario tiene una etiqueta que un lector de pantalla puede decirle a la persona que está viendo el sitio web cuál es la etiqueta.

Pero hay una tercera forma que nos resulta más natural como desarrolladores. Esto es pensando en componentes porque como desarrolladores de front-end modernos tendemos a pensar en el mundo o en las aplicaciones como construidas a partir de componentes. Por ejemplo, mi sitio web está construido a partir de botones, forms, popups, etiquetas, campos de entrada, tal vez menús desplegables, cajas de selección, casillas de verificación. Estamos haciendo composición, estamos tomando este componente y ese componente y los ensamblamos forms, o ensamblamos gráficos o ensamblamos páginas. Tengamos una gran tabla y un menú y algunos campos de texto. Y como empresa de accesibilidad, queríamos asegurarnos de que nuestra propia aplicación sea accesible y decidimos comenzar desde el nivel de componente. Quiero decir, los flujos son una forma válida. Ensamblar páginas, pero los componentes nos encantan. Y esta es la receta que nos funciona cuando creamos nuestra propia biblioteca de componentes accesibles.

Entonces, el primer paso es descomponer la aplicación en componentes más pequeños. En nuestro caso, teníamos cuatro aplicaciones y necesitábamos identificar los componentes comunes y tal vez cambiar la API para que sea la misma para todos ellos y coincida con todos los casos de uso. Y luego los colocamos en un repositorio Git separado. Pero primero comienza identificando qué componentes son comunes a todos los proyectos. En segundo lugar, nos enfocamos en los componentes uno por uno e intentamos construirlos de la manera más accesible posible utilizando el texto HTML adecuado. Profundizaré en eso en un momento. Y en tercer lugar, automatizamos todo lo que pudimos. Estamos automatizando las pruebas funcionales y las pruebas de accessibility. Profundicemos en ello.

Entonces, la primera parte es descomponerlo en componentes más pequeños. Tomemos esta aplicación imaginaria como ejemplo. Imagina que es como un sitio web. Puedes reservar un personaje de Harry Potter, y vendrá a ti. Vendrá a tu casa, o a un lugar que desees, y te visitará por una pequeña tarifa. Es un gran sitio web.

4. Creating Accessible Components

Short description:

Identifiquemos algunos componentes: menús desplegables, selector de fechas y un botón de búsqueda. Estos componentes pueden tener diferentes estados y apariencias. Los separamos en un repositorio común y nos enfocamos en pruebas funcionales y de accesibilidad. Nuestra pila de tecnología incluye React, TypeScript, Storybook, Cypress y CircusCI. Ahora, creemos un botón accesible que se pueda enfocar usando el teclado.

Si encuentras el real, por favor avísame. Seguro lo usaré para el cumpleaños de mi hija. Ahora, identifiquemos algunos de los componentes aquí. Aquí, me refiero a un menú desplegable donde puedes seleccionar el personaje. También hay otro menú desplegable aquí donde puedes seleccionar la ubicación, y hay un selector de fechas. Ahora está marcado en rosa. Puedes seleccionar la fecha en la que el personaje vendrá. Y hay un botón de búsqueda, que es un botón. Y este botón, por ejemplo, puede tener un estado habilitado, un estado deshabilitado. Tiene un estado de hover. Como cuando pasas el cursor sobre él, o cuando te enfocas en él con el teclado, tal vez muestra algún tipo de tooltip. Tal vez el tooltip tenga un diseño o una apariencia específica en casos específicos. Lo mismo para el menú desplegable y el selector de fechas. Puede ser un componente bastante complejo.

Ahora, después de identificar estos componentes, los estamos separando de nuestros repositorios, de nuestros repositorios de productos, a un repositorio común, cuyo único propósito es ser un repositorio designado para estos componentes. En nuestro caso, lo llamamos el Repositorio Común de Componentes, no muy único, pero bastante directo, lo cual es un buen nombre. Y luego consumimos esto en todos los productos. Y este componente tiene bloques de construcción de diferentes tamaños. Puede tener un botón pequeño o un campo de entrada. Puede tener una tabla completa que tenga filtros y tenga la capacidad de comunicarse con el servidor o trabajar localmente y tener un mecanismo de ordenamiento y tener algún tipo de manejo de errores dentro de él. Quiero decir, también puede ser un componente bastante complejo. Y debido a que optamos por este enfoque, también decidimos enfocarnos en pruebas funcionales y de accesibilidad para estos componentes. La pila de tecnología que funciona para nosotros y también es adecuada para esta conferencia es React y TypeScript para construir los componentes. Y usamos Storybook para visualizar los componentes y también como base para nuestras pruebas, lo cual te mostraré en un momento. Y usamos Cypress para las pruebas y CircusCI para la implementación continua.

De acuerdo, la segunda parte, ahora queremos crear un componente accesible. Así que creemos un botón accesible. ¿Qué significa que un botón sea accesible? Pensemos en ello. Bueno, algunas de las características que hacen que un botón sea accesible es que si no puedes usar un mouse como dijimos antes, debes poder enfocarte en ese botón usando tu teclado.

5. Creando Botones Accesibles

Short description:

Al crear botones accesibles, es importante proporcionar indicación de enfoque, admitir pulsaciones de teclas alternativas y utilizar el atributo de rol para informar a los lectores de pantalla. La etiqueta de botón HTML proporciona estas características de accesibilidad de forma gratuita, ahorrando tiempo y esfuerzo. Este enfoque se aplica no solo a los botones, sino también a otras etiquetas HTML como campos de entrada, etiquetas y encabezados.

Y después de que el botón esté enfocado, imagina que tienes como cinco botones en una fila, necesitas dar una indicación de cuál de los botones está enfocado. Y luego, si te enfocas en él, necesitas admitir la tecla Enter o la tecla Espacio como una alternativa al clic. Y lo último, queremos indicar a la tecnología de asistencia que el elemento es un botón. Así que le dirá a los lectores de pantalla u otras herramientas de asistencia que esto es un botón.

De acuerdo, ahora que tenemos estas demandas en mente, vamos a ver el código. Entonces, esto es un comienzo básico para un botón. Es un Div, tiene una clase y un ID, para poder usarlo para el estilo. Tiene un OnClick que abre una alerta, y dice, Soy un botón. Ahora hagámoslo enfocable con el teclado. Para hacerlo, usaremos el atributo TabIndex. El atributo TabIndex le dice al navegador que este elemento está en la lista de tabulación. Entonces, cuando el usuario hace clic en la tecla Tab, eventualmente se enfocará en este elemento. Ahora queremos asegurarnos de que funcione la tecla Enter. No hay una forma fácil de hacerlo, sino agregar un escucha de eventos que escuche las pulsaciones de teclas. Y ahora necesitamos filtrar estas pulsaciones de teclas para ver, si es un Enter, debemos activar la función. Si no es Enter, no debemos hacer nada. Tal vez si es una barra espaciadora, también deberíamos activarlo, depende del sistema operativo, no estoy seguro. Pero también se deben hacer algunas cosas allí. Y ahora queremos decirle a los lectores de pantalla que este elemento es un botón, así que usaremos el atributo de rol.

De acuerdo, lo que tenemos aquí es un botón funcional, pero es solo el comienzo de un botón porque nuestro botón necesitará tener un estado habilitado, un estado deshabilitado, un modo primario, un modo secundario, tal vez un modo para un botón con imágenes, tal vez debería tener un estado específico para una página específica. Quiero decir, el código solo aumentará a partir de aquí. Y este código en realidad ni siquiera cubre todos los aspectos de accessibility. Se necesita mucho código. ¿Qué tal si te digo que hay una forma diferente, una fácil? ¿Qué tal si simplemente usamos la etiqueta de botón de HTML? Entonces, ¿qué sucederá si usamos la etiqueta de botón de HTML? Obtendremos todas estas cosas de forma gratuita porque HTML tiene algunas excelentes características de accessibility integradas. Así que obtendremos el enfoque del teclado, con alguna indicación. Puedes darle estilo si quieres. Obtendremos el evento de pulsación de teclas y obtendremos el rol de forma gratuita, y no tenemos que preocuparnos por ello. Entonces, lo primero que aprendimos al construir nuestra propia Accessibility Component Library es que debemos amar las etiquetas de HTML y no solo los divs para todo. Nos ahorrará mucho tiempo en testing, y nos dará características de forma gratuita. Esto es cierto para los botones, pero también es cierto para los campos de entrada, las etiquetas, los encabezados y otros atributos.

6. Añadiendo Automatización y Pruebas de Accesibilidad

Short description:

Para agregar pruebas de componentes de accesibilidad, creamos un componente de botón utilizando la etiqueta de botón. Utilizamos Storybook para crear historias primarias y secundarias para el botón. Aislamos el componente en una pestaña separada para realizar pruebas funcionales y de accesibilidad. Utilizando Cypress, visitamos la URL, hacemos clic en el botón y verificamos que se registre el clic. Esperamos que un marco de trabajo de accesibilidad encuentre texto alternativo faltante, botones no enfocables, ventanas emergentes inaccesibles y contraste de color insuficiente. En Events, utilizamos nuestras propias herramientas y un SDK para Cypress para recopilar problemas de accesibilidad y ejecutar validaciones.

De acuerdo, hablemos de agregar un nivel de automatización. Para agregar las pruebas automatizadas de componentes de accesibilidad, primero creemos un componente. Este es un componente, es un botón. Aprendimos de la diapositiva anterior que el botón debe tener la etiqueta de botón. Así que usamos la etiqueta de botón. Lo que nos interesa aquí es la propiedad primaria, que indica si es un botón primario o secundario. Ahora, seleccionamos este botón y creamos dos historias en Storybook, la historia primaria y la historia secundaria. Si no estás familiarizado con Storybook, no importa realmente. Es una gran herramienta, pero no es el tema de esta charla. Pero pruébalo, es realmente genial.

Si ejecutas Storybook, obtendrás, en realidad obtendrás dos pantallas que muestran solo los botones, y se ve así. Tiene el botón primario, se ve así, y el botón secundario que se ve así. Un poco diferentes en colores. Ahora, usaremos esto como base para nuestras pruebas. En Storybook, hay un botón mágico, puse un montón de flechas para que no lo pasemos por alto. Si haces clic en él, se abrirá el componente en una pestaña separada, en realidad sin todo el envoltorio de la interfaz de usuario de Storybook. Entonces, se abrirá sin las barras de herramientas y aislará solo el componente que queremos en un estado específico con propiedades específicas. Usaremos eso como base para nuestras pruebas funcionales y de accesibilidad.

Entonces, esta es nuestra prueba funcional. La realizaremos con Cypress y la prueba es bastante simple. Vemos dos pruebas que son idénticas, una para el botón primario y otra para el botón secundario. Visitan la URL que Storybook creó. Hacen clic en el botón y verificamos que se registre el clic. Y si queremos ejecutarlo con Cypress, vemos que todo funciona y es genial, está en verde nuevamente. De acuerdo, ahora agreguemos la accesibilidad a la mezcla. Entonces, ¿qué deberíamos esperar que encuentre un marco de trabajo de accesibilidad? Algunas de las cosas que queremos que nos indique es que falta texto alternativo en una imagen, o tenemos un botón pero no se puede enfocar con el teclado, o tenemos una ventana emergente pero no es accesible, o tenemos texto con algún color y algún color de fondo, pero el contraste de color es insuficiente, por lo que es difícil de ver para personas con baja visibilidad. Todas estas cosas y más son las cosas en las que estamos trabajando en Events. Estas son algunas de las cosas que detectamos utilizando nuestras herramientas. Como trabajamos en Events, queremos usar nuestras propias herramientas, por lo que también utilizamos nuestras propias herramientas para la automatización de pruebas. Y lo hacemos proporcionando un SDK para Cypress que nos permite recopilar problemas de accesibilidad. Entonces, si llamamos a evstart, este es el comando, dice: Events, por favor comienza a recopilar problemas de accesibilidad, y luego hacemos algunas cosas y llamamos a evstop, y luego recopila todos estos problemas y podemos ejecutar nuestras validaciones en base a estos problemas, realizar expectativas o aserciones en nuestras pruebas.

7. Ejecutando Pruebas Funcionales y Solucionando Problemas

Short description:

Así es como se ve. Ejecutamos la prueba funcional, verificamos problemas de accesibilidad y corregimos cualquier error. Reemplazamos el problema de contraste de color con negro. Este proceso ocurre en nuestro pipeline. Nuestra biblioteca de componentes consta de más de 40 componentes utilizados en cuatro proyectos. La biblioteca y nuestro enfoque nos salvaron durante un esfuerzo de rebranding. Lecciones aprendidas: dividir y conquistar, ser amigos de HTML y automatizar tanto como sea posible.

La parte central de la prueba, puedes identificarla desde antes. Esta es la misma prueba, la prueba funcional. Ahora, antes de ejecutar la prueba funcional, llamamos a evstart, para que comience a obtener problemas de accessibility y después de que se haya realizado el clic, esperamos que no haya problemas de accessibility en absoluto. Así que vamos a intentarlo.

De acuerdo, ahora lo ejecutamos y vemos que las cosas no van muy bien. Quiero decir, hay un error. Así que veamos el informe y vemos que hay un problema de contraste de color y la imagen indica que está relacionado y el selector indica que está relacionado con el contraste entre el color del texto y el color de fondo. Para ser más específicos, hay una contradicción, un mal contraste entre RGB 104, 100, 100, 06, 09 y blanco. Bueno, como no soy un diseñador calificado, lo siento, hago lo que haría cualquier buen desarrollador y decimos reemplacémoslo con negro y funciona. Ahora el contraste de color es excelente. En la vida real, consultaría a un diseñador pero esto es una charla y estoy solo aquí.

Y ahora esto es para un solo componente y hacemos esto para todos nuestros componentes y este proceso ocurre durante nuestro pipeline. Así que cada vez que enviamos nuevo código, iniciamos Storybook, ejecutamos todas las pruebas de accessibility y nuestras pruebas funcionales y si todo va bien, implementamos una nueva versión de la biblioteca de componentes para ser utilizada en otros productos. Así es como se ve en la vida real. Lo siento. Entonces, nuestra biblioteca de componentes consta de más de 40 componentes, más de 170 historias y pruebas. Cada historia está cubierta con pruebas funcionales y de accessibility. Se utiliza en cuatro proyectos. Somos un equipo de seis personas, casi siete personas. Depende de cómo cuentes. Y esta biblioteca y este enfoque nos salvaron, nos salvaron en cuanto a accessibility durante un gran esfuerzo de rebranding que acabamos de hacer. Así que cambiamos. Básicamente, ambos componentes fueron cambiados, pero el nivel de accessibility se mantuvo alto porque tenemos el conjunto de pruebas para mantenernos accesibles en todo momento.

Antes de terminar, lecciones aprendidas. Si quieres hacer lo mismo o si quieres aprovechar el mismo enfoque, primero, divide y conquista. Divide tu código en pequeños componentes. Sé amigo de HTML, conoce tus etiquetas de HTML. y automatiza tanto como puedas. Automatiza accessibility, automatiza tu pipeline de implementación. Te ahorrará mucho tiempo.

8. Conclusiones sobre la Accesibilidad

Short description:

La accesibilidad no se enseña en la academia o en los bootcamps, pero es importante. No lo pienses demasiado, comienza con un componente a la vez. Gracias por escuchar, fue divertido hablar en la conferencia. Estaré disponible para preguntas y no dudes en contactarme en LinkedIn o en mi blog. La accesibilidad es más accesible de lo que piensas.

Para resumir, la accesibilidad no es algo que se enseñe en la academia o en los bootcamps. Y es una lástima porque hace que los desarrolladores se sientan incómodos al principio, pero es muy importante. Así que mi consejo para ti es que no lo pienses demasiado. No necesitas tener un doctorado en accessibility para comenzar tu esfuerzo de accessibility. Puedes hacerlo componente por componente. Simplemente comienza.

Quiero agradecerles por escuchar. Fue muy divertido hablar aquí en la conferencia. Estaré disponible en la sesión de preguntas y respuestas en breve y no dudes en contactarme en LinkedIn o a través de mi blog. Y si tienes dudas, recuerda que la accessibility es mucho más accesible de lo que piensas.

Muchas gracias. Me retiro.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Sistemas de Diseño: Caminando la Línea Entre Flexibilidad y Consistencia
React Advanced 2021React Advanced 2021
47 min
Sistemas de Diseño: Caminando la Línea Entre Flexibilidad y Consistencia
Top Content
The Talk discusses the balance between flexibility and consistency in design systems. It explores the API design of the ActionList component and the customization options it offers. The use of component-based APIs and composability is emphasized for flexibility and customization. The Talk also touches on the ActionMenu component and the concept of building for people. The Q&A session covers topics such as component inclusion in design systems, API complexity, and the decision between creating a custom design system or using a component library.
Hacia una Biblioteca Estándar para Runtimes de JavaScript
Node Congress 2022Node Congress 2022
34 min
Hacia una Biblioteca Estándar para Runtimes de JavaScript
Top Content
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
Accesibilidad en Discord
React Advanced 2021React Advanced 2021
22 min
Accesibilidad en Discord
This Talk discusses the accessibility efforts at Discord, focusing on keyboard navigation and the challenges faced with implementing focus rings and outlines. The speaker showcases a unified focus ring system and a saturation slider to address accessibility concerns. They also highlight the implementation of role colors and the use of CSS filters for accessibility improvements. The Talk concludes with insights on runtime accessibility checking and the development of a performant core runtime system for checking accessibility issues.
Composición vs Configuración: Cómo Construir Componentes Flexibles, Resilientes y a Prueba de Futuro
React Summit 2022React Summit 2022
17 min
Composición vs Configuración: Cómo Construir Componentes Flexibles, Resilientes y a Prueba de Futuro
Top Content
Today's Talk discusses building flexible, resilient, and future-proof React components using composition and configuration approaches. The composition approach allows for flexibility without excessive conditional logic by using multiple components and passing props. The context API can be used for variant styling, allowing for appropriate styling and class specification. Adding variants and icons is made easy by consuming the variant context. The composition and configuration approaches can be combined for the best of both worlds.
Configurando las Pruebas de Accesibilidad de Axe
TestJS Summit 2021TestJS Summit 2021
30 min
Configurando las Pruebas de Accesibilidad de Axe
Top Content
AXe is an accessibility engine for automated web UI testing that runs a set of rules to test for accessibility problems. It can be configured to disable or enable specific rules and run based on tags. Axe provides various options, but axe linter does not support all options. The importance of investing time and resources in accessibility is emphasized, as it benefits not only those with disabilities but improves the web for everyone. Manual testing is also highlighted as a necessary complement to automated tests for addressing accessibility issues.
Elementos Interactivos Anidados: Una Pesadilla en Accesibilidad
React Advanced 2023React Advanced 2023
23 min
Elementos Interactivos Anidados: Una Pesadilla en Accesibilidad
Top Content
Nested interactive elements can cause accessibility issues on websites, and the speaker shares a personal experience with an accessibility bug involving a list component. Mitigating nested interactive structures involves limiting these patterns during development and restructuring existing elements. The speaker provides recommendations for improving accessibility, such as adjusting role properties and gathering user feedback. The conclusion emphasizes the importance of accessible solutions and encourages sharing resources to build more inclusive experiences.

Workshops on related topic

Construye un Tablero Rico en Datos y Hermoso con la Rejilla de Datos de MUI X y Joy UI
React Summit 2023React Summit 2023
137 min
Construye un Tablero Rico en Datos y Hermoso con la Rejilla de Datos de MUI X y Joy UI
Top Content
WorkshopFree
Sam Sycamore
Siriwat (Jun) Kunaporn
2 authors
Aprende cómo utilizar el ecosistema completo de MUI para construir un tablero de gestión de proyectos hermoso y sofisticado en una fracción del tiempo que tomaría construirlo desde cero. En particular, veremos cómo integrar la Rejilla de Datos de MUI X con Joy UI, nuestra biblioteca de componentes más nueva y hermana del estándar de la industria Material UI.
Tabla de contenidos:- Presentando nuestro proyecto y herramientas- Configuración de la aplicación e instalación del paquete- Construcción del tablero- Prototipado, estilos y temas - Características de Joy UI- Filtrado, ordenación, edición - Características de la Rejilla de Datos- Conclusión, pensamientos finales, P&R
Accesibilidad web para Ninjas: Un enfoque práctico para crear aplicaciones web accesibles
React Summit 2023React Summit 2023
109 min
Accesibilidad web para Ninjas: Un enfoque práctico para crear aplicaciones web accesibles
Workshop
Asaf Shochet Avida
Eitan Noy
2 authors
En este masterclass práctico, te proporcionaremos las herramientas y técnicas que necesitas para crear aplicaciones web accesibles. Exploraremos los principios del diseño inclusivo y aprenderemos cómo probar nuestros sitios web utilizando tecnología de asistencia para asegurarnos de que funcionen para todos.
Cubriremos temas como el marcado semántico, los roles de ARIA, los formularios y la navegación accesibles, y luego nos sumergiremos en ejercicios de codificación donde podrás aplicar lo que has aprendido. Utilizaremos herramientas de prueba automatizadas para validar nuestro trabajo y asegurarnos de cumplir con los estándares de accesibilidad.
Al final de este masterclass, estarás equipado con el conocimiento y las habilidades para crear sitios web accesibles que funcionen para todos, y tendrás experiencia práctica utilizando las últimas técnicas y herramientas para el diseño inclusivo y las pruebas. ¡Únete a nosotros en este increíble masterclass de codificación y conviértete en un ninja de la accesibilidad web y el diseño inclusivo!
Pruebas automatizadas de accesibilidad con jest-axe y Lighthouse CI
TestJS Summit 2021TestJS Summit 2021
85 min
Pruebas automatizadas de accesibilidad con jest-axe y Lighthouse CI
Workshop
Bonnie Schulkin
Bonnie Schulkin
¿Incluyen tus pruebas automatizadas verificaciones de accesibilidad? Este masterclass cubrirá cómo comenzar con jest-axe para detectar violaciones de accesibilidad basadas en código, y Lighthouse CI para validar la accesibilidad de las páginas completamente renderizadas. Ninguna cantidad de pruebas automatizadas puede reemplazar las pruebas manuales de accesibilidad, pero estas verificaciones se asegurarán de que tus probadores manuales no estén haciendo más trabajo del necesario.
Aprende a utilizar Composables: La navaja suiza de los desarrolladores de Vue
Vue.js Live 2024Vue.js Live 2024
163 min
Aprende a utilizar Composables: La navaja suiza de los desarrolladores de Vue
Workshop
Juan Andrés Núñez Charro
Juan Andrés Núñez Charro
Los Composables (funciones de composición) son funciones con estado/sin estado que pueden aprovechar la API de reactividad de Vue, desacoplándola de los componentes.Este cambio de perspectiva abre la posibilidad de abordar escenarios comunes de una manera nueva y creativa. En este masterclass, aprenderás cómo resolver problemas típicos que enfrenta cada desarrollador de Vue, utilizando composables:
- Almacenamiento de datos;- Comunicación entre componentes;- Funciones de utilidad (DOM, API, etc);Y más.
Accesibilidad web en aplicaciones JavaScript
React Summit 2022React Summit 2022
161 min
Accesibilidad web en aplicaciones JavaScript
Workshop
Sandrina Pereira
Sandrina Pereira
A menudo vemos que JavaScript daña la accesibilidad de un sitio web. En esta masterclass, aprenderás cómo evitar errores comunes y cómo utilizar JS a tu favor para mejorar la accesibilidad de tus aplicaciones web.
En esta masterclass exploraremos múltiples ejemplos del mundo real con problemas de accesibilidad, y aprenderás cómo hacer que funcionen para las personas que utilizan un mouse o un teclado. También aprenderás cómo se utilizan los lectores de pantalla, ¡y te mostraré que no hay razón para tener miedo de usar uno!
Únete a mí y déjame mostrarte cómo la accesibilidad no limita tus soluciones o habilidades. ¡Al contrario, las hace más inclusivas!
Al final, serás capaz de:- Comprender los principios de WCAG y cómo están organizados- Conocer casos comunes en los que JavaScript es esencial para la accesibilidad- Crear enlaces, botones y elementos conmutables inclusivos- Utilizar regiones en vivo para errores y estados de carga- Integrar la accesibilidad en el flujo de trabajo de tu equipo de inmediato- Darte cuenta de que crear sitios web accesibles no es tan difícil como parece ;)
Creando aplicaciones React Native accesibles
React Summit Remote Edition 2021React Summit Remote Edition 2021
91 min
Creando aplicaciones React Native accesibles
Workshop
Scott Vinkle
Scott Vinkle
React Native es un framework utilizado para crear aplicaciones nativas de iOS y Android de una manera con la que los desarrolladores web ya pueden estar familiarizados. Pero, ¿cómo asegurarse de que tus aplicaciones React Native sean inclusivas y utilizables para todos? Scott compartirá consejos sobre cómo probar y construir aplicaciones React Native con accesibilidad integrada.