Pular navegação
Parte II Capítulo 6

Acessibilidade

Data de publicação:
Imagem de destaque de um robô com um ícone azul de acessibilidade em forma de pessoa na parte da frente, escaneando uma página web, enquanto personagens do Web Almanac verificam alguns rótulos.
Escrito por Bogdan Lazar e Mike Gifford
Revisado por Hidde de Vries, Aidan Tierney e Scott Davis
Análise por Mike Gifford e Barry Pollard
Editado por Bogdan Lazar
Traduzido por Mark Santos

Introdução

A web está mudando rapidamente. Em 2025, a acessibilidade na web importa mais do que nunca, à medida que as tecnologias mais difundidas dependem cada vez mais de recursos inclusivos. Por exemplo, assistentes ativados por voz usam tecnologias de leitores de tela. Recursos originalmente projetados para acessibilidade, como legendas em vídeos e feedback háptico, agora são comuns.

Os princípios do Design Universal são fundamentais para o nosso trabalho no desenvolvimento web moderno. Estamos criando, cada vez mais, soluções que atendem a necessidades diversas e melhoram a experiência de todos os usuários. Como disse Sir Tim Berners-Lee em uma frase célebre: “O poder da Web está em sua universalidade. O acesso por todos, independentemente de deficiência, é um aspecto essencial.”

Eventos globais recentes e mudanças nos requisitos legais colocaram a inclusão digital em evidência. As Diretrizes de Design Inclusivo da Microsoft mostram que a acessibilidade ajuda muito mais do que apenas pessoas com deficiências permanentes. As diretrizes mencionam especificamente limitações temporárias e situacionais. Por exemplo, a possibilidade de usar um dispositivo com uma só mão pode ajudar pessoas com lesões, pais com filhos pequenos e também pessoas carregando objetos.

Em 2025, as leis de acessibilidade na web têm força de verdade. O Ato Europeu de Acessibilidade (EAA) da União Europeia (UE) é um grande avanço. Ele estabeleceu junho de 2025 como prazo para que inúmeros sites e aplicativos estivessem em conformidade com a norma EN 301 549, que faz referência às Diretrizes de Acessibilidade para Conteúdo Web (WCAG).

Os Estados Unidos também atualizaram suas regulamentações. Os sites de governos estaduais e locais agora precisam atender à WCAG 2.1, conforme exigido pelo Título II da Lei dos Americanos com Deficiência. Os dados de 2024 nos dão uma linha de base fundamental para medir o impacto concreto desses prazos na acessibilidade dos sites em todo o mundo.

O Google Lighthouse sustenta nossa análise usando o mecanismo axe-core da Deque. Comparamos os resultados de 2025 com os dados de 2024 e identificamos as principais tendências. Com a adoção mais ampla da WCAG 2.2, examinamos a adoção dos novos Critérios de Sucesso e as mudanças contínuas decorrentes de regras descontinuadas, como duplicate-id.

Nossa abordagem é semelhante à do WebAim Million, mas com diferenças nos sites rastreados e nas ferramentas de análise utilizadas. O HTTP Archive rastreia 17 milhões de sites todo mês, em páginas iniciais e secundárias, usando o Lighthouse e outras ferramentas. O WebAim analisa o primeiro milhão de páginas iniciais com o WAVE.

Testes automatizados, incluindo o axe-core, que é usado pelo Lighthouse, conseguem verificar apenas parcialmente um subconjunto dos Critérios de Sucesso da WCAG. O Alphagov, do GOV.UK, oferece uma comparação de ferramentas populares de auditoria automatizada, e todas elas detectam menos de 50% dos erros de acessibilidade. Muitos critérios não têm nenhum teste automatizado, e nem todos os problemas de acessibilidade têm critérios correspondentes na WCAG.

Mas lembre-se da Lei de Goodhart. Quando uma métrica se torna uma meta, ela deixa de ser uma métrica confiável. Uma pontuação perfeita não garante acessibilidade total. Você deve tratar as pontuações de acessibilidade do Lighthouse como um ponto de partida para a avaliação, e não como um objetivo final. Ainda assim, acompanhar essas pontuações oferece um retrato valioso do progresso geral da web.

Nosso relatório se concentra exclusivamente em HTML e não inclui PDFs nem outros documentos de escritório.

Em comparação com 2024, a pontuação mediana de Acessibilidade do Lighthouse melhorou 1%, ultrapassando 85% em 2025. Desde o primeiro Web Almanac, em 2019, temos visto um progresso constante e gradual. O Google Lighthouse atribui pesos diferentes aos problemas do axe-core, então as organizações podem priorizar as correções de formas diferentes.

Melhorias na auditoria do Lighthouse ano a ano.
Figura 6.1. Melhorias na auditoria do Lighthouse ano a ano.

Este ano, vimos os maiores avanços nos seguintes testes do axe-core:

Testes de acessibilidade do Lighthouse que mais melhoraram (axe).
Figura 6.2. Testes de acessibilidade do Lighthouse que mais melhoraram (axe).

Este ano, estamos adicionando ao Web Almanac uma nova seção sobre Inteligência Artificial (IA). A IA está mudando a forma como construímos sites, escrevemos código, geramos conteúdo, otimizamos o desempenho e interagimos com interfaces. Ela já tem um papel crescente no trabalho de acessibilidade, desde a geração de descrições de imagens e legendas até assistentes que ajudam as equipes a encontrar e corrigir problemas.

Ao mesmo tempo, a IA traz riscos e perguntas sem resposta. Ainda não há uma forma confiável de saber quando a IA criou um site ou ajudou a criá-lo. Os modelos de linguagem são treinados com código e conteúdo que frequentemente contêm problemas de acessibilidade. Descrições ou padrões automatizados podem facilmente deixar escapar o contexto, a intenção do usuário ou nuances. Preocupações mais amplas sobre uso de dados, impacto ambiental e vieses embutidos afetam diretamente quem se beneficia da IA na web e quem é prejudicado ou excluído.

O novo capítulo sobre IA explora essas tensões: como a IA já está ajudando as equipes, onde ela deixa a desejar e quais padrões, salvaguardas e práticas são necessários. Um princípio permeia toda a análise: a IA deve apoiar a expertise humana e o design inclusivo, e não substituí-los.

Ao longo deste capítulo, você encontrará links acionáveis e soluções práticas para ajudar a melhorar a acessibilidade dos seus próprios sites.

Facilidade de leitura

Os usuários precisam ler e compreender o conteúdo web com facilidade. Isso vai além de escolher fontes legíveis. Também envolve usar uma linguagem clara, organizar as páginas de forma lógica e seguir padrões de design previsíveis.

Embora este relatório se concentre em métricas técnicas mensuráveis, fatores qualitativos, como escrever em linguagem simples, importam na mesma medida. A WCAG 3.0 está explorando como incorporar requisitos de linguagem clara, mas ainda está em fase de desenvolvimento.

Assim como a linguagem simples, os números apresentam seus próprios desafios de acessibilidade. Alguns usuários têm dificuldade para interpretá-los, e os testes automatizados não conseguem identificar isso de forma confiável como uma barreira. Para lidar com isso, consulte recursos como o Accessible Numbers para obter conselhos práticos sobre como apresentar informações numéricas com clareza na web.

Existem métricas de legibilidade para conteúdo em inglês. A pontuação de legibilidade Flesch-Kincaid é um exemplo. Mas a web é global. Ela abrange muitos idiomas e públicos diversos. Nenhum teste automatizado padronizado cobre todos os casos ou idiomas.

Contraste de cores

A diferença entre as cores de primeiro plano e de fundo determina se as pessoas conseguem perceber o conteúdo web. O contraste de cores insuficiente continua sendo uma barreira comum, especialmente para usuários com baixa visão ou deficiências na visão de cores.

O contraste de cores é especialmente importante para usuários mais velhos, pessoas com deficiências temporárias, como quem está sem os óculos de leitura, e qualquer pessoa lendo sob luz solar intensa ou em ambientes desafiadores.

A WCAG exige taxas de contraste de pelo menos 4,5:1 para texto padrão e 3:1 para texto grande para alcançar a conformidade AA. A conformidade AAA exige 7:1 para texto normal. As taxas de contraste da WCAG são uma base importante, mas essas diretrizes não abordam todas as formas de daltonismo nem as variações individuais de percepção.

Outros documentos, incluindo o Accessible Perceptual Contrast Algorithm (APCA), buscam oferecer uma medição de contraste perceptualmente mais precisa.

Ferramentas de código aberto, como o recém-lançado Contrast Report, tornam mais fácil do que nunca encontrar e corrigir problemas de contraste de cores. Elas até sugerem modificações quando as cores não atingem as taxas exigidas. Para orientações adicionais, você pode consultar recursos de especialistas, como o artigo de Dennis Deacon sobre testes de contraste de cores.

Sites com contraste de cores suficiente.
Figura 6.3. Sites com contraste de cores suficiente.

Este ano, a taxa de aprovação no contraste de texto melhorou cerca de 1% em comparação com 2024. Mas apenas 31% dos sites em dispositivos móveis atendem atualmente aos requisitos mínimos de contraste de cores. Como as experiências em dispositivos móveis dependem muito de uma boa visibilidade, essa lacuna é um problema real para os usuários que acessam a web pelo celular.

Navegadores e sistemas operacionais oferecem cada vez mais suporte aos modos claro, escuro e de alto contraste. Os usuários agora têm mais controle. Ainda assim, a maioria dos sites não responde a essas preferências.

Zoom e redimensionamento

Os usuários devem poder redimensionar o conteúdo de acordo com suas necessidades. Desativar o zoom tira o controle do usuário e é uma violação direta dos requisitos de redimensionamento da WCAG. Isso é mais do que um pequeno inconveniente. Pode tornar um site completamente inutilizável para pessoas com baixa visão ou que dependem de ampliação de tela para ler.

