Declaración de accesibilidad

Una declaración de accesibilidad es más que un escudo legal: es una declaración pública del compromiso de una empresa con el diseño inclusivo. Para propietarios de empresas y profesionales del marketing, es el principal punto de contacto para que los usuarios con discapacidad entiendan cómo funciona un sitio y cómo pedir ayuda cuando algo no funciona. Para los profesionales técnicos, es la documentación de los estándares técnicos aplicados a un producto digital.

Redactar una declaración de accesibilidad eficaz exige cambiar de perspectiva: pasar del marketing a la transparencia. La mayoría de las declaraciones corporativas emplean un lenguaje vago sobre «aspirar a la excelencia», que aporta poco a un usuario de lector de pantalla que se enfrenta a un formulario que no funciona. Una declaración profesional detalla los estándares concretos utilizados (como las WCAG 2.2), la metodología de pruebas empleada y, sobre todo, las carencias conocidas de la experiencia. Esta honestidad reduce el riesgo legal al demostrar un esfuerzo de buena fe y mejora la experiencia del usuario al ofrecer alternativas claras a los recorridos que no funcionan.

Para ilustrar cómo crear este documento desde cero, seguiremos un proyecto hipotético de un estudio creativo de tamaño medio. Este ejemplo ilustrativo recorre el proceso desde la auditoría inicial hasta la publicación final de la declaración, y explica las decisiones técnicas y el razonamiento detrás de cada información divulgada.

Fase 1 del proyecto: definición del objetivo de conformidad

El primer paso de cualquier proyecto de accesibilidad es decidir qué estándar se quiere cumplir. Para este proyecto ilustrativo, el estudio optó por WCAG 2.2 Level AA. Las Pautas de Accesibilidad para el Contenido Web (WCAG) son la referencia de excelencia a nivel mundial, y el nivel AA es el que suele exigirse para cumplir la Americans with Disabilities Act (ADA) en EE. UU. y la Section 508 en los contratos federales.

El estudio tenía que elegir entre los niveles A, AA y AAA. El nivel A es el mínimo; no cumplirlo significa que el sitio no funciona en lo esencial para muchas personas. El nivel AAA es el más alto, pero a menudo resulta poco práctico para sitios comerciales; por ejemplo, exige interpretación en lengua de signos para todo el audio pregrabado. El nivel AA ofrece el equilibrio necesario entre usabilidad y viabilidad.

La decisión de apuntar a la versión 2.2 en lugar de la 2.1 se basó en la necesidad de abordar interacciones móviles más recientes, como el “tamaño del objetivo” (que los botones sean lo bastante grandes para tocarlos sin errores) y los “movimientos de arrastre” (ofrecer una alternativa basada en clics a las interfaces de arrastrar y soltar). Al fijar este objetivo desde el principio, el estudio evitó tener que corregir a posteriori componentes que habrían superado la 2.1 pero no la 2.2.

Fase 2 del proyecto: auditoría técnica y corrección

Una vez fijado el objetivo, el estudio comenzó la auditoría. Dividió el trabajo en dos categorías: escaneo automatizado y verificación manual. Utilizó herramientas como Axe DevTools y WAVE para el barrido inicial, pero sabía que estas herramientas solo detectan una fracción de los problemas.

Landmarks y navegación

La auditoría reveló que el sitio carecía de una estructura de documento clara. Los usuarios de lectores de pantalla dependen de los landmarks (como <main>, <nav> y <footer>) para saltar entre secciones. El estudio implementó un landmark principal en cada página y añadió un enlace “saltar al contenido”. Este enlace es invisible para los usuarios videntes, pero se convierte en el primer elemento enfocable para quienes usan el teclado, lo que les permite omitir el menú de navegación e ir directamente al contenido principal.

Contraste de color y elementos visuales

El estudio comprobó todo el texto con la relación de contraste de 4,5:1 exigida para el texto normal y de 3:1 para el texto grande o los componentes de interfaz. Fue especialmente difícil porque el sitio ofrecía temas claro y oscuro. Utilizaron un comprobador de contraste para asegurarse de que los colores de acento de la marca siguieran siendo legibles en ambos modos. En los componentes de interfaz —como los bordes de los campos de entrada— garantizaron una relación de 3:1 para que los usuarios con baja visión pudieran identificar dónde empezaba y terminaba cada campo del formulario.

Componentes interactivos

