# Interfaces, usabilidade e acessibilidade

Arquitetura de informação, navegação e formulários acessíveis, com a página de compra refeita.

Página: https://resumos.rgo.pt/cadeiras/lbaw/interfaces-acessiveis/

A aplicação funciona quando os dados estão certos; é usável quando as pessoas conseguem comprar sem manual. Esta página desenha a interface da Loja de Bilhetes: onde fica cada coisa, como se navega e como se garante que toda a gente, incluindo quem usa só teclado ou leitor de ecrã, conclui a compra.

## Arquitetura de informação

A **arquitetura de informação** decide que páginas existem e como se ligam. Para a loja chegam quatro níveis:

1.  **Início**: eventos em destaque e pesquisa por data.
2.  **Evento**: descrição e lista de sessões futuras com lugares livres.
3.  **Sessão**: data, preço, lugares e botão de comprar.
4.  **Compra**: formulário, confirmação e histórico.

Cada nível responde a uma pergunta do comprador: o que há, quando posso ir, quanto custa e está comprado. Se uma página não responder a uma destas perguntas, está no sítio errado. O caso de uso de comprar bilhete atravessa os níveis 2 a 4 sem desvios: evento, sessão, compra. Qualquer página extra no meio é um passo onde o comprador pode desistir.

## A página de compra refeita

A primeira versão típica mete tudo numa parede de campos: nome, email, cartão, morada de faturação e três botões parecidos. A versão refeita segue três regras.

Primeiro, **hierarquia clara**: um título com a sessão e a data, depois o resumo do pedido com preço total destacado, e só depois o formulário. O comprador confirma o que está a comprar antes de dar dados.

Segundo, **um rótulo por campo**, ligado ao campo:

```
<label for="email">Email para envio dos bilhetes</label>
<input id="email" name="email" type="email" required autocomplete="email" />
```

O `for` ligado ao `id` faz o leitor de ecrã anunciar o rótulo ao entrar no campo, e o `type="email"` com `required` repete no navegador as regras do servidor. Um campo sem rótulo visível é invisível para parte dos utilizadores, por mais bonito que seja o desenho.

Terceiro, **foco visível e ordem lógica**: a tecla Tab percorre título, resumo, campos e botão de confirmar por esta ordem, e o elemento focado mostra um contorno claro. Testa de olhos fechados no rato: desliga o rato e compra um bilhete só com o teclado. Se ficares preso numa armadilha de foco ou não souberes onde estás, o leitor de ecrã também fica.

Nome, email, cartão, morada de faturação e três botões parecidos, tudo ao mesmo nível. O comprador preenche sem saber o que está a comprar nem quanto custa, e um erro no cartão aparece no topo, longe do campo.

Título com a sessão e a data, resumo do pedido com o preço total destacado, e só depois o formulário com um rótulo por campo. O erro aparece junto ao campo, em texto, e o comprador confirma o pedido antes de dar dados.

## Verificação de contraste e teclado

Antes de declarar a página pronta, corre esta lista curta:

*   O texto normal contrasta com o fundo o suficiente para se ler ao sol. Cinzento claro sobre branco para o preço é o falhanço clássico.
*   Todas as ações funcionam por teclado: Tab para navegar, Enter para confirmar, Escape para fechar diálogos.
*   Cada erro de validação aparece junto ao campo, em texto, não só com cor vermelha. Cor sozinha não chega para quem não a distingue.
*   As imagens que informam têm texto alternativo; as decorativas têm alternativo vazio para o leitor de ecrã as saltar.

O critério do WCAG para texto normal pede um rácio de contraste de pelo menos 4,5 para 1.[1](https://resumos.rgo.pt/cadeiras/lbaw/interfaces-acessiveis/#user-content-fn-wcag) Mede com estes dois casos sobre fundo branco:

*   Preço em cinzento claro `#9CA3AF`: rácio 2,54 para 1. Chumba, e é por isso que o preço “elegante” se torna ilegível ao sol.
*   O mesmo preço em `#595959`: rácio 7,00 para 1. Passa com margem.

Escurecer o texto até o rácio passar de 4,5 é a correção mais barata da página. Para texto grande (a partir de cerca de 24 px) e elementos de interface, o mínimo desce para 3 para 1, mas nada se perde em manter o 4,5 em todo o lado.

[Vídeo: Beyond the Basics Accessible Form Validation That Works](https://www.youtube.com/watch?v=Igf560KIFSo)

A miniatura vem do YouTube. O vídeo só carrega quando clicas. [Abrir no YouTube](https://www.youtube.com/watch?v=Igf560KIFSo)

## Para saber mais

*   [Labels nos formulários](https://www.w3.org/WAI/tutorials/forms/labels/), o tutorial oficial do W3C sobre ligar rótulos a campos.
*   [Formulários acessíveis](https://web.dev/learn/accessibility/forms), o guia prático com HTML nativo.

Usabilidade testa-se com pessoas

Mostra a página a um colega sem explicar nada e pede-lhe para comprar um bilhete para sexta-feira. Observa onde hesita e o que clica por engano. Cada hesitação é um defeito da interface, não do colega. Uma sessão de dez minutos encontra mais problemas do que uma hora a olhar para o próprio desenho.

## Notas de rodapé

1.  W3C, [Understanding Success Criterion 1.4.3: Contrast (Minimum)](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html), o critério dos 4,5 para 1 para texto normal. [Voltar](https://resumos.rgo.pt/cadeiras/lbaw/interfaces-acessiveis/#user-content-fnref-wcag)