Em 2025, esse padrão restritivo ainda aparece, muitas vezes porque os desenvolvedores querem layouts perfeitos ao pixel em dispositivos móveis. Infelizmente, isso custa caro à usabilidade e à acessibilidade.

Páginas com zoom e redimensionamento desativados.
Figura 6.4. Páginas com zoom e redimensionamento desativados.

O número de sites que desativam o zoom ou o redimensionamento continua caindo. Em 2025, apenas 19% dos sites em dispositivos móveis e 21% dos sites em desktop restringem o redimensionamento, seja usando user-scalable=no ou definindo uma escala máxima restritiva. Isso representa uma melhoria de 1–2% em relação a 2024, mostrando um progresso lento, mas constante.

Uso de unidades de fonte.
Figura 6.5. Uso de unidades de fonte.

As unidades de tamanho de fonte afetam diretamente como o texto pode responder às preferências do usuário. Unidades relativas, como em e rem, permitem que o texto seja redimensionado de forma previsível de acordo com as configurações do navegador. Em 2025, o uso de em em sites para dispositivos móveis aumentou 2%, melhorando a experiência de quem ajusta o tamanho da fonte para ler com mais facilidade. Fora isso, o uso de unidades de tamanho de fonte permanece praticamente o mesmo do ano passado.

Se você quiser verificar se o seu site está restringindo o zoom, examine o código-fonte em busca da tag <meta name="viewport">. Evite usar valores como maximum-scale, minimum-scale, user-scalable=no ou user-scalable=0, pois eles limitam o redimensionamento. Em vez disso, deixe os usuários ajustarem livremente o tamanho do conteúdo. A WCAG exige que o texto possa ser redimensionado até 200% sem perda de conteúdo ou funcionalidade.

Identificação de idioma

Declarar o idioma principal de uma página com o atributo lang é essencial. Isso permite que os leitores de tela selecionem as regras de pronúncia corretas e que os navegadores ofereçam traduções automáticas mais precisas. Além do idioma principal, é igualmente importante especificar o idioma de trechos que diferem do idioma principal. Isso garante que os leitores de tela alterem corretamente a pronúncia de palavras ou frases estrangeiras.

Apesar de ser um requisito simples de Nível A da WCAG, a declaração de idioma continua sendo uma área em que muitos sites deixam a desejar. Em 2025, cerca de 86% dos sites incluem um atributo lang válido, praticamente sem mudanças em relação a 2024. Isso sugere uma adoção estável, mas também evidencia espaço para melhorias.

A aplicação correta do atributo lang começa com a sua inclusão na tag <html> para especificar o idioma principal da página. As páginas frequentemente contêm vários idiomas. Use o atributo lang em elementos ou trechos individuais conforme necessário. A documentação do W3C sobre como especificar o idioma de partes oferece orientações detalhadas sobre esse tema.

Declarações de idioma ausentes ou incorretas podem causar erros de tradução.

Por exemplo, a tradução automática do Chrome pode interpretar mal o conteúdo de uma página sem um idioma declarado, gerando traduções confusas ou imprecisas. A marcação adequada do idioma também auxilia na estilização de idiomas escritos da direita para a esquerda e em outros comportamentos específicos de cada idioma.

Preferências do usuário

O CSS moderno inclui Media Queries de Preferência do Usuário que permitem que os sites se adaptem às configurações do sistema operacional ou do navegador do usuário. Os usuários têm uma experiência mais confortável e personalizada. Os sites podem responder a preferências de movimento, contraste e esquemas de cores.

Media queries de preferência do usuário.
Figura 6.6. Media queries de preferência do usuário.

As queries mais conhecidas, prefers-reduced-motion e prefers-color-scheme, continuam amplamente suportadas pelos navegadores. Em 2025, a adoção dessas queries pelos sites mostra poucas mudanças. No entanto, o uso de forced-colors, que oferece suporte a modos de alto contraste para usuários com baixa visão, aumentou 5%, chegando a 19%. Enquanto isso, o uso da media query obsoleta -ms-high-contrast caiu 3%, para 20%. Isso reflete uma transição gradual para os padrões modernos de CSS.

Continuar incorporando essas preferências promove a acessibilidade e a satisfação do usuário, respeitando necessidades individuais e configurações do sistema.

A implementação mais ampla da personalização por meio de media queries CSS não teve um crescimento significativo, apesar desses ganhos graduais. Incentivar uma adoção maior ajuda a garantir que os sites respeitem as preferências dos usuários, incluindo a redução de movimento para quem tem sensibilidade causada por distúrbios vestibulares e a adaptação das cores ou do contraste da tela para conforto visual.

Os usuários navegam pelos sites de formas diferentes. Alguns usam o mouse para rolar a página. Outros usam o teclado, um dispositivo de controle por acionador ou um leitor de tela para navegar pelos títulos. Um sistema de navegação eficaz deve funcionar para todos os usuários, independentemente do dispositivo de entrada.

TVs de tela larga e interfaces de voz como a Siri e a Amazon Alexa criam desafios de navegação únicos. Construir uma boa estrutura semântica em um site ajuda os usuários de leitores de tela a navegar. Também ajuda os usuários de muitos outros tipos de tecnologia.

Indicação de foco

A indicação de foco é essencial para usuários que dependem principalmente da navegação por teclado e de dispositivos assistivos para percorrer o conteúdo web. Ela fornece uma pista visual que destaca qual elemento está em foco no momento, para que os usuários entendam onde estão na página.

Ferramentas de teste automatizado, como o Google Lighthouse, conseguem identificar muitos requisitos básicos e sinalizar falhas óbvias relacionadas aos indicadores de foco. Mas elas são limitadas quando se trata de interações complexas, como armadilhas de teclado, ordem de foco e se o foco se move de forma lógica para novos conteúdos. Passar em auditorias automatizadas não garante a acessibilidade por teclado de um site nem uma boa experiência para usuários de teclado.

Testes manuais abrangentes são insubstituíveis.

Ferramentas como a extensão de código aberto Accessibility Insights for the Web utilizam o axe-core da Deque e oferecem testes manuais guiados. O recurso de visualização “Tab Stops” ajuda os testadores a ver o caminho que os usuários de teclado percorrem e a identificar com eficácia possíveis problemas, como estilos de foco ausentes ou armadilhas de foco inesperadas.

Usuários de dispositivos de navegação alternativos com habilidades motoras limitadas têm necessidades específicas relacionadas à visibilidade e à sequência do foco. Personalizar as interfaces das tecnologias assistivas ajuda a maximizar um controle adaptado às suas habilidades.

As boas práticas de teste de foco incluem:

O relatório do The A11y Collective sobre como entender os indicadores de foco oferece insights práticos para implementar e testar estilos de contorno de foco visíveis.

Estilos de foco

A WCAG determina que todo conteúdo interativo deve ter um indicador de foco claramente visível. Essa pista visual ajuda os usuários de teclado a identificar qual elemento está em foco no momento enquanto percorrem a página.

Sem um indicador de foco bem visível, os usuários de teclado e aqueles que dependem de tecnologias assistivas podem se perder facilmente. Estilos de foco robustos, como um contorno de alto contraste, são fundamentais para o design acessível. Muitas instituições, como o GOV.UK, estabeleceram padrões para indicadores de foco a fim de garantir consistência e clareza.

As anotações de design precisam especificar as interações por teclado, como Craig Abbott explicou claramente no blog da TetraLogical. Pouco depois dessa publicação, o GitHub lançou seu Annotation Toolkit de acessibilidade, abordando o mesmo problema.

Páginas que sobrescrevem os estilos de foco do navegador.
Figura 6.7. Páginas que sobrescrevem os estilos de foco do navegador.

Em 2025, 67% dos sites removeram explicitamente os contornos de foco padrão, um aumento de 14% em relação a 2024. Essa tendência preocupante pode prejudicar a acessibilidade se esses contornos não forem substituídos por estilos eficazes. Pelo lado positivo, a adoção da pseudoclasse :focus-visible cresceu. Isso significa que os desenvolvedores estão começando a criar indicadores de foco sensíveis ao contexto, visíveis apenas quando necessário.

tabindex

O atributo tabindex controla a participação de um elemento na ordem de foco do teclado. Ele permite que os desenvolvedores incluam, excluam ou reordenem elementos focáveis. O uso correto favorece a navegação lógica e a acessibilidade, e é um requisito da WCAG. O uso indevido, especialmente com valores positivos, pode atrapalhar a ordem natural de tabulação e confundir os usuários.

Uso de tabindex.
Figura 6.8. Uso de tabindex.

Em 2025, o uso de tabindex aumentou ligeiramente. Pouco mais de 50% dos sites o utilizaram, cerca de 3-4% a mais do que em 2024. O uso de tabindex positivo permanece estável e, de modo geral, baixo, refletindo a consciência contínua de que valores positivos de tabindex devem ser evitados.

Landmarks

Os landmarks estruturam uma página web em regiões temáticas distintas, usando elementos HTML nativos como <header>, <nav>, <main> e <footer>. Esses elementos criam um esboço claro e de alto nível da página, que ajuda os usuários de tecnologias assistivas a entender rapidamente o layout e a pular diretamente para as seções relevantes.

Um antipadrão comum de acessibilidade persiste quando os desenvolvedores adicionam atributos ARIA redundantes. Por exemplo, adicionar role="navigation" a um elemento <nav>. O elemento <nav> já carrega inerentemente a role de navegação, então essa duplicação polui o código sem nenhum benefício e pode confundir as tecnologias assistivas. A boa prática é priorizar os elementos nativos do HTML5 antes de adicionar roles de landmark ARIA. Essa é a principal diretriz do ARIA.

