Acessibilidade em sistemas web: checklist do que exigir

O sistema novo de pedidos entrou no ar, o treinamento correu bem e, na segunda semana, chega um chamado do setor financeiro: uma analista com baixa visão não consegue ler os valores da tela de conciliação, porque o cinza claro sobre o branco some no monitor dela. Na mesma semana, o supervisor do depósito reclama que o formulário de recebimento não funciona sem mouse, e o coletor de dados que a equipe usa tem só teclado.

Nenhum dos dois problemas é bug no sentido tradicional. O sistema faz o que deveria fazer, só que não para todo mundo. E corrigir depois que as telas estão prontas custa muito mais retrabalho do que ter pedido o requisito certo desde o começo.

Resposta curta: exija conformidade com a WCAG no nível AA: contraste mínimo de texto, uso completo pelo teclado com foco visível, compatibilidade com leitor de tela, zoom de 200% sem quebrar a tela e formulários com rótulos e mensagens de erro claras. Coloque esses itens no contrato como critério de aceite de cada entrega.

Acessibilidade em sistemas web significa que qualquer pessoa, inclusive quem tem deficiência visual, auditiva, motora ou cognitiva, consegue concluir as tarefas do sistema: usando só o teclado, com leitor de tela, com zoom alto ou sem depender de cor. O assunto costuma aparecer ligado a site institucional ou de órgão público. Este texto trata do outro lado: o sistema que a sua empresa contrata ou mantém, usado por funcionários, clientes e fornecedores. A ideia é traduzir a norma em itens que um gestor consegue pedir, conferir e cobrar, sem precisar ler código.

O checklist rápido: o que exigir de qualquer sistema web

Se você só tiver tempo para uma seção, é esta. A referência internacional para acessibilidade digital é a WCAG (Diretrizes de Acessibilidade para Conteúdo Web), organizada em três níveis: A, AA e AAA. A versão mais recente publicada é a 2.2. O nível AA é o alvo usual de mercado e o que faz sentido pedir para um sistema de gestão ou um portal. Em termos práticos, ele se traduz assim:

Esses dez itens não cobrem a WCAG inteira, mas pegam os problemas que mais travam o uso de um sistema corporativo.

Acessibilidade não é só para sites públicos

A associação automática entre acessibilidade e site de governo leva muita empresa a ignorar o tema no sistema interno. É um erro por três motivos.

Primeiro, o sistema interno é usado o dia inteiro. O ERP, o portal do cliente e a intranet são a ferramenta de trabalho de alguém por oito horas. Uma barreira pequena repetida centenas de vezes por dia vira perda de produtividade e erro de digitação.

Segundo, a lei brasileira não faz essa distinção de forma simples. A Lei Brasileira de Inclusão (Lei 13.146/2015) trata de acessibilidade em sítios da internet mantidos por empresas, e as regras de inclusão de pessoas com deficiência no trabalho tornam a ferramenta de trabalho parte do assunto. No campo técnico, a ABNT publicou em 2025 a NBR 17225, norma brasileira de requisitos de acessibilidade para conteúdo e aplicações web, que segue a mesma lógica da WCAG. A extensão exata das obrigações para o seu caso é pergunta para o jurídico. O ponto para o gestor é que acessibilidade não é opcional só porque o sistema fica atrás de um login.

Terceiro, corrigir fica mais difícil com o tempo. Contraste, teclado e rótulos são simples de fazer certo quando o componente nasce. Quando a mesma tabela foi copiada para quarenta telas, corrigir vira projeto.

Num portal do colaborador ou intranet, por exemplo, a regra é ainda mais clara: se a ferramenta é o canal oficial de comunicação, holerite e solicitações de RH, ela precisa funcionar para todos os funcionários, não para a maioria.

Quem é afetado: muito mais gente do que parece

Quando se fala em acessibilidade, a imagem que vem é a de uma pessoa cega usando leitor de tela. Ela é parte do público, mas está longe de ser o todo. Pense nos perfis que existem em qualquer empresa média:

• Baixa visão e daltonismo. Pessoas que usam zoom alto, que não distinguem verde de vermelho ou que precisam de contraste maior. Um painel em que "atrasado" é vermelho e "no prazo" é verde, sem texto, é ilegível para elas.
• Visão que muda com a idade. O diretor de 58 anos que aumenta a fonte do celular também aumenta o zoom do navegador. Se o layout quebra em 150%, ele desiste da tela.
• Limitações motoras, permanentes ou temporárias. Tendinite, punho imobilizado, tremor. Para quem não usa mouse bem, navegação por teclado é a diferença entre trabalhar e pedir ajuda.
• Deficiência auditiva. Vídeos de treinamento sem legenda e alertas que só emitem som deixam essa pessoa de fora. Todo aviso sonoro precisa de um equivalente visual na tela.
• Dificuldades cognitivas e de leitura. Mensagens de erro técnicas, formulários longos sem divisão e prazos curtos de sessão afetam quem tem TDAH, dislexia ou simplesmente está cansado no fim do turno.
• Contexto de uso. O conferente com luvas e coletor, o vendedor no celular sob sol forte. Não têm deficiência, mas se beneficiam das mesmas soluções.

