Recursos de acessibilidade

Uma breve história da acessibilidade na web

Muito antes de existir a web, a legislação federal dos EUA já havia começado a construir o arcabouço jurídico no qual a acessibilidade mais tarde se apoiaria. A Seção 504 da Lei de Reabilitação de 1973 proibiu a discriminação com base em deficiência por qualquer programa que recebesse assistência financeira federal, mas o regulamento de aplicação só foi assinado em 28 de abril de 1977, e apenas depois da famosa ocupação da 504, na qual ativistas dos direitos das pessoas com deficiência ocuparam um prédio federal em San Francisco por 25 dias, a mais longa ocupação não violenta de um prédio federal na história dos EUA. A Seção 508 da mesma lei foi acrescentada por emenda em 1986, mas não tinha dentes para ser aplicada; a versão substancialmente revisada a que os profissionais se referem hoje foi promulgada em 1998 como parte do Workforce Investment Act, exigindo que as agências federais dos EUA tornassem acessível sua tecnologia eletrônica e de informação. A Lei dos Americanos com Deficiência, de 1990 (ADA), é o estatuto de direitos civis mais amplo que proíbe a discriminação por deficiência, e é a ADA (não a Seção 508) que é invocada nos processos contra sites do setor privado.

O W3C lançou a Web Accessibility Initiative (WAI) em 1997 para coordenar o trabalho de acessibilidade na web em toda a comunidade que define padrões. A formulação de Tim Berners-Lee (de que o valor da web repousa na universalidade, e que o acesso por todos, independentemente de deficiência, é essencial) tornou-se a premissa fundadora da WAI.

A linha do tempo das versões da WCAG

• WCAG 1.0: Recomendação do W3C, 5 de maio de 1999. Organizou as orientações de acessibilidade em torno de 14 diretrizes, com pontos de verificação classificados como Prioridade 1, 2 ou 3 (os níveis de conformidade A, AA e AAA herdam desse esquema). Firmemente orientada ao HTML e à pilha de tecnologias da web do fim dos anos 1990.
• WCAG 2.0: Recomendação do W3C, 11 de dezembro de 2008. Reorganizou todo o arcabouço em torno dos quatro princípios POUR. Introduziu o modelo de conformidade em três níveis ainda vigente (A / AA / AAA). Adotada como ISO/IEC 40500:2012 em outubro de 2012.
• WCAG 2.1: Recomendação do W3C, 5 de junho de 2018. Acrescentou 17 novos critérios de sucesso voltados a usuários de dispositivos móveis (orientação da tela, gestos de ponteiro, acionamento por movimento), usuários com baixa visão (reflow a 320 pixels CSS, contraste não textual de 3:1 para componentes de interface, tolerância no espaçamento de texto) e pessoas com deficiências cognitivas e de aprendizagem (finalidade de campo para preenchimento automático, ajuda em tempos limite). A «WCAG 2.1 AA» continua sendo o padrão mais citado na legislação de acessibilidade do mundo todo.
• WCAG 2.2: Recomendação do W3C, 5 de outubro de 2023, com atualizações editoriais de manutenção publicadas em dezembro de 2024. Acrescentou nove novos critérios de sucesso, incluindo Foco não obscurecido (2.4.11/2.4.12), Movimentos de arrastar (2.5.7), Tamanho mínimo de alvo (2.5.8, ao menos 24×24 pixels CSS), Ajuda consistente (3.2.6), Entrada redundante (3.3.7) e Autenticação acessível (3.3.8/3.3.9, em que os fluxos de login não podem exigir CAPTCHAs de quebra-cabeça sem uma alternativa acessível). Removeu o critério obsoleto 4.1.1 Parsing. Esta é a versão publicada atual.
• WCAG 3.0: ainda um rascunho de trabalho (Working Draft). Projetada com um modelo de pontuação mais flexível e um escopo mais amplo (aplicativos, ferramentas de autoria, plataformas de publicação, tecnologias emergentes). O W3C é claro ao dizer que a WCAG 3 não substituirá a WCAG 2 de imediato: a WCAG 2 continuará a ser mantida por vários anos depois de a 3 ser finalizada. Os profissionais que redigem declarações de acessibilidade em 2026 ainda devem fazer referência à WCAG 2.2 (ou 2.1) como o padrão vigente.

Os quatro princípios POUR em linguagem simples

