Criação de páginas web acessíveis

Uma página acessível permite que as pessoas obtenham informações e concluam tarefas com as ferramentas que usam. Essas ferramentas podem incluir teclado, leitor de tela, ampliador ou controle por voz. Uma página pode parecer pronta enquanto seu código ainda impede o uso por essas pessoas.

O que a tecnologia assistiva recebe

O navegador lê o HTML e constrói o DOM, seu modelo do documento. Dele deriva uma árvore de acessibilidade que descreve objetos significativos para tecnologias assistivas. Um controle precisa de uma função, um nome e os estados ou propriedades relevantes. Por exemplo, uma caixa de seleção pode ter a função “caixa de seleção”, o nome “Ofertas por e-mail” e o estado “marcada”.

Um leitor de tela fala o conteúdo ou o envia a uma linha braille. NVDA e JAWS funcionam no Windows; Narrator é integrado ao Windows, VoiceOver ao macOS e iOS e TalkBack ao Android. Leitores de tela podem navegar por títulos, links e controles sem ler cada linha. Alguns também podem informar configurações de fonte ou cor. Ampliadores mostram a página visual ampliada, por isso a clareza visual também importa.

O controle por voz permite que uma pessoa diga o nome de um controle, como “clique em Pesquisar”. Dispositivos acionadores podem enviar comandos semelhantes aos de um teclado. Assim, suporte a teclado e nomes precisos ajudam vários grupos de usuários, não apenas pessoas que ouvem a fala.

Comece pelo elemento correto

Compare estas duas formas de criar um controle para salvar:

<button type="button">Save</button>
<div class="btn" onclick="save()">Save</div>

O botão já disponibiliza sua função e seu nome. Ele recebe foco com Tab e responde a Enter e Espaço. O CSS pode fazer a segunda linha parecer idêntica, mas um div não tem nenhum desses comportamentos de botão. Um leitor de tela pode acionar seu manipulador de clique no modo de leitura, mas não anuncia o elemento como botão. Uma pessoa que navega com Tab não consegue alcançá-lo.

HTML semântico significa escolher um elemento pelo significado do conteúdo ou controle. Use CSS para controlar sua aparência. Isso dá ao navegador um ponto de partida sólido e evita ter que reconstruir o comportamento nativo com script.

Conheça a meta

O W3C publica as Diretrizes de Acessibilidade para Conteúdo Web, ou WCAG. Seus critérios de sucesso são requisitos verificáveis, cada um identificado por número, nome e nível. Por exemplo, 1.4.3 Contraste (Mínimo) é de nível AA. As WCAG 2.2 tornaram-se uma Recomendação em outubro de 2023 e foram atualizadas em dezembro de 2024.

A conformidade com o nível AA exige todos os critérios dos níveis A e AA. Passar em algumas verificações AA não basta. O nível AAA acrescenta outros requisitos. As WCAG 2.2 acrescentam nove critérios à versão 2.1, seis de nível A ou AA, e removem o critério obsoleto 4.1.1 Análise sintática.

A acessibilidade também inclui texto ampliado legível, legendas descritivas para pessoas surdas e ensurdecidas, instruções claras e mensagens de erro úteis. Incorporar esses recursos à página desde o início evita ter que substituir HTML inadequado depois que o layout estiver pronto.

Uma estrutura de página útil oferece às pessoas várias maneiras de se localizar. Um título descritivo identifica a página, regiões de referência identificam suas áreas e títulos de seção revelam o esquema. Esses recursos precisam de significado real em HTML, mesmo quando o design visual já parece claro.

Identifique a página e seu idioma

Defina o idioma principal no elemento raiz, por exemplo, <html lang="en-US">. Leitores de tela o usam para escolher regras de pronúncia. Marque uma mudança dentro da página no elemento correspondente: <span lang="fr">bon appétit</span>. Isso atende a 3.1.1 Idioma da Página (A) e 3.1.2 Idioma das Partes (AA).

Dê a cada página um <title> único e descritivo. “Pedido de bolo de aniversário – Padaria Folha Verde” é mais útil em abas, favoritos e anúncios de leitores de tela do que “Padaria Folha Verde – Página 4”. Coloque o assunto específico primeiro para que as pessoas distingam rapidamente abas semelhantes.

Divida a página em regiões

Use <main> para o conteúdo principal, <nav> para navegação e <aside> para conteúdo complementar. Um <header> no nível da página fornece a região de referência de banner, e um <footer> no nível da página fornece informações de conteúdo. Elementos de cabeçalho e rodapé aninhados em regiões de seção não se tornam essas regiões de referência no nível da página.

Use um <main> visível. Se houver duas regiões de navegação, diferencie-as com nomes como <nav aria-label="Main"> e <nav aria-label="Breadcrumb">. A função já diz “navegação”, por isso o rótulo pode ser curto. Um <section> ou <form> torna-se uma região de referência apenas quando tem um nome acessível.

Crie um esquema antes de escolher tamanhos de fonte

Para a página de pedidos da padaria, um esquema claro poderia ser:

<h1>Order a birthday cake</h1>
<h2>Choose a size</h2>
<h2>Choose a flavor</h2>
<h3>Chocolate</h3>
<h3>Lemon</h3>
<h2>Pickup or delivery</h2>

Use um h1 para o assunto principal, h2 para seções principais e h3 para suas partes. Evite pular níveis ao descer na hierarquia. Escolha níveis de título pela estrutura; ajuste seu tamanho com CSS. Um parágrafo em negrito não entra na lista de títulos do leitor de tela. Por outro lado, colocar uma introdução comum em h2 acrescenta uma seção que o conteúdo não tem.

Preserve o agrupamento e a ordem de leitura

Use <ul> para itens não ordenados, <ol> para etapas ordenadas e <dl> para pares de termo e descrição. Leitores de tela podem anunciar o tamanho de uma lista, ajudando as pessoas a avaliar quanto conteúdo vem a seguir. Links de navegação podem ficar em um ul dentro de nav. No Safari, remover marcadores com list-style: none pode impedir que o VoiceOver anuncie listas; role="list" nessa lista restaura os anúncios.

Escreva o HTML em uma ordem de leitura significativa. A propriedade flex order, a direção flex invertida, o posicionamento em grade e o posicionamento absoluto alteram o que as pessoas veem sem mudar a ordem do DOM. Uma linha que visualmente começa com “Entrar”, mas só chega a esse item por último com Tab, é mais difícil de acompanhar. Corrija a ordem no código-fonte antes de organizar o layout.

Examine a estrutura básica de uma página

Um site de padaria tem um menu principal e um segundo conjunto de links de trilha de navegação. Dê nomes distintos às regiões, mantendo ambos os conjuntos de links disponíveis:

<nav aria-label="Main">
  <ul><li><a href="/bread">Bread</a></li></ul>
</nav>
<nav aria-label="Breadcrumb">
  <ol><li><a href="/">Home</a></li></ol>
</nav>
<main>
  <h1>Order a loaf</h1>
  <h2>Choose your bread</h2>
</main>

Inspecione a lista de regiões de referência: Main e Breadcrumb identificam finalidades diferentes de navegação, seguidas pelo conteúdo principal. Depois inspecione a lista de títulos: ela deve mostrar o assunto da página e sua primeira seção. Essas duas listas oferecem caminhos diferentes pelo mesmo documento; nenhuma delas depende das cores do menu ou do tamanho da fonte do título.

O elemento usado para um controle informa às pessoas o que esperar. Um link indica um destino; um botão indica uma ação. Controles nativos e elementos de tabela também fornecem relações que seriam difíceis de recriar com caixas genéricas estilizadas.

Escolha entre navegação e ação

