A11yConf 2026 abre su convocatoria de propuestas para charlas y talleres sobre accesibilidad digital

La organización de A11yConf 2026 ha abierto el plazo para presentar propuestas de participación en la próxima edición de la conferencia, que se celebrará el sábado 28 de noviembre de 2026 en Zaragoza.

La convocatoria está dirigida a personas interesadas en compartir conocimientos, proyectos, iniciativas y experiencias relacionadas con la accesibilidad digital. Las propuestas podrán enviarse hasta las 23:59 del 16 de agosto de 2026 mediante el formulario disponible en la web oficial de A11yConf 2026.

Charlas y talleres sobre accesibilidad digital

El programa de la conferencia se distribuirá en dos espacios simultáneos dedicados a charlas y un tercer espacio destinado a talleres.

Las charlas tendrán una duración aproximada de 45 minutos. Los talleres podrán presentarse en dos modalidades: un formato breve de alrededor de 60 minutos y otro más extenso de aproximadamente 90 minutos.

La organización busca propuestas técnicas relacionadas con el diseño, la programación y el uso de la tecnología, así como contenidos centrados en otras áreas vinculadas con la accesibilidad digital.

También se valorarán iniciativas, proyectos y experiencias que contribuyan a sensibilizar sobre la importancia de la accesibilidad y a promover la creación de productos, servicios y entornos digitales que puedan ser utilizados por el mayor número posible de personas.

Una convocatoria abierta a nuevos perfiles

No es necesario contar con experiencia previa como ponente para participar en la convocatoria. A11yConf 2026 dispone de un programa de mentoría destinado a quienes necesiten apoyo para desarrollar su idea, estructurar la propuesta o preparar la presentación.

Las personas interesadas en recibir este acompañamiento podrán indicarlo en el formulario de participación. La iniciativa pretende facilitar la incorporación de nuevas voces y ampliar la diversidad de experiencias y conocimientos presentes en la conferencia.

Las propuestas seleccionadas deberán presentarse presencialmente durante el evento. La organización cubrirá los gastos de desplazamiento y alojamiento de las personas elegidas para participar como ponentes.

Introducción a Javascript

Cuando abrimos una página web en el navegador, éste interpreta el código HTML para entender qué contenido hay y qué significa cada parte. Después aplica el CSS para definir el aspecto visual de ese contenido. Pero una página web moderna no solo necesita estructura y presentación: en muchos casos también necesita comportamiento, lógica e interacción. Ahí es donde entra JavaScript.

JavaScript es el lenguaje que permite que una página web responda a acciones del usuario, modifique contenidos, valide formularios, cargue información sin recargar toda la página o cambie el estado de distintos elementos de la interfaz. Es, por tanto, la parte de la Web que aporta funcionalidad y dinamismo.

Qué es JavaScript

JavaScript es un lenguaje de programación. A diferencia de HTML y CSS, que no son lenguajes de programación, Javascript sí puede ejecutar comandos y funciones de lógica. Esto no implica que Javascript no tenga que relacionarse con HTML o CSS. Con HTML describimos el contenido y su estructura. Con CSS definimos la presentación visual. Con JavaScript programamos el comportamiento de la página.

Dónde se puede usar Javascript

Aunque mucha gente identifica JavaScript solo con el navegador, el lenguaje también se puede utilizar fuera de la Web en otros entornos como scripts en la Terminal de Linux o MacOçS, como lenguaje de programación para servidores con NodeJS o para programar servicios para la Nube.

El estándar del lenguaje se denomina ECMAScript, y JavaScript es su implementación más conocida en la actualidad.

Ejemplo básico en JavaScript

A continuación tenemos un ejemplo de una página HTML con un botón y un pequeño fragmento de JavaScript:

<!doctype html>
<html lang="es">
<head>
<meta charset="utf-8">
<title>Mi primera página con JavaScript</title>
</head>
<body>
<h1>Mi primera página con JavaScript</h1>
<p id="mensaje">Todavía no ha pasado nada.</p>
<button id="boton">Pulsa aquí</button>

<script>
document.getElementById("boton").addEventListener("click", function () {
document.getElementById("mensaje").textContent = "Has pulsado el botón.";
});
</script>
</body>
</html>

Si guardamos ese contenido en un fichero con extensión .html y lo abrimos con el navegador, veremos una página con un botón. Al pulsarlo, el texto del párrafo cambiará.

