What the First Rule of ARIA Really Means

Muy bien, hablemos sobre lo que realmente significa la primera regla de ARIA. Y para aquellos que no lo saben, la primera regla de ARIA es no usar ARIA. No uses ARIA. No lo hagas. Esa es la primera regla. Pero, ¿qué es ARIA? El acrónimo en sí significa Accessible Rich Internet Applications, y este es un conjunto de estándares web para la funcionalidad proporcionada a la tecnología asistiva, especialmente cuando estás construyendo contenido dinámico y controles avanzados de interfaz de usuario.

Cuando hablo de tecnologías asistivas, me refiero a cualquier cosa que se use para ayudar a las personas con discapacidades. Así que si estás usando gafas para ver ahora mismo, estás usando tecnología asistiva. Si alguna vez has usado esa rampa desde la acera hasta la carretera en lugar de mover torpemente tu carrito desde la acera hasta la carretera, eso es un rebaje de acera. Eso es tecnología asistiva. Esta no es de ninguna manera una lista exhaustiva, pero en el contexto de esta charla, cuando hablo sobre interactuar con sitios web, me refiero a software y hardware utilizados para interactuar con sitios web, y eso incluye cosas como lectores de pantalla, software de comunicación, interruptores, y teclados.

Antes de continuar, debo dar una advertencia. La accesibilidad nunca es blanco y negro. A menudo es muy frustrantemente gris. Lo que puede hacer algo más accesible para un grupo de personas puede hacerlo más inaccesible para otro grupo de personas, y sé por experiencia que esto frustra especialmente a los desarrolladores, porque queremos una mejor práctica, algo que funcione al menos el 90% del tiempo, pero eso no existe. Así que conseguí un par de auditores de accesibilidad para verificar toda esta información antes de escribir el blog que eventualmente se convirtió en esta charla, pero si digo algo y tu experiencia vivida te dice que esto haría un sitio web más inaccesible para ti, por favor pon una pregunta en el QA o ven y habla conmigo al respecto, y por favor, saluda en cualquier momento. Obtendrás una pegatina.

Pero esa frustración, esa área gris, es parte de la razón por la que comencé a escribir este blog, porque cuando escuché que la primera regla de ARIA es no usar ARIA, supe lo que significaba. ARIA es un tema enorme con muchas reglas. Hay muchas pequeñas reglas que a veces se contradicen entre sí. Es muy fácil ser atrapado por ARIA. Cuando comencé a dar retroalimentación sobre los portafolios o proyectos paralelos de las personas, abro DevTools, ejecuto un verificador de accesibilidad, navego a través de él con un teclado, uso un lector de pantalla, porque sé que la mayoría de las personas que están pidiendo retroalimentación no van a dar ese tipo de retroalimentación, y yo diría, oye, una etiqueta ARIA sería genial aquí. Lo haría más accesible. Y los desarrolladores me mirarían y dirían, pensé que nunca se suponía que debía usar ARIA.

Así que alrededor de la quinta o sexta vez que escuché a uno de mis amigos decir que la primera regla de ARIA es no usar ARIA, pensé, oye, los desarrolladores piensan que nunca se supone que deben usar ARIA o usar en absoluto. Y él me miró a los ojos y dijo, bien. Porque cuando hablas con auditores de accesibilidad sobre ARIA, te contarán sobre el último desastre que fue causado por alguien que no entendía ARIA en absoluto y simplemente colocó ARIA en la página. Así que cuando escuchas que la primera regla de ARIA es no usar ARIA, eso significa que probablemente hay un elemento HTML para eso, y ningún ARIA es mejor que un mal ARIA. Vamos a profundizar en el primero. Ya estás usando ARIA. Al usar HTML. Y sí, JSX es un lenguaje de plantillas, estás usando HTML bajo el capó, así que todos están usando ARIA. No te preocupes por eso. Porque las reglas de ARIA son la semántica en HTML semántico. Comunican información a las computadoras y a las tecnologías asistivas.