Uma âncora sem href não é um link comum que recebe foco pelo teclado. Uma âncora com href="#" e um manipulador de clique que abre um menu anuncia navegação, embora execute uma ação. Use um botão para esse menu. Dentro de um formulário, atribua type="button" aos botões que não devem enviá-lo; caso contrário, seu comportamento padrão pode enviar o formulário.

Deixe os destinos claros

Um leitor de tela pode reunir os links da página em uma lista. Links repetidos com “Leia mais” são difíceis de distinguir nessa lista. “Leia sobre as aulas de fermentação natural” nomeia o destino diretamente. O critério 2.4.4 Finalidade do Link (Em Contexto) (A) das WCAG permite que o contexto próximo explique um link, mas um texto de link significativo também funciona quando ouvido isoladamente.

Informe às pessoas sobre um download ou uma nova aba no texto do link: “Lista de preços (PDF, 2 MB)” ou “Formulário de reserva (abre em uma nova aba)”. Uma nova aba muda a forma como o botão Voltar funciona. Use uma descrição em vez de uma URL longa, quando possível.

Todo link e botão precisa de um nome acessível. Um link para o carrinho formado apenas por uma imagem precisa de texto que informe seu destino; uma imagem sem alternativa pode deixar um link sem nome ou identificado pelo nome de um arquivo. Nomear é tão necessário quanto escolher a função correta.

Mantenha o comportamento nativo

Use caixas de seleção, botões de opção e controles select nativos. Eles já oferecem operação por teclado e anunciam seus estados. Um controle simples de expansão e recolhimento pode usar apenas HTML:

<details>
  <summary>Delivery options</summary>
  <p>We deliver within 10 km.</p>
</details>

O resumo recebe foco do teclado, e o controle informa seu estado aberto ou fechado. Uma linha personalizada com um ícone de triângulo precisaria ter esses recursos implementados separadamente.

Associe os dados da tabela aos cabeçalhos

Use tabelas para dados com relações entre linhas e colunas. Um título nomeia o conjunto de dados; th identifica cabeçalhos; scope informa ao navegador quais células um cabeçalho descreve.

<table>
  <caption>Shop opening hours</caption>
  <tr><th scope="col">Day</th><th scope="col">Opens</th></tr>
  <tr><th scope="row">Saturday</th><td>08:00</td></tr>
</table>

Uma pessoa que se move para a célula do horário pode ouvir o dia e o cabeçalho de coluna associados. Uma grade CSS de elementos div perde essas relações nativas. Para o layout da página, use flexbox ou grade; uma tabela de layout pode criar uma navegação por tabela enganosa onde não há uma relação real entre dados.

O texto alternativo fornece as informações úteis ou a função de uma imagem a quem não pode vê-la. Decida o que a imagem acrescenta nessa página específica antes de descrever sua aparência. A mesma fotografia pode precisar de textos diferentes em contextos diferentes.

Escolha pela finalidade

Para uma fotografia informativa de produto, alt="Round sourdough loaf with a dark, cracked crust" descreve o que uma pessoa compradora precisa saber. Em uma página sobre falhas no preparo de pães, a característica importante poderia ser uma crosta queimada. Imagine ler a página pelo telefone: inclua as informações que a pessoa ouvindo deixaria de receber.

Para uma imagem que serve apenas de decoração, use alt="". Uma alternativa vazia informa aos leitores de tela que devem ignorar a imagem. Omitir o atributo é diferente: um leitor de tela pode anunciar um nome de arquivo como “IMG underline 4032 ponto jpg”. Um fundo puramente decorativo também pode ser colocado no CSS.

Nomeie uma função, não uma forma

Quando uma imagem é o único conteúdo de um link ou botão, sua alternativa fornece o nome do controle. Um link para a página inicial pode ser:

<a href="/">
  <img src="logo.svg" alt="Green Leaf Bakery home">
</a>

Para um botão de pesquisa, use “Pesquisar”, não “Lupa”. A pessoa precisa saber o que acontecerá ao pressionar o controle. Se um link de produto já contém as palavras visíveis “Pão de centeio”, uma foto nesse mesmo link pode usar alt="" para que o nome do link não seja repetido.

Trate imagens de texto e gráficos complexos

Uma imagem de texto precisa das mesmas palavras em sua alternativa. Um banner de promoção com “Promoção de verão: 20% de desconto em todos os pães” precisa dessas palavras, não de “Banner de promoção”. Prefira texto HTML real estilizado com CSS quando possível. Ele pode ser redimensionado, traduzido e reorganizado; o critério 1.4.5 Imagens de Texto (AA) das WCAG exige texto real quando a tecnologia permite, com exceções como logotipos.

Um gráfico, diagrama ou mapa geralmente contém informação demais para uma alternativa curta. Identifique-o brevemente e forneça uma descrição mais completa nas proximidades. Por exemplo, alt="Bar chart of monthly website visitors, January to June" identifica o gráfico. Um texto próximo pode explicar que o número de visitantes aumentou de 1.200 para 3.000, enquanto uma tabela de dados fornece valores individuais quando necessário. Um <figure> com <figcaption> pode agrupar o gráfico e sua explicação.

Revise para incluir detalhes úteis

Mantenha o texto alternativo comum em uma expressão ou frase concisa. Leitores de tela já identificam uma imagem, por isso começar com “Imagem de” geralmente não acrescenta conteúdo útil. Remova palavras repetidas próximas e palavras-chave de busca que não ajudem a pessoa a compreender a página.

O critério 1.1.1 Conteúdo Não Textual (A) das WCAG exige uma finalidade equivalente, não uma descrição de cada detalhe visível. O atributo title não é uma substituição confiável: ele não é anunciado de forma consistente nem está disponível de forma consistente para uso por teclado e toque. Coloque a alternativa de uma imagem em alt e mantenha qualquer explicação mais longa na própria página.

Um ícone, um diagrama e um vídeo precisam de tipos diferentes de alternativas. Comece identificando a informação ou ação que cada um oferece. Depois coloque o equivalente onde tanto o navegador quanto a pessoa que usa a página possam encontrá-lo.

Nomeie o controle que contém o ícone

Texto visível ao lado de um ícone geralmente é mais claro. Se um botão precisar conter apenas um ícone, forneça texto visualmente oculto ou um rótulo no botão:

<button type="button" aria-label="Close">✕</button>

Quando um ícone estiver ao lado do texto visível do botão, oculte o ícone decorativo com aria-hidden="true". Não oculte o botão inteiro. Um span ou div simples tem uma função genérica para a qual a atribuição de nome é proibida; colocar aria-label ali não é uma forma confiável de nomear um ícone.

O texto visualmente oculto permanece disponível para leitores de tela. Uma classe CSS reutilizável pode usar posicionamento absoluto, largura e altura de 1 px, transbordamento oculto, clip-path: inset(50%) e white-space: nowrap. Diferentemente de display: none ou visibility: hidden, ela mantém o texto na árvore de acessibilidade.

Para um SVG embutido no código que transmite significado, use role="img" e um nome, por exemplo, aria-labelledby="rating-title" referindo-se a <title id="rating-title">Rated 4 out of 5 stars</title> dentro dele. SVG decorativo usa aria-hidden="true". Um SVG carregado por img recebe sua alternativa de alt, como outras imagens. Mantenha avisos significativos no HTML; fundos CSS e conteúdo gerado são locais pouco confiáveis para informações essenciais.

Escolha a alternativa adequada à mídia

Legendas descritivas sincronizam falas, sons importantes e identificação de quem fala com o vídeo. Legendas de diálogo transcrevem ou traduzem falas para pessoas que conseguem ouvir, mas precisam de ajuda para entender o idioma. Uma transcrição é um relato textual separado; ela não acompanha o tempo de reprodução.

