La deuda técnica surge como un crédito gratuito por nuestra falta de experiencia, plazos incorrectos o simplemente una combinación de malas decisiones; pero sin importar cómo llegue allí, el costo suele recaer en la accesibilidad. Lo primero en sacrificar es la herramienta que permite a todas las personas navegar por la web sin restricciones.
¿Cómo abordamos una deuda técnica en términos de accesibilidad? ¿Por dónde empezamos? ¿Qué tan rápido y lejos podemos llegar? En esta charla repasaremos ejemplos del mundo real sobre cómo comenzar a solucionar la deuda técnica más importante que existe.
This talk has been presented at JSNation 2022, check out the latest edition of this JavaScript Conference.
FAQ
La deuda técnica es un compromiso consciente de elegir una solución rápida que puede solucionar un problema temporalmente a cambio de tener que revisarlo y mejorarlo en el futuro, con posibles intereses acumulados por no hacerlo inmediatamente.
No, el código malo no se considera deuda técnica. Más bien, es indicativo de una falta de conocimiento, preocupación o control de calidad, y suele ser más perjudicial que la deuda técnica.
Gestionar la deuda técnica involucra reconocerla conscientemente, documentarla y hacer planes para abordarla a través de sprints de desarrollo o asignaciones dedicadas para corregir y optimizar el código existente.
No pagar la deuda técnica puede resultar en la acumulación de intereses y empeorar la calidad del código a lo largo del tiempo, afectando la eficiencia del desarrollo y posiblemente la satisfacción del equipo.
Sí, la accesibilidad puede convertirse en deuda técnica cuando se pospone o ignora durante el desarrollo del producto, tratando las necesidades de los usuarios con discapacidades como secundarias.
Mejorar la accesibilidad se puede lograr mediante auditorías, pruebas manuales y automáticas, y la integración de prácticas accesibles en el ciclo de desarrollo y pruebas, así como educar y concienciar al equipo sobre su importancia.
Herramientas como WAVE o Axe son recomendadas para realizar auditorías de accesibilidad automáticamente, ayudando a identificar y documentar problemas comunes que luego se pueden abordar gradualmente.
La charla analiza la deuda técnica y su relación con el código deficiente y la falta de cuidado. Se enfatiza la importancia de pagar la deuda técnica, especialmente en términos de accesibilidad. Se destaca el bajo número de sitios web que pasan las pruebas básicas de accesibilidad. La charla proporciona estrategias para pagar la deuda técnica de accesibilidad, promover la accesibilidad e incorporar sistemas de diseño. Se enfatiza que la accesibilidad es responsabilidad de todos y no debe pasarse por alto.
Hola, soy Meba. Estoy aquí para hablar sobre el crédito de accesibilidad y cómo pagarlo. Soy un desarrollador frontend que trabaja actualmente en una empresa llamada Mayfell. También soy el organizador de CSSConf Argentina. Hoy estoy aquí para hablar sobre la deuda técnica. La mayoría de las veces, cuando pienso en la deuda técnica, en mi mente aparece este meme. El problema surge cuando comienza a causar problemas en el proceso de desarrollo. Entonces, ¿qué es la deuda técnica? ¿Qué no es la deuda técnica? ¿Es el código malo una deuda técnica? Bueno, en mi humilde opinión, el código malo no es una deuda técnica. En realidad, es una falta. Es una falta de conocimiento. Es una falta de preocupación. Y es una falta de control de calidad. La mayoría de las veces, significa que a alguien no le importa lo que se envía a producción.
Argentina. Y realmente disfruto mucho trabajar con, ya sabes, sistemas de diseño, accesibilidad, y animaciones muy inútiles como la que ves aquí. Hoy estoy aquí para hablar sobre la deuda técnica. La mayoría de las veces, cuando pienso en la deuda técnica, en mi mente aparece este meme. Es como esas situaciones en las que tienes que entregar algo y toda la oficina está en llamas. Y tienes que entregar de todos modos. Entonces, haces lo mejor que puedes mientras finges que nada está ardiendo, nada está en llamas y todo está bien. Así que, creo que usamos memes como mecanismo de afrontamiento, especialmente para la deuda técnica. Estos son mis favoritos. Solo pon la deuda técnica en mi tarjeta de crédito. Moverse rápido y romper cosas, guía de desarrollo frágil. No entiendo por qué tarda tanto en construir una nueva ventana. Y uno de mis favoritos. Arreglemos esto con una solución temporal que creará más problemas a largo plazo. Sí. Para entonces, tendremos que cambiar de tiendas. Entonces, no es deuda técnica si no estás presente cuando se soluciona. O lo que realmente me gusta decir es que no es deuda técnica si no estás presente cuando comienza a causar problemas. Porque tener deuda técnica es normal. El problema surge cuando comienza a causar problemas en el proceso de desarrollo. Entonces, ¿qué es la deuda técnica? ¿Qué no es la deuda técnica? ¿Es el código malo una deuda técnica? Bueno, en mi humilde opinión, el código malo no es una deuda técnica. En realidad, es una falta. Es una falta de conocimiento. Es una falta de preocupación. Y es una falta de control de calidad. La mayoría de las veces, significa que a alguien no le importa lo que se envía a producción. Es muy común culpar al pobre desarrollador junior que
2. Understanding Technical Debt
Short description:
Pero la realidad es que se supone que debe haber un sistema para ayudar a ese desarrollador junior a evitar enviar código malo a producción. El código malo suele ser más perjudicial que la deuda técnica porque muestra una falta de preocupación por el producto final. La deuda técnica es un compromiso consciente, donde elegimos obtener algo de inmediato a cambio de pagarlo con intereses más adelante. Tomemos un ejemplo con la tematización. Tomamos la decisión consciente de construir una solución rápida para un cliente, aunque resultara en un código basura. Lo arreglaremos más adelante.
acaba de unirse a la empresa porque envió código malo a producción. Pero la realidad es que se supone que debe haber un sistema para ayudar a ese desarrollador junior a evitar enviar código malo a producción. Se supone que debe haber un gerente y otros desarrolladores que deberían poder ayudar a esta persona a evitarlo. Honestamente, creo que el código malo suele ser más perjudicial que la deuda técnica, principalmente porque muestra esta falta de preocupación por el producto final. Y principalmente porque termina siendo un lugar triste donde culpan a los desarrolladores junior por simplemente enviar código feo a producción cuando no debería ser así. Entonces, ¿qué es la deuda técnica si no es código malo? Bueno, la deuda técnica es un compromiso consciente. Y eso es, creo, la parte más importante cuando hablamos de deuda técnica, es que es consciente. Hay una cita que realmente disfruto sobre la deuda técnica, dice que sucede cuando elegimos obtener algo de otra manera inalcanzable de inmediato a cambio de pagarlo con intereses más adelante. Esta es una cita del Sr. Harold Roberts. Si no lo sigues en Twitter, te recomiendo que lo hagas. Habla mucho sobre refactorización y deuda técnica. Es una persona extremadamente amable y también extremadamente conocedora. Así que si lo buscas en YouTube, definitivamente aprenderás mucho. Si miramos esta cita, dice de otra manera inalcanzable de inmediato y pagarlo después, esas son las dos cosas que debemos tener en cuenta cuando hablamos de deuda técnica. Tomemos un ejemplo. Hablemos de la tematización. Pretendamos que somos una empresa que brinda un servicio a diferentes clientes y nuestros clientes utilizan nuestro servicio y nuestro servicio no puede ser personalizado. No tiene ninguna tematización, solo es de este color y ya está. Y tenemos un posible cliente, un cliente importante que dice, si proporcionas una tematización que se parezca a mis colores de marca, entonces seré tu cliente. Entonces, ¿qué sucede en esas situaciones es que generalmente el gerente de proyecto o el gerente de producto se acerca al equipo de desarrollo y dice, bueno, ¿cuál es la estimación para hacer que la tematización suceda? Y los desarrolladores pueden decir, bueno, un par de semanas, tal vez cuatro o cinco semanas si queremos hacerlo bien. Eso significaría que perderíamos al cliente y no querríamos hacer eso. Así que terminamos diciendo, bueno, puedo construir una solución muy rápida solo para este cliente, solo para no perderlo. ¿Y en cuatro o cinco días, qué te parece? Eso suena bien. Eso es genial. Construimos la cosa, importamos todas las cosas, y funciona, y conseguimos al cliente, y eso es genial. Y simplemente codificamos basura. Pero deberías estar muy orgulloso de eso porque es increíble. Teníamos muy buenas razones para crear eso. Tomamos la decisión consciente de decir voy a construir código feo a cambio
3. Repaying Technical Debt and Accessibility
Short description:
Así que felicidades. Acabas de crear tu primera deuda técnica. ¿La pagarás? Tenemos dos caminos: pagar o pretender que no pasó nada. Si pagamos, necesitamos limpiar y construirlo correctamente. Si pretendemos, acumula intereses y hace que los miembros del equipo estén tristes. Trabajar con bases de código antiguas y defectuosas dificulta el aprendizaje y limita las posibilidades. Necesitamos pagar, abordando específicamente la parte de accesibilidad de la deuda técnica. La accesibilidad a menudo se pospone, lo que resulta en lanzamientos de código que no son accesibles. Podemos consultar el informe de WebAIM para una auditoría anual de accesibilidad.
para conseguir un cliente y luego lo arreglaré. Así que felicidades. Acabas de crear tu primera deuda técnica. Ahora viene la segunda parte. ¿La pagarás? Así que tenemos dos caminos diferentes. Podemos pagar o podemos pretender que no pasó nada. Si pagamos, eso significa que necesitamos tomar un tiempo para sentarnos y limpiar lo que hicimos, y construirlo correctamente, y construirlo también para futuros clientes. Y si pretendemos, eso significa que seguimos trabajando con lo que estábamos trabajando antes de esto, y nunca arreglamos esas cosas importantes. Y lo que podría suceder es que se acumulen intereses. Y también crearás un efecto de bola de nieve. Así que eso significa que tal vez otro cliente llegue y diga: `Oye, ese cliente tiene tematización. Yo también quiero tematización`. Y luego tendrás que hacer todas esas cosas importantes nuevamente, solo para este Cliente B, y tu código empeora. Y luego llega el Cliente C, y dices: `Bueno, está bien, le daré más importancia`. Y empeora, y empeora, y empeora todo el tiempo. Porque si no pagas, se acumularán intereses. Y también hará que los miembros del equipo estén tristes.
No sé tú, pero he trabajado con bases de código muy antiguas y muy defectuosas antes. Y no es una situación muy feliz. Sientes que no estás aprendiendo. No puedes probar cosas nuevas, y no solo los desarrolladores están tristes. También los gerentes de producto y los diseñadores cuando se dan cuenta de que lo que quieren construir no es posible. Así que necesitamos pagar. ¿Y cómo pagamos? Bueno, voy a hablar específicamente de pagar la parte de accessibility|accesibilidad de la deuda técnica. Y dirás, ¿qué? ¿Es accessibility|accesibilidad una deuda técnica? No. Quiero decir, no, no debería serlo, pero en realidad lo es. La realidad es que los usuarios de accessibility|accesibilidad suelen considerarse ciudadanos de segunda clase en la web. Así que, por lo general, se posponen para el futuro a pesar de sus necesidades. Y lo que suele suceder es que terminamos lanzando código que no es accesible porque queremos lanzarlo en un plazo muy ajustado. Podemos echar un vistazo al informe de WebAIM, ellos hacen un informe, un informe anual sobre accessibility|accesibilidad en los primeros un millón de páginas de inicio de la web. Y realizan una prueba muy básica
4. Resultados de las Pruebas de Accesibilidad
Short description:
En 2022, solo el 3.2% de los sitios web pasaron las pruebas básicas de accesibilidad, lo cual es una ligera mejora respecto al 2.6% del año anterior. Los errores más comunes incluyen la falta de texto alternativo para imágenes, cumplimiento, contraste de colores, etiquetas para entradas, atributos de idioma del documento, botones y enlaces.
WebAIM realiza una auditoría de accesibilidad con pruebas WCAG. Y verifican el texto alternativo, buen contraste, etiquetas para entradas y atributos de idioma del documento. Así que verifican cosas muy simples que se pueden automatizar. Y cada año determinan cuántas de esas un millón de páginas web pasan esas pruebas básicas. Y les pregunto, ¿cuántas creen que las pasaron? ¿Al menos el 20% de ellas? ¿Al menos el 10%? ¿O al menos el 5%? La respuesta es que en 2022, solo el 3.2% las pasaron. Solo 3.2% de los sitios web pasaron esa prueba. Es un poco mejor que el año pasado. El año pasado solo fue el 2.6%. Así que supongo que podemos estar un poco contentos al respecto, pero no demasiado. Los errores más comunes son la falta de texto alternativo para imágenes, falta de cumplimiento, contraste de colores, falta de etiquetas para entradas, atributos de idioma del documento, botones y enlaces.
5. Repaying Accessibility Technical Debt
Short description:
Muchos sitios web todavía tienen problemas de accesibilidad, como pestañas de marquesina y contenido parpadeante. La falta de accesibilidad a menudo es un compromiso consciente debido a las presiones de los plazos. Para pagar la deuda técnica de accesibilidad, comience con una auditoría básica utilizando herramientas como WAVE o Axe. Cree tareas específicas para abordar los problemas de manera incremental, corrigiendo errores, reconstruyendo componentes rotos y agregando nuevas funciones. Documente los problemas no resueltos y colóquelos en el backlog para reconocer y empoderar al equipo. Evite crear más problemas aprendiendo de los errores e implementando un plan a largo plazo para el cambio cultural.
Muchas de esas cosas generalmente se solucionan con una sola línea de código. También hay un dato curioso que siempre me gusta mencionar. A pesar de ser 2022, 9,152 páginas de inicio tenían una pestaña de marquesina, algo que muchos de ustedes pueden ser demasiado jóvenes para saber qué es. 373 páginas de inicio tenían contenido parpadeante, y eso no debería suceder en 2022. Entonces, ¿por qué sucede esto? Bueno, es una situación en la que la falta de accesibilidad es más a menudo un compromiso consciente. No probamos la accesibilidad y simplemente lanzamos cualquier función en la que estemos trabajando sin hacer una prueba adecuada, porque queremos cumplir con el plazo y el plazo no tuvo en cuenta a las personas con discapacidades. Entonces, ¿cómo comenzamos a pagar? Tenemos dos cosas en mente cuando queremos pagar la deuda técnica de accesibilidad. La primera cosa es cómo pagar la deuda técnica actual, y la segunda cosa es cómo evitar que esto vuelva a suceder, lo cual es un proceso a muy largo plazo. Para la deuda técnica actual, recomiendo encarecidamente realizar una auditoría muy básica, puedes usar WAVE o Axe o cualquier herramienta automatizada que verifique los errores más comunes y anótalos. Y trata de encontrar algo de tiempo libre para mejorarlo lentamente, porque podrías encontrarte con unos 600 problemas, y es como, oh Dios mío, ¿qué hago? Bueno, crea una tarea pequeña y bien definida, como que los contornos de estos elementos no funcionan, como que este menú desplegable no aparece en la navegación por teclado. Crea tareas muy específicas y bien definidas para que puedas trabajar en quizás el 15% de cada sprint. Eso significa que te llevará mucho tiempo solucionarlo, pero está bien, porque estás haciendo trabajo para mejorarlo. Entonces, corriges errores, reconstruyes componentes rotos y también puedes construir nuevas funciones que no tenías antes, como un enlace de navegación de escape. Y cuando no tienes tiempo para arreglar algo, aún lo documentas, aún creas un ticket para ello y lo pones en el backlog. Y sé cómo suena eso, y sé lo que viene a tu mente ahora mismo, es este meme, que significa ponerlo en el backlog para arreglarlo más tarde, ¿verdad? Y es muy común pensar en esto, cuando decimos ponerlo en el backlog, porque parece que nunca lo vamos a arreglar. Pero la realidad es que no se trata realmente de eso, se trata de que no podemos pagar lo que no reconocemos. Y no se trata solo de ti. Es como, está bien, sé que tengo ese problema de accesibilidad. Pero no se trata solo de lo que yo sé. Es importante que todos en el equipo sepan que tengo o que tenemos este problema de accesibilidad. Entonces, cuando hablamos de ponerlo en el backlog, lo que queremos decir es que necesitamos empoderar a todos. Y necesitamos que todos estén en la misma página y sepan cuáles son los problemas de accesibilidad que tenemos y que aún no hemos solucionado. Entonces, por eso lo ponemos en el backlog. Para reconocer que todavía tenemos mucho por hacer. Y luego evitamos crear más. Lo cual es la parte divertida. Porque pasamos por una situación en la que de repente tenemos quizás 600 problemas en una sola página. Entonces, lo que queremos hacer no es solo solucionar eso, sino también aprender de nuestros errores y asegurarnos de no crear el mismo problema nuevamente. Entonces, lo que hacemos es tener un plan para una solución a largo plazo para evitar cometer el mismo error. Todo comienza con un cambio cultural en la empresa,
6. Promoting Accessibility and Design Systems
Short description:
Lo que necesitamos hacer es encontrar personas que se preocupen, hablar sobre accesibilidad en las reuniones, hacer saber a la gente que es importante y lograr que los CO, CTO y gerentes también se preocupen. Debemos actualizar los procesos, construir pruebas automatizadas y realizar más pruebas manuales. Ejecutar la navegación por teclado en las funciones, trabajar con QA/QE para verificar la accesibilidad e incluir la accesibilidad en las demostraciones internas. Los sistemas de diseño son la clave para solucionar problemas de accesibilidad en todas partes. Sigue a Brad Frost y Sheena Ann para obtener información práctica. Contrata desarrolladores frontend para asegurarte de que la accesibilidad se solucione correctamente. Recuerda, ningún código puede solucionar un mal diseño.
. Lo que necesitamos hacer es encontrar personas que se preocupen. Necesitamos hablar sobre la accesibilidad en las reuniones. Necesitamos hacer saber a la gente que eso es importante. Y necesitamos que los CO, CTO y gerentes también se preocupen por eso para que nosotros, los desarrolladores, tengamos el tiempo para trabajar en ello. Y también para encontrar el tiempo para actualizar los procesos que no están funcionando correctamente. Tal vez podamos comenzar a construir pruebas automatizadas y agregarlas a nuestras herramientas de CI y CD. Tal vez también deberíamos comenzar a hacer más pruebas manuales. Entonces, si eres un desarrollador, ejecuta una navegación por teclado en la función en la que estás trabajando solo para asegurarte de que un usuario con problemas de movilidad o que utiliza un lector de pantalla pueda utilizar la función que estás construyendo. O también podemos trabajar con el equipo de QA o QE y ayudarlos a construir un proceso para verificar la accesibilidad también. Algo más que encontré muy interesante y que ayudó a introducir la idea de accesibilidad en la empresa fue incluirla en las demostraciones internas. En mi empresa anterior, solíamos hacer muchas demostraciones de nuevas funciones en las que estábamos trabajando. Y comenzamos a hacer esas demostraciones con navegación por teclado y también con lectores de pantalla. Y eso puede sonar un poco extraño, pero el objetivo era mostrar que eso es parte de nuestro trabajo. Nosotros, los desarrolladores, los diseñadores, construimos productos para todos. Entonces, debemos probar para todos. Y para hacer que más personas se preocupen por eso y lo sepan, incluirlo en las demostraciones que realiza tu empresa es una muy buena manera. Y lo más hermoso del mundo que te ayudará a solucionar los problemas de accesibilidad de una vez por todas son los sistemas de diseño. Los sistemas de diseño son esta única fuente de verdad donde construyes un componente y muchos productos diferentes utilizan ese componente. Eso significa que si lo haces bien una vez, funcionará bien en todas partes. Eso es increíble. Eso significa solucionar la accesibilidad en tu sistema de diseño y se solucionará automáticamente en todos los demás productos que utilizan ese sistema de diseño. Haz lo que Brad Frost y Sheena Ann dicen. Personas muy inteligentes que trabajan mucho en accesibilidad. Te recomiendo encarecidamente que los busques en Google, los sigas en Twitter y veas sus videos de YouTube, porque comparten mucha información práctica al respecto. Otra cosa que te ayudará a tener casi ningún problema de accesibilidad es contratar desarrolladores frontend. Y sí, lo digo en serio. La accesibilidad es principalmente un problema frontend. Eso significa que si quieres solucionarlo de la manera correcta, necesitas desarrolladores frontend. Y sé que tal vez sintamos que necesitamos ahorrar dinero o tener, ya sabes, estas personas que lo saben todo, y es genial tener algunos desarrolladores full stack, pero si realmente quieres hacerlo bien, necesitas encontrar personas especializadas en accesibilidad, sitios web responsivos y de rendimiento, necesitas encontrar personas especializadas en frontend.
7. Design Accessibility and Responsibility
Short description:
Si el diseño no es accesible, tampoco lo será el sitio web. Los flujos de UX deficientes no se pueden solucionar con código. Trabajamos en equipo con desarrolladores, diseñadores, gerentes de producto y gerentes de proyecto. La accesibilidad es responsabilidad de todos. Evitemos la deuda técnica, pero no carguemos a los usuarios con discapacidades.
Y ten en cuenta que ningún código puede solucionar un mal design. Si el design no es accesible, tampoco lo será el sitio web. Entonces, si hay flujos de UX deficientes, no hay forma de que pueda agregar código para solucionarlo. No hay forma de que pueda mejorar este design con neomorfismo o este otro. Realmente no se puede agregar código, un mal design o malas decisiones.
Es importante recordar que no estamos en 1999. Trabajamos en equipo. Tenemos desarrolladores, diseñadores, gerentes de producto, gerentes de proyecto. Tenemos personas de calidad que verifican lo que hacemos. Y es importante saber que la accessibility no es solo responsabilidad de una persona, sino de todos y también es responsabilidad de todos. Así que recuerda que no puedes evitar realmente la technical deuda. Eso no es lo que queremos hacer. Pero podemos evitar cargar a los usuarios con discapacidades. Así que muchas gracias.
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.
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.
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.
The Talk discusses the use of dialogues and popovers in web development. Dialogues can be modal or non-modal and are now accessibility-supported. Popovers are versatile and can be added to any element without JavaScript. They provide suggestions, pickers, teaching UI, list boxes, and action menus. Modal and non-modal dialogues and popovers have different behaviors and dismissal methods. Browser support for these features is expanding, but there are still open questions about positioning, semantics, and other use cases.
This Talk explores the intersection of accessibility and test-driven development (TDD) in software development. TDD is a process that involves writing tests before writing production code, providing a safety net for code changes. The Talk demonstrates how to apply TDD principles to real-life examples, such as filling out a form, and emphasizes the importance of user-centric testing. By using atomic design principles, code can be organized in a clean and easy way. The Talk also discusses the use of labels and test IDs in tests for improved accessibility.
Accessibility is about making sure everyone can participate on the web, regardless of disability. Automated tools like Lighthouse and React Axe help identify accessibility errors and provide guidance on fixing them. Unit tests validate ARIA attributes and keyboard navigation, while integration and end-to-end tests focus on outcomes and simulate user experiences. Cypress.io is an open-source testing framework with excellent accessibility support. Implementing small changes leads to a deep understanding of web accessibility and bug resilience.
Accesibilidad web para Ninjas: Un enfoque práctico para crear aplicaciones web accesibles
Workshop
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!
¿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.
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 ;)
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.
Comments