Así que incluso cuando estás usando un elemento como un div que tiene un rol genérico o usando rol presentación o rol ninguno, estás comunicando información a las computadoras y tecnologías asistivas. Al igual que cuando miras un esquema en un documento impreso y ves una lista o el comienzo de un párrafo con sangría, no lees ese espacio en blanco en voz alta y no dices espacio, espacio o tabulador, tabulador cuando estás leyendo esa información, pero está ahí comunicando estructura a la página, que es exactamente para lo que las computadoras y las tecnologías asistivas piensan que un div está ahí. Y la forma en que usas HTML semántico comunica aún más información. Así que si usas un elemento de dirección dentro de un elemento de pie de página, eso le dice a las computadoras y tecnologías asistivas que esa es la información de contacto para esa página web. Si usas una dirección fuera de un elemento de pie de página, es solo una dirección. Antes de llegar a la siguiente parte, tengo que explicar el nombre accesible. Escucharás nombre accesible o nombre. Y esto proviene del árbol de accesibilidad. Así que cuando le das a un navegador una página web, calcula un árbol de accesibilidad. Y parte de ese árbol de accesibilidad es una propiedad de nombre. La propiedad de nombre proviene de muchas cosas, dependiendo de lo que necesite un nombre y lo que hayas usado. Así que el mejor ejemplo son las etiquetas porque todos estamos asociando etiquetas con nuestros inputs cuando los usamos, así es como obtienen su nombre.

Las leyendas de tablas, el texto alternativo de imágenes, el elemento legend, un elemento title de SPG, ARIA label, ARIA label by y el contenido de texto también se utilizan para calcular nombres. Así que cuando usas un elemento button, el nombre que se calcula es del contenido de texto. Y cuando usas un elemento button, obtienes muchas cosas directamente. Es enfocable. Hay un estilo de contorno de enfoque. Se activa al hacer clic, con la barra espaciadora y enter.

Y la activación desencadena un evento de envío si no pones un tipo en el elemento button o pones type equals submit. Y el role button y el nombre se exponen a través del árbol de accesibilidad. Y el nombre del botón se anuncia. Cuando usas div role equals button, obtienes exactamente dos cosas directamente. El role button y un nombre, si tienes contenido de texto allí, se exponen al árbol de accesibilidad.

Y el nombre del botón se anuncia. Para hacer que estas dos cosas sean equivalentes, tienes que programar eventos de clic, barra espaciadora y enter, agregar tab index equals zero para hacerlo enfocable, programar un evento de envío completo si era un botón de envío, y agregar un estilo de contorno de enfoque. Lo que nos lleva a la segunda parte de la primera regla de ARIA. Ningún ARIA es mejor que un mal ARIA.

Cuando optas por div role equals button, estás dejando de lado un montón de cosas que te serían útiles, que se supone que debes programar de nuevo. Y la gente no se da cuenta de eso. Web accessibility in mind realiza verificaciones de accesibilidad en los principales 1 millón de sitios web cada año. Tienen muchos datos sobre el tipo de errores de accesibilidad que podemos ver. Y han encontrado que cuantas más atributos ARIA estaban presentes en la página de los desarrolladores simplemente colocándolos significaba que habría más errores de accesibilidad en esa página.

Así que no llenes tu código con atributos inútiles y elementos inválidos. Es horrible de mantener y, uf, si ejecutas un lector de pantalla en él, es horrible de escuchar anunciado. Porque las reglas de ARIA pueden requerir atributos específicos y elementos hijos. Role equals button requiere un controlador on click y múltiples controladores on key down. Creo que he visto un div role equals button con un controlador on key down alguna vez. La gente no se da cuenta de que están creando elementos inválidos simplemente colocando ARIA en la página.

Role equals check box requiere ARIA checked y mantener el valor de ARIA checked actualizado. Porque el lector de pantalla anunciará check box, nombre, marcado o desmarcado. Así que si anuncia el estado incorrecto, tu usuario de lector de pantalla piensa que tiene un check box marcado que en realidad está desmarcado. Las reglas de ARIA pueden prohibir atributos específicos y elementos hijos. No puedes usar ARIA checked en un botón. No puedes usar ARIA pressed en un check box. Si estás pasando el valor mixed a ARIA checked, es mejor que esté en un check box porque no puede estar en un radio o un switch.

Un hijo de un elemento de lista desordenada tiene que ser un elemento de lista, un elemento script o una etiqueta template. Cualquier otra cosa es inválida. Y esto es para la persona o más en esta sala que sé que ha creado un elemento interactivo anidado donde un botón tiene un hijo como un select o un select tiene un hijo como un botón, un hijo de un botón no puede ser interactivo. Eso es inválido. Y si usas un lector de pantalla con él, solo obtendrás galimatías. Así que al comienzo de esta charla, dije que quiero que la gente use ARIA. Quiero que aprendan sobre ARIA. Y he pasado casi la mitad de la charla hablando sobre cuándo no se supone que debes usarlo. Así que hablemos de cuándo deberías usar ARIA. Si no te llevas nada de esta charla más que los roles de referencia, estaré muy feliz. Por favor, usa roles de referencia en tu página. Hay ocho de ellos.