Una de las partes más complejas del sitio era un control deslizante de imágenes “antes/después” que mostraba transformaciones de diseño. Inicialmente solo funcionaba con el ratón. El estudio lo reconstruyó con un control de rango (<input type=range>). Así se garantizó que el control fuera accesible con la tecla Tab y que la posición actual se anunciara a los lectores de pantalla como un porcentaje, lo que hacía accesible la comparación visual para los usuarios sin visión.

Fase 3 del proyecto: prueba de los recorridos de usuario

El estudio no se limitó a probar páginas: probó recorridos. Una página accesible no sirve de nada si el camino desde la página de aterrizaje hasta el pago está roto. Identificó cuatro recorridos críticos: consulta, solicitud de presupuesto, registro de prueba y pago.

Para cada recorrido, el equipo realizó tres tipos de pruebas:

1. Pruebas solo con teclado: Recorrido de todo el flujo usando únicamente las teclas Tab, Mayús+Tab y Enter. Verificaron que el “indicador de foco” (el anillo alrededor del elemento activo) fuera muy visible y que nunca quedara oculto por outline: none en el CSS.
2. Pruebas con lector de pantalla: Uso de NVDA (Windows) y VoiceOver (macOS) para garantizar que el orden de lectura fuera lógico y que los botones tuvieran etiquetas descriptivas (p. ej., “Enviar solicitud de presupuesto” en lugar de solo “Enviar”).
3. Pruebas de reajuste: Ampliación del navegador al 400 %. Según las WCAG, el sitio debe reajustarse para que el usuario no tenga que desplazarse en dos dimensiones (horizontal y vertical) para leer una línea de texto.

Durante esta fase, el equipo descubrió que algunos artículos antiguos de la biblioteca contenían tablas anchas. Estas tablas eran accesibles con el teclado, pero obligaban a desplazarse horizontalmente en dispositivos móviles. Aunque podrían haber reconstruido todas las tablas, el estudio tomó una decisión de negocio: corregirían las plantillas para todo el contenido nuevo, pero incluirían las tablas heredadas como “limitación conocida” en la declaración. Es una solución de compromiso práctica que prioriza las páginas más utilizadas sin dejar de ser honesta sobre el resto.

Fase 4 del proyecto: redacción de la declaración

Terminado el trabajo técnico, el estudio empezó a redactar la declaración de accesibilidad. Evitó el habitual tono legalista y optó por un documento que sirviera de guía para el usuario. El objetivo era responder a tres preguntas: ¿Cuál es el estándar? ¿Qué funciona? ¿Qué no funciona?

Definición del estado de conformidad

El estudio declaró explícitamente: «Este sitio aspira a cumplir las WCAG 2.1 de nivel AA». Explicaron el motivo de la palabra «aspira», señalando que el sitio cambia cada semana. Esta transparencia evita que la declaración se convierta en un riesgo legal en el momento en que se publique un nuevo contenido sin una auditoría completa.

Enumerar los «aciertos»

La declaración enumeraba logros técnicos concretos. En lugar de decir “el sitio es accesible”, escribieron:

• «Cada página tiene un landmark main y un enlace de salto que funciona».
• «El texto cumple un contraste de 4.5:1 y los componentes de la interfaz, de 3:1».
• «El movimiento respeta prefers-reduced-motion».

Al enumerar estándares concretos, el estudio ofreció una lista de comprobación que un auditor externo o un usuario experto podía verificar. Por ejemplo, mencionar prefers-reduced-motion indica al usuario que el sitio suprimirá automáticamente las animaciones si su sistema operativo está configurado para reducir el movimiento, algo fundamental para los usuarios con trastornos vestibulares.

La sección de “limitaciones conocidas”

Esta es la parte más importante del documento. La mayoría de las empresas omiten sus fallos, pero el estudio decidió destacarlos. Enumeró tres carencias concretas:

1. Tablas heredadas: Algunos artículos antiguos tienen tablas que se desplazan en lugar de reajustarse en pantallas pequeñas.
2. Calidad del texto alternativo: Aunque todas las imágenes tienen atributos alt, algunos de la biblioteca más antigua son descriptivos pero no ideales.
3. Contenido incrustado de terceros: Elementos como los vídeos incrustados de YouTube o los feeds de redes sociales no están bajo el control del estudio y puede que no cumplan plenamente.

