Creando una Web Accesible Juntos en 5 Pasos Sencillos

Rate this content
Bookmark

La accesibilidad a menudo se deja de lado en el ciclo de desarrollo de software. Sin embargo, con 5 técnicas sencillas, podemos incorporar la accesibilidad en nuestras aplicaciones desde el principio. En esta charla, hablaré sobre cómo probar la accesibilidad, las etiquetas ARIA que debes conocer y cómo utilizarlas. Veremos una demostración de lo impactante que puede ser una aplicación no accesible para los usuarios y cómo solucionarlo. También analizaremos cómo Slack ha construido una aplicación accesible y ha ido más allá.

31 min
21 Oct, 2022

Video Summary and Transcription

La charla aborda la importancia de la accesibilidad en el desarrollo web y proporciona consejos prácticos para construir aplicaciones web accesibles. Se discuten los principios básicos de la accesibilidad, las pautas WCAG y el uso de tecnologías de asistencia. La charla enfatiza el uso de HTML semántico, el índice de pestañas, los atributos ARIA y la navegación por teclado para la accesibilidad de la aplicación. También destaca la importancia de probar y depurar problemas de accesibilidad y recomienda el uso de herramientas de accesibilidad. En general, el objetivo de la charla es crear conciencia sobre la accesibilidad y proporcionar a los desarrolladores el conocimiento y las herramientas para crear aplicaciones web inclusivas.

Available in English

1. Introducción a la Accesibilidad en el Desarrollo Web

Short description:

Hola a todos. Gracias por venir a mi charla. Todos nos preocupamos por construir aplicaciones web de alto rendimiento y crear una experiencia de usuario increíble. La accesibilidad a menudo se deja de lado en el desarrollo de software. Hablaré sobre cinco cosas simples que debes tener en cuenta al desarrollar para evitar lanzar una aplicación inaccesible. Construir aplicaciones web accesibles es una tarea importante. Continuaré compartiendo mis conocimientos sobre accesibilidad a través de publicaciones en blogs y redes sociales.

Hola a todos. Gracias por venir a mi charla. Y por quedarse aquí, en realidad. Todos nos preocupamos mucho por construir aplicaciones web de alto rendimiento y crear una experiencia de usuario increíble. Ponemos mucho esfuerzo en hacer sitios web rápidos. Pero, ¿de qué sirve un sitio web rápido si las personas no pueden usarlo? La accesibilidad a menudo se deja de lado en el ciclo de desarrollo de software. Cuando llega el momento de lanzar, hacemos una prueba rápida de accesibilidad y descubrimos que nuestra aplicación no es accesible, así que agregamos un código chapucero y nos aseguramos de que sea accesible lo suficiente. Y luego lo lanzamos. Y a veces termina viéndose así.

Nos aseguramos de que sea visualmente atractivo y estético, pero la experiencia en sí se ve bastante chapucera. En mi charla, hablaré sobre cinco cosas simples que puedes tener en cuenta mientras desarrollas para evitar una situación como esta. Mi nombre es Shruti Kapoor. Soy miembro principal del personal técnico en Slack. Y en los últimos meses, he estado trabajando en la creación de experiencias de usuario accesibles en Estaría mintiendo si dijera que soy una experta en accesibilidad. No me hagan preguntas difíciles. Cuando construí mi sitio personal, lo hice visualmente atractivo, se veía hermoso, usé Tailwind, todo se veía genial. Y cuando hice una prueba de accesibilidad, descubrí que la mayoría de mi sitio no era accesible y las personas no podían hacer las cosas que querían hacer. Como por ejemplo, leer los blogs. Así que a través de esta charla, quiero compartir algunos consejos y trucos que aprendí y algunas cosas que ahora tengo en cuenta al desarrollar tu aplicación web para que no termines en una situación en la que casi es hora de lanzar y tu aplicación no sea accesible.

Este es un largo camino, en realidad. Construir aplicaciones web accesibles es mucho trabajo y es una tarea importante. Mi viaje aquí no ha terminado. A través de esta charla, quiero compartir algunas cosas. Pero este viaje continúa después también. Continuaré compartiendo mis conocimientos sobre accesibilidad a través de publicaciones en blogs y si estás interesado en seguirme, puedes encontrarme en cualquier lugar en Twitter aquí. O en mi sitio web no accesible por ahora. Y si me has estado siguiendo en Twitter, ya sabes que soy una gran fan de DevJoke. Así que ya sabes lo que viene. Te haré una pregunta de DevJoke y puedes gritar la respuesta en voz alta. ¿Qué dijo el proceso después de trabajar en un bucle infinito todo el día? Necesito un descanso.

2. Introducción a la Accesibilidad en la Web

Short description:

Hoy discutiremos el principio básico de accesibilidad, pautas, pruebas, depuración, herramientas de automatización y una aplicación web que prioriza la accesibilidad. La accesibilidad garantiza que todos puedan usar un sitio web fácilmente, beneficiando a todos los usuarios. Ejemplos de accesibilidad incluyen el uso de un teclado cuando falla el trackpad y subtítulos para ver videos. Las tecnologías de asistencia como lectores de pantalla y lupas ayudan a los usuarios con discapacidades a acceder a los sitios web.

Tienes razón. Sí. De acuerdo. Debido a que tenemos poco tiempo, solo haré una broma de DevJoke, pero si quieres más DevJokes, puedes encontrarlos en Twitter. Entonces, esto es de lo que vamos a hablar hoy. Veremos el principio básico de la accesibilidad y las pautas de accesibilidad. Veremos cómo probar si tu aplicación actual es accesible y tendremos una lista de verificación de cosas. Depuraremos una aplicación web y descubriremos cuáles son los problemas y dónde puedes buscar soluciones. Luego veremos algunas herramientas que pueden automatizar este trabajo por ti, para que no tengas que hacerlo todo manualmente. Por último, veremos una aplicación web que se ha tomado en serio la accesibilidad y va más allá.

Entonces, primero hablemos de la accesibilidad. Por cierto, todas las diapositivas ya están disponibles en línea, y si estás interesado, aquí tienes un código QR. También he tuiteado el enlace ahora mismo, y puedes encontrarlo en Twitter si estás interesado. Todos tienen el código QR y seguimos adelante.

Entonces, ¿qué es la accesibilidad? Ahora quiero que te tomes un minuto para pensar en el último sitio web que construiste o en uno de tus sitios web favoritos. ¿Estás seguro de que cualquier persona en el mundo puede usar ese sitio web? ¿Estás seguro de que las personas que tienen limitaciones o que usan tecnologías de asistencia pueden usar ese sitio web de la misma manera que una persona sin discapacidades? ¿Estás seguro de que todas las partes de tu sitio web son fácilmente accesibles? La accesibilidad permite que todos usen tu sitio y realicen las acciones críticas fácilmente. Y la accesibilidad beneficia a todos.

Es posible que hayas visto ejemplos de accesibilidad en tu vida. Por ejemplo, cuando estás programando y tu trackpad deja de funcionar y necesitas conectarte o iniciar sesión. Simplemente usas el teclado para acceder a la pantalla de inicio de sesión. También hemos visto características de accesibilidad que nos benefician en la vida real. Por ejemplo, cuando tienes muchas maletas en la mano y subes una escalera y no hay rampa. O cuando necesitas abrir la puerta y tienes las manos ocupadas. O por la noche, cuando necesitas ver YouTube y tu pareja está durmiendo, así que activas los subtítulos. Entonces, la accesibilidad beneficia a todos, no solo a aquellos con limitaciones. Pero crear experiencias accesibles brinda una gran experiencia para todos los que las utilizan. ¿Cómo se ve la accesibilidad en lo digital o en la web? En la web, cuando una persona está usando la web, puede usar diferentes tecnologías de asistencia para navegar por tu sitio web. Por ejemplo, alguien puede estar usando un lector de pantalla para leer el texto de tu sitio. Y pueden estar usando lupas de pantalla para ampliar tu pantalla hasta 20 veces para ver la pantalla en sí. Las personas con discapacidades motoras pueden estar utilizando diferentes tecnologías.

3. Tecnologías de Asistencia y Pautas WCAG

Short description:

Para asegurarnos de que estamos construyendo para todos, debemos considerar las diferentes tecnologías de asistencia que las personas utilizan. Según la Organización Mundial de la Salud, el 15% de la población tiene algún tipo de discapacidad. Es un requisito legal que una aplicación web sea accesible. Las pautas WCAG 2.1 AA especifican que los sitios web deben ser perceptibles, operables, comprensibles y robustos. Perceptible significa que el contenido debe ser entendido por las tecnologías de asistencia. Operable significa que los sitios web deben ser operables por otras tecnologías de asistencia, como lectores de pantalla y teclados. Comprensible significa que el texto debe ser comprensible para los lectores de pantalla. Robusto significa que las tecnologías de asistencia deben poder analizar tu código.

Por ejemplo, teclados o interruptores de selección. O tal vez usando un rastreador de cabeza para descubrir dónde está el cursor o para señalar el cursor en la página misma. Entonces, para asegurarnos de que estamos construyendo teniendo en cuenta a todos, debemos considerar las diferentes tecnologías de asistencia que las personas utilizan.

De hecho, puedes acceder a la mayoría de estas tecnologías en tu Mac navegando al menú de accesibilidad en Mac. Hay más personas utilizando estas herramientas de accesibilidad de las que piensas. Según la Organización Mundial de la Salud, el 15% de la población tiene algún tipo de discapacidad y puede necesitar utilizar una tecnología de asistencia. En los Estados Unidos, 1 de cada 4 ciudadanos tiene una discapacidad. Y no es solo una característica, también es un requisito legal que una aplicación web sea accesible. En el Reino Unido, según la Ley de Igualdad de 2010, tu sitio web debe ser accesible según las pautas WCAG 2.1 AA. Veamos qué significa eso.

