Dicas práticas de acessibilidade que você pode aplicar hoje

Todos nós já passamos por isso — correndo para cumprir um prazo, criamos um menu suspenso ou modal sem considerar totalmente sua acessibilidade. Mas e se fazer algumas pequenas mudanças pudesse melhorar drasticamente a experiência para uma gama maior de usuários? Acessibilidade não precisa ser uma tarefa assustadora ou uma caixa de conformidade para marcar. Trata-se de criar produtos que sejam utilizáveis ​​por todos, não importa sua habilidade, conhecimento técnico, sistema operacional ou dispositivo.

Neste artigo, compartilharei conselhos práticos sobre como marcar três padrões comuns de IU da maneira correta. Não importa se você é novo em acessibilidade ou precisa apenas de uma atualização, essas dicas ajudarão você a criar interfaces mais inclusivas. Também coloco links para implementações e recursos externos para que você possa experimentar em primeira mão como essas mudanças afetam a usabilidade. Você verá como alguns ajustes bem pensados ​​podem fazer toda a diferença.

Menus suspensos

Os menus suspensos são um dos elementos de IU mais comumente usados ​​na web. De barras de navegação a sistemas de filtragem, eles facilitam a apresentação de várias opções de forma limpa e compacta. Mas, embora os menus suspensos possam parecer simples, eles geralmente são construídos de uma forma que deixa muitos usuários incapazes de interagir com eles de forma eficaz.

O problema

O problema com muitos dropdowns é que eles são construídos com elementos genéricos como <div>ou <span>com interação tipicamente manipulada por JavaScript. Embora isso possa funcionar para um usuário de mouse, alguém usando um teclado, leitor de tela ou outra tecnologia assistiva terá dificuldades. Se os dropdowns não forem marcados corretamente, os usuários podem nem saber que as opções existem ou podem não conseguir navegar por elas.

A correção

Para tornar os menus suspensos mais acessíveis, o primeiro passo é usar HTML semântico. Isso significa usar elementos que comuniquem seu propósito ao navegador e às tecnologias assistivas. Nesse caso, usar um <button>para o gatilho suspenso e um <ul>para a lista de opções fornece a estrutura que as tecnologias assistivas precisam para interpretar o menu corretamente.

Em seguida, você vai querer adicionar atributos ARIA (Accessible Rich Internet Applications) como aria-expanded e aria-controls. Esses atributos dão aos leitores de tela contexto adicional, como se o menu está aberto ou fechado e qual elemento controla o menu suspenso.

<button aria-haspopup="true" aria-expanded="false" aria-controls="menu1">Options</button>  
<ul id="menu1" role="menu" aria-hidden="true">  
  <li role="menuitem">Option 1</li>  
  <li role="menuitem">Option 2</li>  
</ul>  

Vamos dividir:

• O <button>elemento com aria-haspopup="true"sinais para tecnologias assistivas de que este botão abrirá um menu suspenso.
• aria-expanded="false"informa ao usuário que o menu está fechado no momento. Este valor mudará dinamicamente para true quando o menu for aberto.
• A <ul>tag, com seu role="menu", garante que a lista seja reconhecida como um menu pelos leitores de tela.
• Cada <li>elemento possui role="menuitem", permitindo que os leitores de tela tratem esses itens de lista como opções de menu.
• aria-hidden="true"mantém o menu oculto até que o usuário o ative, quando então ele deve ser removido.

Essas pequenas alterações significam que os usuários não apenas podem interagir com seu menu suspenso via teclado, mas também podem receber feedback por meio de seus leitores de tela sobre o estado do menu suspenso.

Diálogos modais

Os modais são extremamente úteis para exibir informações importantes ou capturar a entrada do usuário sem navegar para fora da página. No entanto, sem o gerenciamento de foco correto, eles podem ser incrivelmente frustrantes para usuários que dependem de leitores de tela ou teclados.

O problema

Um erro comum com modais é não gerenciar o foco corretamente. Quando um modal é aberto, os usuários precisam estar focados em interagir dentro dele, mas em muitos casos, o foco não fica preso corretamente dentro do modal. Isso permite que os usuários naveguem pelo restante do conteúdo da página, o que pode ser desorientador. Pior, os usuários podem nem perceber que estão em um modal, dificultando saber como fechá-lo.

A correção

A chave para tornar os modais mais acessíveis é prender o foco dentro do próprio modal. Isso significa que quando um modal é aberto, a navegação pelo teclado deve circular apenas pelos elementos dentro do modal até que ele seja fechado. Isso evita que os usuários naveguem acidentalmente para o conteúdo atrás do modal e garante que eles permaneçam focados na tarefa em questão.

Você pode gerenciar adequadamente o focus trapping com JavaScript, que detecta quando o modal é aberto e garante que o foco permaneça dentro. Além disso, adicionar atributos ARIA como role="dialog"e aria-modal="true"fornece aos leitores de tela o contexto necessário sobre a função e o comportamento do modal.