Especialistas em acessibilidade como Eric Bailey destacaram as armadilhas do uso excessivo de ARIA em contextos nos quais o HTML semântico nativo é suficiente. Os doze princípios de acessibilidade na web de Heydon Pickering também enfatizam o papel fundamental que a estrutura semântica e os landmarks desempenham na navegação acessível.

Elemento Elemento % Role % Ambos %
main 40.72% 17.81% 47.34%
header 65.99% 10.95% 67.41%
nav 67.73% 18.02% 70.94%
footer 66.38% 9.59% 67.66%
Figura 6.9. Uso de elementos e roles de landmark (desktop).
Crescimento anual de páginas com role de elemento.
Figura 6.10. Crescimento anual de páginas com role de elemento.

Em 2025, a adoção de landmarks ARIA aumentou ligeiramente, impulsionada pelo uso crescente do elemento nativo <main>, agora em 47%, um aumento de 3% em relação a 2024. Esse progresso reflete uma melhor conformidade com o HTML semântico e uma estrutura de página mais robusta para os usuários que dependem de ferramentas assistivas.

Usuários de leitores de tela frequentemente navegam por meio de “rotores” ou menus de landmarks para pular entre essas regiões da página. Skip links que apontam para landmarks melhoram a usabilidade ao permitir acesso imediato ao conteúdo principal. Eles contornam blocos repetidos de navegação ou banners. Falaremos sobre skip links em uma seção mais adiante.

A educação contínua sobre o aproveitamento dos landmarks nativos do HTML5 e a redução de roles ARIA redundantes vai melhorar ainda mais as experiências de navegação por teclado e por tecnologias assistivas. O crescimento na adoção de estrutura semântica apoia as metas de acessibilidade e alinha o conteúdo web às boas práticas modernas.

Hierarquia de títulos

Uma estrutura de títulos coerente funciona como um sumário para uma página web. Ela favorece a acessibilidade, o SEO e a compreensão do usuário. Para usuários de leitores de tela, navegar pelos títulos é uma forma essencial de encontrar informações rapidamente. Os mecanismos de busca também dependem da hierarquia de títulos para entender a organização e a relevância de uma página.

Os títulos devem comunicar a estrutura do documento, e não apenas o estilo visual. Usar tags de título como <h3> ou <h4> apenas pelo tamanho da fonte quebra a ordem lógica. Isso dificulta a navegação para usuários de tecnologias assistivas e viola o princípio de separar estrutura e apresentação. Em vez disso, os desenvolvedores devem estilizar os títulos com CSS e usar as tags de título de acordo com a hierarquia do conteúdo.

Para relembrar por que a semântica importa, leia este artigo de Jono Alderson.

Após vários anos de queda, as pontuações de hierarquia de títulos melhoraram quase 2% em 2025, indicando uma atenção renovada à estrutura correta de títulos.

59%
Figura 6.11. Sites em dispositivos móveis aprovados na auditoria do Lighthouse para títulos ordenados corretamente.

Ainda assim, o uso indevido de títulos para estilização em vez de estrutura continua comum.

Skip links são recursos de navegação que permitem que usuários de teclado e outras pessoas que usam dispositivos de entrada diferentes do mouse contornem blocos grandes e repetitivos de conteúdo, como os menus de navegação do site, e pulem diretamente para o conteúdo principal da página. Normalmente, um link “pular para o conteúdo principal” aparece como o primeiro elemento focável da página para uma navegação eficiente.

Contornar blocos de conteúdo é um requisito da WCAG, e implementações básicas continuam sendo a norma.

Existem ferramentas sofisticadas, como o SkipTo, de código aberto, do PayPal, para gerar menus dinâmicos com todos os principais landmarks e títulos de uma página. Essa interação mais rica beneficia uma variedade maior de usuários, melhorando a navegabilidade e a usabilidade em geral. Eleanor Hecks escreveu um artigo convincente sobre a importância da acessibilidade por teclado, assim como a TetraLogical.

A adoção de skip links permaneceu praticamente estável de 2024 para 2025.

24%
Figura 6.12. Páginas em dispositivos móveis e desktop que provavelmente têm um skip link.

Aproximadamente 24% das páginas em desktop e em dispositivos móveis incluem skip links detectáveis por métodos de análise comuns. Esse número pode subestimar o uso real, já que alguns skip links aparecem mais adiante na página ou apontam para landmarks além dos menus de navegação.

Crescimento anual de páginas com skip links.
Figura 6.13. Crescimento anual de páginas com skip links.

Títulos de documentos

Um <title> de página descritivo é uma necessidade básica. Ele fornece contexto para os usuários que navegam entre abas e janelas do navegador e costuma ser a primeira informação anunciada por um leitor de tela, ajudando os usuários a se orientarem. A WCAG também determina que toda página deve ter um título significativo.

Estatísticas do elemento title.
Figura 6.14. Estatísticas do elemento title.

Os dados de 2025 mostram uma ligeira melhora na presença e na descritividade dos títulos de documentos em comparação com os anos anteriores. Aproximadamente 98% dos sites agora incluem um elemento <title>, um aumento de 1% em relação a 2024.

Isso é positivo. Mas, apesar dessa alta taxa de inclusão, muitos títulos continuam insuficientemente descritivos. Isso afeta a usabilidade, especialmente para usuários de leitores de tela, que dependem de títulos claros para se orientar.

Houve uma queda de 2% nos sites em dispositivos móveis com títulos de quatro ou mais palavras, o que pode indicar títulos mais curtos ou menos específicos nas páginas para dispositivos móveis. Incluir tanto uma breve descrição do conteúdo da página quanto o nome do site continua sendo a boa prática para melhorar a navegação e o contexto.

Os títulos de documentos continuam sendo um recurso fundamental de acessibilidade que beneficia todos os usuários. Eles fornecem contexto ao navegar entre abas e janelas do navegador. Embora estejam presentes de forma quase universal, melhorar a descritividade e a consistência dos títulos continua sendo um foco importante em 2025 e nos anos seguintes.

Tabelas

As tabelas HTML apresentam dados em uma grade bidimensional. A acessibilidade depende de estruturá-las com os elementos semânticos apropriados. Usar <caption> fornece um contexto crucial para usuários de leitores de tela, enquanto os elementos <th> definem cabeçalhos para linhas e colunas, ajudando os usuários a entender as relações dentro dos dados. A ferramenta de Steve Faulkner, lançada em 2025, pode ajudar os desenvolvedores a inspecionar rapidamente a semântica de qualquer elemento HTML.

O uso de <caption> permaneceu estável em 2025 em comparação com 2024, com apenas uma pequena porcentagem de sites incluindo legendas. Essa baixa adoção é semelhante à dos anos anteriores: cerca de 1,6% dos sites em desktop incluem legendas, que são um recurso de acessibilidade importante, embora frequentemente esquecido.

As tabelas não devem ser usadas indevidamente para fins de layout. O CSS Flexbox e o Grid cuidam do layout. Quando as tabelas são usadas puramente para layout, o atributo role="presentation" remove seu significado semântico para evitar confusão com as tecnologias assistivas.

desktop mobile desktop mobile
Tabelas com legenda 5.6% 4.7% 1.7% 1.7%
Tabela de apresentação 4.9% 5.4% 3.6% 4.8%
Figura 6.15. Uso de tabelas.

Em 2025, 4,9% das tabelas em dispositivos móveis usam essa técnica, contra 4% em 2024 e 1% em 2022. A ênfase continua sendo o uso correto de elementos HTML semânticos para tornar as tabelas acessíveis.

Formulários

Os formulários são a forma como os usuários interagem com a web, desde fazer login até fazer uma compra ou compartilhar informações. Garantir que sejam acessíveis é fundamental para que os usuários consigam concluir tarefas e participar plenamente da vida online.

Elemento <label>

O elemento <label> continua sendo a forma padrão e recomendada de fornecer nomes acessíveis para campos de entrada. Ao associar programaticamente um texto descritivo a um controle de formulário, normalmente por meio do atributo for apontando para o id do campo, ele garante que os usuários de tecnologias assistivas entendam claramente quais informações são solicitadas. Rótulos adequados também melhoram a usabilidade ao aumentar a área clicável, já que clicar no rótulo coloca o foco no campo.

De onde os campos de entrada obtêm seus nomes acessíveis.
Figura 6.16. De onde os campos de entrada obtêm seus nomes acessíveis.

Em 2025, cerca de 35% dos campos de entrada em dispositivos móveis recebem seus nomes acessíveis de <label>, contra 32% em 2024. Essa é uma tendência positiva.

Também observamos uma redução modesta, de 2%, nos campos que obtêm seus nomes acessíveis apenas do texto de placeholder. O texto de placeholder é menos confiável e não substitui os rótulos. No entanto, a proporção de campos sem nenhum nome acessível permaneceu inalterada em relação ao ano passado, indicando lacunas de acessibilidade persistentes.

Os dados de 2025 mostram uma melhora gradual no uso de label. Eles também ressaltam a necessidade de continuar ampliando as práticas adequadas de rotulagem para alcançar plena conformidade e usabilidade em acessibilidade.

Atributo placeholder

O atributo placeholder fornece uma dica ou um exemplo do formato de entrada esperado dentro de um campo de formulário. Mas ele nunca deve substituir o elemento <label> como nome acessível desse campo. O texto de placeholder desaparece assim que o usuário começa a digitar, deixando de estar disponível para consulta.

O texto de placeholder também costuma ter um contraste padrão ruim, muitas vezes não atendendo aos requisitos de contraste de cores da WCAG. O suporte dos leitores de tela a placeholders também varia bastante.

A abordagem recomendada é usar rótulos visíveis e associados programaticamente aos campos, com o placeholder servindo apenas como uma dica ou exemplo complementar.

Uso de placeholders em campos de entrada.
Figura 6.17. Uso de placeholders em campos de entrada.