Esto especifica las pautas que tu sitio web debe ser perceptible, operable, comprensible y robusto. ¿Qué significa perceptible? Significa que el contenido presentado en la pantalla debe ser entendido por las personas que utilizan tecnologías de asistencia. Un ejemplo de esto podría ser que tienes imágenes en la página y necesitas proporcionar todo el texto para ellas. O si tienes un video o audio en la página, debes proporcionar subtítulos para que las personas puedan leerlos. Este principio también especifica que el color no debe ser la única forma de mostrar información.

El siguiente es operable, lo que básicamente significa que los sitios web deben poder ser operados no solo con el mouse, sino también con otras tecnologías de asistencia, como un lector de pantalla. Por ejemplo, un teclado. Especifica que el enfoque del teclado no debe quedar atrapado y el usuario siempre debe tener una comprensión de dónde está el enfoque del teclado en la aplicación web. El siguiente es comprensible, lo que básicamente significa que el texto presentado en la pantalla debe ser comprensible para los lectores de pantalla. Y asegura que las personas que utilizan tecnologías de asistencia puedan utilizar los conocimientos que tienen de un sitio web para navegar a tu sitio web. Por ejemplo, es posible que hayas visto `saltar al contenido principal` en la mayoría de los sitios web. Entonces, las personas que utilizan tecnologías de asistencia tienen una memoria muscular incorporada porque han estado utilizando sus tecnologías durante un tiempo. Y si mueves `saltar al contenido principal` de esa parte a otra parte, se vuelve muy difícil para las personas entender dónde está y acceder a él. Este principio básicamente establece que cosas como esta deben estar en la misma parte del sitio web. Y finalmente, robusto, lo que básicamente significa que las tecnologías de asistencia deben poder analizar tu código. Y por eso es muy importante utilizar HTML semántico. Y tu código debe funcionar en todos los navegadores. Hay diferentes tipos de necesidades de accesibilidad que debemos tener en cuenta.

4. Accesibilidad de la Aplicación y HTML Semántico

Short description:

Algunos ejemplos de discapacidades incluyen discapacidad motora, discapacidad cognitiva y discapacidad auditiva. Para garantizar la accesibilidad de la aplicación, recuerda el acrónimo STARK: HTML semántico, índice de pestañas, etiquetas ARIA, rol, navegación por teclado y lector de pantalla. Utiliza elementos HTML semánticos como botones en lugar de divs para acciones. Asegúrate de que las etiquetas de anclaje tengan atributos href y las imágenes tengan etiquetas alt. Evita utilizar formato de fuente para los encabezados. El HTML semántico proporciona funciones de accesibilidad gratuitas como la navegación por teclado y la funcionalidad de selección.

Algunos de ellos son discapacidad motora, que es cuando una persona tiene problemas con el control muscular y la incapacidad de usar un mouse o un trackpad, y pueden tener un tiempo de respuesta lento. La discapacidad cognitiva es cuando una persona tiene dificultades de aprendizaje o puede tener TDAH y puede ser difícil para ellos recordar grandes cantidades de información en la pantalla. Y la discapacidad auditiva incluye cosas como la sordera o la dificultad para oír.

Entonces, eso es la accesibilidad 101 y ahora, ¿cómo podemos asegurarnos de que nuestra aplicación sea accesible? Mientras aprendemos cómo hacer que las cosas sean accesibles, se me ocurrieron cinco cosas principales que podemos tener en cuenta y son las siguientes: etiquetas ARIA, rol, navegación por teclado y lector de pantalla. Y para que sea más fácil recordarlo, solo piensa en STARK. O este chico. O si eres fanático de Game of Thrones, aún estos chicos. Entonces, nuevamente, STARK significa HTML semántico, índice de pestañas, etiquetas ARIA, rol, navegación por teclado y lector de pantalla.

Entonces, hablemos de la primera, que es HTML semántico. Creo que todos sabemos qué es HTML semántico, así que voy a pasar a los consejos, que es un gran consejo que todos dicen: utiliza botones para acciones en lugar de agregarlos a un div. Básicamente, en lugar de agregar un controlador onclick a un div, debes usar la versión HTML semántica de ello, que es el botón. Y cada vez que uses una etiqueta de anclaje, asegúrate de que tenga un atributo href. Cada vez que uses imágenes, asegúrate de que tengan etiquetas alt. Y no uses CSS o formato de fuente solo para los encabezados. Y en la medida de lo posible, utiliza los elementos HTML semánticos nativos para mostrar contenido en tu pantalla. Pero tomemos un minuto para pensar en cuál es el problema si usas div en lugar de un botón. El problema es que cuando un lector de pantalla encuentra un div y tiene un controlador onclick, el lector de pantalla no entiende que debería funcionar como un botón. Entonces, si encuentra un div con un controlador onclick o simplemente un div, lo anunciará como grupo o lo anunciará como rol. Entonces, la persona que usa el lector de pantalla no tiene idea de que necesita hacer clic en él. Podría suceder que pasen por alto por completo tu botón y pasen a la siguiente página. Por eso necesitas tener un botón en lugar de div onclicks.