Solo te estoy pidiendo que aprendas ocho elementos y ocho roles. Afortunadamente, algunas de las etiquetas coinciden con los roles. Así que, como search es search y nav es navigation. No sé por qué header es banner y footer es content info. Pero {{^}}solo te estoy pidiendo que aprendas ocho de estos. En un sitio web típico, usualmente tenemos un header, una parte principal de la página y un footer.

Esta imagen proviene de mi masterclass de diseño para no diseñadores. Estoy como, oye, no quieres aprender frontend. No quieres aprender diseño. Lo entiendo. Aquí, ya tienes tu página seccionada con tres elementos que siempre deberías estar usando. Estos elementos no pueden ser duplicados y no pueden ser hijos uno del otro. Si haces un footer hijo de main, entonces simplemente pierde su rol. Podrías también estar usando un div.

Pero los otros roles de referencia pueden ser duplicados. Puedes tener múltiples elementos nav en tu página. Pero cuando haces eso, quieres darles un nombre para que un usuario de lector de pantalla escuche nav, main, y sepan que esto es para guiarlos por tus páginas en lugar de otra barra de navegación. Porque los roles de referencia son esperados por las tecnologías asistivas para la navegación.

Este video soy yo usando VoiceOver para navegar por mi sitio de portafolio. Accedo al rotor. Selecciono roles de referencia. He dado nombres a todas las secciones en mi página. Cuando un usuario de lector de pantalla está usando esto, básicamente obtienen un enlace de salto y no he programado nada. Todo esto es de fábrica, VoiceOver y HTML. Realmente, si ya has leído el header de una página, no quieres leerlo cada vez que vas a esa página. Tampoco lo quiere un usuario de lector de pantalla. Quieren poder saltar entre todas estas regiones de referencia y encontrar el contenido principal de tu página y luego las cosas que quieren dentro de ese cuerpo principal.

Ahora vamos a hablar sobre aria-label, aria-labelby y aria-describedby, porque no puedo recordar si usé aria-label o aria-labelby para nombrar todas mis diferentes secciones para que un usuario de lector de pantalla supiera, oh, quiero leer sobre su escritura, quiero leer sobre su oratoria, lo que sea. Porque aria-label y aria-labelby son muy similares. Ambos calculan un nombre. Pero aria-label calcula el nombre a partir de la cadena que le pasas. Aria-labelby toma un ID y calcula el nombre a partir del elemento que coincide con ese ID.

Así que si tienes, no sé, un input, y piensas, sé que se supone que debo asociarlo con una etiqueta, pero hay un encabezado justo encima que dice exactamente la misma información y no quiero duplicarla, ese es un gran momento para usar aria-labelby. aria-describedby también toma un ID pero calcula una descripción a partir del elemento que coincide con ese ID. Un nombre es corto y dulce. Botón siguiente, botón ir a esto, lo que sea. Una descripción es para cuando se requiere más información.

Así que si alguna vez has puesto un cuadro de información sobre un input que dice, por ejemplo, más información sobre cómo usar este control, este es un momento perfecto para usar aria-describedby. Entonces un usuario de lector de pantalla sabrá que esa información está asociada con ese control. Cuando estás usando íconos e imágenes que transmiten información en imágenes estáticas, usamos texto alternativo. Para SVGs, una de las formas de agregar texto descriptivo que un usuario de lector de pantalla escucharía anunciado es role equals image y aria-label. Para íconos e imágenes que no transmiten información, usas alt equals nothing para imágenes estáticas y aria-hidden equals true para SVGs. No quieres que todo eso se anuncie repetidamente a los usuarios de lectores de pantalla cuando no necesitan saberlo, al igual que un div.

