Volver al Blog
Angular Development4 de noviembre de 20268 min de lectura

La Accesibilidad Ahora Tiene Plazos Legales. Lo Que los Desarrolladores Cambian de Verdad

DR

Doug Ribeiro

8 min de lectura

Cuando activé el conjunto completo de reglas de accesibilidad para templates de Angular en todos los templates de MailHive, la primera corrida reportó 140 violaciones en un producto que funcionaba y tenía tests. Es normal: las violaciones se acumulan donde nada falla al agregar una. Las registré en una línea base y las vengo reduciendo desde entonces, hasta 24 hoy. Para un número creciente de equipos, ese tipo de backlog ahora es una exposición legal además de un problema de calidad.

Escribí aparte sobre el mínimo de WCAG desde la silla de un diseñador. Este post es el lado del desarrollador: qué cubren realmente las reglas y qué cambia en tu repositorio el lunes. Soy desarrollador y no abogado, así que usa esto para saber qué preguntar, y consigue una opinión legal de verdad para tu propia empresa.

Quién Está Realmente Obligado

Los titulares lo hacen sonar como si todos los sitios web ahora fueran ilegales. Es más acotado que eso, y depende de dónde vendes y de quién eres.

  • Unión Europea: la Ley Europea de Accesibilidad (European Accessibility Act) se aplica desde el 28 de junio de 2025. Para la web cubre servicios como el comercio electrónico y la banca para consumidores. Los proveedores de servicios que son microempresas, es decir, con menos de 10 personas y no más de 2 millones de euros de volumen de negocios o de balance, están exentos. El texto gira en torno a los servicios prestados a consumidores, no a dónde está la empresa, así que si vendes estos servicios a consumidores de la UE desde fuera de la UE, asume que estás dentro del alcance.
  • Canadá: las modificaciones de 2025 sobre accesibilidad digital a las Accessible Canada Regulations (SOR/2025-255) se aplican al sector público federal y a las empresas privadas reguladas a nivel federal, como los bancos, con 100 empleados o más. Las telecomunicaciones, las emisoras y la mayoría de los proveedores de transporte quedan excluidos en su mayor parte del lado de cara al público. La fecha para las páginas web del sector público federal es el 5 de diciembre de 2027, y para las páginas web de las empresas grandes y medianas, el 5 de diciembre de 2028. La obligación de cara al público cubre las páginas creadas o actualizadas a partir de esas fechas, en la medida de lo posible. Las empresas con 99 empleados o menos no están cubiertas. Las provincias tienen sus propias leyes, como la AODA en Ontario.
  • Estados Unidos: la regla del Título II de la ADA cubre a los gobiernos estatales y locales. Una regla final provisional (interim final rule) de abril de 2026 movió los plazos a abril de 2027 para quienes atienden a 50.000 personas o más, y a abril de 2028 para los más pequeños. Las empresas privadas son un tema aparte, que se decide en gran parte mediante litigios bajo la ADA y no mediante una regla como esta.

El objetivo técnico es parecido en los tres. La regla de EE. UU. nombra WCAG 2.1 AA. El estándar de Canadá y el estándar de apoyo de la UE se basan en EN 301 549. La edición de Canadá actualmente incorpora WCAG 2.1 AA, y se referencia en su versión modificada periódicamente, así que avanza con las ediciones nuevas. Deque informa que la v4.1.1, con WCAG 2.2 AA, se publicó en septiembre de 2026. Así que construye para WCAG 2.2 AA. Cubre los criterios de 2.1, pero EN 301 549 agrega requisitos propios, así que revísalos también si esas reglas se aplican a ti.

La Mayoría de los Errores Son Aburridos, y Esa Es una Buena Noticia

El WebAIM Million de 2026 encontró fallas de WCAG detectables en el 95,9% de las páginas de inicio del millón de sitios principales, con un promedio de 56,1 errores por página. La parte útil: el 96% de todos los errores detectados cae en seis categorías.

  • Texto con bajo contraste: 83,9% de las páginas de inicio.
  • Falta de texto alternativo en imágenes: 53,1%.
  • Falta de etiquetas en campos de formulario: 51%.
  • Enlaces vacíos: 46,3%.
  • Botones vacíos: 30,6%.
  • Falta del idioma del documento: 13,5%.