Ahora, ¿cuál es el problema de no usar etiquetas de encabezado correctas y simplemente agregar formato? El problema es que cuando un lector de pantalla encuentra un encabezado, en realidad anuncia `encabezado` en el texto. Pero si solo usas formato de fuente, el usuario no tiene idea de que esto es un encabezado y necesita prestar atención. Otra gran ventaja de usar HTML semántico es que obtienes accesibilidad gratuita de serie. Por ejemplo, cosas como, digamos que estás usando un select, puedes usar la barra espaciadora para seleccionar un elemento. O si tienes un botón, puedes usar la tecla Enter para seleccionar o hacer clic en el botón. Entonces, no tienes que construir estas cosas. No tienes que hacer que sean accesibles. Ya te las proporcionan de serie.

5. Uso de Slider y Tab Index en Accesibilidad Web

Short description:

Otro gran ejemplo es el uso de un slider. Puedes usar las teclas de espacio para mover el slider. Utiliza HTML semántico. El índice de pestañas se utiliza para establecer el enfoque en ciertos elementos de la página, permitiendo la navegación por teclado. Un consejo rápido es usar cero para los elementos que deben tener el enfoque de forma predeterminada y menos uno para establecer programáticamente el enfoque en un elemento con JavaScript. Evita usar un índice de pestañas mayor que cero, ya que confunde a los lectores de pantalla.

Otro gran ejemplo es el uso de un slider. Puedes usar las teclas de espacio para mover el slider.

Entonces, en resumen, utiliza HTML semántico. Muy bien. Lo siguiente es el índice de pestañas. Si no estás familiarizado con el índice de pestañas, en realidad se utiliza para establecer el enfoque en ciertos elementos de la página. Así que puedes indicar la navegación por teclado... Básicamente, puedes especificar a dónde debe navegar el teclado o dónde debe establecer el enfoque. Hay una herramienta muy útil en Firefox que puede ayudar a encontrar o depurar el índice de pestañas, y lo mostraré en un momento. Se ve más o menos así. Así que puedes ver los pequeños iconos negros ampliados aquí. Te indica el orden de pestañas de cada elemento, si es interactivo y enfocable. Un consejo rápido sobre el índice de pestañas es usar cero, que es para los elementos que deseas que tengan el enfoque de forma predeterminada, como los divs si necesitan tener el enfoque. O menos uno si deseas establecer programáticamente el enfoque en un elemento y apuntar a él con JavaScript. El menos uno se omite cuando lo usas de forma predeterminada, pero puedes usarlo con JavaScript para enfocarlo programáticamente. Una cosa importante a tener en cuenta es no usar un índice de pestañas mayor que cero, porque confunde a los lectores de pantalla.

6. Atributos ARIA y Tecnologías de Asistencia

Short description:

Los atributos ARIA proporcionan información adicional a las tecnologías de asistencia para que puedan comprender lo que está sucediendo en la página. Por ejemplo, cuando haces clic en un botón de alternancia y tienes el ARIA check activado, puede ayudar a anunciar cosas. Entonces, digamos que tienes un micrófono y estableces el ARIA check en true, puede anunciar el estado de ese micrófono.

El siguiente es ARIA, y estos son los atributos ARIA. Hay muchos de ellos, y solo he enumerado algunos de los que he estado usando comúnmente. Los atributos ARIA proporcionan información adicional a las tecnologías de asistencia para que puedan comprender lo que está sucediendo en la página. Por ejemplo, cuando haces clic en un botón de alternancia y tienes el ARIA check activado, puede ayudar a anunciar cosas. Entonces, digamos que tienes un micrófono y estableces el ARIA check en true, puede anunciar el estado de ese micrófono. Puedes decir `micrófono encendido` o `micrófono apagado`. Y esto ayuda a los lectores de pantalla.

7. Roles, Keyboard Navigation, and Tools

Short description:

Si puedes usar un elemento HTML nativo, úsalo en lugar de usar un rol. El botón te brinda accesibilidad gratuita. Prueba tu sitio con la navegación por teclado. Desconecta tu mouse o trackpad y verifica si puedes acceder a cada parte de tu aplicación a través de la navegación por teclado. Recuerda Starrk: HTML semántico, tabindex, roles y navegación por teclado. Proporciona atributo de audio, rol de audio y etiquetas explícitas para elementos interactivos. Usa el atributo alt para imágenes relevantes. Usa role=presentation para omitir imágenes no pronunciadas. Etiqueta multimedia y proporciona subtítulos. Asegúrate de tener suficiente contraste de color. Ejecuta pruebas de automatización para detectar cualquier problema que hayas pasado por alto.

