Construindo uma página de produto de comércio eletrônico acessível com WCAG 2.2

Uma página de detalhes do produto (PDP) parece simples até você contar a interação que ela contém: uma galeria de imagens, amostras de cores, seletores de tamanho, classificações, comentários, um guia de tamanhos, disponibilidade na loja, controles de quantidade, recomendações, acordeões, controles de compra fixos e um botão Adicionar ao carrinho. Cada um deles pode funcionar perfeitamente com um mouse enquanto bloqueia silenciosamente alguém que usa teclado, leitor de tela, entrada de voz ou ampliação. Isso faz do PDP um dos melhores lugares para tratar a acessibilidade como um requisito de engenharia, e não como uma verificação final de controle de qualidade.

WCAG 2.2 fornece o padrão – funcionalidade operável por teclado, nomes e estados determináveis ​​programaticamente, mensagens de status acessíveis, foco visível e dimensionamento de alvo adequado – mas você ainda precisa traduzi-lo em decisões de implementação. Neste artigo, examinaremos os principais componentes de uma página de produto moderna e construiremos cada um deles tendo a acessibilidade em mente.

Pontos-chave

• Alcance primeiro o HTML nativo; adicione ARIA somente quando o HTML não puder expressar a interação.
• Todo controle personalizado precisa de um nome, função e estado programático — os leitores de tela não podem inferi-los a partir do estilo.
• Comunique disponibilidade, seleção, erros e sucesso no texto, não apenas por meio de cores ou tratamento visual.
• WCAG 2.2 adiciona dois critérios que atingem duramente os PDPs: Foco não obscurecido (2.4.11) e Tamanho da meta (2.5.8).
• Crie acessibilidade em componentes reutilizáveis ​​para que cada página a herde e faça verificações automatizadas com testes reais de teclado e leitor de tela.

Comece com HTML semântico

A acessibilidade fica muito mais fácil quando a estrutura subjacente está correta, portanto, antes de usar ARIA, use HTML nativo sempre que possível. Um PDP simplificado pode começar assim:

<main>
  <nav aria-label="Breadcrumb">
    <ol>
      <li><a href="/women">Womena>li>
      <li><a href="/women/tops">Topsa>li>
      <li aria-current="page">Everyday Shirtli>
    ol>
  nav>

  <article>
    <h1>Everyday Shirth1>
    <p><span class="visually-hidden">Price:span> $78p>
    
  article>
main>

Isso fornece marcos e relacionamentos significativos à tecnologia assistiva sem uma linha de JavaScript. Um erro comum é substituir controles nativos por elementos genéricos:

<div class="add-to-cart" onclick="addToCart()">Add to Cartdiv>

Visualmente, é um botão; semanticamente ainda é um div. A versão melhor não custa nada e traz comportamento, capacidade de foco e função do teclado gratuitamente:

<button type="button" id="add-to-cart">Add to Cartbutton>

O critério Nome, Função e Valor das WCAG é mais importante quando você cria controles personalizados, porque a tecnologia assistiva precisa determinar o que é um componente, como é chamado e em que estado ele se encontra. use HTML nativo primeiro e adicione ARIA somente quando o HTML sozinho não puder expressar a interação necessária.

Galerias de imagens acessíveis

A fotografia do produto costuma ser a parte mais proeminente da página; portanto, para quem não consegue vê-la, o texto alternativo deve conter as informações do produto. Evitar alt="Product image" e descreva a visualização real:

<img src="shirt-front.jpg" alt="Everyday Shirt in navy, front view">
<img src="shirt-back.jpg" alt="Everyday Shirt in navy, back view">

WCAG 1.1.1 exige alternativas de texto para conteúdo não textual, quando apropriado.

Controles de miniatura

Se as miniaturas alteram a imagem principal, elas são controles interativos e precisam ser botões reais. Dê ao botão um nome acessível e deixe a miniatura alt vazio para que você não receba um anúncio duplicado:

<button type="button" aria-label="View back of Everyday Shirt in navy">
  <img src="shirt-back-thumb.jpg" alt="">
button>

Não faça do deslizar a única opção

As galerias móveis geralmente dependem do deslizamento horizontal. Forneça também botões Anterior e Próximo explícitos, porque as WCAG exigem que a funcionalidade seja operável pelo teclado, a menos que a ação dependa inerentemente de um caminho de movimento:

<button type="button" aria-label="Previous product image">‹button>
<button type="button" aria-label="Next product image">›button>

Se sua galeria se comporta como um carrossel, o WAI-ARIA Authoring Practices Guide recomenda controles anteriores/próximos acessíveis e, para carrosséis com rotação automática, uma maneira de interromper a rotação (e a rotação deve parar quando o foco do teclado entrar nela). Para fotografia de produto, raramente há motivo para rotação automática.

