Las pruebas de a11y están rotas: cómo Lighthouse y Axe fallan en proyectos reales

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

El European Accessibility Act (EAA) está llegando, y las empresas se apresurarán a certificar sus sitios web como accesibles de la manera más fácil posible. Pero las altas puntuaciones de Lighthouse y Axe no significan accesibilidad real. Muchos dependerán de estas herramientas para "probar" el cumplimiento, a pesar de sus puntos ciegos críticos: enfoque roto, ARIA engañoso y contenido dinámico inaccesible. Aún más confuso, Lighthouse y Axe están construidos sobre la misma base, sin embargo, pueden producir resultados diferentes. Así que desglosaremos estos defectos y exploraremos mejores formas de garantizar una verdadera accesibilidad. 

This talk has been presented at JSNation 2025, check out the latest edition of this JavaScript Conference.

Glafira Zhur
Glafira Zhur
29 min
12 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La ponente, Gulasha, comparte ideas sobre los desafíos de accesibilidad, el compromiso, las herramientas de prueba automatizadas y el European Accessibility Act. Se hace hincapié en la accesibilidad del contenido de texto, los mandatos de la interfaz web, la importancia de las pruebas manuales y las explicaciones de gráficos complejos. Se destacan los problemas con la visibilidad del enfoque, las pruebas de control por voz y la certificación de accesibilidad global. Se discuten la promoción de prácticas de accesibilidad, la defensa de la certificación y el inicio de pequeñas iniciativas dentro de los equipos.

1. Introducción a la Accesibilidad y Antecedentes

Short description:

La oradora se presenta como Gulasha, una gerente de proyectos de accesibilidad en SEMrush. Ofrece asistencia e invita a hacer preguntas sobre accesibilidad. Originaria de Bielorrusia, comprometida en apoyar ideas comunitarias.

Como Phil les dijo, vine de España y ya viví allí durante seis meses. Y el conocimiento principal que debes aprender al comenzar a vivir allí es una cerveza, por favor. Estoy muy feliz de estar aquí y vamos a hablar sobre lo que Alba nos dijo. No tengo idea. No escuché. Sí.

Así que lo primero que necesito advertirles, esta charla no será una especie de solución porque las cosas de las que voy a hablar hoy dependen de las soluciones que ya tienen en sus sistemas, pero al menos les daré una idea de cómo pueden probar sus aplicaciones para la accesibilidad web. También, accesibilidad móvil, ¿por qué no? Incluso el enfoque está bien para todo. Y el viento es bajo. Y también la idea de esto, como que deberían entender la idea de qué verificar si no saben qué verificar después de haber verificado todo. Así que sí, vamos.

Pero primero permítanme presentarme. Mi nombre es Gulasha. Prefiero este corto, dulce, nadie puede como en Suecia, soy Gulash. Si sabes, sabes. Sí. Trabajo en SEMrush como gerente de proyectos de accesibilidad. También trabajo para Web Technologies, embajadora de VTM, como muchas etiquetas. Si tienen alguna pregunta pueden venir a mí. Soy buena en cosas como accesibilidad 100%. Así que sí, solo vengan a mí y pregunten. Pueden unirse a mí en LinkedIn y Twitter. Pregunten allí todo lo que quieran. Un poco sobre mí. Como esta es en realidad la foto de algunas personas, como en nuestro Minsk, en nuestra comunidad de Bielorrusia. Soy originaria de Bielorrusia, quienes estaban haciendo esta conferencia al principio. Así que es realmente genial estar aquí y apoyar sus ideas. Sí.

2. Challenges and Commitment to Accessibility

Short description:

Comenzó en 2008 como estudiante de informática, se aventuró en la accesibilidad en 2018. Se unió a SEMrush en 2024 como gerente de proyectos de accesibilidad. Encontró desafíos en el diseño web pero sigue comprometida con los esfuerzos de accesibilidad. Requirió formación médica en España, enfrentó barreras lingüísticas durante el proceso.

Así que comencé en 2008 como estudiante de informática. Luego fui a mi primer trabajo justo después de la universidad. Y luego en 2018, la comunidad me atrapó, el front end me atrapó y la accesibilidad también. Era la única persona en Bielorrusia, supongo, que sabía algo sobre accesibilidad. {{^}}Así que comencé a trabajar en el proyecto de accesibilidad del front end. Fue como un gran viaje, mucha inspiración allí. Así que realmente feliz de estar aquí. Y en 2024, me uní a SEMrush como gerente de proyectos de accesibilidad.

Oh dios mío, es realmente difícil conocer el diseño web y todo esto. Es realmente difícil no entrar en los detalles y solo observar todo. Sí. SEMrush es una plataforma líder en gestión de visibilidad en línea y marketing de contenido. Tenemos muchas oficinas alrededor del mundo, mucha gente, y solo un experto en accesibilidad allí. Así que sí. Mucha presión, pero aún así comenzamos a preocuparnos por la accesibilidad hace unos años.