Al reconocer estos fallos, el estudio aumentó de hecho la credibilidad del resto de la declaración. Un usuario que se encuentre con una tabla con desplazamiento la verá mencionada en la declaración y comprenderá que el estudio es consciente del problema, en lugar de suponer que el sitio simplemente está mal construido.

Fase 5 del proyecto: establecimiento del circuito de comentarios

Una declaración de accesibilidad fracasa si no ofrece una forma de notificar problemas. El estudio no se limitó a incluir un enlace genérico de «Contacto»: creó un protocolo específico para los problemas de accesibilidad.

La clave aquí es la promesa de una vía alternativa. Para una persona que usa un lector de pantalla, un formulario que no funciona es un muro infranqueable. Decirle “estamos trabajando en ello” no sirve de nada. Decirle “hoy no podemos arreglar el formulario, pero si nos envía sus datos por correo electrónico, tramitaremos su presupuesto manualmente” es una solución funcional.

Ejemplo práctico: el coste de adaptar a posteriori frente a construir de forma nativa

Para justificar el presupuesto de este proyecto, el estudio analizó el coste de incorporar la accesibilidad de forma nativa frente a adaptarla después del lanzamiento del sitio. Es un dilema habitual para los propietarios de empresas.

En este ejemplo ilustrativo, el estudio comparó dos proyectos de landing page similares. El proyecto A se creó con WCAG 2.2 AA como requisito principal. El proyecto B se creó priorizando la rapidez y la estética, y la accesibilidad solo se abordó tras la queja de un cliente.

El motivo del salto de precio en el proyecto B es la «deuda estructural». En el proyecto A, los desarrolladores usaron un <button> para un elemento clicable. En el proyecto B, usaron un <div> con un evento onClick. Para que el <div> fuera accesible, tuvieron que añadir tabindex="0", role="button" y un detector de eventos de teclado para las teclas Intro y Espacio. Tuvieron que hacerlo con cada uno de los elementos interactivos del sitio, lo que requiere mucho más trabajo que usar simplemente la etiqueta HTML correcta desde el principio.

Comparación de estrategias de accesibilidad

No todas las empresas tienen presupuesto para una auditoría manual completa. Según el tamaño del sitio y el riesgo legal, conviene aplicar estrategias distintas. El estudio utiliza los siguientes criterios para decidir la profundidad de la declaración de accesibilidad y del trabajo que la acompaña.

El veredicto del estudio es que el “enfoque minimalista” es un falso ahorro. Aunque ahorra dinero el primer mes, deja a la empresa expuesta a demandas por la ADA y aleja a una parte importante del mercado. Para cualquier sitio comercial, el “enfoque integral” —en el que la declaración de accesibilidad es un documento vivo respaldado por pruebas manuales— es la única vía sostenible.

El entregable final: la estructura de la declaración

La declaración de accesibilidad final del estudio se organizó en una jerarquía concreta para que los usuarios pudieran encontrar la información rápidamente. Evitaron enterrarla en el pie de página con una letra diminuta; en su lugar, le dedicaron una página propia con un encabezado claro.

Siguiendo esta estructura, el estudio transformó un aburrido requisito legal en una herramienta de atención al cliente. Ya no tenía que «esperar» que el sitio fuera accesible: sabía exactamente en qué punto estaba, y sus usuarios también.

Mantenimiento de la declaración a lo largo del tiempo

El proyecto no terminó con la publicación de la página. La accesibilidad no es una casilla que se marca una sola vez; es una tarea de mantenimiento. El estudio implantó una “definición de terminado” para todo el contenido nuevo. No se podía publicar ninguna página nueva si no superaba una comprobación básica de teclado y contraste.

Además, programaron una revisión trimestral de la sección «Limitaciones conocidas». Si una tabla heredada se actualizaba a un formato adaptable, se eliminaba de la lista de limitaciones. Si se añadía un nuevo plugin de terceros que resultaba no ser accesible, se incorporaba a la lista de inmediato. Así, la declaración sigue reflejando con exactitud el estado actual del sitio.

Para los profesionales del estudio, esto supuso integrar la accesibilidad en el sistema de diseño. Crearon una biblioteca de componentes accesibles (botones, formularios y ventanas modales) probados previamente para WCAG 2.2 AA. Al usar estos componentes, el equipo redujo el riesgo de introducir nuevos errores, de modo que la declaración de accesibilidad rara vez tenía que actualizarse para añadir nuevos fallos, solo para eliminar los antiguos.