Ese cambio no lo hace HTML ni lo hace CSS. Lo hace JavaScript.

Qué está ocurriendo en el ejemplo

Aunque a primera vista pueda parecer mucho código, en realidad están pasando pocas cosas.

Primero tenemos este párrafo:

<p id="mensaje">Todavía no ha pasado nada.</p>

Ese párrafo tiene un atributo id con el valor mensaje. Ese identificador nos permite localizar el elemento desde JavaScript.

Después tenemos este botón:

<button id="boton">Pulsa aquí</button>

También tiene un id, en este caso boton.

Y por último aparece el bloque script:

<script>
document.getElementById("boton").addEventListener("click", function () {
document.getElementById("mensaje").textContent = "Has pulsado el botón.";
});
</script>

Ese bloque contiene código JavaScript que el navegador ejecuta. La instrucción busca el botón, escucha el evento de pulsación (click) y, cuando ese evento ocurre, modifica el texto del párrafo.

La etiqueta <script>

La forma más habitual de incluir JavaScript en una página HTML es mediante la etiqueta <script>.

Puede escribirse directamente dentro del propio documento HTML:

<script>
console.log("Hola desde JavaScript");
</script>

O bien enlazarse desde un fichero externo:

<script src="app.js"></script>

En la práctica, cuando el código crece, lo normal es utilizar un fichero independiente. Esto facilita el mantenimiento, permite reutilizar código y evita mezclar demasiadas responsabilidades en el HTML.

JavaScript y el DOM

Cuando JavaScript trabaja con una página HTML, normalmente no “ve” el fichero como texto plano, sino como una estructura interna que el navegador ha construido en memoria.

A esa representación se la suele llamar DOM (Document Object Model).

Utilizando el DOM, JavaScript puede realizar diversas funciones como buscar y manipular elementos de la página, añadir y eliminar elementos, reaccionar a eventos provocados por el usuario o por el navegador…

JavaScript no sustituye a HTML

Una idea importante al empezar es que JavaScript no debería utilizarse para suplir una mala estructura HTML.

Primero conviene tener un documento HTML bien organizado y semántico. Después CSS se ocupa de la presentación. Y finalmente JavaScript añade comportamiento.

Si se invierte ese orden, es fácil terminar con páginas difíciles de mantener, menos accesibles y más frágiles.

En artículos anteriores indicamos que HTML describe contenido y CSS describe presentación. Siguiendo esa idea de separar contenido, diseño y funcionalidad, Javascript debe añadir funcionalidad sin romper la semántica del documento. Esta separación de responsabilidades hace que la página sea más clara, con un mejor mantenimiento y más robusta.

JavaScript no debe ser intrusivo ni imprescindible

Aunque JavaScript aporta mucha potencia a una página web, conviene usarlo con cierta prudencia.

Una mala práctica bastante común consiste en construir páginas que dependen completamente de JavaScript para funcionar, incluso en tareas básicas como mostrar contenido, seguir enlaces o enviar un formulario. Cuando esto ocurre, la página se vuelve dependiente de Javascript y, en muchos casos, menos accesible.

Lo apropiado es que HTML proporcione una base sólida por sí mismo. Es decir, que la estructura del documento, los enlaces, los textos y la información principal existan ya en el marcado. Después, JavaScript puede enriquecer esa base con comportamiento adicional: validar datos en el navegador, mostrar u ocultar partes de la interfaz, actualizar contenidos o responder a acciones del usuario.

Con esto se mantiene la idea de que JavaScript debería mejorar la experiencia, no convertirse en un obstáculo.

También conviene evitar un uso intrusivo del lenguaje. Por ejemplo, no es buena idea abrir ventanas inesperadas, cambiar el foco sin necesidad, alterar el contenido de manera brusca sin avisar o interceptar comportamientos normales del navegador si no hay un motivo claro. Todas esas prácticas pueden desorientar a muchas personas usuarias y hacer que la navegación resulte confusa.

Introducción a CSS

Cuando abrimos una página web en el navegador, éste interpreta el código HTML para entender qué contenido hay y qué significa cada parte (títulos, párrafos, enlaces, formularios, etc.).

Además de estructura y semántica, una página necesita presentacióny estilo visual (tipografías, tamaños, colores, márgenes, alineación, distribución en columnas, etc).

