Acessibilidade digital para negócios locais: um checklist prático

Acessibilidade começa na tarefa que a pessoa precisa concluir

Um site pode parecer organizado para quem usa mouse, enxerga todas as cores, ouve o vídeo e lê textos pequenos sem ampliação, mas bloquear alguém que navega por teclado, leitor de tela, comando de voz, zoom ou legendas. A barreira não está na pessoa: surge quando a informação ou a interface pressupõe uma única forma de perceber e agir.

Para um negócio local, o efeito é direto na jornada. A pessoa precisa encontrar horário, comparar um serviço, ler cardápio, conferir acesso, reservar, pedir orçamento, telefonar ou iniciar uma conversa. Se o botão não recebe foco, o formulário não explica o erro, a imagem contém todo o texto ou o PDF não pode ser lido, a próxima ação deixa de existir para parte do público.

Na análise de André Deveza, acessibilidade digital deve ser tratada como qualidade operacional. Ela conecta conteúdo, design, desenvolvimento e atendimento. Não é decoração, favor nem recurso separado para um grupo abstrato; é a disciplina de oferecer caminhos compreensíveis e utilizáveis em condições humanas diferentes.

Lei, padrão técnico e limite deste checklist

O artigo 63 da Lei Brasileira de Inclusão determina a acessibilidade nos sites mantidos por empresas com sede ou representação comercial no Brasil e por órgãos de governo, garantindo acesso às informações conforme boas práticas e diretrizes internacionais. A lei também prevê símbolo de acessibilidade em destaque. A aplicação jurídica a um caso concreto exige avaliação própria; este artigo não é parecer, laudo ou certificação.

A referência internacional mais usada é a WCAG, produzida pela Web Accessibility Initiative do W3C. A versão 2.2 organiza treze diretrizes em quatro princípios: o conteúdo precisa ser perceptível, operável, compreensível e robusto. Os critérios de sucesso são testáveis e divididos nos níveis A, AA e AAA. O W3C recomenda usar a versão mais recente.

O eMAG adapta recomendações de acessibilidade ao contexto do governo eletrônico brasileiro. Ele é uma referência pública útil para compreender marcação, comportamento, conteúdo, apresentação, multimídia e formulários, mas seu foco governamental não transforma uma leitura rápida em diagnóstico completo para uma empresa privada.

Use este guia para iniciar e organizar trabalho. Para declarar conformidade, responder a obrigação legal ou avaliar uma jornada complexa, defina escopo, critérios, tecnologias suportadas, amostra de páginas, testes manuais e participação de pessoas qualificadas.

Mapeie a jornada crítica antes de contar erros

A auditoria precisa cobrir o que mantém o negócio funcionando. Liste as páginas e estados da jornada: início, serviço, produto ou cardápio, localização, política, formulário, confirmação, erro, contato e conteúdo externo. Inclua versões móvel e desktop, áreas autenticadas e páginas geradas por ferramentas de terceiros.

Para uma pousada em Itaipava, a sequência pode incluir acomodação, datas, regras, acesso e reserva. Para um restaurante no Centro, cardápio, restrições alimentares, horário, localização e contato. Para um serviço B2B, escopo, prova, formulário e retorno. O teste não termina quando a página abre; termina quando a tarefa pode ser concluída.

Registre responsável e impacto de cada barreira. Um título fora de ordem importa, mas um botão de reserva inalcançável, um campo sem rótulo ou uma mensagem de erro invisível interrompem a tarefa. Prioridade nasce da combinação entre gravidade, frequência, alcance e posição na jornada — não apenas da quantidade apontada por uma ferramenta.

• Quais são as três ações mais importantes do site?
• Em quais páginas e estados elas começam e terminam?
• Que componentes pertencem a fornecedores externos?
• Quais informações só existem em imagem, vídeo ou PDF?
• Quem corrige conteúdo, design, código e atendimento?
• Como a pessoa comunica uma barreira ou pede alternativa?

Faça primeiro o teste sem mouse

Clique na barra de endereço, guarde o mouse e percorra a página com Tab e Shift+Tab. Use Enter, espaço e setas conforme o componente. O W3C orienta verificar se todos os links, botões, campos e controles de mídia podem ser alcançados, se a ordem acompanha a leitura, se o foco é visível e se não existe armadilha de teclado.

