Accesibilidad Transparencia

Nuestro estándar de trabajo

Utilizamos WCAG 2.1 Nivel AA como nuestro estándar de trabajo para la accesibilidad del producto. También adoptamos ideas AAA seleccionadas cuando mejoran claramente la usabilidad, pero no afirmamos conformidad AAA.

No pretendemos que cada ruta sea perfecta en todo momento. Nos comprometemos a solucionar barreras verificadas, documentar cambios y mantener el trabajo de accesibilidad en el flujo de trabajo normal de ingeniería.

Política de soporte de tecnología de asistencia

Publicamos expectativas de soporte basadas en las combinaciones que verificamos directamente y las combinaciones que revisamos durante las auditorías programadas. Esta es una matriz de soporte, no una afirmación de que cada combinación de navegador y tecnología de asistencia se comporte de manera idéntica.

Cuando los usuarios informan sobre una barrera en una combinación de mejor esfuerzo, aún así la investigamos. Si el problema afecta la semántica principal, el comportamiento del teclado o los componentes compartidos, lo tratamos como un defecto del producto incluso cuando el emparejamiento exacto no está en el conjunto verificado principal.

Política de desaprobación y cambio

• No dejamos de admitir intencionalmente una combinación de navegador verificado y tecnología de asistencia sin publicar primero el cambio en esta página.
• Cuando el soporte de una combinación verificada deja de ser práctico debido a limitaciones del proveedor, la plataforma o la seguridad, realizamos al menos un aviso de ciclo trimestral antes de que pase al estado de mejor esfuerzo.
• Cualquier aviso de obsolescencia debe incluir la combinación afectada, por qué cambió, la fecha de vigencia y la alternativa admitida más cercana.

Si una barrera reportada afecta una combinación que actualmente verificamos directamente, el problema se clasifica según esa expectativa de soporte y no se trata como opcional.

Revisión de accesibilidad de dependencia de terceros

La mayoría de las interacciones de PayCal auditadas utilizan código de interfaz de usuario propio. Cuando existe código del lado del navegador de terceros, realizamos un seguimiento de su impacto en la accesibilidad por separado para que las actualizaciones no pasen por alto las expectativas del teclado, la semántica o el CSP.

• Aprobado: permitido para su uso actual, con impacto en la accesibilidad comprendido y documentado.
• Condicional: permitido solo en un alcance limitado mientras el trabajo de revisión, reemplazo o contención permanezca abierto.
• Bloqueado: No se permite el uso de una nueva interfaz de usuario hasta que se cumplan los requisitos de accesibilidad.

Cualquier nueva dependencia del lado del navegador que agregue interfaz de usuario, manejo de enfoque, comportamiento de diálogo, medios integrados o widgets personalizados debe revisarse antes de su adopción y volver a revisarse antes de realizar actualizaciones importantes de la versión.

¿Qué está en vigor ahora?

• La navegación principal admite el uso del teclado, omitir enlaces y atajos documentados de una sola tecla para los principales destinos.
• Los atajos de una sola tecla (C, R, S, E, A, H, N, P,?) están documentados para las principales rutas de aplicaciones.
• Los atajos no se activan mientras se escriben entradas o cuando hay cuadros de diálogo abiertos.
• Las rutas de ayuda y transparencia brindan más de una forma de navegar, incluidas rutas de navegación donde agregan contexto útil.
• Las rutas auditadas utilizan puntos de referencia semánticos, encabezados claros, etiquetas directas y mensajes de estado donde la interacción necesita retroalimentación.
• Las comprobaciones de tokens de contraste y enfoque se automatizan en todo el catálogo de temas actual y se realiza un seguimiento de la matriz publicada en nuestro flujo de trabajo pendiente de accesibilidad.
• Las configuraciones incluyen una preferencia de tipografía compatible con dislexia con espaciado accesible y soporte de pila alternativa.
• Los informes de accesibilidad ahora pueden comenzar desde esta página y continuar en el flujo de contacto seguro con los detalles clave ya completados.