Em 2025, houve uma redução de 2% no uso de texto de placeholder como único nome acessível dos campos de entrada. Apesar dessa tendência positiva, a prática continua comum demais. 53% dos campos em desktop e 55% dos campos em dispositivos móveis dependem exclusivamente do texto de placeholder como nome acessível, o que ainda representa barreiras de acessibilidade significativas.

Informações obrigatórias

Comunicar que um campo de formulário é obrigatório é essencial para a usabilidade e a acessibilidade. Embora um indicador visual como um asterisco (*) seja comum, ele sozinho é insuficiente, pois não traz informação semântica.

O atributo required do HTML5 oferece uma forma nativa e legível por máquina de indicar que o usuário precisa preencher um campo antes de enviar o formulário. Esse atributo funciona com muitos tipos de entrada, como texto, e-mail, senha, data, checkbox e radio. Os navegadores aplicam a validação, e as tecnologias assistivas transmitem aos usuários o status de obrigatório.

Como os campos obrigatórios são especificados.
Figura 6.18. Como os campos obrigatórios são especificados.

Estamos observando um aumento modesto na adoção do atributo required, que subiu 1% em 2025, chegando a 66% em dispositivos móveis. O uso de aria-required caiu 3%, para 37% em dispositivos móveis. Isso indica uma transição gradual para um uso mais semântico da validação nativa do HTML em vez do ARIA, que deve complementar, e não substituir, a semântica nativa.

O progresso em 2025 reflete um movimento lento, mas constante, em direção a uma melhor indicação semântica dos campos obrigatórios, melhorando a acessibilidade dos formulários e a experiência do usuário.

Captchas

Os CAPTCHAs diferenciam humanos de bots automatizados, mitigando atividades maliciosas. A sigla vem de “Completely Automated Public Turing Test to Tell Computers and Humans Apart” (teste de Turing público completamente automatizado para diferenciar computadores e humanos). Embora os CAPTCHAs cumpram uma função de segurança necessária, eles frequentemente criam barreiras de acessibilidade significativas, em especial para pessoas com deficiências visuais, motoras ou cognitivas.

CAPTCHAs visuais tradicionais podem ser difíceis ou impossíveis de resolver para usuários com deficiência. O W3C recomenda explorar métodos alternativos de verificação que sejam mais inclusivos, como:

  • CAPTCHAs de áudio que apresentam desafios falados
  • CAPTCHAs “invisíveis” que funcionam em segundo plano, sem ação do usuário
  • Incorporar métodos de autenticação multifator ou fluxos de verificação mais simples.

Em 2025, o uso de CAPTCHAs permaneceu praticamente estável em comparação com os anos anteriores.

Uso de CAPTCHAs ano a ano.
Figura 6.19. Uso de CAPTCHAs ano a ano.

Vale destacar que o Governo de Luxemburgo lançou uma ferramenta de varredura de CAPTCHAs. Ela avalia e monitora as implementações de CAPTCHA nos sites governamentais, com o objetivo de melhorar a conformidade com a acessibilidade no setor público.

Esforços contínuos para substituir ou complementar os CAPTCHAs visuais com opções mais acessíveis são essenciais. Todos os usuários devem conseguir concluir as etapas de verificação sem dificuldades excessivas nem exclusão.

Mídia na web

A mídia acessível na web exige o fornecimento de formatos alternativos para garantir que o conteúdo possa ser usado por todos. Usuários com deficiência visual se beneficiam de audiodescrições que transmitem informações visuais importantes. Usuários surdos ou com deficiência auditiva dependem de legendas ou de interpretação em língua de sinais para acessar o conteúdo de áudio.

Audiodescrições e legendas não são suficientes. Transcrições são necessárias para conteúdo somente em áudio e somente em vídeo, oferecendo uma alternativa textual completa. Para conteúdo não textual, como imagens, forneça um texto alternativo adequado. Se elas não acrescentarem informação significativa, marque-as como decorativas.

Os princípios e requisitos para mídia acessível permanecem os mesmos entre 2024 e 2025, enfatizando a importância contínua de oferecer experiências multimídia inclusivas para usuários com deficiência.

Imagens

O atributo alt fornece uma descrição textual de uma imagem. Ele é essencial para que usuários de leitores de tela entendam o conteúdo visual. Em 2025, esse atributo continua sendo fundamental para a acessibilidade de imagens, sem mudanças significativas nas taxas de erro em relação aos anos anteriores.

69%
Figura 6.20. Porcentagem de imagens aprovadas na auditoria do Lighthouse para imagens com texto alt.

Arquivos JPG e PNG continuam dominando as imagens na web, mas há um crescimento animador no uso dos formatos WEBP e SVG. Os arquivos SVG oferecem uma semântica rica que beneficia imagens complexas e interativas.

Extensões de arquivo mais comuns em texto alt.
Figura 6.21. Extensões de arquivo mais comuns em texto alt.

No entanto, notamos um problema que continua persistindo: aproximadamente 8,5% dos textos alternativos de imagens terminam com extensões de arquivo comuns, como .jpg ou .png. Isso normalmente acontece quando ferramentas de autoria automatizadas inserem nomes de arquivo como texto alt. Infelizmente, isso não agrega valor e não ajuda os usuários que dependem de tecnologias assistivas.

Comprimento dos atributos alt.
Figura 6.22. Comprimento dos atributos alt.

Há uma tendência positiva em direção a textos alternativos com 20 a 30 caracteres, que tendem a equilibrar descrição e concisão. Mas cerca de 50% das imagens ainda têm atributos alt vazios ou textos com menos de 10 caracteres. O texto alternativo vazio é apropriado apenas para imagens puramente decorativas. A maioria das imagens, no entanto, transmite informações importantes que merecem descrições significativas e, portanto, se beneficiará de um texto alternativo significativo.

As boas práticas continuam a enfatizar o fornecimento de textos alternativos concisos, porém descritivos, adaptados ao contexto da imagem, evitando nomes de arquivo e usando formatos de arquivo semânticos como SVG quando apropriado. As ferramentas de Inteligência Artificial (IA) também se mostram promissoras. A integração de sugestões de texto alternativo assistidas por IA do Drupal ajuda os autores a criar atributos alt melhores ao fornecer exemplos editáveis. Brian Teeman escreveu uma crítica interessante sobre a geração de texto alternativo por IA.

As imagens continuam sendo uma área com oportunidades de melhorias significativas de acessibilidade, apesar do progresso constante.

Áudio e vídeo

O elemento HTML <track> fornece faixas de texto sincronizadas, como legendas descritivas, legendas de tradução e audiodescrições, para elementos de mídia como <video> e <audio>. Em 2025, esse elemento ainda é subutilizado. Apesar de sua importância para usuários surdos, com deficiência auditiva ou cegos, as taxas de adoção continuam excepcionalmente baixas, abaixo de 1%.

Muitas plataformas de vídeo modernas agora usam com frequência o HTTP Live Streaming (HLS) em vez do elemento nativo <track>. Isso pode contribuir para as baixas estatísticas de uso. Com o HLS, que exige implementação personalizada, os desenvolvedores precisam ser mais intencionais ao incorporar eles mesmos o suporte a legendas. Isso significa que há mais espaço para os desenvolvedores esquecerem as legendas ou as implementarem mal.

As legendas são essenciais para usuários surdos e com deficiência auditiva. Elas também beneficiam espectadores em ambientes barulhentos ou pessoas com dificuldade para compreender a linguagem falada. As audiodescrições permitem que usuários com deficiência visual obtenham contexto sobre o conteúdo visual.

Em comparação com 2024, não vimos um crescimento significativo no uso de <track> para legendas descritivas e de tradução, que passou de 0,1% para 0,4% em desktop e de 0,1% para 0,2% em dispositivos móveis. Isso nos mostra que o setor ainda tem um espaço considerável para melhorar.

Tecnologia assistiva com ARIA

Accessible Rich Internet Applications (ARIA) é um conjunto de atributos HTML para melhorar a acessibilidade do conteúdo web. O ARIA é particularmente valioso para componentes complexos ou personalizados que não podem se tornar acessíveis apenas com HTML nativo. O ARIA aprimora interfaces de usuário dinâmicas e interativas, garantindo que pessoas que usam leitores de tela ou outras tecnologias assistivas consigam entender todos os elementos da página e interagir com eles.

O ARIA deve ser usado com cuidado.

O uso incorreto ou excessivo pode introduzir novas barreiras, causando confusão tanto para os usuários quanto para as ferramentas de acessibilidade. Por exemplo, atributos ARIA que não correspondem à funcionalidade pretendida, roles adicionadas a elementos inadequados ou ARIA redundante podem prejudicar a experiência do usuário e aumentar os erros de acessibilidade.

O trabalho de Adrian Roselli destaca as limitações de certas propriedades ARIA, como aria-description, e ressalta a importância de entender tanto os pontos fortes quanto as armadilhas do ARIA.

O princípio mais importante do ARIA é:

Se você puder usar HTML nativo, use.

Elementos nativos como <button>, <input> e <nav> vêm com acessibilidade embutida que o ARIA não consegue reproduzir completamente. O ARIA deve apenas complementar a semântica nativa onde for necessário, e não substituí-la.

Orientações recentes de especialistas, incluindo Florian Schroiff, assim como as boas práticas atuais, reforçam a aplicação do ARIA apenas em elementos personalizados complexos e o cumprimento rigoroso das especificações para evitar exclusão acidental ou falhas de comunicação.

Em 2025, o ARIA continua desempenhando um papel vital, mas às vezes problemático, na acessibilidade web.

Roles ARIA

