Cristian Sainz y Luis Palomares en uno de los eventos de Madblue dando una formación en accesibilidad a las startups asistentes al evento

Recomendaciones clave de accesibilidad para cualquier que startup diseñe mejores productos

La accesibilidad no es una consecuencia de la innovación; es una condición para que los productos o servicios sean más competitivos, reduciendo costes, evitando barreras, mejorando la experiencia de usuario y permitiendo que una startup llegue a más personas y a nuevos clientes. 

Este fue el eje del Bootcamp de Innovación Inclusiva y Accesibilidad del Reto ONCE Innova Emprendedores 2026, una sesión de tres horas en la que las ocho empresas finalistas trabajaron junto a especialistas de la ONCE para comprender qué significa desarrollar una solución realmente accesible. 

La formación fue impartida por profesionales de la ONCE con experiencia directa en accesibilidad, tecnología y atención a las necesidades de las personas con discapacidad. Participaron Cristian Sainz, responsable Puesto de Trabajo Digital y Accesibilidad en ONCE; Luis Palomares, jefe de la Unidad de Información y Accesibilidad de la Dirección de Autonomía Personal de ONCE; Agustín Aguirre, técnico especialista en herramientas tiflotécnicas y consultor de accesibilidad del Centro de Tiflotecnología e Innovación de la ONCE (CTI); y Laura Pozanco, técnica de rehabilitación de la Dirección Territorial de Madrid. 

La participación de la Unidad de Información y Accesibilidad y del CTI permitió abordar la accesibilidad desde perspectivas complementarias: el marco normativo, el diseño inclusivo, la experiencia de uso, la autonomía de las personas y la accesibilidad técnica de páginas web, aplicaciones y productos digitales. Las recomendaciones recogidas en este artículo proceden de los contenidos y ejemplos prácticos compartidos por estos profesionales durante el Bootcamp. 

El objetivo no era que los equipos salieran convertidos en expertos en accesibilidad, sino que aprendieran a formular las preguntas adecuadas antes de diseñar, programar y validar sus soluciones. 

Porque innovar también significa no dejar a nadie fuera. La accesibilidad no es una fase posterior del proceso, sino una condición para que la innovación sea realmente inclusiva y útil.  

La accesibilidad es una decisión de producto, no una adaptación posterior 

Cuando la accesibilidad se deja para el final, aparecen correcciones, rediseños, costes adicionales y deuda técnica que acompañará al producto durante toda su vida. En cambio, incorporarla desde el principio permite construir una base más robusta, escalable y preparada para diferentes formas de interacción. 

Esto no significa diseñar únicamente para personas con discapacidad. Significa asumir que no existe un único usuario medio. Hay personas que no ven la pantalla, no pueden utilizar un ratón, necesitan subtítulos o textos claros, tienen dificultades para manejar una pantalla táctil o utilizan el producto en situaciones de mucho ruido, poca luz o movilidad limitada. También están las personas mayores y quienes atraviesan una dificultad temporal provocada por una enfermedad o un accidente. 

Diseñar para esa diversidad no reduce el mercado: lo amplía. 

Además, una startup que demuestra que sus productos son inclusivos puede mejorar su reputación, diferenciarse frente a otras soluciones y acceder a organizaciones que ya evalúan la accesibilidad de las herramientas que compran para sus clientes y equipos.  

Recomendaciones clave de accesibilidad para cualquier startup 

Estas son algunas de las principales claves prácticas compartidas durante el Bootcamp. 

1. Incorpora la accesibilidad desde el primer boceto: No esperes a tener terminada la aplicación para comprobar si es accesible. 

La accesibilidad debe estar presente en la definición de requisitos, la arquitectura de la información, el diseño, el desarrollo, las pruebas y la evolución del producto. Corregir una solución terminada suele ser más caro y puede obligar a rehacer componentes enteros. 

El equipo técnico debe conocer desde el principio qué criterios tiene que aplicar. No debería depender de que el cliente recuerde pedirlos expresamente. 

2. No decidas quién va a utilizar tu producto: Una de las ideas más repetidas durante la sesión fue que una startup no debe decidir de antemano que su solución “no está dirigida” a personas con discapacidad. 

Un producto puede ser utilizado en contextos muy diferentes de los que imaginó inicialmente su equipo creador. Excluir una forma de uso también puede significar perder clientes. 

3. Comprueba que todo puede utilizarse sin ratón: La navegación por teclado es una de las pruebas más sencillas y reveladoras. Una persona debe poder recorrer los elementos interactivos mediante el tabulador, retroceder con la combinación correspondiente y activar botones, enlaces y controles con el teclado. 

4. Escribe textos alternativos que expliquen la función, no solo la imagen: No basta con que una imagen tenga un texto alternativo. Ese texto debe transmitir la información o la función que cumple. 

Lo mismo ocurre con la lupa del buscador o el icono de menú. En estos casos, el texto debe explicar qué acción permite realizar el elemento. 

Las imágenes puramente decorativas deben marcarse correctamente para que los productos de apoyo puedan ignorarlas y no añadan ruido innecesario a la navegación. 

5. Utiliza una estructura semántica y jerarquías coherentes: Una página puede verse ordenada y resultar, sin embargo, completamente plana para un lector de pantalla. 

Los títulos no deben ser únicamente textos grandes o en negrita. Deben estar identificados como encabezados y seguir una jerarquía lógica. También deben utilizarse correctamente listas, tablas, regiones y otros elementos estructurales. 

La semántica no es un detalle técnico: es el mapa que permite comprender y recorrer el contenido. 

