AccIA: Accesibilidad Cognitiva en la Era de las IAs 2.0 PDF Free Download
1 / 104
/104
100%
Calificación: 5.0
AccIA: Accesibilidad Cognitiva en la Era de las
IAs 2.0
AccIA: Cognitive Accessibility in the Age of AIs
2.0
Trabajo de Fin de Grado
Curso 2024–2025
Autora
Eloísa Rodríguez Sotelo
Directoras
Virginia Francisco Gilmartín
Raquel Hervás Ballesteros
Grado en Ingeniería Informática
Facultad de Informática
Universidad Complutense de Madrid
AccIA: Accesibilidad Cognitiva en la Era
de las IAs 2.0
AccIA: Cognitive Accessibility in the Age
of AIs 2.0
Trabajo de Fin de Grado en Ingeniería Informática
Autora
Eloísa Rodríguez Sotelo
Directoras
Virginia Francisco Gilmartín
Raquel Hervás Ballesteros
Convocatoria: Septiembre 2025
Grado en Ingeniería Informática
Facultad de Informática
Universidad Complutense de Madrid
09 de SEPTIEMBRE de 2025
Dedicatoria
A mi familia por estar a mi lado y ser mi
mayor pilar
v
Agradecimientos
Quiero expresar mi más sincero agradecimiento a todas las personas que han
contribuido, de una u otra forma, a que este Trabajo de Fin de Grado sea posible.
En primer lugar, agradecer a mis tutoras Virginia y Raquel, por su constante
guía, paciencia y dedicación. Sus consejos y su apoyo técnico y humano han sido
fundamentales para superar los retos que surgieron a lo largo del desarrollo.
A mis amigos y familia, por estar siempre presentes, animarme en los momentos
difíciles y celebrar conmigo cada pequeño logro. Gracias por su apoyo incondicional
y por recordarme siempre la importancia de seguir aprendiendo y creciendo.
De manera especial, dedico este trabajo a todas las personas con discapacidad
cognitiva y a quienes trabajan por una sociedad más inclusiva y accesible. Son su
esfuerzo y su ejemplo los que nos han inspirado a desarrollar un proyecto centrado
en la accesibilidad y la empatía.
Finalmente, gracias a todas las personas que han creído en mí y que han hecho
posible este camino. Sin su apoyo, este proyecto no habría sido el mismo.
vii
Resumen
AccIA: Accesibilidad Cognitiva en la Era de las IAs
2.0
Este Trabajo de Fin de Grado aborda la insuficiente accesibilidad cognitiva en
aplicaciones de Inteligencia Artificial Generativa, que, pese a sus avances, suelen ig-
norar las necesidades de personas con discapacidad intelectual limitando su inclusión
y autonomía digital. Como punto de partida se tomó OlivIA 1.0, una primera versión
del asistente conversacional orientado a la accesibilidad. Esta aplicación web había
sido diseñada específicamente para personas con discapacidad intelectual, ofreciendo
una interfaz sencilla que reducía la sobrecarga cognitiva y favorecía la comprensión.
Para lograrlo, incluía un cuestionario inicial que permitía personalizar la experiencia
en función de las preferencias y necesidades de cada usuario, además de un sistema
de plantillas de preguntas y botones de ayuda que facilitaban tanto la formulación
de consultas como la interacción con las respuestas generadas. Gracias a estas ca-
racterísticas, OlivIA 1.0 sentó las bases de una comunicación más clara y adaptada,
constituyendo el punto de partida.
En esta segunda versión, OlivIA 2.0 amplía las funcionalidades de la aplicación
con el objetivo de ofrecer una interacción todavía más accesible y personalizada. Una
de las principales incorporaciones es la generación de respuestas mediante pictogra-
mas, que transforma el texto en representaciones visuales y facilita así la comprensión
de la información. También se ha desarrollado un sistema de sugerencia automática
de preguntas, capaz de analizar el contexto y apoyar a usuarios con menor iniciativa
comunicativa. Además, integra un mecanismo de evaluación de la ambigüedad en las
consultas y un asistente que solicita información adicional con el fin de proponer las
preguntas más probables. Junto a estas mejoras, se ha incorporado la entrada por
voz, que permite formular consultas oralmente y elimina la necesidad de recurrir al
teclado.
En cuanto a la accesibilidad, el desarrollo ha seguido las pautas de la WCAG
2.2 y las recomendaciones cognitivas del grupo COGA, combinando evaluaciones
automáticas y manuales que han permitido validar el nivel alcanzado.
De cara al futuro, se plantea ampliar el vocabulario visual con nuevos pictogra-
mas, incluidos recursos propios, optimizar el motor de IA mediante modelos adap-
tativos y aplicar un perfilado dinámico que refine la personalización. Asimismo, se
ix
prevé la realización de pruebas piloto con validación participativa, así como la in-
corporación de soporte multilingüe y de mecanismos de adaptación cultural para
extender el alcance de la aplicación a un público más diverso.
Palabras clave
Accesibilidad, discapacidad intelectual, Inteligencia Artificial Generativa (IAG),
pictogramas, WCAG, inclusión, asistentes virtuales.
Abstract
AccIA: Cognitive Accessibility in the Age of AIs 2.0
This Bachelor’s Thesis addresses the issue of insufficient cognitive accessibility
in Generative Artificial Intelligence applications which, despite their advances, of-
ten overlook the needs of people with intellectual disabilities, thereby limiting their
inclusion and digital autonomy. As a starting point, OlivIA 1.0 was taken, a first
version of the conversational assistant oriented toward accessibility. This web ap-
plication was specifically designed for people with intellectual disabilities, offering a
simple interface that reduced cognitive overload and supported comprehension. To
achieve this, it included an initial questionnaire that allowed the experience to be
personalized according to each user’s preferences and needs, as well as a system of
question templates and help buttons that facilitated both the formulation of queries
and the interaction with generated responses. Thanks to these features, OlivIA 1.0
laid the foundation for clearer and more adapted communication, serving as the
point of departure.
In this second version, OlivIA 2.0 expands the application’s functionalities with
the aim of offering an even more accessible and personalized interaction. One of the
main additions is the generation of responses through pictograms, which transforms
text into visual representations and thus facilitates comprehension of information.
A system of automatic question suggestion has also been developed, capable of
analyzing context and supporting users with lower communicative initiative. In
addition, it integrates a mechanism for evaluating query ambiguity and an assistant
that requests additional information in order to propose the most likely questions.
Alongside these improvements, voice input has been incorporated, allowing users to
formulate queries orally and removing the need to rely on a keyboard.
With regard to accessibility, the development has followed the WCAG 2.2 guide-
lines and the cognitive recommendations of the COGA group, combining automatic
and manual evaluations that have validated the achieved level.
Looking ahead, the project plans to expand the visual vocabulary with new pic-
tograms, including proprietary resources, optimize the AI engine through adaptive
models, and apply dynamic profiling to refine personalization. Furthermore, pilot
tests with participatory validation are foreseen, as well as the incorporation of mul-
tilingual support and cultural adaptation mechanisms to extend the reach of the
xi
application to a more diverse audience.
Keywords
Accessibility, intellectual disability, Generative AI (GenAI), pictograms, WCAG,
inclusion, virtual assistants.
Índice
1. Introducción 1
1.1. Motivación................................. 1
1.2. Objetivos ................................. 2
1.3. PlandeTrabajo.............................. 3
1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . 4
Introduction 7
1.1. Motivation................................. 7
1.2. Objectives................................. 8
1.3. WorkPlan................................. 9
1.4. Structure of the document . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Estado del arte 11
2.1. Discapacidad intelectual y barreras digitales . . . . . . . . . . . . . . 11
2.2. Accesibilidadweb............................. 12
2.2.1. Accesibilidad cognitiva . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2. Evaluación de la accesibilidad web . . . . . . . . . . . . . . . . 16
2.2.3. WAVE (Web Accessibility Evaluation Tool) . . . . . . . . . . 16
2.2.4. Google Lighthouse . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.5. Pa11y y Pa11y Dashboard . . . . . . . . . . . . . . . . . . . . 18
2.2.6. axeDevTools ........................... 19
2.2.7. SortSite .............................. 20
2.2.8. DYNOMapper .......................... 22
2.2.9. AChecker ............................. 22
2.2.10.Conclusiones ........................... 24
2.3. APIs de reconocimiento de voz . . . . . . . . . . . . . . . . . . . . . . 25
2.4. Pictogramas................................ 25
2.5. OlivIA1.0................................. 27
2.5.1. Obtención de requisitos . . . . . . . . . . . . . . . . . . . . . . 27
2.5.2. Proceso de diseño . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.3. Arquitectura............................ 29
2.5.4. Funcionalidades implementadas . . . . . . . . . . . . . . . . . 31
xiii
2.5.5. Generación de prompts en OlivIA 1.0 .............. 34
2.5.6. Limitaciones y elementos pendientes en OlivIA 1.0. ...... 35
3. OlivIA 2.0 37
3.1. Evaluación de la accesibilidad . . . . . . . . . . . . . . . . . . . . . . 37
3.1.1. Evaluación automática con WAVE . . . . . . . . . . . . . . . 38
3.1.2. Evaluación manual . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2. Ampliaciones y mejoras en la nueva versión de OlivIA . . . . . . . . . 49
3.2.1. Respuestas con pictogramas . . . . . . . . . . . . . . . . . . . 50
3.2.2. Asistente de preguntas . . . . . . . . . . . . . . . . . . . . . . 53
3.2.3. Entradaporvoz.......................... 57
3.3. Evaluación de la accesibilidad de OlivIA 2.0 . . . . . . . . . . . . . . 60
4. Conclusiones y líneas de trabajo futuro 65
4.1. Conclusiones del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2. Líneas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . 66
Conclusions and Future Work 69
4.1. Conclusions ................................ 69
4.2. FutureWork................................ 70
Bibliografía 71
A. Capturas de pantalla análisis automático con WAVE 77
Índice de figuras
2.1. Interfaz de WAVE mostrando el análisis de accesibilidad sobre la
página principal de ChatGPT. . . . . . . . . . . . . . . . . . . . . . . 18
2.2. Interfaz de Google Lighthouse mostrando el análisis de accesibilidad
sobre la página principal de ChatGPT. . . . . . . . . . . . . . . . . . 19
2.3. Interfaz de Pa11y mostrando el análisis de accesibilidad sobre la
página principal de ChatGPT. . . . . . . . . . . . . . . . . . . . . . . 20
2.4. Interfaz de axe DevTools mostrando el análisis de accesibilidad sobre
la página principal de ChatGPT. . . . . . . . . . . . . . . . . . . . . 21
2.5. Interfaz de SortSite mostrando el análisis de accesibilidad sobre la
página principal de ChatGPT. . . . . . . . . . . . . . . . . . . . . . . 21
2.6. Interfaz de DYNO Mapper mostrando el análisis de accesibilidad so-
bre la página principal de Gemini. . . . . . . . . . . . . . . . . . . . . 22
2.7. Interfaz de AChecker mostrando el análisis de accesibilidad sobre la
página principal de ChatGPT. . . . . . . . . . . . . . . . . . . . . . . 23
2.8. Matriz de pictogramas ARASAAC en una interfaz web. . . . . . . . . 27
2.9. Diagrama de cliente y APIs de OlivIA 1.0. Fuente: Amar (2025). . . 30
2.10. Cuestionario inicial de personalización de discapacidad intelectual ne
OlivIA1.0................................. 32
2.11. Cuestionario inicial de personalización de dificultades de comprensión
enOlivIA1.0 ............................... 32
2.12. Cuestionario inicial de personalización de preferencias de respuestas
enOlivIA1.0 ............................... 33
2.13. Página inicial que muestra el diseño visual accesible en OlivIA 1.0 . . 33
3.1. Pantalla del paso 1 del cuestionario personalizado en OlivIA. . . . . . 42
3.2. Pantalla del paso 2 del cuestionario de configuración en OlivIA. . . . 44
3.3. Pantalla del paso 3 del cuestionario de configuración en OlivIA. . . . 45
3.4. Pantalla final de resumen de configuración en OlivIA.......... 46
3.5. Pantalla de entrada con preguntas en OlivIA. ............. 47
3.6. Pantalla de respuesta de OlivIA en modo conversacional. . . . . . . . 48
3.7. Flujograma del proceso de conversión de texto a pictogramas . . . . . 54
3.8. Ejemplo visual de como se muestran las respuestas en pictogramas en
OlivIA................................... 55
xv
3.9. Generador de preguntas de OlivIA. ................... 56
3.10. Pantalla de interacción en la que se solicita información adicional al
usuario y se presentan reformulaciones sugeridas. . . . . . . . . . . . 58
3.11. Pantalla principal donde se muestra la disposición de los botones . . . 60
3.12. Análisis con WAVE de la pantalla de selección rápida de preguntas. . 61
3.13. Análisis con WAVE de la pantalla de selección rápida de preguntas
corregida. ................................. 62
3.14. Análisis con WAVE de la pantalla de Chat con la incorporación de la
la generación de nuevas preguntas en base a una idea. . . . . . . . . . 62
3.15. Análisis con WAVE de la pantalla de Chat con la incorporación de la
evaluación de la ambigüedad y la generación de nuevas preguntas. . . 63
A.1. Análisis con WAVE de la pantalla de inicio de OlivIA (versión inicial). 78
A.2. Análisis con WAVE de la pantalla de inicio tras las mejoras imple-
mentadas. ................................. 78
A.3. Análisis con WAVE del paso 1 del cuestionario (versión inicial). . . . 79
A.4. Análisis con WAVE del paso 1 del cuestionario tras mejoras. . . . . . 79
A.5. Análisis con WAVE del paso 2 del cuestionario (versión inicial). . . . 79
A.6. Análisis con WAVE del paso 2 tras las mejoras. . . . . . . . . . . . . 80
A.7. Análisis con WAVE del paso 3 del cuestionario (versión inicial). . . . 80
A.8. Análisis con WAVE del paso 3 tras las mejoras. . . . . . . . . . . . . 80
A.9. Análisis con WAVE de la pantalla final del cuestionario (versión inicial). 81
A.10.Análisis con WAVE de la pantalla final tras las mejoras. . . . . . . . 81
A.11.Análisis con WAVE de la pantalla de preguntas (versión inicial). . . . 81
A.12.Análisis con WAVE de la pantalla de preguntas tras mejoras. . . . . . 82
A.13.Pantalla de inicio del proceso de configuración personalizada en OlivIA. 82
A.14.Análisis con WAVE de la pantalla de chat (versión inicial). . . . . . . 82
A.15.Análisis con WAVE de la pantalla de chat tras mejoras. . . . . . . . . 83
Cap´
ıtulo 1
Introducción
“No hay puerta, ni cerradura, ni cerrojo que pueda
imponerse a la libertad de mi mente.”
— Virginia Woolf
El Capítulo 1 de este documento introduce el Trabajo de Fin de Grado y se
organiza en varias secciones. En la Sección 1.1 se expone la motivación que ha dado
lugar a la elección del tema. La Sección 1.2 recoge los objetivos que se persiguen con
el desarrollo del proyecto. A continuación, la Sección 1.3 describe el plan de trabajo
establecido para alcanzar dichos objetivos. Finalmente, en la Sección 1.4 se presenta
la estructura general de la memoria.
1.1. Motivación
En los últimos años, la Inteligencia Artificial Generativa (IAG) ha transformado
la forma en que las personas interactúan con la tecnología, especialmente a través
de asistentes conversacionales como ChatGPT. Sin embargo, esta revolución no ha
llegado por igual a todos los colectivos. Las personas con discapacidad intelectual
siguen enfrentándose a barreras significativas al usar estas herramientas, que suelen
diseñarse pensando en usuarios con alta competencia digital y lingüística.
Pese a los avances, muchas de estas interfaces aún presentan texto denso, nave-
gación poco adaptada y opciones limitadas de interacción multimodal. Esto sitúa
en desventaja a quienes necesitan apoyos visuales o verbales, interfaces simplifica-
das o una guía proactiva. Las limitaciones no son solo técnicas, sino que también
se originan en la falta de un diseño inclusivo: persiste la suposición implícita de un
usuario homogéneo, lo que excluye a quienes procesan y comunican la información
de manera diferente.
En este contexto, resulta necesario ir más allá de la accesibilidad básica y propo-
ner soluciones específicas para la accesibilidad cognitiva, un área aún poco explorada
dentro del campo de la IAG. El objetivo no es solo que estas herramientas sean acce-
sibles, sino que además resulten comprensibles para una interacción independiente.
Este Trabajo de Fin de Grado se presenta como una ampliación de un TFG pre-
vio titulado “AccIA: Cognitive Accessibility in the Age of AIs”, desarrollado por Aya
1
2Capítulo 1. Introducción
Yahya Amar. Ambos proyectos comparten un objetivo general: diseñar herramien-
tas accesibles que permitan a personas con discapacidad cognitiva interactuar con
tecnologías de IA generativa. La primera versión estableció la base del asistente web
OlivIA, que incluía un cuestionario inicial de personalización, plantillas para apoyar
la generación de preguntas y botones de ayuda con resúmenes y reformulaciones del
texto generado.
Este Trabajo de Fin de Grado tiene como objetivo diseñar una herramienta acce-
sible que permita a personas con discapacidad intelectual interactuar con tecnologías
de IA generativa. Se plantea como una ampliación de un TFG previo, titulado “Ac-
cIA: Cognitive Accessibility in the Age of AIs” y desarrollado por Aya Yahya Amar,
en el que se establecieron las bases del asistente web OlivIA. Partiendo de ese trabajo
inicial y compartiendo el mismo objetivo general, esta nueva versión busca continuar
su desarrollo y ampliar sus funcionalidades.
Sobre esa base, el proyecto actual amplía funcionalidades existentes e incorpo-
ra nuevas formas de interacción y representación. Lo primero que se abordó en el
desarrollo de OlivIA 2.0 fue la evaluación de la accesibilidad de la versión ante-
rior, identificando limitaciones y adaptándolas para dar cumplimiento a las pautas
WCAG 2.2 y a las recomendaciones de accesibilidad cognitiva COGA del W3C. Una
vez consolidada esta base, se incorporaron nuevas funcionalidades orientadas a enri-
quecer la experiencia de uso: la generación de respuestas mediante pictogramas para
facilitar la comprensión; un sistema de generación de posibles preguntas a partir del
contexto, que incluye la evaluación de la ambigüedad de las consultas y la solici-
tud de información adicional en caso necesario para proponer la interpretación más
adecuada; y la incorporación de entrada por voz, que permite formular consultas
oralmente sin necesidad de utilizar el teclado.
La motivación principal de este proyecto es contribuir al desarrollo de tecnologías
verdaderamente inclusivas: aquellas que no solo eliminan barreras, sino que además
se adaptan activamente a la diversidad cognitiva de las personas, promoviendo su
autonomía digital y su participación activa en entornos virtuales.
1.2. Objetivos
El objetivo principal de este Trabajo de Fin de Grado es avanzar en el desarrollo
de una interfaz de aplicación accesible y adaptable, diseñada específicamente para
reducir la brecha entre las personas con discapacidad cognitiva y las tecnologías
emergentes de IA generativa. El proyecto busca atender las necesidades particulares
de este grupo de usuarios, garantizando que la evolución de la inteligencia artificial
sea inclusiva y coherente con los principios de accesibilidad.
Para conseguir el objetivo general se han planteado los siguientes objetivos es-
pecíficos:
Evaluar la accesibilidad de OlivIA 1.0, identificando sus limitaciones en el
ámbito de la accesibilidad cognitiva.
Corregir los problemas detectados en la evaluación para garantizar el cumpli-
miento de las pautas WCAG 2.2 y las recomendaciones cognitivas COGA del
1.3. Plan de Trabajo 3
W3C.
Determinar las funcionalidades pendientes de implementación que contribuyan
a mejorar la claridad, simplicidad y personalización de la herramienta.
Implementar las funcionalidades seleccionadas en función de su viabilidad y
prioridad, ampliando las posibilidades de interacción y representación de Oli-
vIA.
Evaluar la accesibilidad de herramienta final mediante pruebas automáticas y
manuales de accesibilidad, siguiendo las pautas WCAG 2.2 y las recomenda-
ciones cognitivas COGA.
Además, el proyecto contempla los siguientes objetivos académicos y formativos:
Aplicar los conocimientos adquiridos durante la titulación en un proyecto prác-
tico, reforzando la conexión entre teoría y aplicación real.
Explorar y profundizar en herramientas de IA generativa, reconociendo su
potencial, limitaciones y posibilidades para crear soluciones accesibles.
Adquirir nuevas competencias en diseño de interfaces, accesibilidad cognitiva
y desarrollo de software, contribuyendo al crecimiento personal y profesional.
Comprender y aplicar principios fundamentales para crear soluciones intuitivas
adaptadas a las necesidades de personas con discapacidad cognitiva.
Reflexionar sobre la dimensión ética del desarrollo tecnológico, promoviendo
un uso responsable, inclusivo y respetuoso de la IAG.
Reforzar la conciencia sobre la importancia de la accesibilidad en la práctica
profesional, fomentando el compromiso con soluciones tecnológicas equitativas
y universales.
1.3. Plan de Trabajo
A continuación se detalla el plan de proyecto seguido durante el desarrollo de
este Trabajo de Fin de Grado:
1. Investigación documental y estado del arte (Septiembre 2024 – Mayo
2025)
Investigación y redacción inicial sobre inteligencia artificial generativa,
accesibilidad cognitiva, interfaces inclusivas, discapacidad intelectual y
barreras digitales, accesibilidad web.
Análisis de las principales alternativas a ChatGPT y herramientas de
evaluación de accesibilidad automáticas.
Análisis sobre el usos de pictogramas como apoyo de comprensión.
4Capítulo 1. Introducción
Investigación sobre las dificultades en la formulación de preguntas en
personas con discapacidad cognitiva.
Análisis de OlivIA 1.0
2. Implementación (Mayo – Agosto 2025)
Evaluación e implementación de las mejoras detectadas en las evaluacio-
nes manual y automática de OlivIA 1.0.
Implementación y redacción de la respuesta mediante pictogramas.
Implementación y redacción del asistente de preguntas.
Implementación y redacción de la entrada por voz.
Evaluación e implementación de las mejoras detectadas en la versión final
de OlivIA 2.0.
Publicación de la página web.
Documentación técnica del desarrollo.
3. Conclusiones y Trabajo Futuro (Septiembre 2025)
Revisión ortográfica, gramatical y de estilo en diferentes entregas.
Traducción al inglés de los capítulos 1 y 4, así como del resumen.
Revisión final de la memoria y preparación para la defensa del TFG.
1.4. Estructura del documento
Este informe se organiza en los siguientes capítulos, con el objetivo de presentar
de manera clara y progresiva la motivación, el contexto, el desarrollo técnico y los
resultados del proyecto:
Capítulo 1: Introducción. Describe la motivación del proyecto, los objetivos
propuestos y la estructura general del documento, en español e inglés.
Capítulo 2: Estado del Arte. Presenta los antecedentes y el contexto actual
en torno a la accesibilidad cognitiva. Comienza con la definición de discapaci-
dad intelectual y las barreras digitales que dificultan la inclusión en entornos
tecnológicos. A continuación, se revisan los conceptos de accesibilidad web
y accesibilidad cognitiva, con especial atención a las pautas WCAG 2.2 y a
las recomendaciones cognitivas COGA del W3C como marcos de referencia
fundamentales. El capítulo también aborda la revisión de las principales he-
rramientas automáticas utilizadas para evaluar la accesibilidad web y analiza
el papel de tecnologías de apoyo específicas, como las APIs de reconocimiento
de voz y el uso de pictogramas para favorecer la comprensión. Asimismo, se
examinan las dificultades que presentan las personas con discapacidad cogniti-
va en la formulación de preguntas y, finalmente, se describe el desarrollo previo
de OlivIA 1.0, que constituye el punto de partida del presente trabajo.
1.4. Estructura del documento 5
Capítulo 3: Descripción del Proyecto. Detalla el trabajo realizado, comenzando
por la evaluación de accesibilidad de la versión inicial de OlivIA y las mejoras
implementadas. A continuación describe las nuevas funcionalidades desarro-
lladas: generación de respuestas con pictogramas, sugerencias automáticas de
preguntas, evaluación de ambigüedad y reformulación de preguntas y entrada
por voz.
Capítulo 4: Conclusiones y Trabajo Futuro. Presenta las principales conclu-
siones del proyecto y expone posibles mejoras y nuevas funcionalidades para
futuras iteraciones, tanto en español como en inglés.
Introduction
Chapter 1 of this document introduces the Final Degree Project and is organized
into several sections. Section 1.1 presents the motivation that led to the choice of
the topic. Section 1.2 outlines the objectives pursued with the development of
the project. Section 1.3 then describes the work plan established to achieve these
objectives. Finally, Section 1.4 presents the general structure of the report.
1.1. Motivation
In recent years, Generative Artificial Intelligence (GenAI) has transformed the
way people interact with technology, especially through conversational assistants
such as ChatGPT. However, this revolution has not reached all groups equally. Peo-
ple with intellectual disabilities continue to face significant barriers when using these
tools, which are often designed for users with high digital and linguistic competence.
Despite progress, many of these interfaces still present dense text, poorly adapted
navigation, and limited options for multimodal interaction. This places at a disad-
vantage those who need visual or verbal supports, simplified interfaces, or proactive
guidance. The limitations are not only technical but also stem from the lack of
inclusive design: the implicit assumption of a homogeneous user persists, excluding
those who process and communicate information differently.
In this context, it is necessary to go beyond basic accessibility and propose
specific solutions for cognitive accessibility, an area still little explored within the
field of GenAI. The goal is not only to make these tools accessible but also to ensure
they are understandable for independent interaction.
This Final Degree Project builds upon a previous FYP titled “AccIA: Cogni-
tive Accessibility in the Age of AIs”, developed by Aya Yahya Amar. Both projects
share a general goal: to design accessible tools that enable people with cognitive
disabilities to interact with generative AI technologies. The first version established
the foundations of the web assistant OlivIA, which included an initial personaliza-
tion questionnaire, templates to support question generation, and help buttons for
summaries and reformulations of generated text.
The purpose of this project is to design an accessible tool that enables people with
intellectual disabilities to interact with generative AI technologies. It is conceived
as an extension of the previous project “AccIA: Cognitive Accessibility in the Age
7
8Capítulo 1. Introducción
of AIs”, in which the foundations of the web assistant OlivIA were established.
Building upon that initial work and sharing the same overall objective, this new
version seeks to continue its development and expand its functionalities.
Based on this foundation, the current project extends existing functionalities
and incorporates new forms of interaction and representation. The first step in the
development of OlivIA 2.0 was to evaluate the accessibility of the previous version,
identifying limitations and adapting them to comply with WCAG 2.2 guidelines
and W3C COGA cognitive accessibility recommendations. Once this foundation
was consolidated, new features were incorporated to enrich the user experience: the
generation of responses through pictograms to facilitate understanding; a system for
generating possible questions from context, which includes the evaluation of query
ambiguity and the request for additional information when necessary to propose the
most appropriate interpretation; and the integration of voice input, allowing users
to formulate queries orally without using the keyboard.
The main motivation of this project is to contribute to the development of truly
inclusive technologies: those that not only remove barriers but also actively adapt
to the cognitive diversity of people, promoting their digital autonomy and active
participation in virtual environments.
1.2. Objectives
The main objective of this Final Degree Project is to advance the development
of an accessible and adaptable application interface, specifically designed to reduce
the gap between people with cognitive disabilities and emerging generative AI tech-
nologies. The project seeks to address the particular needs of this group of users,
ensuring that the evolution of artificial intelligence is inclusive and consistent with
accessibility principles.
To achieve this overall objective, the following specific goals were established:
Evaluate the accessibility of OlivIA 1.0, identifying its limitations in the field
of cognitive accessibility.
Correct the problems detected in the evaluation to ensure compliance with
WCAG 2.2 guidelines and W3C COGA cognitive recommendations.
Determine pending functionalities that contribute to improving the clarity,
simplicity, and personalization of the tool.
Implement the selected functionalities based on their feasibility and priority,
expanding the interaction and representation possibilities of OlivIA.
Evaluate the accessibility of the final tool through both automated and manual
accessibility tests, following WCAG 2.2 guidelines and COGA recommenda-
tions.
In addition, the project considers the following academic and training objectives:
1.3. Work Plan 9
Apply the knowledge acquired during the degree in a practical project, strength-
ening the connection between theory and real application.
Explore and deepen the use of generative AI tools, recognizing their potential,
limitations, and possibilities for creating accessible solutions.
Acquire new skills in interface design, cognitive accessibility, and software
development, contributing to personal and professional growth.
Understand and apply fundamental principles to create intuitive solutions
adapted to the needs of people with cognitive disabilities.
Reflect on the ethical dimension of technological development, promoting re-
sponsible, inclusive, and respectful use of GenAI.
Strengthen awareness of the importance of accessibility in professional practice,
fostering commitment to equitable and universal technological solutions.
1.3. Work Plan
The following describes the project plan followed during the development of this
Final Degree Project:
1. Documentary research and state of the art (September 2024 – May
2025)
Initial research and writing on generative artificial intelligence, cognitive
accessibility, inclusive interfaces, intellectual disability and digital barri-
ers, web accessibility.
Analysis of the main alternatives to ChatGPT and automated accessibil-
ity evaluation tools.
Analysis of the use of pictograms as comprehension support.
Research on the difficulties in formulating questions among people with
cognitive disabilities.
Analysis of OlivIA 1.0.
2. Implementation (May – August 2025)
Evaluation and implementation of improvements detected in manual and
automated evaluations of OlivIA 1.0.
Implementation and documentation of response generation through pic-
tograms.
Implementation and documentation of the question assistant.
Implementation and documentation of voice input.
Evaluation and implementation of improvements detected in the final
version of OlivIA 2.0.
10 Capítulo 1. Introducción
Publication of the website.
Technical documentation of the development.
3. Conclusions and Future Work (September 2025)
Orthographic, grammatical, and stylistic review across different deliver-
ies.
Translation into English of Chapters 1 and 4, as well as the abstract.
Final review of the report and preparation for the defense of the FYP.
1.4. Structure of the document
This report is organized into the following chapters, with the aim of presenting
in a clear and progressive manner the motivation, context, technical development,
and results of the project:
Chapter 1: Introduction. Describes the motivation for the project, the pro-
posed objectives, and the general structure of the document, in both Spanish
and English.
Chapter 2: State of the Art. Presents the background and current context
regarding cognitive accessibility. It begins with the definition of intellectual
disability and the digital barriers that hinder inclusion in technological en-
vironments. It then reviews the concepts of web accessibility and cognitive
accessibility, with special attention to WCAG 2.2 guidelines and W3C COGA
cognitive recommendations as fundamental reference frameworks. The chap-
ter also addresses a review of the main automated tools used to evaluate web
accessibility and analyzes the role of specific assistive technologies, such as
speech recognition APIs and the use of pictograms to support comprehension.
Additionally, it examines the difficulties people with cognitive disabilities face
in formulating questions and, finally, it describes the previous development of
OlivIA 1.0, which serves as the starting point for this work.
Chapter 3: Project Description. Details the work carried out, starting with the
accessibility evaluation of the initial version of OlivIA and the improvements
implemented. It then describes the new functionalities developed: generation
of responses with pictograms, automatic question suggestions, evaluation of
ambiguity and reformulation of questions, and voice input.
Chapter 4: Conclusions and Future Work. Presents the main conclusions of
the project and outlines possible improvements and new functionalities for
future iterations, both in Spanish and English.
Cap´
ıtulo 2
Estado del arte
2.1. Discapacidad intelectual y barreras digitales
Las personas con discapacidad intelectual representan uno de los colectivos más
diversos y heterogéneos en el ámbito de la accesibilidad digital. Aproximadamente el
15 % de la población mundial presenta algún tipo de discapacidad, y dentro de este
grupo, la discapacidad intelectual afecta a millones de personas en distintos grados
World Health Organization y World Bank (2011).
La discapacidad intelectual engloba dificultades que afectan el procesamiento de
la información, la memoria, la atención, la resolución de problemas y la comprensión
del lenguaje (Cognitive y Force, 2021). Dentro de este amplio espectro se incluyen
condiciones como los trastornos del espectro autista (TEA), la dislexia o el trastorno
por déficit de atención e hiperactividad (TDAH), entre otros. Cada una de estas
condiciones implica retos específicos en la interacción con entornos digitales, lo que
subraya la necesidad de adoptar enfoques personalizados de diseño.
En el entorno digital, las barreras para usuarios con discapacidad intelectual se
manifiestan en múltiples formas: dificultad para comprender textos largos o abstrac-
tos, problemas al interpretar instrucciones poco claras, obstáculos al realizar tareas
que requieran varios pasos consecutivos y confusión ante interfaces que cambian
dinámicamente. Además, muchos diseños no contemplan la memoria de trabajo li-
mitada ni las dificultades de atención, lo que aumenta la carga cognitiva. Por ello,
este colectivo requiere entornos digitales predecibles, con textos simplificados, nave-
gación consistente y apoyos visuales o auditivos complementarios (Cognitive y Force,
2021).
Para responder a estas necesidades, se han impulsado enfoques de “diseño cogniti-
vo inclusivo” (Microsoft Inclusive Design Team, 2023), que proponen la simplificación
progresiva del contenido, la descomposición de tareas complejas en pasos accesibles y
el uso de apoyos visuales o verbales para reforzar la comprensión (Cognitive y Force,
2021). Asimismo, la personalización adaptativa se ha consolidado como estrategia
clave, con interfaces que se ajustan automáticamente al ritmo, las preferencias y las
capacidades cognitivas del usuario (Cognitive y Force, 2021; Seeman et al., 2021). La
evidencia reciente indica que estas estrategias reducen la carga cognitiva y mejoran
la accesibilidad percibida, desde patrones de simplificación de contenidos y diseños
11
12 Capítulo 2. Estado del arte
centrados en personas con discapacidad cognitiva (Moreno et al., 2024) hasta siste-
mas de microaprendizaje e intervenciones de andamiaje adaptativo que modulan el
soporte en tiempo real (Zhu et al., 2024; Faber et al., 2024).
Entre las distintas barreras, la formulación de preguntas constituye un reto espe-
cífico en entornos basados en lenguaje natural, como los asistentes conversacionales.
Esta actividad exige combinar diversas habilidades lingüísticas y cognitivas, lo que
puede constituir una barrera significativa para personas con discapacidad intelec-
tual (American Association on Intellectual and Developmental Disabilities, 2021;
American Psychiatric Association, 2022).
Muchas personas encuentran complicado comprender el funcionamiento del sis-
tema y delimitar qué tipo de preguntas son posibles o cómo deben estructurarse
para obtener una respuesta útil. Esta falta de modelos claros puede conducir a in-
teracciones frustrantes o a la ausencia de participación tal y como se recogió en la
actividad exploratoria realizada en el desarrollo de Olivia 1.0, donde se analizó el
uso de ChatGPT con usuarios con discapacidad cognitiva (Amar, 2025).
Las limitaciones léxicas y gramaticales propias de ciertos perfiles de discapacidad
intelectual dificultan la construcción de preguntas bien formuladas. La selección de
vocabulario adecuado y la aplicación de estructuras interrogativas requieren un do-
minio del lenguaje que en estos casos puede estar comprometido, lo que se traduce
en preguntas incompletas o ambiguas (American Speech-Language-Hearing Associa-
tion, 2024; American Psychiatric Association, 2022).
Otra barrera habitual está vinculada a los déficits en planificación y organización
del discurso. Formular una pregunta implica decidir qué se quiere saber, ordenar la
información relevante y expresarla en una estructura comprensible. Estos procesos,
que dependen en gran medida de la memoria de trabajo y de las funciones ejecutivas,
suelen estar limitados en este colectivo, generando mensajes desordenados o difíciles
de interpretar (American Psychiatric Association, 2022).
La interacción con un sistema considerado “inteligente” puede generar ansiedad
o falta de confianza, especialmente si la persona ha tenido experiencias previas de
incomprensión o error. Este factor emocional incrementa la reticencia a interactuar,
reduciendo la autonomía digital y limitando los beneficios potenciales de la herra-
mienta. Este factor emocional no solo condiciona la disposición a interactuar, sino
también la calidad de las respuestas, ya que la persona puede optar por preguntas
excesivamente simples o abandonar la interacción.
Estas dificultades se traducen en preguntas incompletas, ambiguas o fuera de
contexto, e incluso en la ausencia total de interacción, lo que limita significativa-
mente el beneficio que este colectivo puede obtener de las tecnologías de inteligencia
artificial generativa (Gartland et al., 2022).
2.2. Accesibilidad web
La accesibilidad web es la disciplina que garantiza que los sitios, herramientas y
tecnologías digitales puedan ser utilizados por todas las personas, incluidas aquellas
con discapacidad, de modo que puedan percibir, comprender, navegar, interactuar
y también contribuir en la Web (W3C, 2018).
2.2. Accesibilidad web 13
Las Web Content Accessibility Guidelines (WCAG) constituyen el marco de refe-
rencia global para la creación de contenidos digitales accesibles y universales. Estas
directrices, elaboradas por el World Wide Web Consortium, tienen como objetivo
garantizar que cualquier persona, independientemente de sus capacidades físicas,
sensoriales o cognitivas, pueda acceder, percibir, comprender, navegar e interactuar
con la web (World Wide Web Consortium (W3C) – Web Accessibility Initiative
(WAI), 2024b). Desde su primera publicación en 1999 (W3C, 1999), las WCAG han
evolucionado para adaptarse a los avances tecnológicos y a las necesidades emergen-
tes de una sociedad cada vez más digitalizada. La versión más reciente, WCAG 2.2
(World Wide Web Consortium (W3C), 2024), fue aprobada como Recomendación
del W3C el 5 de octubre de 2023 y recibió actualizaciones editoriales el 12 de di-
ciembre de 2024 (World Wide Web Consortium (W3C) – Web Accessibility Initiative
(WAI), 2023). En total, las WCAG contienen 86 criterios estructurados en torno a
cuatro principios:
Perceptible: la información debe presentarse de forma que pueda ser per-
cibida por todos los usuarios, lo que implica, por ejemplo, proporcionar al-
ternativas textuales a elementos visuales o incluir subtítulos en contenidos
multimedia.
Operable: los componentes interactivos y la navegación deben poder utilizarse
mediante diversos métodos de entrada, como el teclado, y evitar elementos que
puedan generar barreras, como contenido que se mueve demasiado rápido o que
causa reacciones adversas.
Comprensible: tanto el contenido como la interfaz deben ser fáciles de en-
tender, lo que requiere instrucciones claras, mensajes de error comprensibles
y un diseño coherente y predecible.
Robusto: los contenidos deben estar desarrollados de manera que sean compa-
tibles con las tecnologías de asistencia actuales y futuras, utilizando estructuras
de código correctas y semánticas.
Cada uno de estos principios se traduce en un conjunto de criterios que pueden
cumplirse en tres niveles de conformidad:
Nivel A: requisitos mínimos básicos de accesibilidad; su incumplimiento im-
pide que muchas personas con discapacidad accedan a los contenidos.
Nivel AA: estándar recomendado, incorpora los requisitos del nivel A y añade
mejoras significativas de accesibilidad que benefician a un mayor número de
usuarios.
Nivel AAA: nivel más exigente, garantiza la accesibilidad más completa, aun-
que no siempre es viable cumplirlo en todos los tipos de contenido o contextos.
El nivel AA se considera el mínimo exigible en varios marcos normativos. En la
Unión Europea, la Directiva (UE) 2016/2102 obliga a que los sitios web y las apli-
caciones móviles del sector público cumplan los requisitos de accesibilidad definidos
14 Capítulo 2. Estado del arte
en la norma armonizada EN 301 549, que remite a los criterios de éxito de WCAG
2.1 de nivel A y AA para el contenido web (European Parliament and the Council,
2016; European Commission, 2021; ETSI, 2021).
La adopción de estos criterios no solo asegura el cumplimiento normativo, sino
que además potencia la experiencia de usuario y fomenta la inclusión digital, bene-
ficiando a toda la comunidad.
2.2.1. Accesibilidad cognitiva
A pesar de los avances logrados con las WCAG, existe un reconocimiento crecien-
te de que muchos usuarios continúan enfrentando barreras significativas, especial-
mente aquellos con discapacidad intelectual (Gartland et al., 2022). Para abordar
estas necesidades específicas, el grupo de trabajo Cognitive and Learning Disabilities
Accessibility Task Force (COGA), perteneciente al W3C1, desarrolló la guía Making
Content Usable for People with Cognitive and Learning Disabilities, que amplía las
recomendaciones tradicionales con pautas centradas en la usabilidad y la compren-
sión del contenido para este colectivo (Cognitive y Force, 2021).
Las recomendaciones de COGA complementan las WCAG, enfocándose en re-
ducir la carga cognitiva, mejorar la previsibilidad y ofrecer experiencias más perso-
nalizables (Cognitive y Force, 2021; W3C WAI, 2021). Este enfoque reconoce que,
para muchas personas, la complejidad del contenido, la sobrecarga de información y
los flujos de interacción poco claros pueden suponer barreras aún más importantes
que las limitaciones físicas o sensoriales (Gartland et al., 2022).
En paralelo a estas iniciativas, en Europa se han consolidado las pautas de lectura
fácil (easy-to-read), que ofrecen un método específico para adaptar textos complejos
a un lenguaje más sencillo, claro y comprensible. Estas directrices, recogidas en
documentos como las Pautas europeas de la lectura fácil o el manual de Métodos de
lectura fácil (Inclusion Europe, 2012), promueven la eliminación de tecnicismos, el
uso de frases cortas y estructuras simples, así como el apoyo con recursos visuales.
Para que un texto pueda considerarse en lectura fácil, debe cumplir con criterios
relacionados tanto con el lenguaje como con la presentación visual del contenido.
Entre los más relevantes se encuentran:
Usar frases cortas (una idea principal por oración) y vocabulario cotidiano,
evitando tecnicismos, acrónimos o palabras abstractas.
Mantener la voz activa y un orden sintáctico simple (sujeto–verbo–complemento).
Explicar palabras poco frecuentes con sinónimos o ejemplos concretos.
Estructurar los textos en párrafos breves, separados por títulos o subtítulos
claros.
Utilizar tipografías legibles, tamaño de letra suficiente y contraste adecuado
entre texto y fondo.
1https://www.w3.org/WAI/about/groups/task-forces/coga/
2.2. Accesibilidad web 15
Incorporar apoyos visuales (imágenes, pictogramas, diagramas) que refuercen
el significado de la información.
Evitar el uso excesivo de mayúsculas, cursivas o subrayados, ya que dificultan
la lectura.
Incluir listas con viñetas o numeración para organizar la información de manera
clara y secuencial.
Además, las pautas recomiendan validar los materiales con usuarios finales me-
diante procesos de evaluación participativa, garantizando que los textos no solo
cumplen con los principios formales, sino que realmente resultan comprensibles para
el público destinatario.
En este contexto, los ocho principios u objetivos de diseño establecidos por el gru-
po Cognitive and Learning Disabilities Accessibility Task Force (COGA) del W3C
(W3C WAI Cognitive and Learning Disabilities Accessibility Task Force, 2021) ofre-
cen un marco práctico para orientar la creación de contenidos digitales más compren-
sibles e inclusivos. Cada principio se acompaña de pautas y ejemplos que ilustran
cómo aplicarlo en la práctica. A continuación, se presentan de forma resumida estos
principios:
Contenido claro y comprensible: La redacción debe ser sencilla, directa
y libre de palabras técnicas. Es fundamental usar frases cortas, vocabulario
básico y estructuras gramaticales simples. Por ejemplo, en lugar de “pulse
para proceder con la autenticación”, utilizar “haz clic para entrar”.
Diseño consistente y predecible: La interfaz debe mantener una estruc-
tura visual estable y familiar en todas sus secciones. Elementos como menús,
botones o iconos deben estar ubicados en el mismo lugar en cada pantalla, y
sus funciones no deben cambiar. Por ejemplo, un botón de “Ayuda” debe tener
el mismo icono y estar visible en todas las páginas.
Minimizar la carga cognitiva: Se deben descomponer tareas complejas en
pasos más pequeños, con instrucciones claras en cada fase. Además, conviene
mostrar el progreso y evitar sobrecargar visualmente la pantalla. Por ejemplo,
un formulario largo se puede dividir en varias pantallas, con un indicador de
avance (“Paso 2 de 4”).
Ayuda y soporte contextual: Las ayudas deben estar visibles en el momento
y lugar en que el usuario las necesita, sin obligarlo a buscar en otras secciones.
Por ejemplo, incluir un botón de “¿Qué significa esto?” junto a campos de
entrada complejos o con términos poco habituales.
Opciones de personalización: Se deben ofrecer alternativas para ajustar
la experiencia según las preferencias o necesidades del usuario. Esto incluye
cambiar el tamaño del texto, el contraste de colores o el tipo de contenido
mostrado. Por ejemplo, permitir activar una versión con pictogramas o una
simplificada del contenido textual.
16 Capítulo 2. Estado del arte
Gestión flexible del tiempo: Es importante eliminar o extender los límites
temporales en tareas interactivas para evitar presión o ansiedad. Por ejemplo,
en una prueba o cuestionario online, permitir que el usuario decida cuándo
finalizar, o pausar la actividad si lo necesita.
Retroalimentación clara y multimodal: Toda acción realizada por el usua-
rio debe generar una respuesta clara que confirme el resultado, idealmente
mediante múltiples canales. Por ejemplo, al enviar un formulario, mostrar un
mensaje de confirmación con texto, un icono y, si se habilita, un sonido suave.
Diseño centrado en la persona: Es fundamental involucrar a personas con
discapacidad intelectual en el proceso de diseño, prueba y validación. Esto
asegura que las soluciones estén verdaderamente adaptadas a sus necesidades.
Por ejemplo, realizar sesiones de co-creación o entrevistas con usuarios reales
durante el desarrollo de una aplicación accesible.
2.2.2. Evaluación de la accesibilidad web
La evaluación de la accesibilidad es un proceso clave dentro del desarrollo in-
clusivo, y puede llevarse a cabo mediante técnicas automáticas y manuales. En este
contexto, las herramientas automáticas desempeñan un papel relevante al ofrecer una
primera aproximación al nivel de cumplimiento de los estándares, como las WCAG,
y al permitir identificar de forma rápida errores comunes y problemas potenciales.
Su principal ventaja radica en la inmediatez del diagnóstico y en la priorización
de recomendaciones, lo que facilita la detección temprana de barreras y reduce los
costes asociados a correcciones tardías. Diversos estudios han señalado que su al-
cance es limitado: se estima que únicamente detectan entre el 30 % y el 60 % de los
problemas reales de accesibilidad (The University of Chicago – Center for Digital
Accessibility, 2025; Deque Systems, 2021). Aspectos relacionados con la comprensión
del contenido, la adecuación semántica o la experiencia de usuarios con discapacidad
cognitiva suelen quedar fuera de su cobertura. Por este motivo, se recomienda siem-
pre complementar su uso con evaluaciones manuales y pruebas participativas con
usuarios finales (World Wide Web Consortium (W3C) – Web Accessibility Initiative
(WAI), 2024a).
Partiendo de estas consideraciones, a continuación se presentan las principales
herramientas automáticas que se emplean habitualmente en auditorías de accesibi-
lidad web.
2.2.3. WAVE (Web Accessibility Evaluation Tool)
WAVE 2, desarrollada por WebAIM, es una herramienta en línea que muestra
la página con iconos e indicadores incrustados para señalar errores, advertencias y
elementos a revisar (WebAIM, 2025c,b). Ofrece extensiones para Chrome, Firefox y
Edge (WebAIM, 2025a).
2https://wave.webaim.org
2.2. Accesibilidad web 17
WAVE destaca por su representación visual clara, como se puede ver en la Fi-
gura 2.1, de modo que la localización y la comprensión de cada hallazgo resultan
inmediatas. Más allá de señalar el “qué”, ofrece pistas sobre el “por qué” y el “có-
mo corregirlo”, lo que agiliza el ciclo para detectar, ajustar y verificar, incluso para
quienes no tienen un perfil técnico.
WAVE evalúa principalmente el cumplimiento de las WCAG 2.1 en criterios re-
lacionados con el uso de texto alternativo en imágenes, la estructura y jerarquía
de encabezados, el contraste de color, el uso de etiquetas en formularios y la exis-
tencia de enlaces descriptivos, entre otros. Detecta de forma fiable barreras críticas
habituales y facilita la priorización inicial de correcciones, lo que la convierte en un
recurso útil tanto para fases tempranas de desarrollo como para auditorías rápidas
de contenido publicado.
Además de las comprobaciones técnicas, WAVE incorpora evaluaciones relacio-
nadas con la accesibilidad cognitiva. Estas incluyen, por ejemplo, la detección de
textos con bajo contraste o demasiado extensos, la identificación de títulos repe-
tidos o ambiguos y la señalización de formularios sin instrucciones claras. Aunque
no abarca toda la complejidad de las recomendaciones COGA, estas alertas ayudan
a evidenciar problemas de comprensión, consistencia y carga cognitiva que suelen
pasar desapercibidos en validaciones estrictamente técnicas. De esta manera, WAVE
contribuye a integrar la dimensión cognitiva en los procesos de revisión, complemen-
tando las evaluaciones manuales y las pruebas con usuarios.
Su disponibilidad como servicio web y como extensión de navegador permite
integrarla fácilmente en flujos de trabajo de desarrollo ágil, y su carácter gratuito
favorece su uso sistemático en revisiones periódicas.
En páginas muy densas, la cantidad de marcadores puede resultar abrumadora y
dificultar la priorización si no se filtra por categorías. Por ello, sus resultados deben
interpretarse como una primera criba que necesariamente ha de complementarse con
revisión manual y pruebas con usuarios.
2.2.4. Google Lighthouse
Lighthouse3es una herramienta automatizada de código abierto, desarrollada
por Google e integrada en las Chrome DevTools; permite auditar páginas web en
categorías como rendimiento, accesibilidad, buenas prácticas, SEO y aplicaciones
web progresivas (PWA) (Chrome for Developers, 2025a,b; GoogleChrome, 2025).
Lighthouse es una opción inmediata y gratuita porque se ejecuta directamente
desde el navegador, lo que facilita incorporarlo a revisiones rápidas sin instalar nada
adicional. Ofrece una puntuación de accesibilidad de 0 a 100, como se puede ver en
la Figura 2.2 basada en comprobaciones alineadas con las WCAG 2.1, acompañada
de recomendaciones priorizadas por gravedad y con enlaces a documentación que
explica causas y posibles soluciones. Además, puede simular contextos de uso habi-
tuales, como navegación móvil o condiciones de red limitadas, para observar cómo
afectan estos escenarios a la experiencia y orientar las correcciones.
Por otro lado su alcance es esencialmente página a página, de modo que no re-
3https://chromewebstore.google.com/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk
18 Capítulo 2. Estado del arte
Figura 2.1: Interfaz de WAVE mostrando el análisis de accesibilidad sobre la página
principal de ChatGPT.
sulta práctico para auditar sitios grandes ni para obtener métricas agregadas de un
conjunto de URLs. La cobertura de criterios no es exhaustiva: una buena puntua-
ción no garantiza el cumplimiento de todas las WCAG ni la ausencia de barreras
relevantes. Las simulaciones de móvil o de red son aproximaciones de laboratorio,
por lo que conviene validar también en dispositivos y condiciones reales.
2.2.5. Pa11y y Pa11y Dashboard
Pa11y4es una herramienta de código abierto basada en línea de comandos que
ejecuta auditorías automáticas mapeadas a criterios WCAG (niveles A/AA/AAA)
y puede usarse desde la CLI o desde Node.js (Team Pa11y, 2024c). Pa11y Dashboard
es una interfaz web construida sobre esta herramienta que permite monitorizar múl-
tiples páginas y visualizar tendencias con gráficos como se muestra en la Figura 2.3
(Team Pa11y, 2024a,b).
Pa11y encaja bien en flujos de trabajo profesionales porque se integra en CI/CD
y permite ejecutar comprobaciones automáticamente en cada commit o despliegue.
Esta automatización facilita programar análisis periódicos y conservar un historial de
resultados para detectar regresiones y medir la evolución en el tiempo. Los informes
se pueden exportar en formatos reutilizables (p. ej., JSON o CSV), lo que simplifica
su consumo por otras herramientas, paneles o scripts propios. Además, ofrece una
visión centralizada del estado de accesibilidad en múltiples URLs, útil para priorizar,
comparar secciones del sitio y comunicar avances al equipo.
Esta herramienta requiere cierto nivel técnico para su configuración y uso desde
consola, especialmente si se desea cubrir rutas protegidas, flujos multi-paso o sitios
4https://pa11y.org/
2.2. Accesibilidad web 19
Figura 2.2: Interfaz de Google Lighthouse mostrando el análisis de accesibilidad
sobre la página principal de ChatGPT.
con renderizado dinámico, que suelen exigir scripting adicional. En su variante de
línea de comandos no ofrece una interfaz visual inmediata; los paneles y servicios
asociados necesitan instalación y mantenimiento.
2.2.6. axe DevTools
axe DevTools5, desarrollado por Deque Systems, es una extensión de navegador
basada en la biblioteca axe-core (Deque Systems, 2025b,c). Ofrece una evaluación
profunda de problemas técnicos de accesibilidad (Deque Systems, 2025d; Deque Uni-
versity, 2025) y es ampliamente utilizada en entornos profesionales (Deque Systems,
2025a).
axe DevTools ofrece una detección especialmente precisa en verificaciones téc-
nicas, destacando el nodo afectado, la causa del problema y pasos concretos para
corregirlo, lo que agiliza el ciclo de corrección. Se integra de forma fluida con marcos
de testing como Selenium, Jest o Cypress, permitiendo incorporar pruebas de acce-
sibilidad a suites automatizadas y a pipelines de CI/CD. Para exploración rápida,
la versión gratuita en el navegador resulta suficiente para análisis puntuales durante
el desarrollo, sin configuración previa como se muestra en la Figura 2.4.
La edición completa es de pago tras 14 días de prueba, por lo que algunas fun-
ciones avanzadas (p. ej., reportes ampliados o asistencia guiada) quedan fuera del
alcance de la versión gratuita. No realiza rastreos masivos ni el análisis simultáneo
de múltiples páginas, y no cubre aspectos que requieren juicio humano (adecuación
del texto alternativo, claridad del lenguaje, consistencia de patrones de interacción).
En aplicaciones con estados dinámicos o contenido tras autenticación, el alcance del
5https://www.deque.com/axe/browser-extensions/
20 Capítulo 2. Estado del arte
Figura 2.3: Interfaz de Pa11y mostrando el análisis de accesibilidad sobre la página
principal de ChatGPT.
escaneo depende de lo que esté presente en el DOM en el momento de la prueba;
suele requerir scripting adicional y revisión manual complementaria.
2.2.7. SortSite
SortSite6, desarrollado por PowerMapper, es una herramienta de escritorio que
realiza auditorías de accesibilidad, usabilidad, SEO y cumplimiento de estándares
(PowerMapper Software, 2025d,c,b). Además, contempla comprobaciones relaciona-
das con la privacidad (p. ej., avisos de cookies y seguimiento) (PowerMapper Softwa-
re, 2023). Es ampliamente utilizada en entornos corporativos (PowerMapper Soft-
ware, 2025a; Web Key IT, 2024).
SortSite resulta especialmente útil cuando se necesita una visión de conjunto del
sitio: permite auditar varias páginas en una misma ejecución y descubrir patrones de
error repetidos entre secciones. Contrasta los hallazgos frente a WCAG 2.1 e incluye
comprobaciones de compatibilidad con navegadores, lo que ayuda a priorizar correc-
ciones que afectan a más entornos de uso. Además, sus informes son personalizables
y pueden descargarse en distintos formatos, facilitando su integración en flujos de
trabajo, el intercambio con el equipo y la trazabilidad de decisiones como se muestra
en la Figura 2.5.
Por otro lado es una herramienta de pago, por lo que su adopción puede requerir
justificar coste y licencias frente a alternativas abiertas. Aunque ofrece reportes
detallados, no permite editar o corregir directamente desde la propia interfaz: las
soluciones deben aplicarse en el código o el CMS y luego verificarse de nuevo.
6https://www.powermapper.com/products/sortsite/
2.2. Accesibilidad web 21
Figura 2.4: Interfaz de axe DevTools mostrando el análisis de accesibilidad sobre la
página principal de ChatGPT.
Figura 2.5: Interfaz de SortSite mostrando el análisis de accesibilidad sobre la página
principal de ChatGPT.
22 Capítulo 2. Estado del arte
Figura 2.6: Interfaz de DYNO Mapper mostrando el análisis de accesibilidad sobre
la página principal de Gemini.
2.2.8. DYNO Mapper
DYNO Mapper7es una plataforma que combina la auditoría de accesibilidad
con herramientas de planificación de contenido y mapas visuales de sitio, y soporta
pruebas conforme a WCAG (DYNO Mapper, 2025a,b, 2022).
DYNO Mapper ofrece un panel centralizado que reúne accesibilidad, SEO y ma-
pas visuales del sitio, lo que permite tener una visión estructural del proyecto y
detectar patrones de error por secciones o plantillas. El informe de accesibilidad seg-
menta los hallazgos por tipo de problema, facilitando la priorización y la asignación
de tareas al equipo. Al ser accesible desde el navegador y estar optimizado para
dispositivos móviles, resulta práctico tanto para revisiones de escritorio como para
comprobaciones rápidas sobre la marcha, sin necesidad de instalación adicional.
La versión gratuita está limitada a 3 URLs, por lo que los análisis de mayor
alcance o las funciones de colaboración avanzada requieren una suscripción. En este
caso se ha analizado Gemini, como se muestra en la Figura 2.6 porque haciendo las
pruebas se agotaron los analisis de prueba.
2.2.9. AChecker
AChecker8es una herramienta gratuita y de código abierto que valida páginas
web frente a múltiples estándares (WCAG 1.0/2.0, Section 508, BITV y Stanca
Act) (Inclusive Design Institute, 2021; AChecker Project, 2025b). Además, incorpora
revisión semi-manual mediante tres categorías —problemas conocidos, probables y
7https://dynomapper.com/
8https://websiteaccessibilitychecker.com/
2.2. Accesibilidad web 23
Figura 2.7: Interfaz de AChecker mostrando el análisis de accesibilidad sobre la
página principal de ChatGPT.
potenciales— que requieren juicio humano para su verificación (AChecker Project,
2025a).
AChecker permite seleccionar la normativa con la que se desea evaluar (p. ej.,
distintas versiones y niveles de conformidad de WCAG o normativas internacionales
equivalentes), lo que facilita ajustar la auditoría al marco regulatorio exigido en
cada proyecto. Los informes resultantes son claros y accesibles, e incluyen enlaces
a documentación explicativa que ayuda a comprender la causa de cada hallazgo
y orienta sobre cómo resolverlo. Además, incorpora una evaluación contextual que
permite al usuario marcar hallazgos como relevantes o irrelevantes para su caso,
reduciendo el “ruido” de falsos positivos y dejando un rastro de decisiones útil para
priorizar correcciones.
En cambio la interfaz es menos moderna y no cuenta con integración directa en
el navegador ni con herramientas de desarrollo, por lo que el flujo de trabajo puede
resultar menos ágil que en alternativas más recientes como se puede ver en la Figura
2.7. No ofrece funciones colaborativas ni análisis en lote: la revisión suele realizarse
URL a URL y la coordinación de tareas debe gestionarse con herramientas externas.
Como verificador automático, sus resultados requieren complementar con revisión
manual y pruebas con tecnologías de apoyo para captar problemas dependientes del
contexto.
24 Capítulo 2. Estado del arte
2.2.10. Conclusiones
Cada herramienta aporta una perspectiva complementaria en la evaluación de
accesibilidad como se puede observar en la Tabla 2.1. Lighthouse yPa11y son útiles
para análisis rápidos o monitorización continua, mientras que axe DevTools des-
taca por su precisión técnica. Herramientas como WAVE oAChecker facilitan la
interpretación visual, y SortSite oDYNO Mapper permiten auditorías más amplias
y profesionales. No obstante, ninguna sustituye las evaluaciones manuales, especial-
mente en aspectos subjetivos como claridad cognitiva, usabilidad real o comprensión
semántica por parte del usuario.
Herramientas WAVE Pa11y
Dash-
board
axe
DevTools
(Deque)
SortSite DYNO
Mapper
AChecker
Tipo Extensión
de
navegador
Aplicación
web,
CI/CD
Extensión
de
navegador
+ API
Herramienta
de
escritorio
Herramienta
web
Herramienta
web
Usabilidad Auditoría
manual y
visual
Auditorías
automatiza-
das
Auditorías
mixtas
Auditoría
general
(SEO,
Acc.)
Análisis de
contenido
Análisis de
contenido
Pautas
aplicadas
WCAG 2.1,
ARIA
WCAG 2.1 WCAG 2.1,
ARIA,
Sección 508
WCAG 2.1,
Sección 508
WCAG 2.1 WCAG 2.1,
Sección 508
Análisis Mixto Automático Mixto Mixto Automático Automático
Compatibili-
dad
Chrome,
Firefox (y
Edge)
CI/CD
(Jenkins,
GitHub
Actions)
Chrome,
Edge +
API
Windows,
macOS
Basado en
navegador
Basado en
navegador
Enfoque Problemas
en el DOM
Automatiza-
ción de
pruebas
Recomenda-
ciones
prácticas
Accesibili-
dad y SEO
Organiza-
ción de
contenido
Accesibili-
dad,
velocidad y
SEO
Funciones
destacadas
Iconos
sobre la
interfaz;
lista para
accesibili-
dad
cognitiva
Historial;
exportación
JSO-
N/CSV;
panel cen-
tralizado de
URLs
Integración
con
Selenium/
Jest/
Cypress;
versión
gratuita
para
análisis
rápidos
Informes
personaliza-
bles;
descarga en
múltiples
formatos
Panel
unificado
de
accesibili-
dad/SEO/-
mapas del
sitio
Evaluación
contextual
(marcar
hallazgos
como rele-
vantes/irre-
levantes)
Cobertura Página por
página
(manual)
Múltiples
páginas y
sitios
completos
Página por
página o
múltiples
con API
Sitio
completo
(rastrea
todas las
páginas)
Sitio
completo
(rastreo au-
tomático)
Página por
página (con
opción de
subir
HTML)
Tabla 2.1: Comparativa de herramientas de accesibilidad.
2.3. APIs de reconocimiento de voz 25
2.3. APIs de reconocimiento de voz
En los últimos años, el reconocimiento de voz se ha consolidado como una herra-
mienta clave en el desarrollo de interfaces accesibles y multimodales. Diversas APIs
ofrecen esta funcionalidad con diferentes grados de precisión, facilidad de integración
y requerimientos técnicos. A continuación se describen las más relevantes:
Web Speech API9: API nativa del navegador, desarrollada inicialmente por
Google. Permite el reconocimiento de voz directamente en el cliente web sin
necesidad de servicios externos. Es compatible principalmente con navegadores
basados en Chromium mediante la interfaz webkitSpeechRecognition.
Google Cloud Speech-to-Text10: API comercial de alto rendimiento que
proporciona modelos avanzados de reconocimiento de voz. Soporta múltiples
idiomas y permite personalización, pero requiere conexión constante a Internet
y una cuenta de Google Cloud.
IBM Watson Speech to Text11: Servicio en la nube que ofrece reconoci-
miento preciso y herramientas adicionales como la diarización de hablantes.
Exige configuración más avanzada y registro en la plataforma IBM Cloud.
Microsoft Azure Speech Services12: Plataforma que permite el reconoci-
miento en tiempo real, detección automática de idioma y transcripción con-
tinua. Funciona mediante suscripción a Azure y está pensada para entornos
empresariales.
Amazon Transcribe13: Servicio de AWS orientado a aplicaciones de gran
escala. Destaca por su robustez en entornos de producción, pero requiere co-
nocimientos técnicos en infraestructura cloud.
Estas soluciones ofrecen distintos niveles de control, precisión, privacidad y coste,
lo que condiciona su idoneidad según el contexto de uso.
2.4. Pictogramas
Los pictogramas son representaciones gráficas simples, diseñadas para ser fácil-
mente reconocibles y comprensibles, que representan ideas, acciones u objetos como
se puede observar en la Figura 2.8. Suelen caracterizarse por líneas claras, ausen-
cia de detalles superfluos y uso de colores planos o contrastados que favorecen la
legibilidad. En entornos digitales, los pictogramas funcionan como atajos visuales:
permiten identificar rápidamente funciones o conceptos que, en formato textual, exi-
girían un mayor esfuerzo de lectura. El uso coherente de pictogramas crea patrones
9https://www.google.com/intl/es_es/chrome/demos/speech.html
10https://cloud.google.com/speech-to-text
11https://www.ibm.com/products/speech-to-text
12https://azure.microsoft.com/es-es/products/ai-services/ai-speech
13https://aws.amazon.com/es/transcribe/
26 Capítulo 2. Estado del arte
visuales predecibles que refuerzan el aprendizaje y favorecen una navegación más au-
tónoma. Para muchas personas con discapacidad intelectual, y también para quienes
están aprendiendo un idioma personas con baja alfabetización, los pictogramas pue-
den reforzar o incluso sustituir al lenguaje escrito, facilitando la comprensión de
instrucciones, conceptos y contenidos complejos (Kudo, 2022).
La evidencia reciente muestra que los apoyos visuales bien diseñados mejoran la
autonomía y reducen la carga cognitiva en tareas digitales; en particular, los picto-
gramas con buena iconicidad (es decir, cuya forma se asemeja a lo que representan)
y transparencia (cuyo significado se “adivina” sin necesidad de aprendizaje previo)
favorecen la comprensión (Díez y colleagues, 2024). No obstante, algunos trabajos
advierten que aprender símbolos nuevos puede resultar difícil para parte del colectivo
con discapacidad intelectual; por ello, se recomiendan iconos familiares, consistentes
y culturalmente neutros (Kudo, 2022).
Existen distintas colecciones de pictogramas ampliamente utilizadas en contextos
educativos, sanitarios y tecnológicos. Entre las más relevantes destacan:
ARASAAC14: proyecto español de referencia internacional que ofrece un re-
positorio de pictogramas gratuitos y con licencia abierta, validados en múlti-
ples ámbitos (educativo, sanitario, señalización pública). Su estilo se basa en
figuras esquemáticas, con trazos simples y un repertorio amplio y actualizado
(ARASAAC, 2019, 2017).
Sclera15: colección belga con un estilo característico en blanco y negro y con-
tornos gruesos, diseñada para personas con discapacidad cognitiva y comuni-
cación aumentativa. Su minimalismo busca maximizar la claridad.
Mulberry16: conjunto de símbolos con licencia libre, usados principalmente
en software educativo y herramientas de comunicación aumentativa.
SymbolStix17: colección comercial ampliamente empleada en Norteamérica,
con un estilo más colorido y cercano a los dibujos animados, utilizada en
sistemas de comunicación aumentativa y alternativa (CAA).
Widgit Symbols18: otra colección comercial con más de 20.000 pictogramas,
usada en entornos educativos y de accesibilidad, con soporte multilingüe y
adaptaciones culturales.
En la implementación de este proyecto se han cuidado criterios de eficacia comu-
nicativa: elegir símbolos claros y culturalmente neutros, mantener buen contraste,
acompañarlos de texto cuando procede y asegurar consistencia de estilo, tamaño y
posición (W3C WAI Cognitive and Learning Disabilities Accessibility Task Force,
2021; U.S. General Services Administration, 2025). De este modo, se garantiza que
los pictogramas integrados no solo cumplan una función estética, sino que contribu-
yan activamente a mejorar la comprensión y reducir la carga cognitiva del usuario.
14https://arasaac.org
15url{https://www.sclera.be}
16https://mulberrysymbols.org
17https://www.n2y.com/symbolstix-prime/
18https://www.widgit.com/about-symbols/widgit_symbol_set.htm
2.5. OlivIA 1.0 27
Figura 2.8: Matriz de pictogramas ARASAAC en una interfaz web.
2.5. OlivIA 1.0
El presente Trabajo de Fin de Grado se construye sobre el desarrollo previo de
OlivIA 1.0 (Amar, 2025), una aplicación web concebida con un enfoque centrado en
la accesibilidad cognitiva cuyo objetivo inicial fue facilitar el acceso de personas con
discapacidad intelectual a tecnologías de Inteligencia Artificial Generativa.
2.5.1. Obtención de requisitos
Los requisitos de OlivIA 1.0 se extrajeron a partir de: la revisión de literatura
sobre accesibilidad cognitiva y barreras digitales; el análisis de patrones de interac-
ción en asistentes conversacionales; y una actividad exploratoria con usuarios, donde
se observaron dificultades reales al interactuar con ChatGPT (bloqueos al iniciar la
interacción, preguntas incompletas o ambiguas, necesidad de apoyos visuales y sim-
plificación textual) (Amar, 2025). De este proceso se derivaron requisitos funcionales
y no funcionales, priorizados para construir un prototipo útil y evaluable.
Requisitos funcionales.
1. Cuestionario de perfil inicial. La aplicación debe ofrecer un cuestionario
breve que recoja nombre, dificultades principales (p. ej., textos largos, voca-
bulario complejo, organización de ideas), y preferencias de ayuda (ejemplos,
28 Capítulo 2. Estado del arte
listas con viñetas, frases cortas, texto breve). Fuente: literatura + actividad
con usuarios.
2. Personalización de respuestas. El sistema debe adaptar el prompt envia-
do al modelo según el perfil y las preferencias seleccionadas para producir
respuestas más claras (p. ej., ejemplos, viñetas, frases cortas).
3. Botones de ayuda sobre la respuesta. Deben existir acciones rápidas para
resumir,explicar con un ejemplo yreformular en lenguaje sencillo. Fuente:
actividad con usuarios.
4. Plantillas de preguntas. La interfaz debe ofrecer plantillas de inicio (p. ej.,
“Dame un ejemplo de. . . ”, “¿Qué significa. . . ?”) que faciliten la formulación sin
partir de texto en blanco.
5. Lectura en voz alta (TTS). Debe existir una opción para reproducir por
voz la respuesta mostrada (play/stop).
6. Historial de conversación en sesión. El usuario debe poder consultar men-
sajes previos de la sesión actual de forma simple.
7. Mensajería y estados claros. La interfaz debe mostrar retroalimentación
evidente de carga/éxito/error y mensajes comprensibles en lenguaje llano.
8. Teclado y foco visibles. Todos los controles deben ser operables con teclado
y mostrar foco claramente.
Requisitos no funcionales.
1. Accesibilidad web. Cumplimiento de WCAG 2.1 nivel AA (estructura se-
mántica, encabezados jerárquicos, alt en imágenes, contraste adecuado, land-
marks, navegación por teclado).
2. Accesibilidad cognitiva. Lenguaje claro, frases cortas, evitar tecnicismos
innecesarios, consistencia visual y ayudas contextuales (alineado con recomen-
daciones COGA y lectura fácil). Fuente: literatura.
3. Rendimiento. Tiempo de respuesta percibido menor de unos pocos segundos
en condiciones normales; indicadores de carga cuando aplique.
4. Compatibilidad y responsive.Funcionamiento en navegadores principales
(Chrome, Edge, Firefox) y diseño adaptable a escritorio y móvil.
5. Privacidad. No almacenar datos personales más allá de la sesión sin consen-
timiento explícito; el perfil se usa para adaptar la respuesta.
6. Arquitectura. Enfoque serverless y cliente React para facilitar despliegue y
escalabilidad.
2.5. OlivIA 1.0 29
2.5.2. Proceso de diseño
Con los requisitos priorizados se elaboraron bocetos y prototipos de baja fidelidad
que permitieron definir la estructura general de OlivIA 1.0. El diseño se centró en
asegurar una interfaz sencilla, predecible y comprensible, adaptada a las necesidades
de usuarios con discapacidad cognitiva.
Las decisiones de diseño se orientaron a simplificar tanto el aspecto visual como el
flujo de interacción. En la composición de la pantalla se establecieron tres elementos
principales: un área central de diálogo donde se muestran las preguntas y respuestas,
un panel de ayudas con accesos directos para obtener resúmenes, ejemplos o sim-
plificaciones del texto generado, y un bloque de controles de personalización. Este
último se apoyaba en un breve cuestionario inicial, que recogía las preferencias del
usuario para ajustar la experiencia de manera personalizada.
Para reducir la carga cognitiva se optó por textos breves y opciones claras, evi-
tando tecnicismos innecesarios. Además, se incorporaron plantillas de preguntas que
funcionaban como ejemplos iniciales para guiar la formulación de consultas, de modo
que el usuario no tuviera que comenzar desde cero. Del mismo modo, las ayudas con-
textuales se colocaron junto a las respuestas, asegurando que estuvieran disponibles
en el momento y lugar adecuados.
El flujo de uso se diseñó de manera lineal y predecible, siguiendo tres pasos
principales: configurar la aplicación a través del cuestionario, plantear preguntas al
asistente y recibir respuestas que podían adaptarse según las ayudas seleccionadas
por el usuario. Estas decisiones de diseño buscaban ofrecer un entorno accesible y
adaptado a la diversidad cognitiva, manteniendo la simplicidad como criterio rector.
2.5.3. Arquitectura
Visión general. OlivIA 1.0 se implementó como una aplicación web cliente de-
sarrollada con React y empaquetada con Vite, desplegada en GitHub Pages como
solución serverless. Esto implica que toda la lógica de interfaz y la composición de
prompts se ejecutan en el navegador y que las llamadas a modelos de lenguaje se
realizan directamente contra proveedores externos mediante peticiones HTTP POST.
La elección elimina la necesidad de un backend propio y simplifica el despliegue y
mantenimiento como se muestra en la Figura 2.9. Amar (2025)
Integración con LLMs. La integración con modelos de lenguaje se resolvió con
un esquema primario–respaldo: Groq como proveedor principal y OpenRouter como
alternativa. La aplicación invoca los endpoints de inferencia con el prompt generado
en el cliente y recibe la respuesta textual para su presentación. En la memoria se
documenta el uso de modelos como Meta Llama 4 Scout 17B Instruct en Groq y la
posibilidad de seleccionar, vía OpenRouter, modelos alternativos (p. ej., Mistral o
DeepSeek) según disponibilidad y tipo de tarea. Para la validación de endpoints y
payloads se empleó Apidog. Amar (2025)
Módulos principales en el cliente. La aplicación se estructura en componen-
tes React especializados: Controla el flujo general, la navegación y la conversación:
2.5. OlivIA 1.0 31
Main.jsx (montaje en el DOM), App.jsx (orquesta el paso del cuestionario a la in-
terfaz conversacional), InterfazPrincipal.jsx (controlador de la interfaz principal
y del flujo completo), Chat.jsx (gestiona el diálogo y muestra mensajes propios y
de la IA), ChatHistory.jsx (historial de conversaciones: abrir, guardar, reanudar),
yBotonesInteraccion.jsx (botones auxiliares para operar sobre la respuesta de la
IA). La personalización del usuario se recoge en Questionario.jsx, que construye
el perfil summary con useState a lo largo de un formulario progresivo de cinco pasos.
2.5.4. Funcionalidades implementadas
Además del cuestionario inicial de personalización, OlivIA 1.0 ofrecía un conjun-
to de capacidades orientadas a facilitar la formulación de consultas y la comprensión
de las respuestas del asistente:
Cuestionario inicial y ayudas contextuales. Recoge preferencias y nece-
sidades del usuario para adaptar el estilo de respuesta como se puede ver en
las Figuras 2.10, 2.11 y 2.12.
Interfaz de preguntas en dos modos. Plantillas guiadas con inicios de
frase que ayudan a estructurar la consulta; Entrada libre para escribir una
pregunta desde cero. Este planteamiento reduce barreras a la hora de iniciar
la interacción.
Módulo conversacional con apoyos a la comprensión. Tras cada res-
puesta, la interfaz ofrece acciones directas para operar sobre el contenido:
•Resumir: genera una versión breve y esencial del texto.
•Explicar con un ejemplo: añade un ejemplo sencillo y cercano.
•Lenguaje más sencillo: reformula el contenido en lectura más fácil.
•Palabras difíciles / Sinónimos: aclara términos complejos y propone al-
ternativas más comunes.
Estas ayudas actúan como “atajos cognitivos” que disminuyen la carga de
lectura y favorecen la comprensión.
Lectura en voz alta. Posibilidad de escuchar la respuesta del asistente como
apoyo multimodal.
Historial de conversación. Permite consultar y retomar conversaciones pre-
vias de manera sencilla.
Diseño visual accesible. Estructura jerárquica, contraste suficiente y com-
ponentes consistentes en toda la interfaz (véase Figura 2.13).
En conjunto, estas funcionalidades materializan los requisitos iniciales: reducir la
dificultad de formular preguntas, ofrecer apoyos explícitos para entender la respuesta
y mantener una interacción predecible y adaptable al perfil del usuario.
32 Capítulo 2. Estado del arte
Figura 2.10: Cuestionario inicial de personalización de discapacidad intelectual ne
OlivIA 1.0
Figura 2.11: Cuestionario inicial de personalización de dificultades de comprensión
en OlivIA 1.0
2.5. OlivIA 1.0 33
Figura 2.12: Cuestionario inicial de personalización de preferencias de respuestas en
OlivIA 1.0
Figura 2.13: Página inicial que muestra el diseño visual accesible en OlivIA 1.0
34 Capítulo 2. Estado del arte
2.5.5. Generación de prompts en OlivIA 1.0
La adaptación de las respuestas en OlivIA 1.0 se lograba mediante la cons-
trucción dinámica de un prompt compuesto por varias capas de información. El
proceso no consistía en enviar directamente la pregunta del usuario al modelo de
lenguaje, sino en enriquecerla con instrucciones adicionales que orientaban al mode-
lo hacia un estilo más claro, sencillo y accesible. Este enfoque seguía una lógica de
prompt engineering con cuatro bloques principales:
1. Instrucciones de sistema (estáticas). Son reglas generales que siempre
acompañan al prompt, asegurando que la salida siga criterios de accesibilidad.
Por ejemplo: utilizar frases cortas, evitar tecnicismos innecesarios, emplear
listas numeradas cuando sea posible y mantener un tono cercano.
2. Perfil del usuario (dinámico). Se construye a partir de la información
recogida en el cuestionario inicial (véanse Figuras 2.10, 2.11, 2.12). Este bloque
incluye parámetros como nivel de lectura preferido, longitud máxima de la
respuesta, necesidad de ejemplos o de resúmenes. De este modo, dos usuarios
diferentes reciben respuestas adaptadas a sus preferencias cognitivas.
3. Plantillas de tarea. Dependiendo de la ayuda contextual seleccionada (resu-
mir, dar un ejemplo, explicar en lenguaje sencillo, aclarar palabras difíciles),
se añade una instrucción específica al prompt. Por ejemplo: “Resume este texto
en 3 frases cortas” o“Explícalo con un ejemplo sencillo”.
4. Contexto conversacional. Para mantener coherencia, se añade un breve
historial de la interacción (última pregunta y respuesta). No obstante, se evita
acumular demasiado contexto para no sobrecargar al usuario con información
irrelevante ni provocar salidas demasiado largas.
Ejemplo de construcción de prompt
Supongamos que el usuario selecciona en el cuestionario:
Nivel de lectura: sencillo.
Prefiere respuestas con ejemplos.
Desea frases cortas.
Después, formula la pregunta: “¿Qué es la fotosíntesis?” y pulsa el botón de ayuda
contextual “Dame un ejemplo”. El pipeline de generación construye un prompt que
combina todos los bloques anteriores:
Eres un asistente de inteligencia artificial.
Responde de forma clara y fácil de entender.
Usa frases cortas y evita palabras técnicas.
Pregunta del usuario: "¿Qué es la fotosíntesis?"
2.5. OlivIA 1.0 35
Requisitos del usuario:
- Lenguaje sencillo.
- Respuesta breve (máximo 4 frases).
- Incluir un ejemplo.
Instrucción adicional:
"Dame un ejemplo para explicarlo mejor".
El modelo recibe este prompt completo y devuelve una respuesta como la si-
guiente:
La fotosíntesis es el proceso por el cual las plantas fabrican su alimento.
Lo hacen usando la luz del sol, el agua y el aire. Por ejemplo, una planta
toma la luz del sol y el dióxido de carbono del aire para producir oxígeno
y energía. Gracias a esto, las plantas crecen y también nos dan aire
limpio.
Este ejemplo ilustra cómo la combinación de capas, instrucciones generales, perfil
del usuario, plantilla de tarea y contexto, produce una respuesta más comprensible
y adaptada a las necesidades cognitivas de la persona usuaria.
2.5.6. Limitaciones y elementos pendientes en OlivIA 1.0.
La versión 1.0 dejó identificadas varias mejoras a abordar en trabajos posteriores:
Persistencia entre sesiones del perfil y preferencias (solo había estado lo-
cal).
Gestión global del estado más estructurada para escalar componentes y
flujos.
Motor de personalización con mayor cobertura (más niveles/granularidad
y reglas específicas por perfil).
Ampliación de ayudas (p. ej., simplificación con pictogramas, preguntas
guiadas, detección y gestión de ambigüedad).
Entrada por voz de preguntas, como apoyo multimodal.
Evaluación de accesibilidad más amplia con usuarios y validación sistemá-
tica de criterios cognitivos.
En síntesis, OlivIA 1.0 proporcionó una base técnica y de diseño sólida (re-
quisitos, prototipos, arquitectura y prompts adaptativos) sobre la que se apoya la
ampliación planteada en este TFG.
Cap´
ıtulo 3
OlivIA 2.0
Este capítulo presenta el trabajo realizado en OlivIA 2.0, una evolución del pro-
totipo OlivIA 1.0 orientada a consolidar una herramienta accesible y usable para
personas con discapacidad intelectual en su interacción con sistemas de inteligen-
cia artificial generativa. Partiendo de la versión previa, se ha llevado a cabo una
evaluación de accesibilidad (automática y manual) para identificar limitaciones y
corregirlas conforme a las pautas WCAG 2.2 y recomendaciones de accesibilidad
cognitiva. Además, se han implementado tres mejoras clave: generación de respues-
tas mediante pictogramas, un asistente de preguntas que sugiere consultas y gestiona
la ambigüedad, y la entrada por voz. Finalmente, se ha revaluado la accesibilidad de
la versión resultante a fin de verificar el impacto de los cambios. La nueva versión
de OlivIA, se encuentra https://github.com/elosotelo/TFG-OlivIA2 y se puede
probar en https://elosotelo.github.io/TFG-OlivIA2/
El capítulo se organiza del siguiente modo. En primer lugar, se detalla la eva-
luación de accesibilidad de OlivIA 1.0 (metodología, hallazgos y correcciones). Se-
guidamente, se presentan las implementaciones realizadas: el módulo de respuestas
mediante pictogramas, el asistente de preguntas (incluida la generación de preguntas
a partir de un contexto, la evaluación de ambigüedad y la reformulación guiada) y la
entrada por voz. Por último, se expone la evaluación final de accesibilidad de OlivIA
2.0.
3.1. Evaluación de la accesibilidad
Con el fin de detectar barreras de acceso y verificar la conformidad con los es-
tándares de accesibilidad, se llevó a cabo una evaluación combinada de la interfaz
que integra revisión manual y análisis automatizado. La evaluación manual se basó
en criterios de accesibilidad cognitiva, valorando claridad del lenguaje, organización
visual, consistencia, ayudas contextuales, redundancia informativa y pautas de lec-
tura fácil, aspectos especialmente relevantes para el público objetivo. En paralelo,
la evaluación automática se realizó con la herramienta WAVE (Web Accessibility
Evaluation Tool)1, ya que identifica errores frecuentes conforme a las WCAG 2.2
1https://wave.webaim.org/
37
38 Capítulo 3. OlivIA 2.0
(p. ej., contraste insuficiente, ausencia de alt en imágenes, jerarquías de encabeza-
dos incorrectas, uso inadecuado del color o falta de roles semánticos) y es la que lo
muestra de forma más visual y por tanto es la más intuitiva.
Los hallazgos combinados guiaron decisiones de rediseño en componentes, paleta
y contraste, etiquetado de controles, estructura semántica del HTML y jerarquía de
encabezados. A continuación se presentan los resultados por pantalla, cuestionario,
selector de preguntas y chat, comparando el estado inicial y el posterior a las mejoras,
lo que permitió detectar deficiencias críticas y validar las correcciones aplicadas para
garantizar una experiencia inclusiva y universal.
3.1.1. Evaluación automática con WAVE
El diagnóstico inicial de OlivIA con WAVE reveló varios problemas de accesibili-
dad que impedían la conformidad total con WCAG 2.2 y perjudicaban la experiencia
del usuario. A partir de estos hallazgos se aplicaron correcciones para alcanzar di-
cha conformidad. A continuación se describen los principales errores identificados y
cómo se solucionaron.
3.1.1.1. Pantalla de inicio
En el análisis inicial de la pantalla de inicio realizado con la herramienta WAVE,
mostrado en la Figura A.1 se observan los siguientes errores y alertas que afectaban
negativamente la experiencia de los usuarios:
Errores críticos:
Falta de etiqueta de cuestionario (<label>): Se detectó la ausencia de una
etiqueta correctamente asociada al campo principal de entrada de texto, lo
cual supone una barrera importante para los usuarios que emplean lectores
de pantalla, dificultando la identificación y el propósito del campo. Para re-
solverlo, se añadió un elemento <label> vinculado mediante el atributo for,
describiendo de forma clara la funcionalidad.
Alertas:
Falta de encabezado principal (<h1>): La herramienta WAVE informó de la
ausencia de un encabezado de primer nivel, esencial para establecer una jerar-
quía clara y facilitar la navegación estructurada mediante tecnologías asistivas.
Para solucionarlo, se incorporó un encabezado <h1> con un título descriptivo
de la pantalla, lo que permitió establecer correctamente la jerarquía semántica
del documento.
Ausencia de regiones semánticas (<main>,<header>,<nav>): No se encontra-
ron landmarks que definan secciones funcionales de la página, lo cual dificulta
la navegación por saltos y la comprensión global de la estructura. Para re-
solverlo, se añadieron las etiquetas semánticas correspondientes, delimitando
el contenido principal con <main>, el encabezado superior con <header> y la
barra de navegación con <nav>. Esta incorporación mejora la jerarquía estruc-
tural y permite a los usuarios de tecnologías asistivas desplazarse de manera
más eficiente entre las secciones de la interfaz.
3.1. Evaluación de la accesibilidad 39
De forma positiva, se comprobó que las imágenes incluían texto alternativo,
aunque en algunos casos se actualizó el atributo alt para reflejar de manera precisa
la identidad de la aplicación (cambiando «AventurIA» por «OlivIA»).
Tras aplicar las correcciones propuestas, la pantalla inicial alcanzó conformidad
con los criterios WCAG 2.1, tal como se muestra en la Figura A.2, mejorando sig-
nificativamente la accesibilidad y la experiencia inclusiva.
3.1.1.2. Cuestionario
Se realizó un análisis exhaustivo de los pasos 1, 2 y 3 del cuestionario de OlivIA
utilizando WAVE, como se observa en las Figuras A.3, A.5 y A.7. Tras la evaluación
automática se detectaron los siguientes errores:
Errores críticos:
Etiquetas vacías: Se detectaron etiquetas de cuestionario sin contenido en los
tres pasos. Esto dificulta que los lectores de pantalla transmitan información
precisa sobre el propósito de cada campo. Para solucionarlo, se añadió conte-
nido textual visible o se aplicaron atributos aria-label adecuados.
Problemas de contraste: En el paso 3, se identificó un problema de contras-
te bajo entre texto y fondo, lo cual afecta especialmente a usuarios con baja
visión. Se recomendó ajustar los colores para garantizar un ratio mínimo de
4.5:1, conforme a lo estipulado por WCAG 2.1. Para solucionarlo, se modificó
la paleta cromática de los botones y cajas de texto, incrementando la dife-
rencia entre color de fondo y texto hasta alcanzar el contraste adecuado. De
esta manera, se asegura la legibilidad incluso en condiciones de baja visión o
pantallas con poca luminosidad.
Alertas de estructura:
Falta de encabezado principal (<h1>): La ausencia de un encabezado principal
impedía establecer una jerarquía clara y coherente. Para solucionarlo, se aña-
dió un <h1> descriptivo al inicio de cada pantalla, proporcionando un punto
de referencia principal para usuarios de lectores de pantalla y mejorando la
estructura semántica global.
Encabezados potenciales no definidos: En los pasos 2 y 3 se detectaron textos
que visualmente actuaban como subtítulos, pero carecían de marcado semán-
tico (<h2>,<h3>). Se corrigió asignándoles el nivel de encabezado adecuado,
manteniendo una jerarquía lógica sin saltos (<h1> →<h2> →<h3>). Esta
mejora permite una navegación estructurada más eficiente.
Tras las correcciones aplicadas, el cuestionario alcanzó un nivel máximo de ac-
cesibilidad, tal como se evidencia en las Figuras A.4, A.6 y A.8.
3.1.1.3. Pantalla final del cuestionario
En la pantalla final (Figura A.9), el análisis con WAVE mostró resultados posi-
tivos en términos generales, aunque se identificaron áreas susceptibles de mejora:
40 Capítulo 3. OlivIA 2.0
Problemas de contraste: Se reportó un contraste insuficiente (2.47:1) en el
recuadro azul claro del resumen, el cual fue corregido incrementando el contraste
para cumplir el ratio mínimo de 4.5:1.
Alertas: La falta de encabezado principal (<h1>) marcó una alerta importante,
ya que impedía establecer un punto de referencia jerárquico en la página. Para
corregirlo, se añadió un <h1> descriptivo al inicio de la pantalla, garantizando una
jerarquía semántica adecuada y facilitando la navegación estructurada para usuarios
de tecnologías asistivas.
Gracias a estas mejoras, la pantalla final se convirtió en una sección accesible y
coherente, como se observa en la Figura A.10.
3.1.1.4. Pantalla de preguntas
En la pantalla de preguntas (Figura A.11), se identificaron mejoras necesarias
relacionadas con el etiquetado y la estructura semántica:
Errores críticos: Falta de etiqueta en el campo de entrada principal. Se corrigió
mediante un <label> asociado o aria-label.
Alertas:
Ausencia de región semántica (<main>): La página carecía de landmarks que
delimitaran el contenido principal, dificultando la navegación por secciones con
tecnologías asistivas. Para solucionarlo, se incorporó un contenedor <main> que
agrupa el contenido central de la pantalla, facilitando así la comprensión global
y la navegación estructurada.
Jerarquía de encabezados incompleta: Se detectó un salto directo de <h1> a
<h3>, lo que rompía la secuencia lógica de la jerarquía semántica. La estructura
se reorganizó introduciendo los niveles intermedios (<h2>) correspondientes,
garantizando una progresión coherente y accesible de los encabezados.
Tras estas correcciones, la pantalla cumplió con los estándares de accesibilidad,
como se muestra en la Figura A.12.
3.1.1.5. Pantalla de chat
En la pantalla de chat (Figura A.14), se identificaron los siguientes aspectos:
Errores críticos: Campo de entrada sin etiqueta accesible. Corregido con <label>
oaria-label.
Errores de contraste: Insuficiencia de contraste en botones interactivos, solu-
cionado aumentando el contraste a ratio 4.5:1.
Alertas detectadas por WAVE:
Falta de regiones semánticas: Se incorporaron etiquetas semánticas como <main>
para delimitar el contenido principal y <nav> para la barra de navegación, fa-
cilitando así la navegación estructurada con lectores de pantalla.
Salto en la jerarquía de encabezados (uso de <h3> sin <h2>): Se reorganizaron
los encabezados HTML asegurando que cada nivel (<h1>,<h2>,<h3>, etc.)
3.1. Evaluación de la accesibilidad 41
siguiera un orden jerárquico coherente, sin saltos, para garantizar la correcta
interpretación semántica y visual del contenido.
Tras la implementación de mejoras, la pantalla se alineó con WCAG 2.1, como
se ve en la Figura A.15.
3.1.2. Evaluación manual
La evaluación manual se ha realizado con base en criterios de accesibilidad cog-
nitiva y Lectura Fácil (LF), priorizando: lenguaje claro (palabras frecuentes, evitar
tecnicismos y abstracciones), oraciones cortas (una idea por frase, preferiblemente
<15–20 palabras), estructura visual predecible (títulos, bloques, listas), consistencia
de persona, tiempo y género, apoyos visuales con texto asociado, y retroalimenta-
ción en el contexto. Estos criterios son especialmente relevantes para personas con
discapacidad intelectual y usuarias con baja alfabetización.
A continuación se describen, para cada pantalla, los hallazgos y las correcciones
aplicadas.
3.1.2.1. Pantalla de inicio
Para evaluar la accesibilidad cognitiva de la interfaz, se ha realizado una evalua-
ción manual centrada en la pantalla de inicio de OlivIA (Figura A.13).
Desde el punto de vista del lenguaje se han detectado los siguientes errores:
Términos técnicos y abstractos: “compañero/a digital de Inteligencia Artificial”
y “compañera digital única” son expresiones complejas para el público objetivo.
Frases largas o con varias ideas a la vez: la frase “Hoy vas a diseñar a OlivIA, tu
compañera digital única, hecho a tu medida.” combina varias ideas y aumenta
la carga cognitiva.
Inconsistencia de género: “compañera digital única, hecho a tu medida” (dis-
cordancia femenino/masculino).
Redundancias semánticas: “compañera digital única” y “a tu medida” comuni-
can ideas similares.
Apoyos faltantes: No hay botón de ayuda/lectura en voz alta visible junto al
contenido principal.
En cuanto a la organización visual, los elementos están distribuidos de manera
jerárquica y equilibrada. El título principal está claramente diferenciado por tamaño
y peso tipográfico. Las instrucciones se presentan inmediatamente después en un
párrafo breve, lo que facilita su escaneo visual. La pregunta “¿Cómo te llamas?” está
ubicada en una zona predecible de la interfaz, acompañada de un campo de entrada
con un marcador de posición que anticipa la acción esperada.
La consistencia en el uso de colores, tipografías y alineaciones refuerza la estruc-
tura cognitiva de la pantalla. Además, el botón de acción “Siguiente” tiene un diseño
42 Capítulo 3. OlivIA 2.0
Figura 3.1: Pantalla del paso 1 del cuestionario personalizado en OlivIA.
claramente distinguible, con un color de contraste alto y una etiqueta textual explí-
cita que describe la acción que realizará. El icono situado junto al texto principal
(emoticono de robot) y los pictogramas al pie de la pantalla aportan claves visua-
les complementarias, apoyando la redundancia informativa, lo cual es especialmente
beneficioso para usuarios con dificultades lectoras.
No obstante, se identifican algunas oportunidades de mejora. La ausencia de
un botón de ayuda o lectura en voz alta limita la accesibilidad multisensorial, y la
falta de iconografía junto al campo de entrada podría dificultar la comprensión para
usuarios con menor alfabetización funcional. Asimismo, sería conveniente incorporar
descripciones accesibles para los elementos gráficos mediante atributos como alt o
aria-label, con el fin de garantizar compatibilidad con lectores de pantalla.
Para solucionar estos errores se implementaron las siguientes mejoras:
Se simplificó el lenguaje eliminando tecnicismos como “Compañera Digital de
Inteligencia Artificial”. El nuevo título es más breve y claro: “Vamos a crear tu
asistente”.
Se dividieron las frases largas en oraciones más cortas, con una sola idea por
frase.
Se corrigieron problemas de concordancia de género (“única / hecho a tu me-
dida” →“única / hecha a tu medida”).
Se añadió <label> yaria-describedby al campo de entrada del nombre.
Se incorporaron landmarks semánticos (<main>,<header>) y jerarquía correc-
ta de encabezados.
3.1.2.2. Paso 1 del cuestionario
La Figura 3.1 muestra el paso 1 del proceso de configuración de OlivIA, en el
que se pregunta al usuario con qué perfil o dificultad se siente más identificado.
Desde el punto de vista del lenguaje se han detectado los siguientes errores:
3.1. Evaluación de la accesibilidad 43
Mensaje correcto en tono y extensión, pero faltaba explicar para qué se usa la
información (transparencia).
Etiquetas breves con siglas (TEA) sin explicación accesible (texto o tooltip).
En lo relativo a la organización visual, los elementos están bien distribuidos
verticalmente, con márgenes amplios que favorecen la legibilidad. Cada opción de
respuesta está presentada dentro de un botón claramente delimitado, con un inte-
rruptor tipo toggle para activar o desactivar la selección. Esta estructura facilita la
interacción y evita ambigüedad visual.
La consistencia se mantiene en el diseño gráfico de los botones, el estilo de los
iconos y la tipografía. Las etiquetas son cortas (“TEA”, “Dislexia”, “Memoria”, etc.)
muy útil para personas con dificultades de lectura o comprensión verbal.
Además, la inclusión de opciones como “No responder” u “Otra opción” demues-
tra sensibilidad hacia la diversidad de usuarios, permitiendo que cada persona in-
teractúe sin sentirse forzada a encasillarse. Este tipo de decisiones de diseño son
fundamentales para favorecer la inclusión y respetar la autonomía del usuario.
Como oportunidad de mejora podría contemplarse la posibilidad de añadir un
breve texto o símbolo que explique la finalidad de esta pregunta, especialmente si el
cuestionario es utilizado por personas con menor competencia digital.
Para solucionar estos errores se realizaron los siguientes cambios:
Título simplificado: “Paso 1. Cada persona es diferente”.
Se añadió una explicación breve sobre la finalidad de la pregunta.
Las opciones (TEA, TDAH, etc.) se acompañaron de iconos y explicación breve
de siglas.
Agrupación en <fieldset> y<legend> para mejorar la navegación con tec-
nologías de apoyo.
Conmutadores accesibles con aria-label y estado visual activo.
Inclusión de la opción “No responder”, respetando la autonomía del usuario.
3.1.2.3. Paso 2 del cuestionario
La Figura 3.2 muestra el paso 2 del cuestionario de configuración de OlivIA,
que busca identificar qué aspectos del lenguaje o la comunicación suponen mayores
dificultades para el usuario.
El texto principal destaca por lo siguiente:
Título motivador, pero algo abstracto (“sea tu mejor guía”).
Falta de ejemplos concretos bajo cada opción (apoyo a la comprensión).
La organización visual del contenido es coherente con la pantalla anterior, lo que
refuerza la consistencia y reduce la carga cognitiva. Las opciones están presentadas
como botones independientes, cada uno acompañado de un icono y un conmutador
44 Capítulo 3. OlivIA 2.0
Figura 3.2: Pantalla del paso 2 del cuestionario de configuración en OlivIA.
(“No” activado por defecto). Esta disposición segmentada facilita el reconocimiento
de cada alternativa y la toma de decisiones, reduciendo la posibilidad de error.
Además, el diseño contempla variedad funcional: se permite seleccionar múlti-
ples respuestas y se incluye una opción abierta (“Otra opción”), lo cual proporciona
flexibilidad y respeto a la individualidad del usuario. También se mantiene la posi-
bilidad de navegación entre pasos con los botones “Anterior” y “Siguiente”, ambos
claramente visibles y etiquetados.
Como mejora potencial, podría añadirse una breve explicación contextual (me-
diante un ícono de ayuda opcional) sobre cómo se usará esta información, aumen-
tando la transparencia y comprensión del proceso.
Para solucionarlo se hicieron los siguientes cambios:
Título simplificado: “Paso 2. ¿Qué te cuesta más?”.
Cada opción incluye un ejemplo entre paréntesis para facilitar la comprensión
(p. ej. “Textos largos (mucho texto)”).
Agrupación en <fieldset> con <legend>.
Conmutadores con etiquetas claras y aria-label.
Instrucción explícita indicando que se pueden seleccionar varias opciones.
3.1.2.4. Paso 3 del cuestionario
La Figura 3.3 muestra la tercera pantalla del proceso de configuración persona-
lizada de OlivIA, donde se propone adaptar el estilo de respuesta de la inteligencia
artificial a las preferencias cognitivas del usuario.
Desde el punto de vista del lenguaje se destaca lo siguiente:
Título correcto pero con metáfora (“dar personalidad”) que puede resultar
abstracta.
3.1. Evaluación de la accesibilidad 45
Figura 3.3: Pantalla del paso 3 del cuestionario de configuración en OlivIA.
Ejemplos útiles, pero algunas frases largas.
Desde el punto de vista visual, las opciones están organizadas en tarjetas inde-
pendientes, con bordes delimitados, color de fondo diferenciado y ejemplos textuales
que ilustran el efecto de cada preferencia seleccionable (por ejemplo, usar ejemplos,
frases cortas, listas en viñetas o texto breve). Este uso de ejemplos visuales concre-
tos es una estrategia muy efectiva para usuarios con dificultades de abstracción o
comprensión, ya que permite anticipar el resultado sin ambigüedad.
Cada bloque incorpora un interruptor para activar o desactivar la opción corres-
pondiente, manteniendo la consistencia respecto a las pantallas anteriores. Además,
se hace uso de iconos (emoji, lápiz, tijera, viñetas), esta redundancia comunicativa
contribuye a una mayor accesibilidad para personas con discapacidad cognitiva o
baja alfabetización funcional.
Los colores de fondo, las líneas de separación y los tamaños de fuente utiliza-
dos respetan los principios de jerarquía visual. La presentación de la información
por bloques bien diferenciados evita la sobrecarga y favorece la segmentación del
contenido.
Como recomendación de mejora, podría añadirse una opción de “vista previa
dinámica” que simule cómo serían las respuestas con las distintas combinaciones se-
leccionadas. También se sugiere incluir accesibilidad semántica a través de atributos
como aria-label en los interruptores, para favorecer el uso con lectores de pantalla.
Para solucionar los errores se realizaron los siguientes cambios:
Título directo: “Paso 3. ¿Cómo quieres las respuestas?”.
Opciones con nombres claros: “Con ejemplos”, “Listas con puntos”, “Texto bre-
ve”, “Frases cortas”, “Pictogramas”.
Ejemplo simple bajo cada opción para anticipar el resultado.
En la opción “Pictogramas” se añadió un ejemplo visual acompañado de ex-
plicación textual accesible.
Uso de aria-label y textos alternativos descriptivos en imágenes.
46 Capítulo 3. OlivIA 2.0
Figura 3.4: Pantalla final de resumen de configuración en OlivIA.
3.1.2.5. Pantalla de resumen
La Figura 3.4 muestra la pantalla final del proceso de configuración de OlivIA,
en la que se presenta un resumen de las elecciones realizadas por el usuario, seguido
de una confirmación para comenzar a utilizar la aplicación.
La pantalla se inicia con un mensaje de confirmación positiva (“¡OlivIA está
lista para ayudarte!”), acompañado de un icono simbólico (cohete), lo cual comunica
entusiasmo y cierre de ciclo de manera emocionalmente accesible. El texto “Gracias
por contarme cómo puedo ayudarte mejor” refuerza el tono empático y personal que
ha acompañado todo el proceso.
El recuadro central, que contiene el resumen de la configuración, sigue un diseño
limpio y estructurado. Se utilizan emojis y etiquetas de colores para identificar cada
ítem (nombre, dificultades, herramientas), lo que aporta redundancia informativa
y facilita el reconocimiento visual. El uso de un fondo azul claro con borde negro
permite distinguir el bloque del resto del contenido, mejorando la jerarquía visual.
Cada sección del resumen está identificada con una frase corta y directa, seguida
del contenido seleccionado o un marcador de “No seleccionado”, lo cual proporciona
retroalimentación inmediata al usuario. Esta claridad es fundamental para personas
con dificultades de memoria o atención, que necesitan verificar sus elecciones antes
de avanzar.
En la parte inferior se presenta una pregunta directa y sencilla: “¿Quieres conocer
a tu nueva compañera?”, con dos botones de respuesta claramente etiquetados y
diferenciados por color: “No, quiero cambiar algo” (gris con icono) y “Sí, estoy listo”
(verde con check). Este diseño facilita la toma de decisiones y previene errores de
navegación, alineándose con los principios de usabilidad y accesibilidad cognitiva.
Como mejora, se podría considerar un breve refuerzo visual adicional cuando no
se ha completado algún paso (por ejemplo, un icono de advertencia junto a campos
vacíos) para facilitar la revisión sin necesidad de volver atrás sin guía. También sería
recomendable garantizar que todos los elementos visuales cuenten con descripciones
accesibles para tecnologías asistivas, como lectores de pantalla.
Se han implementado los siguientes cambios:
3.1. Evaluación de la accesibilidad 47
Figura 3.5: Pantalla de entrada con preguntas en OlivIA.
Título simplificado: “Paso final. OlivIA está lista”.
Resumen estructurado con bloques claramente identificados: nombre, identifi-
cación, dificultades y herramientas.
Botones con etiquetas simples y autoexplicativas: “Cambiar algo” y “Empezar”.
Imágenes decorativas marcadas como alt= para evitar redundancia en lectores
de pantalla.
3.1.2.6. Pantalla de preguntas
La Figura 3.5 muestra la interfaz principal de interacción con OlivIA, en la que
el usuario puede elegir entre varias plantillas de preguntas predefinidas o formular
una nueva desde cero. Esta pantalla es clave para facilitar la interacción con la
inteligencia artificial, especialmente en personas con dificultades cognitivas o de
formulación lingüística. La evaluación se ha centrado en los criterios de accesibilidad
cognitiva: claridad, estructura visual, asistencia contextual y flexibilidad.
El encabezado “Hola ¿Qué vamos a aprender hoy?” establece un tono cercano,
positivo y orientado a la acción. El uso de lenguaje inclusivo y emocionalmente
accesible favorece la implicación del usuario desde el primer momento.
En el centro de la pantalla se presentan seis botones de plantillas de pregunta con
frases incompletas (por ejemplo, “Dame un ejemplo de ...” o “¿Qué significa ...?”),
distribuidos en un diseño de rejilla de dos filas por tres columnas. Cada botón tiene
un color de fondo distinto, lo que mejora la segmentación visual y permite a usuarios
con dificultades de lectura localizar más fácilmente sus opciones. El diseño visual de
las cajas sigue una estructura simétrica y sencilla, lo que reduce la carga cognitiva.
Debajo de las plantillas, se presenta un botón gris con la opción “Formular una
pregunta desde cero”. Esta alternativa ofrece mayor libertad a usuarios con mayor
competencia lingüística, sin excluir a quienes requieren apoyo estructurado. Más aba-
jo, el campo de entrada libre aparece acompañado de la etiqueta “Escribe aquí. . . ”
48 Capítulo 3. OlivIA 2.0
Figura 3.6: Pantalla de respuesta de OlivIA en modo conversacional.
y un botón de acción con texto e icono accesible: “¡Descubrir Respuesta!”. El icono
de lupa refuerza visualmente la funcionalidad del botón.
Desde una perspectiva de accesibilidad cognitiva, esta pantalla cumple de forma
ejemplar con los principios de personalización, orientación y simplicidad. Permite
distintos niveles de apoyo, presenta opciones claras y repetibles, y reduce la necesidad
de redactar desde cero. Esto es especialmente útil para personas con discapacidad
intelectual leve, dislexia o trastornos del lenguaje expresivo.
Como mejora potencial, podría añadirse retroalimentación por voz opcional o
pictogramas junto a las plantillas para apoyar a usuarios no lectores. También sería
recomendable proporcionar ejemplos dinámicos o desplegables que muestren cómo
se completaría cada frase para quienes necesiten guía paso a paso.
En relación a la lectura fácil destaca:
Título correcto pero algo largo (“¿Qué vamos a aprender hoy?”) para el primer
impacto.
Plantillas útiles; faltaba texto de ayuda muy corto bajo cada plantilla.
3.1.2.7. Pantalla de interacción con el chat
La Figura 3.6 representa una de las pantallas clave del flujo de uso de OlivIA: el
entorno conversacional donde el usuario interactúa directamente con la inteligencia
artificial. Esta evaluación se centra en cómo se presenta la respuesta de la IA, qué
apoyos adicionales se ofrecen al usuario y qué recursos se integran para facilitar la
comprensión en personas con discapacidad cognitiva.
En la parte superior se muestra el botón de historial (“Abrir Historial”) y el
botón de configuración, ambos accesibles visualmente mediante iconos reconocibles
y texto claro, lo cual facilita la navegación incluso para personas con dificultades de
memoria o atención.
La respuesta de OlivIA aparece centrada en pantalla dentro de una tarjeta de
texto con borde redondeado, fondo blanco y fuente clara. Se presenta un listado de
sinónimos de forma vertical y con separación de líneas, lo que mejora la legibilidad.
3.2. Ampliaciones y mejoras en la nueva versión de OlivIA 49
Al final del mensaje aparece un botón de audio con icono, lo que permite activar la
lectura en voz alta de la respuesta. Esta funcionalidad es fundamental para personas
con dislexia, dificultades lectoras o baja alfabetización funcional.
Debajo de la respuesta, se ofrece un bloque de ayuda contextual con la pregunta
“¿Quieres que te ayude a entenderlo mejor?”, seguida de múltiples opciones: “Explí-
came con un ejemplo”, “Dame un resumen”, “Responder en lenguaje más sencillo”
y “No, gracias”. Estos botones actúan como apoyos estructurados y promueven la
comprensión incremental del contenido. Su diseño visual por color (azul, verde, rojo
y gris) ayuda a distinguir las acciones y facilita la toma de decisiones. Además, el
uso de un emoji en el encabezado refuerza el tono amigable.
Finalmente, se incluye un bloque adicional con la opción “¿Prefieres formular
la pregunta desde cero?”, con fondo amarillo y formato de botón extendido. Esta
redundancia funcional permite al usuario retomar el control y navegar según su
preferencia, lo cual es esencial para la accesibilidad cognitiva.
En conjunto, esta pantalla ejemplifica una interacción adaptativa: no solo entrega
una respuesta, sino que ofrece múltiples caminos para reformular o profundizar la
comprensión. La información está jerárquicamente organizada, el lenguaje es claro
y accesible, y se proporciona ayuda visual y funcional constante.
Como posibles mejoras, se podría valorar añadir pictogramas junto a los botones
para reforzar el significado semántico, así como implementar una barra de progreso
que indique que se está dentro de un flujo conversacional.
Cambios globales:
Lenguaje simplificado según pautas de lectura fácil: frases cortas, sin tecnicis-
mos, con ejemplos cuando era necesario.
Correcciones de concordancia y eliminación de redundancias.
Implementación de landmarks semánticos y jerarquía correcta de encabezados.
Inclusión de redundancia informativa: texto + icono.
Homogeneidad en el uso de conmutadores, botones y tarjetas.
3.2. Ampliaciones y mejoras en la nueva versión de
OlivIA
En esta fase del desarrollo, se ha puesto especial énfasis en la mejora de la
accesibilidad de la interfaz.
Además del refuerzo de la accesibilidad, esta versión introduce nuevas funciona-
lidades diseñadas para facilitar la interacción de los usuarios con la IA generativa,
eliminando barreras cognitivas y ampliando las posibilidades de comunicación:
Pictogramas como apoyo visual: se ha incorporado un sistema de res-
puesta aumentada mediante pictogramas, generados dinámicamente a partir
del contenido textual de la IA. Esta salida alternativa facilita la comprensión
50 Capítulo 3. OlivIA 2.0
de conceptos clave para personas con dificultades lectoras, discapacidad inte-
lectual o trastornos del espectro autista (TEA). Para ello se ha utilizado el
repositorio abierto de pictogramas de ARASAAC2, ampliamente validado en
contextos educativos, sanitarios y de señalética pública.
Entrada de voz: se ha habilitado un sistema de reconocimiento de voz que
permite al usuario enviar peticiones habladas al modelo de IA, eliminando la
necesidad de escribir. Esta funcionalidad mejora la accesibilidad para usuarios
con dificultades motoras, de lectoescritura o que presentan baja alfabetiza-
ción digital. Además, reduce el esfuerzo cognitivo asociado a la planificación y
redacción textual.
Generador automático de preguntas: se ha desarrollado un sistema basa-
do en plantillas guiadas, que permite al usuario construir preguntas seleccio-
nando opciones predefinidas. Esta solución responde a una necesidad detectada
en la fase previa: muchas personas con discapacidad cognitiva tienen dificul-
tades para estructurar correctamente una consulta en lenguaje natural. Las
plantillas actúan como soporte semántico y sintáctico, reduciendo la carga de
formulación y mejorando la precisión de las peticiones.
Las mejoras implementadas no sólo amplían la funcionalidad de la herramienta,
sino que suponen un paso importante hacia la accesibilidad en entornos de inteligen-
cia artificial. Al contemplar diferentes formas de entrada y salida de información,
y al guiar la interacción con apoyos visuales y estructurales, OlivIA se adapta a
un espectro más amplio de usuarios, promoviendo su autonomía, participación y
comprensión en el uso de tecnologías avanzadas.
Este enfoque refuerza el valor de la herramienta en contextos educativos, tera-
péuticos y de inclusión digital, donde la equidad de acceso a la información es un
componente esencial.
3.2.1. Respuestas con pictogramas
Una de las funcionalidades principales implementadas en esta aplicación es la
posibilidad de generar respuestas con pictogramas. Esta característica está orientada
a facilitar la comprensión del contenido por parte de personas con dificultades del
lenguaje a las que con un soporte visual las comprensión de textos resulta más
sencilla.
El uso de pictogramas permite representar conceptos de forma más intuitiva y
directa, eliminando en gran medida la ambigüedad que puede presentar el lenguaje
escrito. De este modo, se busca que el sistema no solo sea funcional, sino también
inclusivo y adaptado a distintos perfiles de usuario.
A lo largo de este apartado se describe el funcionamiento de este sistema de
traducción a pictogramas, desde el procesamiento del texto hasta su representación
final en la interfaz.
En primer lugar se añadió en el cuestionario de personalización la opción de que
se de la respuesta en pictogramas.
2https://beta.arasaac.org
3.2. Ampliaciones y mejoras en la nueva versión de OlivIA 51
3.2.1.1. Generación del prompt
Una de las principales aportaciones de OlivIA es la capacidad para adaptar diná-
micamente el prompt enviado al modelo de lenguaje, en función de las características
cognitivas y necesidades de accesibilidad del usuario. Este flujo adaptativo ya existía
en la versión anterior, pero ha sido extendido con la implementación de un nuevo me-
canismo específico para generar respuestas basadas en pictogramas. A continuación
se describen los cambios realizados.
En la versión anterior, al introducir una pregunta, el sistema recogía el perfil
del usuario, específicamente su discapacidad, retos y herramientas y generaba un
prompt textual en el siguiente formato:
Hola, respóndeme a esta pregunta y dame la respuesta directamente sin
introducción: [PREGUNTA DEL USUARIO]
Pero ten en cuenta estas instrucciones al responder:
Mi Discapacidad: [DISCAPACIDAD(ES)]
NO uses: [RETOS A EVITAR]
Quiero que me generes la respuesta usando: [HERRAMIENTAS]
Este prompt era enviado directamente a un modelo de lenguaje, que respondía
con un bloque de texto, sin ningún procesamiento posterior. La mejora introducida
para este TFG consiste en un cambio explícito del prompt cuando el usuario se-
lecciona “pictogramas” como herramienta de accesibilidad. En este caso, se fuerza
al modelo a generar una respuesta más estructurada y segmentada, lo cual facili-
ta su posterior transformación a pictogramas. La instrucción que se introduce es:
Responde en bullets y usando frases muy cortas:
Con ello, el prompt completo que se genera tendría este formato:
Hola, respóndeme a esta pregunta y dame la respuesta directamente sin
introducción: Responde en bullets y usando frases muy cortas: [PRE-
GUNTA DEL USUARIO]
Pero ten en cuenta estas instrucciones al responder:
Mi Discapacidad: [DISCAPACIDAD(ES)]
NO uses: [RETOS A EVITAR]
Quiero que me generes la respuesta usando: pictogramas + [HE-
RRAMIENTAS]
Esta adaptación del prompt tiene un doble propósito:
Asegurar que el modelo divida su respuesta en frases independientes, cortas y
sin tecnicismos para que las respuesta mediantes pictogramas sea más util y
concisa.
Facilitar el tratamiento posterior frase a frase para la conversión de palabras
clave en pictogramas.
52 Capítulo 3. OlivIA 2.0
3.2.1.2. Traducción de texto a pictogramas
Una vez generada la respuesta textual mediante el modelo LLM, se inicia el
proceso de conversión visual palabra a palabra. El sistema divide la frase en unidades
léxicas significativas, omitiendo preposiciones y otras stopwords3, que se encuentran
en un listado, antes de buscar pictogramas. Para cada palabra resultante se lanza una
petición HTTP a la API pública de ARASAAC4. La respuesta de esta API consiste
en un array JSON, donde cada elemento representa un pictograma disponible
para la palabra consultada. Cada objeto de este array contiene un identificador
único asignado a cada pictograma. Es un valor alfanumérico que permite construir
la URL a la imagen del pictograma con la siguiente sintaxis:
https://static.arasaac.org/pictograms/[ID]/[ID]_500.png
Por ejemplo, si la API devuelve el siguiente objeto:
{ "_id": "12345", "keywords": [...], ... }
La imagen del pictograma correspondiente se obtiene desde:
https://static.arasaac.org/pictograms/12345/12345_500.png
Esta abstracción permite separar la lógica visual de la textual, centralizando la
carga en una URL autogenerada, reutilizable y fácilmente trazable. Si una palabra
no tiene ningún resultado asociado, se omite directamente del flujo de generación
visual. Este comportamiento se debe a que no todos los términos o expresiones del
lenguaje natural tienen un pictograma correspondiente en el repositorio de ARA-
SAAC. Por tanto, es necesario aplicar una lógica selectiva para evitar resultados
vacíos o incoherentes. Además, la conservación del identificador _id para cada pic-
tograma facilita su trazabilidad y depuración durante fases de desarrollo o testing,
permitiendo reconstruir la cadena completa de traducción desde palabra clave a
imagen.
En este punto, también se contempla el control de errores en las respuestas
de la API. Si una petición falla (por ejemplo, por un error de red o de formato
inesperado), el sistema captura la excepción mediante bloques try/catch y descarta
silenciosamente esa palabra, evitando que se interrumpa el procesamiento del resto
del contenido.
El flujo de esto se puede ver en la Figura 3.7.
3.2.1.3. Visualización de pictogramas
La visualización de los pictogramas se organiza en dos niveles, como se puede
observar en la Figura 3.8:
3En este caso, se consideran stopwords aquellas palabras funcionales sin valor semántico rele-
vante (como “de”, “la”, “y”) que se eliminan del texto para evitar generar pictogramas innecesarios
o vacíos.
4https://beta.arasaac.org/developers/api
3.2. Ampliaciones y mejoras en la nueva versión de OlivIA 53
Nivel horizontal: cada frase se transforma en una fila (array) de palabras cla-
ve, donde cada palabra representa una celda visual. Estas celdas se presentan
en una línea horizontal para imitar la estructura gramatical de la oración.
Nivel vertical por palabra: cada celda contiene una lista doblemente enla-
zada de pictogramas, que se puede recorrer mediante botones de navegación
(flechas) ya que una palabra puede tener varios pictogramas asociados y este
diseño permite al usuario visualizar diferentes pictogramas alternativos para
una misma palabra y que así pueda utilizar el que más le guste y además tener
más opciones de pictogramas, si existen, para entender mejor a qué se refiere
la palabra.
El usuario puede utilizar las flechas arriba/abajo para recorrer los pictogramas
disponibles. Si solo existe un pictograma para una palabra, las flechas no se muestran,
y la imagen se centra verticalmente con el resto para mantener la alineación visual.
Para mejorar la experiencia de usuario, el proceso de recuperación y renderizado
de pictogramas se realiza de forma asíncrona. Técnicamente, esto se implementa
utilizando funciones async/await y promesas en el cliente, que permiten continuar el
procesamiento del resto del contenido mientras las imágenes se descargan en segundo
plano. Esto evita que la interfaz quede bloqueada y permite una respuesta más fluida
en entornos con conexiones lentas o inestables.
Internamente, cada nodo de la lista enlazada contiene:
La imagen del pictograma (derivada del _id).
Un índice activo (selectedIndex) para controlar el pictograma actualmente
mostrado.
Referencias implícitas a los anteriores y siguientes pictogramas mediante na-
vegación circular.
Este sistema garantiza tanto accesibilidad como flexibilidad semántica, ya que
permite elegir entre múltiples representaciones gráficas de una misma palabra sin
recargar la pantalla ni comprometer la usabilidad.
3.2.2. Asistente de preguntas
El asistente de preguntas está formado por dos partes, la primera que genera
preguntas a partir de un contexto y la segunda que evalua las preguntas formuladas
por el usuario de forma que si considera que falta contexto o es ambigua pide más
información al usuario y la refomula.
3.2.2.1. Generador de preguntas a partir de un tema
La funcionalidad de generación automática de preguntas en OlivIA responde al
objetivo de apoyar a personas con dificultades cognitivas o baja iniciativa comu-
nicativa, facilitando el proceso de formular preguntas relevantes y concretas. Esta
característica resulta especialmente útil para usuarios que presentan dificultades
54 Capítulo 3. OlivIA 2.0
Figura 3.7: Flujograma del proceso de conversión de texto a pictogramas
3.2. Ampliaciones y mejoras en la nueva versión de OlivIA 55
Figura 3.8: Ejemplo visual de como se muestran las respuestas en pictogramas en
OlivIA
para estructurar sus ideas o para quienes encuentran complejo iniciar una conversa-
ción desde cero. Esta funcionalidad se inspira en estrategias de aprendizaje guiado
y en principios de accesibilidad cognitiva, donde disponer de apoyos estructurados
fomenta la autonomía y la participación activa.
El generador se activa únicamente cuando la persona usuaria selecciona la opción
“Formular una pregunta desde cero” y ha introducido un tema en el campo de texto
asociado. De este modo, la herramienta solo se habilita cuando existe un contexto
temático definido, evitando sugerencias genéricas o irrelevantes. Una vez cumplidas
estas condiciones, aparece un botón que permite solicitar preguntas automáticas
directamente relacionadas con el tema introducido.
Al pulsar el botón, el sistema construye un mensaje dinámico (prompt) que se
envía al servicio de inteligencia artificial. Este mensaje solicita la creación de cuatro
preguntas concisas y claras sobre el tema indicado, evitando tecnicismos innecesarios
y priorizando la simplicidad. Un ejemplo de prompt generado es el siguiente:
Genera 4 preguntas claras y concisas sobre el tema: "energías renovables".
El flujo consiste en que cuando el usuario selecciona la opción “Formular una
pregunta desde cero” e introduce un tema en el campo de texto se habilita el botón
de generación de preguntas automáticas. Al pulsar el botón, se envía el prompt
dinámico al servicio de IA solicitando que formule 4 preguntas relacionadas con el
tema y la IA devuelve cuatro preguntas en formato de lista, se almacenan en el estado
global del componente y se muestran en la interfaz como elementos interactivos.
Cada una se presenta en forma de botón, lo que permite seleccionarla y enviarla
directamente al asistente conversacional sin necesidad de escritura manual como se
muestra en la Figura 3.9, listos para ser seleccionados y enviados al chat.
56 Capítulo 3. OlivIA 2.0
Figura 3.9: Generador de preguntas de OlivIA.
3.2.2.2. Asistente de reformulación de preguntas
Otra de las funcionalidades clave de OlivIA, dentro del asistente de preguntas,
es el sistema de detección y gestión de ambigüedad en las consultas. Su finalidad
es identificar preguntas mal formuladas, demasiado breves o carentes de contexto,
que podrían dar lugar a respuestas inadecuadas por parte del modelo de lenguaje.
Esta capacidad resulta especialmente relevante en un entorno de accesibilidad cog-
nitiva, ya que permite anticipar errores de comunicación y guiar al usuario hacia
interacciones más claras y eficaces.
El mecanismo se integra en el hook usePromptFunctions, donde se concentra la
lógica tanto de detección como del flujo posterior de aclaración y reformulación de
las preguntas.
Proceso de evaluación
La evaluación combina dos niveles: un primer filtrado basado en reglas heurís-
ticas y una validación semántica mediante el propio modelo de lenguaje.
En la primera fase se aplican patrones sencillos que marcan como potencial-
mente ambiguas aquellas preguntas muy cortas (con cuatro palabras o menos)
o que comienzan con partículas interrogativas generales como “qué”, “cómo” o
“por qué”. No obstante, para evitar falsos positivos, se incorpora una lista de
excepciones con estructuras claras y frecuentes, como “qué es X” o “dame un
ejemplo de X”, que se consideran explícitamente no ambiguas pero que aún así
son evaluadas por la IA.
Cuando la heurística detecta una posible ambigüedad, se pasa a una segunda
fase de validación a través del modelo de lenguaje. Para ello se construye un
mensaje instructivo muy concreto, en el que se pide al modelo que clasifique
la pregunta únicamente como “sí” (ambigua) o “no” (clara), siguiendo un con-
junto de reglas predefinidas. Este enfoque de prompting instructivo reduce la
3.2. Ampliaciones y mejoras en la nueva versión de OlivIA 57
probabilidad de interpretaciones erróneas y garantiza mayor consistencia en la
clasificación.
Gestión de la interacción
Si la pregunta se confirma como ambigua, el sistema no la envía directamente
al asistente, sino que abre un flujo específico de aclaración. En este punto, se
guarda la pregunta original y se notifica al usuario con un mensaje sencillo del
tipo: “Tu pregunta no está clara. ¿Puedes darme más información sobre lo que
quieres saber?”.
Se habilita entonces un nuevo campo de entrada en el que la persona puede
añadir una o varias aclaraciones. Estas se almacenan secuencialmente en un
array y forman el contexto sobre el cual se construirá la siguiente etapa del
proceso.
Generación de reformulaciones
Cuando el usuario aporta al menos una aclaración, el sistema combina toda la
información recogida (la pregunta original más las aclaraciones adicionales) en
un nuevo mensaje que se envía al modelo de lenguaje. Este mensaje solicita la
generación de tres reformulaciones alternativas de la pregunta, con la condición
de que sean claras, breves y fáciles de comprender.
Las reformulaciones devueltas se presentan en la interfaz como opciones in-
teractivas. Cada una aparece en forma de botón, de manera que el usuario
solo tiene que elegir la que mejor se ajuste a su intención para continuar la
conversación sin necesidad de redactarla manualmente.
Si la pregunta que quería hacer el usuario no se encuentra en el listado se vuelve
a hacer este proceso, pidiendo más información y aumentando el contexto para
la generación de nuevas posibles preguntas.
Visualización en la interfaz
Las reformulaciones se integran en el flujo normal del chat y se muestran
como sugerencias de elección rápida. Este diseño, ilustrado en la Figura 3.10,
facilita que el usuario avance en la interacción incluso cuando no dispone de
los recursos lingüísticos necesarios para formular una consulta adecuada por
sí mismo.
En consecuencia, la funcionalidad no solo corrige problemas de comunicación,
sino que también actúa como apoyo cognitivo, promoviendo la autonomía y
reduciendo la frustración derivada de posibles malentendidos.
3.2.3. Entrada por voz
La entrada por voz se integra en OlivIA como un mecanismo alternativo de
interacción que facilita el acceso a personas con dificultades motoras, problemas
de escritura o aquellas que simplemente prefieren una experiencia más directa y
natural. Su inclusión responde al objetivo principal de accesibilidad universal y a los
58 Capítulo 3. OlivIA 2.0
Figura 3.10: Pantalla de interacción en la que se solicita información adicional al
usuario y se presentan reformulaciones sugeridas.
principios de diseño centrado en la persona, promoviendo una comunicación fluida
y sin barreras.
Para implementar la entrada por voz en OlivIA se ha utilizado la Web Speech
API, concretamente la interfaz SpeechRecognition (o webkitSpeechRecognition
en navegadores basados en Chromium). Esta elección se justifica en base a los si-
guientes criterios:
Simplicidad e integración directa: Al ser una API nativa del navegador,
no requiere bibliotecas externas ni autenticación, lo que facilita su integración
y mantenimiento.
Baja latencia y respuesta inmediata: La transcripción del habla ocurre
en tiempo real en el navegador, permitiendo una experiencia fluida para el
usuario, especialmente útil en contextos educativos o de asistencia.
Gratuita y sin costes de servicio: A diferencia de las APIs comerciales, la
Web Speech API es de uso gratuito, lo cual es ventajoso para proyectos con
presupuesto limitado o en fases iniciales de desarrollo.
Privacidad y procesamiento local: La API permite mantener la interacción
en el navegador, reduciendo el envío de datos a servicios externos, lo cual
mejora el control sobre la privacidad.
Adecuación a usuarios con discapacidad cognitiva: La facilidad de uso
y la naturaleza inmediata de esta API encajan con las necesidades del público
objetivo, que puede tener dificultades de lectoescritura o motricidad fina.
3.2. Ampliaciones y mejoras en la nueva versión de OlivIA 59
En base a estos criterios, la Web Speech API resulta ser la opción más equilibrada
en términos de accesibilidad, simplicidad, eficiencia y adecuación al contexto del
proyecto.
En caso de que el navegador no soporte la Web Speech API, se ha incorporado
un control de fallback que informa al usuario mediante un mensaje de alerta. Es-
te mecanismo es fundamental para garantizar una experiencia predecible y evitar
frustraciones derivadas de funcionalidades no disponibles.
El siguiente fragmento muestra la estructura principal de la función:
const startListening = () => {
const SpeechRecognition =
window.SpeechRecognition || window.webkitSpeechRecognition;
if (!SpeechRecognition) {
alert("Tu navegador no soporta reconocimiento de voz.");
return;
}
const recognition = new SpeechRecognition();
recognition.lang = "es-ES";
recognition.interimResults = false;
recognition.onstart = () => console.log("Grabando...");
recognition.onresult = (event) => {
const transcript = event.results[0][0].transcript;
setPrompt(transcript);
console.log("Texto reconocido:", transcript);
};
recognition.onerror = () => console.log("Error en el reconocimiento");
recognition.onend = () => console.log("Grabación finalizada");
recognition.start();
};
El botón de micrófono se ha incorporado en la interfaz principal junto al campo
de texto y el botón de envío (“Descubrir Respuesta”) como se puede ver en la en la
Figura 3.11. Para asegurar una disposición clara y accesible, se utiliza un contenedor
flex que alinea todos los elementos de forma coherente y responsiva.
En el módulo de conversación avanzada (chat), la entrada por voz se gestiona a
nivel local dentro del componente BotonesInteraccion.jsx. Para ello se ha definido
una función startListeningLocal, que reutiliza la misma lógica base y actualiza
el estado prompt recibido como prop. De este modo, se preserva la independencia
y modularidad de los componentes, facilitando el mantenimiento y la escalabilidad
futura.
60 Capítulo 3. OlivIA 2.0
Figura 3.11: Pantalla principal donde se muestra la disposición de los botones
3.3. Evaluación de la accesibilidad de OlivIA 2.0
Tras la incorporación de nuevas funcionalidades se ha realizado un nuevo aná-
lisis de accesibilidad. El objetivo de esta evaluación es comprobar si los elementos
añadidos cumplen con los principios de accesibilidad establecidos por las Pautas de
Accesibilidad al Contenido en la Web (WCAG 2.1), asegurando así que la plataforma
continúe siendo usable para todas las personas, incluidas aquellas con algún tipo de
discapacidad. Para ello, se ha llevado a cabo una evaluación automática utilizando
la herramienta WAVE, con el fin de identificar errores técnicos y posibles mejoras
y una revisión manual, centrada en la interacción y comprensión visual. A conti-
nuación, se detallan los resultados obtenidos para cada uno de los nuevos elementos
introducidos.
En la nueva pantalla de preguntas (Figura 3.12), se identificaron ciertos aspectos
de accesibilidad relacionados con la estructura semántica y el etiquetado:
Errores críticos: Falta de etiqueta en el campo de entrada para la pregunta
personalizada. Se propuso la corrección mediante un <label> asociado o el uso del
atributo aria-label.
Alertas: Jerarquía de encabezados incompleta, con salto del nivel <h1> al <h3>
sin incluir <h2>. Esta omisión puede dificultar la navegación estructurada con tec-
nologías asistivas pero ya ha sido solucionado.
Elementos positivos:
Los botones implementados presentan buen contraste de color y etiquetas des-
criptivas, lo que mejora la comprensión y navegación.
Se especifica correctamente el idioma del documento y se identifican algunas
imágenes con texto alternativo.
3.3. Evaluación de la accesibilidad de OlivIA 2.0 61
Figura 3.12: Análisis con WAVE de la pantalla de selección rápida de preguntas.
Se ha incorporado una etiqueta explícita para el campo de entrada y reorganizado
los encabezados para mantener una jerarquía semántica coherente. Tras aplicar estos
cambios, esta pantalla cumple con los requisitos establecidos en las WCAG 2.1 como
se puede ver en la Figura 3.13.
Por otro lado como la pantalla de chat con la incorporación de la evaluación
inicial y la generación de nuevas preguntas sigue el mismo estilo de las correcciones
que se hicieron al principio del proyecto cumple con los requisitos establecidos en
las WCAG 2.1 como se puede observar en la Figura 3.14 y en la Figura 3.15.
La evaluación manual de la accesibilidad cognitiva de OlivIA se realizó siguiendo
los principios de lectura fácil y diseño inclusivo. Los principales aspectos considerados
fueron los siguientes:
Claridad del lenguaje: uso de frases cortas, vocabulario sencillo y estruc-
turas directas. Se identificaron expresiones técnicas o abstractas que podían
generar confusión y se propusieron alternativas más simples.
Organización visual y jerarquía: análisis de la distribución de títulos, ins-
trucciones, preguntas y botones, verificando que tuvieran una jerarquía clara
(tamaño, color, posición) y un orden predecible. También se comprobó el uso
correcto de encabezados semánticos (<h1>,<h2>, etc.).
Consistencia de diseño: revisión de la uniformidad en tipografías, colores,
estilos de botones e iconografía, asegurando que los elementos mantuvieran la
misma función y apariencia en todas las pantallas.
Apoyos visuales y redundancia informativa: verificación de que iconos
y pictogramas reforzaran la información textual, y análisis de combinaciones
62 Capítulo 3. OlivIA 2.0
Figura 3.13: Análisis con WAVE de la pantalla de selección rápida de preguntas
corregida.
Figura 3.14: Análisis con WAVE de la pantalla de Chat con la incorporación de la
la generación de nuevas preguntas en base a una idea.
3.3. Evaluación de la accesibilidad de OlivIA 2.0 63
Figura 3.15: Análisis con WAVE de la pantalla de Chat con la incorporación de la
evaluación de la ambigüedad y la generación de nuevas preguntas.
texto + símbolo para mejorar la comprensión en usuarios con baja alfabetiza-
ción. Se identificó la ausencia de descripciones alternativas (alt,aria-label)
en algunos elementos.
Facilidad de lectura y comprensión: contraste con criterios de lectura
fácil, evitando frases largas, metáforas o expresiones ambiguas, y corrigiendo
problemas de concordancia o redundancias innecesarias.
Accesibilidad multisensorial: evaluación de apoyos alternativos como la
lectura en voz alta o ayudas contextuales. Se señalaron carencias, como la
falta de botones de audio en todas las pantallas.
Flexibilidad e inclusión: análisis de opciones abiertas (“otra opción”, “pre-
fiero no responder”) para respetar la diversidad de usuarios, así como de la
posibilidad de navegar entre pasos, modificar respuestas y confirmar la confi-
guración final antes de iniciar la interacción.
Cap´
ıtulo 4
Conclusiones y líneas de trabajo futuro
4.1. Conclusiones del trabajo
El presente Trabajo de Fin de Grado ha tenido como propósito principal el diseño
e implementación de una nueva versión de OlivIA, un asistente conversacional in-
clusivo, centrado especialmente en personas con discapacidad cognitiva, dificultades
de aprendizaje y otras necesidades especiales.
A lo largo del proyecto, se han abordado diversos retos técnicos y de accesibili-
dad, consiguiendo desarrollar una solución que conjuga la inteligencia artificial con
principios de diseño universal y accesibilidad cognitiva.
Entre los logros más destacados, se encuentran:
La integración de pictogramas como canal de salida adicional, permitien-
do que la información textual se presente en formato visual, favoreciendo la
comprensión en usuarios con dificultades lectoras o que requieren apoyos vi-
suales adicionales. Esta funcionalidad vincula cada fragmento con pictogramas
estandarizados, reforzando la comunicación multimodal y adaptada.
La incorporación de entrada por voz, que habilita la interacción sin tecla-
do y mejora la autonomía para personas con limitaciones motoras, problemas
de coordinación o usuarios que simplemente buscan una interacción más na-
tural.
La generación de preguntas a partir de un tema y el asistente de
reformulación de preguntas ambiguas, funcionalidad clave para usuarios
con baja iniciativa comunicativa o dificultades para estructurar ideas y formu-
lar preguntas. Gracias a esta herramienta, se facilita la exploración de temas
complejos y se reduce la barrera inicial a la participación, contribuyendo a una
experiencia más guiada y accesible.
Además, se ha realizado una evaluación exhaustiva de accesibilidad, utilizan-
do herramientas automáticas como WAVE, lo que permitió identificar y corregir
problemas críticos relacionados con estructura semántica, contraste, jerarquía de
encabezados y etiquetado de formularios. Gracias a estas mejoras, se alcanzó un
65
66 Capítulo 4. Conclusiones y líneas de trabajo futuro
nivel alto de conformidad con las pautas WCAG 2.1 y se avanzó hacia la alineación
con las recomendaciones cognitivas propuestas por el grupo COGA (Cognitive and
Learning Disabilities Accessibility Task Force).
En conjunto, tanto OlivIA 1.0 como su nueva versión 2.0 representan representa
un avance significativo hacia la creación de asistentes conversacionales verdadera-
mente inclusivos, que no solo responden a preguntas, sino que se adaptan activa-
mente al usuario, empoderándolo y fomentando su independencia.
4.2. Líneas de trabajo futuro
Si bien el proyecto actual cumple con los objetivos propuestos y logra una expe-
riencia accesible avanzada, existen diversas áreas de mejora y expansión que podrían
explorarse en futuras iteraciones. Entre las principales líneas de trabajo futuro, se
destacan:
Ampliación del vocabulario visual y personalización de pictogramas:
integrar nuevas bibliotecas de pictogramas, como Sclera o Blissymbolics, así
como permitir a los usuarios subir sus propios pictogramas personalizados,
fomentando una mayor adaptación cultural y contextual.
Optimización del motor de IA: incorporar modelos adaptativos que no
solo generen contenido en función del tema, sino que también ajusten el nivel
de detalle, la complejidad lingüística y el tono en tiempo real, basándose en la
retroalimentación implícita del usuario.
Desarrollo de un sistema de perfilado dinámico: permitir que el sistema
adapte progresivamente la experiencia en función del historial de interacciones,
identificando preferencias y necesidades recurrentes de cada usuario para ajus-
tar automáticamente configuraciones como el uso de pictogramas, longitud de
las respuestas o nivel de formalidad.
Pruebas piloto con usuarios finales y validación participativa: organi-
zar estudios de usabilidad y sesiones de co-creación con personas con discapa-
cidad cognitiva y sus cuidadores, recogiendo retroalimentación directa y vali-
dando la efectividad real de las funcionalidades implementadas. Estas pruebas
permitirían refinar la herramienta de manera basada en evidencia y centrada
en la experiencia real.
Soporte multilingüe y adaptación cultural: expandir la aplicación a otros
idiomas y adaptar los pictogramas y ejemplos a contextos culturales diversos,
ampliando el impacto global de la herramienta y promoviendo la accesibilidad
en comunidades internacionales.
Explorar estas líneas de trabajo permitirá fortalecer el compromiso de OlivIA
con la inclusión y la accesibilidad, evolucionando hacia un asistente cada vez más
inteligente, humano y empático. De este modo, se contribuirá no solo al avance
tecnológico, sino también a la reducción de brechas digitales y a la promoción de la
4.2. Líneas de trabajo futuro 67
autonomía personal en colectivos tradicionalmente desatendidos por las soluciones
tecnológicas convencionales.
Conclusions and Future Work
4.1. Conclusions
This Final Degree Project has focused on the design and implementation of a
new version of OlivIA, an inclusive conversational assistant especially tailored for
people with cognitive disabilities, learning difficulties, and other special needs.
Throughout the project, various technical and accessibility challenges have been
addressed, resulting in a solution that combines artificial intelligence with principles
of universal design and cognitive accessibility.
Among the most notable achievements are:
The integration of pictograms as an additional output channel, allowing
textual information to be presented in a visual format. This facilitates compre-
hension for users with reading difficulties or those requiring additional visual
support. Each text segment is linked to standardized pictograms, reinforcing
multimodal and adaptive communication.
The implementation of voice input, which enables interaction without a
keyboard and enhances autonomy for users with motor limitations, coordina-
tion issues, or those simply seeking a more natural interaction.
The automatic question generation feature, which is crucial for users with
low communicative initiative or difficulties structuring ideas and formulating
questions. This tool facilitates the exploration of complex topics and lowers
the entry barrier to participation, contributing to a more guided and accessible
experience.
Additionally, a comprehensive accessibility evaluation was conducted using au-
tomated tools such as WAVE, which helped identify and correct critical issues re-
lated to semantic structure, contrast, heading hierarchy, and form labeling. These
improvements led to a high level of compliance with WCAG 2.1 guidelines and
progress toward alignment with the cognitive recommendations proposed by the
COGA (Cognitive and Learning Disabilities Accessibility Task Force) group.
Overall, both OlivIA 1.0 and its new version 2.0 represent a significant step
toward creating truly inclusive conversational assistants that not only respond to
69
70 Capítulo 4. Conclusiones y líneas de trabajo futuro
questions but actively adapt to users, empowering them and promoting their inde-
pendence.
4.2. Future Work
Although the current project meets the proposed objectives and achieves an
advanced accessible experience, several areas for improvement and expansion can be
explored in future iterations. Key future work lines include:
Expansion of the visual vocabulary and pictogram customization:
Integrate new pictogram libraries, such as Sclera or Blissymbolics, and allow
users to upload their own customized pictograms, fostering greater cultural
and contextual adaptation.
Optimization of the AI engine: Incorporate adaptive models that not only
generate content based on the topic but also adjust the level of detail, linguistic
complexity, and tone in real time, based on implicit user feedback.
Development of a dynamic profiling system: Allow the system to pro-
gressively adapt the experience based on the user’s interaction history, identi-
fying recurring preferences and needs to automatically adjust settings such as
pictogram use, response length, or formality level.
Pilot testing with end users and participatory validation: Organize us-
ability studies and co-creation sessions with people with cognitive disabilities
and their caregivers, collecting direct feedback and validating the actual effec-
tiveness of the implemented features. These tests would enable evidence-based
and user-centered refinement of the tool.
Multilingual support and cultural adaptation: Expand the application
to other languages and adapt pictograms and examples to diverse cultural
contexts, increasing the tool’s global impact and promoting accessibility in
international communities.
Exploring these future lines of work will strengthen OlivIA’s commitment to
inclusion and accessibility, evolving into an increasingly intelligent, human, and em-
pathetic assistant. In this way, the project contributes not only to technological ad-
vancement but also to reducing the digital divide and promoting personal autonomy
among groups traditionally underserved by conventional technological solutions.
Bibliografía
La tecnología más profunda es aquella que
desaparece.
Mark Weiser
AChecker Project.AChecker Handbook — Report and Problem
Types. Web Accessibility Checker, 2025a. Disponible en https:
//websiteaccessibilitychecker.com/documentation/print.php?p=
checker%2Findex.php (último acceso, Agosto, 2025).
AChecker Project.AChecker Web Service API — Supported Gui-
delines. Web Accessibility Checker, 2025b. Disponible en https:
//websiteaccessibilitychecker.com/documentation/web_service_api.php
(último acceso, Agosto, 2025).
Amar, A. Y. Accia: Accesibilidad cognitiva en la era de las ias. 2025. Trabajo de
Fin de Grado, Universidad Complutense de Madrid.
American Association on Intellectual and Developmental Disabi-
lities.Intellectual Disability: Definition, Classification, and Systems of Sup-
ports (12th ed.). AAIDD, 2021. Disponible en https://www.aaidd.org/
intellectual-disability/definition (último acceso, Agosto, 2025).
American Psychiatric Association.Diagnostic and Statistical Manual of Men-
tal Disorders (5th ed., text rev.) — DSM-5-TR. American Psychiatric Association,
2022. Disponible en https://doi.org/10.1176/appi.books.9780890425787
(último acceso, Agosto, 2025).
American Speech-Language-Hearing Association.Practice Portal: In-
tellectual Disability. ASHA, 2024. Disponible en https://www.asha.org/
Practice-Portal/Clinical-Topics/Intellectual-Disability/ (último ac-
ceso, Agosto, 2025).
ARASAAC.Research and Scientific Studies on ARA-
SAAC Pictographic Symbols. Gobierno de Aragón,
2017. Disponible en https://aulaabierta.arasaac.org/en/
71
72 BIBLIOGRAFÍA
scientific-research-carried-out-on-the-pictographic-symbols-of-arasaac
(último acceso, Agosto, 2025).
ARASAAC.ARASAAC pictographic system and uses (education, health, signage).
Gobierno de Aragón, 2019. Disponible en https://aulaabierta.arasaac.org/
en/arasaac-pictographic-system-of-reference-in-the-aac (último acce-
so, Agosto, 2025).
Chrome for Developers.Introduction to Lighthouse. Google, 2025a. Dispo-
nible en https://developer.chrome.com/docs/lighthouse/overview (último
acceso, Agosto, 2025).
Chrome for Developers.Lighthouse — Audits and Categories. Google, 2025b.
Disponible en https://developer.chrome.com/docs/lighthouse (último acce-
so, Agosto, 2025).
Cognitive, W. W.
yForce, L. D. A. T. Making Content Usable for People with Cognitive and
Learning Disabilities. World Wide Web Consortium (W3C), 2021. Disponible en
https://www.w3.org/TR/coga-usable/ (último acceso, Agosto, 2025).
Deque Systems.Deque Study Shows Its Automated Tes-
ting Identifies 57 Percent of Digital Accessibility Issues. De-
que, 2021. Disponible en https://www.deque.com/blog/
automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/
(último acceso, Agosto, 2025).
Deque Systems.Automate Accessibility Testing with axe DevTools (Overview).
Deque, 2025a. Disponible en https://www.deque.com/axe/devtools/ (último
acceso, Agosto, 2025).
Deque Systems.axe-core — Accessibility Testing Engine (GitHub). GitHub,
2025b. Disponible en https://github.com/dequelabs/axe-core (último acceso,
Agosto, 2025).
Deque Systems.axe DevTools - Web Accessibility Testing (Chrome Ex-
tension). Google Chrome Web Store, 2025c. Disponible en https:
//chromewebstore.google.com/detail/axe-devtools-web-accessib/
lhdoppojpmngadmnindnejefpokejbdd (último acceso, Agosto, 2025).
Deque Systems.axe DevTools Browser Extension — Documentation. Deque
Docs, 2025d. Disponible en https://docs.deque.com/devtools-for-web/4/
en/devtools-extension/ (último acceso, Agosto, 2025).
Deque University.List of axe DevTools HTML Rules (v4.x). Deque University,
2025. Disponible en https://dequeuniversity.com/rules/axe-devtools/4.4
(último acceso, Agosto, 2025).
Díez, E. ycolleagues. Transparency and translucency indices for 1525 pic-
tograms from arasaac. 2024. Disponible en https://pmc.ncbi.nlm.nih.gov/
articles/PMC11533329/ (último acceso, Agosto, 2025).
BIBLIOGRAFÍA 73
DYNO Mapper.Website Accessibility Testing — Supported Gui-
delines. DYNO Mapper (Zendesk Help Center), 2022. Dispo-
nible en https://dynomapper.zendesk.com/hc/en-us/articles/
6367486982285-Website-Accessibility-Testing (último acceso, Agosto,
2025).
DYNO Mapper.DYNO Mapper — Visual Sitemap Generator for Smarter Web-
site Planning. DYNO Mapper, 2025a. Disponible en https://dynomapper.com/
(último acceso, Agosto, 2025).
DYNO Mapper.Website Accessibility Testing. DYNO Mapper, 2025b. Disponi-
ble en https://dynomapper.com/features/website-accessibility-testing
(último acceso, Agosto, 2025).
ETSI.EN 301 549 V3.2.1: Accessibility requirements for ICT products and
services. European Telecommunications Standards Institute, 2021. Disponi-
ble en https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.
02.01_60/en_301549v030201p.pdf (último acceso, Agosto, 2025).
European Commission.Accessibility of public sector websites and mobile apps
— summary and latest changes. EUR-Lex / European Commission, 2021.
Disponible en https://eur-lex.europa.eu/EN/legal-content/summary/
accessibility-of-public-sector-websites-and-mobile-apps.html (último
acceso, Agosto, 2025).
European Parliament and the Council.Directive (EU) 2016/2102 on the
accessibility of the websites and mobile applications of public sector bodies. Official
Journal of the European Union, 2016. Disponible en https://eur-lex.europa.
eu/eli/dir/2016/2102/oj/eng (último acceso, Agosto, 2025).
Faber, T. J. E.,Dankbaar, M. E. W.,van den Broek, W. W.,Bruinink,
L. J.,Hogeveen, M. yvan Merriënboer, J. J. G. Effects of adaptive
scaffolding on performance, cognitive load and engagement in game-based lear-
ning: a randomized controlled trial. 2024. Disponible en https://bmcmededuc.
biomedcentral.com/articles/10.1186/s12909-024-05698-3 (último acceso,
Agosto, 2025).
Gartland, S.,Flynn, P.,Carneiro, M. A.,Holloway, G.,de Sou-
sa Fialho, J.,Cullen, J.,Hamilton, E.,Harris, A. yCullen, C. The
state of web accessibility for people with cognitive disabilities: A rapid evidence
assessment. 2022. Disponible en https://pmc.ncbi.nlm.nih.gov/articles/
PMC8869505/ (último acceso, Agosto, 2025).
GoogleChrome.Lighthouse (GitHub Repository). GitHub / Google, 2025. Dispo-
nible en https://github.com/GoogleChrome/lighthouse (último acceso, Agos-
to, 2025).
Inclusion Europe. Information for all: European guidelines for easy-to-read in-
formation. 2012. Accessed: 2025-09-08.
74 BIBLIOGRAFÍA
Inclusive Design Institute.AChecker — Automated Web Accessibility Checker
(GitHub). GitHub / Inclusive Design Institute, 2021. Disponible en https://
github.com/inclusive-design/AChecker (último acceso, Agosto, 2025).
Kudo, M. The inclusive design of pictograms and easy to understand for people
with intellectual disabilities. 2022. Disponible en https://journals.uc.edu/
index.php/vl/article/view/5976 (último acceso, Agosto, 2025).
Microsoft Inclusive Design Team.Inclusive Design for Cognition Guide-
book. Microsoft, 2023. Disponible en https://inclusive.microsoft.design/
tools-and-activities/InclusiveDesignForCognitionGuidebook.pdf (últi-
mo acceso, Agosto, 2025).
Moreno, L.,Petrie, H.,Martínez, P. yAlarcón, R. Designing user interfaces
for content simplification aimed at people with cognitive impairments. vol. 23(1),
páginas 99–117, 2024. Disponible en https://link.springer.com/article/10.
1007/s10209-023-00986-z (último acceso, Agosto, 2025).
PowerMapper Software.OnDemand/Enterprise User Manual — Privacy
and SEO Checks. PowerMapper Software, 2023. Disponible en https://www.
powermapper.com/download/enterprise/enterprise-user-manual.pdf (últi-
mo acceso, Agosto, 2025).
PowerMapper Software.Accessibility Testing Tool — Used by federal agencies
and the Fortune 100 . PowerMapper Software, 2025a. Disponible en https://www.
powermapper.com/products/sortsite/ads/acc-accessibility-testing/
(último acceso, Agosto, 2025).
PowerMapper Software.Check Website Usability — SortSite. PowerMap-
per Software, 2025b. Disponible en https://www.powermapper.com/products/
sortsite/checks/usability/ (último acceso, Agosto, 2025).
PowerMapper Software.SortSite — Checkpoints (Accessibility, Standards,
etc.). PowerMapper Software, 2025c. Disponible en https://www.powermapper.
com/products/sortsite/checks/ (último acceso, Agosto, 2025).
PowerMapper Software.SortSite — Product Information. PowerMap-
per Software, 2025d. Disponible en https://www.powermapper.com/products/
sortsite/overview/ (último acceso, Agosto, 2025).
Seeman, L.,LaPierre, C.,Foliot, J.,Cooper, M.,Ran, R. ySchwerdtfe-
ger, R. Personalization Semantics Content Module 1.0 (W3C Working Draft).
World Wide Web Consortium (W3C), 2021. Disponible en https://www.w3.
org/TR/2021/WD-personalization-semantics-content-1.0-20210812/ (últi-
mo acceso, Agosto, 2025).
Team Pa11y.Pa11y Dashboard — Web interface for monitoring accessibility.
GitHub / Pa11y Project, 2024a. Disponible en https://github.com/pa11y/
pa11y-dashboard (último acceso, Agosto, 2025).
BIBLIOGRAFÍA 75
Team Pa11y.Pa11y — Project site (Dashboard, Webservice, CI). Pa11y, 2024b.
Disponible en https://pa11y.org/ (último acceso, Agosto, 2025).
Team Pa11y.Pa11y — Your automated accessibility testing pal (CLI/Node.js).
GitHub / Pa11y Project, 2024c. Disponible en https://github.com/pa11y/
pa11y (último acceso, Agosto, 2025).
The University of Chicago – Center for Digital Accessibility.Tes-
ting for Accessibility. The University of Chicago, 2025. Disponible en https:
//digitalaccessibility.uchicago.edu/testing-for-accessibility/ (últi-
mo acceso, Agosto, 2025).
U.S. General Services Administration.Designing Digital
Content for Users with Cognitive Disabilities. Section508.gov,
2025. Disponible en https://www.section508.gov/design/
digital-content-users-with-cognitive-disabilities/ (último acceso,
Agosto, 2025).
W3C. Web content accessibility guidelines (wcag) 1.0. W3c recommendation, World
Wide Web Consortium (W3C), 1999. Accessed: 2025-09-08.
W3C. Introduction to web accessibility. https://www.w3.org/WAI/fundamentals/
accessibility-intro/, 2018. Accessed: 2025-09-08.
W3C WAI.Support Adaptation and Personalization (Objective 8). World Wi-
de Web Consortium (W3C), 2021. Disponible en https://www.w3.org/WAI/
WCAG2/supplemental/objectives/o8-personalization/ (último acceso, Agos-
to, 2025).
W3C WAI Cognitive and Learning Disabilities Accessibility Task For-
ce.COGA Design Guide — Objectives and Patterns. World Wide Web Con-
sortium (W3C), 2021. Disponible en https://www.w3.org/TR/coga-usable/
design_guide.html (último acceso, Agosto, 2025).
Web Key IT.Accessibility aids and tools — PowerMapper SortSite.
Web Key IT, 2024. Disponible en https://www.webkeyit.com/resources/
accessibility-aids-and-tools/ (último acceso, Agosto, 2025).
WebAIM.WAVE Chrome, Firefox, and Edge Extensions. WebAIM, 2025a. Dispo-
nible en https://wave.webaim.org/extension/ (último acceso, Agosto, 2025).
WebAIM.WAVE Help — What is WAVE and how do I use it?. WebAIM, 2025b.
Disponible en https://wave.webaim.org/help (último acceso, Agosto, 2025).
WebAIM.WAVE Web Accessibility Evaluation Tools. WebAIM, 2025c. Disponible
en https://wave.webaim.org/ (último acceso, Agosto, 2025).
World Health Organization yWorld Bank.World Re-
port on Disability. World Health Organization, 2011. Disponi-
ble en https://www.who.int/teams/noncommunicable-diseases/
76 BIBLIOGRAFÍA
sensory-functions-disability-and-rehabilitation/
world-report-on-disability (último acceso, Agosto, 2025).
World Wide Web Consortium (W3C).Web Content Accessibility Guideli-
nes (WCAG) 2.2 . W3C, 2024. Disponible en https://www.w3.org/TR/WCAG22/
(último acceso, Agosto, 2025).
World Wide Web Consortium (W3C) – Web Accessibility Initiative
(WAI).WCAG 2.2 is a Web Standard "W3C Recommendation". W3C, 2023.
Disponible en https://www.w3.org/WAI/news/2023-10-05/wcag22rec/ (últi-
mo acceso, Agosto, 2025).
World Wide Web Consortium (W3C) – Web Accessibility Initiative
(WAI).Selecting Web Accessibility Evaluation Tools. W3C, 2024a. Disponible
en https://www.w3.org/WAI/test-evaluate/tools/selecting/ (último acce-
so, Agosto, 2025).
World Wide Web Consortium (W3C) – Web Accessibility Initiative
(WAI).WCAG Overview: Web Content Accessibility Guidelines (WCAG). W3C,
2024b. Disponible en https://www.w3.org/WAI/standards-guidelines/wcag/
(último acceso, Agosto, 2025).
Zhu, B.,Chau, K. T. yMokmin, N. A. M. Optimizing cognitive load and
learning adaptability with adaptive microlearning for in-service personnel. vol.
14(1), página 25960, 2024. Disponible en https://pubmed.ncbi.nlm.nih.gov/
39472703/ (último acceso, Agosto, 2025).
Ap´
endice A
Capturas de pantalla análisis automático
con WAVE
Figuras asociadas al análisis automático realizado con WAVE de OlivIA 1.0.
77
78 Apéndice A. Capturas de pantalla análisis automático con WAVE
Figura A.1: Análisis con WAVE de la pantalla de inicio de OlivIA (versión inicial).
Figura A.2: Análisis con WAVE de la pantalla de inicio tras las mejoras implemen-
tadas.
79
Figura A.3: Análisis con WAVE del paso 1 del cuestionario (versión inicial).
Figura A.4: Análisis con WAVE del paso 1 del cuestionario tras mejoras.
Figura A.5: Análisis con WAVE del paso 2 del cuestionario (versión inicial).
80 Apéndice A. Capturas de pantalla análisis automático con WAVE
Figura A.6: Análisis con WAVE del paso 2 tras las mejoras.
Figura A.7: Análisis con WAVE del paso 3 del cuestionario (versión inicial).
Figura A.8: Análisis con WAVE del paso 3 tras las mejoras.
81
Figura A.9: Análisis con WAVE de la pantalla final del cuestionario (versión inicial).
Figura A.10: Análisis con WAVE de la pantalla final tras las mejoras.
Figura A.11: Análisis con WAVE de la pantalla de preguntas (versión inicial).
82 Apéndice A. Capturas de pantalla análisis automático con WAVE
Figura A.12: Análisis con WAVE de la pantalla de preguntas tras mejoras.
Figura A.13: Pantalla de inicio del proceso de configuración personalizada en OlivIA.
Figura A.14: Análisis con WAVE de la pantalla de chat (versión inicial).
83
Figura A.15: Análisis con WAVE de la pantalla de chat tras mejoras.
Todas las batallas en la vida sirven para enseñarnos algo,
incluso aquellas que perdemos.
El Alquimista
Paulo Coelho