Por isso acessibilidade bem feita aparece como melhora de usabilidade para todos: menos erro, menos chamado de suporte.

Contraste, tamanho de texto e cores

É o grupo mais fácil de verificar e o mais violado, quase sempre por decisão estética.

Contraste mínimo

A WCAG nível AA pede contraste de pelo menos 4,5:1 entre texto comum e fundo, e 3:1 para texto grande e para elementos gráficos que transmitem informação, como bordas de campo e ícones. O erro típico é o texto cinza claro no texto de exemplo dentro do campo, rodapé de tabela e rótulo secundário. Fica elegante no protótipo e invisível no monitor antigo do almoxarifado.

Zoom e texto redimensionável

O sistema deve continuar usável com o zoom do navegador em 200%. Isso significa que menus não se sobrepõem, botões não somem para fora da tela e tabelas largas ganham rolagem própria em vez de cortar colunas.

Cor como única informação

Status de pedido, prioridade de chamado, situação de boleto: tudo isso costuma ser codificado por cor. A regra é simples: a cor pode reforçar, mas nunca ser a única pista. "Pago" em verde com a palavra "Pago" escrita funciona. Uma bolinha verde sozinha, não.

Navegação por teclado e leitores de tela

Aqui estão os problemas que realmente impedem alguém de usar o sistema, não só dificultam.

Teclado em tudo

Qualquer ação possível com o mouse precisa ser possível com o teclado: abrir menu, escolher data, selecionar linha de tabela, fechar janela modal, arrastar cartão de um quadro. Os vilões costumam ser componentes personalizados, como seletor de data, combo com busca e quadro estilo kanban.

Três pontos que vale pedir explicitamente:

• Ordem de foco lógica. O Tab percorre a tela na ordem em que se lê, não pula do cabeçalho para o rodapé e volta.
• Foco visível. O elemento selecionado tem destaque claro. Muitos sistemas removem o contorno padrão do navegador por estética e não colocam nada no lugar.
• Sem armadilha de foco. Ao abrir uma janela modal, o foco vai para ela; ao fechar, volta para onde estava. O usuário nunca fica preso num componente sem saída pelo teclado.

Leitor de tela

O leitor de tela lê a interface em voz alta. Para funcionar, o sistema precisa expor a estrutura certa:

• Botões e links com nome. Um ícone de lixeira sem texto é lido como "botão", e o usuário não sabe o que ele faz. Precisa ser lido como "Excluir pedido 1042".
• Títulos reais. A página usa marcação de título de verdade, para que o usuário pule de seção em seção.
• Tabelas com cabeçalho. Ao ler uma célula, o leitor anuncia a coluna e a linha correspondentes.
• Mensagens dinâmicas anunciadas. "Pedido salvo" ou "Erro ao gravar" que aparecem por alguns segundos no canto da tela precisam ser comunicados ao leitor, não só exibidos.

Formulários, erros e mensagens claras

Sistema de gestão é, em boa parte, formulário. É onde a acessibilidade mais se confunde com qualidade de produto.

• Todo campo tem rótulo visível e associado. O texto de exemplo dentro do campo não é rótulo: some quando a pessoa começa a digitar e muitas vezes tem contraste baixo.
• Campos obrigatórios identificados por texto, não só por asterisco vermelho.
• Erro explica o que fazer. "Valor inválido" não ajuda. "CNPJ deve ter 14 caracteres; você digitou 13" ajuda. A mensagem fica ao lado do campo e é anunciada ao leitor de tela.
• O formulário não apaga o que foi digitado quando dá erro na validação.
• Prazos de sessão com aviso. Se a sessão expira, o usuário recebe um aviso antes e pode estender. Perder um cadastro de vinte campos por inatividade afeta todo mundo, mas afeta mais quem digita devagar.
• Confirmação antes de ações irreversíveis, como excluir, cancelar nota ou enviar pagamento.

Como testar sem ser especialista

Uma auditoria completa exige experiência, mas o responsável de TI consegue fazer uma triagem rápida que revela boa parte dos problemas. Escolha as três tarefas mais frequentes do sistema (por exemplo, lançar um pedido, consultar um cliente e aprovar uma despesa) e siga este roteiro:

1. Teste do teclado. Desconecte o mouse e execute cada tarefa só com Tab, Shift+Tab, Enter, Espaço e setas. Anote onde travou e onde você perdeu o foco de vista.
2. Teste do zoom. Coloque o navegador em 200% e repita. Anote o que sobrepôs, sumiu ou exigiu rolagem lateral na página inteira.
3. Teste do contraste. Use uma extensão gratuita de verificação de acessibilidade ou a ferramenta de inspeção do próprio navegador, que mostra a razão de contraste de cada texto.
4. Teste do formulário vazio. Envie cada formulário sem preencher nada e depois com dados errados. Leia as mensagens como se você fosse um funcionário novo.
5. Teste do leitor de tela. Ative o NVDA no Windows ou o VoiceOver no Mac e tente achar um botão específico. Se você não entende o que é cada ícone, o usuário real também não.
6. Varredura automática. Ferramentas automáticas, inclusive as que vêm no navegador, apontam rótulos ausentes, contraste baixo e estrutura errada. Elas pegam só uma parte dos problemas, por isso não substituem os testes manuais acima.
7. Teste com quem usa. Se há na equipe alguém que usa leitor de tela, zoom alto ou navega por teclado, convide essa pessoa para usar o sistema por uma hora.

