Accesibilidad en los Servicios Bancarios y Financieros: Lo que exige la ley en 2025

En 2025, una clienta con discapacidad visual intenta solicitar una hipoteca en el sitio web de un banco importante. El formulario de solicitud no tiene etiquetas visibles, los mensajes de error no son anunciados por su lector de pantalla y el indicador de progreso está construido completamente en CSS sin texto alternativo accesible. Abandona el proceso por completo. Mientras tanto, el equipo legal de su banco ya está gestionando una carta de requerimiento, una de las 3,117 demandas por accesibilidad web presentadas en los tribunales federales de EE. UU. solo el año pasado, un aumento del 27% con respecto al año anterior. Para las instituciones financieras, 2025 es el año en que el argumento legal y ético a favor de la accesibilidad convergió en algo imposible de ignorar.

Por qué los servicios financieros enfrentan obligaciones de accesibilidad reforzadas

La banca no es un servicio discrecional. Las personas necesitan acceso a su dinero, crédito y cuentas de inversión para participar plenamente en la vida económica moderna. Para los clientes con discapacidad, los servicios financieros accesibles no son un lujo: son esenciales para la participación económica y la independencia. Esa realidad se refleja cada vez más en la forma en que los tribunales, los reguladores y los legisladores tratan a las instituciones financieras.

Los bancos son “lugares de alojamiento público” y, por lo tanto, están cubiertos por el Título III de la Ley de Estadounidenses con Discapacidades (ADA). En virtud del Título III de la ADA, los lugares de alojamiento público —una categoría amplia que incluye bancos y otros negocios abiertos al público— están obligados a proporcionar servicios accesibles para las personas con discapacidad. Aunque la ADA se promulgó en 1990 y se centró inicialmente en el acceso físico, los tribunales han ampliado de forma constante su alcance a las plataformas digitales, las aplicaciones móviles y los portales de banca en línea.

Con el auge de la banca digital, aproximadamente dos tercios de los adultos en EE. UU. dependen ahora de plataformas en línea —sitios web y aplicaciones— para gestionar sus finanzas. Ese cambio ha hecho que la infraestructura digital inaccesible no sea simplemente inconveniente, sino genuinamente discriminatoria. Para las aproximadamente 61 millones de personas con algún tipo de discapacidad en EE. UU., los bancos y las instituciones financieras deben garantizar que sus plataformas digitales cumplan con la Sección 508 y la ADA, ya que la accesibilidad web es fundamental para que las personas con discapacidad puedan utilizar estos servicios. No proporcionar acceso a sitios web, aplicaciones y documentos en línea —como formularios y PDF— puede derivar en litigios, una tendencia que aumenta de forma constante.

El sector financiero también se enfrenta a una red más amplia de exposición regulatoria más allá de la ADA. Las instituciones financieras se enfrentan a múltiples mandatos de accesibilidad: el Título III de la ADA exige que los bancos, como lugares de alojamiento público, proporcionen servicios accesibles, lo que se interpreta cada vez más como algo que incluye los sitios web; la Sección 504 se aplica a las instituciones financieras que reciben fondos federales; la Sección 508 rige los servicios financieros contratados por el gobierno; y leyes estatales como la Ley Unruh de California y la Ley de Derechos Humanos de Nueva York proporcionan protecciones adicionales. Además, la Oficina de Protección Financiera del Consumidor (CFPB) examina la accesibilidad como parte de los préstamos justos y la protección del consumidor, y la Oficina del Contralor de la Moneda (OCC) incluye la accesibilidad en su guía de gestión de riesgos.

El panorama legal en EE. UU. en 2025: récord de demandas y aumento del riesgo

El entorno de litigios nunca ha sido tan intenso. Los demandantes presentaron 3,117 demandas por accesibilidad web en tribunales federales en 2025, un aumento del 27% con respecto a 2024. Las demandas por accesibilidad web presentadas en tribunales federales repuntaron tras un descenso de dos años, alcanzando un total de 3,117 demandas que alegaban que los demandantes con discapacidad no podían utilizar los sitios web porque no estaban diseñados para ser accesibles.