Así que estoy muy feliz de unirme a este camino en nuestra empresa. Y sí, hace unas semanas, se me requirió pasar el entrenamiento médico, cómo decirlo, coaching algo así. Así que fue un requisito de España. Así que como trabajadora en España, debía pasar esta formación. Fueron seis horas de información. Estaba realmente sobrecargada con todo. Y además, el inglés no es mi primer idioma. Así que es realmente difícil entender a veces lo que quieren de mí.

3. Challenges in Accessing Text Content

Short description:

No se pudo acceder al texto para traducir debido al formato de imagen, destacando la accesibilidad rota. Importancia de hacer el contenido disponible para todas las personas, independientemente de sus habilidades o distracciones. La Ley de Accesibilidad Europea exige que todas las interfaces web sean accesibles para el 28 de julio de 2025.

Así que realmente esperaba traducir algunas cosas durante el recorrido por este interesante material. Intenté copiar el texto y pegarlo en el Google Translate. Puedes imaginar lo que pasó. No pasó nada. Ni siquiera pude copiarlo. Porque todo el texto aquí es una imagen, como una gran imagen con texto sobre ella. Así que no puedes copiarlo. No puedes hacer nada con él. Solo la IA puede ayudarte a reconocer todo el texto, pero no es el caso para ti si no sabes cómo hacerlo.

Sí. Así que la accesibilidad aquí está rota. No pude acceder al contenido. Si fuera una persona ciega, no obtendría esta información en absoluto. Así que las cosas médicas no son accesibles. Es realmente divertido. Por eso decidí hablar de ello.

Ni siquiera pude probarlo con tecnologías de accesibilidad con algunos plugins porque ellos no tienen esta función de IA para reconocer textos de tus imágenes. Así que sí. Si no lo sabías, por si acaso, muchos de ustedes, estoy realmente feliz. Por si acaso, ¿de qué se trata la accesibilidad? En primer lugar, te encontrarás con esta abreviatura como A-11-Y. Es lo mismo que con la internalización y todo esto. Así que la accesibilidad es una cosa.

4. Importance of Web Accessibility and European Act

Short description:

Garantizar la accesibilidad del contenido para todas las personas. Importancia de considerar diversas discapacidades y desafíos situacionales. La Ley de Accesibilidad Europea exige que todas las interfaces web sean accesibles para el 28 de julio de 2025.

Y sí. Según la iniciativa de W3C, es una práctica que asegura que tu contenido esté disponible para todos. No importa si la persona es ciega o simplemente, no sé, se perdió algo o está distraída con algo. Así que no significa que todas las personas deban acceder a tu contenido. Por supuesto, se trata más de personas que realmente no pueden hacerlo debido a sus problemas de salud. Pero sí.

Entonces, ¿por qué nos importa? En primer lugar, nos importa por los usuarios. Muchas personas en el mundo tienen discapacidades reales, condiciones médicas. El 15% de la población mundial, eso es mucho. Pero también debemos tener en cuenta que hay personas que no están incluidas en este 15%. Así que deberíamos pensar en nosotros que nos rompimos el brazo o algo así. Estoy bastante seguro de que algo así le ha pasado a alguno de ustedes. Soy zurdo. No puedo usar tijeras en absoluto. Así que es como, ¿por qué?

Y también algunas cosas situacionales, como una luz realmente alta, no sé, a tu alrededor. Como un sol realmente brillante. Así que no puedes ver nada de tu pantalla debido al pobre contraste. O estás conduciendo o estás cargando a un niño, algo así. Como si ahora tuvieras un brazo. Así que sí. Es realmente importante recordar que estas personas no están incluidas en este número. Y también aquí, vivimos en Europa. Europa se trata de accesibilidad. Es realmente genial. Pero este año, llega la nueva Ley de Accesibilidad Europea. Así que todas las empresas que proporcionan a las personas algunas interfaces web deben ser accesibles para el 28 de julio de 2025. En un mes a partir de hoy, todos deberían ser accesibles.

5. Automated Testing and Tool Comparison

Short description:

Europa imponiendo multas por sitios web inaccesibles. Importancia de las pruebas automatizadas para la accesibilidad. Comparación de Google Lighthouse y Agile DevTools para la accesibilidad web.