Los botones y enlaces deben tener contenido de texto. Así es como se calcula su nombre. Así es como están destinados a ser utilizados. Pero no moriré en esta colina. He aceptado que el diseño es que usamos el caret derecho para ir a la siguiente página con un SVG. Lo entiendo. Así que cuando estás usando botones con un SVG, en la imagen, quieres usar aria-hidden igual a true, y en el botón, quieres poner un aria-label, que es lo que estás tratando de comunicar con ese pequeño caret derecho, que probablemente es siguiente. Cuando estás haciendo enlaces con contenido de imagen, los enlaces deben tener contenido. Así que vas a poner un aria-label en la imagen, porque un texto alternativo es más como una descripción que un nombre. Hablamos de que los nombres son cortos y dulces. Usas aria cuando HTML no es suficiente. Esto no es tan común como los desarrolladores piensan que es. El select es feo, no es esto. Es 2026, los selects estilizados ahora están en Safari. No uses aria para selects. Esto viene de alguien que ha tenido que construir una vista de árbol con funcionalidad de lector de pantalla y teclado. Así que como un navegador de archivos, pero esto era para nodos DOM.

Levanta la mano si alguna vez has usado treewalker o node iterator. Esta es la segunda persona que he conocido que ha usado esas cosas. Estoy muy emocionado. Por favor, ven a hablar conmigo después. El uso más común para esto es tab, tab list y tab panel. Eso es usualmente cuando estás buscando aria en lugar de HTML. Para cosas como esta, hay patrones establecidos que los usuarios de tecnología asistiva esperan. Así que usa esos patrones establecidos. Anunciar adiciones a la página, otro gran momento para usar aria, haz una región en vivo. Cuando un lector de pantalla está enfocado en algo, eso se está anunciando. Si algo se agrega a la página en otro lugar, no van a saber sobre eso. Así que si pones una región en vivo, algo como un chat, notificaciones, temporizadores, entonces ellos eventualmente recibirán esa notificación. Depende del uso del navegador y de cómo han sido implementados.

Pero eventualmente recibirán una notificación de algo en lo que no están enfocados actualmente. Otro gran ejemplo, agrupar elementos interactivos fuera de un formulario. Div rule equals group y un aria label equals algo es efectivamente lo mismo que field set y legend. Si no te gusta el estilo de field set y legend, simplemente sobrescríbelo con CSS. Pero esto es súper útil para cosas como menús, barras de menú y barras de herramientas cuando necesitas decirle a alguien, oye, todo este grupo de botones, no quieres tener cada uno a menos que estés estilizando tu fuente. Entonces adelante y entra en esto y comienza a escuchar lo que hace cada botón. Así que espero que ahora entiendas que aria es un adorno. No es una cobertura completa. Usa reglas de landmark, por favor, por favor, por favor, por favor. Cuando escuches que no uses aria, probablemente hay un elemento HTML para eso y ningún aria es mejor que un mal aria.

Aquí hay un código QR para estas diapositivas y que tiene formas de contactarme así como el blog completo en el que se basó esta charla y más recursos de aprendizaje sobre accesibilidad si esto ha despertado tu interés. Gracias. ¡Woo! Bueno, primero que nada, quería agradecerte por ser tan inclusivo cuando dijiste que no lees espacio, espacio o tab, tab. Así que no tenemos este argumento aquí. Muchas gracias por ser tan inclusivo. Eso es correcto. Muy bien. Primera pregunta. Ah, veo que la gente está poniendo sus nombres. Eso es muy agradable. Mi comentario funcionó. Jens de Wolf está preguntando, Abby, tengo un diálogo que vive en la capa superior. El disparador para el diálogo vive en el main. ¿Puedo o debo tener landmarks dentro de ese diálogo si están presentes visualmente? ¿Es mejor con título incluido o main con contenido de diálogo primario? Así que los landmarks son para la estructura general de tu página. No suelen ser para un solo elemento. Sería como si ese diálogo estuviera en la sección sobre obtener más información sobre tu producto, entonces estaría en la sección about. No necesita ser tan granular. Si eso tiene sentido. Y si no, ven a hablar conmigo más tarde y lo discutiremos. Bueno, supongo que ahora puedes usar simplemente el elemento de diálogo genérico y eso resolvería mucho.

¿Verdad? Sí. Sí. Usar HTML semántico es lo mejor. Desafortunadamente, estoy en el mundo de las vistas. Así que usamos mucho teleport para resolver este tipo de problemas, pero estoy feliz de hablar sobre ello en profundidad después. Investigar junto con Jens.

Muy bien. A continuación, de nuestro querido visitante, Anónimo. ¿Las tecnologías asistivas habilitadas por IA harían obsoleta el área? Así que las tecnologías asistivas habilitadas por IA serían algo idealmente que podría rastrear el HTML y crear su propio árbol de accesibilidad, es lo que creo que esta pregunta está preguntando. Es como preguntar, ¿la IA va a empezar a renderizar cosas en lugar del navegador? Así que cuando entregas una página web a un navegador, crea ese árbol de accesibilidad con toda esa información. Sería más probable que la IA pudiera crear más conexiones y contexto a partir del árbol de accesibilidad que reemplazar el HTML que crea el árbol de accesibilidad.