Las demandas por accesibilidad web representaron el 36% del número total de demandas del Título III de la ADA presentadas en tribunales federales en 2025: 3,117 de 8,667 casos. Y esa cifra casi con seguridad subestima la exposición real. Lo más notable en 2025 es que las demandas y acuerdos sobre accesibilidad digital ya no se limitan a los tribunales federales. Los demandantes presentaron cada vez más demandas en tribunales estatales, especialmente en Nueva York y California. Estos tribunales permiten a los demandantes recuperar daños económicos, no solo medidas cautelares, costas judiciales y honorarios legales.

Para las instituciones financieras específicamente, los litigios por accesibilidad web en banca siguen siendo comunes: según el State of Digital Accessibility Report (SODAR), el 57% de los profesionales de servicios financieros informó haber participado en acciones legales relacionadas con la accesibilidad digital solo en el último año. Los acuerdos rara vez son baratos. Los acuerdos suelen oscilar entre $5,000 y $75,000, más honorarios de abogados, costos de rediseño y gastos de monitoreo. Cuando esos costos se multiplican por cartas de requerimiento, acciones en tribunales estatales y plazos obligatorios de remediación, la exposición financiera crece sustancialmente.

El Departamento de Justicia ha enfatizado cada vez más la aplicación de la accesibilidad digital, dejando claro que los servicios de banca en línea deben ser tan accesibles como las sucursales físicas, con nuevas directrices que exigen el cumplimiento de WCAG 2.1 Nivel AA para los servicios digitales antes de abril de 2026. La próxima norma del Título II para entidades gubernamentales sienta un precedente que probablemente seguirá la aplicación en el sector privado, y las instituciones financieras con contratos gubernamentales o depósitos asegurados federalmente harían bien en tratar WCAG 2.1 AA como su piso, no su techo.

La Ley Europea de Accesibilidad: ahora aplicable y dirigida directamente a la banca

Para las instituciones que operan en la Unión Europea o prestan servicios a clientes en ella, 2025 marcó un punto de inflexión decisivo. La Ley Europea de Accesibilidad (Directiva (UE) 2019/882) se aplica desde el 28 de junio de 2025 en todos los Estados miembros y busca eliminar las barreras para los consumidores con discapacidad armonizando los requisitos de accesibilidad en el mercado interior para determinados productos, servicios y entornos construidos. No se trata de una obligación futura: desde el 28 de junio de 2025, las organizaciones deben cumplir con la EAA tal como se haya transpuesto a la legislación nacional de su Estado miembro, y la aplicación está activa con los reguladores vigilando.

La EAA es inusualmente explícita en su cobertura de los servicios financieros. Desde el 28 de junio de 2025, las empresas dentro de su alcance deben garantizar que diseñan sus sitios web, aplicaciones móviles, contratos y todas las formas de comunicación con los consumidores —incluidos los servicios de centros de llamadas, así como dispositivos como terminales de pago y cajeros automáticos— de manera accesible para las personas con discapacidad. La directiva abarca los “servicios bancarios al consumidor”, incluidos los contratos de crédito, los servicios de pago y determinados servicios de inversión; sin embargo, el negocio de depósitos puro no entra en el alcance de los “servicios bancarios al consumidor” en virtud de esta Ley: solo las cuentas de pago y el dinero electrónico están cubiertos.

La EAA exige que los “operadores económicos” de productos y servicios dentro de su alcance proporcionen determinada información de forma accesible mediante el principio de los dos sentidos, haciendo que los sitios web y las aplicaciones móviles sean accesibles al hacerlos perceptibles, operables, comprensibles y robustos. “Operadores económicos” incluye a los proveedores de servicios financieros, incluidos bancos, proveedores de servicios de pago y proveedores de dinero electrónico. La norma técnica que sustenta la EAA es la EN 301 549, que hace referencia a requisitos de accesibilidad armonizados a través de la EN 301 549, la norma europea para la accesibilidad TIC que incorpora los criterios de WCAG 2.1 Nivel AA para contenido y documentos digitales.

Las sanciones por incumplimiento son graves y varían según el Estado miembro. El incumplimiento puede dar lugar a sanciones de hasta €100,000 o el 4% de los ingresos anuales, lo que convierte el cumplimiento de la EAA en una prioridad crítica para cualquier empresa que atienda a clientes de la UE. Cabe destacar que la EAA tiene alcance extraterritorial: si su empresa presta servicios a clientes de la UE, es posible que deba cumplirla independientemente de dónde tenga su sede, creando obligaciones de cumplimiento dual junto con la ADA para las empresas estadounidenses.