<video controls src="bread.mp4">
  <track kind="captions" src="bread-en.vtt"
         srclang="en" label="English">
</video>

O arquivo WebVTT contém entradas de texto temporizadas, como 00:00:01.000 --> 00:00:04.000, seguidas pelo texto da legenda. Verifique nomes, termos técnicos e pontuação nas legendas automáticas antes de publicar.

Se uma demonstração mostrar silenciosamente uma configuração do forno, as legendas descritivas das falas não transmitirão essa informação. A audiodescrição narra informações visuais importantes nas pausas ou em uma versão com audiodescrição. Uma alternativa textual completa que inclua os elementos visuais é uma opção no nível A; vídeos gravados precisam de audiodescrição no nível AA conforme 1.2.5.

Mantenha a reprodução utilizável

Use controls nativos em áudio e vídeo e dê aos quadros incorporados um title descritivo, como “Mapa da localização da nossa loja”. Evite som com reprodução automática. Áudio que começa automaticamente e dura mais de 3 segundos precisa de controle para pausar, parar ou ajustar o volume independentemente do volume geral do sistema.

Relacione o nome oculto e o texto temporizado

Para um botão compacto de exclusão, mantenha suas palavras no documento:

<button type="button">
  <img src="trash.svg" alt="">
  <span class="visually-hidden">Delete item</span>
</button>

A imagem é ignorada porque o texto já informa a ação. Aplique a classe de ocultação sem remover esse texto da árvore de acessibilidade:

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
}

Um arquivo de legendas descritivas, por sua vez, relaciona palavras ao tempo de reprodução. Um pequeno exemplo de WebVTT é:

WEBVTT

00:00:01.000 --> 00:00:03.000
[Mixer whirring]

00:00:03.000 --> 00:00:06.000
Today we bake rye bread.

A primeira entrada transmite um som relevante sem diálogo. A segunda transmite uma fala durante seu próprio intervalo. Assista ao vídeo com a faixa ativada e verifique se cada entrada aparece quando seu som ocorre.

Quem usa teclado precisa de um caminho por toda a tarefa: alcançar um controle, reconhecê-lo, operá-lo e seguir adiante. Controles HTML padrão já oferecem suporte a esse caminho. Problemas costumam aparecer quando a estilização ou controles personalizados interferem no comportamento do navegador.

Use as teclas esperadas

Tab avança pelos elementos interativos; Shift+Tab volta. Enter segue links e ativa botões. Espaço ativa botões e alterna caixas de seleção. Em um grupo de botões de opção, Tab entra ou sai do grupo e as setas movem entre as opções. As setas também funcionam em controles de seleção nativos. Escape fecha caixas de diálogo e muitos menus.

Links com href, botões, campos de entrada, listas de seleção, áreas de texto, elementos summary e mídias com controles recebem foco por padrão. Parágrafos, títulos, imagens, contêineres genéricos e âncoras sem href não são paradas comuns de Tab. Um leitor de tela tem comandos de leitura separados para texto, por isso adicionar cada título à sequência de Tab torna a navegação por teclado mais lenta.

No macOS, ative a navegação por teclado ao testar. A configuração “Pressione Tab para destacar cada item em uma página web” do Safari controla se a navegação comum com Tab alcança links; Option+Tab pode alcançá-los quando essa configuração está desativada.

Mantenha os valores de tabindex simples

Valores positivos são difíceis de manter porque criam um segundo sistema de ordenação. Escreva o HTML em uma ordem lógica e evite-os. Um título que precise receber foco após uma atualização pode usar -1 sem se tornar uma parada em cada percurso pela página.

Verifique significado e comportamento juntos

<div role="button" tabindex="0">Save</div>

Isso disponibiliza uma função de botão e recebe foco, mas ainda precisa de script para Enter e Espaço, uma ação e um estilo de foco visível. Substituí-lo por <button type="button">Save</button> oferece ativação nativa por teclado sem reconstruí-la. ARIA sozinho não pode criar a interação.

O CSS também pode atrapalhar a navegação. Se a ordem no código-fonte for logotipo, menu, pesquisa, link de entrada, order: -1 no CSS pode mostrar a entrada primeiro enquanto Tab ainda a alcança por último. Mova o conteúdo no HTML quando a ordem de leitura precisar mudar. O critério 2.4.3 Ordem de Foco (A) das WCAG exige uma ordem que preserve o significado e a operação.

Elimine armadilhas e paradas ocultas

Teste se o foco consegue sair de cada componente usando o teclado. Um mapa ou reprodutor que aceita foco, mas não oferece saída pelo teclado, cria uma armadilha de teclado, proibida por 2.1.2 Sem Armadilha de Teclado (A).

Um menu fechado movido para fora da tela ou com opacity: 0 ainda pode conter links que recebem foco. Use hidden, display: none ou inert para conteúdo que deve ficar indisponível enquanto estiver fechado. Mantenha, porém, um link para pular blocos de conteúdo fora da tela capaz de receber foco: ele tem uma regra específica que o torna visível ao receber foco.

O foco é a posição atual de quem usa teclado. Um contorno visível informa qual controle será operado por Enter ou Espaço. O contorno precisa permanecer visível em relação à página, e o controle em foco precisa permanecer à vista.

Mantenha um indicador claro

Navegadores fornecem um contorno de foco padrão. Removê-lo com outline: none elimina uma indicação essencial, a menos que seja fornecida uma substituição adequada. Use :focus-visible para mostrar um contorno quando o navegador considerar útil, inclusive na navegação por teclado e em campos de texto:

:focus-visible {
  outline: 3px solid #1A73E8;
  outline-offset: 2px;
}

O azul tem contraste de 4,51:1 em relação ao branco. Verifique as cores adjacentes reais no design; um contorno que funciona sobre branco pode se confundir com um painel azul. O critério 2.4.7 Foco Visível (AA) das WCAG exige foco de teclado visível, enquanto 1.4.11 Contraste Não Textual (AA) se aplica às informações visuais que identificam um estado personalizado, incluindo um indicador de foco personalizado, com razão de 3:1.

Um contorno é uma escolha útil para temas de contraste do Windows. As cores forçadas podem substituir fundos e remover sombras de caixa, enquanto os contornos permanecem disponíveis. Uma sombra sozinha pode, portanto, desaparecer em um modo do qual uma pessoa depende.

Mantenha o controle em foco visível

Cabeçalhos aderentes, banners e controles de chat podem encobrir o foco. Pelo critério 2.4.11 Foco Não Encoberto (Mínimo) (AA), conteúdo criado pelo autor não deve ocultar completamente o componente em foco. Manter o componente inteiro visível facilita o uso; o requisito de que nenhuma parte fique oculta pertence ao nível AAA.

Para um cabeçalho aderente de 5 rem de altura, reserve espaço de rolagem:

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

Depois percorra a página real com Tab. Verifique as duas direções e teste quando um aviso de cookies estiver presente. A regra CSS é um ponto de partida; ela ainda precisa funcionar com os tamanhos reais do cabeçalho e da área de visualização da página.

Dê espaço também a quem usa ponteiro

Tamanho do Alvo (Mínimo), 2.5.8 (AA), exige alvos do ponteiro de pelo menos 24 por 24 px CSS, com exceções. Um alvo menor pode atender ao critério se um círculo de 24 px de diâmetro centrado nele não intersectar outro alvo nem o círculo de outro alvo pequeno. Links em frases, controles com tamanho definido pelo navegador e sem modificações e alvos com um controle equivalente que atenda ao critério na página também são exceções. Uma apresentação essencial ou exigida por lei também pode ser uma exceção.