Así que esta es la fecha en que Europa podrá multarte, quitarte tu dinero, decirte que tienes tres meses para arreglar todo, o serás multado con una gran cantidad de dinero. Y no se trata realmente de este acto, porque ya está funcionando en los países europeos. Por ejemplo, como un caso reciente, la aerolínea llamada Vueling. Volé aquí con Vueling. Fueron multados con 90,000 euros debido a su sitio web inaccesible. Así que ya está sucediendo. Sí. Por eso decidí que es hora de hablar sobre ti. Sobre ti, no sobre ti. Sobre la accesibilidad contigo. Sí. ¿Y qué podemos hacer hoy? Como en un mes, el acto comenzará a funcionar. Así que el primer intento es usar algunas pruebas automatizadas para probar todo lo que tienes para la accesibilidad. Y las pruebas automatizadas son geniales. Dirán, como, eres 100% accesible con, como, un esfuerzo realmente pequeño. Es realmente, realmente genial. No juzgamos este enfoque en absoluto. Estamos contentos de que lo uses. Hazlo. Y W3C ya actualizó la lista de las herramientas automatizadas. Como que recopilaron esta lista. Hay muchas, muchas herramientas en este mundo. Puedes usar, como, 70 para pruebas automatizadas. Eso es mucho. Y realmente me encanta que este sitio web muestre cómo y cuándo fueron actualizadas. Así que puedes elegir las más recientes, las nuevas, para tus casos, solo pruébalas. Sí.

Así que hoy vamos a hablar sobre Google Lighthouse y Agile DevTools. Porque son los más populares en el mercado. Lo primero que escucharás si vas a probar tus sitios web para accesibilidad son estas dos herramientas. Lighthouse es fácil porque ya está en tu navegador. Y Agile DevTools es, como, es una herramienta realmente genial. Porque te proporcionan mucha información. Lighthouse también te proporciona mucha información. Pero Lighthouse se siente más central. Pero lo curioso aquí es que Lighthouse y Agile, usan el mismo núcleo de accesibilidad como, la misma biblioteca, que está verificando la accesibilidad. Pero ellos, por alguna razón, lo usan de manera diferente. Así que no sé por qué. Por eso decidí compararlos. Porque realmente quiero que veas que no todas las herramientas funcionan de la misma manera. Incluso si usan el mismo código bajo el capó. Así que sí. Realmente recomiendo Lighthouse y Agile DevTools. Agile DevTools es solo un plugin para tu navegador. Así que instálalo. Y usa la versión gratuita de él. Eso es suficiente por ahora. Así que estas herramientas suelen afirmar que son... Tienen una gran cobertura.

6. Accessibility Testing and Text Alternatives

Short description:

Explorando problemas de accesibilidad en las pruebas de sitios web. Importancia de la revisión manual para problemas específicos. Enfatizando la necesidad de una comprensión clara del texto y las etiquetas.

Como la cobertura de todos los problemas de accesibilidad. Como alrededor del 60% de los problemas se detectarán en tu sitio web cuando lo pruebes por primera vez con Lighthouse. O en realidad, lo mismo. Como el núcleo de Agile. Agile DevTools Lighthouse, lo mismo. Pero los expertos no están tan seguros. Nos están mostrando... Los expertos... Como realmente grandes empresas de auditoría en América, que tienen estos números. Como el 25% de los problemas en tu sitio web podrían ser detectados automáticamente. Solo el 25. Como cosas verdaderas o falsas. Esto es verde. Esto es amarillo. ¿Es suficiente el contraste de color? No. Sí. Así que lo que pueden contar, más o menos. Hay un 35% de los problemas que deberían ser revisados por la persona que está probando. Como revisión manual. Y también hay un 40% de los problemas que son... Que no pueden ser detectados automáticamente en absoluto. Y el tipo de problemas son sobre cosas visuales. La comprensión del texto, las etiquetas. Como si son lo suficientemente claras para el usuario. También algunos detalles técnicos que te mostraré un poco más tarde. Así que es realmente... Te muestro este recurso donde recopilan todos los tipos de problemas que pueden ser probados automáticamente. O hay algunas ideas sobre cómo probarlos, etc. Así que solo ve allí y revisa. Tal vez da algunas ideas. Es de código abierto. Así que sí.

Probemos ejemplos de la vida real. Y primero, por supuesto, quiero volver a las alternativas de texto para gráficos. Para imágenes, como no pude copiarlo. Así que si la imagen es un texto, si carece de la presentación de texto, enfrentarás problemas como que no puedes acceder al contenido con las tecnologías de asistencia. No puedes copiar el texto. Y no puedes traducir herramientas automáticamente. Y esto es porque soy un desarrollador web. Por supuesto, abro DevTools cada vez. Así que esto es porque no tienes ningún texto alternativo para esta imagen. Como si estuviera vacío. Pero está ahí. Así que no podría ser probado como un problema con Lighthouse. Porque muestra como si todo estuviera realmente bien. Tienes alt. Está vacío. Parece... Significa que es una imagen decorativa. No necesitas poner nada allí. Así que no es un problema en absoluto.

7. Pruebas de Gráficos Complejos e Interacciones de Teclado

Short description:

Importancia de explicar gráficos complejos para usuarios que no pueden verlos. Destacando pruebas de accesibilidad para cuadros de selección personalizados e interacciones de teclado.

