Después de un tiempo de ausencia, Accesible Othello vuelve a estar disponible en la App Store y sigue estando disponible para iPhone y iPad.
El juego, internamente, ha sufrido una renovación profunda. El código ha sido actualizado y rehecho para adaptarlo a las tecnologías actuales de Apple y utilizar las últimas versiones de sus librerías. El objetivo no ha sido únicamente recuperar el juego, sino construir una base renovada sobre la que pueda seguir evolucionando.
La nueva versión mantiene la esencia de Accesible Othello y presta una atención especial a uno de sus principios fundamentales: la accesibilidad. Se han incorporado nuevas características destinadas a facilitar el uso del juego y a ofrecer una experiencia más adaptable a las distintas necesidades de los usuarios.
También se han ampliado las posibilidades de personalización, permitiendo configurar diferentes aspectos de la experiencia de juego. La intención es que cada usuario pueda ajustar el juego de la forma que le resulte más cómoda y adecuada.
Esta actualización implica algo más que la vuelta de Accesible Othello a la App Store. Es una renovación técnica y funcional que permite recuperar el proyecto sobre una base moderna, manteniendo su compromiso con la accesibilidad y ampliando las posibilidades para adaptar la experiencia a cada jugador.
Puedes obtener Accessible Othello en la AppStore.
Garantizar la accesibilidad con pruebas automatizadas
En el mundo del desarrollo de software una funcionalidad que hoy funciona puede dejar de hacerlo mañana después de una modificación 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ía formar parte de esas pruebas para garantizar que todos los usuarios pueden acceder a la funcionalidad.
Sin embargo, todavía es frecuente tratarla como una actividad posterior al desarrollo. Primero se construye la interfaz, después se comprueba si funciona y, en algún momento, alguien ejecuta una herramienta de accesibilidad o realiza una auditoría. El problema de este planteamiento es que convierte la accesibilidad en una fotografía puntual cuando debería ser una propiedad del software que intentamos conservar durante toda su vida.
La automatización de las pruebas puede ayudar a garantizar y mantener esa accesibilidad.
Como explica Marcy Sutton en Writing Automated Tests for Accessibility, las pruebas automáticas no pueden descubrir todos los problemas de accesibilidad. Tampoco sustituyen las pruebas manuales ni las realizadas con personas con discapacidad. Su utilidad está en otro lugar: permiten comprobar de manera sistemática aquello que una máquina sí puede verificar y, sobre todo, detectar regresiones antes de que lleguen a producción.
La accesibilidad también puede sufrir regresiones
Una regresión aparece cuando una modificación introduce un problema en algo que anteriormente funcionaba.
Si una función debe devolver un determinado resultado para una entrada concreta, podemos escribir una prueba que establezca ese comportamiento. Cada vez que alguien modifique el código, la prueba volverá a ejecutarse.
Con la accesibilidad sucede exactamente lo mismo. Un botón puede tener hoy un nombre accesible y perderlo durante una refactorización. Un diálogo puede devolver correctamente el foco al elemento que lo abrió hasta que alguien modifica su implementación. Un componente de pestañas puede responder a las flechas del teclado y dejar de hacerlo después de actualizar una dependencia.
La interfaz puede parecer idéntica. Para una persona que utiliza el ratón puede incluso continuar funcionando con normalidad. Pero para otros usuarios el cambio puede haber roto una parte esencial de la aplicación.
Las pruebas automatizadas permiten convertir algunos de esos requisitos de accesibilidad en condiciones verificables. En lugar de confiar únicamente en que nadie elimine accidentalmente un comportamiento accesible, podemos hacer que el propio proyecto compruebe su existencia.
Automatizar no significa automatizarlo todo
La accesibilidad no puede reducirse a obtener un informe sin errores de una herramienta automática.
Una máquina puede comprobar determinadas propiedades del código y del documento. Puede encontrar ciertos usos incorrectos de ARIA, detectar algunos problemas de contraste, analizar etiquetas o identificar errores en la estructura HTML. También podemos escribir nuestras propias pruebas para comprobar el comportamiento de componentes concretos.
Pero existen preguntas mucho más difíciles.
¿Tiene sentido el orden de lectura? ¿Es comprensible el texto alternativo de una imagen dentro de su contexto? ¿Resulta sencillo completar una tarea utilizando un lector de pantalla? ¿Es predecible la gestión del foco? ¿Puede una persona comprender un mensaje de error y recuperarse de él?
No todas estas cuestiones pueden resolverse observando el DOM y aplicando un conjunto de reglas.
La automatización, por tanto, no debería entenderse como un sustituto de las pruebas de accesibilidad realizadas por personas. Es una capa adicional dentro de una estrategia más amplia.
Su ventaja consiste precisamente en encargarse de las comprobaciones repetibles para que el tiempo humano pueda dedicarse a aquello que exige interpretación, experiencia y contexto.
Probar resultados en lugar de implementaciones
Una buena prueba automatizada debería sobrevivir, dentro de lo razonable, a los cambios internos del software.
Las pruebas deberían concentrarse en el resultado esperado y no en los detalles de implementación.
Supongamos que tenemos un componente que muestra un diálogo. Desde el punto de vista de quien utiliza la interfaz, lo importante no es qué funciones internas se ejecutan ni qué variables cambian de valor. Lo que importa es que el diálogo 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ón coherente.
Una prueba demasiado vinculada a la implementación 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áculo. Finalmente alguien las desactiva o las elimina.
Una prueba centrada en el comportamiento expresa algo diferente: mientras esta funcionalidad exista, esta propiedad debe seguir cumpliéndose.
En accesibilidad, esa diferencia es particularmente valiosa porque transforma ciertos requisitos en parte del contrato del componente.
El teclado como parte de las pruebas
El teclado es una de las herramientas más sencillas para comenzar a evaluar la accesibilidad de una interfaz.
Podemos recorrer una página utilizando la tecla Tab, comprobar si alcanzamos los controles interactivos, observar si el foco resulta visible y verificar si podemos realizar una tarea sin recurrir al ratón.
Una parte de ese comportamiento también puede incorporarse a las pruebas automatizadas.
Un diálogo puede tener una prueba que compruebe que Escape permite cerrarlo. Un menú puede verificar el funcionamiento de las teclas de dirección. Un componente de pestañas puede comprobar que el foco se desplaza de acuerdo con el patrón de interacción previsto.
Esto resulta especialmente interesante porque la accesibilidad deja de estar asociada únicamente al marcado HTML.
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ámica depende tanto de la información que exponemos como de las interacciones que permitimos realizar.
Las pruebas de integración son especialmente adecuadas para muchas de estas comprobaciones, ya que el foco y la interacción suelen atravesar los límites de un único componente.
Pruebas unitarias y pruebas de integración
No todas las pruebas de accesibilidad tienen que ejecutarse al mismo nivel.
Una prueba unitaria puede comprobar una pieza aislada del sistema. Por ejemplo, que determinada propiedad proporcionada a un componente termine convirtiéndose en el nombre accesible de un botón.
Este tipo de prueba es rápida y permite verificar problemas concretos.
Las pruebas de integración permiten observar un escenario más amplio. Podemos cargar una interfaz, simular una interacción con el teclado y comprobar qué elemento recibe el foco después de una determinada acción.
Las pruebas de extremo a extremo llevan esta idea todavía más lejos, reproduciendo recorridos próximos a los de una persona que utiliza la aplicación.
No existe un único nivel correcto para probar la accesibilidad. La elección depende de aquello que queremos garantizar.
Si nos interesa comprobar que una API transmite correctamente determinada información de accesibilidad, una prueba unitaria puede ser suficiente. Si queremos saber qué sucede con el foco después de abrir y cerrar varios componentes, necesitaremos observar una porción mayor de la aplicación.
Incorporar motores de accesibilidad
Además de escribir pruebas específicas para nuestros componentes, podemos incorporar motores especializados en detectar automáticamente problemas de accesibilidad.
Uno de los más conocidos es axe-core, desarrollado por Deque. Puede integrarse con distintos entornos de pruebas para analizar un componente, una página o un estado determinado de la aplicación.
La idea es sencilla. La prueba presenta una interfaz al motor de accesibilidad, ejecuta el análisis y comprueba los resultados obtenidos. Si aparecen determinadas infracciones, la prueba puede fallar.
Esto permite trasladar algunas comprobaciones al mismo lugar en el que ya verificamos el resto del software.
En lugar de esperar a una auditoría posterior, una modificación que introduzca ciertos errores puede provocar un fallo durante la integración continua. El problema aparece entonces mucho más cerca del momento en que fue introducido.
Esta proximidad tiene una ventaja práctica considerable. Corregir un error cuando todavía estamos trabajando en el componente suele ser más sencillo que descubrirlo semanas después, cuando el código ya se encuentra integrado con otras partes del sistema.
Probar los estados, no solamente las páginas
Las aplicaciones web modernas cambian constantemente de estado. Un menú cerrado no contiene necesariamente los mismos elementos visibles que un menú abierto. Un diálogo puede no existir en el DOM hasta que alguien pulsa un botón. Un formulario puede mostrar mensajes adicionales después de una validación. Un acordeón oculta información hasta que se expande.
Todo esto plantea un problema para las herramientas automáticas: solo pueden analizar aquello que existe en el estado que les presentamos.
Ejecutar un análisis de accesibilidad inmediatamente después de cargar una página puede dejar fuera una parte considerable de la interfaz.
Por esta razón las pruebas automáticas deberían recorrer los estados significativos.
Podemos analizar la página inicialmente, abrir después un diálogo y volver a analizarla. Podemos desplegar un menú, provocar los errores de un formulario o mostrar contenido que inicialmente estaba oculto.
La unidad de accesibilidad que nos interesa comprobar no siempre es la página. En una aplicación dinámica, muchas veces es el estado de la interfaz.
Accesibilidad dentro de la integración continua
Cuando estas pruebas forman parte de la ejecución habitual del proyecto, la accesibilidad entra también en el proceso de integración continua.
Una auditoría periódica nos dice qué problemas existen en un momento determinado. Una prueba automática puede impedir que ciertos problemas conocidos vuelvan a introducirse.
La diferencia es parecida a la que existe entre inspeccionar periódicamente si una puerta permanece cerrada e instalar un mecanismo que avise cada vez que alguien la deja abierta.
La segunda opción tampoco garantiza que el edificio sea seguro. Pero convierte una condición concreta en algo que se vigila continuamente.
Con la accesibilidad podemos hacer lo mismo. No podremos automatizar toda la experiencia de una persona, pero sí establecer determinadas condiciones que el software no debería incumplir.
El peligro de confiar demasiado en el resultado
Existe una consecuencia incómoda al automatizar la accesibilidad que consiste en que podemos empezar a confiar demasiado en aquello que hemos automatizado.
Una batería de pruebas sin errores no demuestra que un producto sea accesible. Más bien demuestra que ha superado las comprobaciones que hemos decidido ejecutar.
Las herramientas automáticas trabajan con reglas que pueden evaluarse mediante software. La experiencia de una persona utilizando una interfaz es considerablemente más compleja. Un sitio puede superar todas las comprobaciones automáticas y continuar presentando obstáculos importantes. Por esta razón las pruebas manuales siguen siendo necesarias.
Utilizar únicamente el teclado, probar con lectores de pantalla, comprobar diferentes niveles de ampliación, observar el comportamiento en dispositivos móviles y estudiar la experiencia con distintas tecnologías de apoyo permiten encontrar problemas que difícilmente aparecerán en una comprobación automática.
Además de todo esto deberíamos probar con personas.
Se puede comprobar técnicamente que un componente sigue un patrón accesible y descubrir después que resulta confuso durante una tarea real. Cumplimiento técnico y usabilidad están relacionados, pero no son equivalentes.
Automatizar para reservar tiempo para las personas
El objetivo final de automatizar las pruebas de accesibilidad no debería ser eliminar la intervención humana, sino utilizarla mejor.
Hay comprobaciones que una máquina puede repetir cientos de veces con un coste muy pequeño. No tiene demasiado sentido pedir a una persona que las realice manualmente en cada modificación si podemos convertirlas en pruebas fiables.
Ese tiempo puede dedicarse a cuestiones que necesitan criterio humano.
La automatización también 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ás pueden olvidarse. Una prueba permanece junto al código recordando que determinado comportamiento no es accidental.
Si alguien implementó correctamente la gestión del foco de un diálogo, una prueba puede conservar esa decisión mucho después de que se haya olvidado la conversación que la originó.
La accesibilidad como propiedad del software
Cuando escribimos una prueba para una característica de accesibilidad estamos diciendo que ese comportamiento forma parte del producto.
No es una mejora opcional que comprobaremos al final. No es una característica externa al código. Es una condición que esperamos que siga siendo cierta después de cada modificación.
La automatización no puede decirnos que una aplicación es accesible. Tampoco puede sustituir a una persona utilizando un lector de pantalla, navegando con el teclado o intentando completar una tarea real.
Lo que si puede hacer es impedir que olvidemos automáticamente algunas de las cosas que ya habíamos aprendido a hacer bien.
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ón y recurre a personas con discapacidad para conocer la experiencia que ningún conjunto de aserciones puede reproducir.
Las pruebas automatizadas no son el destino de la accesibilidad. Son una forma de evitar que, mientras avanzamos, deshagamos parte del camino recorrido.
Participación en AliBlueBox en el día mundial del videojuego
El pasado 29 de agosto participé en el canal de AliBlueBox en una entrevista donde hablé con Alicia sobre accesibilidad, videojuegos y Vibecoding.
La IA como oportunidad de crear con más accesibilidad y más rapidez
Hablamos de muchos temas siempre sobre tecnología y accesibilidad y, con el videojuego como hilo argumental, aproveché para presentar mi próximo juego: Boat hunter, un juego arcade donde pilotas un barco de guerra por el océano Atlántico buscando barcos enemigos a los que hundir.
Puedes ver la entrevista en AliBlueBox en Youtube.
ColorSym: un estándar abierto para identificar colores de forma accesible
Dentro de las barreras de accesibilidad más comunes que aparecen en las diversas páginas web e interfaces digitales está la de la dependencia exclusiva del color para transmitir información.
Cuando un gráfico distingue categorías únicamente mediante colores, cuando un tablero de juego identifica sus piezas por el color o cuando una interfaz utiliza el rojo y el verde como única referencia visual, una parte importante de la población encuentra dificultades para interpretar esa información.
ColorSym nace precisamente para resolver este problema.
El problema de depender únicamente del color
Se estima que alrededor del 5 % de la población mundial presenta algún tipo de deficiencia en la visión del color. Esto supone aproximadamente 300 millones de personas. En el caso de los hombres, la proporción ronda uno de cada doce. En las mujeres es menos frecuente, aproximadamente una de cada doscientas.
Aunque las Pautas de Accesibilidad para el Contenido Web (WCAG) llevan años indicando que el color no debe ser el único medio para transmitir información, en la práctica sigue siendo una situación muy habitual. Formularios que marcan errores únicamente en rojo, mapas con leyendas exclusivamente cromáticas, diagramas, interfaces o productos físicos continúan utilizando el color como único identificador.
La solución habitual consiste en añadir texto, iconos o patrones, pero no existe un sistema universal que permita representar los colores de forma consistente.
Qué es ColorSym
ColorSym es un proyecto de código abierto que propone un sistema de símbolos para representar colores de forma que las personas con ceguera al color puedan distinguir entre esos elementos en los que el color es necesario para entender su significado.
Cada color dispone de un símbolo propio que puede acompañar al color visual. De esta forma, una persona que no pueda distinguir correctamente determinados colores sigue siendo capaz de identificarlos mediante el símbolo asociado.
Este proyecto no pretende sustituir al color, sino complementarlo. Esta aproximación resulta especialmente interesante porque puede utilizarse tanto en soportes digitales como impresos sin modificar la apariencia general del diseño.
Un sistema basado en reglas simples
Uno de los aspectos más interesantes de ColorSym es que no asigna símbolos arbitrarios.
El sistema parte de tres símbolos básicos correspondientes a los colores primarios. A partir de ellos se generan el resto de colores mediante combinaciones visuales de los símbolos originales.
Por ejemplo, el símbolo del naranja combina los elementos que representan al rojo y al amarillo. El verde combina los correspondientes al amarillo y al azul. El mismo principio se aplica al resto de colores compuestos.
Este enfoque hace que el sistema resulte mucho más fácil de aprender que un conjunto de iconos independientes.
Además, los símbolos han sido diseñados para ser reconocibles independientemente de su orientación, una característica especialmente útil en aplicaciones donde los elementos pueden rotarse, como ocurre en juegos de mesa o determinadas interfaces.
Un proyecto pensado para ser reutilizado
ColorSym se distribuye como proyecto abierto. Los símbolos pueden utilizarse tanto en proyectos comerciales como personales, y además se ofrece una tipografía específica que permite escribir los símbolos directamente desde el teclado.
Incluso las combinaciones de colores funcionan mediante ligaduras tipográficas: al escribir los identificadores de dos colores primarios, la fuente genera automáticamente el símbolo correspondiente al color resultante.
El proyecto también anima a crear nuevas variantes tipográficas manteniendo el mismo sistema de símbolos, favoreciendo así su adopción en distintos contextos gráficos.
Aunque el proyecto nació en el ámbito de los juegos de mesa, su utilidad va mucho más allá. Puede incorporarse en aplicaciones móviles y de escritorio para complementar estados codificados mediante colores, en gráficos y visualizaciones de datos, en señalización, en material educativo, en envases de productos o incluso en sistemas de clasificación documental. En todos estos casos el objetivo es el mismo: evitar que el significado dependa exclusivamente de la percepción del color.
Este planteamiento coincide con una de las recomendaciones fundamentales de las WCAG, que establecen que la información nunca debería comunicarse únicamente mediante diferencias cromáticas.
A11yConf 2026 abre su convocatoria de propuestas para charlas y talleres sobre accesibilidad digital
La organización de A11yConf 2026 ha abierto el plazo para presentar propuestas de participación en la próxima edición de la conferencia, que se celebrará el sábado 28 de noviembre de 2026 en Zaragoza.
La convocatoria está dirigida a personas interesadas en compartir conocimientos, proyectos, iniciativas y experiencias relacionadas con la accesibilidad digital. Las propuestas podrán enviarse hasta las 23:59 del 16 de agosto de 2026 mediante el formulario disponible en la web oficial de A11yConf 2026.
Charlas y talleres sobre accesibilidad digital
El programa de la conferencia se distribuirá en dos espacios simultáneos dedicados a charlas y un tercer espacio destinado a talleres.
Las charlas tendrán una duración aproximada de 45 minutos. Los talleres podrán presentarse en dos modalidades: un formato breve de alrededor de 60 minutos y otro más extenso de aproximadamente 90 minutos.
La organización busca propuestas técnicas relacionadas con el diseño, la programación y el uso de la tecnología, así como contenidos centrados en otras áreas vinculadas con la accesibilidad digital.
También se valorarán iniciativas, proyectos y experiencias que contribuyan a sensibilizar sobre la importancia de la accesibilidad y a promover la creación de productos, servicios y entornos digitales que puedan ser utilizados por el mayor número posible de personas.
Una convocatoria abierta a nuevos perfiles
No es necesario contar con experiencia previa como ponente para participar en la convocatoria. A11yConf 2026 dispone de un programa de mentoría destinado a quienes necesiten apoyo para desarrollar su idea, estructurar la propuesta o preparar la presentación.
Las personas interesadas en recibir este acompañamiento podrán indicarlo en el formulario de participación. La iniciativa pretende facilitar la incorporación de nuevas voces y ampliar la diversidad de experiencias y conocimientos presentes en la conferencia.
Las propuestas seleccionadas deberán presentarse presencialmente durante el evento. La organización cubrirá los gastos de desplazamiento y alojamiento de las personas elegidas para participar como ponentes.
Nace el panel de expertos en entornos inclusivos
El Panel de Expertos en Entornos Inclusivos se ha constituido como una asociación privada y sin ánimo de lucro orientada al análisis, el debate y la difusión de propuestas relacionadas con la accesibilidad universal.
La iniciativa comenzó su actividad el 15 de abril de 2026 y reúne a quince especialistas procedentes de distintos ámbitos profesionales.
La finalidad del Panel es generar un espacio independiente en el que puedan abordarse cuestiones prácticas, técnicas y estratégicas vinculadas con la creación de entornos, productos y servicios accesibles.
Sus integrantes participan a título personal y no representan a las empresas, administraciones u organizaciones con las que mantienen vínculos profesionales.
Esta independencia constituye uno de los principios centrales de la iniciativa.
El Panel busca favorecer un análisis crítico basado en la experiencia profesional, el rigor técnico y la pluralidad de perspectivas, sin subordinación a intereses corporativos, institucionales o políticos.
Un foro para el análisis y la formulación de propuestas
La actividad del Panel se desarrolla a través de debates periódicos sobre accesibilidad universal.
En el futuro se prevé la publicación de conclusiones y recomendaciones dirigidas a la sociedad civil, los medios de comunicación, las empresas y los poderes públicos.
Entre sus propósitos se encuentra contribuir a la formación de una opinión pública informada, trasladar recomendaciones concretas a entidades públicas y privadas y analizar aquellos problemas que dificultan la aplicación efectiva de la accesibilidad.
El Panel también aspira a actuar como espacio de referencia para el intercambio de conocimiento y la evaluación crítica de políticas, proyectos y prácticas profesionales.
Una visión transversal de la accesibilidad universal
El proyecto parte de la consideración de la accesibilidad universal como una condición necesaria para el ejercicio efectivo de los derechos fundamentales. Desde este planteamiento, la accesibilidad no se limita al cumplimiento de requisitos técnicos o normativos, sino que se relaciona con la igualdad, la no discriminación, la dignidad humana y la participación plena de todas las personas.
El manifiesto fundacional del Panel se articula en torno a diez principios, entre los que se encuentran la igualdad, el diseño universal, la independencia, la pluralidad, la transparencia, la innovación y la responsabilidad cívica.
Asimismo, la accesibilidad se analiza desde seis dimensiones interrelacionadas: como instrumento para el ejercicio de derechos, factor de calidad, motor de innovación social, oportunidad económica y profesional, elemento vinculado con la sostenibilidad y expresión de justicia social.
Un equipo multidisciplinar
El Panel está formado por quince profesionales con experiencia en campos como la accesibilidad universal, el diseño inclusivo, los entornos digitales, la arquitectura, la educación, la empresa y la sociedad civil.
La diversidad de perfiles busca facilitar un análisis transversal de los obstáculos que afectan a la participación de las personas con discapacidad y de las medidas necesarias para eliminarlos. También permite estudiar la accesibilidad desde perspectivas complementarias, incluyendo sus implicaciones sociales, jurídicas, tecnológicas, económicas y organizativas.
Con la creación del Panel de Expertos en Entornos Inclusivos se establece un nuevo espacio de reflexión destinado a promover el conocimiento, el diálogo y la formulación de propuestas sobre accesibilidad universal.
Su actividad, documentación y próximos debates estarán disponibles en su página web del proyecto.