En los artículos sobre HTML se ha hablado de contenido, semántica y estructura pero nunca hablamos de aspecto visual o diseño. Esto se debe a que HTML, en las versiones más modernas y responsables con la accesibilidad, ha cedido toda la responsabilidad de definir el aspecto visual del contenido a la parte CSS de una página web.

Qué es CSS

CSS son las siglas de Cascading Style Sheets (Hojas de estilo en cascada).

Al igual que ocurre con HTML, CSS no es un lenguaje de programación. No ejecuta lógica como lo haría JavaScript; en su lugar, define reglas de estilo que el navegador aplica sobre los elementos HTML para controlar cómo se muestran en la pantalla.

La idea fundamental es separar responsabilidades entre las distintas partes de una página web. El código HTML describe el contenido y su estructura. El código CSS describe el aspecto visual y parte del comportamiento de presentación (por ejemplo, el diseño adaptable o ciertas animaciones). Por último, el código Javascript describe la funcionalidad y el dinamismo de la página.

Ejemplo básico en CSS

Un ejemplo típico es tener un fichero HTML y, aparte, un fichero CSS enlazado. Por ejemplo, un HTML clásico es:

<!doctype html>
<html lang="es">
<head>
<meta charset="utf-8">
<title>Mi primera página con CSS</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<h1>Mi primera página</h1>
<p>Este es un párrafo con información.</p>
<a href="https://programaraciegas.net">Visitar el blog</a>
</body>
</html>

Y el contenido del fichero styles.css podría ser:

body {
font-family: system-ui, sans-serif;
line-height: 1.5;
}

h1 {
font-size: 2rem;
}

a {
text-decoration: underline;
}

Si guardamos ambos ficheros en la misma carpeta y abrimos el HTML en el navegador, veremos que el contenido es el mismo, pero con el aspecto definido por las reglas CSS.

Por qué estilos en cascada

El término cascading (en cascada) tiene una razón por la forma de aplicarse los estilos en un contenido. Cuando varias reglas podrían aplicarse al mismo elemento, CSS define un sistema para resolver conflictos (origen, orden, especificidad, importancia). 

Partes de una regla CSS

La unidad básica de CSS es la regla (a veces llamada ruleset). Una regla se compone de:

• Un selector, que indica a qué elementos se aplica.
• Un bloque de declaraciones, que indica qué propiedades se aplican y con qué valores.

Veamos un ejemplo simple:

p {
font-size: 1rem;
margin-bottom: 1rem;
}

En este caso:
• p es el selector: selecciona todos los párrafos.
• Dentro de { … } hay declaraciones.
• Cada declaración es un par propiedad: valor; como font-size: 1rem;.

Cómo se aplica CSS a una página web

Hay tres formas habituales de aplicar CSS:

Hoja de estilo externa

Es la forma más común y la recomendada por accesibilidad. Se enlaza desde el <head> de la página:

<link rel="stylesheet" href="styles.css">

Entre las ventajas encontramos la separación del diseño del contenido y permite reutilizar estilos en muchas páginas.

Estilos internos

Se escriben dentro de un bloque <style> en el <head>:

<style>
p { line-height: 1.6; }
</style>

Esto es útil para ejemplos o páginas muy pequeñas, pero no es reutilizable para otras páginas.

Estilos en línea

Se escriben directamente en el atributo style de un elemento del <body>: dentro de la estructura de contenidos de la página.

<p style="line-height: 1.6;">Texto</p>

Aunque este estilo se aplica al contenido, es la opción menos recomendable porque mezcla contenido y presentación y complica el mantenimiento de la página y su estructura.

Los selectores CSS

El selector es la condición que decide qué elementos reciben una regla. 
Los más utilizados son:

Selector por etiqueta

Afecta a todos los elementos de ese tipo:

p { ... }
h1 { ... }

Selector por clase

Afecta a elementos que tengan class=»…»:

.destacado { font-weight: bold; }

Y en HTML:

<p class="destacado">Texto importante</p>

Selector por id

Afecta a un único elemento con id=»…»:

#cabecera { ... }

En HTML:

<header id="cabecera">...</header>

En la práctica, para estilos suele preferirse clases antes que abusar de id, porque son más reutilizables en otros contenidos o componentes.

La cascada: qué pasa cuando hay conflicto