Perceptível pergunta: o usuário consegue de fato captar o que está na tela? Uma fotografia sem texto alternativo não é perceptível para quem usa um leitor de tela. Um vídeo sem legendas não é perceptível para quem é surdo. Texto em cinza-escuro de 9 pontos sobre um cinza um pouco menos escuro não é perceptível para muitas pessoas com baixa visão. «Perceptível» não quer dizer «bonito», quer dizer «a informação está presente de uma forma que os sentidos e as ferramentas deste usuário conseguem captar?».

Operável pergunta: o usuário consegue de fato usar a interface? Um site que exige passar o mouse por cima (hover) não é operável para quem usa teclado ou toque. Um tempo limite de 60 segundos não é operável para quem precisa de mais tempo para ler. Um modal que prende o foco do teclado sem saída não é operável.

Compreensível pergunta: o usuário consegue entender o que está acontecendo? Um formulário que diz apenas «Erro 47» e nada mais não é compreensível. Uma página em que a navegação se reorganiza de forma diferente a cada visita não é compreensível.

Robusto pergunta: o conteúdo continuará funcionando à medida que os agentes de usuário e as tecnologias assistivas evoluírem? Componentes personalizados que não expõem papéis, nomes e estados adequados à árvore de acessibilidade falham nesse princípio. O conselho prático mais comum: prefira elementos HTML padrão a widgets personalizados em JavaScript sempre que possível; quando você de fato construir widgets personalizados, siga os padrões ARIA documentados pelo W3C.

WAI-ARIA, o complemento para aplicações ricas

A WAI-ARIA é uma especificação separada do W3C que define papéis, estados e propriedades que o HTML pode carregar para comunicar às tecnologias assistivas a finalidade e o estado atual de componentes dinâmicos de interface. A ARIA é necessária porque o HTML sozinho não consegue descrever padrões modernos como abas, caixas de diálogo, combo-boxes de autocompletar, visões em árvore e regiões dinâmicas (live regions) que se atualizam sem recarregar a página. Linha do tempo das versões: WAI-ARIA 1.0, Recomendação de 20 de março de 2014; 1.1 em 14 de dezembro de 2017; 1.2 em 6 de junho de 2023, a versão atual. As cinco «regras de uso da ARIA» se resumem a: prefira o HTML nativo; não altere a semântica de elementos existentes; garanta a operabilidade por teclado; nunca esconda das tecnologias assistivas elementos que podem receber foco; e sempre dê a cada elemento interativo um nome acessível.

O panorama jurídico, jurisdição por jurisdição

Nos Estados Unidos, os processos de acessibilidade na web são movidos quase inteiramente sob o Título III da ADA. Dois casos definiram o panorama moderno. National Federation of the Blind v. Target Corp. (protocolado em 7 de fevereiro de 2006, encerrado em acordo em agosto de 2008 por US$ 6 milhões mais US$ 3,7 milhões de honorários advocatícios) foi a primeira grande ação coletiva de acessibilidade na web dos EUA. Robles v. Domino's Pizza: decisão do Nono Circuito em 15 de janeiro de 2019; a Suprema Corte recusou-se a julgar o recurso em 7 de outubro de 2019, confirmando que a ADA alcança qualquer plataforma on-line de uma empresa dos EUA com locais físicos. O resultado foi um aumento sustentado no número de processos: 4.187 processos federais de acessibilidade digital em 2024, com mais de 4.000 por ano desde 2021. Cerca de um quarto dos casos de 2024 envolveu empresas que já haviam sido processadas antes. Notavelmente, mais de 1.000 dos réus de 2024 já tinham instalado um «widget de acessibilidade» (os scripts em estilo de sobreposição muito divulgados para pequenas empresas) que não evitou o processo.

Em abril de 2024, o Departamento de Justiça dos EUA finalizou uma regra há muito esperada que aplica o Título II da ADA ao conteúdo web e aos aplicativos móveis dos governos estaduais e locais. A regra foi publicada no Federal Register em 24 de abril de 2024 e adotou a WCAG 2.1 Nível AA como padrão técnico. Em abril de 2026, o DOJ prorrogou os prazos originais em um ano por meio de uma Regra Final Provisória (Interim Final Rule): as grandes entidades públicas agora têm até 26 de abril de 2027, e as pequenas entidades até 26 de abril de 2028.

