Creando una Web Accesible Juntos en 5 Pasos Sencillos

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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í.

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.