Abra e feche menu, modal, busca, seletor de data, carrossel, consentimento de cookies e formulário. Um menu que abre com Tab mas não fecha, um modal que deixa o foco escapar para o conteúdo atrás ou um calendário que só funciona por clique continuam sendo barreiras.

Não remova o contorno de foco apenas por estética. Se o estilo padrão não combina com a identidade, substitua-o por um indicador claramente visível em todos os fundos e estados. Foco não é a mesma coisa que hover: quem usa teclado precisa saber onde está antes de ativar.

1. 01

   Percorrer cabeçalho, menu, conteúdo e rodapé em ordem.

2. 02

   Confirmar que cada item interativo recebe foco perceptível.

3. 03

   Executar a ação principal somente com teclado.

4. 04

   Abrir e fechar camadas sem perder a posição.

5. 05

   Verificar que nenhum componente aprisiona o foco.

6. 06

   Repetir o fluxo nas páginas e estados críticos.

Estrutura e linguagem precisam orientar, não apenas decorar

Defina o idioma da página, use um título principal coerente e organize subtítulos por relação, não por tamanho visual. Elementos semânticos de cabeçalho, navegação, conteúdo principal e rodapé ajudam tecnologias assistivas a identificar regiões. O tutorial do W3C explica que boa estrutura também beneficia navegação por teclado, modos de leitura e compreensão cognitiva.

Um texto visualmente grande não vira título se for apenas um bloco genérico. Um botão desenhado como imagem não recebe função automática. Use o elemento HTML adequado antes de adicionar ARIA; nomes, funções e estados precisam ser expostos de forma compatível com tecnologias assistivas.

Escreva links que façam sentido fora do parágrafo. ‘Ver cardápio’, ‘consultar áreas atendidas’ e ‘pedir orçamento’ informam o destino; cinco links chamados ‘clique aqui’ exigem contexto visual. Preserve navegação e identificação consistentes entre páginas.

Texto alternativo depende da função da imagem

O W3C orienta que imagens informativas recebam uma alternativa textual que transmita a informação essencial. Uma foto de quarto pode descrever espaço e características relevantes; um gráfico precisa comunicar o dado ou oferecer equivalente próximo; uma imagem usada como botão deve nomear a ação.

Imagens puramente decorativas podem usar alternativa vazia para não criar ruído. Não escreva uma lista de palavras-chave nem comece automaticamente por ‘imagem de’. Descreva o que a pessoa precisa compreender naquele contexto. A mesma fotografia pode exigir textos diferentes se cumprir funções diferentes.

Texto incorporado dentro de card, banner ou cardápio é frágil: não responde bem a ampliação, pode ter contraste insuficiente e não fica disponível ao leitor de tela. Mantenha a informação em HTML sempre que possível. A legenda pode acrescentar autoria, local, condição ou crédito, mas não substitui a alternativa funcional.

• Informativa: descreva a informação relevante.
• Funcional: nomeie a ação ou o destino.
• Decorativa: use alternativa vazia quando não acrescenta conteúdo.
• Complexa: forneça resumo e equivalente detalhado próximo.
• Texto em imagem: publique também como texto real e legível.

Contraste, cor e ampliação precisam sobreviver ao design

Na WCAG 2.2, o critério AA de contraste mínimo pede proporção de pelo menos 4,5:1 para texto comum e 3:1 para texto grande, com exceções específicas. Não estime pelo monitor nem suponha que fonte em negrito resolve. Meça combinações reais, inclusive texto sobre fotografia, estados de botão, placeholder, aviso e link visitado.

Cor não deve ser a única forma de transmitir estado. Se campos inválidos ficam apenas vermelhos ou horários disponíveis apenas verdes, parte das pessoas perde a diferença. Acrescente texto, ícone com nome acessível, padrão ou outra indicação perceptível.

Amplie o texto a 200% e observe se conteúdo e funções continuam disponíveis. Depois reduza a largura para testar reflow e zoom. Barras horizontais, texto cortado, botão encoberto e cabeçalho fixo que ocupa quase toda a tela transformam uma preferência visual em bloqueio.

