Uma proposta interativa pode mostrar o preço certo e, ao mesmo tempo, manter o prazo da opção anterior. É fácil não perceber isso quando cada botão é conferido separadamente.
Ao organizar um exemplo pequeno em HTML e JavaScript, o critério foi fazer preço, prazo e entregáveis saírem da mesma combinação de dados. São dois pacotes e duas revisões, com valores fictícios.
Primeiro, saber de onde vem cada resposta
O estado guarda as escolhas, não o resultado:
let revision = "first";
let plan = "essential";
Uma tabela contém as quatro combinações. Este recorte usa números em USD apenas para ilustrar o modelo, sem conversão para reais:
const proposals = {
first: {
essential: { price: 4800, weeks: 3 },
complete: { price: 7200, weeks: 4 }
},
revised: {
essential: { price: 5400, weeks: 4 },
complete: { price: 8100, weeks: 5 }
}
};
O registro atual é proposals[revision][plan]. Não existe uma variável extra para o preço, nem outra para o prazo. Assim, há menos valores que precisam ser mantidos em acordo.
O evento escolhe; a renderização atualiza
Em vez de cada botão atualizar um pedaço da página, os eventos mudam uma escolha e chamam a mesma função render().
No exemplo completo, essa função atualiza o resumo, reconstrói a lista de entregáveis e ajusta aria-pressed dos dois grupos de botões. Os textos entram com textContent, sem serem interpretados como HTML.
Isso também evita um comportamento estranho: trocar a revisão não volta o pacote para o básico. Quem está comparando o pacote completo continua nele. Só a revisão muda.
Essa escolha deixa a comparação mais fácil de acompanhar. Se um pacote não estiver disponível em uma revisão futura, a interface precisará tratar e explicar esse caso.
Conferir quatro resultados e depois percorrer o caminho
A tabela esperada é pequena:
| Revisão | Pacote | Valor fictício (USD) | Prazo |
|---|---|---|---|
| Inicial | Básico | 4800 | 3 semanas |
| Inicial | Completo | 7200 | 4 semanas |
| Revisada | Básico | 5400 | 4 semanas |
| Revisada | Completo | 8100 | 5 semanas |
Conferir essas linhas ajuda a encontrar um dado errado. Mas a interface tem memória entre os cliques: algum elemento pode ficar com o conteúdo da seleção anterior.
Por isso, vale percorrer Completo → Revisada → Básico → Inicial sem recarregar a página.
Em cada etapa, confira:
- se o preço e o prazo correspondem à mesma combinação;
- se a lista de entregáveis foi atualizada;
- se o pacote escolhido foi mantido ao trocar a revisão;
- se os dois grupos mostram o estado selecionado correto.
Não é preciso transformar esse exemplo em uma aplicação grande para conferir isso. Uma sequência curta já revela mais do que abrir cada combinação isoladamente.
O teclado também precisa entrar na conferência
Os controles usam elementos button. Tab muda o foco; Enter e Espaço ativam o botão. aria-pressed expõe a seleção.
O resumo usa aria-live="polite" e aria-atomic="true", para disponibilizar a atualização completa às tecnologias assistivas. Ainda é necessário conferir o comportamento nos leitores de tela usados pelo público; esses atributos, sozinhos, não garantem que toda a experiência esteja boa.
Prévia não é publicação
As duas revisões já estão no arquivo. O botão alterna o que aparece, sem salvar nem atualizar a página hospedada.
Por isso, “prévia da revisão” descreve melhor a ação. Para atualizar o conteúdo público, é necessário enviar o arquivo alterado e conferir o endereço que será compartilhado.
O exemplo ficou pequeno porque tem uma tarefa limitada: comparar escopo sem separar preço, prazo e entregáveis. A parte interessante é conferir se essa promessa continua verdadeira depois de vários cliques.
O artigo original em inglês traz o HTML e o JavaScript completos para reproduzir o exemplo. Aqui, o foco foi o raciocínio por trás da verificação das transições.
Vocês costumam testar os estados isolados primeiro ou já começam pelos caminhos que a pessoa pode percorrer?
Top comments (0)