{"id":1380,"date":"2026-09-11T07:00:00","date_gmt":"2026-09-11T05:00:00","guid":{"rendered":"https:\/\/programaraciegas.net\/?p=1380"},"modified":"2026-08-28T07:26:30","modified_gmt":"2026-08-28T05:26:30","slug":"garantizar-la-accesibilidad-con-pruebas-automatizadas","status":"publish","type":"post","link":"https:\/\/programaraciegas.net\/?p=1380","title":{"rendered":"Garantizar la accesibilidad con pruebas automatizadas"},"content":{"rendered":"

En el mundo del desarrollo de software una funcionalidad que hoy funciona puede dejar de hacerlo ma\u00f1ana despu\u00e9s de una modificaci\u00f3n aparentemente inocente. Para evitar este problema se crean las pruebas automatizadas<\/strong> para mantener la funcionalidad y la forma de utilizar una interfaz de usuario.<\/p>\n

La accesibilidad<\/strong> deber\u00eda formar parte de esas pruebas para garantizar que todos los usuarios pueden acceder a la funcionalidad.<\/p>\n

Sin embargo, todav\u00eda es frecuente tratarla como una actividad posterior al desarrollo. Primero se construye la interfaz, despu\u00e9s se comprueba si funciona y, en alg\u00fan momento, alguien ejecuta una herramienta de accesibilidad o realiza una auditor\u00eda. El problema de este planteamiento es que convierte la accesibilidad en una fotograf\u00eda puntual cuando deber\u00eda ser una propiedad del software que intentamos conservar durante toda su vida.<\/p>\n

La automatizaci\u00f3n de las pruebas puede ayudar a garantizar y mantener esa accesibilidad.<\/p>\n

Como explica Marcy Sutton en Writing Automated Tests for Accessibility<\/a>, las pruebas autom\u00e1ticas no pueden descubrir todos los problemas de accesibilidad. Tampoco sustituyen las pruebas manuales ni las realizadas con personas con discapacidad. Su utilidad est\u00e1 en otro lugar: permiten comprobar de manera sistem\u00e1tica aquello que una m\u00e1quina s\u00ed puede verificar y, sobre todo, detectar regresiones antes de que lleguen a producci\u00f3n<\/strong>.<\/p>\n

La accesibilidad tambi\u00e9n puede sufrir regresiones<\/h2>\n

Una regresi\u00f3n<\/strong> aparece cuando una modificaci\u00f3n introduce un problema en algo que anteriormente funcionaba.<\/p>\n

Si una funci\u00f3n debe devolver un determinado resultado para una entrada concreta, podemos escribir una prueba que establezca ese comportamiento. Cada vez que alguien modifique el c\u00f3digo, la prueba volver\u00e1 a ejecutarse.<\/p>\n

Con la accesibilidad sucede exactamente lo mismo. Un bot\u00f3n puede tener hoy un nombre accesible<\/strong> y perderlo durante una refactorizaci\u00f3n. Un di\u00e1logo puede devolver correctamente el foco al elemento que lo abri\u00f3 hasta que alguien modifica su implementaci\u00f3n. Un componente de pesta\u00f1as puede responder a las flechas del teclado y dejar de hacerlo despu\u00e9s de actualizar una dependencia.<\/p>\n

La interfaz puede parecer id\u00e9ntica. Para una persona que utiliza el rat\u00f3n puede incluso continuar funcionando con normalidad. Pero para otros usuarios el cambio puede haber roto una parte esencial de la aplicaci\u00f3n.<\/p>\n

Las pruebas automatizadas permiten convertir algunos de esos requisitos de accesibilidad en condiciones verificables<\/strong>. En lugar de confiar \u00fanicamente en que nadie elimine accidentalmente un comportamiento accesible, podemos hacer que el propio proyecto compruebe su existencia.<\/p>\n

Automatizar no significa automatizarlo todo<\/h2>\n

La accesibilidad no puede reducirse a obtener un informe sin errores de una herramienta autom\u00e1tica.<\/p>\n

Una m\u00e1quina puede comprobar determinadas propiedades del c\u00f3digo y del documento. Puede encontrar ciertos usos incorrectos de ARIA<\/strong>, detectar algunos problemas de contraste, analizar etiquetas o identificar errores en la estructura HTML. Tambi\u00e9n podemos escribir nuestras propias pruebas para comprobar el comportamiento de componentes concretos.<\/p>\n

Pero existen preguntas mucho m\u00e1s dif\u00edciles.<\/p>\n

\u00bfTiene sentido el orden de lectura? \u00bfEs comprensible el texto alternativo de una imagen dentro de su contexto? \u00bfResulta sencillo completar una tarea utilizando un lector de pantalla? \u00bfEs predecible la gesti\u00f3n del foco? \u00bfPuede una persona comprender un mensaje de error y recuperarse de \u00e9l?<\/p>\n

No todas estas cuestiones pueden resolverse observando el DOM y aplicando un conjunto de reglas.<\/p>\n

La automatizaci\u00f3n, por tanto, no deber\u00eda entenderse como un sustituto de las pruebas de accesibilidad realizadas por personas. Es una capa adicional dentro de una estrategia m\u00e1s amplia.<\/p>\n

Su ventaja consiste precisamente en encargarse de las comprobaciones repetibles para que el tiempo humano pueda dedicarse a aquello que exige interpretaci\u00f3n, experiencia y contexto.<\/p>\n

Probar resultados en lugar de implementaciones<\/h2>\n

Una buena prueba automatizada deber\u00eda sobrevivir, dentro de lo razonable, a los cambios internos del software.
Las pruebas deber\u00edan concentrarse en el resultado esperado y no en los detalles de implementaci\u00f3n.<\/p>\n

Supongamos que tenemos un componente que muestra un di\u00e1logo. Desde el punto de vista de quien utiliza la interfaz, lo importante no es qu\u00e9 funciones internas se ejecutan ni qu\u00e9 variables cambian de valor. Lo que importa es que el di\u00e1logo pueda abrirse con el teclado, que el foco termine donde corresponde, que pueda cerrarse y que, al hacerlo, el usuario pueda continuar desde una posici\u00f3n coherente.<\/p>\n

Una prueba demasiado vinculada a la implementaci\u00f3n puede romperse cada vez que refactorizamos el componente, aunque su comportamiento siga siendo correcto. Cuando esto ocurre con frecuencia, las pruebas empiezan a percibirse como un obst\u00e1culo. Finalmente alguien las desactiva o las elimina.<\/p>\n

Una prueba centrada en el comportamiento expresa algo diferente: mientras esta funcionalidad exista, esta propiedad debe seguir cumpli\u00e9ndose.<\/p>\n

En accesibilidad, esa diferencia es particularmente valiosa porque transforma ciertos requisitos en parte del contrato del componente.<\/p>\n

El teclado como parte de las pruebas<\/h2>\n

El teclado<\/strong> es una de las herramientas m\u00e1s sencillas para comenzar a evaluar la accesibilidad de una interfaz.<\/p>\n

Podemos recorrer una p\u00e1gina utilizando la tecla Tab<\/em>, comprobar si alcanzamos los controles interactivos, observar si el foco resulta visible y verificar si podemos realizar una tarea sin recurrir al rat\u00f3n.<\/p>\n

Una parte de ese comportamiento tambi\u00e9n puede incorporarse a las pruebas automatizadas.<\/p>\n

Un di\u00e1logo puede tener una prueba que compruebe que Escape<\/em> permite cerrarlo. Un men\u00fa puede verificar el funcionamiento de las teclas de direcci\u00f3n. Un componente de pesta\u00f1as puede comprobar que el foco se desplaza de acuerdo con el patr\u00f3n de interacci\u00f3n previsto.<\/p>\n

Esto resulta especialmente interesante porque la accesibilidad deja de estar asociada \u00fanicamente al marcado HTML.<\/p>\n

Un componente puede utilizar atributos ARIA aparentemente correctos y seguir siendo inaccesible si su comportamiento con el teclado es incorrecto. La accesibilidad de una interfaz din\u00e1mica depende tanto de la informaci\u00f3n que exponemos como de las interacciones que permitimos realizar.<\/p>\n

Las pruebas de integraci\u00f3n<\/strong> son especialmente adecuadas para muchas de estas comprobaciones, ya que el foco y la interacci\u00f3n suelen atravesar los l\u00edmites de un \u00fanico componente.<\/p>\n

Pruebas unitarias y pruebas de integraci\u00f3n<\/h2>\n

No todas las pruebas de accesibilidad tienen que ejecutarse al mismo nivel.<\/p>\n

Una prueba unitaria<\/strong> puede comprobar una pieza aislada del sistema. Por ejemplo, que determinada propiedad proporcionada a un componente termine convirti\u00e9ndose en el nombre accesible de un bot\u00f3n.<\/p>\n

Este tipo de prueba es r\u00e1pida y permite verificar problemas concretos.<\/p>\n

Las pruebas de integraci\u00f3n<\/strong> permiten observar un escenario m\u00e1s amplio. Podemos cargar una interfaz, simular una interacci\u00f3n con el teclado y comprobar qu\u00e9 elemento recibe el foco despu\u00e9s de una determinada acci\u00f3n.<\/p>\n

Las pruebas de extremo a extremo<\/strong> llevan esta idea todav\u00eda m\u00e1s lejos, reproduciendo recorridos pr\u00f3ximos a los de una persona que utiliza la aplicaci\u00f3n.<\/p>\n

No existe un \u00fanico nivel correcto para probar la accesibilidad. La elecci\u00f3n depende de aquello que queremos garantizar.<\/p>\n

Si nos interesa comprobar que una API transmite correctamente determinada informaci\u00f3n de accesibilidad, una prueba unitaria puede ser suficiente. Si queremos saber qu\u00e9 sucede con el foco despu\u00e9s de abrir y cerrar varios componentes, necesitaremos observar una porci\u00f3n mayor de la aplicaci\u00f3n.<\/p>\n

Incorporar motores de accesibilidad<\/h2>\n

Adem\u00e1s de escribir pruebas espec\u00edficas para nuestros componentes, podemos incorporar motores especializados en detectar autom\u00e1ticamente problemas de accesibilidad.<\/p>\n

Uno de los m\u00e1s conocidos es axe-core<\/a>, desarrollado por Deque. Puede integrarse con distintos entornos de pruebas para analizar un componente, una p\u00e1gina o un estado determinado de la aplicaci\u00f3n.<\/p>\n

La idea es sencilla. La prueba presenta una interfaz al motor de accesibilidad, ejecuta el an\u00e1lisis y comprueba los resultados obtenidos. Si aparecen determinadas infracciones, la prueba puede fallar.<\/p>\n

Esto permite trasladar algunas comprobaciones al mismo lugar en el que ya verificamos el resto del software.<\/p>\n

En lugar de esperar a una auditor\u00eda posterior, una modificaci\u00f3n que introduzca ciertos errores puede provocar un fallo durante la integraci\u00f3n continua<\/strong>. El problema aparece entonces mucho m\u00e1s cerca del momento en que fue introducido.<\/p>\n

Esta proximidad tiene una ventaja pr\u00e1ctica considerable. Corregir un error cuando todav\u00eda estamos trabajando en el componente suele ser m\u00e1s sencillo que descubrirlo semanas despu\u00e9s, cuando el c\u00f3digo ya se encuentra integrado con otras partes del sistema.<\/p>\n

Probar los estados, no solamente las p\u00e1ginas<\/h2>\n

Las aplicaciones web modernas cambian constantemente de estado. Un men\u00fa cerrado no contiene necesariamente los mismos elementos visibles que un men\u00fa abierto. Un di\u00e1logo puede no existir en el DOM hasta que alguien pulsa un bot\u00f3n. Un formulario puede mostrar mensajes adicionales despu\u00e9s de una validaci\u00f3n. Un acorde\u00f3n oculta informaci\u00f3n hasta que se expande.<\/p>\n

Todo esto plantea un problema para las herramientas autom\u00e1ticas: solo pueden analizar aquello que existe en el estado que les presentamos.
Ejecutar un an\u00e1lisis de accesibilidad inmediatamente despu\u00e9s de cargar una p\u00e1gina puede dejar fuera una parte considerable de la interfaz.<\/p>\n

Por esta raz\u00f3n las pruebas autom\u00e1ticas deber\u00edan recorrer los estados significativos.<\/p>\n

Podemos analizar la p\u00e1gina inicialmente, abrir despu\u00e9s un di\u00e1logo y volver a analizarla. Podemos desplegar un men\u00fa, provocar los errores de un formulario o mostrar contenido que inicialmente estaba oculto.<\/p>\n

La unidad de accesibilidad que nos interesa comprobar no siempre es la p\u00e1gina. En una aplicaci\u00f3n din\u00e1mica, muchas veces es el estado de la interfaz<\/strong>.<\/p>\n

Accesibilidad dentro de la integraci\u00f3n continua<\/h2>\n

Cuando estas pruebas forman parte de la ejecuci\u00f3n habitual del proyecto, la accesibilidad entra tambi\u00e9n en el proceso de integraci\u00f3n continua<\/strong>.<\/p>\n

Una auditor\u00eda peri\u00f3dica nos dice qu\u00e9 problemas existen en un momento determinado. Una prueba autom\u00e1tica puede impedir que ciertos problemas conocidos vuelvan a introducirse.<\/p>\n

La diferencia es parecida a la que existe entre inspeccionar peri\u00f3dicamente si una puerta permanece cerrada e instalar un mecanismo que avise cada vez que alguien la deja abierta.<\/p>\n

La segunda opci\u00f3n tampoco garantiza que el edificio sea seguro. Pero convierte una condici\u00f3n concreta en algo que se vigila continuamente.<\/p>\n

Con la accesibilidad podemos hacer lo mismo. No podremos automatizar toda la experiencia de una persona, pero s\u00ed establecer determinadas condiciones que el software no deber\u00eda incumplir.<\/p>\n

El peligro de confiar demasiado en el resultado<\/h2>\n

Existe una consecuencia inc\u00f3moda al automatizar la accesibilidad que consiste en que podemos empezar a confiar demasiado en aquello que hemos automatizado.<\/p>\n

Una bater\u00eda de pruebas sin errores no demuestra que un producto sea accesible. M\u00e1s bien demuestra que ha superado las comprobaciones que hemos decidido ejecutar.<\/p>\n

Las herramientas autom\u00e1ticas trabajan con reglas que pueden evaluarse mediante software. La experiencia de una persona utilizando una interfaz es considerablemente m\u00e1s compleja. Un sitio puede superar todas las comprobaciones autom\u00e1ticas y continuar presentando obst\u00e1culos importantes. Por esta raz\u00f3n las pruebas manuales<\/strong> siguen siendo necesarias.<\/p>\n

Utilizar \u00fanicamente el teclado, probar con lectores de pantalla, comprobar diferentes niveles de ampliaci\u00f3n, observar el comportamiento en dispositivos m\u00f3viles y estudiar la experiencia con distintas tecnolog\u00edas de apoyo permiten encontrar problemas que dif\u00edcilmente aparecer\u00e1n en una comprobaci\u00f3n autom\u00e1tica.<\/p>\n

Adem\u00e1s de todo esto deber\u00edamos probar con personas.<\/p>\n

Se puede comprobar t\u00e9cnicamente que un componente sigue un patr\u00f3n accesible y descubrir despu\u00e9s que resulta confuso durante una tarea real. Cumplimiento t\u00e9cnico y usabilidad est\u00e1n relacionados, pero no son equivalentes.<\/p>\n

Automatizar para reservar tiempo para las personas<\/h2>\n

El objetivo final de automatizar las pruebas de accesibilidad no deber\u00eda ser eliminar la intervenci\u00f3n humana, sino utilizarla mejor.<\/p>\n

Hay comprobaciones que una m\u00e1quina puede repetir cientos de veces con un coste muy peque\u00f1o. No tiene demasiado sentido pedir a una persona que las realice manualmente en cada modificaci\u00f3n si podemos convertirlas en pruebas fiables.<\/p>\n

Ese tiempo puede dedicarse a cuestiones que necesitan criterio humano.<\/p>\n

La automatizaci\u00f3n tambi\u00e9n proporciona una memoria que los equipos de desarrollo no siempre tienen. Las personas cambian de proyecto, los componentes evolucionan y las decisiones tomadas meses atr\u00e1s pueden olvidarse. Una prueba permanece junto al c\u00f3digo recordando que determinado comportamiento no es accidental.<\/p>\n

Si alguien implement\u00f3 correctamente la gesti\u00f3n del foco de un di\u00e1logo, una prueba puede conservar esa decisi\u00f3n mucho despu\u00e9s de que se haya olvidado la conversaci\u00f3n que la origin\u00f3.<\/p>\n

La accesibilidad como propiedad del software<\/h2>\n

Cuando escribimos una prueba para una caracter\u00edstica de accesibilidad estamos diciendo que ese comportamiento forma parte del producto.
No es una mejora opcional que comprobaremos al final. No es una caracter\u00edstica externa al c\u00f3digo. Es una condici\u00f3n que esperamos que siga siendo cierta despu\u00e9s de cada modificaci\u00f3n.<\/p>\n

La automatizaci\u00f3n no puede decirnos que una aplicaci\u00f3n es accesible. Tampoco puede sustituir a una persona utilizando un lector de pantalla, navegando con el teclado o intentando completar una tarea real.<\/p>\n

Lo que si puede hacer es impedir que olvidemos autom\u00e1ticamente algunas de las cosas que ya hab\u00edamos aprendido a hacer bien.<\/p>\n

Una estrategia madura de accesibilidad combina esas capas. Automatiza aquello que puede expresarse mediante reglas y comportamientos verificables, utiliza pruebas manuales para explorar lo que necesita interpretaci\u00f3n y recurre a personas con discapacidad para conocer la experiencia que ning\u00fan conjunto de aserciones puede reproducir.<\/p>\n

Las pruebas automatizadas no son el destino de la accesibilidad. Son una forma de evitar que, mientras avanzamos, deshagamos parte del camino recorrido.<\/p>\n","protected":false},"excerpt":{"rendered":"

En el mundo del desarrollo de software una funcionalidad que hoy funciona puede dejar de hacerlo ma\u00f1ana despu\u00e9s de una modificaci\u00f3n aparentemente inocente. Para evitar este problema se crean las pruebas automatizadas para mantener la funcionalidad y la forma de utilizar una interfaz de usuario. La accesibilidad deber\u00eda formar parte de esas pruebas para garantizar … <\/p>\n

Continuar leyendo \u00abGarantizar la accesibilidad con pruebas automatizadas\u00bb<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,4,5],"tags":[11,559,453,94],"class_list":["post-1380","post","type-post","status-publish","format-standard","hentry","category-accesibilidad","category-desarrollo","category-diseno","tag-accesibilidad-2","tag-pruebas","tag-tests","tag-web"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/programaraciegas.net\/index.php?rest_route=\/wp\/v2\/posts\/1380","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/programaraciegas.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/programaraciegas.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/programaraciegas.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/programaraciegas.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1380"}],"version-history":[{"count":0,"href":"https:\/\/programaraciegas.net\/index.php?rest_route=\/wp\/v2\/posts\/1380\/revisions"}],"wp:attachment":[{"href":"https:\/\/programaraciegas.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1380"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/programaraciegas.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1380"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/programaraciegas.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1380"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}