Ni siquiera pude probar este sitio web porque es un iFrame. Y no todas las herramientas pueden probar iFrame. Así que solo ten cuidado. Pero algunas herramientas sí pueden. En SEMrush, hacemos... Es realmente importante entender que hay un gráfico complejo. Te olvidas de ello. Pero es realmente importante dar una explicación para este tipo de gráficos. Por ejemplo, damos la explicación para nuestros gráficos, para nuestros datos de alguna manera para los usuarios que no pueden leerlo o verlo.

Así que es realmente genial hacer algunas cosas. Interacciones de teclado. Me encanta este ejemplo. Es como para siempre. Permanece allí para siempre. V3C Schools, por supuesto, es un recurso algo desactualizado. Pero tienen este ejemplo de cuadro de selección personalizado. Así que cómo estilizarlo. Así que revisé el sitio web con Aux Dev Tools para accesibilidad. ¿Y qué veo? Veo que no hay problemas. Hay seis problemas de contraste de color. Y un problema para el select. El nativo. Pero no hay problemas para este select azul. Es accesible. Significa que es accesible. Así que está bien. Genial.

Y Lighthouse es lo mismo. Encuentra los mismos problemas, como el contraste de color de fondo y primer plano. Y también el select no tiene el nombre accesible. Así que genial. Estamos cubiertos. Pero ¿por qué? ¿Por qué? Porque diff está en todas partes. Así que este componente puede ser capturado por las herramientas de prueba. Porque son solo diffs con texto. Así que no es nada. Como para las Aux Dev Tools, no tiene ningún tipo. No es un campo. No es un select. Son solo diffs con texto. Así que no. No hay pruebas para este componente. Desafortunadamente. Sí. Así que deberías... Ni siquiera lo sabes. No hay problema. Está bien. La otra cosa con el teclado es la visibilidad del enfoque. Y te muestro el caso. El estado inicial es dos botones.

8. Focus Visibility Issues and Voice Control Testing

Short description:

Explorando problemas con la visibilidad del enfoque y la herramienta de control por voz para pruebas de accesibilidad.

Botón izquierdo y derecho. Luego presiono la tecla tabulador. Y veo el estado de enfoque, como un hermoso borde alrededor de un botón. Y luego presiono la tecla tabulador para ver el mismo borde en el botón derecho. Lo que veo, en realidad, es una pequeña línea entre estos elementos que aparece. Así que no tiene la misma forma de borde. Siempre estamos al frente y siempre tenemos problemas con la visibilidad del enfoque. El enfoque del teclado o del ratón realmente no importa. Sí.

Así que este es un problema que es visual. El Lighthouse, el Aux Core, no pueden encontrar este tipo de problemas. Así que necesitas verificarlo manualmente con tus ojos. También, tal vez algún tipo de prueba. Como la... No sé. Como la prueba de captura de pantalla o algo así. Sí. Y no hay problemas. Si pruebas este sitio web para accesibilidad, encuentras solo algún botón sin etiqueta y solo uno. Así que es un gran resultado. Y no hay problemas. Y también, Lighthouse y Aux muestran el mismo resultado.

Y esto es lo que realmente quiero mostrarte, es la herramienta de control por voz. Como cada sistema operativo tiene esta herramienta que se llama control por voz. Así que puedes controlar, obviamente, el sistema operativo con tu voz. Dices algunos comandos, como... Espero haberlo apagado. Como empezar a escuchar, dejar de escuchar, y así sucesivamente. Así que decidí probar el sitio web. Así que no puedes mover tus brazos. Solo puedes operar con tu voz. Sí. Así que el sitio web de la compañía de transporte, realmente irreconocible. Así que primero probé este sitio web para accesibilidad con Lighthouse. Muestra que hay algunos enlaces que no están etiquetados. Bien.

9. Aux Test Results and Voice Control Challenges

Short description:

Las pruebas con Aux revelaron problemas con enlaces e imágenes sin etiquetar, y la importancia de etiquetas de accesibilidad precisas para la operación de control por voz.

Entonces es como un resultado realmente genial. Sin problemas. Luego probé con Aux. Aux nos da diferentes resultados por alguna razón. Como hay algunos enlaces, hay algunas imágenes que no están etiquetadas, y también algunos SVG que no están etiquetados. Así que Aux obtiene más información. Así que está bien. Y estos son enlaces. Así que podemos arreglarlos realmente rápido y obtendremos como el 100% del resultado.

Y déjame mostrarte un pequeño video de cómo opero con mi voz con el sistema, lo que veo. Espero que puedas escucharlo. No estoy seguro si puedo escucharlo. Click search. Así que estoy pidiendo hacer click en search. Show names. No pasa nada. Asumo que las etiquetas son diferentes. Así que para search, es search trips, en realidad. Click change departure date today. Así que mi experiencia se volvió más larga. Click change departure date today. No es solo el campo de departure. Eso es algo que no veo. Click search trips. Ahora pido hacer click en search trips y funciona. Funciona y va a la página diferente.