Sí. ¿O no sé qué es una tecnología asistiva habilitada por IA? Lo que me vino a la mente es la última demostración que dio Apple. Bien. Una persona ciega camina y simplemente apunta su teléfono. Ella lanza dos camisas en la cama y dice, ¿cuál es la roja? Ah, bien. También podrías apuntar tu teléfono a una pantalla. Como, ¿dónde está el botón del menú? Bueno, eso es un poco difícil. Mueve el ratón dos píxeles arriba, dos píxeles a la izquierda. Quizás un poco más difícil que cuál es la camisa roja. Lo es. Lo es. Y podrías apuntar tu teléfono a un sitio web y obtener básicamente la misma cantidad de información que un árbol de accesibilidad. Pero el árbol de accesibilidad se genera a partir del HTML y ARIA. Así que creo que es una capa diferente. Cierto. Y por supuesto, debemos ser conscientes del medio ambiente. Así que usa la IA lo menos posible.

Ben está preguntando, ¿cuál es tu opinión sobre el texto visualmente oculto? No sé cuál es el contexto de esto. Yo oculto texto visualmente. Así que depende. Como si estuviéramos hablando de algo que no crees que una etiqueta ARIA o un ARIA descrito por sea útil y quieres el texto visualmente oculto allí, siempre que esté en el orden correcto del DOM, está totalmente bien. Pero es cuando empiezas a ignorar el orden del DOM y cómo un lector de pantalla recorrerá la página y lo pones en otro lugar y luego no tiene contexto o relación con la cosa a la que realmente está vinculado, que eso comienza a tener problemas. Para cosas como los ejemplos de botones que di, donde deberían tener contenido de texto, así es como obtienen su nombre y los enlaces siempre necesitan contenido, está totalmente bien usar ese contenido de texto visualmente oculto en la página en lugar de una etiqueta ARIA. Y no se trata de recurrir a ARIA primero, que es de lo que se trataba toda la charla. Siempre que los usuarios puedan obtener el texto. Esa es la parte más importante, ¿verdad? Sí.

Muy bien. Siguiente pregunta de Tobias Brenner. ¿Tienes mejores prácticas para la accesibilidad de páginas con muchos gráficos o diagramas? Sí. Es difícil. Es difícil aquí con los gráficos y los diagramas. Hay varios recursos. Creo que tengo un par en ese último enlace en mis diapositivas. Y si no lo tengo, por favor házmelo saber. Pero es muy difícil hasta el punto de que hay un patrocinador completo aquí, creo. Highcharts. Highcharts, sí. Que ha resuelto este problema con una biblioteca de componentes. Es como preguntar si tengo mejores prácticas para toda una biblioteca de componentes. Obviamente estás tratando de dar toda la información que un usuario visual obtendría del gráfico, pero eso significa que tienes que describir relaciones de cosas y líneas y todo ese tipo de cosas. Así que se vuelve complicado.

Debería tener algunos recursos para ello, porque honestamente no tengo suficiente tiempo para cubrir esto en esta sesión de preguntas y respuestas. No, pero creo, Tobias, que deberías echar un vistazo a Highcharts. Recuerdo de su video, su video de demostración, el primer USP que mencionaron es 100% accesible. Así que ese es un buen primer USP. Me sorprendió mucho que eso esté en su video de demostración. No tengo acciones en Highcharts.

Abby, toasts y regiones en vivo. ¿Opinión? La opinión es no molestar al usuario, pero decirle cuando las cosas están sucediendo. Si eres un usuario visual y ves que hay un error, un usuario de lector de pantalla debería también tener esa información. Así que cuando algo se añade a la página, una región en vivo es buena, pero no quieres, como, si tienes un temporizador no necesitas anunciar cada segundo, ¿de verdad? Eso sería como, puedo leer media oración. Temporizador, temporizador, temporizador, temporizador, temporizador. Puedo leer media oración. Temporizador, temporizador, temporizador, temporizador.