Para três botões com ícones de 16 por 16 px separados por espaços de 4 px, os círculos se sobreporiam. Adicionar preenchimento interno de 4 px em todos os lados faz cada alvo ter 24 por 24 px. Meça a área clicável, não apenas o ícone desenhado dentro dela.

O alvo de 44 por 44 px CSS em 2.5.5 e o requisito de tamanho da área de foco em 2.4.13 são requisitos AAA. São melhorias úteis, mas mantenha seu nível separado do mínimo AA ao relatar um problema.

Menus repetidos não devem obrigar as pessoas a repetir o mesmo percurso em cada página. Um link para pular blocos de conteúdo oferece um caminho curto até o conteúdo principal. Quando uma interação altera a página, o tratamento deliberado do foco também ajuda as pessoas a manter sua posição.

Crie e teste um link para pular blocos de conteúdo

Coloque o link antes dos controles repetidos do cabeçalho:

<a class="skip-link" href="#main">Skip to main content</a>
<main id="main" tabindex="-1">
  <h1>Order a birthday cake</h1>
</main>

O link aponta para a região principal, e tabindex="-1" ajuda essa região a receber foco sem adicionar uma parada comum de Tab. A navegação por regiões de referência de um leitor de tela ajuda seus usuários; o link também ajuda pessoas que enxergam e usam teclado a pular blocos repetidos, conforme 2.4.1 Ignorar Blocos (A).

Mantenha o link disponível para o teclado quando estiver visualmente oculto:

.skip-link { position: absolute; left: -9999px; }
.skip-link:focus { left: 1rem; top: 1rem; }

Não use display: none ou visibility: hidden, que impedem o foco. Recarregue a página, pressione Tab uma vez e verifique se o link aparece. Pressione Enter e depois Tab novamente: a navegação deve continuar no primeiro link ou controle do conteúdo principal, não no menu do cabeçalho.

Dê uma próxima posição adequada ao conteúdo alterado

Se uma linha do carrinho e seu botão Remover em foco desaparecerem juntos, o foco pode retornar ao início da página. Mova-o deliberadamente para o botão Remover do próximo item ou para um título do carrinho com tabindex="-1". Escolha um lugar que permita continuar a tarefa. Apenas rolar até uma região não garante que o foco do teclado tenha sido movido para lá.

Use uma caixa de diálogo modal nativa

Uma caixa de diálogo aberta com showModal() move o foco para dentro dela e torna o restante da página inerte. Tab permanece dentro dela enquanto estiver aberta; Escape a fecha. Ao fechar normalmente, o foco retorna ao elemento que a abriu, caso ele ainda exista.

<button type="button"
  onclick="document.getElementById('hours').showModal()">Opening hours</button>
<dialog id="hours" aria-labelledby="hours-title">
  <h2 id="hours-title">Opening hours</h2>
  <p>Tuesday to Saturday, 08:00–17:00.</p>
  <form method="dialog"><button>Close</button></form>
</dialog>

O script de uma linha encontra a caixa de diálogo pelo ID e a abre como modal. O formulário da caixa de diálogo a fecha sem outro script. Seu título fornece seu nome. Uma sobreposição feita à mão precisa que todas essas regras de interação sejam recriadas; deixar o fundo com aparência escura não impede que o foco do teclado o alcance.

Aguarde uma ação intencional

Receber foco não deve abrir uma nova página nem mudar o contexto de outra forma. Mudar uma seleção também não deve fazer isso inesperadamente; as pessoas devem ser avisadas com antecedência se esse comportamento ocorrer. Um botão “Ir” depois de um seletor de destino dá tempo para que as pessoas examinem e alterem sua seleção antes de navegar. Esses comportamentos atendem a 3.2.1 Ao Receber Foco (A) e 3.2.2 Na Entrada de Dados (A).

O contraste mede a clareza com que informações em primeiro plano se destacam do fundo. Uma cor que parece legível em uma tela pode ser difícil de ler para alguém com baixa visão ou sob luz intensa. Meça o par em vez de avaliá-lo a olho.

Aplique o mínimo correto

Texto em tamanho grande significa pelo menos 18 pontos, equivalentes a 24 px CSS, ou pelo menos 14 pontos em negrito, cerca de 18,7 px CSS em negrito. Um título de 20 px com peso normal ainda precisa de 4,5:1. Textos de exemplo de campo, de rodapé e nos estados de passagem do ponteiro e de foco não são exceções ao contraste de texto. Há exceções para logotipos, controles inativos e texto incidental ou puramente decorativo.

Entenda a razão

A luminância relativa expressa o brilho em uma escala de 0 para preto a 1 para branco. Com a luminância mais clara como L1 e a mais escura como L2, a razão é:

Os extremos são 1:1 para cores idênticas e 21:1 para preto em relação ao branco. Uma ferramenta de contraste calcula a luminância a partir dos canais de cor e compara a razão com o limiar relevante.

Para o cinza #767676, cada canal é 76 em hexadecimal, ou 118. Divida por 255 para obter aproximadamente 0,4627. Como esse valor é maior que 0,04045, converta-o para luz linear:

Os três canais são iguais, portanto sua luminância ponderada também é aproximadamente 0,1812. O branco tem luminância 1. Manter a precisão completa durante o cálculo resulta em 4,54:1, que atende ao requisito para texto normal. Use uma ferramenta de verificação para pares de cores reais, para que valores intermediários arredondados não afetem um resultado próximo do limiar.

Nunca arredonde um resultado insuficiente para que passe

O cinza #777777 sobre branco resulta em 4,48:1. Exibi-lo com uma casa decimal como 4,5 não faz com que atenda ao requisito. Da mesma forma, #949494 sobre branco resulta em 3,03:1 e atende para texto em tamanho grande; #959595 resulta em 2,99:1 e não atende para texto em tamanho grande.

Branco sobre #0066CC resulta em 5,57:1. Sobre o âmbar #FFC107, texto branco resulta em apenas 1,63:1, enquanto o preto resulta em 12,88:1. Escolher um fundo de botão brilhante não informa se seu texto deve ser claro ou escuro.

Verifique limites e todos os fundos

Uma borda de campo necessária para identificar o campo deve atender ao contraste não textual. #CCCCCC em relação ao branco resulta em 1,61:1 e não atende; #949494 resulta em 3,03:1 e atende. A mesma regra de 3:1 se aplica a ícones significativos, linhas de gráficos e indicadores de foco personalizados. Controles inativos e controles padrão do navegador sem modificações têm exceções.

Texto sobre uma fotografia ou gradiente deve atender ao requisito no ponto de menor contraste atrás dele. Adicione um painel sólido ou suficientemente opaco, ou mova o texto. Verifique as cores resultantes com as ferramentas do desenvolvedor ou uma ferramenta de contraste. O critério 1.4.3 das WCAG abrange texto e 1.4.11 abrange informações não textuais; os limiares AAA para texto são maiores, 7:1 para texto normal e 4,5:1 para texto em tamanho grande.

Verifique as partes de um botão separadamente

Suponha que um botão tenha texto branco em tamanho normal sobre #0066CC, esteja em uma página branca e use um contorno de foco personalizado #CCCCCC. Verifique cada relação:

1. O rótulo em relação ao botão azul tem 5,57:1, acima do mínimo de 4,5:1 para texto.
2. O botão azul em relação à página branca também tem 5,57:1, portanto seu limite é distinguível.
3. O contorno de foco cinza-claro em relação à página branca tem apenas 1,61:1. Esse indicador de estado não atende ao requisito, embora o rótulo atenda.

Substitua o contorno por uma cor que atinja 3:1 em relação ao fundo adjacente e meça novamente. A leitura de uma ferramenta para o rótulo do botão não mede também cada limite ou estado de interação. Trate o texto, o componente e o estado personalizado como verificações separadas de pares de cores.