As roles ARIA comunicam a finalidade ou o tipo de um elemento às tecnologias assistivas. Em 2025, elas continuam tendo um papel significativo em tornar o conteúdo web acessível. Embora elementos HTML nativos como <button> venham com semântica embutida, o ARIA oferece a possibilidade de atribuir roles a componentes personalizados que não têm equivalentes nativos, como interfaces com abas ou componentes dialog.

As dez roles ARIA mais comuns.
Figura 6.23. As dez roles ARIA mais comuns.

Observamos um aumento de aproximadamente 4% no uso da role ARIA button, que chegou a 53% dos sites em desktop e 54% dos sites em dispositivos móveis em 2025. Vimos aumentos semelhantes no uso de roles como presentation e dialog, enquanto o uso da role search permanece estável.

O aumento do uso da role ARIA button gera preocupações. Muitas vezes, ele indica que os sites estão aplicando roles como button a elementos não semânticos, como <div> ou <span>. Ou estão atribuindo roles de forma redundante a elementos HTML nativos como <button>.

Uso da role presentation

Aplicar role="presentation" ou role="none" instrui as tecnologias assistivas a tratar o elemento como puramente de apresentação. Isso remove sua semântica nativa da árvore de acessibilidade. Embora isso possa ser útil para elementos de layout que não transmitem nenhuma informação significativa, o uso excessivo ou indevido pode criar barreiras de acessibilidade significativas.

Por exemplo, aplicar role="presentation" a um elemento <ul> faz com que toda a semântica da lista, incluindo a dos elementos <li> filhos, seja ignorada. Os usuários de leitores de tela perdem informações contextuais e estruturais cruciais, como quantos itens há em uma lista.

Embora a role presentation possa ajudar a remover semânticas enganosas quando os elementos são usados de forma puramente decorativa ou para layout, ela deve ser aplicada com moderação e com uma intenção clara.

42%
Figura 6.24. Porcentagem de sites em desktop e em dispositivos móveis que têm pelo menos uma role presentation.

Em 2025, o uso de role="presentation" aumentou 2%, dando continuidade a uma tendência preocupante.

Rotulagem de elementos com ARIA

Os navegadores mantêm uma árvore de acessibilidade que expõe informações sobre os elementos da página, como seus nomes acessíveis, roles, estados e descrições. As tecnologias assistivas dependem dela para transmitir contexto aos usuários. O nome acessível de um elemento é crucial e geralmente é derivado do conteúdo de texto visível. No entanto, atributos ARIA como aria-label e aria-labelledby podem ser usados para definir ou sobrescrever explicitamente os nomes acessíveis quando o texto nativo é insuficiente ou indisponível.

Os 10 atributos ARIA mais usados.
Figura 6.25. Os 10 atributos ARIA mais usados.

Em 2025, o uso de quase todos os principais atributos ARIA aumentou. O uso de aria-label em desktop subiu 5%, e o de aria-labelledby, 3%. O uso de aria-describedby em desktop caiu 1%.

Essas mudanças sugerem que os desenvolvedores estão atribuindo nomes acessíveis programaticamente a cada vez mais elementos. Isso pode ser útil, mas também problemático se não for implementado com cuidado.

Origem do nome acessível dos botões.
Figura 6.26. Origem do nome acessível dos botões.

Estamos vendo uma tendência preocupante, com o aumento contínuo, de 4% a 5%, na definição de botões apenas com aria-label, sem rótulos visíveis correspondentes. Essa desconexão entre o que o usuário vê e o que as tecnologias assistivas anunciam pode criar confusão e barreiras. Isso vale especialmente para pessoas com deficiências cognitivas ou que usam entrada por voz. Idealmente, o nome acessível e o rótulo visível devem coincidir para proporcionar uma experiência de usuário consistente.

Quase 66% das páginas usam o atributo aria-label, mais do que em anos anteriores, o que o torna o atributo ARIA mais usado para nomes acessíveis. Cerca de um quarto das páginas usa aria-labelledby.

Embora usar ARIA para melhorar a acessibilidade seja positivo, isso ressalta a importância de testar com tecnologias assistivas e de envolver usuários com deficiência para garantir uma nomeação significativa e precisa.

Ocultando conteúdo

O atributo aria-hidden="true" remove um elemento e todos os seus descendentes da árvore de acessibilidade, tornando o conteúdo invisível para os leitores de tela. Isso é útil para ocultar elementos visuais puramente decorativos ou redundantes que, de outra forma, confundiriam usuários não visuais.

66%
Figura 6.27. Páginas com pelo menos um elemento com o atributo aria-hidden.

Em 2025, o uso de aria-hidden aumentou 3% em comparação com 2024. Aproximadamente 66% dos sites têm algum conteúdo oculto por meio desse atributo ARIA.

Da mesma forma, o atributo aria-expanded, que sinaliza se uma seção de conteúdo está expandida ou recolhida, também teve sua adoção ampliada, chegando a 40% dos sites em desktop e 38% dos sites em dispositivos móveis. Esse atributo é importante para comunicar às tecnologias assistivas o estado de widgets de disclosure, como acordeões ou menus expansíveis.

A aplicação criteriosa desses atributos ARIA continua sendo crucial em 2025. Eles ajudam no gerenciamento de conteúdo dinâmico e garantem experiências inclusivas em diferentes dispositivos e para diferentes necessidades dos usuários.

Texto exclusivo para leitores de tela

Em 2025, uma técnica comum e eficaz de acessibilidade é o uso de texto exclusivo para leitores de tela. Trata-se de um texto visualmente oculto, mas que continua acessível a tecnologias assistivas como os leitores de tela. Essa abordagem costuma ser aplicada para fornecer contexto adicional, instruções ou rótulos descritivos para elementos interativos sem poluir a interface visível.

Os desenvolvedores frequentemente usam classes CSS comuns, como .sr-only, .visually-hidden ou .element-invisible, para obter esse efeito. Essas classes normalmente usam posicionamento fora da tela, recorte ou caixas de tamanho zero para ocultar o texto visualmente, garantindo que ele permaneça na árvore de acessibilidade e possa ser lido pelos leitores de tela.

16%
Figura 6.28. Sites em desktop com uma classe sr-only ou visually-hidden.

O uso dessas classes comuns de texto exclusivo para leitores de tela permaneceu praticamente inalterado entre 2024 e 2025. Alguns sites incluem texto oculto para fornecer aos usuários de leitores de tela um contexto que pode não ficar evidente apenas pelo HTML semântico.

Conteúdo renderizado dinamicamente

As live regions ARIA são fundamentais para tornar acessível o conteúdo que muda dinamicamente. Elas informam os leitores de tela sobre atualizações no conteúdo da página, como mensagens de validação de formulários, atualizações de status ou feeds ao vivo. Essas atualizações ocorrem sem recarregar a página inteira e, por isso, as live regions são necessárias para que os usuários recebam informações importantes sem interrupções.

Role Desktop Mobile Valor implícito de aria-live
status 15.18% 14.51% polite
alert 7.12% 6.74% assertive
timer 0.91% 0.84% off
log 0.61% 0.55% polite
marquee 0.09% 0.10% off
Figura 6.29. Páginas com roles ARIA de live region e seu valor implícito de aria-live.

Em 2025, cerca de 33% dos sites usam o atributo aria-live, um aumento de 4% em relação a 2024. O uso do valor status para role, que equivale essencialmente a um valor polite de aria-live, aumentou aproximadamente 5%. Isso sinaliza uma adoção mais ampla de notificações polite, que informam os usuários sobre atualizações não urgentes.

Outras roles ARIA, como alert, timer, log e marquee, também têm atributos aria-live implícitos com comportamentos predefinidos, permitindo um amplo espectro de casos de uso de live regions.

O aumento do uso de live regions ARIA em 2025 reflete um progresso na comunicação eficaz de atualizações de conteúdo dinâmico, apoiando os usuários que dependem de tecnologias assistivas para interagir com experiências web modernas e responsivas.

Widgets de personalização do usuário e remediação por overlays

Widgets de acessibilidade e ferramentas de remediação por overlay são scripts de terceiros projetados para melhorar a acessibilidade dos sites. Eles oferecem opções de personalização ao usuário, como ajustes de tamanho de fonte ou de contraste, e correções automatizadas para problemas comuns de acessibilidade.

Esses overlays muitas vezes prometem conformidade por meio de uma solução rápida, mas não dão conta de desafios complexos de acessibilidade que exigem mudanças manuais no código e no design. O Fórum Europeu da Deficiência alertou que essas ferramentas podem interferir nas tecnologias assistivas dos próprios usuários, criando conflitos que reduzem a acessibilidade e frustram os usuários.

Embora os overlays possam ajudar a remover algumas barreiras superficiais e oferecer recursos adicionais de personalização, depender deles muitas vezes leva as organizações a deixar de investir em uma acessibilidade adequada. Os overlays geralmente trazem mais desvantagens de usabilidade, segurança e desempenho do que corrigir os problemas no código subjacente.

Páginas que usam aplicativos de acessibilidade (overlays).
Figura 6.30. Páginas que usam aplicativos de acessibilidade (overlays).

Os dados mostram que cerca de 2% dos sites em desktop usam esses aplicativos de acessibilidade. As taxas são ainda menores entre os sites com mais tráfego: 0,2% entre os 1.000 principais. Esse padrão mostra que os overlays são adotados principalmente por sites com menos tráfego e continuam sendo uma solução controversa e imperfeita.

Apesar de um aumento marginal no uso em 2025, a distribuição desses aplicativos de acessibilidade permanece consistente com a de 2024, dominada por fornecedores como UserWay, AccessiBe, AudioEye e EqualWeb.

Uso de aplicativos de acessibilidade por ranking.
Figura 6.31. Uso de aplicativos de acessibilidade por ranking.

Confusão sobre overlays

Os overlays de acessibilidade e os widgets de personalização, embora tenham crescido marginalmente, cerca de 2%, em 2025, continuam sendo uma fonte significativa de controvérsia e confusão.