O European Accessibility Act é a Diretiva (UE) 2019/882, adotada em abril de 2019. Os Estados-membros tiveram de transpô-la para a legislação nacional até 28 de junho de 2022, e os requisitos substantivos de acessibilidade começaram a valer em 28 de junho de 2025. A EAA abrange uma ampla gama de produtos e serviços de consumo colocados no mercado da UE: computadores e sistemas operacionais, smartphones e tablets, leitores de e-book, caixas eletrônicos e máquinas de bilhetagem/check-in, sites de comércio eletrônico, serviços bancários, e-books, serviços de mídia audiovisual e informações de transporte de passageiros. As microempresas (menos de 10 funcionários, faturamento inferior a € 2 milhões) que prestam serviços estão isentas. O padrão técnico harmonizado é a EN 301 549, publicada em conjunto por CEN, CENELEC e ETSI; a versão atual, 3.2.1 (março de 2021), incorpora o texto completo da WCAG 2.1.

Outros arcabouços nacionais significativos: a AODA de Ontário (Accessibility for Ontarians with Disabilities Act), promulgada em 2005 com a meta declarada de acessibilidade plena até 2025; o RGAA da França (Référentiel Général d'Amélioration de l'Accessibilité) v4.1.2 (2022), um conjunto de 106 critérios técnicos mapeados para a WCAG 2.1 AA, com multas substanciais por descumprimento para o setor público e grandes empresas privadas (faturamento anual de € 250 milhões ou mais).

Quem realmente usa o seu site: o panorama das tecnologias assistivas

Os dados mais confiáveis sobre combinações de leitor de tela e navegador vêm da WebAIM Screen Reader User Survey. A edição mais recente, a Survey #10, foi realizada em dezembro de 2023 e janeiro de 2024 e reuniu 1.539 respostas válidas. Números de destaque: como leitor de tela principal, JAWS 40,5%, NVDA 37,7%, VoiceOver 9,7%. Como «o mais usado no geral» (múltipla escolha), NVDA 65,6%, JAWS 60,5%, VoiceOver 43,9%: cerca de 71,6% dos respondentes usam mais de um leitor de tela. As combinações mais comuns são JAWS + Chrome (24,7%), NVDA + Chrome (21,3%), JAWS + Edge (11,4%), NVDA + Firefox (10,0%) e VoiceOver + Safari (7,0%).

• JAWS (Job Access With Speech), leitor de tela comercial para Windows, lançado originalmente em 1989 por Ted Henter pela Henter-Joyce, hoje parte da Vispero. Dominante em empresas e no governo dos EUA.
• NVDA (NonVisual Desktop Access), principal leitor de tela gratuito e de código aberto para Windows, lançado pela primeira vez em abril de 2006 por Michael Curran e James Teh (ambos cegos). A organização sem fins lucrativos NV Access foi criada no início de 2007. O crescimento do NVDA foi a tendência mais marcante no mercado de leitores de tela na última década.
• VoiceOver: integrado aos sistemas operacionais da Apple. Estreou no Mac OS X 10.4 Tiger (2005); foi adicionado ao iOS com o iPhone 3GS (2009). Hoje vem no macOS, iOS, iPadOS, tvOS e watchOS.
• TalkBack: o leitor de tela integrado equivalente no Android, mantido pelo Google.

Outras tecnologias assistivas no ecossistema mais amplo: ampliadores de tela (ZoomText para Windows, o ampliador integrado do macOS), softwares de reconhecimento de fala (Dragon NaturallySpeaking), dispositivos de acesso por acionadores para usuários com controle motor limitado, teclados alternativos e ponteiros de cabeça, sistemas de rastreamento ocular e linhas braille atualizáveis. Os critérios da WCAG contemplam todas elas, mesmo quando a página só pensa nos leitores de tela.

Contraste de cor: o modelo da WCAG 2 e o candidato APCA

A WCAG 2.x mede o contraste como uma razão de luminância entre duas cores, um número que vai de 1:1 (sem contraste) a 21:1 (branco puro sobre preto puro). Os limiares: Nível AA, texto normal 4,5:1; texto grande (18 pt ou 14 pt em negrito) 3:1; Nível AAA, texto normal 7:1; texto grande 4,5:1. O §1.4.11 Contraste Não Textual da WCAG 2.1 acrescentou uma exigência de 3:1 no nível AA para componentes de interface e objetos gráficos que transmitem informação.