La integración de la accesibilidad en el ciclo de desarrollo

La verdadera accesibilidad no es una fase de auditoría final, sino un requisito distribuido a lo largo de todo el flujo de trabajo. Para superar una mentalidad reactiva de «arreglarlo después», las organizaciones deben integrar puntos de control de accesibilidad en la Definition of Ready (DoR) y la Definition of Done (DoD). Esto exige pasar de tratar la accesibilidad como una tarea de control de calidad (QA) a tratarla como un requisito funcional central. Cuando la accesibilidad se relega al final del ciclo de producción, el coste de la corrección aumenta exponencialmente y a menudo exige cambios estructurales en el DOM o modificaciones fundamentales en la lógica de navegación que pueden desestabilizar una versión. En su lugar, el diseño del flujo de trabajo debe aplicar los principios «Shift Left», según los cuales los requisitos de accesibilidad se definen en la fase de wireframing. Esto significa que un diseño no puede pasar a ingeniería a menos que incluya un orden de foco documentado, etiquetas ARIA para los componentes complejos y un informe de validación del contraste de color. Al hacer de la accesibilidad un requisito previo para el desarrollo, el calendario de producción sigue siendo predecible y se evita el habitual «cuello de botella de accesibilidad» que se produce 48 horas antes de un lanzamiento programado.

Definición de responsabilidades por rol y la matriz de responsabilidades

La ambigüedad sobre quién es «dueño» de la accesibilidad es la principal causa de los fallos sistémicos. Un modelo operativo sólido asigna responsabilidades específicas y sin solapamientos dentro del equipo de producto. El Product Manager (PM) es responsable del requisito: debe garantizar que las historias de usuario de accesibilidad se prioricen en el backlog junto con las solicitudes de funcionalidades. El diseñador UX/UI es responsable del plano: se encarga de la estructura semántica, la jerarquía de encabezados y la accesibilidad visual de la interfaz. El ingeniero front-end es responsable de la implementación: garantiza que el código se ajusta al plano y supera las pruebas automáticas de linting. Por último, el ingeniero de QA es responsable de la verificación: realiza pruebas manuales con lector de pantalla y auditorías de navegación por teclado. Para evitar lagunas, conviene utilizar una matriz de asignación de responsabilidades (RACI). Por ejemplo, aunque el ingeniero es el «responsable final» (Accountable) del código, al diseñador se le «consulta» (Consulted) sobre el comportamiento de los estados de foco. Así se evita el error habitual de que los ingenieros adivinen el orden de tabulación previsto, lo que da lugar a una experiencia de usuario fragmentada que requiere varias rondas de rediseño.

Operativización de los traspasos y estándares de documentación

El traspaso de diseño a ingeniería es donde se pierde la mayor parte de la intención de accesibilidad. Para mitigarlo, los traspasos deben pasar de exportaciones de imágenes estáticas a “fichas de especificaciones de accesibilidad”. Estas fichas deben asignar explícitamente a cada elemento interactivo su comportamiento previsto con el teclado y el anuncio del lector de pantalla. Por ejemplo, un menú desplegable personalizado no debe limitarse a representarse visualmente; el traspaso debe especificar que utiliza aria-expanded para comunicar su estado y que la tecla Enter activa la selección. Además, el traspaso debe incluir un “perfil de accesibilidad del componente” para los elementos reutilizables. Si existe un sistema de diseño, cada componente de la biblioteca debe tener un conjunto documentado de requisitos de accesibilidad. Cuando un desarrollador toma un “botón principal” de la biblioteca, debe heredar un perfil de accesibilidad ya validado. Esta estandarización reduce la carga cognitiva del desarrollador y garantiza que el calendario de producción no se descarrile por la depuración repetida de los mismos componentes básicos en distintas páginas.

Planificación de la producción y el margen para correcciones

Programar la accesibilidad como un “sprint” independiente es un error estratégico que genera deuda técnica. En su lugar, las tareas de accesibilidad deben fragmentarse y repartirse a lo largo del calendario estándar de desarrollo de funcionalidades. Se puede usar un sistema de “puntos de historia ponderados”, en el que a cualquier historia con elementos interactivos complejos se le asignan puntos adicionales para cubrir las pruebas de accesibilidad. Además, el calendario de producción debe incluir un “margen de corrección”: una ventana de tiempo dedicada entre el hito de funcionalidades completas y la versión final. Este margen no es para el desarrollo principal, sino para pulir la experiencia a partir de pruebas de usuario con personas con discapacidad. Si un equipo descubre un bloqueo de navegación crítico durante esta ventana, el margen evita que el proyecto acabe en un lanzamiento retrasado. Al destinar entre el 10 y el 15 % de cada sprint específicamente a perfeccionar la accesibilidad, el equipo evita el periodo de “crunch” y garantiza que el producto final no solo cumpla la normativa, sino que sea realmente usable.

