Acessibilidade digital
Por que implementar a WCAG na tecnologia
As Diretrizes de Acessibilidade para Conteúdo Web (WCAG) são o padrão internacional que define como sites, aplicativos e ferramentas digitais devem ser construídos para que possam ser usados por todas as pessoas, inclusive as com deficiência. A seguir, explicamos por que isso importa e apresentamos dois portais open source que criamos como referência prática em nível AAA.
Segundo a Organização Mundial da Saúde, cerca de 1,3 bilhão de pessoas, aproximadamente 16% da população mundial, vivem com alguma deficiência significativa. No Brasil, o IBGE estima mais de 17 milhões de pessoas com deficiência. Pessoas cegas ou com baixa visão dependem de leitores de tela, ampliação e alto contraste; pessoas com limitações motoras dependem do teclado ou de dispositivos assistivos; pessoas surdas precisam de legendas e de alternativas textuais para o áudio.
Quando uma ferramenta digital ignora a acessibilidade, ela nega autonomia, informação e participação a essas pessoas. Com o envelhecimento da população, o público beneficiado só cresce: perda de visão, audição e mobilidade aumentam com a idade. E os mesmos recursos pensados para a deficiência beneficiam todo mundo em uma tela ao sol, com as mãos ocupadas ou em uma conexão ruim, o chamado efeito do rebaixamento de guia (curb-cut effect).
Quatro razões para levar a WCAG a sério
Dignidade e direitos
Acessibilidade é inclusão e direito humano. Uma ferramenta acessível permite que a pessoa estude, trabalhe, compre e se relacione com autonomia, sem depender de terceiros.
Obrigação legal
No Brasil, a Lei Brasileira de Inclusão (Lei 13.146/2015) exige acessibilidade em sites de empresas e órgãos públicos. Nos EUA há a ADA e a Section 508; na União Europeia, a EN 301 549 e o European Accessibility Act. Ignorar isso gera risco jurídico e de imagem.
Mercado e reputação
Produtos acessíveis não excluem clientes: ampliam alcance e conversão. Acessibilidade é requisito frequente em licitações e contratos corporativos e fortalece a marca.
Qualidade técnica
HTML semântico, textos alternativos, foco visível e estrutura clara melhoram o SEO, a performance e a manutenibilidade. Construir acessível desde o início custa pouco; corrigir depois custa caro.
Os quatro princípios da WCAG
Toda a norma se organiza em quatro princípios, resumidos pela sigla POUR. Cada princípio se desdobra em diretrizes e critérios de sucesso testáveis.
Perceptível
A informação e os componentes da interface precisam ser apresentados de forma que as pessoas consigam percebê-los: alternativas em texto, legendas, contraste suficiente e conteúdo adaptável.
Operável
Todos os componentes e a navegação precisam ser operáveis por teclado, com tempo suficiente, sem conteúdo que provoque convulsões e com formas claras de localizar-se e navegar.
Compreensível
Texto legível, comportamento previsível e ajuda para evitar e corrigir erros, para que a pessoa entenda tanto o conteúdo quanto a operação da interface.
Robusto
Conteúdo interpretável por uma ampla variedade de agentes de usuário, incluindo tecnologias assistivas atuais e futuras, com uso correto de HTML e ARIA.
Níveis de conformidade
- A
- Requisitos mínimos. Sem eles, grupos inteiros de pessoas ficam impedidos de usar o conteúdo.
- AA
- Nível de referência exigido pela maioria das legislações e políticas públicas, incluindo contraste 4,5:1 e navegação consistente.
- AAA
- Nível mais alto: contraste 7:1, controle total de leitura, linguagem clara, sem limites de tempo e ajuda contextual. É o nível adotado nos dois projetos de demonstração abaixo.
Marco legal e normativo
Brasil
Lei Brasileira de Inclusão (Lei 13.146/2015, art. 63), Decreto 5.296/2004, Modelo de Acessibilidade em Governo Eletrônico (eMAG) e ABNT NBR 17060 para aplicativos móveis.
Internacional
WCAG 2.x, publicada pelo W3C e adotada como norma ISO/IEC 40500; nos EUA, ADA e Section 508; na União Europeia, EN 301 549 e o European Accessibility Act, em vigor desde 2025.
Projetos de demonstração
Dois portais open source em nível AAA
Criamos e mantemos dois portais públicos, com código aberto, para demonstrar que é possível entregar uma experiência moderna, bonita e totalmente acessível. Ambos rodam em produção, em infraestrutura própria, e servem de referência para equipes de desenvolvimento, design e QA.
DevTools Khori
Ferramentas do dia a dia de desenvolvedores, construídas como referência de acessibilidade com foco na pessoa com deficiência visual.
dev.tools.khori.com.br · github.com/khoriati/devtools-khori
O DevTools Khori é uma mini-plataforma de utilidades para desenvolvedores, arquitetos e administradores de sistemas: calculadora de programador, sub-redes IP, chmod, decodificador JWT, Base64, hashes, UUID, timestamps, formatador JSON, gerador e validador de CPF e CNPJ, WHOIS, ping, traceroute, consulta DNS, inspetor HTTP, guias rápidos de Linux, Docker, Kubernetes, ffmpeg, ImageMagick, PowerShell, Azure CLI e AWS CLI, além de um verificador de contraste WCAG e um guia de validadores de acessibilidade por linha de comando.
O projeto existe, antes de tudo, para servir de exemplo de portal acessível. Ele mostra que ferramentas técnicas, densas em informação, podem ser 100% navegáveis por teclado e leitor de tela, com contraste mínimo de 7:1, sem sacrificar uma interface moderna.
O que demonstra
- Três temas (claro, escuro e alto contraste), com contraste mínimo de 7:1 e suporte ao modo de cores forçadas do Windows
- Navegação completa por teclado, skip links, marcos semânticos e um único h1 por página
- Anúncios para leitores de tela via regiões aria-live
- Alvos de toque de pelo menos 44 px e foco nunca obscurecido pela barra fixa
- Glossário de termos e siglas (critérios 3.1.3 e 3.1.4) e largura de linha confortável (1.4.8)
- Cinco idiomas (pt-BR, en-US, es, de, fr) com o atributo lang sincronizado
- Tradução para Libras via widget VLibras quando o idioma é português
- Respeita prefers-reduced-motion e prefers-color-scheme; tipografia legível (Atkinson Hyperlegible)
Tecnologia
React 18, TypeScript, Vite e MUI no front-end; Node.js e Express no back-end com WAF de aplicação; Docker e Kubernetes com TLS automático. Testes automatizados de acessibilidade com axe-core e Playwright cobrindo todas as ferramentas.
Escopo e ressalvas
- A declaração de nível AAA cobre a interface própria do portal. O avatar VLibras é um componente de terceiros e o conteúdo técnico de leitura avançada (critério 3.1.5) ficam fora desse escopo.
- As ferramentas de dados rodam inteiramente no navegador; nada é enviado ao servidor. As ferramentas de rede rodam no back-end com validação estrita, limites de uso e mascaramento do endereço de origem.
- Os validadores automáticos citados fazem uma checagem técnica superficial e não substituem testes de QA com profissionais capacitados e pessoas com deficiência.
WCAG AAA · Demonstração de Acessibilidade
Uma aplicação que demonstra, de ponta a ponta, as melhores práticas da WCAG 2.2 no nível AAA, pensada para ser tecnicamente exemplar e agradável para qualquer pessoa.
wcag.tool.khori.com.br · github.com/khoriati/wcag-tool
O WCAG Tool percorre, seção a seção, os grupos de critérios de sucesso da WCAG 2.2: contraste reforçado, controle da leitura, operação por teclado, foco visível, prevenção de erros, componentes ARIA seguindo o guia de padrões do W3C (APG), alternativas de mídia, linguagem clara e localização. Cada seção explica o critério, mostra a implementação funcionando e aponta onde ela está no código.
Diferente de um checklist teórico, é um produto que a pessoa usuária pode ajustar ao próprio gosto: tema, contraste, tamanho de texto, espaçamento, largura de coluna, movimento e fonte, com tudo persistido no navegador e sem necessidade de login.
O que demonstra
- Contraste reforçado 7:1 em todo o tema, com modo de contraste máximo em preto e branco puros (1.4.6, 1.4.11)
- Painel de leitura: tamanho de texto, altura de linha, espaçamento e largura de coluna (1.4.8, 1.4.12, 1.4.4)
- Operação 100% por teclado com roving tabindex e foco espesso sempre visível (2.1.1, 2.1.3, 2.4.7, 2.4.12, 2.4.13)
- Formulário com revisão e prevenção total de erros (3.3.5, 3.3.6, 1.3.6)
- Abas, acordeão, diálogo modal e toasts implementados conforme o ARIA Authoring Practices Guide (4.1.2, 2.2.4, 3.2.5)
- Alternativas de mídia: transcrição, audiodescrição e legendas (1.2.6, 1.2.7, 1.2.8)
- Glossário e linguagem clara (3.1.3, 3.1.4, 3.1.6); alvos de toque generosos e localização (2.4.8, 2.5.5)
- Redução de movimento, fonte para dislexia, regiões aria-live e checklist final com todos os critérios cobertos
Tecnologia
React 19 e Vite, sem dependências de UI externas, servido por nginx em contêiner sem privilégios de root, publicado em Kubernetes com TLS automático.
Escopo e ressalvas
- Trata-se de uma aplicação demonstrativa e educacional. A conformidade WCAG é avaliada página a página e depende de auditoria manual com tecnologias assistivas; a demonstração não é um selo ou certificação.
- A estrutura foi auditada (semântica, hierarquia de títulos, marcos, nomes acessíveis, rótulos, lang e aria-live) sem problemas encontrados. Recomendamos complementar com axe DevTools, Lighthouse e testes com NVDA, VoiceOver e apenas teclado.
- A seção de mídia usa conteúdo de exemplo para ilustrar as alternativas exigidas pela norma.
Avisos importantes
- Os dois portais são projetos de demonstração e de referência, oferecidos gratuitamente e sem garantias, com código aberto para estudo, reutilização e contribuição.
- Nenhum deles exige cadastro ou login, e nenhum coleta dados pessoais para fins de rastreamento ou publicidade.
- Conformidade com a WCAG não é um estado permanente: cada nova versão de um produto precisa ser reavaliada. Use os portais como ponto de partida, não como substituto de uma avaliação profissional do seu próprio produto.
- WCAG e W3C são marcas do World Wide Web Consortium. Marcos Khoriati (Khori) não tem vínculo com o W3C; os portais implementam as diretrizes públicas da norma.
Perguntas frequentes
Quer tornar o seu produto acessível?
Avaliamos, corrigimos e capacitamos a sua equipe para entregar experiências que todas as pessoas conseguem usar.