Acessibilidade web (WCAG) é o tipo de tema que todo mundo concorda que é crucial, mas que raramente recebe a atenção prática que merece durante a nossa formação. Seja na faculdade ou na grande maioria dos cursos de desenvolvimento, o assunto ou é completamente ignorado ou é tratado de forma puramente teórica. São raros os conteúdos que mostram como aplicar as diretrizes da WCAG na realidade de um framework componentizado.

Recentemente, passei pela experiência de implementar conformidade com a WCAG em um sistema corporativo real utilizando as versões mais recentes do Angular. Neste artigo, vamos entender o que é essa sopa de letrinhas, por que ela importa e como aplicar 4 abordagens práticas no ecossistema do Angular moderno.

Entendendo a WCAG: O que é e por que devemos nos importar?

WCAG significa Web Content Accessibility Guidelines (Diretrizes de Acessibilidade para Conteúdo Web). Desenvolvido pelo W3C (World Wide Web Consortium), trata-se do padrão ouro global que define como tornar o conteúdo da web mais acessível para pessoas com deficiências visuais, auditivas, físicas, cognitivas e neurológicas.

As diretrizes são organizadas sob 4 princípios fundamentais conhecidos como POUR:

  1. Perceptível: A informação e os componentes da interface devem ser apresentados de forma que os usuários possam percebê-los (ex: texto alternativo para imagens, contraste adequado).
  2. Operável: Os componentes da interface e a navegação devem ser operáveis através de diferentes dispositivos (ex: navegação completa apenas via teclado, sem armadilhas de foco).
  3. Compreensível: A informação e a operação da interface devem ser fáceis de entender (ex: mensagens de erro claras em formulários).
  4. Robusto: O conteúdo deve ser robusto o suficiente para ser interpretado de forma confiável por uma ampla variedade de tecnologias assistivas (como leitores de tela).

Por que devemos seguir a WCAG?

  • Inclusão e Alcance: Desenvolver pensando na WCAG garante que o seu software possa ser utilizado por qualquer pessoa, independentemente de suas limitações permanentes, temporárias ou situacionais.
  • Qualidade de Engenharia: Código acessível exige HTML semântico. Interfaces acessíveis possuem uma estrutura de árvore do DOM muito mais limpa, o que melhora indiretamente o SEO (Search Engine Optimization) e a manutenibilidade do projeto.
  • Conformidade Legal: Em escala global, governos e empresas estão tornando a acessibilidade um requisito obrigatório por lei. Negligenciar a WCAG pode resultar em barreiras comerciais e até processos jurídicos para sistemas corporativos.

Longe da teoria dos slides, o jogo muda quando precisamos abrir o repositório. Vamos ao código.

1. Atributos ARIA Dinâmicos com Signals

Acessibilidade em Single Page Applications (SPAs) precisa ser reativa. Quando o estado da interface muda, o leitor de tela precisa ser notificado imediatamente.

Em formulários de login, por exemplo, a ação de alternar a visibilidade da senha exige que o aria-label mude dinamicamente para que o usuário saiba exatamente o que o botão fará a seguir. Com a reatividade dos Signals, conseguimos vincular isso diretamente ao DOM utilizando o prefixo attr..

<div class="input-group">
  <input 
    [type]="showPassword() ? 'text' : 'password'" 
    id="password" 
    formControlName="password" 
  />
  <button 
    type="button"
    [attr.aria-label]="showPassword() ? 'Esconder senha' : 'Mostrar senha'"
    (click)="togglePasswordVisibility()"
  >
    <i [class]="showPassword() ? 'pi pi-eye-slash' : 'pi pi-eye'"></i>
  </button>
</div>

Enter fullscreen mode Exit fullscreen mode

2. Navegação por Teclado e Gerenciamento de Foco

Um dos maiores problemas de acessibilidade na web moderna é a quebra de navegação por teclado. Elementos nativos como <button> e <a> já possuem comportamento de foco nativo, mas quando criamos componentes customizados (como timelines ou itens de menu baseados em div), eles ficam invisíveis para a tecla Tab.

Para resolver isso, precisamos injetar explicitamente o tabindex="0" (colocando o elemento na sequência natural de tabulação) e capturar os eventos de teclado correspondentes ao clique (Enter ou Espaço).

<div 
  class="timeline-item" 
  tabindex="0"
  role="button"
  (click)="selectEvent(event)"
  (keydown.enter)="selectEvent(event)"
>
  <div class="timeline-marker"></div>
  <div class="timeline-content">
    <h3>{{ event.title }}</h3>
    <p>{{ event.description }}</p>
  </div>
</div>

Enter fullscreen mode Exit fullscreen mode

3. Papéis Semânticos (Roles) Explícitos para Interfaces Ricas

Quando a árvore do DOM é gerada através de múltiplos componentes aninhados do Angular, a semântica nativa do HTML pode se perder facilmente em meio a um mar de tags customizadas e invólucros estruturais.

Se você está construindo estruturas complexas, como uma barra de navegação ou um menu de configurações, o uso do atributo role ajuda o leitor de tela a mapear a árvore de acessibilidade corretamente.

<nav class="sidebar-menu" role="menu">
  @for (item of menuItems(); track item.id) {
    <div class="menu-item" role="menuitem" tabindex="0" (keydown.enter)="navigate(item.path)">
      <i [class]="item.icon"></i>
      <span>{{ item.label }}</span>
    </div>

    @if (item.hasSeparator) {
      <div class="menu-separator" role="separator"></div>
    }
  }
</nav>

Enter fullscreen mode Exit fullscreen mode

4. Alternativas de Texto para Botões Apenas com Ícones

Botões que contêm apenas ícones (como botões de busca com uma lupa, exclusão com uma lixeira ou fechamento com um "X") são visualmente limpos, mas completamente mudos para um leitor de tela se não forem tratados. O software de acessibilidade tentará ler a classe CSS do ícone (ex: pi-search), resultando em uma experiência confusa.

Adicionar um aria-label descritivo garante que a função do botão seja anunciada perfeitamente.

<button 
  type="button" 
  class="p-button-rounded"
  aria-label="Pesquisar registros"
  (click)="executeSearch()"
>
  <i class="pi pi-search"></i>
</button>

Enter fullscreen mode Exit fullscreen mode

Conclusão e Fluxo de Testes

Escrever código acessível não aumenta a complexidade da sua arquitetura; pelo contrário, força a escrita de um HTML mais limpo, semântico e robusto. Acessibilidade não é uma feature secundária para entregar no final do projeto, é parte fundamental da qualidade da engenharia do software.

Para validar essas implementações no dia a dia, recomendo fortemente integrar testes manuais ao seu fluxo de desenvolvimento:

  1. Desconecte o mouse: Tente realizar o fluxo principal do seu sistema (como autenticação e navegação) usando apenas as teclas Tab, Shift + Tab e Enter.
  2. Use Leitores Reais: Utilize ferramentas como o NVDA (Windows) ou o VoiceOver (macOS) em conjunto com o navegador para ouvir como a sua aplicação está se comportando em tempo real.

O ecossistema do Angular nos dá todas as ferramentas necessárias para criar aplicações inclusivas. Cabe a nós, desenvolvedores, virar a chave da teoria para a prática.