Buenas noticias para los equipos de cumplimiento: Tanto la ADA como la EAA convergen en la misma base técnica. Ambas leyes comparten WCAG 2.1 Nivel AA como base técnica, lo que significa que un programa único de WCAG 2.1 AA bien ejecutado aborda simultáneamente los requisitos básicos de ambos marcos.

WCAG en banca: lo que realmente exige la norma

Se espera que los sitios web y las aplicaciones móviles de los bancos se alineen con las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.1 Nivel AA, y los tribunales estadounidenses suelen hacer referencia a WCAG al evaluar el cumplimiento de la ADA en la banca digital. WCAG se organiza en torno a cuatro principios fundamentales: Perceptible (las personas usuarias deben poder percibir la información, por ejemplo, compatibilidad con lectores de pantalla y texto alternativo), Operable (la navegación y los elementos de la interfaz deben poder utilizarse mediante teclado y dispositivos de asistencia), Comprensible (el contenido y las interacciones deben ser previsibles y fáciles de entender) y Robusto (los sitios web deben funcionar con las tecnologías de asistencia actuales y futuras).

La versión más reciente, WCAG 2.2, introduce criterios de especial relevancia para la banca. WCAG 2.2 introdujo Autenticación Accesible (Mínima), que tiene como objetivo facilitar el inicio de sesión a las personas con discapacidades cognitivas evitando pruebas que dependan en exceso de la memoria, la transcripción o la resolución de rompecabezas; esto es importante en las aplicaciones bancarias porque muchos equipos siguen añadiendo fricción en nombre de la seguridad. Botones diminutos, enlaces muy juntos y elementos de menú estrechos dificultan el uso de la aplicación para las personas con destreza limitada, y WCAG 2.2 añadió Tamaño del Objetivo (Mínimo) en el Nivel AA, que exige que los objetivos de puntero tengan al menos 24 por 24 píxeles CSS, salvo que se aplique una excepción.

Las plataformas bancarias se enfrentan a desafíos únicos de WCAG debido a sus interfaces inherentemente complejas. A pesar de los requisitos legales, las personas con discapacidad suelen encontrar barreras significativas al acceder a los servicios bancarios. Problemas como la incompatibilidad con lectores de pantalla, formularios inaccesibles y un manejo deficiente de errores pueden hacer que toda la experiencia de banca en línea sea frustrante e inutilizable. Estos desafíos suelen aparecer después de la etapa inicial de inicio de sesión, ya que muchos bancos se han centrado en mejorar la accesibilidad de sus sitios web públicos mientras que la experiencia posterior al inicio de sesión suele descuidarse.

El principio se aplica de extremo a extremo. Un servicio bancario solo es tan accesible como su eslabón más débil. Si un solo paso falla, todo el proceso falla, independientemente de lo bien que estén implementadas las demás partes. Para los bancos, esto tiene implicaciones legales: un servicio solo se considera accesible si puede utilizarse en su totalidad, de principio a fin.

Los fallos de accesibilidad más comunes en las plataformas financieras

Saber dónde fallan sistemáticamente los bancos es tan importante como saber qué exigen las normas. De los primeros un millón de páginas de inicio en internet, el 95 por ciento tiene barreras de accesibilidad que interfieren con la capacidad de las personas con discapacidad para utilizarlas, según un informe de 2025 de WebAIM. En los servicios financieros específicamente, ciertos patrones de fallo aparecen con una regularidad preocupante.

Estas son las categorías de fallos más críticas para las plataformas bancarias y financieras:

• Flujos de inicio de sesión y autenticación inaccesibles. Muchos equipos siguen añadiendo fricción en nombre de la seguridad, como obligar a las personas usuarias a copiar códigos de un solo uso entre aplicaciones sin soporte de autocompletado, exigir recordar caracteres complejos de contraseñas parciales o utilizar desafíos de imagen o rompecabezas sin opciones accesibles. La seguridad y la accesibilidad no son mutuamente excluyentes: el soporte para gestores de contraseñas y las alternativas de CAPTCHA de audio satisfacen ambos requisitos.
• Botones e iconos sin etiqueta. Un fallo importante es la ausencia o debilidad de las etiquetas: los botones que solo muestran un icono pueden volverse carentes de significado para un lector de pantalla si no están etiquetados correctamente. Un botón de transferencia que se representa solo como una flecha visual se anuncia a una persona usuaria de lector de pantalla simplemente como “botón”, sin proporcionar contexto alguno.
• Tablas de transacciones y paneles de control inaccesibles. Los servicios bancarios y financieros se enfrentan a desafíos derivados de aplicaciones complejas, interfaces de gestión de cuentas y requisitos de seguridad, con un patrón común de tablas complejas sin encabezados adecuados, datos de cuentas mal estructurados y widgets de panel de control inaccesibles.
• Caducidad de sesión sin advertencia adecuada. Los bancos suelen limitar el tiempo que una persona visitante pasa en una página web por motivos de seguridad. Al interactuar con páginas web que tienen límites de tiempo, las personas visitantes deben poder desactivar o, al menos, ampliar el límite de tiempo. No proporcionar esto es una violación directa de WCAG 2.1 (SC 2.2.1).
• Documentos PDF inaccesibles. Las personas con discapacidades motoras tienen dificultades para navegar por sitios web que carecen de un diseño compatible con el teclado, y documentos financieros importantes como estados de cuenta mensuales, informes y cartas en formato PDF a menudo no están diseñados para lectores de pantalla, lo que dificulta el acceso a ellos para las personas con discapacidad visual.
• Pobre contraste de color. Si el texto gris se encuentra sobre un fondo pálido, las personas usuarias pueden pasar por alto un estado de pago o un aviso de comisión, y si los estados deshabilitado y activo se ven casi iguales, es posible que las personas no sepan qué acción está disponible.
• Firmas electrónicas inaccesibles. Los documentos en línea utilizados y presentados por los bancos a veces requieren una firma electrónica. Deben hacerse adaptaciones para que las personas con discapacidad puedan firmar estos documentos, por ejemplo, ofreciendo métodos de firma alternativos como un sello de firma o software de reconocimiento de voz.

Construir una plataforma bancaria accesible: un ejemplo práctico de código

Las interfaces financieras accesibles requieren cuidado a nivel de código. Un formulario de inicio de sesión suele ser lo primero que encuentra una persona usuaria con discapacidad y marca el tono de toda la experiencia. A continuación se muestra un ejemplo de un formulario de inicio de sesión bancario correctamente estructurado y accesible que utiliza HTML semántico, atributos ARIA y permite el autocompletado de gestores de contraseñas:

<!-- Accessible bank login form -->
<form id='login-form' novalidate aria-labelledby='login-heading'>
  <h1 id='login-heading'>Sign In to Your Account</h1>

  <div class='form-group'>
    <label for='username'>Username or Account Number</label>
    <input
      type='text'
      id='username'
      name='username'
      autocomplete='username'
      aria-required='true'
      aria-describedby='username-hint'
    >
    <span id='username-hint' class='hint-text'>
      Enter the username you created at registration
    </span>
  </div>

  <div class='form-group'>
    <label for='password'>Password</label>
    <!-- Do NOT block paste — password managers must work -->
    <input
      type='password'
      id='password'
      name='password'
      autocomplete='current-password'
      aria-required='true'
    >
  </div>

  <!-- Accessible error region -->
  <div
    role='alert'
    aria-live='assertive'
    id='login-error'
    class='error-region'
    hidden
  >
    <!-- Errors injected here are announced immediately -->
  </div>

  <!-- Accessible CAPTCHA: audio option required -->
  <div class='captcha-wrapper'>
    <!-- Use accessible reCAPTCHA or SMS/email OTP instead of visual-only CAPTCHA -->
  </div>

  <button type='submit'>Sign In</button>

  <p>
    <a href='/forgot-password'>Forgot password?</a>
    <a href='/forgot-username'>Forgot username?</a>
  </p>
</form>

Patrones clave demostrados arriba: cada campo de entrada tiene una etiqueta explícita <label> vinculada mediante for/id; los atributos de autocomplete están configurados para que los gestores de contraseñas y la tecnología de asistencia puedan rellenar previamente los campos; nunca se bloquea pegar; los mensajes de error utilizan role='alert' para que los lectores de pantalla los anuncien de inmediato; y el CAPTCHA tiene una alternativa accesible. Estos patrones se aplican por igual a los formularios de solicitud de préstamos, pantallas de transferencia de fondos y páginas de configuración de cuentas.

