Claude escreveu um React DatePicker, mas alcançar acessibilidade WCAG levou mais 3 dias

A equipe de desenvolvimento pediu ao Claude para criar um DatePicker React customizado para um formulário de marcação de consultas médicas—com suporte completo para navegação por teclado e leitores de tela. A IA lidou rapidamente com a primeira versão. Depois vieram três dias de refinamento.

O Que Claude Fez Bem

Claude gerou uma base funcional para o componente: estrutura JSX, atributos ARIA básicos (`role="dialog"`, `aria-label`, `aria-live`), manipuladores de teclado para navegação por setas e lógica de grade de calendário. Como ponto de partida—sólido: o código compilava, parecia visualmente correto, e testes manuais não quebraram nada. A IA provou ser especialmente útil para código boilerplate: gerar 42 células de grade, calcular o deslocamento do primeiro dia do mês, formatar datas para `aria-label`. Este é um trabalho tedioso de fazer manualmente, e Claude o manipulou com limpeza. O problema só se tornou óbvio depois de conectar as tecnologias assistivas reais.

Onde Tudo Deu Errado

O teste real começou quando NVDA no Windows e VoiceOver no macOS foram acionados. Havia vários problemas:

• Armadilha de foco não funcionava — ao fazer tabulação dentro do diálogo, o foco voltava ao documento principal
• Datas eram lidas incorretamente — o leitor de tela dizia "1" em vez de "Segunda-feira, 1º de junho de 2026"
• Alternância de mês era silenciosa — a região `aria-live` não se atualizava quando o mês mudava
• Escape fechava mas não retornava — após fechar o calendário, o foco era perdido em vez de retornar ao botão gatilho
• Contraste alto do Windows — a data selecionada não se distinguia visualmente do resto: o componente dependia de cor CSS sem atributos de estado

Cada um desses pontos no código gerado parecia "manipulador presente"—mas o comportamento com um leitor de tela real diferiu das expectativas.

Como Corrigimos

A salvação foi WAI-ARIA APG—guia oficial da W3C com um padrão específico para diálogos DatePicker. Não diz apenas "adicione `aria-modal`," mas prescreve a sequência exata: qual elemento recebe foco ao abrir, como manter a armadilha de foco, para onde retorná-lo ao fechar, que `aria-label` é necessário nos botões de navegação de mês.

"Ler código gerado não significa verificar acessibilidade.

Apenas um leitor de tela real revela a verdade."

A armadilha de foco foi reescrita usando `querySelectorAll` com interrupção manual de Tab e Shift+Tab. Cada célula de dia recebeu um `aria-label` completo como "Quarta-feira, 3 de junho de 2026" além de `aria-pressed="true"` para o estado selecionado. Para modo de alto contraste, adicionamos `aria-selected` e contorno via `outline` em vez de apenas cor de fundo. A parte mais sutil foi `aria-live`: a região deve existir no DOM antes de o texto ser escrito nela, caso contrário o leitor de tela a ignora. Claude inseriu a região dinamicamente—essa nuance só surgiu no teste.

O Que Isso Significa

Claude acelera a escrita de código acessível mas não substitui testes com leitor de tela. A boa notícia: uma vez que você trabalhou através de WAI-ARIA APG uma vez e documentou as soluções, o próximo componente acessível é escrito notavelmente mais rápido. A IA assume o trabalho boilerplate—mas pular verificação final com NVDA e VoiceOver não é uma opção.