Haciendo las interacciones accesibles para todos los usuarios

Gracias, Metin. También es un honor para mí ser presentado por Metin. Es como mi MC favorito, así que sí.

Y hola a todos. Espero que estén disfrutando de la conferencia hoy. En primer lugar, me gustaría pedirles nuevamente que aplaudan a todos los organizadores y a todos los voluntarios. Han estado haciendo un gran trabajo organizando esto. Así que aplaudamos. Increíble.

Entonces, mi tema de hoy es hacer que las interacciones sean accesibles para todos los usuarios. De acuerdo. Bien. Así que la agenda es que comenzaremos con algunas breves presentaciones. Luego veremos un poco cómo los usuarios interactúan con la web y cómo podemos hacerla accesible, ¿de acuerdo?

Antes de comenzar, una breve introducción sobre mí. Trabajo como consultor frontend aquí en Ámsterdam. Soy un Experto en Desarrolladores de Google para web. Microsoft MVP. Embajador de Women Techmakers y Embajador de Cloudinary. Pueden conectarse conmigo en LinkedIn o Twitter en anrada15 o en Twitter en Miracle Underscore 404. Así que empecemos.

¿Qué es exactamente la interacción? En términos simples, significa que ha ocurrido algún contacto entre el usuario y la interfaz. Entonces, el usuario podría haber realizado alguna acción y hay alguna respuesta de la interfaz y eso se llama interacción.

Entonces, ¿cómo interactuamos todos con la web? ¿Puedo obtener algunos ejemplos? ¿Qué hacemos para interactuar con la web? Abrir un sitio web. ¿Qué hacemos? Hacer clic. Sí. Pasar el cursor. Desplazarse. Tabulador. Tecla de tabulación, sí. ¡Increíble! También escribimos cuando vemos un cuadro de entrada o algo así.

Tenemos que completar la información. Pasamos el cursor. Nos desplazamos. Usamos las pestañas, por supuesto. Estas son las formas en las que interactuamos. Veremos más en un momento.

Pero antes de eso, ¿qué es la accessibility? La accessibility significa hacer que los recursos y servicios sean utilizables por todos, independientemente de sus discapacidades. Ahora, ¿por qué debemos preocuparnos por la accessibility? Porque todo lo que construimos, lo construimos para nuestros usuarios. Entonces, los usuarios deberían poder usarlo, ¿verdad? Tenemos usuarios muy diversos. Pueden tener diferentes tipos de discapacidades. Y dado que tienen diferentes tipos de discapacidades, también interactúan con la web de diferentes formas. Diferentes tipos de tecnologías y dispositivos. Y se llaman tecnologías de asistencia.

Entonces, hay varias formas en las que podemos acceder a la web. Podemos usar el mouse normal, podemos usar el teclado, lectores de pantalla, lectores de braille , un interruptor de pantalla braille y mucho más. Hay muchas más opciones. Así que ahora volvamos a revisar. Sí, interactuamos con la web de estas formas. Pero también podemos usar la tecla de tabulación. Podemos usar la tecla Enter si queremos ir allí. Si no podemos hacer clic. Si no podemos usar un mouse. Entonces, tal vez solo dependamos del teclado. Entonces iremos y presionaremos Enter en él. La barra espaciadora, podemos usar la tecla de tabulación, escape para alejarnos de un modelo, podemos usar las teclas de flecha para navegar. Así que hay muchas formas en las que podemos navegar. Y esto es algo de lo que debemos ser conscientes. Ahora mostraré algunos ejemplos. Y el enlace está en Code Sandbox y compartiré las diapositivas al final. Así que no se preocupen por eso.

Y los ejemplos son bastante simples, no tan complejos. El formato es simplemente mostrar un escenario inaccesible. Luego veremos cómo podemos solucionarlo. Y cuál debería ser el comportamiento accesible.

Entonces, el primer escenario es el botón. Muy simple, ¿verdad? Pero los botones están en todas partes. Botones y enlaces. No podemos hacer nada al respecto. En cualquier lugar al que quieras ir, usarás botones, usarás enlaces para navegar, y así sucesivamente. Así que veamos. De nuevo.

Aquí hay un botón, tal vez registrarse, iniciar sesión. Hago clic en él, algo sucede. Aquí solo sucede un mensaje y así sucesivamente. Así que puedo hacerlo bastante bien cuando uso el mouse. Pero comencemos a usar el teclado. ¿El tamaño de fuente está bien? Así que comienzo a usar la tecla de tabulación. Presiono la tecla de tabulación. ¿Puedes decirme dónde estoy actualmente, si estoy presionando la tecla de tabulación? Presiono la tecla de tabulación nuevamente. No lo sabemos, ¿verdad? No hay interacción visual. Entonces, si quiero saber, si solo estoy usando el teclado y quiero ir a iniciar sesión, como, presionar enter, solo por mi deseo o simplemente contar, y luego, bien, he presionado tantas teclas de tabulación. Tal vez esté en el botón correcto y así sucesivamente. No. Pero lamentablemente, este es un comportamiento muy común que vemos en todos los sitios web.

El culpable es un estilo muy simple. Cuando nos enfocamos en algo, sé que debería estar enfocado en un botón. Así que vayamos a un botón y digamos enfoque. Y vemos que hay un estilo. Esta única línea de código es la culpable. Y si vamos y revisamos en nuestras bases de código, tal vez en muchas bases de código busquemos y encontraremos esto, es un pecado.

Debería considerarse un pecado. Pero de todos modos, si lo quito, ahora, nuevamente, si presiono la tecla de tabulación, tal vez no se vea correctamente, pero hay un contorno azul en él. Entonces, hay un contorno predeterminado del navegador que se muestra en el botón. Pero aún así te brinda una retroalimentación de dónde estoy actualmente, ¿verdad, o en todas partes?

Ahora, la mayoría de las veces, los diseñadores piensan que son feos. Así que los contornos feos son una noción muy común en nuestro desarrollo web. Pero podemos cambiarlo. No tiene que ser el comportamiento del navegador. Podemos usar algún estilo relacionado con nuestro tema, nuestro diseño sistema, y podemos mejorarlo un poco. Por ejemplo, en lugar de decir `outline: none`, puedo hacer algo. Puedo agregar un poco de desplazamiento, un poco de color, y de repente se verá un poco mejor y se corresponderá con la paleta de colores que tengo.

Entonces, lo segundo, cuando tenemos botones como estos, que solo tienen un icono, no tenemos ningún texto. Tenemos un icono y queremos hacer algunas interacciones. Ahora, nuevamente, puedo verlo. Puedo hacer clic en él. OK, funciona. Lo sé. OK, tal vez estoy favoreciendo algo. Pero muchas veces usamos HTML no semántico para esto. Tal vez tenemos un SVG o una imagen o un icono y seguimos adelante y le agregamos un onClick. Cuando hacemos eso, estas cosas no son accesibles para los usuarios de teclado. Porque, dado que no son semánticos, no obtienen accesibilidad mediante el teclado de forma predeterminada. Entonces, ¿qué deberíamos usar en su lugar? Deberíamos usar un botón. Eso lo veremos en un momento. Pero me gustaría decir una cosa aquí, que hay algunas veces en las que estamos creando algo que no es nativo, tal vez HTML no tiene un elemento nativo para eso. Un escenario muy raro pero puede suceder. En esos casos, necesitamos agregar un código adicional para que sea interactivo. Como el índice de pestaña, le asignamos un rol adecuado. Y además de agregar solo onClick, también necesitamos agregar key down. Para que los usuarios que usan el teclado también puedan realizar la acción.

Pero no lo hagas solo por un botón o algo así. Si tenemos un elemento HTML nativo, vamos a usar HTML semántico. Por lo tanto, vamos a usar el botón. Entonces, una vez que usemos un botón, seguirá funcionando así, ¿verdad? Entonces, aquí también es un botón. Y no lo he quitado. De todos modos, sí.

Entonces aquí puedo presionar y puedo presionar y funciona. Ahora hay dos problemas más con esto. Dado que solo es un botón con icono, ¿cómo sabe un usuario de lector de pantalla qué es este botón? No conocen su nombre. Entonces podemos proporcionarle algún texto. Podemos usar etiquetas ARIA para eso. Pero luego se ha encontrado que las etiquetas ARIA también tienen problemas cuando estamos utilizando la internacionalización y cosas así. Entonces, en su lugar, podemos crear un componente oculto visualmente y podemos aplicarle estilos. Esto es estilo. Lo que hace es sacar el texto de la vista. Entonces no lo verías visualmente, pero está ahí en el DOM. Entonces, cuando se usa el lector de pantalla, se pronuncia este texto. Entonces puedo decir, ok, coloca un texto oculto visualmente aquí y dale un nombre. Entonces este nombre es favorito.

Lo otro es que esto también tiene un tipo de estado. Tiene dos estados. O lo he presionado o no lo he presionado. Entonces, o es un favorito o no es un favorito. Pero nuevamente, un usuario de lector de pantalla solo escucharía tal vez botón favorito. ¿Cómo sabrían si es favorito o no? Entonces, si tenemos este tipo de comportamiento de alternancia, podemos usar algo llamado aria-pressed. Y una vez que lo hacemos, lo que hace, cuando voy y uso el lector de pantalla aquí... VoiceOver en Chrome, favorito, nombre del botón de alternancia, DevTool, seleccionado. Entonces, una vez que lo selecciono, dice seleccionado. Y de alguna manera, cuando abro el VoiceOver, los estilos no se aplican. Pero si cierro, verás que ya está seleccionado.

Sí. Así que dice que está seleccionado cuando lo has seleccionado y pretendías que estuviera seleccionado. A continuación está el enlace. Para el enlace, ocurren cosas similares. Si estamos utilizando una imagen o algo así, debemos proporcionar algún texto alternativo o algún texto para ello. De esta manera, los usuarios de lectores de pantalla también entenderán qué hace ese enlace.

Aparte de eso, una cosa importante de la que quiero hablar es que a veces en los sistemas de diseño, decimos: `bueno, este enlace parece un botón`. Y luego salimos e implementamos usando un elemento de botón. Y decimos window.location o usamos un hook como useNavigate o algo así. Lo que hace es que, okay, esto te llevará a esa URL. Pero lo que no entendemos es que las etiquetas de anclaje tienen un propósito. Nos llevan a algún lugar. Por lo tanto, también tienen un comportamiento al que estamos acostumbrados. Por ejemplo, si paso el cursor sobre un enlace, se muestra la URL. Sabemos cuál es la URL real, a pesar del texto que haya. Además, cuando hago clic derecho en él, obtengo un comportamiento adicional. Puedo abrirlo en una nueva pestaña y cosas así, o puedo usar clic con control y se abre. Pero si usamos un botón y lo usamos como un enlace, entonces esas capacidades no están presentes. Por lo tanto, eliminamos estas capacidades de interacción adicionales del usuario. Siempre debemos tener en cuenta qué elemento estamos utilizando. Nuevamente, hay más matices sobre cuándo debemos usar un botón y cuándo debemos usar un enlace. Pero una de las cosas principales es que si tenemos alguna acción que realizar, debería haber un botón. Y si tenemos que navegar a algún lugar, como llevar al usuario desde otra parte de la página o a una URL diferente, entonces un enlace sería más apropiado allí. El siguiente escenario son los formularios. Los formularios, nuevamente, son un componente muy importante de nuestra web. En todas partes, si tienes que hacer una transacción, si tienes que completar algún formulario, tienes que iniciar sesión, tienes que registrarte, debes completar alguna información en los formularios. Por lo tanto, los formularios son algo con lo que interactuamos casi a diario. Y deben ser accesibles. Un error muy común, si avanzamos y revisamos el informe webm-1million, lo que hace es auditar las 1 millón de páginas web más importantes del mundo y enumera los errores. Este es uno de los errores más comunes en los que las etiquetas de entrada no tienen etiquetas adecuadas.

Ya sea que falten las etiquetas o tal vez no estén conectadas correctamente, y por lo tanto faltan. Entonces, nuevamente, casi la mitad de las páginas web tienen este error. Así que también necesitamos hacer mucho aquí. Aquí, en lugar de usar solo un span o div para etiquetar, o simplemente omitirlo, deberíamos usar etiquetas adecuadas. Usamos una etiqueta y le agregamos el atributo 'for', o si estamos usando React, HTML 'for', y le damos el ID del elemento. Y así, la etiqueta se conecta. De alguna manera, esto es algo muy importante que debemos hacer.

Otra cosa es, supongamos que este es un formulario y lo hemos etiquetado correctamente. ¿Qué leerá? Nombre, texto, apellido, texto, contraseña, campo de contraseña, y así sucesivamente. A veces tenemos información adicional, información de validación para algunos de estos campos de entrada. Por ejemplo, para la contraseña, podría ser muy complicado. Y agregas una pista larga que dice, okay, caracteres mínimos, deben tener guión bajo y bla, bla, muchas cosas. Ahora, cuando usamos un lector de pantalla, nuevamente, solo lee la etiqueta y el campo de entrada. Como lo que deberías sentir. Pero esta pista no se leerá automáticamente para nuestros usuarios de lectores de pantalla. Por lo tanto, se perderían información importante que tenemos. Para eso, podemos agregar aria-described-by y decir que esta entrada está descrita por este SPAN o DIV, que contiene esa información adicional.

Ahora, los dioses de la demostración estaban enojados conmigo hoy. Entonces, en Chrome, todas mis cosas de accesibilidad dejaron de funcionar, pero aún funciona en Safari. Así que voy a mostrarte el ejemplo del lector de pantalla en Safari. VoiceOver en Safari. Nombre. Último correo electrónico. Contraseña. Contraseña. Requerido, campo de texto seguro con menú de autocompletar. Mínimo ocho caracteres. Leerá toda la información de validación que tenemos para que el usuario sepa exactamente, okay, esto es lo que debo completar. Todas estas otras cosas debo seguirlas si quiero pasar por eso. Ahora, lo siguiente es la información dinámica.

Esto también puede formar parte de un formulario. Pero lo he separado porque también podemos tener información dinámica, alertas, mensajes y demás, aparte de los forms. A veces podemos tener información importante que queremos transmitir a nuestro usuario. Por ejemplo, supongamos que se produce un error. Si podemos ver el error o el mensaje, sabemos qué hacer a continuación. Pero, ¿recibe esta información el usuario que utiliza un lector de pantalla? ¿Cómo obtendrán esta información? Para eso, necesitamos tener algo llamado regiones en vivo. Entonces, esas regiones, una regla es que cuando el DOM se pinta, eso ya debería estar allí. No se debe crear el elemento cuando llegue el mensaje. El elemento ya debería estar allí. Y lo que hacemos es que cuando llega el mensaje, colocamos ese mensaje dentro de esa región en vivo. Por ejemplo, aquí, lo que podemos hacer es que este es un div donde estoy colocando mis mensajes de validation. Puedo decir que ARIA life polite y el rol de estado. Hay diferentes valores para ello. También hay assertive y demás. Pero estoy usando polite porque esto significa que, OK, este mensaje no es tan urgente. Entonces, lo que haces es que si el lector de pantalla ya está leyendo algo, déjalo terminar y luego anuncia este mensaje. Entonces, cómo funciona ahora es que nuevamente quería hacer algo mal. Botón de registro, error al enviar el formulario. Así que continúa y obtiene el mensaje para que el usuario sepa que hay algo mal. Hay más capas en esto, pero debido al tiempo no revisaré todo. Pero una cosa más importante que quiero decir aquí es que esto es algo de lo que algún mensaje viene del servidor o algo así y se lo mostramos al usuario. Ahora hay otro patrón muy importante que estamos siguiendo en la web. Lo que hacemos es que cuando algo sale mal en el formulario, simplemente lo mostramos en rojo. Usamos un color, lo ponemos en rojo y este es el error. Ahora hay diferentes tipos de discapacidades. Hay una condición llamada daltonismo y hay diferentes tipos de daltonismo. Uno se llama acromatopsia. Entonces podría haber un usuario que solo vea en blanco y negro y gris. Y si usas solo el color para mostrar alguna información, nuevamente el usuario no podrá entender, si no saben dónde está el error, ¿cómo lo solucionarán? Se enfrentarán al problema.

Entonces no deberíamos usar solo el color, deberíamos usar errores específicos y mostrarlos , okay, este es el campo donde está el error y cuál es el error, y así sucesivamente. Okay.

Entonces el último escenario son los modelos. Entonces, sobre diálogos y popovers, creo que Hiday hizo una charla muy buena sobre eso ayer. Así que no entraré en eso, pero quiero mostrar algo sobre los modelos. Porque este es uno de los componentes más complejos que existen, así que tenemos algo llamado, aquí me gustaría hablar sobre algo llamado guía de prácticas de autoría por área, es de W3C.

Esto es algo que realmente me gusta porque siempre que estamos creando algo, si estamos confundidos acerca de cuál debería ser la interacción, como cuál debería ser el flujo diferente, ¿verdad? Entonces lo que podemos hacer es ir a patterns y buscar el patrón que estamos intentando. Por ejemplo, aquí un diálogo, podemos ir y ver cuáles son las interacciones previstas que el usuario puede realizar. Estas son las cosas de las que debemos ocuparnos cuando pensamos en la accessibility. Por ejemplo, dará una lista de todas las interacciones de teclado y qué debería suceder como cuando el diálogo se abre, el enfoque debería ir al primer elemento enfoque automático dentro y qué debería hacer la tecla Tab, la tecla Mayús + Tab y todo eso. Escape debería cerrar el diálogo y así sucesivamente. Así que es algo muy interesante para leer, pero en cuanto a eso, anteriormente teníamos que escribirlo todo desde cero.

Teníamos que escribir código JavaScript para crear este elemento de diálogo, pero ahora HTML también tiene un elemento de diálogo, un elemento nativo adjunto, lo cual es genial. Así que podemos usar eso. Y hace casi todas las cosas. Por ejemplo, presiono Enter, el enfoque está adentro, estamos adentro. Presiono Escape, se cierra, el enfoque vuelve al lugar de donde se lo llevó. Pero aún así, el enfoque no está atrapado dentro de este diálogo. Entonces, cuando presiono Tab nuevamente, todavía me muevo a diferentes partes. No hay atrapamiento de enfoque. Entonces, esto podría ser un problema si tenemos un modelo que no tiene nada más además de él. Y si el enfoque se va detrás de la pantalla, eso no es una buena user experience. Entonces, en cambio, lo que debería suceder es que presiono Tab y el enfoque debería estar dentro del modelo. Porque este es el único lugar donde un usuario puede interactuar en este momento si está abierto. Para eso, aún podemos usar algo de código JavaScript para mejorarlo. Lo que podemos hacer es usar un controlador de eventos de teclado y allí podemos tener cierta lógica para... Lo que podemos hacer es obtener elementos enfoque del modelo. Podemos decir, hey, dame todos los elementos enfoque del modelo, que básicamente es solo seleccionar la consulta en el modelo de referencia y obtener botones, anclas, entradas, cualquier elemento interactivo que tengamos dentro de él. Y nos enfocamos en el primer y último elemento activo, y luego podemos poner la lógica de qué hacer cuando tenemos Tab y la tecla Mayús, y cuando estamos en el último... Cuando... Sí.

Entonces, esta es la lógica. Cuando presionamos esto y estamos navegando por pestañas, cuando estamos en el último elemento, cuando volvemos a navegar por pestañas, va al primer elemento interactivo, y cuando hacemos shift + tab, va al último elemento interactivo.

Ahora, nuevamente, casi se me acaba el tiempo, pero... Sí. Entonces, esto no es algo, nuevamente, que necesitemos reinventar. Podríamos tener diferentes bibliotecas de componentes en frameworks que podemos usar. Para React, hay algo llamado React ARIA, que proporciona muchos ganchos, y son bastante buenos. Incluso el uso de diálogos es bastante bueno. Así que adelante y compruébalo.

Entonces, para resumir, siempre que estemos creando algo, debemos probar todas las diferentes formas en que los usuarios interactúan con la web. Nunca debemos quitar el contorno al enfocar. Use HTML semántico siempre que sea posible. Siempre debe haber una descripción de texto para elementos gráficos interactivos. Los elementos dinámicos y los mensajes deben ser anunciados. Y siempre piense desde la perspectiva de la accesibilidad. Tengo algunos enlaces para leer más. Puede escanear el código QR o ir a tinyurl.com diagonal A11y-interactions. Gracias. Gracias por abogar por la accesibilidad. Es un tema importante y, sí, hay muchas cosas que la gente hace y, sí, la gente no piensa en ello lo suficiente. Así que muchas gracias, Anuradha, por compartir.

Una pregunta que hace un visitante anónimo, que se hace con frecuencia. ¿Cómo convencer a la alta dirección para obtener el tiempo y el presupuesto? Sí. Esa es una pregunta muy común también. Y bastante difícil, ya sabes. Es muy difícil hablar con la alta dirección. Pero lo que encuentro que funciona es una cosa muy importante: crear un escenario para la accessibility. Como sea que sea el producto en el que estemos trabajando o los servicios en los que estemos trabajando, encontramos que, está bien, este flujo no es lo suficientemente accesible. Y es bueno encontrar una parte crítica. Porque así es como nos acercamos. Si algo no es accesible, no podemos avanzar y hacerlo todo accesible en un día, ¿verdad? Así que primero averigüemos la parte crítica. Aquí es donde el usuario hace la mayor parte. Por ejemplo, si es e-commerce, ¿qué hace el usuario? Agregar al carrito y el flujo de compra es la parte principal, ¿verdad? De eso se trata todo el negocio. Así que toma una parte accesible de eso, hazla accesible, preséntala a la dirección y muéstrales que, hey, esto es algo tan importante de hacer en nuestro negocio. Nuestro negocio depende de esto. Y si nuestros usuarios no pueden hacerlo, entonces estamos perdiendo usuarios, ¿verdad? Como los usuarios no estarían utilizando nuestros sitios web y aplicaciones. Esperemos que la dirección lo entienda. Y también podemos mostrar que esto no es tan difícil. No necesitamos 100 años para hacer algo accesible, ¿verdad? Podemos hacerlo en etapas. No tiene que ser de cero a cien por ciento. Puedes ir del 5 por ciento, 10 por ciento y simplemente hacerlo. Sí. Y si nada funciona, entonces recurre a las leyes. Hay leyes en todos los países para la accessibility. Por favor, cita las leyes. Involucra la ley. Sí. Sí. Y depende de la empresa en la que estés y del presupuesto que tengas, por supuesto. Pero para mí, si es solo parte de los requisitos, no puedes fusionar nada si no todos pueden usarlo. Así que eso es algo bueno.

Y eso es algo bueno de trabajar en una empresa grande. Sí. Sí. Quiero decir, definitivamente podemos utilizar varias herramientas para las pruebas automatizadas. Por ejemplo, algunas herramientas están en los navegadores. Puedes usar Lighthouse. Puedes usar AXE DevTools. De hecho, cualquier cosa relacionada con AXE es bastante buena, porque incluso Lighthouse está impulsado por AXE. Luego tenemos Microsoft Insights for web, que puedes instalar como extensión. También está AXE-Core. Puedes instalar AXE-Core y usarlo en el pipeline de CI-CD. Así que realiza pruebas para ello. También hay algunos linters que podemos utilizar. Pero hay que tener en cuenta que todas estas pruebas automatizadas no detectarán el 100% de la accessibility. Por ejemplo, los ejemplos que mencioné, como Outline y Search, es posible que no se detecten en las pruebas automatizadas. También es necesario realizar pruebas manuales y pruebas de usuario. Sí, utiliza pruebas automatizadas, ya que realmente nos ayudan a abordar los problemas más evidentes, pero no podemos depender únicamente de las pruebas automatizadas para hacerlo más accesible.

Sí, siempre siento que la mayoría de los problemas de accesibilidad se pueden abordar simplemente utilizando la plataforma, ¿verdad? Por ejemplo, no escribir tu propio botón, simplemente usar una etiqueta de botón. Pero si estás utilizando alguna biblioteca de componentes, asegúrate de que cumpla con los estándares. Que cumpla con WCAG y que digan que es... y pruébalo, incluso si dicen que es accesible, no lo creas. Adelante y pruébalo, por favor.

Siguiente pregunta de un anónimo. ¿Qué lector de pantalla recomendarías para el desarrollo? Te vi usando VoiceOver, pero para usuarios de Windows. Depende de la plataforma que estés utilizando. Los usuarios utilizan diferentes tipos de lectores de pantalla según el sistema operativo o el dispositivo que estén utilizando. Por ejemplo, para Mac, se utiliza VoiceOver como estándar. Para Windows, también tenemos algo similar a VoiceOver incorporado en Windows, pero también utilizamos NVDA. Creo que NVDA es gratuito, luego está JAWS. Linux tiene algo llamado Orca. Android tiene TalkBack, algo así. Sí, cada dispositivo tiene uno. Pero los lectores de pantalla, necesitas leer un poco antes de comenzar a usarlo porque los usuarios también tienen una combinación. Los lectores de pantalla no son como empezar a usarlo en cualquier navegador. Tienen una combinación. Como, estamos usando este dispositivo, estamos usando este lector de pantalla y luego tenemos este navegador específico. Funcionan mejor. Por ejemplo, en realidad se dice que VoiceOver funciona mejor con Safari, pero sí, lo uso con Chrome. Sí, está bien. De acuerdo, gracias.

Pregunta de Veronica. ¿Hay algunas desventajas de usar Border en Focus para el estilo en lugar de Outline? Bueno, solo usando los estilos de borde. Si hay alguna, aún no lo sé, tendré que buscar más. Pero lo que siento es que si lo estás mostrando, el usuario aún puede verlo. Obtienen esa retroalimentación visual. Debería haber una retroalimentación visual. Si está ahí, creo que está bien.

Pero nuevamente, no te quedes solo con mi palabra. Aún no sé si hay alguna desventaja. Bueno, creo que la mayor desventaja es que si usas el estilo de borde o cambias el ancho del borde, porque generalmente es más grande. El diseño. Sí, el diseño se arruinará porque se hará más grande.

Sí. Tenemos tiempo, sí. Dijiste que se deben evitar las etiquetas ARIA debido a problemas de internacionalización. Si traducimos las etiquetas, ¿tienes preferencia por una etiqueta o elementos ocultos para lectores de pantalla? ¿Etiqueta o elemento oculto para lectores de pantalla? Elemento oculto para lectores de pantalla. Entonces, visualmente. Ah, visualmente. No, quiero decir, si hay un formulario, debe tener una etiqueta. Incluso si lo estás ocultando visualmente, aún debe tener una etiqueta. Porque si solo usamos cualquier otro texto, los formularios no se leerían. Si estás navegando a través de los formularios, las etiquetas están vinculadas a nuestros campos de formulario, por lo que se leerán. Pero hay otra forma en que podemos usar ARIA etiquetado, como algunas personas lo usan, pero creo que simplemente use etiquetas. Sí. Siempre me gusta si está etiquetado porque puedes hacer clic en el texto para enfocar la entrada. Exactamente. Proporciona mucho. Haces clic en la etiqueta y sabes que estás en este campo de entrada. Es bastante genial.

Esta es una buena pregunta. Hay algunas formas. Como hay algunas herramientas que podemos usar, pero también hay una en Chrome DevTools. En Chrome DevTools, si haces creo que comando shift P o algo así y escribes emular, obtienes diferentes tipos de ceguera que puedes emular. También puedes emular diferentes esquemas de color. Puedes ir al modo oscuro, modo claro y puedes emular todas estas cegueras. Esta es la forma si estás usando Chrome DevTools, o puedes instalar algunas extensiones. O hay algunos programas de eventos que la gente usa para emular esto.

Si no estás utilizando la web, sino una foto o algo así. Viene en capas en muchos componentes. Genial.

Siguiente pregunta, de Metin Parzinski. ¿Quién es él? Nombre extraño. Siempre uso el atributo de título para botones de iconos. ¿Eso también está permitido? En realidad, el título también se hereda. Entonces, si avanzas y ves el accessibility tree, verás que incluso para elementos interactivos estás usando el título. Leen ese título y tratan de usarlo si no proporciona ningún texto. Pero no sé cómo funciona si usamos el título cuando estamos traduciendo el sitio web. Así que todavía no lo sé. Entonces, ¿qué pasa si estoy traduciendo a algún idioma diferente? No sé si el título se traduce o no. ¿Si estás utilizando la traducción automática de Google automation? Sí. Eso no lo sé, pero entonces simplemente no deberías traducirlo. Entonces tenemos que probarlo.

Pero lo que me gusta del atributo de título es que también para las personas que pueden leer, eso pueden pasar el cursor sobre él y obtener ese texto. No, eso es definitivamente bueno. Realmente me encanta mucho, porque no conoces todos los iconos. No sabes. Para mí, siempre estoy perdido. ¿Qué es esto? Necesito saberlo. Y eso definitivamente es algo útil. Muy bien. Y se acabó el tiempo. ¡De acuerdo! Así que eso es todo el tiempo que tenemos para Anuradha.