Organizações de referência, como a International Association of Accessibility Professionals (IAAP) e o Fórum Europeu da Deficiência (EDF), alertaram explicitamente que os overlays não são uma solução mágica. Eles nunca devem impedir o acesso dos usuários nem interferir em suas tecnologias assistivas, e não devem ser comercializados como algo que deixa um site em total conformidade.

As alegações de marketing muitas vezes criam expectativas irreais nas organizações, gerando riscos jurídicos e práticos. Essas ferramentas não podem substituir o design inclusivo, os testes manuais de acessibilidade e a remediação contínua. Tudo isso é essencial para atender aos padrões de acessibilidade.

O Ato Europeu de Acessibilidade e outras regulamentações enfatizam que a acessibilidade deve ser incorporada aos sites desde a origem. Embora existam overlays de acessibilidade, eles não atendem aos critérios detalhados dos padrões de acessibilidade se o próprio site subjacente não for acessível. Portanto, eles não são uma solução adequada por si sós.

O Bitvtest.de decidiu recentemente deixar de testar sites que usam uma ferramenta de overlay e proibir neles o uso do seu selo de certificação. O Bitvtest é um serviço profissional de testes de acessibilidade construído em torno do BITV-Test alemão, uma forma estruturada de verificar o quão acessível é um site ou aplicativo.

O impacto da Inteligência Artificial (IA)

A inteligência artificial (IA) é um amplo campo da ciência da computação voltado à construção de sistemas capazes de realizar tarefas que normalmente exigem inteligência humana. Dentro desse campo, os grandes modelos de linguagem (LLMs) são um tipo específico de sistema de IA treinado com conjuntos de dados muito grandes para aprender padrões estatísticos.

Os LLMs usam esses padrões para gerar e transformar texto, responder a perguntas e seguir instruções, mas não têm compreensão nem intenção no sentido humano. Eles preveem palavras e frases prováveis com base em seus dados de treinamento.

As ferramentas de acessibilidade web dependem cada vez mais de LLMs. Muitas plataformas agora oferecem texto alt gerado por IA como forma de lidar com descrições de imagem ausentes, embora a qualidade e a precisão dessas soluções automatizadas variem bastante.

Os desenvolvedores estão incorporando ferramentas de IA, como o Accessibility Scanner do GitHub, ao seu trabalho diário. Essas ferramentas oferecem feedback instantâneo e recomendações de acessibilidade, facilitando a correção de problemas de acessibilidade.

Mas a IA na acessibilidade não está livre de problemas.

No momento, não há uma forma padronizada de saber se a IA criou ou aprimorou um site ou seu conteúdo. Isso dificulta a avaliação dos sites e deixa os usuários sem saber o que estão vendo.

Alguns especialistas, como a defensora da acessibilidade Léonie Watson, falam de uma “web agêntica”, em que a IA muda a forma como interagimos com o conteúdo online. Isso levanta questões sobre como os padrões de acessibilidade precisam se adaptar.

Navegadores e extensões com IA estão se popularizando rapidamente. Assistentes de voz e agentes de IA integrados aos navegadores podem em breve dar conta da maior parte das nossas buscas básicas por informação. As pessoas já têm a opção de escolher respostas geradas por IA em vez dos resultados de busca tradicionais. Essa mudança pode ajudar ou prejudicar o design acessível. Tudo depende de essas ferramentas de IA serem, elas próprias, totalmente acessíveis.

Especialistas como Joe Dolson investigaram se a IA consegue construir sozinha sites totalmente acessíveis, destacando tanto o potencial quanto as limitações atuais da tecnologia. As experiências de Scott Vinkle na Shopify mostram como a IA pode melhorar a acessibilidade em situações reais.

O blog do The A11Y Collective sobre Inteligência Artificial e Acessibilidade aponta que, embora ferramentas de IA que automatizam texto alt ou legendas em tempo real, assim como os assistentes de voz, possam ajudar a acessibilidade em escala, elas ainda têm dificuldades com precisão, contexto, privacidade e viés.

Uma pesquisa de Dries Buytaert mostra que a IA consegue dar conta de enormes acúmulos de imagens sem descrição, mas a revisão humana ainda é essencial para garantir a qualidade. Ele explora o equilíbrio entre qualidade, privacidade, custo e complexidade para organizações que estão considerando texto alternativo gerado por IA.

A Digital Accessibility Training descreve as oportunidades e os desafios da IA para criadores de conteúdo. As ferramentas de IA viabilizam recursos de acessibilidade em escala, mas levantam preocupações sobre a validade do conteúdo, vieses e uso ético.

Hidde de Vries compara como humanos e modelos de linguagem abordam o código de componentes acessíveis. Os humanos baseiam suas decisões de HTML, CSS e ARIA em especificações, necessidades dos usuários, comportamento das tecnologias assistivas e peculiaridades das plataformas, tudo guiado pelas intenções para a interface. Já os LLMs preveem o código provável a partir dos dados de treinamento, o que é problemático porque a maior parte do código existente tem problemas de acessibilidade, e os modelos não têm intenção nem compreensão de usuários específicos.

Adrian Roselli reconhece que os avanços recentes em visão computacional e LLMs podem potencialmente ajudar os leitores a condensar artigos complexos em resumos compreensíveis. No entanto, ele argumenta que essas ferramentas ainda carecem de contexto e autoria. Elas não conseguem saber por que um conteúdo foi criado, do que depende uma piada ou um meme, nem como uma interface deve funcionar. Suas descrições e sugestões de código podem facilmente errar o foco ou induzir os usuários ao erro.

A IA levanta preocupações éticas significativas que vão além da acessibilidade.

100
Figura 6.32. Número equivalente de carros a gasolina em emissões de carbono necessárias para treinar um LLM.

Uma questão importante é o impacto ambiental. Um estudo sobre emissões de carbono e o treinamento de grandes redes neurais estimou que treinar um único grande modelo de linguagem, como o GPT‑3, consumiu mais de 1.200 megawatts-hora de eletricidade e produziu cerca de 500–550 toneladas métricas de CO₂ equivalente. Isso é comparável às emissões de mais de 100 carros a gasolina ao longo de toda a sua vida útil. Para mais informações, consulte o capítulo Sustentabilidade.

Outra preocupação central é como os dados de treinamento são coletados e usados. Vários processos judiciais de grande repercussão alegam que fornecedores de IA coletaram e usaram material protegido por direitos autorais sem permissão ou compensação. Isso incluiu milhões de fotos de banco de imagens e livros.

Estudos sobre grandes modelos mostram que eles podem amplificar vieses capacitistas, racistas e outros vieses nocivos presentes em seus dados de treinamento. Isso acaba moldando a forma como deficiência, raça e gênero são descritos, reforçando estigmas em escala.

Olhando para o futuro, está claro para nós que a IA se tornará cada vez mais uma ferramenta da qual desenvolvedores web e criadores de conteúdo dependem. No entanto, a IA deve apoiar a expertise humana, e não substituí-la.

À medida que essas ferramentas melhoram, a comunidade de acessibilidade precisa responder a algumas perguntas importantes em 2026 e nos anos seguintes:

  • Como verificamos se o conteúdo gerado por IA é preciso e acessível?
  • Que padrões devem reger o uso de IA em conteúdo web?
  • Como as tecnologias assistivas vão funcionar com interfaces orientadas por IA?
  • A IA pode oferecer acessibilidade igualitária respeitando as necessidades individuais?
  • De quais diretrizes éticas precisamos para evitar que a IA reforce vieses ou exclua pessoas?

Setores e acessibilidade

Esta seção compara as pontuações de acessibilidade entre diversos setores da indústria e da comunidade para identificar padrões e líderes.

País

Podemos identificar o país de origem de um site pela localização geográfica do servidor (GeoID) ou pelo seu domínio de nível superior (TLD). Ambos os métodos têm limitações. Custos de hospedagem, estratégias de localização de servidores e práticas de propriedade de domínios fazem com que o servidor de um site nem sempre reflita seu público-alvo. TLDs usados globalmente, como .ai ou .io, não estão necessariamente ligados aos seus países de origem.

Mais acessíveis por GeoID do servidor
Figura 6.33. Mais acessíveis por GeoID do servidor

Em 2025, os Estados Unidos continuam sendo o país mais acessível por GeoID, posição impulsionada por décadas de requisitos de conformidade com a Seção 508 para agências federais e pelos litígios contínuos com base no Título III da ADA. Os TLDs .edu e .gov também lideram as métricas de acessibilidade, refletindo a conformidade obrigatória para instituições governamentais e educacionais dos EUA.

Também observamos o impacto limitado do Ato Europeu de Acessibilidade em 2025. Embora o Ato tenha entrado plenamente em vigor em 28 de junho de 2025, exigindo que os serviços digitais dos setores público e privado sejam acessíveis em toda a União Europeia, os dados preliminares não mostram nenhum salto expressivo na acessibilidade dos sites sediados na Europa.

Esse atraso provavelmente reflete desafios de implementação, períodos de transição para serviços existentes e o tempo necessário para que as organizações redesenhem e auditem suas ofertas digitais.

A fiscalização legal e a ameaça de litígios continuam sendo os principais impulsionadores da conformidade em acessibilidade, como evidencia a posição de liderança dos Estados Unidos. O impacto total das legislações europeias e globais mais recentes pode levar anos para se refletir nas estatísticas de acessibilidade web, à medida que as organizações avançam em seus cronogramas de implementação e períodos de transição.

Notamos uma tendência relevante surgindo em 2025. Os domínios .ai apareceram pela primeira vez nos rankings de acessibilidade e agora superam todos os TLDs, exceto .edu e .gov. Isso provavelmente reflete a crescente adoção por empresas ligadas à IA, muitas das quais priorizam práticas de desenvolvimento modernas, incluindo acessibilidade.