Es habitual que varias reglas intenten aplicar estilos al mismo elemento. CSS resuelve esto con la aplicación en cascada: el navegador decide qué declaración gana según el origen y el orden, y si hace falta entra en juego la especificidad del selector. 

Un ejemplo típico que nos podemos encontrar es:

p { color: black; }
.destacado { color: blue; }

Si un párrafo tiene class=»destacado», el color será azul porque .destacado es más específico que p.

La cascada es una de las razones por las que, al empezar con CSS, a veces parece que no se aplique correctamente a algunos contenidos. normalmente sí funciona, pero otra regla está ganando en prevalencia de la cascada.

Accesibilidad y CSS

CSS puede mejorar mucho la experiencia de navegación y la accesibilidad presente en la página web o romperla con facilidad. Un mal CSS es responsable de estas barreras de accesibilidad:

  • Contraste de color insuficiente entre texto y fondo. 
  • Eliminar el foco del teclado por estética. Evita hacer outline: none; sin ofrecer una alternativa visible.
  • No respetar preferencias del usuario, como reducir animaciones con prefers-reduced-motion. 
  • Uso de tipografía ilegible o no adaptable a las necesidades del usuario.

Accesibilidad en los videos de la administración y las empresas gracias a la IA

La accesibilidad audiovisual ha dejado de ser un proyecto excepcional reservado a grandes presupuestos y tiempos infinitos. La combinación de automatización, producción en la nube y flujos de trabajo estandarizados está cambiando la economía de los subtítulos, las transcripciones y las audiodescripciones, reduciendo de forma drástica el coste económico por minuto y, sobre todo, el tiempo necesario para hacer que un video o presentación multimedia sea completamente accesible.
En este nuevo contexto, la excusa de que no es asumible desde el punto de vista económico pierde fuerza, porque el mercado ya ofrece modelos operativos diseñados precisamente para industrializar la accesibilidad sin sacrificar la calidad.

Este cambio viene de la mano de la Inteligencia Artificial (IA) y las nuevas oportunidades de automatización que ofrece a empresas y profesionales.

Este cambio no es únicamente tecnológico, es también regulatorio y reputacional. El Acta Europea de Accesibilidad establece estándares obligatorios para garantizar la accesibilidad de productos y servicios y traslada a empresas privadas y entidades públicas una responsabilidad más clara en la eliminación de barreras.
Según las WCAG para que un contenido multimedia sea accesible debe incorporar, como mínimo, audiodescripciones, subtítulos y transcripciones, y hacerlo de forma consistente en volumen y en el tiempo.

El problema, hasta hace poco, era que hacer accesible un vídeo implicaba un esfuerzo grande en tareas especializadas que van mucho más allá de poner subtítulos. En audiodescripción se requiere detectar silencios y duraciones, escribir un guion específico, rehacer locuciones cuando procede, seleccionar tomas válidas y montar el resultado final. En subtitulado de tipo closed captions es necesario identificar personajes, transcribir diálogos y locuciones, describir músicas y sonidos relevantes y controlar métricas como caracteres por línea y caracteres por segundo para asegurar legibilidad y sincronización. Además, la accesibilidad moderna tiende a incorporar transcripciones navegables, capítulos y artefactos en diferentes formatos listos para publicación en múltiples plataformas. Cuando todo esto se aborda artesanalmente, cada minuto adicional de video arrastra el mismo esfuerzo y el mismo coste provocando que el proceso de hacer accesible un contenido multimedia fuese económicamente más caro.

La automatización para la accesibilidad

La automatización orientada a accesibilidad marca un punto de inflexión en las oportunidades de negocio y de la situación legal sobre el concepto de adaptaciones razonables para la accesibilidad. Una producción multimedia se puede convertir en un contenido accesible generando variantes accesibles de forma automatizada, supervisada y autónoma, sin exigir conocimientos de edición de vídeo al equipo que produce el contenido. Esto permite producir en masa en la nube, obtener distintos archivos y formatos, y resolver de forma práctica un problema frecuente.

Automatización con calidad

Pero la automatización no elimina la exigencia de calidad. En accesibilidad, la calidad no es un lujo, es un requisito funcional. Un subtítulo mal segmentado o una audiodescripción imprecisa no sólo incumple criterios, también compromete la comprensión y la experiencia de usuario. Por eso resulta especialmente relevante el modelo de compañías como LViS Vally, que combinan automatización con una metodología de revisión humana en dos fases para garantizar que los elementos accesibles sean precisos, claros, estén sincronizados y sean plenamente comprensibles para cualquier persona. Ese componente humano, incorporado como control de calidad estructural y no como corrección ocasional, es el puente entre la eficiencia de la producción automática y la fiabilidad que requieren contenidos institucionales, educativos, formativos o corporativos.

