Category: Angular

Introducción

Angular Aria — nueva librería de accesibilidad llega para resolver lo que suele hacerse mal una y otra vez: la lógica de interacción accesible. En las primeras líneas: no es un tema de añadir atributos; es una capa de comportamiento (gestión de foco, navegación por teclado, anuncios a lectores de pantalla) que ahora Angular ofrece como primitivas headless, complementando Angular Material y el CDK.

Resumen rápido (lectores con prisa)

Qué es: Colección de patrones UI headless que implementan prácticas APG para accesibilidad.

Cuándo usarlo: Cuando necesitas control visual propio y comportamiento accesible consistente.

Por qué importa: Reduce errores de interacción al estandarizar foco, teclado y anuncios a lectores de pantalla.

Cómo encaja: Primitivas headless que exponen estado y handlers; tú aplicas estilos desde tu Design System.

Qué es Angular Aria — nueva librería de accesibilidad y por qué importa

Angular Aria es una colección de patrones de UI “headless” diseñada para implementar las prácticas recomendadas de WAI-ARIA (APG) sin imponer estilos. La idea es separar semántica y comportamiento de la capa visual: tú pones los estilos, Angular Aria se encarga de que el componente responda correctamente a teclado, foco y tecnologías asistivas.

Documentación relevante:

• WAI-ARIA Authoring Practices Guide
• Angular docs
• Ejemplos conceptuales en otros ecosistemas: React Aria, Radix UI

¿Por qué importa? Porque los errores de accesibilidad no son solo reputacionales ni legales: son errores de interacción. Un Combobox mal implementado deja fuera a usuarios con teclado o lectores de pantalla. La complejidad real no está en el atributo aria-label; está en coordinar foco, roles, aria-live, y atajos de teclado en todas las plataformas.

Diferencias claras: Angular Material vs CDK vs Angular Aria

Angular Material

Componentes completos con estilo y accesibilidad integrada. Ideal si aceptas Material Design y quieres velocidad.

Docs: Docs

Angular CDK

Utilidades de bajo nivel (Overlays, FocusMonitor, LiveAnnouncer). Es la caja de herramientas para construir componentes.

CDK a11y: CDK a11y

Angular Aria

Patrones de componentes sin estilo (Accordion, Dialog, Combobox, Menu, etc.) con semántica ARIA y gestión de interacción resuelta. Tú aplicas CSS.

Piensa en Aria como la “implementación canónica” de las APG para Angular: reduce la deuda técnica y la variabilidad entre implementaciones de distintos equipos.

Ejemplo conceptual (cómo encaja en un Design System)

No entraré a nombrar APIs finales —las convenciones pueden evolucionar—, pero un flujo habitual sería:

1. Importas la primitiva headless (p. ej. DialogBehavior).
2. Montas el markup semántico y enlazas directivas/servicios que exponen estado y handlers.
3. Aplicas estilos desde tu sistema (Tailwind, Sass, CSS Modules).

Pseudocódigo conceptual:

<app-dialog *ariaDialog>
  <div ariaDialogTrigger>Abrir diálogo</div>
  <div ariaDialogContent>
    <!-- foco gestionado, escape cierra, roles y aria-hidden se aplican automáticamente -->
  </div>
</app-dialog>

Resultado: el comportamiento accesible ya está cubierto; el equipo sólo diseña la apariencia.

Impacto en equipos y auditorías de accesibilidad

• Time to Market: menor, porque no rehaces la lógica de interacción en cada componente.
• Consistencia: menos variaciones entre módulos y menos fallos en auditorías WCAG 2.1 AA.
• Mantenibilidad: actualizaciones de patrones centralizadas en la librería oficial reducen riesgo técnico.

Si tu organización debe pasar auditorías (WCAG, EN 301 549), Angular Aria reduce la superficie de riesgo técnico al ofrecer implementaciones alineadas con APG.

Riesgos, limitaciones y puntos de decisión

• Estabilidad de API: siendo lanzamiento reciente, algunas APIs pueden cambiar. Revisa changelogs antes de adopciones masivas.
• Superposición con CDK a11y: es probable que parte del CDK siga existiendo como utilidades de bajo nivel; Aria levantará patrones completos.
• Integración visual: necesitas disciplina en el Design System para unir las primitivas headless con tokens y utilidades de estilos.

Criterio técnico para la adopción (resumen accionable)

Adopta Angular Aria si:

• Estás construyendo un Design System white‑label o con identidad visual propia.
• Tu equipo usa CSS utilitario (Tailwind) o quiere control total sobre la apariencia.
• Tienes requisitos normativos o usuarios con necesidades de accesibilidad.

No es prioritaria si:

• Estás plenamente integrado con Angular Material y aceptas su estética.
• Tu proyecto es un prototipo o MVP donde la prioridad es velocidad visual sin personalización.

Checklist de integración mínima:

• Añade pruebas de accesibilidad automatizadas (axe, Pa11y) en CI.
• Mantén lockfiles y revisa cambios en dependencias a nivel de PR.
• Planifica migración por componentes: empezar por Dialogs/Comboboxes reduce riesgo.

Conclusión