El problema de los proveedores terceros

Uno de los temas más espinosos en el cumplimiento de la accesibilidad bancaria es la responsabilidad de los proveedores. Muchos bancos utilizan portales de banca en línea creados y gestionados por proveedores terceros. Cuando esos portales son inaccesibles, el banco —no el proveedor— es la entidad que recibe la demanda. Los tribunales han sostenido de forma constante que externalizar una función no externaliza la responsabilidad legal.

La EAA es explícita en este punto. Las empresas financieras pueden estar directamente dentro del alcance de la EAA, pero sus proveedores y suministradores posteriores de servicios y productos dentro del alcance también pueden tener obligaciones en virtud de la EAA, o verán cómo sus clientes de servicios financieros trasladan obligaciones hacia ellos a través de los contratos. Esto significa que los equipos de compras deben convertir la accesibilidad en un criterio de evaluación de proveedores, no en una idea tardía. Cada servicio de terceros —pasarelas de pago, software de originación de préstamos, módulos de autenticación de clientes, chatbots, motores de generación de PDF— debe cumplir la misma norma WCAG que el código propio.

El principio de recorrido integrado es especialmente relevante aquí. Una transacción típica consta de varios pasos consecutivos: inicio de sesión, autenticación, la transacción en sí y la documentación. Estos pasos están interconectados y a menudo son gestionados por distintos sistemas subyacentes. El factor crítico no es si los componentes individuales son accesibles, sino si todo el flujo de trabajo funciona. La EAA sigue exactamente este enfoque: el recorrido de la persona usuaria se evalúa en su conjunto, en lugar de sus partes individuales.

Estrategia de cumplimiento: pasar de lo reactivo a lo proactivo

Muchas instituciones financieras siguen tratando la accesibilidad como un problema legal reactivo: corregir las cosas solo después de recibir una carta de requerimiento. Ese enfoque es cada vez menos sostenible. Se ha estimado que entre 7 y 10 cartas de requerimiento privadas se presentan por cada demanda presentada en los tribunales. Estas cartas suelen advertir que se emprenderán acciones legales a menos que el destinatario haga accesibles sus recursos digitales. Para cuando llega una queja formal, la institución ya ha sido identificada como objetivo.

Un programa proactivo de accesibilidad en servicios financieros debe incluir los siguientes elementos:

1. Auditoría de referencia en todas las propiedades digitales. Encargue una auditoría combinada automática y manual de su sitio web público, portal bancario autenticado, aplicaciones móviles y PDF críticos. Las herramientas automatizadas detectan alrededor del 30–40% de los problemas de WCAG, por lo que las pruebas manuales con personas usuarias reales de tecnología de asistencia son esenciales para descubrir el resto.
2. Priorizar primero los flujos de transacción principales. Comience con las funciones bancarias principales —acceso a cuentas, transacciones y estados de cuenta— y luego amplíe a servicios adicionales. Corregir el formulario de inicio de sesión, la tabla de historial de transacciones y la pantalla de transferencia de fondos ofrece el mayor impacto para las personas usuarias con las necesidades más críticas.
3. Integrar la accesibilidad en su SDLC. Los problemas de accesibilidad son un orden de magnitud más baratos de corregir durante el diseño y el desarrollo que después del despliegue. Incluya criterios de aceptación de accesibilidad en cada historia de usuario e integre el escaneo automatizado en su canalización CI/CD para detectar regresiones antes de que lleguen a producción.
4. Evaluar y contratar proveedores en función de la accesibilidad. Exija documentación VPAT (Voluntary Product Accessibility Template) a todos los proveedores de tecnología. Si trabaja con el Gobierno Federal o con cualquier organización que reciba fondos gubernamentales, necesitará obtener un VPAT para todas sus propiedades digitales, ya sea su sitio web, aplicación móvil o portal de clientes.
5. Formar a los equipos de contenido y cumplimiento. Los PDF inaccesibles, el texto alternativo mal redactado y los campos de formulario sin etiqueta suelen ser creados por personal no técnico. La formación periódica garantiza que la accesibilidad no retroceda a través de actualizaciones de contenido ordinarias.
6. Mantener un monitoreo continuo. El monitoreo continuo detecta problemas antes de que afecten a los clientes o desencadenen quejas. Despliegue escaneos automatizados con una cadencia regular y configure alertas cuando las páginas recién desplegadas introduzcan regresiones de accesibilidad.
7. Publicar una declaración de accesibilidad. Documente su nivel de conformidad, las limitaciones conocidas y un canal claro de comentarios para las personas usuarias que encuentren barreras. Esto demuestra buena fe y es un requisito explícito de la EAA.