A cor pode chamar a atenção, mas não pode ser a única indicação visual de significado. Pessoas podem ter deficiência na visão de cores, usar escala de cinza ou configurações de contraste, ou ouvir conteúdo por um leitor de tela sem anúncios de cores. Combine a cor com texto, formas, padrões ou outra indicação clara.

Separe duas verificações

O contraste verifica se um elemento em primeiro plano pode ser distinguido do fundo. O uso de cor, WCAG 1.4.1 (A), verifica se a informação continua compreensível sem reconhecer a cor. Um rótulo vermelho-escuro sobre branco pode atender ao contraste e ainda não explicar qual campo tem erro.

Comece pela mensagem. Se a página disser “Escolha uma opção verde”, dê também um nome útil a cada opção. Se um ponto vermelho significar que uma loja está fechada, adicione “Fechada agora” ao lado dele. O texto transmite o status, enquanto a cor ajuda as pessoas a percebê-lo.

Mantenha links reconhecíveis

A maneira mais simples de identificar um link em um parágrafo é um sublinhado. Ele fornece uma indicação mesmo quando o link e o texto ao redor são vistos em escala de cinza.

Uma diferença apenas de cor em relação ao texto ao redor precisa de contraste de pelo menos 3:1 entre as duas cores de texto e de uma indicação adicional, como sublinhado, ao passar o ponteiro e ao receber foco. O texto do link também deve atender ao contraste de texto em relação ao fundo. São comparações separadas; um azul que atende em relação ao branco pode ser parecido demais com o texto escuro do parágrafo ao lado.

Explique erros e campos obrigatórios

Para um erro de e-mail, mostre “Erro: digite um endereço de e-mail no formato nome@example.com” ao lado do campo. Um contorno vermelho pode permanecer como indicação adicional. O texto identifica o problema e informa como corrigi-lo, enquanto o código o associa ao campo.

Para campos obrigatórios, use um rótulo como “Endereço de e-mail (obrigatório)”. Um asterisco também funciona quando o início do formulário explica “* significa obrigatório”. Adicione o atributo nativo required para que o requisito esteja disponível à tecnologia assistiva e à validação do navegador. O texto vermelho do rótulo, sozinho, não fornece uma explicação visual adequada nem um requisito identificável pelo código.

Dê aos gráficos uma segunda forma de comunicar

Um gráfico de vendas com duas séries precisa de mais do que uma linha vermelha e uma linha verde. Rótulos diretos, estilos de linha diferentes ou padrões permitem que as pessoas acompanhem cada série sem identificar sua cor. Use essas indicações no gráfico e em sua legenda para que correspondam entre si.

Verifique a página com emulação de escala de cinza ou de deficiência na visão de cores nas ferramentas do desenvolvedor. Inspecione links em texto corrido, erros, campos obrigatórios, gráficos e indicadores de disponibilidade. Pergunte qual indicação visual permanece para cada distinção. Se uma distinção desaparecer, adicione uma indicação que informe ou represente seu significado; aumentar apenas a saturação não fornecerá a informação ausente.

Ampliar uma página deve facilitar seu uso sem ocultar controles ou cortar frases. As pessoas podem ampliar a página inteira, ampliar apenas o texto ou aplicar seu próprio espaçamento. Layouts flexíveis permitem que essas escolhas funcionem em conjunto.

Teste o tamanho do texto e o refluxo

O critério 1.4.4 Redimensionar Texto (AA) das WCAG exige que o texto seja ampliado até 200% sem perda de conteúdo ou funcionalidade. O zoom do navegador usa Ctrl e sinal de mais no Windows ou Cmd e sinal de mais no macOS. Teste também um tamanho de fonte padrão maior, que altera o texto sem ampliar todo o resto da mesma forma.

O critério 1.4.10 Refluxo (AA) das WCAG exige que o conteúdo comum funcione em uma largura de 320 px CSS sem rolagem em duas direções. Uma janela de 1280 px CSS de largura com zoom de 400% fornece essa largura efetiva. Os parágrafos devem se ajustar em uma coluna estreita, com todas as funcionalidades ainda disponíveis. Tabelas de dados, mapas e outros conteúdos cujo significado depende de duas dimensões têm exceções.

Deixe o layout crescer com o texto

Use unidades relativas de fonte como rem e em para que o texto siga a configuração de fonte padrão do usuário. Texto em pixels CSS ainda responde ao zoom do navegador, mas não segue essa configuração padrão da mesma forma. Contêineres flexíveis e max-width permitem que as linhas se ajustem; pontos de quebra em em podem se adaptar conforme o texto cresce.

Uma altura fixa pode cortar conteúdo sem aviso:

/* Problem when larger text needs more space */
.card { height: 200px; overflow: hidden; }

/* Content can grow beyond the minimum */
.card { min-height: 200px; }

Permita que o conteúdo determine sua altura. Em larguras pequenas, empilhe a navegação ou ofereça um controle acessível de expansão e recolhimento em vez de excluir links. Deixe um cabeçalho aderente grande demais rolar para fora da tela se ele ocupar espaço excessivo da área de visualização utilizável.

Mantenha o zoom em dispositivos móveis disponível

Use uma declaração da área de visualização que siga a largura do dispositivo:

<meta name="viewport" content="width=device-width, initial-scale=1">

Não adicione maximum-scale=1 ou user-scalable=no. Eles tentam bloquear o zoom por pinça, do qual pessoas com baixa visão podem precisar. Alguns navegadores ignoram essas restrições, mas as pessoas não deveriam ter que depender desse comportamento.

Aplique o espaçamento definido pelo usuário

O critério 1.4.12 Espaçamento do Texto (AA) das WCAG exige que não haja perda ou sobreposição de conteúdo quando as pessoas definem a altura da linha como 1,5 vez o tamanho da fonte, o espaçamento entre parágrafos como 2 vezes, o espaçamento entre letras como 0,12 vez e o espaçamento entre palavras como 0,16 vez. Essas são configurações de teste, não valores padrão obrigatórios de design. Use uma ferramenta de espaçamento de texto e verifique rótulos, cartões, menus e botões, além dos parágrafos.

Uma verificação prática combina um teste de texto a 200%, um teste de refluxo a 320 px CSS e a substituição do espaçamento. Procure linhas cortadas, rótulos sobrepostos, rolagem horizontal de parágrafos e funcionalidades que desapareceram. Corrija o contêiner ou layout que causa o problema; reduzir o texto ampliado pelo usuário elimina o benefício que ele pediu.

Um rótulo visível informa o que inserir e dá a um campo um nome acessível. Rótulos de grupo acrescentam a pergunta à qual várias opções respondem. As associações precisam existir no HTML, mesmo quando rótulos e campos já aparecem próximos.

Associe um rótulo a um controle

Um rótulo explícito usa for para fazer referência ao id único do controle:

<label for="email">Email address</label>
<input id="email" name="email" type="email">

O navegador pode anunciar “Email address” quando o campo recebe foco. Clicar no texto também coloca o foco no campo, oferecendo um alvo maior. O atributo name identifica os dados enviados; ele não substitui o id usado pelo rótulo.

Um rótulo implícito envolve seu campo de entrada: <label>Email address <input type="email" name="email"></label>. Isso funciona quando ambos cabem dentro do mesmo elemento de rótulo. Com contêineres de layout separados, a associação explícita é mais fácil de manter.

Um texto de exemplo do campo desaparece durante a digitação e costuma ter baixo contraste. Mantenha o rótulo visível e coloque exemplos ou orientações de formato por perto. “Campo 1” é tecnicamente um nome, mas não descreve a finalidade. O critério 2.4.6 Títulos e Rótulos (AA) das WCAG exige uma redação descritiva.

