Formulário de contato

What are you most proud of, and what would you do differently next time?

Do que você mais se orgulha: Tenho muito orgulho de ter desenvolvido um formulário completamente acessível e alinhado às diretrizes do WCAG. Foquei em estruturar o HTML de forma semântica (usando tags adequadas como <fieldset> e <legend>), além de gerenciar atributos ARIA dinamicamente (aria-invalid e aria-describedby) para que os leitores de tela comuniquem os erros de validação em tempo real. Também fiquei satisfeito em criar todo o layout e a lógica em CSS e JavaScript Vanilla, sem depender de nenhuma biblioteca externa.

O que faria diferente da próxima vez: Na próxima vez, adotaria uma abordagem estritamente Mobile-First no CSS para deixar as media queries mais simples e o código mais enxuto. Além disso, no JavaScript, estruturaria a lógica de validação utilizando delegação de eventos (event delegation) em vez de checar os campos individualmente no evento de envio, facilitando a expansão do código caso novos campos sejam adicionados no futuro.

What challenges did you encounter, and how did you overcome them?

Aqui está a resposta para a segunda pergunta da Solution Retrospective em Português (Brasil): What challenges did you encounter, and how did you overcome them?

Desafios encontrados e como foram superados:

Acessibilidade Dinâmica de Erros (ARIA):

    Desafio: Garantir que as mensagens de erro fossem lidas corretamente por leitores de tela no momento do envio, sem gerar alertas falsos enquanto o usuário ainda estava preenchendo o formulário.

    Como superei: Utilizei o atributo aria-live="polite" nos contêineres de erro e passei a vincular o input à sua respectiva mensagem apenas quando o erro ocorria, usando o atributo aria-describedby via JavaScript.

Estilização Personalizada de Inputs Nativos (Radio e Checkbox):

    Desafio: Manter a aparência visual dos botões de rádio e do checkbox alinhada ao design sem comprometer a acessibilidade e o foco nativo do teclado.

    Como superei: Empreguei o pseudo-seletor :has() no CSS para aplicar o estilo visual de "selecionado" no contêiner pai (.radio-option:has(input:checked)) e utilizei accent-color para estilizar o indicador nativo mantendo o contraste exigido pelas diretrizes da WCAG.

Validação do Grupo de Radio Buttons:

    Desafio: Validar se pelo menos uma opção do grupo de rádio foi selecionada, já que esses inputs compartilham o mesmo nome, mas pertencem a elementos do DOM diferentes.

    Como superei: Usei document.querySelector('input[name="queryType"]:checked') no JavaScript para verificar globalmente se havia algum item marcado antes de liberar a submissão, exibindo o aviso no <legend> do <fieldset>.

What specific areas of your project would you like help with?

Gestão de Estado e Foco em Telas de Erro (Acessibilidade de Foco):

Gostaria de saber se a melhor prática para o foco de teclado, ao submeter o formulário com erros, é mover automaticamente o foco (.focus()) para o primeiro campo inválido ou para a mensagem de erro associada. Qual abordagem oferece a melhor experiência para usuários de leitores de tela?

Compatibilidade do Pseudo-seletor :has() no CSS:

Utilizei a regra .radio-option:has(input:checked) no CSS para estilizar o contêiner do botão de rádio quando selecionado. Gostaria de saber se o suporte atual dos navegadores para :has() já é amplo o suficiente para projetos em produção ou se seria mais seguro contornar isso manipulando classes de estado (ex: .is-selected) via JavaScript.

Arquitetura e Escalabilidade da Validação JS:

Receber feedback sobre a estrutura da função validateForm(). O código atual limpa e adiciona erros iterando sobre os campos de forma direta. Existe um padrão de projeto (Design Pattern) mais limpo ou modular em Vanilla JS para gerenciar regras de validação sem poluir a função principal de submit?