<div role="dialog" aria-modal="true" aria-labelledby="modal-title">  
    <h1 id="modal-title">Sign Up</h1>  
    <button>Close</button>  
    <!-- Modal content -->  
</div>  

Vamos dividir:

• role="dialog"informa às tecnologias assistivas que esta é uma janela de diálogo.
• aria-modal="true"garante que os leitores de tela entendam que os usuários não devem interagir com conteúdo fora do modal até que ele seja fechado.
• aria-labelledby="modal-title"ajuda os usuários a saber qual é o propósito do diálogo associando-o ao título do modal.

Para sua informação

O elemento HTML<dialog> será fornecido role="dialog"gratuitamente, mas você ainda precisará definir aria-modal="true"para garantir que os leitores de tela entendam que os usuários não devem interagir com conteúdo fora do modal até que ele seja fechado.

Além disso, o JavaScript deve ser usado para gerenciar o foco. Quando o modal abre, o foco deve ser enviado automaticamente para o primeiro elemento interativo, como um campo de formulário ou um botão de fechar. Quando os usuários pressionam a tabtecla, o foco deve percorrer os elementos interativos dentro do modal sem sair dele. Finalmente, pressionar a esctecla deve fechar o modal.

Os princípios básicos do seu JavaScript para gerenciamento de foco devem garantir que, quando um modal for aberto, o primeiro elemento interativo dentro dele (como um botão ou campo de entrada) receba o foco, guiando os usuários do teclado diretamente para o conteúdo. Conforme o usuário navega pelo modal usando a tabtecla, o foco fica preso dentro do modal, alternando entre o primeiro e o último elementos focáveis. Se o usuário tentar sair do modal, o script deve evitar isso redirecionando o foco para a extremidade oposta, dependendo da direção da tabulação. Quando o modal é fechado, você precisa retornar o foco para o botão que o abriu, garantindo uma experiência de usuário suave e lógica.

Interfaces com abas

Interfaces com abas são uma ótima maneira de organizar conteúdo sem sobrecarregar os usuários, mas somente se forem estruturadas corretamente. Quando a navegação por abas é construída de forma inadequada, usuários que dependem da navegação por teclado ou leitores de tela podem achar difícil entender qual aba está selecionada e como navegar entre diferentes seções.

O problema

Muitas interfaces com abas usam tags básicas <div>ou <span>para botões de abas, que não fornecem contexto para tecnologias assistivas. Sem funções ARIA, leitores de tela não podem informar aos usuários que uma aba faz parte de um conjunto maior de abas ou qual conteúdo corresponde à aba selecionada. Além disso, usuários que dependem de teclados podem achar impossível navegar entre abas sem a funcionalidade de tecla de seta.

A correção

Para corrigir isso, use uma combinação de funções e propriedades ARIA. Especificamente, role="tablist"define o contêiner para todas as guias, role="tab"identifica cada guia e role="tabpanel”especifica o conteúdo para cada guia. Além disso, implemente a navegação por teclado para que os usuários possam alternar as guias usando as teclas de seta, tornando a experiência perfeita.

<div role="tablist" aria-label="Sample Tabs">  
  <button role="tab" aria-selected="true" aria-controls="panel1" id="tab1">Tab 1</button>  
  <button role="tab" aria-selected="false" aria-controls="panel2" id="tab2">Tab 2</button>  
</div>  
<div id="panel1" role="tabpanel" aria-labelledby="tab1">  
  <p>Content for Tab 1.</p>  
</div>  
<div id="panel2" role="tabpanel" aria-labelledby="tab2">  
  <p>Content for Tab 2.</p>  
</div>  

Vamos dividir:

• role="tablist"informa aos leitores de tela que o contêiner contém um conjunto de guias.
• Cada role="tab"botão faz parte da lista de guias e é vinculado ao conteúdo da guia correspondente usando aria-controls.
• aria-selected="true"denota qual aba está ativa no momento. Apenas uma aba deve ter esse atributo definido como true por vez.
• role="tabpanel"garante que os leitores de tela possam navegar pelo conteúdo da guia. aria-labelledbyvincula o painel de guias de volta à guia associada para fornecer um contexto claro.

Para garantir a acessibilidade do teclado, os usuários devem ser capazes de alternar entre as guias usando as teclas de seta, o que imita o comportamento que eles esperam de outras interfaces. Além disso, o foco deve se mover para o conteúdo da guia ativa quando uma nova guia for selecionada.

Para saber mais sobre como criar interfaces com abas acessíveis, confira este excelente recurso da Inclusive Components.

Encerrando

Construir padrões de UI acessíveis não precisa ser complicado, mas requer atenção aos detalhes e um comprometimento com a empatia. Como você viu, algumas pequenas mudanças — como usar HTML semântico, adicionar funções ARIA e gerenciar o foco corretamente — podem tornar suas interfaces muito mais inclusivas. Se quisermos criar uma web que funcione para todos, precisamos priorizar a acessibilidade em todas as decisões que tomamos.