Mantenha as palavras visíveis no nome

Uma pessoa que usa controle por voz pode dizer “clique em Enviar” ao ver um botão Enviar. Se aria-label="Submit form" substituir o texto desse botão, seu nome acessível não conterá mais as palavras visíveis. O critério 2.5.3 Rótulo no Nome (A) das WCAG exige que essas palavras sejam incluídas, de preferência no início. Use o próprio texto visível quando possível: <button type="submit">Send message</button>.

Um campo de pesquisa isolado pode ter um rótulo visualmente oculto se um botão Pesquisar próximo tornar sua finalidade visualmente clara. Rótulos ocultos não substituem, de modo geral, as instruções visíveis em todo o formulário.

Agrupe opções sob sua pergunta

<fieldset>
  <legend>Delivery method</legend>
  <input type="radio" id="pickup" name="delivery" value="pickup">
  <label for="pickup">Pick up in store</label>
  <input type="radio" id="courier" name="delivery" value="courier">
  <label for="courier">Courier delivery</label>
</fieldset>

A legenda fornece a pergunta do grupo; cada botão de opção ainda precisa de seu próprio rótulo. Leitores de tela podem anunciar o contexto do grupo junto com uma opção. Use o mesmo name para opções mutuamente exclusivas e legendas curtas que continuem úteis quando repetidas. Caixas de seleção relacionadas também podem usar um fieldset e uma legenda.

Escolha tipos e verifique associações

Use email, tel, url e date para os dados correspondentes. Os tipos de e-mail e URL oferecem uma verificação de formato; campos de telefone podem oferecer um teclado móvel adequado, mas não validam formatos de número de telefone. Use number para quantidades, como o número de convidados, não para identificadores de telefone ou cartão.

Clique em cada rótulo para testar sua associação. Se o campo errado receber foco, procure IDs duplicados ou um for que não corresponda ao campo. Inspecione também o nome computado nas ferramentas do desenvolvedor; a proximidade visual por si só não associa um rótulo.

As instruções ajudam mais quando chegam antes de um erro. Um bom formulário explica a entrada esperada, mostra o que é obrigatório e oferece suporte às ferramentas do navegador para inserir informações pessoais. Ele também evita que as pessoas repitam trabalho desnecessariamente.

Associe uma orientação sem substituir o rótulo

<label for="pw">Password (required)</label>
<input id="pw" type="password" required
       autocomplete="new-password" aria-describedby="pw-hint">
<p id="pw-hint">At least 12 characters.</p>

O rótulo nomeia o campo. O parágrafo visível explica seu requisito, e aria-describedby acrescenta esse texto como descrição. Leitores de tela podem anunciá-lo depois do nome. Para várias descrições, liste seus IDs separados por espaços, como em aria-describedby="pw-hint pw-error".

Identifique campos obrigatórios visualmente e com required. Você pode escrever “(obrigatório)” ou explicar um asterisco no início do formulário. O required nativo oferece suporte à validação do navegador e à tecnologia assistiva; ele não precisa de um aria-required="true" adicional.

Identifique a finalidade dos dados pessoais

Conforme 1.3.5 Identificar a Finalidade da Entrada (AA), campos que coletam informações do usuário precisam de tokens autocomplete adequados. Exemplos incluem name, given-name, family-name, email, tel, street-address, postal-code, country-name e bday. Campos de entrada na conta podem usar username e current-password; uma nova senha usa new-password, e um código de verificação pode usar one-time-code.

Esses tokens permitem que navegadores, gerenciadores de senhas e ferramentas assistivas reconheçam a finalidade de um campo. Use o token correspondente à pessoa cujas informações estão sendo inseridas. Marcar o endereço de contato de um amigo como o e-mail do próprio usuário para preenchimento automático pode inserir os dados errados.

Reduza as exigências de memória e de redigitação

Permita colar em campos de senha e código de verificação e ofereça suporte a gerenciadores de senhas. O critério 3.3.8 Autenticação Acessível (Mínimo) (AA) das WCAG permite testes cognitivos durante a entrada na conta apenas com uma alternativa ou ajuda que atenda ao critério, ou nas exceções especificadas para reconhecimento de objetos ou conteúdo pessoal. Bloquear a colagem cria uma barreira quando obriga a pessoa a lembrar ou transcrever informações e não existe outra forma de entrar que atenda ao critério.

Em um pedido com várias etapas, reaproveite as informações já inseridas. Uma opção “O endereço de cobrança é o mesmo da entrega” evita a redigitação. O critério 3.3.7 Entrada Redundante (A) das WCAG permite exceções quando a repetição é essencial, necessária para segurança ou quando a informação anterior não é mais válida.

Forneça uma proteção para envios com consequências

Um pedido pode criar um compromisso financeiro. Antes de concluí-lo, ofereça uma etapa de revisão que permita corrigir os dados. Conforme 3.3.4 Prevenção de Erros (Legal, Financeiro, Dados) (AA), os envios abrangidos devem ser reversíveis, verificados com oportunidade de correção ou revisados e confirmados com possibilidade de correção. O escopo também inclui alterar ou excluir dados armazenados controlados pelo usuário e enviar respostas de testes.

Mantenha o layout do formulário fácil de acompanhar quando ampliado: rótulos diretamente acima dos campos e uma coluna principal reduzem a distância entre uma instrução e o lugar ao qual ela se aplica.

Diferencie formato de finalidade pessoal

O tipo de entrada e o token de preenchimento automático respondem a perguntas diferentes. O tipo identifica o tipo de valor e pode fornecer uma verificação de formato. O token identifica a informação pessoal do usuário para preenchimento automático:

<label for="your-email">Your email address (required)</label>
<input id="your-email" name="email" type="email"
       required autocomplete="email">
<label for="guest-email">Guest's email address</label>
<input id="guest-email" name="guest-email" type="email">

Ambos os campos aceitam endereços de e-mail, mas apenas o primeiro pede o e-mail do usuário atual. O segundo não deve ser marcado como o e-mail desse usuário para preenchimento automático. Os rótulos visíveis preservam a distinção para quem insere os valores por conta própria. Alterar um token não muda o que o tipo de e-mail verifica.

Uma mensagem de erro deve ajudar a pessoa a se recuperar sem perder o trabalho já feito. Uma mensagem de status deve informar uma mudança sem tirar a pessoa de sua posição. Ambas precisam de texto visível e da associação correta no código.

Informe o problema e uma correção útil

“Entrada inválida” oferece pouca ajuda. “Erro: digite um endereço de e-mail no formato nome@example.com” identifica o que precisa de atenção e sugere uma correção. O critério 3.3.1 Identificação de Erros (A) das WCAG exige que erros detectados sejam descritos em texto; 3.3.3 Sugestão de Correção de Erro (AA) exige correções conhecidas quando elas não comprometem a segurança ou a finalidade do formulário.

<label for="email">Email address</label>
<input id="email" type="email" aria-invalid="true"
       aria-describedby="email-error">
<p id="email-error">Error: Enter an email address in the format name@example.com</p>

Defina aria-invalid="true" apenas depois de verificar o campo e encontrar um erro. O atributo informa o estado inválido; a descrição explica o motivo. Uma borda vermelha sozinha não fornece a explicação em texto nem a associação.

Ajude as pessoas a encontrar vários erros

Após o envio, um formulário longo pode mostrar um resumo de erros no topo. Dê a ele um título como “Há 2 problemas com seu pedido” e depois links para os campos afetados. Permita que o resumo receba foco com tabindex="-1" e faça o script colocar o foco nele. Acrescentar “Erro: ” ao início do título da página também ajuda a identificar a mudança de estado da página.