El caso empresarial más allá del cumplimiento

Los requisitos de cumplimiento son convincentes por sí solos, pero el caso empresarial para la banca accesible va más allá. El 65% de las personas usuarias cambiaría de proveedor financiero por mejores funciones de accesibilidad, pero solo el 48% está satisfecha con las funciones de accesibilidad de su banca digital actual, lo que presenta tanto un desafío como una oportunidad para que las instituciones financieras mejoren sus servicios.

Según los Centros para el Control y la Prevención de Enfermedades de EE. UU., el 28.7% de los adultos —más de uno de cada cuatro— en Estados Unidos tiene algún tipo de discapacidad, lo que se traduce en aproximadamente 70 millones de adultos. Cuando los activos digitales son inaccesibles, más de una cuarta parte de los consumidores estadounidenses que podrían ser clientes potenciales quedan excluidos del acceso a los bienes y servicios de una empresa. Si se suman los familiares y cuidadores que toman decisiones financieras por las personas con discapacidad, el impacto en el mercado total accesible es enorme.

El diseño accesible también mejora de forma sistemática la usabilidad para todas las personas. Etiquetas claras en los formularios, contraste de color adecuado y navegación lógica mediante teclado no son solo adaptaciones para la discapacidad: son simplemente buen diseño de interfaz. El diseño inclusivo ayuda a que los servicios cotidianos sean más fáciles de usar para las personas con discapacidad, y esto es particularmente importante para los sitios web financieros, donde las personas usuarias necesitan acceder a información sensible y completar transacciones de forma segura e independiente. Una base de clientes envejecida, personas usuarias en dispositivos móviles bajo luz solar intensa y cualquiera que utilice un teléfono con una sola mano se benefician de las mismas decisiones de diseño que sirven a las personas con discapacidades permanentes.

El riesgo reputacional funciona en ambos sentidos. Un banco que es demandado por incumplimiento de la ADA puede sufrir un daño reputacional significativo, especialmente si la demanda atrae la atención de los medios. Por el contrario, las instituciones que lideran en accesibilidad generan confianza y lealtad medibles entre los clientes que históricamente han sido desatendidos por los servicios financieros.

Conclusiones clave

• La presión legal es real y se acelera. Las demandas federales por accesibilidad web bajo la ADA alcanzaron 3,117 en 2025 —un aumento del 27%— mientras que la Ley Europea de Accesibilidad pasó a ser aplicable en junio de 2025 con sanciones de hasta €100,000 o el 4% de los ingresos anuales. Las instituciones financieras están en el punto de mira de ambos marcos.
• WCAG 2.1 Nivel AA es la norma mínima de facto en todas partes. Los tribunales estadounidenses la citan en acuerdos, el Departamento de Justicia la exige para las entidades del Título II y la columna vertebral técnica de la EAA (EN 301 549) la incorpora directamente. Apuntar a WCAG 2.2 le prepara para el futuro cercano mientras satisface los requisitos actuales.
• Todo el recorrido de la persona usuaria debe ser accesible, no solo la página de inicio. Los portales bancarios posteriores al inicio de sesión, los flujos de transacciones, los estados de cuenta, los documentos PDF y los módulos de pago de terceros conllevan la misma exposición legal. Un servicio solo es conforme si el flujo de trabajo de extremo a extremo es utilizable por personas con discapacidad.
• Los contratos con proveedores deben incluir obligaciones de accesibilidad. La responsabilidad legal permanece en el banco cuando un portal de terceros incumple WCAG. Traslade los requisitos de la EAA y la ADA a todos los proveedores de tecnología y exija documentación VPAT antes del despliegue.
• La remediación proactiva es materialmente más barata que la defensa reactiva. Las cartas de requerimiento, los acuerdos, los honorarios legales, los acuerdos de monitoreo ordenados por los tribunales y los costos de rediseño superan de forma constante el costo de construir productos accesibles desde el principio. Integre la accesibilidad en sus procesos de SDLC y adquisiciones ahora.