Go back. Regreso a la página anterior y sí. Hide names. Pido ocultar nombres y solo intento. Click search. Hazlo una vez más. Click search. No pasa nada. Click search trips. Y search trips sucede, como funciona bien. Esto se debe a las etiquetas de accesibilidad que son diferentes de lo que ves. Start listing. Solo un segundo. Sí. Cuando reviso estos botones, veo que el nombre, el nombre accesible, es search trips. Y el contenido era search. Así que para las personas que no, solo ven tu contenido. Ellos dependen de las etiquetas. Así que es realmente importante para ellos entender, como hacer click directamente.

10. Label Overuse and Page Zooming Impact

Short description:

Problemas con el uso excesivo de etiquetas, desafíos con el zoom de página que afectan la accesibilidad, y la importancia de probar nuevas características con la funcionalidad existente.

Ellos no quieren hablar más o encontrar algunos lugares para hablar donde la etiqueta real exista. Lo mismo para los botones de continuar en la segunda página. Tienen un nombre accesible. Así que selecciona este viaje y continúa. Entonces, ¿cómo debería adivinar? Solo pido hacer clic en continuar y no funcionará. Porque la etiqueta es mucho más larga. Así que sí. No sobreutilicemos etiquetas reales, por favor.

Y también, el zoom de página es algo enorme. Como este es el sitio web antes de que ampliara la página. Lo revisé para accesibilidad. Ya es gracioso. Porque como cuando abrí DevTools, se volvió más pequeño. Y ya veo los problemas con el contenido, que sale de la pantalla. Pero no hay problemas, como cero problemas. Sí. Así que correcto. Es accesible, completamente accesible. Y lo mismo. Estos resultados son diferentes de ActiveTools.

Como ahora Lighthouse nos da más información sobre esto. Así que sí. Aumento hasta un 200% en el navegador. Y veo que el contenido sale de la pantalla. No hay como un scroll. Así que no puedo obtener este contenido ya. Así que es inaccesible. También, algunas etiquetas. Como al 100% están bien. Al 200% se esconden bajo el otro contenido. Así que es realmente algo que no puedes verificar automáticamente. Y sí. Así que cosas como tenemos alguna nueva característica. La añadimos a nuestro sitio web. Y nunca verificamos cómo funciona con la funcionalidad existente.

11. European Accessibility Testing Approach

Short description:

Impacto del Accessibility Act en los desarrolladores, importancia de la comprensión humana en las pruebas, enfoque de Europa hacia las pruebas de accesibilidad con una combinación de herramientas y pruebas manuales.

Así que aquí el menú está oculto bajo el banner sobre el cambio de país. Así que sí. Lo que realmente quiero que saquemos de esta charla. Primera cosa. El Accessibility Act está llegando. Así que nos afectará a todos, supongo. A todos los desarrolladores front-end.

O a todos los desarrolladores móviles. Así que por favor revisen sus interfaces para accesibilidad. Todos estaremos de alguna manera obligados a tener este conocimiento. Además, por favor tengan en cuenta que todas las herramientas. Pueden usar todas las herramientas en este mundo para verificar todo.

QnA

Global Accessibility Certification

Short description:

Recuerda ser el humano que entiende el contenido, vuelve a probar a fondo. Las pruebas insuficientes afectan a todos los usuarios. Se proporcionan enlaces para acceso directo. Europa prueba con herramientas Aux Dev, pruebas manuales, enfocándose en lectores de pantalla. Importancia de la certificación global de accesibilidad con estándares WCAG.

Pero debes recordar que no revisarán todo, en realidad. No son humanos. Así que no pueden entender el contenido correctamente. Así que debes ser ese humano que entenderá este contenido. Y además, no dudes en volver a probar las cosas. Por favor. Bueno, vivo en España, así que por favor es solo por favor. Sí. Sí. Así que sí. Por favor prueba todo. Y recuerda que las pruebas insuficientes excluirán a las personas de tu producto. Y no se trata solo de personas que tienen alguna discapacidad. Se trata de todos. Te doy una lista de los enlaces de esta charla. Así que puedes usarlos directamente. También está el enlace a la diapositiva. Así que puedes obtenerlos justo después de la charla. Sí. Muchas gracias. Por favor contáctame en todas partes. Estoy pasando al siguiente. Únete a mí en LinkedIn. Y estoy realmente feliz de que estuvieras aquí conmigo. Gracias.

