Recentemente, me deparei com uma pergunta em um fórum de discussão para meu curso de design de experiência do usuário por outro aluno.

Estou um pouco familiarizado com a ideia de atributos ARIA , mas como alguém que nunca usou um leitor de tela ou outro tipo de tecnologia assistiva, sempre tive curiosidade sobre quais impactos específicos diferentes atributos ARIA têm sobre como eles apresentam o conteúdo aos usuários .

A maioria deles é apenas à prova de futuro, caso as tecnologias assistivas decidam utilizar essas informações no futuro, ou a maioria dos atributos realmente tem um efeito tangível agora?

Exagerar nos atributos ARIA pode realmente prejudicar a experiência do usuário em alguns casos?

Aprender sobre coisas assim parece ser importante para a construção de sites acessíveis na prática e não apenas na teoria.

Acho que a maioria dos desenvolvedores tem esse entendimento de alto nível de que os atributos ARIA são importantes para usuários com deficiências. Mas como alguém que nunca precisou usar um leitor de tela, não entendo muito bem quais são as consequências quando você não configura seus atributos corretamente. É por isso que quero explorar exemplos do mundo real do que um usuário com deficiência visual ouviria quando um site não fosse configurado corretamente com atributos ARIA. Mas primeiro, precisamos entender exatamente como funciona um leitor de tela.

O que são leitores de tela e quem os utiliza?

Os leitores de tela usam síntese de texto para fala e outros métodos para ler em voz alta o conteúdo e os elementos em uma tela, como texto, botões, links e imagens, e permitem que os usuários naveguem e interajam com o conteúdo usando comandos de teclado ou outros métodos de entrada. Esse ciclo simples de navegar-ouvir-interagir permite que os usuários usem todas as funções de um site se ele for projetado com esse tipo de interação do usuário em mente.

Existem opções integradas como o VoiceOver (incluído nos sistemas operacionais macOS e iOS da Apple) e o Narrador (incluído no Microsoft Windows), bem como o plug-in do navegador que normalmente fornece recursos adicionais e personalização.

Embora a maioria pense que os leitores de tela são ruins para usuários com pouca ou nenhuma visão. Eles também são usados ​​por indivíduos com deficiências cognitivas ou de mobilidade e por indivíduos que não possuem deficiência, mas precisam acessar informações eletrônicas e sites em situações em que o acesso visual não é possível ou prático.

Exemplo 1: uma imagem

Vamos pegar esta imagem simples de um pug.

<img src="assets/images/8193903121.png"/>

      
                

                    
                    
                
            

8193903121.png, imagem

O que não fornece informações a um usuário de leitor de tela além do fato de haver uma imagem. Para corrigir isso, adicione uma alttag às imagens.

<img
  src="assets/images/8193903121.png" 
  alt="A pug wearing a red party hat with white dots"
/>

Como observação, quando um elemento html suporta essa alttag, ela deve ser usada em vez de aria-label. Aria-labelsó deve ser usado em casos especiais, como quando a divtem a propriedade role=”img”.

Exemplo 2: um botão de envio desativado

<button disabled>Let's Go!</button>

      
                

                    
                    
                
            

Vamos!, botão

Isso não informa ao usuário o que o pressionamento do botão fará ou o fato de que ele está desativado. Vamos corrigir isso:

<button aria-label="Submit email" aria-disabled="true" disabled>Let's Go!</button>

Aqui o aria-labeldescreve qual é a finalidade do botão e o aria-disabledatributo permite que o leitor de tela descreva que o botão está esmaecido e desativado no momento.

Exemplo 3: uma caixa de comentários com um rótulo

Comment:
<textarea></textarea>
<p> Your comment will be visible to all members of your organization.</p>

      
                

                    
                    
                
            

Editar texto, em branco

Para corrigir isso, precisamos associar a área de texto ao rótulo e à descrição.

<label id="comment-label" for="comment-box">Comment:</label>
<textarea 
  id="comment-box" 
  aria-labelledby="comment-label" 
  aria-describedby="comment-desc"
></textarea>
<p id="comment-desc">Your comment will be visible to all members of your organization.</p>

Aqui aria-labelledbyconecta o textareaao label, permitindo que o leitor de tela entenda que o campo está solicitando um comentário. Observe também que a forpropriedade no rótulo faz o inverso para que, quando o leitor de tela estiver focado no label, ele saiba que é um rótulo para o textarea. Por fim, aria-describedbyo atributo vincula a descrição ao arquivo textarea.

Exemplo 4: Tabela Simples

<table>
  <thead>
    <tr>
      <th>Name</th>
      <th>Quantity</th>
      <th>Rating</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th>Product 1</th>
      <td>5</td>
      <td>4.5</td>
    </tr>
    <tr>
      <th>Product 2</th>
      <td>3</td>
      <td>3.7</td>
    </tr>
  </tbody>