6. Diseña formularios que informen de qué ocurre: Los formularios reúnen muchos de los errores más frecuentes de accesibilidad. 

Cada campo debe tener una etiqueta clara y asociada correctamente. No basta con cambiar el borde a color rojo o mostrar un mensaje que el lector de pantalla no anuncia. 

Los avisos dinámicos también deben comunicarse de manera accesible. Para determinadas actualizaciones puede ser necesario utilizar atributos como aria-live, que permiten que los productos de apoyo anuncien un cambio sin que la persona tenga que localizarlo por sí misma. 

7. Controla el foco en ventanas emergentes y avisos: Las ventanas modales, los mensajes de cookies y los avisos de finalización de sesión pueden convertirse en barreras críticas. 

Cuando aparece una ventana emergente, el foco debe desplazarse a ella y permanecer dentro hasta que la persona la cierre o complete la acción. Si el foco continúa recorriendo el contenido que ha quedado detrás, alguien puede navegar por toda la página sin saber que existe un aviso en primer plano. 

8. No dependas exclusivamente del color, la imagen, el sonido o la vibración: La información esencial debe estar disponible por más de una vía. 

Un gráfico necesita una alternativa que permita comprender sus datos. Un aviso no puede depender únicamente del color. Un vídeo puede necesitar subtítulos, transcripción o audiodescripción. Una solución de guiado no debería confiar solo en sonidos o vibraciones difíciles de distinguir. 

El Bootcamp puso especial atención en el riesgo de sobrecargar a la persona con información. Más avisos no significan necesariamente más accesibilidad. 

En sistemas de navegación, por ejemplo, comunicar cada elemento del entorno puede interferir con la orientación. La información debe ser concreta, relevante para la tarea y, cuando sea posible, configurable por la persona usuaria. La solución debería permitir ajustar la cantidad y el tipo de información a cada contexto. 

9. Diseña productos compatibles con las herramientas que ya utiliza la persona: Una solución accesible no debe obligar a utilizar varios dispositivos adicionales ni interferir con las herramientas habituales. 

Una tecnología puede ser muy avanzada, pero perder utilidad si sobrecarga a la persona, interfiere con otras señales o exige una atención excesiva. 

10. Haz accesible tanto la plataforma como el contenido: Permitir que una persona abra una plataforma no garantiza que pueda realizar las actividades que contiene. 

Puede ocurrir que una plataforma sea accesible, pero sus contenidos no lo sean. También puede suceder lo contrario: que existan materiales accesibles a los que la persona no puede llegar porque la interfaz crea una barrera. 

La experiencia debe evaluarse de principio a fin. 

11. Combina validadores automáticos con pruebas manuales: Las herramientas automáticas son útiles, pero no pueden determinar por sí solas si un producto es accesible. 

Pueden detectar, por ejemplo, la ausencia de etiquetas, problemas de contraste o determinados errores de código. Sin embargo, no siempre pueden valorar si un texto alternativo explica adecuadamente una imagen, si una jerarquía resulta comprensible o si una interacción tiene sentido para quien la utiliza. 

12. Valida con personas reales, pero distingue experiencia y auditoría: Probar con personas con discapacidad es imprescindible, aunque no todas las pruebas responden al mismo objetivo. 

Una persona usuaria puede explicar dónde se pierde, qué información necesita o qué parte de la experiencia le genera fricción. Una persona con conocimiento técnico puede además relacionar esa barrera con los criterios y soluciones de accesibilidad aplicables. 

Ambas perspectivas son necesarias, pero no son intercambiables. 

También conviene probar con perfiles diferentes. No todas las personas tienen el mismo nivel de experiencia tecnológica, autonomía o familiaridad con los productos de apoyo. Diseñar únicamente para usuarios muy avanzados puede ocultar las dificultades que encontrará una parte importante del público. 

Las cuatro bases de una web accesible 

Durante la parte técnica se presentaron los cuatro principios que estructuran las pautas de accesibilidad web: 

  • Perceptible: la información debe poder recibirse de distintas formas. Por ejemplo, una imagen relevante necesita una alternativa textual. 
  • Operable: todos los controles y procesos deben poder utilizarse, también mediante teclado o tecnologías de apoyo. 
  • Comprensible: la información, la navegación y las respuestas del sistema deben resultar claras y previsibles. 
  • Robusto: el contenido debe estar correctamente construido para funcionar con diferentes navegadores, dispositivos y productos de apoyo. 

Estos principios se concretan en criterios con niveles A, AA y AAA. El cumplimiento normativo suele exigir un nivel determinado, pero durante el Bootcamp se insistió en que cumplir el mínimo no debería ser el único objetivo. 

La pregunta no es únicamente “¿cumple la norma?”, sino también “¿puede una persona utilizar esta solución con autonomía y completar la tarea que se propone?”. 

Un aprendizaje aplicable más allá del Reto ONCE Innova Emprendedores 

El Bootcamp trasladó todos estos principios a los cuatro retos de la convocatoria: la visualización y trazabilidad de productos de venta, la detección de obstáculos en exteriores, la navegación accesible en centros y las herramientas de formación para vendedores. 

Uno de los principales objetivos del programa es que las soluciones no se diseñen desde suposiciones, sino desde el conocimiento técnico, la experiencia de las personas y la validación en contextos reales. 

Porque la accesibilidad no consiste en hacer una versión especial de un producto. Consiste en construir desde el principio una solución mejor preparada para la diversidad de personas, capacidades y situaciones en las que tendrá que funcionar.