Los valores por defecto de los componentes, los design tokens y las reglas de lint pueden prevenir la mayoría. Así que este es un lugar donde un pequeño esfuerzo de desarrollo mueve números reales. Y hay una cifra más que deberías conocer: las páginas con ARIA promediaron 59,1 errores, contra 42 de las páginas sin ARIA. Es una correlación, ya que las páginas complejas usan más ARIA. Recurrir primero a ARIA agrega formas de equivocarse. Usa un botón de verdad.

Paso 1: Falla Ante Violaciones Nuevas Desde Hoy

Las reglas estáticas son gratis, rápidas y detectan problemas antes de que se abra el navegador. Para Angular, angular-eslint trae una config de accesibilidad para templates. Para React, el equivalente es eslint-plugin-jsx-a11y.

javascript 
// eslint.config.js, inside tseslint.config(...), simplified
{
  files: ['**/*.html'],
  extends: [
    ...angular.configs.templateRecommended,
    ...angular.configs.templateAccessibility,
  ],
}

En una app existente, espera un número así. No lo conviertas en un proyecto de limpieza, porque ese proyecto va a perder contra la próxima feature. Registra las violaciones existentes con las bulk suppressions de ESLint, de modo que solo las nuevas hagan fallar el build. Los templates de terceros que viven en el repo y que no son tuyos también necesitan una decisión: exceptuarlos mantiene el build en verde, pero igual pueden bloquear a un usuario, así que dales seguimiento. La línea base detiene el sangrado. No arregla nada: cada entrada suprimida es un pendiente conocido que hay que reducir, no uno aceptado. Redúcela, empezando por los componentes compartidos y luego por los flujos que la gente no puede evitar, como el inicio de sesión y el checkout. Así es como MailHive pasó de 140 a 24.

Paso 2: Prueba la Página Renderizada

El lint ve templates, no el resultado. El contraste depende de los estilos computados, y el orden de los encabezados solo aparece en tiempo de ejecución. Axe encuentra ambos, aunque el orden de los encabezados es una regla de buenas prácticas, así que agrega el tag de best practices si la quieres. Se conecta a la suite end-to-end que probablemente ya tienes, y es open source y gratis.