</table>

      
                

                    
                    
                
            

Nome: (Coluna 1 de 3)-> Quantidade: (Coluna 2 de 3)-> Classificação: (Coluna 3 de 3)-> Produto 1 -> 5 -> 4,5 -> Produto 2->3-> 3,7

Isso pode ser suficiente para alguns usuários, especialmente quando a tabela é curta. No entanto, podemos adicionar atributos Aria para melhorar significativamente esta experiência.

<table role="table" aria-label="Product Comparison">
  <thead>
    <tr>
      <th scope="col" aria-label="Product Name">Name</th>
      <th scope="col" aria-label="Product Quantity">Quantity</th>
      <th scope="col" aria-label="Product Rating">Rating</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row" aria-label="Product 1">Product 1</th>
      <td>5</td>
      <td>4.5</td>
    </tr>
    <tr>
      <th scope="row" aria-label="Product 2">Product 2</th>
      <td>3</td>
      <td>3.7</td>
    </tr>
  </tbody>
</table>

Agora, ao passar pela terceira coluna, um leitor de tela pode dizer:

Nome do produto: Produto 2->Quantidade do produto: 3-> Classificação do produto: 3,7

Obviamente, a verbosidade disso pode ser ajustada na maioria dos leitores de tela para evitar dizer os títulos das colunas se após x repetições, mas adicionar esses rótulos dá esse controle ao usuário e permite que eles escolham o quanto desejam ouvir.

Exemplo 5: uso excessivo de atributos de ária

Claro, como acontece com a maioria das coisas na vida, muito de uma coisa boa pode ser ruim.

<div 
  role="dialog" 
  aria-labelledby="modal-title" 
  aria-describedby="modal-description" 
  aria-modal="true" 
  aria-hidden="false" 
  aria-live="polite" 
  aria-atomic="true"
>
  <h2 id="modal-title">Modal Title</h2>
  <p id="modal-description">This is a modal window that contains important information for the user.</p>
  {...}
</div>

O futuro da ÁRIA

À medida que a Web continua a evoluir e se tornar mais complexa, o ARIA continuará a desempenhar um papel crucial em tornar os aplicativos da Web acessíveis e fáceis de usar para usuários de tecnologias assistivas, como leitores de tela e navegação por teclado.

Uma das principais áreas em que o ARIA provavelmente terá maior desenvolvimento é o suporte a novas tecnologias da Web e padrões de design . Por exemplo, à medida que mais aplicativos da Web passam a usar arquiteturas de página única e JavaScript assíncrono, o ARIA precisará fornecer novos atributos e técnicas para tornar esses aplicativos acessíveis a usuários de tecnologia assistiva.

Outra área importante para o futuro do ARIA é melhorar a interoperabilidade e compatibilidade dos atributos ARIA em diferentes navegadores e tecnologias assistivas . Atualmente, existem algumas inconsistências e diferenças em como diferentes navegadores e tecnologias assistivas interpretam e usam atributos ARIA. Trabalhar para uma implementação mais consistente e padronizada do ARIA na Web será fundamental para melhorar a experiência do usuário para usuários de tecnologia assistiva.

Por fim, o futuro do ARIA também envolverá colaboração e diálogo contínuos entre desenvolvedores da Web, especialistas em acessibilidade e usuários de tecnologia assistiva . À medida que surgem novos desafios e oportunidades no mundo da acessibilidade na Web, será importante que essas partes interessadas trabalhem juntas para identificar e abordar possíveis problemas e desenvolver novas soluções que possam beneficiar todos os usuários da Web.

No geral, o futuro do ARIA parece brilhante e promissor. À medida que a Web continua a evoluir, o ARIA desempenhará um papel crucial em torná-la mais acessível e fácil de usar para todos. Os desenvolvedores da Web devem:

1. Use atributos e técnicas ARIA para fornecer contexto e funcionalidade adicionais para tecnologias assistivas.
2. Forneça rótulos e descrições claras e descritivas para todos os elementos e controles.
3. Use elementos HTML semânticos para transmitir com precisão a estrutura e o conteúdo da página.
4. Certifique-se de que o conteúdo esteja devidamente estruturado e organizado, com hierarquia e relacionamentos claros entre os elementos.
5. Use cor e contraste criteriosamente para garantir que o conteúdo seja legível e visível para usuários com baixa visão.
6. Forneça acessibilidade de teclado, permitindo que os usuários naveguem e interajam com a página usando apenas um teclado ou outro dispositivo de entrada.
7. Teste o aplicativo com tecnologias assistivas para garantir que ele seja utilizável e acessível.

Existem muitos outros atributos ARIA que não mostrei aqui. Veja uma lista completa deles aqui:https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes

Observe que o ChatGPT foi usado para pesquisa e para escrever algumas partes deste artigo.