La excusa del coste económico ya no es válida. Empresas como LViS Vally ofrecen tarifas individuales de 40 euros por hacer accesible un minuto de contenido de video. Esos precios debían ser multiplicados por 20 o por 100 hace un par de años.

Nuevas oportunidades de negocio en la accesibilidad gracias a la IA

Desde la perspectiva de negocio, la discusión también ha cambiado. La accesibilidad ya no compite sólo por presupuesto, compite por el riesgo y la oportunidad. El incumplimiento puede traducirse en sanciones, reclamaciones o deterioro reputacional, mientras que la accesibilidad bien ejecutada mejora la transparencia, amplía la participación y refuerza la percepción de modernidad y responsabilidad social. Además, la reutilización del contenido y la mejora en difusión y posicionamiento son efectos colaterales habituales cuando se dispone de transcripciones, textos y metadatos reutilizables. En otras palabras, la accesibilidad no es únicamente coste, es también una inversión que amplifica el valor del contenido y su alcance.

Gracias a las nuevas oportunidades que nos ofrece la Inteligencia artificial el ecosistema actual reduce el coste de oportunidad de hacer accesibles los contenidos multimedia y debilita la narrativa de que no hay presupuesto como justificación estructural. Con obligaciones normativas más próximas, con expectativas sociales crecientes y con soluciones que combinan automatización y control humano de calidad, la accesibilidad audiovisual se está convirtiendo en una práctica estándar. La pregunta relevante ya no es si una organización puede permitirse hacer accesible su contenido, sino si puede permitirse no hacerlo cuando existen vías rápidas, escalables y económicamente racionales para cumplir y, al mismo tiempo, ampliar el impacto de su comunicación.

La importancia de integrar la accesibilidad de forma temprana

La accesibilidad digital ya no puede considerarse como una tarea aislada ni como una etapa tardía de un proyecto. El enfoque conocido como shifting left en accesibilidad implica integrar criterios de inclusión desde las primeras fases del desarrollo desde la estrategia y la definición de requerimientos en lugar de retrasarlos al test final o a una fase de corrección previa al lanzamiento de un producto o servicio.

La práctica del shifting left no sólo mejora la experiencia de los usuarios, incluidas las personas con discapacidad, también repercute positivamente en la eficiencia del equipo, la calidad del producto, el cumplimiento normativo y la contención de costes en el proyecto.

Cuando la accesibilidad se aborda de forma temprana, se favorece una experiencia verdaderamente universal. Los usuarios con discapacidad por ejemplo personas con baja visión, sordera, dificultades de movilidad o discapacidad cognitiva se benefician de una interfaz diseñada con ellos en mente desde el inicio, y a la vez se mejora la usabilidad para todos los demás. Lo que se diseña con criterios de accesibilidad tiende a resultar más claro, más usable, más compatible y más duradero. Además, al evitar que los problemas de accesibilidad se acumulen o solo se detecten al final, se reduce las tareas de reconstrucción y aplicación de parches, se minimiza la deuda técnica y se evita el elevado coste de corrección que suele surgir cuando un defecto o barrera llega hasta producción.

El reparto de responsabilidades

Desde el punto de vista estratégico mover la accesibilidad hacia la izquierda del cronograma significa que cada rol del equipo asume responsabilidades concretas en distintos momentos del ciclo de vida del proyecto. Los estrategas, por ejemplo, deben asegurarse de que la arquitectura de la información, los flujos de usuario y las decisiones de contenido contemplen personas con discapacidad en sus perfiles y contextos de uso. Se deben plantear requisitos funcionales que incluyan criterios de accesibilidad como por ejemplo navegación mediante teclado, compatibilidad con lector de pantallas, descripciones alternativas de imágenes y explicar por qué estos importan tanto para una experiencia inclusiva.
Los diseñadores tienen la misión de aplicar desde muy temprano en los wireframes y prototipos principios como alto contraste de color, tipografías legibles, orden lógico de encabezados, espaciamiento adecuado, indicadores de foco, tamaño mínimo de zonas táctiles y opciones para reducir el movimiento.
Al hacerlo de esta manera, se crean componentes de diseño que facilitan una implementación accesible y evitan que el desarrollador tenga que arreglar errores complejos más adelante.