Não congele tamanhos nem impeça zoom no celular. Use espaçamento, largura de linha e hierarquia que continuem legíveis em telas pequenas e com texto maior. Acessibilidade e responsividade se encontram quando a interface se adapta sem retirar informação.

Botões e links precisam ter nome, área e estado claros

A pessoa deve distinguir link de botão pela função. Link leva a um destino; botão executa uma ação. Ambos precisam de nome compreensível e estado perceptível. Ícones isolados de telefone, menu, fechar ou WhatsApp exigem rótulo acessível quando o significado não aparece em texto.

No critério 2.5.8 da WCAG 2.2, alvos de ponteiro no nível AA têm referência mínima de 24 por 24 pixels CSS ou espaçamento suficiente, com exceções definidas. Em vez de buscar somente o limite, desenhe áreas confortáveis para toque, sobretudo em ações críticas e listas de pequenos ícones.

Evite dois controles diferentes com o mesmo nome genérico. Se a página mostra telefones de unidades distintas, identifique cada destino. Se o botão abre uma conversa, informe o canal e o que acontece; não dispare aplicativo, download ou nova janela sem contexto.

Formulários acessíveis explicam campo, formato e erro

Cada campo precisa de rótulo visível e associado ao controle. Placeholder não substitui rótulo: desaparece durante a digitação e costuma oferecer contraste fraco. Instruções, formato esperado e obrigatoriedade devem ser compreensíveis antes do erro.

Quando a validação falhar, mostre uma mensagem em texto, associe-a ao campo e permita que tecnologias assistivas percebam a mudança. ‘Algo deu errado’ não orienta correção. Diga qual campo precisa de atenção e como resolver, sem apagar respostas válidas nem obrigar o usuário a recomeçar.

Peça somente dados necessários para a próxima etapa. Campos, máscaras, CAPTCHA, upload e autenticação ampliam o risco de barreira. Ofereça alternativa quando um mecanismo depende de percepção visual, memória, transcrição ou gesto difícil. Teste o envio com teclado, leitor de tela e preenchimento automático quando aplicável.

No atendimento local, a alternativa precisa ser real. Exibir telefone ou WhatsApp não corrige um formulário inacessível se o canal também depende de áudio, resposta imediata ou aplicativo específico. Informe opções e horários, e garanta que a equipe saiba receber o contato.

Vídeo e áudio precisam funcionar além do som e da imagem

Vídeos com fala precisam de legendas sincronizadas e revisadas. Legenda automática pode acelerar produção, mas nomes, endereços, valores e termos locais exigem conferência humana. Identifique falantes e sons relevantes quando necessários à compreensão.

Transcrição ajuda quem prefere ou precisa ler e torna o conteúdo consultável. Quando informação visual importante não está no áudio — demonstração, texto na tela, ambiente ou ação — considere audiodescrição ou alternativa equivalente conforme o caso e o critério aplicável.

Não deixe reprodução automática com som surpreender o visitante. Garanta controles acessíveis por teclado, foco visível e nome compreensível. Um Reels incorporado pode continuar inacessível mesmo que a página ao redor esteja correta; ofereça o conteúdo essencial em formato textual próximo.

Cardápio, catálogo e PDF não podem ser becos sem saída

Um cardápio publicado apenas como fotografia impede busca, seleção e leitura assistiva. Um catálogo em PDF pode perder ordem, títulos, tabelas e alternativas de imagem. Não basta o arquivo abrir: o conteúdo precisa ser estruturado e a ação seguinte precisa permanecer disponível.

Publique a informação essencial em HTML sempre que possível. Para restaurante, inclua itens, descrições, preços vigentes, restrições que possam ser declaradas com segurança e forma de confirmar dúvidas. Para pousada, descreva acomodações e condições sem obrigar o visitante a ampliar um folheto. Para loja, disponibilize medidas, materiais, troca e contato em texto.

Quando o documento for necessário, crie-o com estrutura acessível, idioma, ordem de leitura, títulos, links e texto alternativo; teste-o no formato final. Mantenha também uma página que informe conteúdo, data e alternativa de contato. Um PDF visualmente bonito não deve ser o único acesso a uma informação decisiva.

Mobile não é acessível só porque cabe na tela