R significa rol. Hay muchos roles disponibles. Pero ten cuidado. Si puedes usar un elemento HTML nativo, úsalo en lugar de usar un rol. El problema del rol es que debes construir accesibilidad sobre él. Entonces, si estás usando un div y agregando un rol, no estás usando un botón. El botón te brinda accesibilidad gratuita. Así que usa elementos nativos tanto como sea posible, en lugar de agregar un rol encima de ellos.

Y finalmente, la navegación por teclado y el lector de pantalla. Prueba tu sitio con la navegación por teclado. La navegación por teclado significa básicamente usar solo el teclado para navegar por tu sitio, en lugar de usar el trackpad o el mouse. Un consejo rápido es desconectar tu mouse o trackpad y verificar si puedes acceder a cada parte de tu aplicación a través de la navegación por teclado. Y verifica si el contorno de enfoque también se mantiene visible y sabes dónde te encuentras en tu página web.

Entonces, si quieres recordar esos acrónimos, nuevamente, recuerda Starrk. Y aquí tienes una lista rápida de cosas que puedes hacer antes de lanzar tu aplicación. Así que recuerda Starrk, HTML semántico, tabindex, roles y navegación por teclado. Asegúrate de que no haya trampas de teclado y que el enfoque se mantenga visible en tu sitio. Para cualquier elemento interactivo, proporciona un atributo de audio, un rol de audio, y proporciona etiquetas explícitas sobre qué es ese elemento. Por ejemplo, un video. Todas las imágenes relevantes deben usar el atributo alt. Si tienes una imagen que no deseas que se pronuncie, por ejemplo, es un icono de marca de verificación o es solo un elemento de presentación, puedes usar el rol igual a presentación para omitirlo. Y asegúrate de etiquetar todo tu contenido multimedia. Debes tener subtítulos disponibles para cualquier cosa que sea auditiva. El texto tiene suficiente contraste de color. Y asegúrate de ejecutar pruebas de automatización para detectar cualquier cosa que hayas pasado por alto.

Muy bien. Ahora veamos algunas herramientas disponibles. Hay muchas herramientas disponibles. Pueden hacer la mayoría de estas cosas por ti y proporcionar una lista de errores que tu aplicación puede tener. Hay extensiones de navegador.

8. Accessibility Tools and Demo

Short description:

Axe y wave son herramientas populares de accesibilidad. Utiliza la navegación por teclado, el lector de pantalla y las herramientas de automatización para garantizar la accesibilidad. Prueba tu aplicación con usuarios reales para una evaluación completa. Ahora veamos una demostración de un sitio inaccesible e intentemos depurarlo.

Axe y wave son populares. Hay muchas herramientas de accesibilidad integradas en los propios navegadores. Firefox y Chrome. Lo demostraremos en un momento. También hay herramientas de construcción que puedes usar dentro de tu propio código. Y finalmente, hay herramientas de CI que pueden ayudarte a mostrar errores cuando hayas publicado tu código.

Entonces, antes de lanzar tu función o antes de terminar, antes de crear tu PR, asegúrate de probar la accesibilidad. Utiliza la navegación por teclado para asegurarte de que tu contenido sea accesible. Recuerda Stark. Y verifica tu aplicación. Asegúrate de que sea navegable por teclado. Utiliza el lector de pantalla y las herramientas de automatización para encontrar errores que hayas pasado por alto. Y finalmente, asegúrate de probar tu aplicación con usuarios reales. El código no puede detectar tantos errores. Incluso puede decirte que tu aplicación está perfecta al 100%, pero si un usuario no puede entender tu aplicación, no tiene sentido. Así que asegúrate de hacer pruebas con usuarios reales.

Muy bien. Ahora vamos a ver una demostración rápida de un sitio que no es muy accesible y vamos a encontrar los problemas que tiene y ver si podemos depurarlo. Voy a duplicar mi pantalla. Perfecto. De acuerdo. Así que me puse en una situación difícil. Construí un sitio y si lo miras ahora, se ve visualmente bien. Mis habilidades de diseño están bien. Si pasas el cursor sobre un elemento, puedes ver qué elemento debería resaltarse. Cuando haces clic en él, también se abrirá. Hay algunos enlaces y algunos videos en la parte inferior. Ahora veamos lo que vería una persona que utiliza una tecnología de asistencia. Así que voy a activar el lector de pantalla. Y pido disculpas por el ruido.

9. Screen Reader Focus and Accessibility Tree

Short description:

Reproducción del video. Observa en qué se enfoca el lector de pantalla y en qué se salta. Se enfoca en leer blogs y buscar más charlas, pero se saltó por completo una sección. Vamos a investigar. Cerrando VoiceOver, abriré las propiedades de accesibilidad en Chrome y Firefox. El árbol de accesibilidad ayuda a los lectores de pantalla a comprender la página. Muestra elementos en los que se puede enfocar y en qué se enfocará a continuación. Firefox tiene una función de accesibilidad aún mejor.

Reproducción del video. Así que observa en qué se enfoca el lector de pantalla y en qué se salta. Se enfoca en leer blogs y también puedes ver el contorno. Está en la parte superior de mi publicación de blog. Eso es genial. Y lo siguiente en lo que se enfoca es buscar más charlas. Así que se saltó por completo esa sección. Veamos qué está pasando. Y esta es una experiencia realmente mala para alguien que usa un lector de pantalla porque no vio ninguna publicación de blog que escribí. Así que voy a cerrar VoiceOver y ver qué está pasando.

De acuerdo. Así que tengo Chrome abierto aquí y también tengo Firefox abierto aquí porque quiero mostrarte ambas herramientas. Lo que voy a hacer es abrir las propiedades de accesibilidad en Firefox y abrir las propiedades de accesibilidad en Chrome. Puedes encontrarlas aquí. Asegúrate de que esté ampliado. De acuerdo. Lo primero que veremos es el árbol de accesibilidad. Y este es el árbol que un lector de pantalla usaría para comprender lo que está sucediendo en la página. Puedes encontrarlo aquí. Habilitar el árbol de accesibilidad de página completa en Chrome. Cuando haces clic en eso, te muestra una ventana emergente para recargar las herramientas de desarrollo. Lo haremos. De acuerdo. He recargado y ves al hombrecito aquí, y así es como puedes acceder al árbol de accesibilidad. Esto se ve un poco diferente que el árbol DOM, pero básicamente la idea aquí es que te mostrará todas las cosas que un lector de pantalla estaría viendo. Es posible que puedas ver cosas como enfocable verdadero. Eso significa que puedo ver esto y puedo enfocarlo. Y luego cosas aquí que se enfocarán a continuación. Volveremos a esto en un momento.

En Firefox, esto es aún mejor.

10. Debugging Keyboard Issues in Firefox

Short description:

En Firefox, encontré problemas con el teclado durante las pruebas. El problema es que los elementos interactivos deben ser enfocables. Agregar un atributo de índice de pestaña a un div no es correcto ya que el div no es un elemento interactivo. En su lugar, encuentra el siguiente elemento interactivo, que en este caso es una etiqueta de anclaje. Sin embargo, la etiqueta de anclaje no tiene el atributo href.

En Firefox, tiene estos problemas, ya tiene esta función de testing incorporada. Entonces, lo que puedo hacer es hacer clic en buscar problemas. Y descubrí que tenía problemas con el teclado. Voy a hacer clic en teclado. Y ahora veo que me está dando algunos errores aquí. Déjame ver si puedo ampliar eso. Bajar eso. Entonces ves que todos estos son problemas que mi contenido está teniendo actualmente. Estoy tratando de debug este. Así que voy a abrir esto y ver qué está pasando.

Entonces veo que hay un problema de teclado aquí. Veamos cuál es el problema. Dice que los elementos interactivos deben ser enfocables. Y para entender lo que eso significa, voy a abrir este enlace. Pero básicamente, dice que necesitas tener un índice de pestaña en tu contenido. Parte de stock. De acuerdo. Entonces, para hacer eso, veamos cómo se ve mi contenido. Voy a inspeccionar esto. Entonces, si ves aquí, esta es mi caja. Veo que hay un div aquí. Ahora, nuestra sugerencia fue agregar un índice de pestaña. Entonces, es posible que tengas la tentación de agregar un índice de pestaña a esta caja en sí. Pero recuerda, el índice de pestaña solo debe agregarse a elementos interactivos. El problema de agregar un índice de pestaña al div es que el div en realidad no es un elemento interactivo. Un elemento interactivo es un botón o un enlace. Entonces, en lugar de agregar un índice de pestaña al div, baja por el árbol y ve cuál es nuestro próximo elemento interactivo.

Entonces, si miro el árbol, hay una etiqueta de anclaje aquí. Ahora, veamos cuál es el problema. Tengo una clase aquí, pero no tengo ningún href.

11. Debugging Keyboard Issues and Tabbing Order

Short description:

Con la ayuda del árbol de accesibilidad y una prueba rápida, puedo identificar y solucionar problemas. La función de orden de tabulación es útil para depurar la tabulación incorrecta. Utilice herramientas de accesibilidad del navegador para depurar aplicaciones web. Asegúrese de que los contornos siempre sean visibles durante la navegación con el teclado. Algunas aplicaciones hacen que las aplicaciones web sean accesibles agregando índices de pestañas en todas partes.

