Voltar ao Blog
Angular Development4 de novembro de 20268 min de leitura

Acessibilidade Agora Tem Prazos Legais. O Que os Desenvolvedores Realmente Mudam

DR

Doug Ribeiro

8 min de leitura

Quando ativei o conjunto completo de regras de acessibilidade de template do Angular nos templates do MailHive, a primeira execução reportou 140 violações num produto que funcionava e tinha testes. Isso é normal: violações se acumulam sempre que nada falha quando você adiciona uma. Registrei essas violações numa baseline e venho reduzindo desde então, e hoje são 24. Para um número crescente de times, esse tipo de backlog agora é uma exposição legal, além de um problema de qualidade.

Escrevi separadamente sobre o mínimo de WCAG do ponto de vista de um designer. Este post é o lado do desenvolvedor: o que as regras realmente cobrem, e o que muda no seu repositório na segunda-feira. Sou desenvolvedor, não advogado, então use isto para saber o que perguntar, e busque um parecer jurídico de verdade para a sua empresa.

Quem Realmente Responde por Isso

As manchetes fazem parecer que todo site agora é ilegal. É mais restrito do que isso, e depende de onde você vende e de quem você é.

  • União Europeia: o European Accessibility Act se aplica desde 28 de junho de 2025. Na web, ele cobre serviços como e-commerce e serviços bancários ao consumidor. Prestadores de serviço que são microempresas, ou seja, com menos de 10 pessoas e no máximo 2 milhões de euros de faturamento ou de balanço, estão isentos. O texto gira em torno de serviços prestados a consumidores, não de onde a empresa está, então se você vende esses serviços para consumidores da UE a partir de fora da UE, assuma que está no escopo.
  • Canadá: as emendas de acessibilidade digital de 2025 às Accessible Canada Regulations (SOR/2025-255) se aplicam ao setor público federal e a empresas privadas reguladas em nível federal, como bancos, com 100 ou mais funcionários. Telecoms, emissoras e a maioria dos prestadores de transporte ficam, em grande parte, de fora no lado voltado ao público. As páginas web do setor público federal têm prazo em 5 de dezembro de 2027, e as páginas web de empresas grandes e médias em 5 de dezembro de 2028. O dever voltado ao público cobre páginas criadas ou atualizadas a partir dessas datas, na medida do possível. Empresas com 99 funcionários ou menos não estão cobertas. As províncias têm suas próprias leis, como a AODA em Ontário.
  • Estados Unidos: a regra do ADA Title II cobre governos estaduais e locais. Uma interim final rule de abril de 2026 adiou os prazos para abril de 2027 para quem atende 50.000 pessoas ou mais, e abril de 2028 para os menores. Empresas privadas são outra história, decidida em grande parte por litígios com base no ADA e não por uma regra como esta.

O alvo técnico é parecido nos três. A regra dos EUA cita o WCAG 2.1 AA. O padrão do Canadá e o padrão de apoio da UE são baseados na EN 301 549. A edição do Canadá hoje incorpora o WCAG 2.1 AA, e é referenciada com suas alterações ao longo do tempo, então acompanha as edições mais novas. A Deque informa que a v4.1.1, com WCAG 2.2 AA, foi publicada em setembro de 2026. Então construa para o WCAG 2.2 AA. Ele cobre os critérios da 2.1, mas a EN 301 549 adiciona requisitos próprios, então confira esses também se essas regras se aplicam a você.

A Maioria dos Erros É Banal, e Isso É uma Boa Notícia

O WebAIM Million de 2026 encontrou falhas de WCAG detectáveis em 95,9% das home pages do top 1 milhão, com média de 56,1 erros por página. A parte útil: 96% de todos os erros detectados caem em seis categorias.

  • Texto com baixo contraste: 83,9% das home pages.
  • Texto alternativo de imagem ausente: 53,1%.
  • Labels de campos de formulário ausentes: 51%.
  • Links vazios: 46,3%.
  • Botões vazios: 30,6%.
  • Idioma do documento ausente: 13,5%.

Defaults de componentes, design tokens e regras de lint conseguem evitar a maioria deles. Então este é um lugar onde um pequeno esforço do desenvolvedor mexe em números reais. E tem mais um número que você deveria conhecer: páginas com ARIA tiveram em média 59,1 erros, contra 42 das páginas sem. É uma correlação, já que páginas complexas usam mais ARIA. Recorrer a ARIA primeiro adiciona jeitos de errar. Use um botão de verdade.

Passo 1: Falhe em Violações Novas Hoje

Regras estáticas são gratuitas, rápidas e pegam problemas antes de o navegador abrir. Para Angular, o angular-eslint traz uma config de acessibilidade para templates. Para React, o equivalente é o eslint-plugin-jsx-a11y.

javascript 
// eslint.config.js, inside tseslint.config(...), simplified
{
  files: ['**/*.html'],
  extends: [
    ...angular.configs.templateRecommended,
    ...angular.configs.templateAccessibility,
  ],
}

Num app existente, espere um número parecido. Não transforme isso num projeto de limpeza, porque esse projeto vai perder para a próxima feature. Registre as violações existentes com as bulk suppressions do ESLint, para que só as novas quebrem o build. Templates vendorizados que não são seus também exigem uma decisão: isentá-los mantém o build verde, mas eles ainda podem bloquear um usuário, então acompanhe-os. A baseline estanca o sangramento. Ela não corrige nada: cada entrada suprimida é um item conhecido a ser zerado, não um item aceito. Vá zerando, começando pelos componentes compartilhados e depois pelos fluxos que as pessoas não conseguem evitar, como login e checkout. Foi assim que o MailHive foi de 140 para 24.

Passo 2: Teste a Página Renderizada