Ejemplo operativo práctico: el flujo de trabajo de la “tabla de datos compleja”

Consideremos la implementación de una tabla de datos dinámica y ordenable. En un flujo de trabajo tradicional, el desarrollador construye la tabla y, más tarde, QA informa de que los lectores de pantalla no identifican la columna ordenada. En un flujo de trabajo que prioriza la accesibilidad, el proceso sigue estos pasos concretos:

• Fase de requisitos: El jefe de proyecto especifica que la tabla debe poder recorrerse con el teclado y que los estados de ordenación deben anunciarse a los lectores de pantalla.
• Fase de diseño: El diseñador crea una especificación que muestra el indicador visual de «orden ascendente» y «orden descendente», y documenta que el encabezado de la tabla debe usar <th scope="col">.
• Fase de desarrollo: El ingeniero implementa la tabla con HTML semántico y añade atributos aria-sort. Ejecuta un análisis automatizado local (p. ej., Axe) antes de enviar el Pull Request.
• Verificación del traspaso: El ingeniero muestra al diseñador el orden de tabulación con el teclado para garantizar que el flujo lógico coincide con la UX prevista.
• Validación de QA: El especialista de QA prueba la tabla con NVDA o VoiceOver y verifica específicamente que la acción de «ordenar» se anuncia como un cambio de estado.

Este enfoque estructurado garantiza que, cuando la funcionalidad llega al entorno de staging final, los retos de accesibilidad más difíciles ya se han resuelto.

Criterios de decisión para las soluciones de compromiso en accesibilidad

En entornos de producción de ritmo rápido, los equipos se enfrentan a veces a conflictos entre los deseos estéticos y los requisitos de accesibilidad. Para resolverlos sin optar por el camino más fácil, las organizaciones deben aplicar un conjunto estandarizado de criterios de decisión. Cuando surge un conflicto, el equipo debe plantearse las siguientes preguntas en este orden:

1. ¿Incumple el diseño propuesto algún criterio de conformidad del nivel AA de las WCAG? Si es así, el diseño debe modificarse. El cumplimiento es una base innegociable.
2. ¿Empeora notablemente la solución accesible alternativa la experiencia de los usuarios sin discapacidad? Si la respuesta es no, se adopta la solución accesible aunque suponga un ligero aumento del tiempo de desarrollo.
3. ¿Existe una vía de “mejora progresiva”? ¿Podemos ofrecer una versión básica y accesible de la funcionalidad que luego se enriquezca con elementos visuales complejos para los usuarios que puedan utilizarlos?
4. ¿Crea el enfoque «primero lo visual» una barrera cognitiva? Si un diseño depende únicamente del color para transmitir significado, no supera los criterios de decisión y debe rediseñarse para incluir texto o iconos.

Al aplicar estos criterios, el equipo elimina la subjetividad del proceso y evita que la «pureza del diseño» se imponga a la necesidad legal y ética de la accesibilidad.

Errores poco evidentes en la gestión de la accesibilidad

Muchas organizaciones caen en «la trampa de las herramientas», creyendo que superar un análisis automatizado de accesibilidad equivale a tener un producto conforme. Las herramientas automáticas suelen detectar solo entre el 30-40% de los problemas de accesibilidad; no pueden saber si un orden de tabulación es lógico o si una descripción de texto alternativo resulta realmente útil. Otro error habitual es «el silo del especialista», en el que se recurre a un único «experto en accesibilidad» al final del proyecto. Esto crea un cuello de botella y fomenta una cultura en la que el resto del equipo siente que no necesita aprender sobre accesibilidad porque «el experto lo arreglará». El resultado es un ciclo de errores repetidos y resentimiento. Por último, los equipos a menudo pasan por alto la «accesibilidad temporal»: el hecho de que la accesibilidad se deteriora con el tiempo. Un producto accesible en el lanzamiento puede dejar de serlo tras una sola actualización de CSS o la integración de una nueva biblioteca JS. Sin un conjunto de pruebas de regresión específico para la accesibilidad, el calendario de producción acabará consumido por «errores fantasma» que reaparecen cada vez que se actualiza el código.