Y ese es el problema. Así que con la ayuda de este árbol de accesibilidad y una prueba rápida, puedo descubrir cuál es el problema. Si agrego href aquí, podré hacer tabulación en él. Sin problema. Muy bien.

Aquí hay otra cosa realmente genial que quiero mostrarte. Y eso es el orden de tabulación, si puedo encontrarlo. Ahí está. Tiene un orden de tabulación aquí. Y tarda un poco en cargarse realmente. Y básicamente lo que hace es mostrarme en qué secuencia se está haciendo tabulación en cada elemento. Pone como un 1, 2 y como 4, 5 aquí, según el orden de tabulación de cada elemento es. Y eso es muy útil para depurar cuando quieres hacer cuando quieres debug, supongamos que tu elemento no se está tabulando correctamente. Así que eso es el orden de tabulación. Asegurémonos de haber tomado todos estos. Genial. OK. Así es como puedes encontrar problemas con tus web apps y ver, usar las herramientas de accessibility del navegador para debugarlos.

Ahora voy a cambiar de nuevo. Y veamos. Ah, maldición. El otro. OK. Volviendo a la presentación. Y reproducir. ¡Genial! OK. Entonces, algunas cosas que vimos fueron arreglar etiquetas de anclaje rotas. Una cosa que no sé si notaron fue que cuando nos enfocamos, nuestros contornos eran visibles debido al lector de pantalla. Así que eso es algo que debemos asegurarnos de que cuando usemos la navegación con el teclado nuestros contornos siempre sean visibles. Ahora hay aplicaciones que han hecho que la aplicación web sea accesible simplemente agregando índices de pestañas en todas partes.

12. Atajos de Teclado y Enfoque en Secciones

Short description:

Pero puedes hacer más que eso. Puedes proporcionar atajos de teclado para acciones comúnmente utilizadas. Te mostraré una aplicación que va más allá para garantizar la accesibilidad. Ofrece navegación por teclado, enfoque en secciones y atajos para tareas comunes como editar mensajes.

Pero puedes hacer un poco mejor que eso. Hay algunas aplicaciones que ofrecen saltar al contenido principal y eso es un gran primer paso. Pero puedes hacer más que eso. Puedes proporcionar atajos de teclado para cosas que son comúnmente utilizadas por un usuario. Y ahora te mostraré una aplicación que ha ido más allá para garantizar una experiencia de usuario accesible.

De acuerdo. Así que déjame reproducir este video. No funciona muy bien. De acuerdo. De acuerdo. Voy a volver a las pantallas principales. De acuerdo. Así que si miras este video, voy a usar la navegación por teclado para recorrer todos estos elementos, y notarás que detecta que estoy usando el teclado, y muestra un mensaje emergente diciendo que si estás usando el teclado, entonces hay algunos atajos disponibles. Y eso fue realmente genial. Me sorprendió mucho ver esto. Básicamente lo que me está diciendo es que puedes usar esta tecla de comando o atajo de comando para enfocarte en una determinada sección. Vamos a ver cómo funciona eso.

Básicamente lo que hace es que cuando uso el comando de control y la flecha izquierda o derecha para mover el enfoque entre secciones, mantendrá el enfoque en esa sección en sí. Ahora voy a usar el comando de control de enfoque, y verás que ahora está en la sección izquierda, y ahora si sigo presionando la tecla Tab, no irá a la sección de mensajes. Mantendrá el enfoque en esa sección. Y eso ayuda a las personas que tienen problemas para enfocarse en una determinada sección, especialmente si hay mucho contenido en la página. Y puedes pensar en Slack como una aplicación donde hay toneladas de mensajes, así que tal vez cuando sigas presionando la tecla Tab en un mensaje, puede ser muy difícil navegar hasta ese mensaje. Entonces, atajos como estos realmente ayudan mucho a las personas para asegurarse de que el enfoque se mantenga en un área específica, en lugar de tener que pasar por cada elemento interactivo en la página. Y ahora puedo usar las teclas de flecha del teclado para mantenerme en esa sección enfocada. También puedo usar más que solo las teclas Tab, y puedo usar las teclas de flecha para ir entre otras secciones de la aplicación. Por ejemplo, en Slack, una de las cosas más importantes es escribir un mensaje. Entonces escribirás un mensaje, y ahora digamos que cometí un error y quiero editarlo. Ahora puedes usar tu tecla de atajo, que es la tecla E en Slack, para subir un mensaje y editarlo. Así es como una aplicación ha estado pensando en la accesibilidad seriamente y no solo usando las teclas Tab para hacer todo accesible, sino también pensando en las cosas más comunes que un usuario puede hacer y mejorando esa experiencia para el usuario. Muy bien.

13. Visión general de la accesibilidad y consideraciones clave