Originalmente atribuída a Anguila, uma pequena ilha do Caribe, em 1995, a extensão de TLD .ai permaneceu relativamente obscura por quase 15 anos, até 2009, quando Anguila abriu os registros diretos para o mundo todo. O domínio ficou adormecido durante a maior parte de sua história, até que o boom da inteligência artificial, de 2022 em diante, o transformou em um dos TLDs que mais crescem no mundo.

O catalisador veio com a chegada do ChatGPT, no fim de 2022, que despertou um interesse sem precedentes pela IA. Entre julho de 2022 e julho de 2023, os domínios .ai registrados dispararam de 75.314 para 196.292, um aumento de 161% em apenas doze meses.

Geograficamente, a América do Norte responde pela maioria dos registros de domínios .ai, com 62,5%, sendo que somente os Estados Unidos respondem por 62,5% de todos os domínios .ai registrados. A Ásia vem em seguida, com 18,8%, e a Europa, com 17,2%.

Muitos titulares de domínios .ai são startups de tecnologia bem financiadas, apoiadas por capital de risco, com maior probabilidade de usar IA. Ainda está em debate se a IA consegue produzir código mais acessível do que equipes humanas, mas esse é um indicador.

Ao contrário das empresas tradicionais mais antigas, que usam .com ou .org, as empresas de IA mais novas costumam construir com padrões e ferramentas web contemporâneos, que consideram a acessibilidade desde o início. Essas empresas que usam um domínio .ai e vendem produtos de IA muito provavelmente envolveram a IA na construção de seus sites, ao menos consultando-a para obter código ou conteúdo, se não usando-a em configurações agênticas mais automatizadas.

TLDs tradicionais como .com, .org e .net não aparecem entre os líderes em acessibilidade. Isso sugere que o tipo de domínio, por si só, não é um forte indicador de conformidade em acessibilidade.

Países acessíveis por domínio de nível superior (TLD).
Figura 6.34. Países acessíveis por domínio de nível superior (TLD).

O mapa do ranking de TLDs é muito parecido com o de 2024, mas obviamente não inclui o número crescente de TLDs não específicos de países disponíveis atualmente.

Mapa de países acessíveis por domínio de nível superior (TLD).
Figura 6.35. Mapa de países acessíveis por domínio de nível superior (TLD).

Governo

Os sites governamentais continuam sendo uma arena crucial para demonstrar o compromisso público com a acessibilidade. Mas a implementação varia drasticamente entre as jurisdições. Os dados de 2025 revelam tendências importantes na acessibilidade dos sites governamentais em todo o mundo, influenciadas por legislações recentes, mudanças metodológicas na coleta de dados e mecanismos de fiscalização.

Usamos uma metodologia diferente este ano para conseguir avaliar uma gama mais ampla de domínios que ficaram fora das varreduras em 2024.

Em 2024, amostramos apenas 79 domínios do governo dos Países Baixos. Em 2025, consultamos mais de 10 vezes esse número, com 957 domínios. Da mesma forma, varremos cerca do dobro de domínios de Luxemburgo e da Finlândia. A maior precisão significa que temos um conjunto de dados mais abrangente, mas também uma comparação ano a ano mais complexa.

No Reino Unido, vimos uma melhora para 94% de acessibilidade, um aumento de 2% em relação a 2024. Isso reflete os benefícios de design systems padronizados, como o Padrão de Serviços Digitais do Governo do Reino Unido, que prioriza a acessibilidade em todos os serviços digitais públicos. Os Países Baixos, Luxemburgo e a Finlândia continuam liderando, com os Países Baixos tendo alcançado 98% em anos anteriores. Eles mantiveram essa posição por meio de estruturas de governança consistentes e da priorização de design systems.

Também nos esforçamos para incluir a Escócia (gov.scot) e o País de Gales (gov.wales). Em 2025, calculamos a média a partir de 19.568 domínios, enquanto em 2024 foram apenas 16.594.

O monitoramento é uma parte essencial da priorização da acessibilidade, e aplaudimos painéis como o do Governo Francês, que destacam o progresso em diversos indicadores de qualidade de sites, incluindo acessibilidade. Grande parte do código por trás disso é de código aberto. O governo neerlandês também tem um painel que acompanha quase 9.000 sites e aplicativos. No momento em que este texto foi escrito, 60% de todas as propriedades web monitoradas estavam em conformidade com os requisitos legais.

Os Relatórios de Monitoramento de Acessibilidade feitos pelo AccessibleEU são importantes, mas muito mais abstratos. A Diretiva de Acessibilidade da Web da UE exige que os Estados-membros monitorem e relatem a conformidade em acessibilidade a cada 3 anos. Esses relatórios estão disponíveis publicamente.

O cenário regulatório em evolução da União Europeia teve um impacto significativo na acessibilidade dos sites governamentais em 2025.

A Diretiva de Acessibilidade da Web da UE exige que as organizações do setor público atendam a padrões técnicos específicos. O Ato Europeu de Acessibilidade (EAA), mais amplo, que entrou plenamente em vigor em 28 de junho de 2025, estende os requisitos a organizações do setor privado em setores-chave, como comércio eletrônico, viagens e bancos.

Apesar desse impulso regulatório, os dados de acessibilidade de 2025 não mostram nenhum salto expressivo na conformidade dos sites governamentais europeus, o que sugere que a implementação ainda está em andamento e que o impacto total talvez só se torne visível em 2026.

Os Estados-membros da UE são obrigados a publicar declarações de acessibilidade e a oferecer mecanismos de feedback para que os usuários relatem barreiras. As declarações de acessibilidade são uma parte importante da Diretiva de Acessibilidade da Web da UE, mas, até o momento, não temos uma boa forma de incluí-las nas varreduras de sites. A Funka Foundation nos lembrou das limitações desse tipo de teste para avaliar conformidade.

Governos nacionais mais acessíveis.
Figura 6.36. Governos nacionais mais acessíveis.

O mapa de 2025 é quase indistinguível do de 2024.

Mapa da acessibilidade dos sites governamentais no mundo.
Figura 6.37. Mapa da acessibilidade dos sites governamentais no mundo.

Nos Estados Unidos, a conformidade dos governos estaduais continua inconsistente, apesar das novas exigências federais. A regra final do Departamento de Justiça (DOJ) sobre o Título II da Lei dos Americanos com Deficiência, publicada em junho de 2024, exige que todas as entidades governamentais estaduais e locais alcancem a conformidade com a WCAG 2.1 AA dentro de prazos específicos: 26 de abril de 2026, para entidades que atendem populações de 50.000 pessoas ou mais, e 26 de abril de 2027, para entidades menores.

Estados como Colorado e Vermont se destacaram ao estabelecer estruturas de governança centralizadas. A Statewide Internet Portal Authority do Colorado (SIPA) demonstra como a gestão centralizada melhora a acessibilidade em várias agências.

Nevada, Kansas, Califórnia e Nova York tiveram bom desempenho nas amostras de ambos os anos. Mas as médias não indicam que os governos estaduais tenham feito qualquer progresso significativo no cumprimento dos novos requisitos da Regra Final do Departamento de Justiça dos EUA de 2024 para Fortalecer o Acesso à Web e a Aplicativos Móveis. Líderes estaduais de tecnologia, na conferência nacional da National Association of State Chief Information Officers (NASCIO), reafirmaram a acessibilidade como prioridade máxima.

A Lei dos Americanos com Deficiência (ADA), que completou 35 anos em julho, foi um trabalho pioneiro que estabeleceu um precedente global.

O compromisso recente de Singapura com a melhoria da acessibilidade, demonstrado por meio da ferramenta de código aberto Oobee, mostra um impulso global emergente. O Oobee permite que as organizações façam a varredura de centenas de páginas e gerem relatórios de acessibilidade consolidados, o que o posiciona como um Bem Público Digital.

Os governos estaduais mais acessíveis dos EUA.
Figura 6.38. Os governos estaduais mais acessíveis dos EUA.

Sistemas de Gerenciamento de Conteúdo (CMS)

A escolha do Sistema de Gerenciamento de Conteúdo (CMS) de um site influencia significativamente seus resultados de acessibilidade. Usando dados do Wappalyzer, o Web Almanac 2025 comparou as pontuações de acessibilidade entre CMSs tradicionais, plataformas e criadores de sites especializados. Isso revelou tanto padrões consistentes quanto exceções notáveis.

CMSs tradicionais mais acessíveis.
Figura 6.39. CMSs tradicionais mais acessíveis.

Entre os CMSs tradicionais, o Sitecore manteve 85% de acessibilidade em 2025, embora seu número de instâncias tenha caído para menos de 10.000. O Adobe Experience Manager (AEM) e o Contentful continuam liderando, provavelmente porque as grandes corporações que adotam essas soluções corporativas têm mais recursos para resolver problemas de acessibilidade. O WordPress não apresentou melhora significativa em relação a 2024, mas subiu para o terceiro lugar, refletindo seu domínio de mercado e a crescente consciência sobre acessibilidade de sua base de usuários.

Notavelmente, os cinco principais CMSs tradicionais compartilham padrões de erro consistentes. Contraste de cores, nomes de links e ordem dos títulos dominam como os problemas mais comuns. Esses erros refletem principalmente escolhas de conteúdo, e não limitações das plataformas, já que um CMS não pode ditar a nomeação de links ou a escolha de cores. No entanto, o AEM é o único com label-content-name-mismatch entre seus cinco principais erros. O WordPress é o único a ter erros de meta-viewport.

Entre os 10 principais CMSs, apenas o DNN tem image-alt entre os 3 principais erros. Para a maioria dos CMSs tradicionais, image-alt e target-size aparecem de forma consistente em quarto ou quinto lugar entre os erros do Google Lighthouse.

