Transparência de acessibilidade

Nosso padrão de trabalho

Usamos WCAG 2.1 Nível AA como nosso padrão de trabalho para acessibilidade de produtos. Também adotamos ideias AAA selecionadas quando elas melhoram claramente a usabilidade, mas não reivindicamos conformidade com AAA.

Não afirmamos que todas as rotas sejam perfeitas em todos os momentos. Comprometemo-nos a corrigir barreiras verificadas, documentar alterações e manter o trabalho de acessibilidade no fluxo de trabalho normal de engenharia.

Política de suporte de tecnologia assistiva

Publicamos expectativas de suporte com base nas combinações que verificamos diretamente e nas combinações que revisamos durante as auditorias programadas. Esta é uma matriz de suporte, não uma afirmação de que cada par de navegador e tecnologia assistiva se comporta de forma idêntica.

Quando os usuários relatam uma barreira em uma combinação de melhor esforço, ainda assim investigamos. Se o problema afetar a semântica central, o comportamento do teclado ou os componentes compartilhados, trataremos isso como um defeito do produto, mesmo quando o emparelhamento exato não estiver no conjunto primário verificado.

Política de depreciação e mudança

• Não abandonamos intencionalmente o suporte para uma combinação verificada de navegador e tecnologia assistiva sem primeiro publicar a alteração nesta página.
• Quando uma combinação verificada se torna impraticável para suporte devido a restrições de fornecedor, plataforma ou segurança, visamos pelo menos um aviso de ciclo trimestral antes que ela passe para o status de melhor esforço.
• Qualquer aviso de descontinuação deve incluir a combinação afetada, o motivo da alteração, a data de vigência e a alternativa suportada mais próxima.

Se uma barreira relatada afetar uma combinação que atualmente verificamos diretamente, o problema será submetido a uma triagem em relação a essa expectativa de suporte e não será tratado como opcional.

Revisão de acessibilidade de dependências de terceiros

A maioria das interações auditadas do PayCal usa código de IU próprio. Onde existe código do lado do navegador de terceiros, rastreamos seu impacto na acessibilidade separadamente para que as atualizações não ignorem as expectativas do teclado, da semântica ou do CSP.

• Aprovado: permitido para uso atual, com impacto na acessibilidade compreendido e documentado.
• Condicional: permitido apenas em escopo limitado enquanto o trabalho de revisão, substituição ou contenção permanecer aberto.
• Bloqueado: não é permitido o uso de nova UI até que os requisitos de acessibilidade sejam atendidos.

Qualquer nova dependência do lado do navegador que adicione UI, manipulação de foco, comportamento de diálogo, mídia incorporada ou widgets personalizados deve ser revisada antes da adoção e revisada novamente antes de atualizações de versões principais.

O que está em vigor agora

• A navegação principal suporta o uso do teclado, pular links e atalhos documentados de tecla única para os principais destinos.
• Atalhos de tecla única (C, R, S, E, A, H, N, P,?) estão documentados para as principais rotas do aplicativo.
• Os atalhos não são acionados durante a digitação ou quando as caixas de diálogo estão abertas.
• As rotas de ajuda e transparência fornecem mais de uma maneira de navegar, incluindo trilhas de navegação, onde isso adiciona um contexto útil.
• As rotas auditadas usam marcos semânticos, títulos claros, rótulos diretos e mensagens de status onde a interação precisa de feedback.
• As verificações de token de contraste e foco são automatizadas em todo o catálogo de temas atual, e a matriz publicada é rastreada em nosso fluxo de trabalho de pendências de acessibilidade.
• As configurações incluem uma preferência de tipografia compatível com dislexia, com espaçamento acessível e suporte para pilha substituta.
• Os relatórios de acessibilidade agora podem começar nesta página e continuar no fluxo de contato seguro com os principais detalhes preenchidos previamente.

Preferimos primeiro HTML semântico e usamos ARIA onde ajuda a expor nomes, relacionamentos ou mudanças de status ao vivo com mais clareza.

Teclas de acesso rápido

PayCal publica atalhos de tecla única para os principais destinos, para que rotas frequentes permaneçam acessíveis sem deslocamentos repetitivos do ponteiro. O conjunto documentado atual cobre calendário, organizações, configurações, ganhos, administração, ajuda, notas, períodos de pagamento e ajuda com atalhos de teclado.

Esses atalhos fazem parte do contrato de acessibilidade apenas quando são previsíveis, documentados e seguros para serem ignorados. Os usuários podem continuar navegando com links, botões, links para pular e pontos de referência padrão sem depender da memorização de atalhos.

Segurança do foco

As regras de segurança de foco evitam que manipuladores de atalhos e UI com script roubem o foco enquanto alguém está digitando ou trabalhando dentro de um modal. Os atalhos não são acionados dentro de controles editáveis ​​e as interações de diálogo mantêm o foco no escopo até que a caixa de diálogo seja fechada.

Esta política reduz a navegação acidental, protege a entrada de formulários e mantém o comportamento do teclado consistente com a cobertura de regressão em nível de rota que executamos no Playwright e no Lightpanda.

O que verificamos ativamente