Mantenha também as mensagens de cada campo ao lado dos respectivos campos de entrada e preserve tudo o que já foi inserido. Um link do resumo leva a pessoa a um campo; a explicação local ajuda durante a correção. Limpar todos os campos obriga a repetir o trabalho já concluído corretamente.

Atributos de validação nativos como required, type="email" e minlength podem fornecer mensagens do navegador. Um sistema personalizado pode usar novalidate e mostrar suas próprias mensagens. Em ambos os casos, os erros precisam de texto que as pessoas possam localizar e associar ao campo correspondente.

Anuncie uma mudança sem mover o foco

Uma atualização do carrinho costuma ocorrer enquanto o foco deve permanecer no botão Adicionar. Use uma região viva que já esteja presente no documento:

<p role="status" id="cart-status"></p>

Quando um item é adicionado, um script muda seu texto para “Adicionado 1 pão de fermentação natural ao seu carrinho”. role="status" é polido: permite que o leitor de tela termine a fala atual antes de anunciar a atualização. Isso atende a 4.1.3 Mensagens de Status (AA).

Reserve role="alert", um anúncio assertivo, para mensagens urgentes. Interrupções constantes dificultam compras comuns. Insira a região vazia antes de atualizar seu conteúdo; criar a região e sua mensagem juntas não é anunciado de forma confiável em muitas combinações. Mantenha o foco na tarefa para atualizações rotineiras e mova-o deliberadamente em situações como um resumo de erros que a pessoa precisa examinar.

ARIA acrescenta informações à árvore de acessibilidade quando o HTML precisa de ajuda para expressar um nome, uma relação ou um estado. Ela não constrói a interação em si. Antes de adicionar um atributo, verifique o que o elemento nativo já fornece e o que realmente está faltando.

Trate uma função como uma promessa

WAI-ARIA significa Aplicações de Internet Ricas e Acessíveis. A versão 1.2 tornou-se uma Recomendação do W3C em junho de 2023. Suas funções, estados e propriedades influenciam o que é informado às tecnologias assistivas. Uma função como button promete comportamento de botão, mas não cria capacidade de receber foco, ativação por teclado nem estilização.

Um div com role="button" ainda precisa de tratamento de teclado e suporte a foco. Um button real já os fornece. O princípio “nenhum ARIA é melhor que ARIA mal usado”, do Guia de Práticas de Autoria ARIA, alerta que informações incorretas podem induzir as pessoas ao erro sobre o que um controle faz.

Preserve o significado nativo

Use primeiro elementos e atributos nativos: nav, button, um campo de caixa de seleção e o required nativo. Evite repetir funções implícitas, como role="main" em main ou role="button" em button. Uma exceção útil é role="list" em uma lista cuja remoção de marcadores afeta os anúncios do VoiceOver.

Não substitua o significado de um título por uma função de botão. Aninhe um botão dentro dele:

<h2>
  <button type="button" aria-expanded="false">Shipping</button>
</h2>

O título continua aparecendo na navegação por títulos, e seu botão disponibiliza a ação. O script deve manter o conteúdo exibido e o estado expandido em concordância.

Nunca coloque aria-hidden="true" em um controle que pode receber foco ou em um ancestral que contenha um. O foco poderia chegar a algo removido da árvore de acessibilidade. role="presentation" e role="none" funcionam de outra forma: removem a semântica, não o conteúdo. Navegadores ignoram essas funções em elementos que podem receber foco, por isso elas não podem transformar um link ativo em texto simples.

Encontre a origem de um nome

Para os controles comuns apresentados aqui, verifique as origens do nome nesta ordem de prioridade:

1. aria-labelledby, que faz referência a texto por ID.
2. aria-label, que fornece uma string.
3. A fonte nativa, como um rótulo, texto de botão ou texto alternativo de imagem.
4. title, como último recurso, quando aplicável.

aria-describedby acrescenta uma descrição depois do nome; não define o nome. Uma substituição pode ocultar acidentalmente palavras visíveis úteis. <button aria-label="Close dialog">Cancel</button> é anunciado como “Close dialog”, embora a pessoa veja “Cancel”. Prefira texto visível ou inclua-o no início de um nome mais extenso quando necessário.

Sites básicos costumam precisar de ARIA para nomes de regiões de referência repetidas, botões com ícones, orientações e erros de campos, controles de expansão e recolhimento, links da página atual e atualizações em tempo real. Uma grande quantidade de atributos ARIA não é uma medida de qualidade. Inspecione a função e o nome computados e use o teclado para verificar o comportamento prometido pela função.

Acompanhe fontes de nome concorrentes

Considere um botão com vários atributos de nomeação:

<h2 id="options-title">Delivery options</h2>
<button type="button" aria-labelledby="options-title"
        aria-label="Choose delivery">Show pickup options</button>

Primeiro siga aria-labelledby: seu texto referenciado fornece “Delivery options”. O aria-label de menor prioridade e o texto visível do botão não prevalecem. Portanto, remover apenas aria-label mantém o mesmo nome computado.

Para que “Show pickup options” nomeie esse botão, remova ambas as substituições desnecessárias. A função de botão permanece a mesma durante todo o processo; apenas a fonte de seu nome muda. Inspecione o nome computado após cada edição para identificar qual atributo causou a divergência. Adicionar uma descrição não corrigiria o nome errado, pois uma descrição é uma informação separada.

Uma interface que muda precisa transmitir a mesma informação visualmente e pelo código. Se um painel estiver aberto, mas seu botão ainda informar “recolhido”, uma pessoa que usa leitor de tela receberá informação falsa. Atualize o estado sempre que a interface mudar.

Mantenha um controle de expansão e recolhimento sincronizado

<button type="button" aria-expanded="false"
        aria-controls="main-menu">Menu</button>
<ul id="main-menu" hidden>
  <li><a href="/bread">Bread</a></li>
</ul>

Quando o menu abre, o script remove hidden e define o aria-expanded do botão como true. Quando fecha, o script restaura hidden e define o estado como false. O estado pertence ao botão que alterna a exibição. aria-controls identifica o elemento afetado; seu suporte varia, por isso ele não pode substituir o estado expandido nem o comportamento real de ocultação.

Escolha o estado adequado ao controle

Para o link da página atual, estilize o mesmo atributo no CSS, por exemplo, com fonte em negrito e borda inferior em a[aria-current="page"]. Isso mantém o destaque visível ligado ao estado anunciado. aria-selected pertence a componentes como abas e opções de caixas de lista, não a links comuns de navegação entre páginas.

Um botão de alternância pode manter o rótulo “Silenciar” e mudar aria-pressed entre false e true. Outro design válido altera o rótulo de um botão de ação comum entre “Silenciar” e “Ativar som” sem um estado pressionado. Não combine um rótulo de ação variável com o padrão de estado de alternância, pois isso pode produzir anúncios confusos como “Ativar som, pressionado”.

Diferencie ocultar de desabilitar

aria-hidden="true" remove um elemento e seus descendentes da árvore de acessibilidade, mas os mantém visíveis. Use-o para ícones decorativos ou conteúdo visual redundante. Ele não impede o acesso por teclado. Use hidden ou display: none quando uma região deve ficar indisponível para todas as pessoas.

O disabled nativo impede a interação comum com um controle nativo. aria-disabled="true" informa um estado indisponível, mas não bloqueia cliques nem ativação por teclado. Se esse atributo for usado para manter um controle desabilitado capaz de receber foco para fins de explicação, o script deverá impedir sua ação. Prefira também checked e required nativos em campos de entrada nativos.

Teste nos dois sentidos