La primera es, ¿alguna idea de cómo Europa prueba aplicaciones para accesibilidad? ¿Usan herramientas similares? Tengo la idea. Porque ahora hay empresas apareciendo como hongos, ¿sabes? Como, cada segundo, nuevas empresas que serán una especie de auditores. Así que prueban con las mismas herramientas. Usualmente usan herramientas Aux Dev, o van por cosas más, como, pesadas. Pero todos usan este núcleo. Así que definitivamente será así. Así que Aux es una buena herramienta para comenzar. Y también, harán una prueba manual, por supuesto, porque es realmente importante probar el lector de pantalla, como lo usan las personas ciegas, y todas las demás tecnologías asistivas. Pero lo harán realmente rápido. Así que no espero nada, como, realmente difícil para la primera etapa de la prueba para el acta. Así que veremos cómo va. Pero sí, definitivamente usarán estas herramientas, porque son como gratuitas o incluso pagadas. Y no hay nada realmente nuevo en el mercado. Así que es realmente bueno. Así que solo están estas. Sí, sí. Así que abres el W3C, abres las herramientas más populares, las tomas, y verificas todo con ellas. Así que es así. OK. Así que al menos si probamos con esas herramientas, estamos listos para ir. OK. Así que siguiente pregunta. ¿Cuál es la mejor manera de asegurar que tu producto sea accesible para todos los demográficos a nivel mundial? ¿Qué puedo decir? Primero que nada, necesitas entender dónde estás presente. Como, ¿estás presente en los países que requieren realmente mucho, como en América en los Estados Unidos, requieren accesibilidad? Así que es realmente importante tener este tipo de certificación. Así que hay estándares WCAG que tenemos para accesibilidad.

Accessibility Advocacy and Certification

Short description:

Asegurar la accesibilidad cumpliendo con los requisitos y obteniendo la certificación. Realizar auditorías, priorizar problemas y realizar pruebas automatizadas. Abogar por la accesibilidad dentro del equipo y la empresa con ejemplos prácticos y comenzando con pequeñas iniciativas.

Es una lista de requisitos. Así que necesitas ser accesible cumpliendo con todos los requisitos, como para este país en particular o algo así. Así que vas a esta lista. Verificas los requisitos. Pruebas tu aplicación de acuerdo con los requisitos, porque esto es lo que hará el auditor. Y también, es realmente importante obtener esta certificación. Si necesitas ser accesible en estos países, necesitas obtener la certificación de alguna empresa bien conocida. No es una certificación real. No tenemos tales cosas en accesibilidad. Así que sí, alguna empresa realmente bien conocida que sea de confianza. Así que lo haces. Y luego haces una auditoría. Encuentras todos los problemas. Los estás delimitando. Les das, ¿cómo se llama?, prioridades. Y luego los solucionas. Así que diría, en términos de los requisitos, debería ser el auditor primero quien encuentre todos los problemas. O lo haces tú mismo. Enumera todos los problemas. Pero si no es necesario para ti, entonces solo comienza con pruebas automatizadas. Por favor hazlo. Por favor encuentra todos los problemas que puedas solucionar automáticamente. Luego comienza a aprender cómo los usuarios usan los sitios web, cómo usan las tecnologías asistivas. Y soluciona estas cosas que encuentres. Es difícil. Es un camino enorme. Es un proceso continuo. Sí, exactamente, exactamente.

Sobre ello sin que tus usuarios estén allí, específicamente. Bien, entonces la siguiente pregunta es, ¿algún consejo sobre cómo abogar por la accesibilidad en las empresas de nuestros equipos? Así que esto es como explicas la accesibilidad a tu jefe. Sí, exactamente. Exactamente, exactamente. Así que, ¿algún consejo? Ya estás trabajando en esto. Depende, depende. Sí, estoy trabajando. Fui contratado para la accesibilidad. Fui contratado dos veces. Y ambas veces, de hecho, tres veces. Y las tres veces, fue como, tenemos un proyecto sobre accesibilidad. Necesitamos un experto en accesibilidad. Así que por favor hazlo por nosotros. Así que ya estaban motivados. Pero en caso de que no tengas a nadie, definitivamente puedo compartir el enlace al último Accessibility Club Summit donde una persona realmente importante explica cómo abogar por la accesibilidad a través de ejemplos realmente buenos con las, ¿cómo se dice?, bombas de semillas. Como pones las semillas en el suelo, y crecerán como hermosas flores. Y lo haces aquí y allá. Y sí, así que el enfoque es realmente divertido. Pero sí, es difícil. Puedes empezar por ti mismo.

Promoting Accessibility Practices

Short description:

Iniciando prácticas de accesibilidad en diferentes roles. Abordando desafíos con desarrolladores y enfatizando la importancia de la accesibilidad. Explorando herramientas de control por voz en varias plataformas y guiando a los usuarios en la configuración.