typescript 
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('checkout has no detectable WCAG A or AA violations', async ({ page }) => {
  await page.goto('/checkout');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

Empieza por tus tres flujos más importantes, y prueba cada uno en sus estados importantes, por ejemplo con los mensajes de error visibles. Axe solo ve lo que está en pantalla cuando corre.

Paso 3: Acepta Lo Que Ninguna Herramienta Va a Detectar

El propio estudio de Deque sobre más de 2.000 auditorías encontró que el testing automatizado cubría alrededor del 57% de los problemas por volumen. Es la cifra de un proveedor, y una que le favorece, así que tómala como el extremo optimista. Aun así, algo así como cuatro de cada diez problemas necesitan a una persona. Una herramienta puede decirte que una imagen tiene texto alternativo. No puede decirte que ese texto no tiene sentido. Puede decirte que un botón tiene nombre, no que el foco fue a un lugar sensato después de hacer clic.

En una single-page app, las fallas manuales se concentran en los mismos lugares. Revísalos a mano, solo con teclado, antes de dar una feature por terminada:

  • Cambio de ruta: el foco se mueve al contenido nuevo y el título de la página cambia. En una SPA el foco no se mueve solo, y Angular solo actualiza el título si defines uno en la ruta. Un usuario de lector de pantalla puede no recibir ninguna señal de que algo pasó.
  • Diálogos: el foco entra, se queda dentro y vuelve al elemento que lo abrió al cerrar. El módulo a11y del Angular CDK y el elemento nativo dialog con showModal resuelven la mayor parte. No escribas el tuyo salvo que no cubran tu caso.
  • Errores de formulario: el error está vinculado a su input con aria-describedby y se anuncia después del submit. Un borde rojo no anuncia nada.
  • Actualizaciones dinámicas: un toast o un conteo de resultados necesita una live region. En Angular, LiveAnnouncer del CDK hace esto.
  • Widgets personalizados: cualquier div con un click handler. Llega a él con Tab, intenta operarlo con Enter y Espacio, y verifica que puedes ver dónde está el foco.

Las pruebas con lector de pantalla son la siguiente capa. NVDA es gratis en Windows y VoiceOver viene con las Mac y los iPhone. Mi post de WCAG cubre esas combinaciones, así que no las voy a repetir. Pon primero la pasada con teclado en tu definición de terminado (definition of done). Toma minutos y encuentra mucho.

No Intentes Comprar la Salida con un Overlay

Un script de una línea que promete cumplimiento es una respuesta tentadora ante un plazo legal. En abril de 2025, la Federal Trade Commission de EE. UU. finalizó una orden que obliga a accessiBe a pagar 1 millón de dólares por afirmar que su plugin podía hacer que cualquier sitio web cumpliera con WCAG. La orden prohíbe ese tipo de afirmaciones sin evidencia. Un overlay corre por encima del código que tiene el problema. Arregla el código.

Cosas Que los Desarrolladores Olvidan Que También Están Dentro del Alcance

  • PDFs y documentos. Para el sector público federal y las empresas con 500 empleados o más, las reglas de Canadá cubren los documentos descargables, así que revisa tu generador de facturas.
  • Declaraciones de accesibilidad. Canadá las exige cada año al sector público federal y a las empresas con 500 empleados o más, y la UE tiene sus propias obligaciones de información para los servicios. Averigua quién se encarga de esto en tu empresa antes de que alguien pregunte.
  • Capacitación y registros. Las reglas de Canadá exigen capacitación para las personas que trabajan en tecnologías digitales, y conservar registros durante cuatro años. No es solo tu trabajo, pero plantéalo.
  • Widgets de terceros. Tu iframe de pago, tu burbuja de chat y tu banner de consentimiento son parte de la página que tu usuario tiene que atravesar.

El Primer Sprint Que Haría

  • Día 1: activa las reglas de lint, pon las violaciones existentes en una línea base y falla ante las nuevas.
  • Día 2: arregla primero los componentes compartidos. Un componente de botón o de input arreglado corrige todos sus usos de una vez.
  • Día 3: agrega axe a tus tests end-to-end para tus tres flujos principales.
  • Día 4: haz una pasada solo con teclado por esos flujos, y registra lo que encuentres como bugs, con su severidad.
  • Día 5: agrega la pasada con teclado a tu definición de terminado, y pregunta en tu empresa cuál de estas leyes se le aplica.

El lint y axe no te hacen cumplir la normativa. Evitan que empeores. El resto requiere a una persona.

Referencias

AccessibilityWCAGAngularReactTesting

Publicaciones Relacionadas

UX/UI Design10 min de lectura

Accesibilidad WCAG: Lo Mínimo Que Todo Diseñador Necesita Saber

Una guía práctica de cumplimiento WCAG 2.2 AA cubriendo contraste de color, navegación por teclado, ARIA labels y testing con lectores de pantalla, desde establecer un design system en Strongest Families hasta entregar features que cumplen con accesibilidad en BMO.

AI & Development7 min de lectura

Deuda de Verificación: La IA Abarató Escribir Código, No Confiar en Él

Un gate de cobertura puede parecer estricto y no aplicar nada. La IA aumenta el volumen de código, así que demostrar que cada control puede fallar importa más que agregar controles nuevos.

Angular10 min de lectura

Apps bilingües en Canadá: Desafíos técnicos y de UX

Construir aplicaciones bilingües EN/FR en Canadá va mucho más allá de la traducción. Estos son los patrones técnicos y las decisiones de UX que realmente importan cuando construyes para ambos idiomas oficiales.