Abra e feche o controle de expansão e recolhimento com o teclado enquanto observa os atributos nas ferramentas do desenvolvedor. Inspecione o estado computado e ouça seu anúncio. Uma mudança visual bem-sucedida, por si só, não mostra que o estado foi atualizado, e um atributo alterado, por si só, não mostra que o painel se tornou visível ou utilizável.

Verificações automatizadas encontram rapidamente muitos problemas de código em uma página renderizada. Use os resultados para localizar barreiras e verificar correções. Suas regras podem inspecionar algumas relações e valores, mas decidir se o conteúdo faz sentido ainda exige uma pessoa.

Escolha uma ferramenta e examine os resultados

Axe DevTools usa o motor axe-core. O WAVE coloca marcadores na página para que os problemas sejam vistos em contexto. O Lighthouse nas ferramentas do desenvolvedor do Chrome fornece uma pontuação de acessibilidade usando uma seleção de verificações do axe-core. O Accessibility Insights oferece outro fluxo de teste. O Serviço de Validação de Marcação do W3C verifica problemas de HTML, como IDs duplicados e elementos não fechados.

Dependendo de suas regras e do contexto, as ferramentas podem detectar atributos alt ausentes, controles sem nome, campos sem rótulo, baixo contraste de texto em fundos lisos, ausência de idioma da página e ARIA inválido. Alguns problemas de nível de título aparecem como avisos. Leia a explicação do resultado e inspecione o elemento identificado.

Um alerta ou resultado “precisa de revisão” pede julgamento. Um texto em negrito sinalizado como possível título pode ser um título de seção real escrito como parágrafo ou apenas enfatizar uma frase. Examine sua finalidade antes de alterar sua marcação.

Entenda o que a análise não pode decidir

Uma ferramenta pode ver alt="photo" sem saber que a alternativa é inútil. Ela não consegue avaliar de forma confiável a clareza do texto de um link, a precisão das legendas descritivas, se a ordem de foco é lógica ou se uma mensagem de erro ajuda alguém a se recuperar. Uma sobreposição visual pode prender o teclado de uma forma que a análise atual não detecta. Texto sobre uma fotografia também precisa de verificação manual de contraste.

Uma pontuação de 100 significa que as regras testadas não encontraram falhas. Não é um veredito de conformidade com as WCAG. Continue testando tarefas e significados que essas regras não conseguem avaliar.

Teste os estados que as pessoas usam

Uma análise examina o estado renderizado naquele momento. Execute verificações em cada modelo de página e novamente com menus e caixas de diálogo abertos, após erros de formulário e em larguras pequenas. Um componente fechado pode ocultar problemas que só aparecem durante o uso.

Suponha que um relatório de uma padaria encontre uma imagem principal de destaque sem alt, um campo de entrada do boletim informativo sem rótulo e texto de rodapé #999999 sobre branco. Primeiro decida se a imagem informa ou decora. Adicione uma alternativa útil ou alt="" de acordo com a finalidade. Associe o campo de e-mail a um rótulo visível. O par do rodapé tem contraste de 2,85:1; substituir a cor do texto por #595959 resulta em 7,00:1 sobre branco.

Corrija causas e verifique resultados

Priorize barreiras pelo efeito sobre a tarefa. Uma armadilha de teclado ou um controle obrigatório sem nome pode impedir completamente um pedido. Corrija um componente compartilhado de campo ou rodapé em sua origem para melhorar todas as páginas que o usam. Depois execute a análise novamente no mesmo estado e repita o teste manual relevante. Uma contagem menor de erros é uma evidência útil, mas a correção também deve permitir que a pessoa conclua a tarefa.

Testes manuais mostram como uma página se comporta durante uma tarefa real. Combine uso de teclado, visualizações ampliadas, verificações com leitor de tela e inspeção direta da árvore. Registre detalhes suficientes para que outra pessoa possa reproduzir um problema e confirmar sua correção.

Acompanhe uma tarefa de teclado do início ao fim

Deixe o mouse de lado. Comece pela barra de endereços e percorra a página com Tab. Alcance cada link e controle, use Enter e Espaço quando adequado e inverta a direção com Shift+Tab. Verifique se o foco permanece visível e não é encoberto por uma região aderente.

Use o link para pular blocos de conteúdo, abra e feche menus, feche uma caixa de diálogo com Escape e verifique para onde o foco retorna. Procure paradas invisíveis em componentes fechados e armadilhas em reprodutores ou mapas incorporados. Em um Mac, ative a navegação por teclado e a navegação completa com Tab no Safari antes de considerar controles pulados um defeito da página.

Amplie e reorganize a página

Teste com ampliação de 200% sem perder texto ou funcionalidade. Depois use uma janela de 1280 px CSS de largura com zoom de 400%, equivalente a 320 px CSS de largura disponível. Verifique se há rolagem horizontal, sobreposições e cortes nos parágrafos. Mantenha todas as funcionalidades disponíveis no layout estreito. Aplique os valores de espaçamento de texto com uma ferramenta e inspecione controles e texto corrido.

Ouça a estrutura e os nomes

O NVDA no Windows usa Insert como tecla NVDA padrão; Caps Lock é uma alternativa opcional. No modo de leitura, H percorre títulos, D regiões de referência, K links, F campos, T tabelas e B botões. NVDA+F7 abre a lista de elementos. Tab continua percorrendo controles interativos.

No macOS, Cmd+F5 ativa e desativa o VoiceOver. Seu modificador VO é Control+Option; VO+Seta para a direita lê o próximo item e VO+U abre o rotor. No iPhone, deslizar para a direita move para o próximo item do VoiceOver. O TalkBack oferece leitura por toque semelhante no Android.

Ouça se há um título de página e um esquema úteis, nomes claros de controles, funções corretas, alternativas úteis para imagens e rótulos de campo compreensíveis. Estados obrigatórios, orientações e erros devem estar disponíveis nos campos correspondentes. Abra um controle de expansão e recolhimento e ouça a mudança de estado. Adicione um item e ouça se há uma atualização de status sem salto de foco.

Inspecione, registre e teste novamente

O painel Acessibilidade no Chrome e o Inspetor de Acessibilidade no Firefox mostram funções, nomes e estados computados. Eles ajudam a descobrir por que um rótulo está errado antes mesmo de executar um leitor de tela.

Um relatório útil informa o local, as etapas, o comportamento observado, as pessoas afetadas, o critério relacionado e a correção sugerida. Por exemplo: “Campo do boletim informativo no rodapé: use Tab até o campo de entrada; ele é anunciado sem rótulo. Usuários de leitores de tela e controle por voz não conseguem identificar sua finalidade. Adicione um rótulo de endereço de e-mail associado; verifique 1.3.1, 3.3.2 e 4.1.2.”

Teste novamente com o método que encontrou o problema. Combinações comuns incluem NVDA com Firefox ou Chrome, JAWS com Chrome e VoiceOver com Safari. Testes com pessoas que usam tecnologia assistiva diariamente podem revelar barreiras que o uso ocasional por desenvolvedores deixa passar.

Torne reproduzível uma falha de estado

Um relatório para um controle de expansão e recolhimento pode registrar um teste curto e completo:

1. Na página de pães, use NVDA com Firefox e pressione Tab até “Opções de entrega”.
2. Pressione Enter uma vez. O painel fica visível, mas o botão ainda é anunciado como recolhido.
3. Inspecione o botão: aria-expanded ainda está como false.

A pessoa afetada recebe a informação de que o painel visível continua fechado. Registre 4.1.2 Nome, Função, Valor (A) e sugira atualizar o estado do botão quando o painel mudar. Após a correção, repita a abertura e o fechamento com as mesmas teclas e combinação. Verifique se a visibilidade do painel e o estado expandido anunciado concordam nos dois sentidos; inspecionar apenas o estado inicial recolhido deixaria essa falha passar.