Porque todos realmente intentarán ponerte en una habitación oscura. Sí, así que solo comienza despacio e intenta involucrar a más personas. Intenta darles algunos consejos. Intenta aprender juntos. Así que se trata más del proceso realmente largo de insistir en algunas prácticas en todas las esferas. Como los diseñadores deberían saber sobre ello. Y es realmente bueno comenzar con los diseñadores porque los requisitos no son tan grandes como para los desarrolladores web, por ejemplo. Los desarrolladores web son la parte más difícil de ello.

Sí, los desarrolladores de Android son como, sí, podemos hacerlo, pero no queremos hacerlo. Pero wow, resultados. Oh Dios mío, sí, sí. Finalmente, podemos hacerlo. Y los desarrolladores de iOS son como, somos realmente geniales. Ya tenemos accesibilidad. Sí, así que es diferente, pero es un proceso. Y realmente necesitas llevar a todos allí uno por uno, diría yo. Bueno, al menos ahora con el Acto Europeo, tenemos algo por lo que luchar. Sí, 100%. Puedes llevar esto a tu jefe. Y presentar el hallazgo que seguirá.

Sí, bueno, sí, también tenemos una pregunta. ¿Qué herramienta estás usando para el control por voz? Era una herramienta predeterminada de Mac OS llamada Voice Control. Y también en Windows hay la misma herramienta. Y también los usuarios están usando herramientas más avanzadas como las herramientas de control por voz Dragon y así sucesivamente. Así que también en tu teléfono, las mismas herramientas como las llaman, todas se llaman el mismo controlador de voz, algo cercano a ello. Pero esta predeterminada, así que solo encuéntrala en tus configuraciones, enciéndela e intenta hacerlo. Pero primero, busca en Google cómo hacerlo, porque... Sí, configúralo, para mí, habla todo el tiempo y es realmente confuso porque no sé... Es uno diferente. Es uno diferente. Es un lector de pantalla.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Accesibilidad en Discord
React Advanced 2021React Advanced 2021
22 min
Accesibilidad en Discord
This Talk discusses the accessibility efforts at Discord, focusing on keyboard navigation and the challenges faced with implementing focus rings and outlines. The speaker showcases a unified focus ring system and a saturation slider to address accessibility concerns. They also highlight the implementation of role colors and the use of CSS filters for accessibility improvements. The Talk concludes with insights on runtime accessibility checking and the development of a performant core runtime system for checking accessibility issues.
Configurando las Pruebas de Accesibilidad de Axe
TestJS Summit 2021TestJS Summit 2021
30 min
Configurando las Pruebas de Accesibilidad de Axe
Top Content
AXe is an accessibility engine for automated web UI testing that runs a set of rules to test for accessibility problems. It can be configured to disable or enable specific rules and run based on tags. Axe provides various options, but axe linter does not support all options. The importance of investing time and resources in accessibility is emphasized, as it benefits not only those with disabilities but improves the web for everyone. Manual testing is also highlighted as a necessary complement to automated tests for addressing accessibility issues.
Elementos Interactivos Anidados: Una Pesadilla en Accesibilidad
React Advanced 2023React Advanced 2023
23 min
Elementos Interactivos Anidados: Una Pesadilla en Accesibilidad
Top Content
Nested interactive elements can cause accessibility issues on websites, and the speaker shares a personal experience with an accessibility bug involving a list component. Mitigating nested interactive structures involves limiting these patterns during development and restructuring existing elements. The speaker provides recommendations for improving accessibility, such as adjusting role properties and gathering user feedback. The conclusion emphasizes the importance of accessible solutions and encourages sharing resources to build more inclusive experiences.
Dilemas de los diálogos y travesuras modales: Un análisis profundo de las ventanas emergentes
JSNation 2023JSNation 2023
10 min
Dilemas de los diálogos y travesuras modales: Un análisis profundo de las ventanas emergentes
The Talk discusses the use of dialogues and popovers in web development. Dialogues can be modal or non-modal and are now accessibility-supported. Popovers are versatile and can be added to any element without JavaScript. They provide suggestions, pickers, teaching UI, list boxes, and action menus. Modal and non-modal dialogues and popovers have different behaviors and dismissal methods. Browser support for these features is expanding, but there are still open questions about positioning, semantics, and other use cases.
Construyendo un Sitio Web Rápido para Cada Visitante
React Advanced 2024React Advanced 2024
31 min
Construyendo un Sitio Web Rápido para Cada Visitante
This talk focuses on building a fast and accessible website for all users, highlighting the importance of performance and user experience optimization. It emphasizes the need for adaptive implementation to cater to different devices and user conditions. The talk also discusses the factors beyond the developer's control, such as screen size, browsers, devices, internet connection, and sitting position. It highlights the significance of optimizing image components for various devices and the role of browser support and rendering engines. The speaker discusses the use of future APIs and the challenges of browser compatibility, as well as optimizing image formats and bundler compatibility. The talk provides insights on controlling bundler and device compatibility, optimizing CPU usage, internet connection, and JavaScript form submission. It concludes with a proposal to respond with save data instead of effective type for limited internet connections and recommends using React with adaptive hooks for better user experiences. Overall, the talk covers essential aspects of building a fast and accessible website.
a11y y TDD: Una Combinación Perfecta
JSNation 2022JSNation 2022
24 min
a11y y TDD: Una Combinación Perfecta
This Talk explores the intersection of accessibility and test-driven development (TDD) in software development. TDD is a process that involves writing tests before writing production code, providing a safety net for code changes. The Talk demonstrates how to apply TDD principles to real-life examples, such as filling out a form, and emphasizes the importance of user-centric testing. By using atomic design principles, code can be organized in a clean and easy way. The Talk also discusses the use of labels and test IDs in tests for improved accessibility.