Optimización y normalización de los recursos de origen

La accesibilidad empieza en la fase de creación de los recursos, mucho antes de que un lector de pantalla interactúe con el DOM final. En los recursos visuales, los archivos fuente deben normalizarse para que las relaciones de contraste se calculen a partir de los valores hexadecimales reales y no de los colores percibidos. Los diseñadores deben utilizar una “capa semántica” en sus herramientas de diseño y etiquetar los elementos como “heading”, “button” o “landmark” dentro del archivo fuente. Así se evita el error habitual de confiar en el estilo visual para transmitir la jerarquía, lo que a menudo provoca la pérdida del significado estructural en el traspaso a desarrollo. Además, a todos los recursos rasterizados se les deben eliminar los metadatos propietarios que pueden interferir con el análisis de las tecnologías de asistencia y sustituirlos por etiquetas XMP estandarizadas que incluyan borradores preliminares del texto alternativo.

Especificaciones técnicas de los formatos de entrega

La elección del formato de entrega influye directamente en la perceptibilidad del contenido. Para los gráficos vectoriales, SVG es el estándar obligatorio frente a PNG o JPG por su capacidad de alojar las etiquetas <title> y <desc> directamente en la estructura XML. Al entregar archivos PDF, la especificación debe pasar de «listo para imprimir» a «PDF etiquetado» (PDF/UA), de modo que el orden lógico de lectura quede definido explícitamente en el árbol del documento en lugar de depender de las coordenadas visuales de los bloques de texto. En el caso de los recursos audiovisuales, la entrega debe incluir archivos VTT (WebVTT) sincronizados para los subtítulos en lugar de subtítulos «incrustados», lo que permite a los usuarios personalizar el tamaño, el color y el fondo del texto para lograr la máxima legibilidad.

Organización de archivos y mapeo semántico

Para mantener la accesibilidad a gran escala, la organización de los archivos debe reflejar el árbol de accesibilidad previsto. Los recursos deben almacenarse en una estructura de directorios que refleje su función semántica (p. ej., /assets/ui-controls/ frente a /assets/decorative/). Este rigor organizativo permite que los auditores automáticos de accesibilidad apliquen reglas de validación distintas según la ruta de la carpeta. Un criterio de decisión clave es la división «decorativo frente a informativo»: cualquier recurso almacenado en una carpeta decorativa debe ser ignorado programáticamente por los lectores de pantalla (mediante aria-hidden="true" o atributos alt vacíos), mientras que los recursos informativos deben vincularse a un archivo de manifiesto con su equivalente textual que acompañe al paquete de entrega.

Ejemplo operativo: la cadena de producción de imágenes accesibles

Pensemos en la implementación de una visualización de datos compleja. El flujo operativo es el siguiente: primero, los datos sin procesar se exportan como CSV para ofrecer una alternativa en forma de tabla. Segundo, el gráfico se exporta como SVG con un <title> interno que resume la tendencia. Tercero, se redacta un fragmento HTML de descripción larga que explica los matices de los datos. Por último, estos tres archivos se agrupan con una convención de nombres coherente (p. ej., chart_01_visual.svg, chart_01_data.csv, chart_01_desc.html). Así, sea cual sea la herramienta de asistencia del usuario, existe una vía directa y predecible hacia la información.

Errores de implementación y lógica de decisión

Un descuido técnico frecuente es la trampa de la «redundancia del texto alternativo», en la que los desarrolladores incluyen las palabras «imagen de» o «foto de» en los metadatos del recurso, algo que los lectores de pantalla ya anuncian, lo que crea una experiencia de usuario repetitiva y frustrante. Otro error es confiar en el texto alternativo «generado automáticamente» por herramientas de IA sin verificación humana; aunque es eficiente, a menudo no capta la intención de la imagen y ofrece una descripción literal (p. ej., «un hombre sentado a un escritorio») en lugar de una funcional (p. ej., «Empleado mostrando la interfaz del software»). Los criterios de decisión para seleccionar recursos deben priorizar el «mínimo común denominador» tecnológico: si un formato de alta fidelidad rompe la accesibilidad para el 5% de los usuarios, la alternativa accesible de menor fidelidad debe ser el método de entrega principal.