Short description:

En esta charla, discutimos las pautas y principios de accesibilidad, así como los diferentes tipos de discapacidades. Exploramos Stark, HTML semántico, índice de pestañas, atributos, roles y navegación. Estas son consideraciones importantes para construir aplicaciones web accesibles y evitar la necesidad de una refactorización extensa. Compartiré más información a través de publicaciones en el blog en el futuro.

Debido a que esto se está volviendo más difícil, simplemente voy a presentar desde aquí. Genial. De acuerdo. Entonces, en la charla de hoy, examinamos las pautas de accesibilidad, los principios de accesibilidad, los diferentes tipos de discapacidades que las personas pueden tener. Hablamos sobre Stark, HTML semántico, índice de pestañas, atributos, roles y K para... ¡Navegación! Estas son algunas cosas simples para tener en cuenta al construir tu próxima aplicación web. Para que una vez que hayas terminado, no tengas que volver atrás y refactorizar y pasar mucho tiempo deshaciendo el trabajo que hiciste y volviendo a hacer todo ese trabajo. Así que espero que esto te haya dado una buena indicación de las cosas que puedes tener en cuenta. Y si estás interesado en seguir el camino hacia adelante, enviaré una publicación de blog de todo lo que hablé hoy y todo en el futuro. Y si quieres, puedes registrarte aquí.

14. Final Joke, Alt Attributes, Testing, and Pitching

Short description:

No podemos irnos sin un último chiste de desarrollador. ¿Existe tal cosa como demasiada información con atributos alt o etiquetas ARIA? Es un error común agregar un rol a HTML semántico como botones. Tanto las pruebas a nivel de componente como las pruebas de extremo a extremo son importantes para la accesibilidad. Convence a los interesados de implementar accesibilidad enfatizando el requisito legal y el costo de la refactorización posterior.

No podemos irnos sin un último chiste de desarrollador. ¿Quién ganó el debate sobre el mejor dispositivo portátil? ¿Qué dijiste? ¡Yo gané! Muchas gracias a todos. Han sido geniales. Muchas gracias, Rudy. ¿Quieres tomar asiento? Prometo no retenerlos mucho tiempo ni hacer preguntas demasiado difíciles, principalmente porque nos estamos pasando un poco de tiempo y la gente quiere su café.

Pero respondamos aquí la pregunta más votada, que creo que es una muy buena pregunta y no sé la respuesta. ¿Con atributos alt o etiquetas ARIA, existe tal cosa como demasiada información? ¿Cómo decides qué poner realmente? Esa es una gran pregunta. Creo que una de las cosas y uno de los errores más comunes que la gente puede cometer es especialmente si estás usando HTML semántico como botones, puedes agregar un rol a ello. Podrías hacerlo. Técnicamente, no rompe nada, pero es un trabajo inútil. No necesitas hacer eso si estás usando HTML semántico, así que. Sí.

Genial, eso fue muy rápido, hagamos otra. Hay muchas herramientas de prueba de accesibilidad disponibles. En tu opinión, ¿cuál es la mejor fase para probar tu código? ¿Es a nivel de componente o a nivel de extremo a extremo cuando se trata de accesibilidad? Oh, gran pregunta. Creo que ambos son realmente importantes, pero al final del día, creo que una vez que tu código está en manos de los usuarios, es muy importante hacer pruebas de accesibilidad allí. Puedes asegurarte de tener HTML semántico, tu código se ve genial. Pero si no es utilizable para el usuario y no pueden acceder a la información, creo que no sirve para nada. Eso es muy cierto. Y en mi práctica personal, solo hago pruebas de extremo a extremo para accesibilidad porque generalmente utilizo bibliotecas de componentes accesibles que hacen sus propias pruebas a nivel primitivo. Consejo profesional. Usa Radix.

Muy bien. Y luego la pregunta final. ¿Cómo presentaríamos la implementación accesible a los interesados? ¿Hay algún tipo de argumento que tienda a funcionar bien? Oh, gran pregunta de nuevo. Una cosa que puedes decirles es que es un requisito legal, por lo que si no se ocupan de ello, tendrán que pagarlo, y mucho. Otra cosa para recordar es que, no sé, si tienes una experiencia de caso de uso de tu propia experiencia, si tienes un caso de uso de tu propia experiencia, pero en mi experiencia he notado que construimos aplicaciones web y luego nos damos cuenta de que no son accesibles, volvemos atrás y refactorizamos todo el componente. Y eso también me ha pasado a mí, y desperdicié como un mes de mi tiempo, así que es mejor comenzar con la accesibilidad desde el principio y desde el nivel de diseño en sí en lugar de volver a ello y refactorizarlo. Palabras sabias. Y eso es todo lo que tenemos tiempo. Muchas gracias, Ruti, por tu charla y los chistes. Muchas gracias. Espero escuchar más más tarde. 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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn