Construyendo interfaces de usuario - ¡Por la gente, para la gente!

Hola a todos, espero que estén teniendo un gran día. Hablaré sobre un tema interesante que es la construcción de interfaces de usuario por y para las personas. Antes de profundizar, para aquellos que no me conocen, soy Nikhil, soy ingeniero de software en Postman, principalmente me ocupo de cosas relacionadas con Postman en la web, la plataforma de escritorio de Postman y el sistema Xen en Postman. Estaré allí, pueden conectarse conmigo a través de Twitter o GitHub. Vengan a saludar, me encantaría tener una charla.

Muy bien. Antes de profundizar, vamos a entender una pequeña analogía que me gusta mucho cuando se introduce un concepto como la accesibilidad. Imaginen si hay una constitución de un país, garantiza a los ciudadanos algunos derechos, digamos que hay derecho a la educación, derecho a la religión y también derecho a la expresión. Cosas así. Tomando eso solo como ejemplo de una constitución de un país, podemos decir que al igual que la constitución es la que garantiza una igualdad de estatura, independientemente de cuál sea el origen de una persona. Ahora, cuando se trata de la accesibilidad, podemos hacer algunos cambios en la declaración. Ahora la declaración puede decir que, muy bien, la accesibilidad también hace lo mismo. Nos garantiza una igualdad de consumo de una interfaz de usuario, independientemente de cuál sea la discapacidad de una persona. Cosas simples, simplemente dicho. La accesibilidad significa simplemente que si tengo un producto o un servicio, la accesibilidad permitiría a una persona, independientemente de cualquier tipo de discapacidad que pueda tener, acceder al producto y utilizar todas sus funciones en una experiencia fluida.

Entonces, en nuestro caso, limitaremos esta charla solo a la accesibilidad del contenido web, pero la accesibilidad es un tema mucho más amplio. Utilizamos muchas herramientas para tener una experiencia accesible para nuestros usuarios, como lectores de pantalla, que nos ayudan a anunciar lo que hay en la pantalla para las personas que tienen problemas de visión. Hay navegación por teclado para aquellos que no tienen un mouse o tienen un problema para mantener el mouse estable y no pueden usarlo directamente. Entonces, hay accesibilidad mediante teclado para eso. Pero discutiremos más sobre esto a medida que avancemos con la charla.

Entonces, yendo más allá, es posible que ya sepan que ya tenemos accesibilidad en el mundo real, ¿verdad? Para aquellos que tienen problemas para caminar, tenemos sillas de ruedas para ellos para que puedan moverse. Tenemos un bastón inventado para personas que tienen problemas de visión, o incluso tenemos escrituras en braille para que las personas que tienen problemas de visión puedan leer claramente. Entonces, si la accesibilidad tiene tanta importancia en el mundo real, ¿por qué el mundo de JS se quedaría atrás, verdad? Con este pensamiento en mente, veamos dos conceptos importantes antes de avanzar con la charla.

A la izquierda, podrán ver que está WCAG. Ahora, este término significa Directrices de Accesibilidad al Contenido Web. No es nada extravagante, sino simplemente un conjunto de directrices y listas de verificación que han sido elaboradas por un grupo de personas de todo el mundo, y estas listas de verificación ayudan a las personas a hacer que el contenido dentro de sus aplicaciones sea más accesible y más accesible para cualquier tipo de personas con discapacidad. Ahora, a la derecha está solo un subconjunto de esta WCAG, que llamamos WAI, que significa Iniciativa de Accesibilidad Web, Aplicaciones Ricas en Accesibilidad. Ahora, lo que dicen es que, muy bien, quieres cumplir con las directrices de WCAG, ahora, muy bien, tengo algunas API para que puedas usar en tu código y cumplir con esas directrices. Entonces, ya sabemos que hay muchas API de accesibilidad como esta, hay ARIA inválido, que dice que, muy bien, los lectores de pantalla sabrán que una vez que una entrada es inválida, pueden anunciarlo en la pantalla. Hay ARIA requerido para anunciar en la pantalla, ¡oye, estás en una entrada que requiere una alimentación!

Entonces, hay cosas como esa. Y veremos más al respecto en las diapositivas siguientes, pero sí. Solo una cosa a tener en cuenta es que, especialmente, esto es especialmente relacionado con el mundo de JSX o el mundo de React en el que tenemos este tipo de modelo mental en el que usamos camel case para cada prop, pero eso no es lo mismo con la accesibilidad. Entonces, con estos atributos de accesibilidad, simplemente tenemos que usarlos tal como son, como lo hemos estado usando con HTML, que es con valores separados por guiones y no en camel case. Así que ahí tienes un pequeño consejo.

Y pasando a por qué deberíamos preocuparnos por la accesibilidad. Ahora, la primera y principal razón es que te sorprendería saber que el 15% de la población mundial tiene algún tipo de discapacidad. Entonces, si no hacemos que nuestras aplicaciones sean accesibles, eso significa que el 15% de una gran parte de nuestra audiencia, que es un número que no podemos ignorar, no puede usar nuestras aplicaciones de la manera que queremos, ¿verdad? Y la segunda cosa es que si tenemos una aplicación que se va a utilizar en varios países, es decir, tiene un alcance en todo el mundo. Es posible que queramos ver que hay países que realmente le dan importancia a la accesibilidad y a las personas que tienen alguna discapacidad. Por ejemplo, hubo un caso muy reciente, ¿verdad?, que todos conocemos, sobre el sitio web de Domino's donde, según la Ley de Discapacidad de los Estadounidenses, no cumplía con las prácticas de accesibilidad que deberían estar presentes. Entonces, si estás creando un sitio web y va a tener alcance mundial, asegúrate de tener estas cosas en mente. Muy bien.

Con esta charla, vamos a desmentir algunos mitos sobre la accesibilidad. Por ejemplo, que la accesibilidad es solo para personas con discapacidad. No diría eso porque la discapacidad también puede significar que alguien no tiene un mouse, eso también es una discapacidad. Si muestras un cargador en la pantalla cuando algo aún se está cargando, eso también es una experiencia accesible que les estás brindando a los usuarios. Entonces, el significado más profundo de la accesibilidad es atender cualquier tipo de discapacidad y no solo la discapacidad física. Eso es solo un subconjunto. Y el segundo es que la accesibilidad es difícil. Creo que veremos esto al final de esta charla, que no, no lo es y la accesibilidad tampoco se trata solo de aria evidente y hay 10 o más prácticas que puedes hacer para que nuestras aplicaciones sean más accesibles. Y sí, esta charla no es una introducción a la accesibilidad. No es solo una clase teórica. Quiero que sea cada vez más inclusiva y más orientada a la demostración para que después de esta charla, tengamos una idea clara de cuál es el significado más profundo de la accesibilidad y cómo podemos comenzar sin tener que leer esos grandes blogs en Internet, ¿verdad? Muy bien.

Con todas estas ideas en mente, comencemos. El primer y más importante consejo que doy a todos es utilizar las etiquetas HTML correctas, lo cual generalmente nos ayuda en la mayoría de los casos para la accesibilidad. Ahora, cuando usamos las etiquetas HTML correctas, nuestros lectores de pantalla utilizan esa información para proporcionar el contexto correcto sobre lo que hay en la pantalla. Por ejemplo, si estás utilizando un botón HTML, los lectores de pantalla pueden decirle a las personas que, okay, esto es un botón. Y estas etiquetas HTML también te brindan algunas ventajas importantes. Por ejemplo, no tienes que preocuparte por el orden de tus botones o por los elementos dentro de un formulario, no tienes que pensar en cuál debe ser el primer elemento que se selecciona, cuál debe ser el último, si el foco se mueve primero o no. Todo esto ya está incorporado. Una vez que uses las etiquetas HTML correctas, también puedes, si quieres ampliar esta definición de accesibilidad, tienes colegas que están utilizando la misma estructura HTML en su código diario.

Y están trabajando en ello. Y si usas algo en la izquierda que ves, como una gran lista de divs, podría ser difícil para ellos, tienen que abrir cada uno de sus div para averiguarlo. Oh, ¿qué? Oh, esto es como un div de encabezado. Oh, luego en este div, okay, hay esta sección principal aquí en este último div. Oh, esto es un pie de página. Okay. Pero en el lado derecho, si ves, si estamos usando un conjunto correcto de HTML, no solo le da a los lectores de pantalla una buena experiencia, sino que también les permite a tus colegas y desarrolladores descubrir qué hay en cada parte de tu aplicación. Así que aquí hay un pequeño gráfico para ayudarte a descubrir, qué significa cada área y como, qué etiqueta semántica debería tener cada área. Por ejemplo, lo más importante debería ser un encabezado. Después del encabezado, debería haber una etiqueta de navegación que muestre la navegación y cosas así. Y JSX accesible, como ya mencioné, no es accesible HTML. Así que, por lo general, veo algunas consultas de personas que dicen, `Oye, estoy usando estas tres cosas como mencionaste, Nikhil, pero aún no tengo accesibilidad`. Diría que hay un HTML accesible que debería aplicarse a tus componentes accesibles, como el encabezado y el menú en la izquierda, eso debería hacer las cosas accesibles. Así que otra cosa a tener en cuenta, y déjame también darte, como un pequeño resumen de cómo nosotros también complicamos las cosas tanto para los usuarios como para nosotros mismos. ¿De acuerdo? Así que imaginemos un caso en el que tenemos un div y al hacer clic, tenemos una función que manejará cosas cuando se haga clic en este div. Ahora, esto simula un botón, pero ahora dirás, `Oye`. Mis lectores de pantalla no están leyendo esto. Lo leen como un div. ¿Cómo le digo a mis lectores de pantalla? Ahora dirás, `De acuerdo, tenemos IA text`. Asignémosle un rol como botón. Y diremos, `Oh, eso está bien`. Ahora lo he solucionado. Y luego dirás, `Oye, pero no me da una experiencia de navegación por pestañas`. ¿Cómo muestro que, uh, un enfoque particular aparece cuando alguien está en este día en particular para un botón, pero alguien hace clic en él, entonces diremos, `De acuerdo,` hay un índice de pestaña, debes darle un valor cero y debes, así que tienes que hacer todo este mambo-jambo, ¿verdad? Cuando no estás usando HTML semántico, pero la realidad era como, como algo súper simple. Solo tenías que usar algo que era simplemente un botón y todo eso se convirtió en algo grande para ti. Así que si estás utilizando el HTML correcto, también tienes menos problemas tanto para ti como para los lectores de pantalla, etc.

Muy bien. Pasando al próximo tema, que es la accesibilidad de palabras clave. Como su nombre ya sugiere, la accesibilidad de palabras clave simplemente significa que tu aplicación debe ser utilizable y debes poder interactuar con cualquier parte de esa aplicación solo con la navegación por pestañas, sin usar un mouse. Deberías poder usarlo.

Y eso significa que también debería haber, como, ninguna trampa de palabras clave. Como si sigo presionando eso, es, es que debería poder ir a cada parte de mi aplicación, como cada parte de mi pantalla y no solo, simplemente sigo girando alrededor de uno o dos botones y campos de entrada. Entonces, básicamente eso es lo que significa.

¿Por qué es importante la accesibilidad de palabras clave? Uh, lo primero y más importante es que, si hay personas que tienen problemas de visión o que son ciegas, generalmente dependen de los teclados y cuando hacen clic en cosas, dependen del lector de pantalla para que les diga exactamente dónde están en la página. Así que eso es realmente importante. Y también, si alguien no tiene un problema de visión, hay un problema con discapacidades motoras donde si alguien usa un mouse, no pueden tener una mano estable y tienen problemas para interactuar con un mouse porque su mano no es estable, ¿verdad? Así que eso también es cuando entra en juego la accesibilidad del teclado porque tienen que depender de un teclado. Y en tercer lugar, en general, a todos nos encantan las palabras clave, como si también estás viendo esto, estoy usando más de un, como mis navegaciones por teclado para ir entre las pantallas en lugar de usar el mouse y el trackpad. ¿Verdad? Así que es bueno tener accesibilidad del teclado en tu aplicación en este espacio.

Y, como HTML para el viento aquí mismo, porque estoy usando, en esta pequeña demostración, un formulario de inicio de sesión. Estoy mostrando que una vez que hago tabulación, no estoy usando ningún mouse y simplemente estoy navegando por los elementos con la tecla Tab y puedo ir a cada conjunto correcto de mi HTML en el orden correcto. Así que hay HTML semántico para la web. Entonces, todos los navegadores te dan un enfoque predeterminado. Como acabamos de ver en esta pantalla, el navegador nos está dando un borde de color azul predeterminado en cada elemento, pero podemos hacerlo personalizable y más vibrante porque queremos que nuestros sitios web se vean más bonitos, ¿verdad? Entonces, puedes usar una pseudo-clase de enfoque en este caso y aplicar un borde o agregar una sombra en esos casos para mejorar tus estilos de enfoque. También puede haber un caso en el que tengas un formulario de entrada y quieras enfocar por defecto, específicamente un campo de entrada cuando se carga un formulario, porque eso es una mejor experiencia. En ese caso, aunque este fragmento se enfoca más en React, puedes usarlo en JavaScript mismo, así que usando este gancho de efecto de uso que tienes en React, puedes, uh, usar una referencia de ese campo de entrada en particular y usando esa referencia puedes enfocarlo en el momento, las notas del espacio.

Ahora pasando a los campos de entrada y las etiquetas, siempre es una buena práctica usar etiquetas y, uh, esas etiquetas deben apuntar a tus campos de entrada. Como cuando alguien hace clic en una etiqueta, el elemento de entrada se enfoca automáticamente, lo cual es una cosa muy pequeña, pero una buena experiencia de usuario. Entonces, hay un atributo HTML for que se puede usar. Es una cosa muy simple en una línea. Me preguntarás, `Oye, no siempre necesitaré vivir con mi entrada`. ¿Verdad? En ese caso, mi respuesta sería tener una etiqueta de todos modos, pero usar una clase para ocultar esa etiqueta de tu pantalla. Pero esa etiqueta aún debe renderizarse en tu documento. Así que tengo esta clase llamada visually hidden, que estoy usando para ocultar mi etiqueta. Pero mi etiqueta está realmente ahí arriba. Se renderiza porque los lectores de pantalla aún van a ver lo que se renderiza en la parte superior porque quieren anunciar de qué se trata esta entrada. ¿Verdad?

Y van a hacer uso de esa etiqueta. Muy bien. También hay un montón de etiquetas de nivel ARIA que puedes usar. Por ejemplo, hay ARIA invalid true, que le indica a los lectores de pantalla que, hey, tu entrada es inválida y ellos pueden anunciarlo en la pantalla. Y de nuevo, como formularios accesibles. Tengo un montón de otros elementos de entrada como field set legend para que puedan proporcionar más información sobre los formularios.

Ahora pasando a la navegación, la navegación también es muy importante porque ahora en nuestro caso, tenemos muchos niveles anidados de páginas y una vez que estamos en lo profundo de un flujo, queremos ver exactamente dónde estamos y queremos navegar más rápido. Entonces, hay un elemento de navegación que son las migas de pan. Muy bien. Así que, en este caso, querrías manejar una navegación hacia el contenido principal cuando se trata de la experiencia de tabulación. Muy bien. Entonces, si alguien está tabulando y tienes muchos enlaces, algunos usuarios pueden no querer ir a esos enlaces. Ellos directamente quieren ir al contenido principal de tu aplicación. Y ahí es donde podemos simplemente insertar una clase de ancla y una etiqueta de ancla. Y al hacer clic en esa ancla, se saltará directamente nuestra experiencia de tabulación para ir al contenido principal. Así que eso será otra experiencia para aquellas personas que solo usan el teclado. Muy bien. Pasando a los SVGs accesibles, aunque ya sabemos cómo usar los SVGs, usar un atributo de título y descripción dentro de ellos puede ayudar a los lectores de pantalla a saber de qué se trata ese SVG. Así que cuando lo anuncien, no se volverán locos, sino que conocerán una pequeña descripción al respecto. Así que les da a los usuarios una imagen significativa de qué es, okay. Qué es esta imagen, o qué es este SVG. Muy bien. Usar un título de documento es una cosa muy pequeña. Normalmente lo pasamos por alto, pero es algo muy importante. Así que una vez que tenemos una idea de qué se trata una aplicación de una sola página, ya sea en JavaScript o React, aunque nuestra página esté cambiando, nuestros títulos de documento suelen permanecer iguales. Así que también queremos cambiar los títulos de documento porque nuestros lectores de pantalla también los van a leer. Así que, digamos de nuevo en React, puedes usar el componente Helmet. O también podemos usar hooks para cambiar el título del documento. Cada vez que cambias el estado o cada vez que piensas que estás yendo de una página a otra página.

Así que esa es una mejor experiencia de usuario. También hay una biblioteca llamada como React document title que puedes usar. Y siento que es mucho más declarativo, pero puedes usar cualquiera de esos enfoques. Depende totalmente de ti.

Muy bien. Pero creo que compartí algunas ideas contigo y hay todo como de nuevo, como la accesibilidad es como una, aunque muy larga, es un largo viaje, pero con esta charla podrás comenzar a dar los primeros pasos y estarás en una posición para comenzar a migrar tus pantallas y comenzar a desarrollar algunas prácticas de accesibilidad en tus aplicaciones.

También hay un montón de ejemplos que quería cubrir, pero no pude hacerlo por falta de tiempo. Uh, hay contenido real que debería ser preciso y claro para las personas que no tienen la visión correcta. Debe haber internacionalización en su lugar porque las personas que están en diferentes áreas del mundo no tienen el mismo idioma. Pueden ser otros idiomas además del inglés que quieran usar en la aplicación. Entonces, si nuestras aplicaciones se convierten al mismo idioma según la región, eso las hace más utilizables y atractivas para las personas. Así que hay muchas más prácticas. Así que diría que si alguien está interesado, adelante y profundice en estos conceptos.

Muy bien. Entonces, con esto, veamos rápidamente una demostración de una aplicación de inicio de sesión que había creado. Primero te mostraré cómo era, qué anunciará el lector de pantalla en esta aplicación, no tiene ninguna similitud en la mano. Y luego veremos, después de aplicar estas prácticas que acabo de mencionar en la charla, qué puede cambiar para alguien, así que, como cierra los ojos e intenta imaginar, intenta ver lo que tú, en el espacio de un usuario ciego o una persona con discapacidad visual, vería o cuando estás escribiendo en este formulario.

Entonces, muy bien, déjame comenzar esta grabación. Encabezado de contenido web de la aplicación nivel uno. Formulario de inicio de sesión. HTTPS dos puntos barra barra www.mindinventory.com barra blog barra WP guion contenido barra uploads barra 2019 barra 0 6 barra reactjs guion benefits.jpg imagen y el campo de texto editable, una contraseña y un campo de texto editable seguro enlace visitado. Obtén más información. Chrome tiene una nueva ventana enlace visitado. Contáctanos. Actualmente estás en un enlace dentro del contenido web. Voiceover. Encabezado de contenido web de la aplicación nivel. Muy bien. Uh, minimicemos esto. Entonces sí, aunque creo que sí, básicamente ahora verías que el nombre de la imagen se pronuncia hasta su longitud y, uh, no estoy obteniendo información significativa sobre dónde exactamente me encuentro. Ahora intentemos ver cómo es exactamente la experiencia ahora después de agregar algo de accessibility. De acuerdo. Software ingresando, react, buena demostración diaria contenido web enlace visitado. Ir al contenido principal enlace visitado. Ir al contenido principal. Chrome principal. Formulario de inicio de sesión imagen de banner. Imagen ingresar nombre de usuario y el campo de texto editable requerido, ingresar contraseña. Y el campo de texto editable seguro requerido, botón de enviar. Enlace visitado. Obtén más información. Lista dos elementos enlace visitado. Contáctanos encabezado nivel uno.

Inicio de sesión para la imagen principal. Inicio de sesión para la imagen de banner. Entrar. Muy bien. Entonces parece estar un poco mejor, ¿verdad? Software.

Entonces, muy bien. Creo que hemos estado progresando. Otro detalle, algunas cosas pequeñas para mencionar. Me gustó mucho la herramienta AXE Dev Tools y realmente recomendaría a cualquiera que esté trabajando con accessibility que la use porque no solo muestra los errores en términos de prácticas de accessibility que has estado haciendo, sino que también te proporciona una solución para ello. Además, es muy descriptiva, así que realmente me encanta. Así que mi consejo es que cualquiera que confíe en ella la use.

Muy bien. Con esto, queremos finalizar nuestra discusión. Y hay algunos enlaces que se han agregado, los cuales están relacionados con las demos que he agregado. Y también el enlace a las diapositivas, que de todos modos no comparto con todos. Algunos de mis favoritos personales que creo que son muy buenas lecturas además de esto, y también te brindarán más conocimiento sobre algunas otras cosas que no pudimos discutir en la charla. Así que siéntete libre de seguir adelante con eso. Y sí, hagamos que nuestro contenido web sea más accesible para todos. Creo que con esta charla, espero que puedas obtener algunas ideas y ahora puedas incorporar la accessibility en tus aplicaciones. Como nota aparte, en Postman también nos fascinan las tecnologías como React y también la accessibility. Así que si quieres unirte a nosotros en este viaje de construir algo genial, no dudes en contactarnos en nuestra página de carreras y estaremos encantados de conectarnos. Muy bien, con esto doy por terminado y muchas gracias por invitarme. Gracias.