Workshops on related topic

Accesibilidad web para Ninjas: Un enfoque práctico para crear aplicaciones web accesibles
React Summit 2023React Summit 2023
109 min
Accesibilidad web para Ninjas: Un enfoque práctico para crear aplicaciones web accesibles
Workshop
Asaf Shochet Avida
Eitan Noy
2 authors
En este masterclass práctico, te proporcionaremos las herramientas y técnicas que necesitas para crear aplicaciones web accesibles. Exploraremos los principios del diseño inclusivo y aprenderemos cómo probar nuestros sitios web utilizando tecnología de asistencia para asegurarnos de que funcionen para todos.
Cubriremos temas como el marcado semántico, los roles de ARIA, los formularios y la navegación accesibles, y luego nos sumergiremos en ejercicios de codificación donde podrás aplicar lo que has aprendido. Utilizaremos herramientas de prueba automatizadas para validar nuestro trabajo y asegurarnos de cumplir con los estándares de accesibilidad.
Al final de este masterclass, estarás equipado con el conocimiento y las habilidades para crear sitios web accesibles que funcionen para todos, y tendrás experiencia práctica utilizando las últimas técnicas y herramientas para el diseño inclusivo y las pruebas. ¡Únete a nosotros en este increíble masterclass de codificación y conviértete en un ninja de la accesibilidad web y el diseño inclusivo!
Pruebas automatizadas de accesibilidad con jest-axe y Lighthouse CI
TestJS Summit 2021TestJS Summit 2021
85 min
Pruebas automatizadas de accesibilidad con jest-axe y Lighthouse CI
Workshop
Bonnie Schulkin
Bonnie Schulkin
¿Incluyen tus pruebas automatizadas verificaciones de accesibilidad? Este masterclass cubrirá cómo comenzar con jest-axe para detectar violaciones de accesibilidad basadas en código, y Lighthouse CI para validar la accesibilidad de las páginas completamente renderizadas. Ninguna cantidad de pruebas automatizadas puede reemplazar las pruebas manuales de accesibilidad, pero estas verificaciones se asegurarán de que tus probadores manuales no estén haciendo más trabajo del necesario.
Accesibilidad web en aplicaciones JavaScript
React Summit 2022React Summit 2022
161 min
Accesibilidad web en aplicaciones JavaScript
Workshop
Sandrina Pereira
Sandrina Pereira
A menudo vemos que JavaScript daña la accesibilidad de un sitio web. En esta masterclass, aprenderás cómo evitar errores comunes y cómo utilizar JS a tu favor para mejorar la accesibilidad de tus aplicaciones web.
En esta masterclass exploraremos múltiples ejemplos del mundo real con problemas de accesibilidad, y aprenderás cómo hacer que funcionen para las personas que utilizan un mouse o un teclado. También aprenderás cómo se utilizan los lectores de pantalla, ¡y te mostraré que no hay razón para tener miedo de usar uno!
Únete a mí y déjame mostrarte cómo la accesibilidad no limita tus soluciones o habilidades. ¡Al contrario, las hace más inclusivas!
Al final, serás capaz de:- Comprender los principios de WCAG y cómo están organizados- Conocer casos comunes en los que JavaScript es esencial para la accesibilidad- Crear enlaces, botones y elementos conmutables inclusivos- Utilizar regiones en vivo para errores y estados de carga- Integrar la accesibilidad en el flujo de trabajo de tu equipo de inmediato- Darte cuenta de que crear sitios web accesibles no es tan difícil como parece ;)
Creando aplicaciones React Native accesibles
React Summit Remote Edition 2021React Summit Remote Edition 2021
91 min
Creando aplicaciones React Native accesibles
Workshop
Scott Vinkle
Scott Vinkle
React Native es un framework utilizado para crear aplicaciones nativas de iOS y Android de una manera con la que los desarrolladores web ya pueden estar familiarizados. Pero, ¿cómo asegurarse de que tus aplicaciones React Native sean inclusivas y utilizables para todos? Scott compartirá consejos sobre cómo probar y construir aplicaciones React Native con accesibilidad integrada.