Teste em um aparelho real, com orientação vertical e horizontal, zoom, tamanho de fonte ampliado e conexão limitada. Observe menus, banners fixos, consentimento, teclado virtual e mensagens. Componentes que passam em uma tela larga podem se sobrepor quando o texto cresce.

A ação não deve depender de gesto complexo quando uma alternativa simples é possível. Arrastar um carrossel, manter pressionado ou realizar movimento preciso pode excluir pessoas com limitações motoras e também falhar em situações comuns, como usar o celular com uma mão.

Mapas incorporados ajudam a localizar, mas precisam de endereço textual, referência verificável e contato. Botões de rota ou chamada devem ter nomes claros. Em Petrópolis, onde acesso, distrito e entrada podem mudar a decisão, informação textual correta é parte da acessibilidade e da utilidade local.

Plataformas externas continuam dentro da experiência

Reserva, pagamento, agenda, chat, mapa e vídeo podem ser fornecidos por terceiros, mas a barreira continua sendo sentida como parte da marca. Inclua esses componentes no inventário, teste a tarefa completa e registre limitações com o fornecedor.

Quando não é possível corrigir imediatamente, ofereça alternativa equivalente e funcional, não uma promessa vaga de suporte. Informe como concluir a mesma tarefa, em que horário e por qual canal. A alternativa não pode cobrar mais, esconder condições ou exigir exposição desnecessária.

Ao contratar ferramenta ou agência, inclua requisitos de acessibilidade, critérios de aceite, correção de defeitos e responsabilidade por atualizações. Uma plataforma acessível hoje pode regredir após mudança de tema, componente ou conteúdo.

Ferramenta automática encontra sinais, não determina acessibilidade

Scanners ajudam a localizar ausência de rótulos, problemas de contraste, estrutura inválida e outros padrões detectáveis. O W3C alerta que ferramentas não verificam todos os aspectos, podem produzir resultados imprecisos e não determinam acessibilidade; julgamento humano e revisão manual continuam necessários.

Um placar alto não comprova que alguém consegue reservar, comprar ou pedir ajuda. A ferramenta pode confirmar que uma imagem tem atributo alt, mas não que o texto transmite a função. Pode encontrar um botão, mas não saber se o nome faz sentido no contexto. Use o relatório como entrada de trabalho, não como selo.

O mesmo limite vale para widgets e camadas automáticas. Um controle que muda contraste ou tamanho pode ser útil para algumas pessoas, mas não corrige estrutura, foco, rótulos, conteúdo, teclado, documento ou processo. Não anuncie conformidade somente porque instalou um botão.

Inclua pessoas e tecnologias reais na avaliação

Teste com mais de um navegador, teclado e, quando houver competência, leitores de tela e outras tecnologias assistivas. Evite concluir que uma experiência funciona com base em um único programa. Compatibilidade depende de conteúdo, código, navegador, dispositivo e ferramenta usada pela pessoa.

A participação de pessoas com deficiência encontra barreiras e prioridades que equipes homogêneas não percebem. Planeje recrutamento, tarefa, remuneração, consentimento e tratamento de dados com respeito. Não peça que uma única pessoa represente todas as deficiências ou valide o site inteiro sem escopo.

Registre a tarefa, o caminho, o bloqueio, a tecnologia e o impacto, sem transformar participantes em depoimento publicitário. A evidência serve para corrigir o produto. Depois da mudança, repita o teste no estado final e confirme que a solução não criou nova barreira.

Priorize correção pela jornada e previna regressão

Corrija primeiro bloqueios que impedem acesso, compreensão ou conclusão: navegação por teclado, foco, formulário, autenticação, compra, reserva, contato, conteúdo essencial e segurança. Depois trate barreiras de alto atrito e padrões repetidos. A ordem pode mudar conforme público, risco e serviço.

Separe conteúdo, design, desenvolvimento e fornecedor. Texto alternativo ruim pede revisão editorial; contraste pode exigir token do design system; foco e semântica chegam ao código; agenda externa exige negociação. Sem responsável, a lista vira dívida permanente.

Adicione critérios ao fluxo normal: componente novo precisa de teclado e foco; imagem pede decisão de alternativa; vídeo não publica sem legenda revisada; formulário não entra no ar sem erro testado. Automatize o que for confiável no build, mas mantenha revisão humana e teste de tarefas.