O resultado é uma lista priorizada: primeiro o que impede a tarefa, depois o que dificulta.

Como pedir acessibilidade no contrato

Requisito que não está escrito vira discussão na entrega. Se você está avaliando fornecedores, inclua acessibilidade entre os critérios de como escolher uma software house e pergunte como ela trata o tema hoje, com exemplos de componentes e de testes. Na proposta e no contrato, peça de forma verificável:

• Nível de conformidade alvo: WCAG nível AA, na versão vigente na data do contrato, para as telas definidas no escopo.
• Critério de aceite: cada entrega passa pelo roteiro de teclado, zoom e contraste antes de ser homologada, e o resultado vai junto com a entrega.
• Componentes reutilizáveis acessíveis: botões, campos, tabelas, modais e seletores são construídos uma vez, de forma acessível, e reaproveitados em todo o sistema. Isso evita corrigir a mesma coisa em quarenta lugares.
• Exceções documentadas. Se alguma parte não atende, como um componente de terceiros ou um gráfico complexo, isso fica registrado com a alternativa oferecida.
• Tratamento como defeito. Barreira encontrada depois da entrega é corrigida como bug, dentro da garantia.

Para sistemas que já existem, a abordagem é outra: em vez de reescrever, faça a triagem descrita acima, priorize as telas mais usadas e inclua a correção no ciclo de manutenção evolutiva. Cada componente corrigido melhora todas as telas que o usam. Quando a tela inteira está datada, dá para modernizar a interface do sistema antigo sem trocar o núcleo.

Perguntas frequentes

O que é WCAG e qual nível pedir para um sistema da empresa?

A WCAG é a referência internacional de acessibilidade digital: as Diretrizes de Acessibilidade para Conteúdo Web, organizadas nos níveis A, AA e AAA. Para um sistema de gestão, portal ou intranet, o alvo usual de mercado é o nível AA, na versão vigente na data do contrato. A versão mais recente publicada é a 2.2.

Empresa privada é obrigada a ter sistema acessível?

Depende do caso, e a resposta exata cabe ao jurídico. A Lei Brasileira de Inclusão (Lei 13.146/2015) trata de acessibilidade em sites mantidos por empresas, e as regras de inclusão de pessoas com deficiência no trabalho alcançam a ferramenta usada pelo funcionário. Por isso, um sistema atrás de login não fica automaticamente fora da obrigação.

Ferramenta automática de acessibilidade basta para validar o sistema?

Não. A varredura automática aponta rótulos ausentes, contraste baixo e estrutura errada, mas pega só uma parte dos problemas de acessibilidade. Navegação pelo teclado, ordem de foco, clareza das mensagens de erro e uso real com leitor de tela exigem teste manual, de preferência com alguém da equipe que usa esses recursos no dia a dia.

Dá para tornar acessível um sistema que já está em uso?

Sim, sem reescrever o sistema. O caminho é fazer uma triagem das tarefas mais usadas, montar uma lista priorizada começando pelo que impede a tarefa e incluir as correções na manutenção evolutiva. Cada componente corrigido, como uma tabela ou um seletor de data, melhora todas as telas que o usam. O prazo é definido depois do diagnóstico.

Acessibilidade deixa o desenvolvimento do sistema mais caro?

Pouco, quando a acessibilidade entra como requisito desde o início. Contraste, teclado e rótulos são simples de fazer certo quando o componente nasce e é reaproveitado em todo o sistema. O esforço grande aparece quando o tema fica para depois: a mesma tabela copiada para dezenas de telas transforma uma correção simples em projeto de retrabalho.

Como a Pervian Tech trabalha acessibilidade

Na Pervian Tech, acessibilidade entra no projeto como requisito desde o início, e não como uma etapa no fim. Começamos pelo diagnóstico: quem usa o sistema, em quais equipamentos e contextos, quais tarefas são críticas e, se o sistema já existe, onde estão as barreiras hoje. Esse diagnóstico inicial é gratuito.

A partir dele, os componentes de interface são construídos acessíveis e reaproveitados, e cada entrega passa pelos testes de teclado, zoom, contraste e leitor de tela antes da homologação. Em sistemas legados, montamos uma lista priorizada e encaixamos as correções na evolução normal do produto, sem parar o planejamento do produto. Saiba mais sobre como desenvolvemos sistemas e plataformas web sob medida e veja outros textos sobre o tema em plataformas web.

O prazo depende do tamanho do sistema e do ponto de partida, e é definido depois do diagnóstico. O investimento é sob consulta, porque cada sistema tem um número diferente de telas, componentes e perfis de usuário. Se o seu sistema tem telas que parte da equipe não consegue usar direito, conte como ele funciona hoje.