O modelo de razão de luminância tem fraquezas conhecidas, em particular o fato de superestimar o contraste percebido de cores escuras: um par de 4,5:1 com duas cores escuras pode ser funcionalmente ilegível mesmo passando tecnicamente. O APCA (Accessible Perceptual Contrast Algorithm), desenvolvido por Andrew Somers, é um substituto baseado na percepção, projetado para telas autoiluminadas. É o método de contraste candidato para a WCAG 3.0, e não faz parte de nenhuma versão publicada da WCAG no momento. O APCA produz um número com sinal em uma escala de aproximadamente -108 a +108 (negativo quando texto claro fica sobre um fundo escuro). Os profissionais que publicarem em 2026 ainda devem testar com base nas razões da WCAG 2.x como exigência legal, tratando as pontuações do APCA como verificações perceptuais complementares de sanidade.

O estado da área, em números

O retrato anual mais citado é o relatório WebAIM Million, que desde 2019 roda verificações automáticas de acessibilidade nas páginas iniciais do um milhão de sites mais acessados do mundo. A edição WebAIM Million 2026, publicada em março de 2026, é a mais recente no momento em que isto é escrito. 95,9% das páginas iniciais tinham falhas de WCAG 2 detectadas (ante 94,8% em 2025, a primeira reversão de uma tendência de melhora que durava seis anos). A página média tinha 56,1 erros de acessibilidade detectados, um aumento de 10,1% ano a ano. Os seis tipos de erro mais comuns respondem por cerca de 96% de todos os problemas detectados:

1. Texto de baixo contraste: 83,9% das páginas, em média ~34 ocorrências por página
2. Texto alternativo ausente em imagens, 53,1%
3. Rótulos de formulário ausentes: 51,0%
4. Links vazios: 46,3%
5. Botões vazios: 30,6%
6. Declaração de idioma do documento ausente: 13,5%

Para contextualizar: 1,3 bilhão de pessoas no mundo todo, cerca de 16% da população global, ou aproximadamente 1 em cada 6, vivem com uma deficiência significativa, segundo a ficha informativa da Organização Mundial da Saúde atualizada pela última vez em 7 de março de 2023.

De onde vêm os recursos deste diretório

O diretório acima reúne o pequeno número de organizações e projetos que efetivamente definem a área:

• W3C Web Accessibility Initiative (WAI). O próprio órgão de padronização. Os dois grupos de trabalho mais ativos para as equipes de sites são o Accessibility Guidelines Working Group (que mantém a WCAG) e o ARIA Working Group (que mantém a WAI-ARIA). A WAI publica páginas de visão geral, especificações técnicas aprofundadas, a Quick Reference e cursos educativos gratuitos no edX.
• WebAIM (Web Accessibility In Mind). Fundada em 1999 no Center for Persons with Disabilities da Utah State University. Opera a ferramenta de avaliação WAVE, conduz a Screen Reader User Survey e a WebAIM Million, e publica uma das bibliotecas mais consultadas de artigos práticos de acessibilidade na web.
• Deque Systems. Fundada em 1999, com sede em Herndon, Virgínia. Publicadora do mecanismo de regras axe-core, cujo código abriu em junho de 2015. A Deque também mantém a Deque University e produz a extensão de navegador axe DevTools, que hoje é o testador automático padrão da indústria.
• A11Y Project. Um recurso e uma biblioteca de padrões de código aberto, conduzidos pela comunidade, fundados em 2013. Mais conhecido por sua lista de verificação de acessibilidade amplamente compartilhada; o site inteiro está no GitHub para contribuição da comunidade.
• International Association of Accessibility Professionals (IAAP). Entidade profissional fundada em 19 de março de 2014, que se tornou uma divisão da G3ict em julho de 2016. Administra as certificações reconhecidas da indústria (CPACC, WAS, CPWA, ADS).
• MDN Web Docs. A referência da Mozilla para desenvolvedores, incluindo a seção de acessibilidade mantida que documenta ARIA, semântica e padrões de acessibilidade do ponto de vista da implementação por desenvolvedores.

Juntando tudo isso: a resposta prática para «com qual padrão devo estar em conformidade» em 2026 é a WCAG 2.1 AA como piso (porque a maioria das leis ainda a cita) e a WCAG 2.2 AA como o alvo voltado para o futuro. A resposta prática em ferramentas de teste é o axe DevTools para a automação, mais um leitor de tela de verdade (NVDA + Chrome no Windows, VoiceOver + Safari no macOS) para as partes que nenhuma ferramenta automática consegue captar; a própria Deque descreve o axe como capaz de detectar «até 80% dos problemas», e a maioria das estimativas independentes situa a detecção automática em 30-50% da conformidade total com a WCAG. O teste manual com um leitor de tela de verdade ainda é necessário.