Preferimos HTML semántico primero y usamos ARIA, donde ayuda a exponer nombres, relaciones o cambios de estado en vivo con mayor claridad.

Teclas de acceso rápido

PayCal publica atajos de una sola tecla para los principales destinos, de modo que las rutas frecuentes sigan siendo accesibles sin necesidad de viajar con punteros repetitivos. El conjunto documentado actual cubre calendario, organizaciones, configuración, ganancias, administración, ayuda, notas, períodos de pago y ayuda con atajos de teclado.

Estos atajos son parte del contrato de accesibilidad sólo cuando son predecibles, documentados y seguros de ignorar. Los usuarios pueden seguir navegando con enlaces, botones, enlaces para saltar y puntos de referencia estándar sin depender de la memorización de accesos directos.

Seguridad de enfoque

Las reglas de seguridad de enfoque evitan que los controladores de accesos directos y la interfaz de usuario con secuencias de comandos roben el enfoque mientras alguien escribe o trabaja dentro de un modal. Los accesos directos no se activan dentro de los controles editables y las interacciones del diálogo mantienen el foco hasta que se cierra el diálogo.

Esta política reduce la navegación accidental, protege la entrada de formularios y mantiene el comportamiento del teclado consistente con la cobertura de regresión a nivel de ruta que ejecutamos en Playwright y Lightpanda.

Lo que verificamos activamente

• Los análisis WCAG a nivel de ruta se ejecutan en páginas principales, incluidos barridos de ruta estrictos en busca de infracciones y comprobaciones de contraste más estrictas.
• Las regresiones de encabezados y formularios se verifican para que la estructura de los puntos de referencia, las etiquetas y los mensajes de recuperación no se desvíen silenciosamente.
• La cobertura de reflujo y espaciado de texto verifica las rutas principales en anchos de ventana gráfica compactos para detectar fallas de espaciado y desbordamiento horizontal.
• Las pruebas de regresión de rutas de navegación y de atajos verifican las rutas de navegación, las rutas alternativas, la transferencia de comentarios, el comportamiento de seguridad de los atajos y la cobertura de la política de atajos de teclado.
• Las comprobaciones a nivel de suite combinan Playwright, PHPUnit y cobertura de matriz de navegador para que las afirmaciones de accesibilidad sigan respaldadas por pruebas.

Esto significa que nuestras declaraciones de accesibilidad pública están vinculadas a la cobertura de regresión real, no solo a la intención.

Mejoras recientes