Publique um canal para reportar barreiras e informe o que a empresa consegue oferecer como alternativa. Responda com prazo de retorno realista, sem pedir diagnóstico da pessoa nem transferir a ela a responsabilidade técnica.

Uma auditoria inicial de 60 minutos

Uma hora não certifica um site, mas pode revelar bloqueios que merecem ação imediata. Escolha uma jornada crítica e use a versão pública. Preserve evidências com URL, dispositivo, navegador, passo e resultado esperado. Não faça correções isoladas antes de entender se o problema se repete no componente.

Nos primeiros quinze minutos, percorra a tarefa sem mouse. Depois, revise estrutura, títulos, idioma, links e nomes. Em seguida, confira zoom, reflow, contraste, cor e tamanho de alvos. Termine com imagens, mídia, formulário, documento e canal alternativo.

Classifique cada achado como bloqueio, dificuldade ou melhoria, e indique o critério técnico relacionado quando souber. Não invente conformidade. Se a equipe não consegue avaliar um item, registre a necessidade de especialista ou teste com usuários em vez de marcá-lo como aprovado.

1. 01

   0–15 min: concluir a tarefa principal usando apenas teclado.

2. 02

   15–25 min: revisar idioma, regiões, títulos, links e ordem.

3. 03

   25–35 min: ampliar texto, reduzir largura e verificar contraste e cor.

4. 04

   35–45 min: conferir imagens, vídeo, áudio, PDF e conteúdo incorporado.

5. 05

   45–55 min: preencher, errar, corrigir e enviar o formulário.

6. 06

   55–60 min: registrar impacto, responsável e próximo teste.

Exemplos locais sem transformar acessibilidade em slogan

Em uma pousada de Itaipava, a pessoa precisa comparar acomodações, política e acesso sem depender apenas de galeria ou motor externo. Em um restaurante, o cardápio em texto, a identificação de botões e o canal para dúvidas podem ser mais importantes do que um selo na abertura. Esses exemplos são hipotéticos, não cases da AD.

Em uma loja de moda no Bingen ou na Rua Teresa, medidas, composição, preço, estoque e troca devem ser legíveis e navegáveis; foto não substitui dado. Em um serviço no Centro, o formulário precisa explicar o que será solicitado e permitir recuperação de erro. Em todos os casos, o atendimento precisa reconhecer a alternativa publicada.

A localização também deve ser comunicada em mais de uma forma. Mapa, endereço textual, entrada, distrito, referência e telefone cumprem funções diferentes. Não prometa acessibilidade física com base apenas na presença de um atributo digital; confirme condições do local e mantenha informação atualizada.

Checklist para transformar a revisão em rotina

Acessibilidade não termina no lançamento. Conteúdo novo, campanha, plugin, integração e atualização podem reintroduzir barreiras. Faça uma revisão curta em toda publicação e uma avaliação periódica das jornadas críticas, com histórico de correções e pendências.

Comece pelos bloqueios que já consegue reproduzir, mas não limite o programa ao que a equipe enxerga. Combine padrão técnico, ferramentas, inspeção manual, teste com pessoas e governança. Quando houver obrigação, risco ou complexidade além da capacidade interna, busque profissionais qualificados.

O resultado esperado não é uma página que parece acessível. É uma pessoa conseguir encontrar informação, entender condições, escolher e contatar o negócio com autonomia. Essa é a medida que aproxima inclusão, experiência e operação.

• Jornadas e páginas críticas inventariadas.
• Idioma, regiões, títulos e HTML semântico revisados.
• Navegação completa por teclado, foco visível e sem armadilha.
• Texto legível com zoom, reflow e contraste medido.
• Cor não usada como único sinal.
• Imagens com alternativa adequada à função.
• Links, botões e alvos com nome e área compreensíveis.
• Formulários com rótulos, instruções, erros e recuperação.
• Vídeos com legendas revisadas e alternativas necessárias.
• Cardápios, catálogos e documentos disponíveis de forma utilizável.
• Integrações externas testadas até a conclusão da tarefa.
• Ferramenta automática combinada com revisão manual e humana.
• Responsáveis, prioridades, regressão e canal de feedback definidos.