CMSs de plataformas de criação de sites mais acessíveis.
Figura 6.40. CMSs de plataformas de criação de sites mais acessíveis.
CMS de plataforma Mais comum Segundo mais comum Terceiro mais comum Quarto mais comum Quinto mais comum
Wix heading-order link-name color-contrast button-name target-size
Squarespace color-contrast heading-order link-name label-content-name-mismatch frame-title
Webnode heading-order link-name frame-title color-contrast image-redundant-alt
Google Sites image-alt link-name aria-allowed-attr heading-order color-contrast
Webflow link-name color-contrast heading-order html-has-lang target-size
Figura 6.41. Principais problemas de auditoria de acessibilidade em plataformas de CMS populares.

Plataformas de criação de sites como Wix, Squarespace e Google Sites superam significativamente os CMSs tradicionais em acessibilidade. Esse desempenho superior provavelmente decorre da abordagem delas. Essas plataformas costumam restringir as escolhas dos usuários por meio de designs baseados em templates e padrões de acessibilidade embutidos, reduzindo as oportunidades para decisões ruins de acessibilidade.

Os dados comprovam que a escolha do CMS tem um impacto significativo nos resultados de acessibilidade, mesmo quando os criadores de conteúdo precisam assumir a responsabilidade final por algumas decisões. Plataformas com restrições de design mais rígidas e padrões de acessibilidade embutidos têm melhor desempenho, enquanto aquelas que oferecem máxima flexibilidade deixam as decisões de acessibilidade para os usuários.

Frameworks JavaScript de frontend

A escolha do framework JavaScript também influencia significativamente os resultados de acessibilidade de um site. Usando as classificações do relatório State of JS, examinamos como diferentes frameworks de UI e meta-frameworks se correlacionam com o desempenho em acessibilidade. Isso revelou padrões, mudanças e preocupações emergentes.

Frameworks JavaScript de UI para frontend mais acessíveis.
Figura 6.42. Frameworks JavaScript de UI para frontend mais acessíveis.

Em 2025, o OpenUI5 subiu nos rankings de acessibilidade, enquanto os frameworks que lideravam em 2024 (Stimulus, Remix e Qwik) mudaram de posição. O Remix aparece tanto na categoria de UI quanto na de meta-frameworks, mas caiu nos rankings em 2025, permitindo o avanço de outros frameworks. Essa volatilidade pode refletir mudanças no tamanho da amostra ou melhorias reais nos frameworks concorrentes. O fato de toda a funcionalidade do Remix ter sido integrada diretamente à versão seguinte do React Router, tornando o Remix redundante como framework React, também pode ter impacto nos rankings.

Historicamente, Stimulus, Remix e Qwik superaram opções mais populares, como React, Svelte ou Ember.js, por vários pontos percentuais, provavelmente porque priorizam o aprimoramento progressivo e o HTML semântico.

Entre os meta-frameworks, Remix, RedwoodJS e Astro lideravam em 2024, e a queda do Remix permitiu que o Gatsby subisse para o terceiro lugar em 2025. A ascensão dos meta-frameworks server-first (SvelteKit, Astro, Remix, Qwik, Fresh, Analog) reflete uma mudança mais ampla do setor em direção a melhores práticas de desempenho e acessibilidade, reduzindo a complexidade do JavaScript no lado do cliente.

A escolha da biblioteca também tem impacto na acessibilidade.

O React oferece máxima flexibilidade e personalização, mas exige que os desenvolvedores implementem a acessibilidade de forma intencional. Seu amplo ecossistema inclui bibliotecas focadas em acessibilidade, como React Aria e Reach UI, mas a acessibilidade não é imposta por padrão.

O Angular oferece recursos robustos de acessibilidade embutidos, convenções estruturadas que promovem o HTML semântico, suporte a atributos ARIA e componentes Material Design com navegação por teclado e suporte a leitores de tela prontos para uso. A estrutura opinativa do Angular tende a guiar os desenvolvedores para práticas mais padronizadas e acessíveis.

O Vue.js busca encontrar um equilíbrio entre a flexibilidade do React e a estrutura do Angular. O design progressivo do Vue, sua sintaxe de templates clara e sua arquitetura de componentes favorecem a acessibilidade, embora ele dependa mais da disciplina dos desenvolvedores e de plugins de terceiros, como o vue-a11y.

Também observamos que o GitHub assumiu o compromisso do Global Accessibility Awareness Day (GAAD) de melhorar a acessibilidade do código aberto em escala. Esse compromisso aborda uma lacuna crítica: 90% das empresas usam código aberto, 97% das bases de código contêm componentes de código aberto e estima-se que 70–90% do código das ferramentas comerciais derive de código aberto.

Meta-frameworks JavaScript mais acessíveis.
Figura 6.43. Meta-frameworks JavaScript mais acessíveis.

O RedwoodJS continua sendo o mais acessível, seguido por Astro e Gatsby.

Conclusão

A análise de acessibilidade do Web Almanac 2025 revela um ano de progresso gradual, atenuado por desafios significativos e oportunidades perdidas.

Os testes automatizados continuam sendo essenciais para avaliar a acessibilidade em escala. Mas os dados demonstram que apenas medir não garante uma melhoria significativa. A comunidade web precisa ir além das métricas básicas de conformidade para enfrentar os problemas sistêmicos que continuam excluindo milhões de usuários com deficiência.

As melhorias mais notáveis em 2025 surgiram em setores e regiões onde a pressão regulatória e os mecanismos de fiscalização são mais fortes. No entanto, a falta de uma melhora expressiva após o prazo de 28 de junho de 2025 do Ato Europeu de Acessibilidade é instrutiva. O impacto total talvez só fique evidente em 2026 e nos anos seguintes.

A rápida ascensão do domínio .ai ao grupo dos TLDs mais acessíveis reflete um padrão importante. Empresas de tecnologia mais novas, apoiadas por capital de risco, tendem a construir com práticas modernas de acessibilidade desde o início, enquanto sites legados muitas vezes continuam inacessíveis. Isso comprova que a acessibilidade é alcançável quando priorizada desde o início do desenvolvimento.

Apesar das melhorias em áreas específicas, as principais barreiras de acessibilidade identificadas em 2024 persistem praticamente inalteradas em 2025.

Contraste de cores, nomeação de links, hierarquia de títulos e texto alt de imagens continuam sendo os quatro principais problemas em quase todas as plataformas e frameworks. Essas não são falhas diretas da ferramenta, mas da forma como os autores a utilizam. Os autores têm algum papel em todas essas falhas, de acordo com o Accessibility Roles and Responsibilities Mapping (ARRM) do W3C.

Essa realidade revela uma percepção crucial. Plataformas de CMS, frameworks JavaScript e tecnologias web podem fornecer bases de acessibilidade, mas não podem forçar os criadores de conteúdo a fazer escolhas acessíveis. Abordagens como as Authoring Tool Accessibility Guidelines (ATAG) 2.0 e o novo ATAG Community Group do W3C podem ajudar.

As métricas de 2025 sugerem estagnação onde esperávamos uma melhora gradual, evidenciando a distância entre o que é fácil de medir e o que é fácil de corrigir.

O crescimento contínuo dos overlays de acessibilidade (agora em 2% dos sites) é preocupante. Parece que as organizações muitas vezes escolhem atalhos em vez de uma acessibilidade genuína. A IAAP e o Fórum Europeu da Deficiência alertaram explicitamente que os overlays podem interferir nas tecnologias assistivas dos usuários e nunca devem substituir o design acessível. Os dados de 2025 confirmam que os overlays continuam concentrados em sites com menos tráfego, um sinal de que organizações de alta qualidade e com bons recursos estão se afastando deles em direção a soluções reais.

Os dados de 2025 ressaltam que a automação é necessária, mas insuficiente. O Lighthouse e ferramentas semelhantes detectam violações facilmente mensuráveis, mas 50% das imagens na web têm texto alt vazio ou inadequado. A hierarquia de títulos pode ser auditada, mas a relevância semântica exige julgamento humano. O contraste de cores pode ser verificado, mas as escolhas de design visual envolvem decisões artísticas subjetivas, embasadas pelos requisitos de acessibilidade.

Nossos resultados de 2025 revelam uma web que continua, em grande parte, inacessível para milhões de pessoas com deficiência.

Embora as melhorias graduais em áreas específicas sejam encorajadoras, as lacunas persistentes em contraste de cores, nomeação de links, estrutura de títulos e descrições de imagens demonstram que a comunidade web ainda não fez da acessibilidade uma prioridade genuína.

A ascensão dos domínios .ai, o compromisso do GitHub com o código aberto e prazos regulatórios como os do Ato Europeu de Acessibilidade e da regra final do Título II da ADA trazem a esperança de que 2026 tenha mudanças mais substanciais. Mas isso só acontecerá se as organizações forem além da medição para a responsabilização, da retórica para os recursos e da conformidade para a inclusão genuína.

A web deve funcionar para todos. Enquanto esse princípio não orientar nossas decisões de design, desenvolvimento e implantação, as lacunas de acessibilidade documentadas neste relatório vão persistir.

Explore os resultados

Ver resultados Ver consultas Sugerir edição Ajudar traduzir

Autores

Citaat

BibTeX 
@inbook{WebAlmanac.2025.Acessibilidade,
author = "Lazar, Bogdan e Gifford, Mike e Vries, Hidde de e Tierney, Aidan e Davis, Scott e Pollard, Barry",
title = "Acessibilidade",
booktitle = "Web Almanac 2025",
chapter = 6,
publisher = "HTTP Archive",
year = "2025",
language = "Português",
doi = "10.5281/zenodo.18246524",
url = "https://almanac.httparchive.org/en/2025/accessibility"
}