Crédito de Accesibilidad y Cómo Pagarlo

Rate this content
Bookmark

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.

21 min
20 Jun, 2022

Video Summary and Transcription

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.

Available in English

1. Introducción a la Deuda Técnica

Short description:

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.

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

TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Top Content
Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.
JSNation 2022JSNation 2022
24 min
a11y and TDD: A Perfect Match
Accessibility has been web development's ugly duckling for quite some time now. I often get asked, "when should you test for a11y in your apps?" My answer is simple, "right from the start!". Regardless of the framework considered - React, Svelte, Vue, YourOwn™️ - as developers we are in a privileged position to help the ugly duckling grow into a beautiful swan. How? By diving deep into the pond and harnessing the power of Javascript APIs to build the right components for your web apps. And how can do you know you are building them right? By pairing Test Driven Development with the Testing Library family. Ready to grow your web apps into swans?
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
Our design systems commonly feature components that show on top of other content: tooltips, date pickers, menus and teaching UI, to name just a few. Proposed updates to the web platform are about to make building these a whole lot easier. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, modality and the top layer.
React Advanced Conference 2021React Advanced Conference 2021
32 min
How to do Good Without Doing Anything
There’s no arguing that building accessible websites is a force for good. But ensuring that our React websites and apps work for everyone can be time-consuming and isn’t always easy to get right. Luckily, investing a little bit of time on your accessibility workflow and setting up a series of automated tools will end up saving you tons of time and energy in the long run.In this talk I will demonstrate how you can leverage automated tools, clearly documented code standards and a well-defined development process in order to make building and testing accessible React apps a breeze. I will discuss the ways that I automate certain aspects of my development workflows to catch accessibility errors, define and set up tests and go through the entire lifecycle of accessibility feature development using a real-world example.
JSNation 2023JSNation 2023
30 min
Accessible Component System Through Customization
Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization, and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance.
How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much accessible we can provide out of the box to our users? How much customization freedom is enough?
That's what my talk's about.

Workshops on related topic

React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
Workshop
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Workshop
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)
React Summit Remote Edition 2021React Summit Remote Edition 2021
91 min
Creating Accessible React Native Apps
Workshop
React Native is a framework used to create native iOS and Android apps in a way web developers may already be familiar with. But how do you ensure your React Native apps are inclusive and usable everyone? Scott will share tips on how to test and build React Native apps with accessibility baked-in!