• As varreduras WCAG em nível de rota são executadas nas páginas principais, incluindo varreduras de rota rigorosas em busca de violações e verificações de contraste mais rigorosas.
• As regressões de cabeçalho e formulário são verificadas para que a estrutura de pontos de referência, os rótulos e as mensagens de recuperação não se desloquem silenciosamente.
• A cobertura de refluxo e espaçamento de texto verifica as rotas principais em larguras de janela de visualização compactas para capturar estouro horizontal e falhas de espaçamento.
• Os testes de regressão de caminhos de navegação e atalhos verificam trilhas de navegação, caminhos alternativos, transferência de feedback, comportamento de segurança de atalhos e cobertura da política de atalhos de teclado.
• As verificações em nível de suíte combinam Playwright, PHPUnit e cobertura de matriz de navegador para que as reivindicações de acessibilidade permaneçam apoiadas em testes.

Isso significa que nossas declarações públicas de acessibilidade estão vinculadas à cobertura real da regressão, não apenas à intenção.

Melhorias recentes

• 23/03/2026: foram aplicados mais de 30 tokens de design para barras de status, banners de verificação, cronômetros de contagem regressiva e componentes de espaçamento de formulário/caixa de diálogo, removendo todo acoplamento direto de cores de estilos compartilhados e estendendo a matriz de contraste para cobrir os novos pares de tokens (WCAG-020).
• 23/03/2026: adicionados metadados de verificação (data da última verificação, data da próxima revisão, escopo e limitações conhecidas) a todas as quatro subpáginas de transparência ativa: acessibilidade, métricas, impostos e governança de verificação (WCAG-021).
• 23/03/2026: 31 strings de erro e status simplificadas em fluxos de autenticação, calendário e organizações: jargão técnico removido (referências nonce), mensagens de campo vazio tornadas acionáveis ​​e mensagens de erro de organização padronizadas para um consistente "Não foi possível X. Tente novamente." padrão (WCAG-024).
• 23/03/2026: Padrões de acessibilidade em nível de componente publicados cobrindo caixas de diálogo, guias, grades de dados e formulários com contratos de teclado/ARIA e exemplos de fazer/não fazer; interligado a partir do modelo PR e do fluxo de trabalho de regressão (WCAG-025).
• 23/03/2026: anúncios de erro assertivos separados dos anúncios de progresso educados em /auth/ e /settings/ para remover saída duplicada da região ativa (WCAG-017).
• 23/03/2026: publicada tabela de SLA de defeitos de acessibilidade com janelas de reconhecimento, alvos de correção, proprietários e caminhos de escalonamento (WCAG-019).
• 23/03/2026: Publicou uma lista de verificação formal de trabalho restante e um manual trimestral de auditoria de acessibilidade com proprietários, cobertura de rota e requisitos de evidências.
• 23/03/2026: adicionado um caminho de entrada de feedback de acessibilidade desta página ao formulário de contato seguro.
• 23/03/2026: adicionadas trilhas de navegação e cobertura de regressão para vários caminhos de navegação nas principais rotas públicas.
• 23/03/2026: foram resolvidos bloqueadores de contraste estritos nas principais rotas públicas e mantidas essas verificações no conjunto de rotas WCAG.
• 23/03/2026: Adicionada cobertura de preferência de tipografia adequada para dislexia nas configurações, com pilha de fontes acessível e comportamento de espaçamento.
• 22/03/2026: adicionado refluxo em nível de rota e cobertura de espaçamento de texto para páginas principais em larguras de janela de visualização compactas.
• 2026-03-20: Adicionados atalhos documentados no estilo de aplicativo com proteções para que não sejam acionados durante a digitação ou enquanto as caixas de diálogo estiverem abertas.
• 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.

O que ainda estamos melhorando

• Pacote de preparação para auditoria externa: histórico de problemas pré-empacotado, registros de remediação e evidências de políticas para que um pacote de auditoria completo possa ser produzido em um dia útil (WCAG-026).

Trabalho Aberto Atual

• WCAG-026: Pacote de preparação para auditoria externa — histórico de problemas pré-empacotado, registros de remediação, artefatos de evidências e documentos de política para que um pacote de evidências de auditoria possa ser produzido em um dia útil.

Este é o item ativo em nosso backlog de execução WCAG. Tokens de design, metadados de transparência, contratos de região ativa, governança de relações públicas e trabalho de cópia em linguagem simples foram concluídos e são cobertos por pacotes de regressão para reduzir o risco de retrocesso.

Janelas de resposta a defeitos de acessibilidade

Cada defeito de acessibilidade verificado é registrado com gravidade, proprietário, critério WCAG e data de vencimento na criação para que o trabalho permaneça operacional e não informal.

Como usamos ARIA

Não tratamos o ARIA como um substituto do HTML semântico. Usamos ARIA para esclarecer nomes de controle, relacionamentos, descrições e alterações de status quando o HTML nativo por si só não é suficiente.

Isso significa que nosso trabalho de acessibilidade é mais amplo do que apenas o uso de ARIA. O comportamento do teclado, títulos, manipulação de foco, contraste, refluxo e recuperação de erros são igualmente importantes.

Padrões e Diretrizes

Nosso trabalho de acessibilidade é orientado principalmente pelas WCAG 2.1 e padrões legais relacionados que fazem referência às expectativas do Nível AA.

• WCAG 2.1 (Diretrizes de acessibilidade para conteúdo da Web do W3C) — Padrão internacional para acessibilidade na web
• Seção 508 (lei federal dos EUA) — Alinha-se com WCAG 2.0 Nível AA
• EN 301 549 (norma europeia) — Alinha-se com WCAG 2.1 Nível AA
• AODA (Lei de Acessibilidade para Ontarianos com Deficiência) — Referências às expectativas de acessibilidade alinhadas às WCAG no Canadá