accesible para las personas. No, simplemente no sabía mejor en ese momento. Y necesitamos un mecanismo para hacer que algo de esto suceda. Creo que si lo integro en mi componente, los desarrolladores que lo usen se beneficiarán de este tipo de decisiones. Entonces, para esto, las aplicaciones serán un poco más accesibles y generarán más conciencia al respecto. Y creo que cosas como esa, como, ya sabes, la extensión de accesibilidad es genial. Pero ¿qué tal si tuviéramos este tipo de comprobación en nuestras aplicaciones de
typescript, como en el caso del componente? Que realmente deberíamos realizar para abordar los problemas relacionados con la accesibilidad y la privacidad. Sería un mecanismo, no solo, ya sabes, confiar en nuestras buenas intenciones que estoy seguro de que todos tendremos. Y cuando ves, ya sabes, las estadísticas de las 1 millón de páginas principales, puedes ver que muchos de los principales problemas en nuestras aplicaciones son fácilmente corregibles, como, ya sabes, el bajo contraste entre texto y colores, la falta de alternativas para imágenes que creo que fácilmente podemos, ya sabes, encontrar formas de evitar enlaces vacíos, etiquetas de entrada faltantes, botones vacíos, falta de idioma del documento. Creo que si dedicamos un poco más de esfuerzo en nuestros componentes, en nuestras bibliotecas, realmente podemos proporcionar una mejor experiencia de usuario. Y si ves el mismo informe, nos muestra que
React en sí no es, ya sabes, como tiene casi el mismo tipo de problemas que, ya sabes, cualquier otra página. Puedes ver que
Angular tiene el mismo número promedio de errores, pero puedes ver que algunas bibliotecas que consideramos, ya sabes, de mejor rendimiento, como
React, tienen muchos más errores en comparación con, ya sabes,
React o comparando, ya sabes, con otros tipos de
frameworks como
WordPress y Laravel. Creo que esto puede mostrar que a veces nos enfocamos tanto en una parte de nuestra aplicación que perdemos de vista que la experiencia de usuario no es una sola cosa. No se trata solo de interacciones rápidas. No es solo una cosa. Cuando hablamos de la experiencia de usuario, tenemos que hablar en plural. Tenemos que hablar de experiencias de usuario y para llegar a más personas, debemos tener accesibilidad desde el principio, porque cuando obtienes los números de personas que tienen algún tipo de problema, y esto puede incluir incluso a personas que leen en dispositivos de gama baja, que necesitan un mejor contraste en el teléfono, verás que no es un problema que afecta a un pequeño porcentaje de tus usuarios. Y diría que leas la documentación, la documentación es realmente genial, verás que cuando uses jiv y uses roles, de hecho, si usas los elementos correctos de
HTML, obtienes todo por defecto, ves las formas correctas de usar secciones y cosas así, a veces la gente piensa que solo usando secciones en lugar de jiv se resuelve el problema y no es exactamente así, si lees los documentos de Db3 verás que es una lectura mucho más amigable, creo que es muy amigable y aprenderás mucho y sigue el hashtag
A11y en Twitter para la accesibilidad, ya sabes, verás varios usuarios y tweets sobre este tema y formas que te ayudarán no solo a crear un mejor código sino a ofrecer una mejor experiencia de usuario. Y no te equivoques. Muchos de los problemas de accesibilidad también son problemas semánticos con tu código. Y me gustaría dejarles con el mensaje, depende de ti, depende de nosotros dar a los usuarios una mejor experiencia al usar nuestras aplicaciones. Y si, desde el principio, al crear nuestras bibliotecas, por pequeña que sea nuestra biblioteca, creo que si pensamos y creamos valores predeterminados sensatos, creamos mecanismos para que las personas ofrezcan experiencias accesibles y privadas por defecto, creo que haremos una web mejor y brindaremos una mejor experiencia para todos en la web y en nuestras aplicaciones de
React. Quiero agradecer a
React Summit por tenerme y crear una web mejor para todos. Adiós. Ciao.