Así que recomiendo usar un lector de pantalla tú mismo y descubrir cómo sería la experiencia de tu página si fueras un usuario de lector de pantalla. Mi video me mostraba con la voz apagada y estaba mostrando el texto, porque a diferencia de las personas que típicamente usan lectores de pantalla, tengo más problemas para escuchar y procesar sonido que para leer. Así que no hagas eso. No hagas lo que hice. Pero apaga, si puedes, simplemente bloquea tu pantalla por completo y usa un lector de pantalla para navegar la página y descubrir cómo sería la experiencia de tu propio sitio web si fueras visualmente impedido. Y si nunca has hecho eso antes, confía en mí, es más doloroso de lo que piensas.

Sí. Y te incentivará a optimizar. Hay un desafío que mucha gente propone donde no usas tu ratón por un día. Solo usa el teclado y descubrirás lo molesto que es internet cuando no tienes un ratón. Ay.

Muy bien. A continuación, de Chloe, Abbey, ¿qué herramientas recomendarías para mejorar el uso de ARIA? Creo que esto es como lo que decía Mark Erickson, donde hemos ido en la dirección opuesta diciendo a la gente que no use ARIA hasta el punto de que le tienen miedo y piensan que nunca deberían usarlo o nunca han escuchado eso y lo usan de cualquier manera que deseen.

Recomendaría estudiar ARIA, aprender sobre ello, usarlo y usarlo con un lector de pantalla para entender qué es lo que estás creando cuando usas estos atributos y roles. Sí. Y si, por supuesto, tu empresa tiene el presupuesto, recuerdo la primera vez que vi a una persona con discapacidad venir, como un consultor que usó nuestra aplicación y piensas, oh, esto debería estar bien. Correcto.

Y si ves los problemas que están enfrentando o la velocidad a la que solo pueden avanzar, entonces realmente, como dije, te incentivará a optimizar para ellos. Sí. La única manera de saber si algo es accesible es probar con usuarios con discapacidades y te sorprenderá la velocidad a la que usan un lector de pantalla. Es, ni siquiera puedo escucharlo. Tendrán como el discurso a como x 40 y solo escucharás, y ellos estarán como, está bien.

Sí. De acuerdo. Siguiente pregunta de nuestro amigo, Doug. ¿Hay nuevos requisitos de accesibilidad para páginas web que llegarán en 2027? Sí. Se supone que saldrá el Tres, que sé que implica recalcular completamente las matemáticas de contraste. Y sé que estamos en Europa. Así que el Acta de Accesibilidad Europea es algo que necesitas conocer y aprender. No estoy preparado para hablar sobre la diferencia entre WCAG 2 versus WCAG 3, pero debería poder encontrarte algunos recursos si no existen en mi cosa de recursos de aprendizaje. Solo házmelo saber.

Genial. Doug viene por ti. Lo sé. Siempre lo hace. Una buena pregunta. Muy relevante en el tiempo. Hice clic en el botón equivocado. ¿Cómo hago que la IA sea más accesible? Así que tienes que pensar en la experiencia del usuario, ¿verdad? Hemos hablado sobre cuando se añaden cosas a la página usando regiones en vivo en un chat, también necesitamos asegurarnos de que las interfaces que estamos construyendo sean accesibles para personas que no ven y usan un ratón. Aparte de eso, realmente no sé. Podría ser una larga discusión. Podría ser toda una charla. Si quieres dar una charla sobre eso, sería genial.

Estábamos ambos. Ay. Muy bien.

Siguiente pregunta de nuestro amigo Anónimo. Abby, gran demostración. Soy el desarrollador con el aderezo. ¿Conoces alguna buena manera de automatizar las pruebas de lectores de pantalla, por ejemplo? Así que las pruebas automatizadas para la accesibilidad detectan... Hay un montón de diferentes números flotando, pero como el 30 al 40% de los errores. La mejor manera de saber si un sitio web es accesible es probar con usuarios con discapacidades. Hay recursos de IBM que te guiarán a través de todo el plan de pruebas manuales que haría un auditor de accesibilidad. Así que podrías automatizar con... Sé que incluso hay herramientas de desarrollo para flujos de usuario a través de tu página. Podrías automatizar el tabulado a través de tu página o algo así y verlo tú mismo o conseguir algo que te diga si no hay un contorno de enfoque o algo así. Pero el 100% del tiempo, la mejor manera de averiguar si tu sitio web es accesible es probar con usuarios con discapacidades. Palabra. Muy bien. Eso es todo el tiempo que tenemos para preguntas y respuestas. De hecho, nos hemos pasado y he invadido el tiempo de almuerzo de la gente, así que veo algunas caras enojadas. Así que Abby, quiero agradecerte por estar aquí con nosotros. Gracias. Gracias.