O lint enxerga templates, não o resultado. Contraste depende dos estilos computados, e a ordem dos headings só aparece em tempo de execução. O axe encontra os dois, embora a ordem dos headings seja uma regra de best practice, então adicione a tag best-practice se quiser. Ele se encaixa na suíte end-to-end que você provavelmente já tem, e é open source e gratuito.

typescript 
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('checkout has no detectable WCAG A or AA violations', async ({ page }) => {
  await page.goto('/checkout');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

Comece pelos seus três fluxos mais importantes, e teste cada um nos estados importantes, como com as mensagens de erro aparecendo. O axe só vê o que está na tela quando roda.

Passo 3: Aceite o Que Nenhuma Ferramenta Vai Pegar

O próprio estudo da Deque com mais de 2.000 auditorias concluiu que o teste automatizado cobriu cerca de 57% dos problemas em volume. É um número de fornecedor, e um número bom para eles, então trate como o limite otimista. Mesmo assim, algo como quatro problemas em cada dez precisam de uma pessoa. Uma ferramenta pode te dizer que uma imagem tem texto alternativo. Não pode te dizer que o texto não faz sentido. Pode te dizer que um botão tem um nome, não que o foco foi para um lugar sensato depois do clique.

Num single-page app, as falhas manuais se concentram nos mesmos lugares. Verifique estes à mão, só com teclado, antes de uma feature ser considerada pronta:

  • Mudança de rota: o foco vai para o novo conteúdo e o título da página muda. Numa SPA o foco não se move sozinho, e o Angular só atualiza o título se você definir um na rota. Um usuário de leitor de tela pode não receber nenhum sinal de que algo aconteceu.
  • Diálogos: o foco entra, fica dentro e volta para o gatilho ao fechar. O módulo a11y do Angular CDK e o elemento dialog nativo com showModal resolvem a maior parte disso. Não escreva o seu, a menos que eles não cubram o seu caso.
  • Erros de formulário: o erro fica ligado ao seu input com aria-describedby e é anunciado depois do submit. Uma borda vermelha não anuncia nada.
  • Atualizações dinâmicas: um toast ou uma contagem de resultados precisa de uma live region. No Angular, o LiveAnnouncer do CDK faz isso.
  • Widgets customizados: qualquer div com um click handler. Chegue nele com Tab, tente operá-lo com Enter e Espaço, e confira se dá para ver onde está o foco.

Teste com leitor de tela é a próxima camada. O NVDA é gratuito no Windows e o VoiceOver vem com Macs e iPhones. Meu post sobre WCAG cobre essas combinações, então não vou repetir. Coloque primeiro a passada de teclado na sua definition of done. Leva minutos e encontra muita coisa.

Não Tente Comprar a Saída com um Overlay

Um script de uma linha que promete conformidade é uma resposta tentadora para um prazo legal. Em abril de 2025, a Federal Trade Commission dos EUA finalizou uma ordem exigindo que a accessiBe pagasse 1 milhão de dólares por alegar que seu plugin conseguia deixar qualquer site em conformidade com o WCAG. A ordem proíbe esse tipo de alegação sem evidências. Um overlay roda por cima do código que tem o problema. Corrija o código.

Coisas Que os Desenvolvedores Esquecem Que Também Estão no Escopo

  • PDFs e documentos. Para o setor público federal e empresas com 500 ou mais funcionários, as regras do Canadá cobrem documentos para download, então confira seu gerador de faturas.
  • Declarações de acessibilidade. O Canadá as exige todo ano do setor público federal e de empresas com 500 ou mais funcionários, e a UE tem seus próprios deveres de informação para serviços. Descubra quem é dono disso na sua empresa antes que alguém pergunte.
  • Treinamento e registros. As regras do Canadá exigem treinamento para quem trabalha com tecnologias digitais, e manter registros por quatro anos. Não é só trabalho seu, mas levante o assunto.
  • Widgets de terceiros. O iframe de pagamento, a bolha de chat e o banner de consentimento fazem parte da página que o seu usuário precisa atravessar.

A Primeira Sprint Que Eu Faria

  • Dia 1: ligue as regras de lint, coloque as violações existentes na baseline e falhe nas novas.
  • Dia 2: corrija primeiro os componentes compartilhados. Um componente de botão ou de input corrigido resolve todos os usos de uma vez.
  • Dia 3: adicione o axe aos seus testes end-to-end nos seus três fluxos principais.
  • Dia 4: faça uma passada só com teclado nesses fluxos, e registre o que encontrar como bugs, com severidade.
  • Dia 5: adicione a passada de teclado à sua definition of done, e pergunte à sua empresa quais dessas leis se aplicam a ela.

Lint e axe não te deixam em conformidade. Eles impedem que você piore. O resto exige uma pessoa.

Referências

AccessibilityWCAGAngularReactTesting

Posts Relacionados

UX/UI Design10 min de leitura

Acessibilidade WCAG. O Mínimo Que Todo Designer Precisa Saber

Um guia prático sobre conformidade WCAG 2.2 AA cobrindo contraste de cores, navegação por teclado, labels ARIA e testes com leitores de tela, de estabelecer um design system na Strongest Families a entregar features em conformidade com acessibilidade no BMO.

AI & Development7 min de leitura

Dívida de Verificação: A IA Barateou Escrever Código, Não Confiar Nele

Um gate de cobertura pode parecer rigoroso e não garantir nada. A IA aumenta o volume de código, então provar que cada verificação consegue falhar importa mais do que adicionar novas.

Angular10 min de leitura

Apps Bilíngues no Canadá: Desafios Técnicos e de UX

Construir aplicações bilíngues EN/FR no Canadá vai muito além da tradução. Aqui estão os padrões técnicos e as decisões de UX que realmente importam quando você está desenvolvendo para os dois idiomas oficiais.