En la fase de desarrollo, tanto front-end como back-end juegan un papel esencial: los desarrolladores front-end deben aplicar marcado semántico correcto, roles ARIA sólo cuando se requieren, gestión efectiva del foco, navegación por teclado, estados visibles de los controles, compatibilidad con tecnologías de asistencia.

Los desarrolladores back-end deben asegurarse de que la estructura generada respete los criterios de accesibilidad, documentar las decisiones, automatizar pruebas accesibles en el flujo de integración continua y reducir la deuda de accesibilidad futura.

El equipo de QA debe incluir auditorías de accesibilidad automatizadas y manuales en el ciclo de verificación: no esperar al último sprint, más bien que la accesibilidad sea parte del definition of done.

En paralelo, los creadores de contenido como editores de texto, gestores de CMS o responsables de medios también tienen responsabilidades específicas: redactar en lenguaje claro, usar estructuras de encabezado correctas, proporcionar alternativas textuales para imágenes, vídeos subtitulados, evitar texto incrustado en imágenes y asegurar la coherencia entre contenido y navegación.

Si todos estos roles trabajan de forma coordinada desde el inicio, se genera una cultura de accesibilidad que atraviesa todo el proceso y evita que la accesibilidad sea un añadido apresurado, costoso e insuficiente.

Después de la publicación

Pero el trabajo no termina con el lanzamiento del sitio web o la entrega de la aplicación. La accesibilidad requiere mantenimiento continuo. Las nuevas funcionalidades, el nuevo contenido, las integraciones de terceros, las actualizaciones de plataforma pueden introducir regresiones de accesibilidad.

Por esta razón es necesario establecer mecanismos de monitorización como dashboards de accesibilidad, auditorías periódicas automatizadas, revisiones manuales cuando sean necesarias y formación continua del equipo para mantener actualizado el conocimiento sobre pautas como World Wide Web Consortium (W3C) y estándares legales locales.

También debe existir un compromiso organizativo que vincule la accesibilidad a métricas, a cultura interna, a responsabilidad compartida en los distintos equipos y al ciclo de vida completo del producto digital.

En definitiva, integrar la accesibilidad desde el arranque del proyecto digital mediante la estrategia de shifting left permite no solo cumplir con criterios éticos y legales, sino construir productos más robustos, usables y sostenibles. Equipos que adoptan este enfoque logran una experiencia más inclusiva, reducen costes de corrección, aceleran la entrega y evitan que la accesibilidad se convierta en un parche final. En un mundo en el que una proporción significativa de la población vive con alguna discapacidad o circunstancia temporal de uso, este enfoque deja de ser opcional y se convierte en una ventaja estratégica.

Ethical Shift: un festival para repensar el diseño digital con propósito

Del 17 al 18 de octubre de 2025, Sevilla acogerá Ethical Shift, el primer festival en España dedicado al diseño ético digital. Bajo el lema de conectar, inspirar y aprender junto a profesionales comprometidos, este evento propone una reflexión urgente: ¿cómo podemos diseñar productos digitales que no solo sean funcionales, sino también responsables, humanos e inclusivos?

El festival se celebrará en Magma Espacio (calle Bajeles 13, Sevilla) y combina talleres el viernes con conferencias el sábado. Las charlas abarcan temas como diseño resiliente, ética aplicada a la inteligencia artificial, diseño centrado en la vida (“Life-Centered Design”), y accesibilidad y comunicación clara.

Aunque la organización reconoce que en esta primera edición no puede garantizar el cumplimiento de todas las condiciones de accesibilidad, invita a las personas con necesidades específicas a contactar para que se realicen los ajustes necesarios. Esto muestra voluntad de abrir canales para la inclusión.

El evento ofrece charlas con enfoques de mucho interés como: diseño resiliente y ético: reconstruyendo procesos en la que se invita a cuestionar las estructuras de trabajo que subyacen al diseño digital; Life-Centered Design y el rol ético de quienes diseñan en la que se explica diseñar con una mirada no antropocéntrica, considerando vida, ecosistemas e interdependencia, y
temas tan actuales como la ética aplicada a la inteligencia artificial.

Puedes obtener más información y comprar las entradas en la página web del evento.