Angular Aria no es “otro paquete” más; es la pieza que permite a Angular competir en el terreno del Headless UI con garantías de accesibilidad. Para equipos que construyen componentes a medida, representa una inversión de tiempo recuperable en forma de consistencia, cumplimiento y reducción de deuda técnica. Implementa pruebas y políticas de adopción por fases, y usa Aria para que la accesibilidad deje de ser un añadido y pase a ser la base del comportamiento de tus interfaces.

FAQ

¿Qué es Angular Aria?

¿En qué se diferencia de Angular Material?

¿Tengo que dejar de usar CDK a11y?

¿Qué beneficios trae para auditorías WCAG?

¿Cuáles son los riesgos al adoptar Angular Aria ahora?

¿Dónde puedo leer las prácticas y ejemplos relacionados?

¿Qué es, en una línea? Aislar la lógica de negocio (TypeScript puro) del mundo exterior (Angular, Http, storage), usando puertos (contratos) y adaptadores (implementaciones).

Resumen rápido (lectores con prisa)

Patrón que separa dominio, aplicación e infraestructura para mantener la lógica de negocio independiente del framework. Útil cuando hay lógica cliente significativa y se busca testeo rápido. Implementación con puertos (contratos) y adaptadores (implementaciones concretas).

Hexagonal Architecture con Angular: las capas y el contrato de dependencia

Dominio (core)

Entidades y reglas. Nada de Angular, nada de RxJS. Tipo puro.

Aplicación

Casos de uso y puertos. Orquestan el dominio y definen contratos (interfaces o clases abstractas).

Infraestructura

Adaptadores concretos (HttpClient, NgRx, components). Aquí vive Angular.

Regla de oro: las capas exteriores conocen a las interiores; las interiores no conocen a las exteriores.

Referencia conceptual: Alistair Cockburn — Ports and Adapters (hexagonal)

Ejemplo mínimo y realista

Dominio puro

// domain/user.entity.ts
export class User {
  constructor(public id: string, public email: string, public role: 'admin' | 'user') {}
  isAdmin() { return this.role === 'admin'; }
}
  

Puerto (aplicación)

// application/ports/user.repository.port.ts
export abstract class UserRepositoryPort {
  abstract findById(id: string): Promise;
  abstract save(user: User): Promise;
}
  

Adaptador (infraestructura – Angular)

// infrastructure/adapters/http-user.repository.ts
@Injectable()
export class HttpUserRepository implements UserRepositoryPort {
  constructor(private http: HttpClient) {}
  findById(id: string) { return firstValueFrom(this.http.get(`/api/users/${id}`)); }
  save(user: User) { return firstValueFrom(this.http.post('/api/users', user)); }
}
  

Inyección con Angular (config)

// app.config.ts
providers: [
  { provide: UserRepositoryPort, useClass: HttpUserRepository },
  GetUserUseCase
]
  

Angular DI hace el puente. Más sobre DI en la doc oficial: Angular Dependency Injection

Testing: la ganancia real

Cuando los casos de uso son TypeScript puro, los tests son instantáneos y sin TestBed. No más correr un microclima Angular solo para comprobar una regla de negocio.

it('devuelve usuario por id', async () => {
  const mockRepo = { findById: jest.fn().mockResolvedValue(fakeUser) };
  const useCase = new GetUserUseCase(mockRepo as any);
  expect(await useCase.execute('123')).toEqual(fakeUser);
});
  

Resultado: CI más rápido, menos fragilidad y menos magia negra en los tests.

Estructura recomendada (simple y práctica)

Mantén carpetas por responsabilidad, no por tecnología:

src/
├── domain/
├── application/
│   ├── ports/
│   └── use-cases/
└── infrastructure/
    ├── adapters/
    └── ui/
  

Esto hace que mover o substituir adaptadores (pasar de Http a WebSocket, o de NgRx a Signals) sea una tarea controlada, no una reescritura.

Cuándo aplicarla (criterio técnico)

Aplica Hexagonal Architecture con Angular si:

• Tienes lógica importante en cliente (cálculos, reglas offline, validaciones complejas).
• Quieres tests rápidos y confiables.
• El producto vive años y el equipo crece.
• Necesitas desarrollar en paralelo con mocks estables.

No la apliques si

• Es un CRUD simple que solo pinta el backend.
• La prioridad es lanzar rápido con un equipo pequeño.
• El dominio todavía está cambiando cada sprint (prototipado extremo).

El patrón no te hace bueno; te sirve si resuelves un problema claro. Forzarlo es sobreingeniería.

Puntos de atención y antipatterns

• No conviertas cada función en una interfaz por paranoia. Aplica abstracción donde hay cambio probable.
• Evita traer RxJS al dominio para “beneficiarte” del stream — eso es acoplamiento. Usa adaptadores para transformar observables a promesas o tipos puros.
• No escondas lógica en componentes; los componentes deben orquestar, no contener reglas.

Cierre con acción

Si quieres, en el próximo artículo preparo:

• Un scaffold de proyecto Angular con carpeta hexagonal lista.
• Un checklist de decisiones (qué abstraer, cuándo usar InjectionToken vs clase abstracta).

Apúntate al newsletter de Dominicode para recibirlo y el starter con ejemplos de tests en Jest.

Esto no termina aquí. Si tu código se está volviendo difícil de probar o de migrar, la arquitectura es la palanca—y saber cuándo usarla es criterio.

FAQ