Seleção de cores acessíveis

As amostras de cores quebram com mais frequência quando são criadas como círculos clicáveis. div com uma cor de fundo não diz nada ao leitor de tela. Como as opções de cores são mutuamente exclusivas, os botões de opção nativos são a escolha natural:

<fieldset class="color-selector">
  <legend>Color: Navylegend>
  <label><input type="radio" name="color" value="navy" checked> <span>Navyspan>label>
  <label><input type="radio" name="color" value="black"> <span>Blackspan>label>
  <label><input type="radio" name="color" value="green"> <span>Greenspan>label>
fieldset>

Você pode estilizar os rótulos como amostras circulares, mantendo o comportamento nativo do rádio. Não confie apenas na cor para identificar opções — exponha o nome da cor como texto — e se a seleção de uma cor alterar as imagens, o preço ou a disponibilidade, certifique-se de que essas atualizações também sejam comunicadas.

Seletores de tamanho

Os seletores de tamanho parecem triviais, mas levantam questões reais: eles podem ser acessados ​​pelo teclado, a tecnologia assistiva sabe qual tamanho está selecionado, os usuários podem dizer quais tamanhos não estão disponíveis e um erro é anunciado quando nenhum é escolhido? As rádios nativas respondem a todas elas:

<fieldset id="size-options">
  <legend>Select sizelegend>
  <label><input type="radio" name="size" value="S"> Smalllabel>
  <label><input type="radio" name="size" value="M"> Mediumlabel>
  <label><input type="radio" name="size" value="L" disabled> Large — Sold outlabel>
fieldset>

O ponto principal: a disponibilidade não deve ser transmitida apenas por um tratamento visual, como texto cinza ou tachado.

Erros de adicionar ao carrinho

Considere o caminho de falha usual – o usuário escolhe uma cor, esquece um tamanho, clica em Adicionar ao carrinho e nada acontece, exceto uma borda vermelha. Para muitos usuários, isso não é nenhum erro. WCAG 3.3.1 exige que os erros de entrada sejam identificados e descritos em texto:

<fieldset id="size-options" aria-describedby="size-error">
  <legend>Select sizelegend>
  
fieldset>
<p id="size-error" role="alert">
  Please select a size before adding this item to your cart.
p>

Quando a validação falhar, mova o foco para o grupo inválido para que os usuários de teclado e leitor de tela possam corrigi-lo com eficiência — e não limpem suas seleções anteriores apenas porque um campo falhou.

Anunciando atualizações do carrinho

No caminho do sucesso, um pequeno brinde “Adicionado ao saco” é óbvio para usuários com visão, mas silencioso para um leitor de tela se for inserido no DOM sem semântica. Use uma região de status ativa e atualize seu texto:

<div id="cart-status" role="status" aria-live="polite">div>

const status = document.querySelector('#cart-status');

function announceCartUpdate(product, size) {
  status.textContent = `${product}, size ${size}, added to your cart.`;
}

WCAG 4.1.3 exige que as mensagens de status de qualificação sejam determináveis ​​programaticamente para que sejam anunciadas sem foco em movimento – W3C nomeia especificamente role="status" para mensagens de sucesso e resultados. Mantenha o foco no botão Adicionar ao carrinho, a menos que o fluxo de trabalho realmente precise do usuário em outro lugar.

Modais e caixas de diálogo

Guias de tamanhos, informações de entrega e disponibilidade da loja geralmente abrem em sobreposições, mas exibir algo como modal não o torna acessível. Um modal real precisa de um nome acessível, o foco movido para ele ao abrir, o foco preso enquanto aberto, um fechamento acessível pelo teclado, conteúdo de fundo inerte e o foco retornado a um local lógico ao fechar:

<div role="dialog" aria-modal="true" aria-labelledby="size-guide-title">
  <h2 id="size-guide-title">Size Guideh2>
  <table>table>
  <button type="button">Close size guidebutton>
div>

O nativo

html {
  scroll-padding-top: 5rem;
  scroll-padding-bottom: 6rem;
}

button:focus-visible,
a:focus-visible,
input:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

.product-control {
  min-width: 44px;
  min-height: 44px;
}

<h2>
  <button type="button" aria-expanded="false"
          aria-controls="product-details-panel" id="product-details-button">
    Product Details
  button>
h2>
<div id="product-details-panel"
     aria-labelledby="product-details-button" hidden>
  <p>Lightweight woven fabric with a relaxed fit.p>
div>

<a href="/product/123">
  <img src="product.jpg" alt="Everyday Jogger in black">
  <span>Everyday Joggerspan>
  <span>$118span>
a>