• 2026-03-23: Se aplicaron más de 30 tokens de diseño para barras de estado, pancartas de verificación, temporizadores de cuenta regresiva y componentes de espaciado de formularios/diálogos, eliminando todo acoplamiento de color directo de los estilos compartidos y ampliando la matriz de contraste para cubrir los nuevos pares de tokens (WCAG-020).
• 2026-03-23: Se agregaron metadatos de verificación (fecha de la última verificación, fecha de la próxima revisión, alcance y limitaciones conocidas) a las cuatro subpáginas de transparencia activa: accesibilidad, métricas, impuestos y gobernanza de verificación (WCAG-021).
• 2026-03-23: Se simplificaron 31 cadenas de error y estado en los flujos de autenticación, calendario y organizaciones: se eliminó la jerga técnica (referencias sin referencias), se hicieron procesables los mensajes con campos vacíos y se estandarizaron los mensajes de error de la organización a un consistente "No se pudo X. Inténtelo de nuevo". patrón (WCAG-024).
• 2026-03-23: Estándares de accesibilidad a nivel de componentes publicados que cubren diálogos, pestañas, cuadrículas de datos y formularios con contratos de teclado/ARIA y ejemplos de hacer/no hacer; reticulado de la plantilla PR y el flujo de trabajo de regresión (WCAG-025).
• 2026-03-23: Se separaron los anuncios de error asertivos de los anuncios de progreso educados en /auth/ y /settings/ para eliminar la salida duplicada de la región en vivo (WCAG-017).
• 2026-03-23: Tabla de SLA de defectos de accesibilidad publicada con ventanas de reconocimiento, objetivos de corrección, propietarios y rutas de escalada (WCAG-019).
• 2026-03-23: Publicó una lista de verificación formal del trabajo restante y un manual de auditoría de accesibilidad trimestral con propietarios, cobertura de rutas y requisitos de evidencia.
• 2026-03-23: Se agregó una ruta de entrada de comentarios sobre accesibilidad desde esta página al formulario de contacto seguro.
• 2026-03-23: Se agregaron rutas de navegación y cobertura de regresión para múltiples rutas de navegación en rutas públicas clave.
• 2026-03-23: Se resolvieron bloqueadores de contraste estrictos en rutas públicas principales y se mantuvieron esas comprobaciones en el conjunto de rutas WCAG.
• 2026-03-23: Se agregó cobertura de preferencia de tipografía compatible con dislexia en la configuración, con comportamiento de espaciado y pila de fuentes accesible.
• 2026-03-22: Se agregó reflujo a nivel de ruta y cobertura de espaciado de texto para páginas principales en anchos de ventana gráfica compactos.
• 2026-03-20: Se agregaron accesos directos documentados al estilo de las aplicaciones con protecciones para que no se activen mientras se escribe o mientras los cuadros de diálogo están abiertos.
• 2026-04-12: Added aria-label to the read-only current email input in change-email dialogs on settings and profile pages; replaced four hardcoded English labels in the Data Portability section with i18n-backed strings.

Lo que aún estamos mejorando

• Paquete de preparación para auditoría externa: historial de problemas previo al empaquetado, registros de remediación y evidencia de políticas para que se pueda producir un paquete de auditoría completo en un día hábil (WCAG-026).

Trabajo abierto actual

• WCAG-026: Paquete de preparación para auditoría externa: historial de problemas previo al empaquetado, registros de remediación, artefactos de evidencia y documentos de políticas para que se pueda producir un paquete de evidencia de auditoría dentro de un día hábil.

Este es el elemento activo en nuestro trabajo pendiente de ejecución de WCAG. Los tokens de diseño, los metadatos de transparencia, los contratos de regiones en vivo, la gobernanza de relaciones públicas y el trabajo de copia en lenguaje sencillo se han completado y están cubiertos por conjuntos de regresión para reducir el riesgo de retroceso.

Ventanas de respuesta a defectos de accesibilidad

Cada defecto de accesibilidad verificado se presenta con una gravedad, propietario, criterio WCAG y fecha de vencimiento en el momento de la creación para que el trabajo permanezca operativo en lugar de informal.

Cómo utilizamos ARIA

No tratamos a ARIA como un reemplazo del HTML semántico. Usamos ARIA para aclarar nombres de control, relaciones, descripciones y cambios de estado cuando el HTML nativo por sí solo no es suficiente.

Eso significa que nuestro trabajo de accesibilidad es más amplio que el uso de ARIA por sí solo. El comportamiento del teclado, los títulos, el manejo del enfoque, el contraste, el reflujo y la recuperación de errores son igualmente importantes.

Estándares y directrices

Nuestro trabajo de accesibilidad se guía principalmente por las WCAG 2.1 y los estándares legales relacionados que hacen referencia a las expectativas del Nivel AA.

• WCAG 2.1 (Pautas de accesibilidad al contenido web del W3C): estándar internacional para la accesibilidad web
• Sección 508 (ley federal de EE. UU.): se alinea con WCAG 2.0 Nivel AA
• EN 301 549 (norma europea): se alinea con WCAG 2.1 Nivel AA
• AODA (Ley de Accesibilidad para Ontarianos con Discapacidades): hace referencia a las expectativas de accesibilidad alineadas con las WCAG en Canadá