Como a WAI-ARIA pode tornar as aplicações acessíveis

Apesar de organizado, esse exemplo não considera pessoas que navegam por leitores de tela ou por teclado, diminuindo muito a acessibilidade da nossa aplicação.

Vamos analisar alguns pontos importantes? Vem comigo:

• Falta de semântica para tecnologias assistivas: O código usa elementos <div> e <button> genéricos sem roles ARIA que especificariam seus papéis, como role="tab" para os botões e role="tabpanel" para os conteúdos das abas. Isso dificulta para as tecnologias assistivas entenderem a estrutura de tabs e como os elementos estão relacionados.

• Navegação por teclado incompleta: Embora os botões possam ser focados usando a tabulação do teclado, nosso exemplo não implementa uma maneira de alternar entre as abas usando apenas o teclado (por exemplo, através das teclas de seta), o que é uma prática recomendada para a acessibilidade de componentes de tabs.

• Indicação de estado: Não há indicação (como aria-selected="true") que informe qual aba está atualmente ativa para usuários de leitores de tela. Isso torna a experiência de navegação confusa para quem depende de feedback auditivo.

• Indicação de conteúdo dinâmico ausente: Não há uso de ARIA live regions para informar as pessoas sobre mudanças no conteúdo dinâmico que ocorrem quando uma nova aba é selecionada. Isso significa que usuários de leitores de tela podem não ser notificados quando o conteúdo da aba muda.

• Estrutura de navegação: A falta de uma estrutura semântica clara e de landmarks dificulta para as pessoas usuárias de tecnologias assistivas entenderem a organização do conteúdo e navegarem de forma eficiente pela aplicação.

A preocupação com a acessibilidade é fundamental, especialmente quando se trabalha com componentes que não são elementos HTML nativos, como nossas tabs. E é aqui que o WAI-ARIA entra em cena, oferecendo uma maneira de tornar esses componentes personalizados acessíveis, adicionando roles, propriedades e estados específicos que comunicam sua função e estado para tecnologias assistivas.

Vamos atualizar nosso exemplo, implementando WAI-ARIA para torná-lo acessível:

Ao introduzir o WAI-ARIA (nesse exemplo, os atributos: role, aria-selected, aria-labelledby), não só melhoramos a acessibilidade do nosso componente de tabs, mas também damos um passo significativo para garantir que nossa aplicação seja mais inclusiva.

Este artigo é um convite para explorarmos juntos o universo do WAI-ARIA. Ao longo dele, desvendaremos como essa poderosa ferramenta pode transformar a acessibilidade das nossas aplicações web, tornando-as verdadeiramente acessíveis para todas as pessoas, independentemente de suas características. Vem comigo?

O que é WAI ARIA

WAI-ARIA, ou simplesmente ARIA, é uma especificação técnica desenvolvida pelo W3C, com o objetivo de melhorar a acessibilidade de aplicações web.

ARIA é uma sigla e significa Accessible Rich Internet Applications, ou em Português: Aplicações avançadas de internet acessíveis.

Seu papel é fornecer maneiras de tornar o conteúdo e os componentes da web mais acessíveis a pessoas com deficiências.

Em sua essência, ARIA permite que pessoas que fazem os códigos do desenvolvimento web comuniquem a funcionalidade e o estado de elementos interativos e dinâmicos para tecnologias assistivas, como leitores de tela.

Isso é feito através do uso de atributos especiais que podem ser adicionados ao HTML.

Para ilustrar a importância do WAI-ARIA na melhoria da acessibilidade de aplicações web, vamos considerar um exemplo prático: um carrossel de imagens.

Carrosséis são elementos comuns em websites, usados para exibir uma coleção de imagens, notícias ou outros conteúdos em um espaço compacto, permitindo que o usuário navegue entre eles.

Apesar de visualmente atraentes e funcionais, carrosséis construídos apenas com HTML e JavaScript podem ser inacessíveis para usuários que dependem de leitores de tela, porque estes usuários não recebem informações adequadas sobre como interagir com o carrossel ou sobre o conteúdo que está sendo exibido.

Por que fica inacessível?

Um carrossel típico é composto por um conjunto de imagens que o usuário pode navegar clicando em botões de próximo e anterior ou através de indicadores de slide.

Sem o uso de ARIA, esses controles e o estado dinâmico do carrossel (como qual imagem está atualmente em foco) não são comunicados de forma eficaz aos leitores de tela.

Isso significa que um usuário de leitor de tela pode não saber que está interagindo com um carrossel, quais ações podem ser tomadas (como navegar entre as imagens) e qual imagem está sendo exibida no momento.

Como tornar o carrossel acessível com WAI-ARIA

Para tornar o carrossel acessível, podemos utilizar os atributos ARIA para descrever a funcionalidade e o estado do carrossel para as tecnologias assistivas. Veja como isso pode ser feito:

• Roles: Usar role="listbox" para o contêiner principal do carrossel indica que ele contém uma lista de itens selecionáveis (as imagens). Cada imagem pode ser marcada com role="option" para indicar que são itens individuais dentro da lista.

• Propriedades e estados: Atributos como aria-selected="true" podem ser usados para indicar qual imagem está atualmente selecionada.

Além disso, aria-live="polite" pode ser adicionado ao contêiner da imagem para informar ao usuário de tecnologia assistiva sobre mudanças no conteúdo dinâmico, como quando uma nova imagem é trazida ao foco, de maneira não intrusiva.

Vamos ver a marcação HTML como fica?

A implementação de ARIA transforma um carrossel visualmente funcional em um componente totalmente acessível, permitindo que usuários de tecnologias assistivas naveguem e interajam com ele tão eficazmente quanto qualquer outro usuário.

Este exemplo destaca o papel vital que o WAI-ARIA desempenha na ponte sobre as lacunas de acessibilidade em componentes de interface rica na web.

Roles

Imagine um escritório grande, com muitas pessoas trabalhando em diferentes funções: temos gestão, desenvolvimento, atendimento ao cliente, e assim por diante.

Cada uma dessas pessoas usa um crachá que não apenas apresenta o nome, mas também descreve sua função.

Esse crachá ajuda todos a entenderem rapidamente quem faz o quê, facilitando a interação e a colaboração.

Na web, as "roles" do WAI-ARIA atuam como esses crachás. Quando adicionamos uma role a um elemento, estamos essencialmente colocando um “crachá virtual” nele, que diz para os leitores de tela e outras tecnologias assistivas: "Ei, aqui está um botão!" ou "Olha, isso é uma tab!".

Isso permite que os usuários de tecnologias assistivas compreendam o propósito de cada elemento na página, orientando suas interações de forma mais intuitiva, assim como saber a função de cada colega facilita a interação no escritório.

Widgets são elementos com os quais as pessoas conseguem interagir na aplicação, como por exemplo: botões, sliders, caixas de seleção e outros controles. da interface que permitem ao usuário interagir com a aplicação, como botões, sliders, caixas de seleção e outros controles.

No contexto do WAI-ARIA, especificar o papel (role) de um widget é crucial para assegurar que esses controles sejam acessíveis a tecnologias assistivas

Tecnicamente as roles são atributos que você adiciona diretamente ao seu HTML. Elas oferecem uma indicação clara sobre a função de cada elemento, permitindo que as tecnologias assistivas interpretem corretamente a interface do usuário.

Isso é especialmente útil em casos onde elementos genéricos do HTML são usados para criar componentes interativos complexos. Já conhecemos algumas no nosso exemplos, mas vamos ver mais algumas:

• alert: Indica um alerta importante e, geralmente, temporário.
• button: Representa um botão.
• checkbox: Denota um controle do tipo caixa de seleção.
• dialog: Usado para marcar uma caixa de diálogo ou janela popup.
• grid: Identifica uma grade ou tabela complexa.
• link: Aplica-se a um elemento que deveria ser usado como um link.
• menu: Marca uma lista de opções.
• progressbar: Indica o progresso de uma tarefa.
• radio: Representa um botão de opção.
• slider: Denota um controle deslizante.
• tab: Usado para um dos botões em um conjunto de tabs.
• tablist: Identifica um conjunto de tabs. É usado para agrupar uma coleção de tabs, facilitando a navegação entre diferentes seções de conteúdo relacionadas.
• tabpanel: Indica o painel de conteúdo associado a um tab.
• textbox: Identifica uma caixa de texto onde o usuário pode inserir dados.
• tooltip: Fornece uma descrição adicional ou contextual para um elemento.

Essa lista é muito extensa, você pode conferir ela na integra aqui na documentação da W3C.

Properties

Continuando com nossa analogia do escritório, se as "roles" do WAI-ARIA são como crachás que identificam a função de cada profissional, as "properties" seriam como as informações adicionais que acompanham esses crachás, como o status do projeto em que estão trabalhando, se estão disponíveis para uma reunião ou se têm alguma tarefa específica naquele momento.

Essas informações complementares ajudam a entender não apenas quem é a pessoa e qual é sua função, mas também qual é seu estado atual e como você pode interagir com ela.

Da mesma forma as properties do WAI-ARIA complementam as roles ao fornecer detalhes adicionais sobre os elementos.

Por exemplo, uma property pode informar se um botão está ativado ou desativado (aria-disabled="true"), ou se um item de menu está selecionado (aria-selected="true").

Essas informações são cruciais para as tecnologias assistivas, pois não apenas identificam o que é um elemento (a sua "role"), mas também descrevem seu estado atual ou como ele deve ser tratado, tornando a navegação mais rica e intuitiva para todos os usuários.

Vamos ver alguns exemplos de properties?

• aria-disabled: Indica se a interação com o elemento está desabilitada.
• aria-expanded: Mostra se um elemento que pode ser expandido está aberto ou fechado.
• aria-hidden: Comunica se um elemento está visivelmente oculto ou não para o usuário.
• aria-label: Fornece uma string de texto que rotula o elemento atual.
• aria-labelledby: Identifica o(s) elemento(s) que rotulam o elemento atual.
• aria-controls: Aponta para o(s) elemento(s) controlado(s) pelo elemento atual.
• aria-selected: Indica se o item está selecionado em um conjunto de itens selecionáveis.

Essas properties são ferramentas poderosas para criar interfaces ricas e acessíveis, garantindo que os usuários de tecnologias assistivas recebam todas as informações necessárias para navegar e interagir com conteúdo web de forma efetiva.

States

States, ou estados, são atributos dinâmicos que comunicam mudanças de estado nos elementos de uma interface web.

Diferente das properties, que tendem a ser estáticas ou configuradas uma única vez (como aria-disabled), os states refletem alterações em tempo real no comportamento ou na apresentação de um componente, informando às tecnologias assistivas sobre essas mudanças conforme ocorrem.

Os states são cruciais para a acessibilidade, pois permitem que usuários de leitores de tela e outras tecnologias assistivas entendam o que está acontecendo em uma aplicação web dinâmica.

Por exemplo, um botão que pode ser pressionado ou liberado, um item que pode ser selecionado ou desselecionado, ou um menu que está expandido ou colapsado, todos representam estados que podem mudar em resposta à interação do usuário.

Bora conhecer alguns states?

• aria-checked: Indica se um item do tipo caixa de seleção, rádio ou interruptor está selecionado ou não.
• aria-busy: Comunica se um elemento está em processo de carregamento ou em operação, o que pode ser útil para indicar atividade ou progresso.
• aria-expanded: Mostra se um elemento que pode ser expandido ou colapsado, como um menu dropdown ou um painel de acordeão, está aberto ou fechado. Embora listado sob properties, devido à sua natureza dinâmica, ele também funciona como um state.
• aria-hidden: Embora possa ser usado como uma property estática, também pode atuar como um state para indicar quando um elemento se torna visível ou invisível dinamicamente.

Nota: Você pode encontrar uma lista útil de todas as roles de ARIA e seus usos, com links para informações adicionais, na especificação WAI-ARIA — veja a definição de roles — neste site — veja roles de ARIA.

A especificação também contém uma lista de todas as propriedades e estados, com links para informações adicionais — veja definições de estados e propriedades (todos os atributos aria-*).

Quando devemos usar o WAI-ARIA?

Já tocamos no assunto sobre os problemas que levaram à criação do WAI-ARIA anteriormente, mas, essencialmente, existem quatro áreas principais onde o WAI-ARIA se mostra útil:

Signposts/Landmarks ("marcos" / "pontos de referência")

Os valores do atributo role do ARIA podem atuar como landmarks que replicam a semântica de elementos HTML (por exemplo, <nav>), ou vão além da semântica do HTML para fornecer sinalizações para diferentes áreas funcionais, como pesquisa, tablist, tab, listbox, etc.

Com as roles que aprendemos, agora podemos adicionar valor semântico extra aos nossos elementos, se forem necessários.

Principalmente quando queremos fornecer informações adicionais para leitores de tela, permitindo que seus usuários possam encontrar elementos comuns da página. Vamos analisar um exemplo que não implementa roles:

Um leitor de tela em um navegador moderno já vai conseguir tirar algumas informações úteis do site como, por exemplo:

• No elemento <header> — "cabeçalho, 2 itens" (contém um cabeçalho e o <nav>).
• No elemento <nav> — "navegação, 2 itens" (contém uma lista e um formulário).
• No elemento <main> — "principal, 2 itens" (contém uma seção e um aside).
• No elemento <aside> — "complementar, 2 itens" (contém um cabeçalho e uma lista).
• No input do formulário de busca — "Consulta de busca, inserção no início do texto".
• No elemento <footer> — "rodapé, 1 item".

Mas podemos melhorar isso. O formulário de busca é uma landmark que merece destaque, mas ele não está listado ou tratado de alguma forma especial, além do próprio input ser identificado como um input de busca (<input type="search">).

Vamos adicionar algumas funcionalidades do ARIA. Começamos com detalhes simples e importantes, adicionando alguns atributos role, assim:

Aqui tem um ponto muito importante — o elemento <input> recebeu o atributo aria-label, que fornece uma etiqueta (label) descritiva para ser lida pelo leitor de tela, mesmo que não tenhamos incluído um elemento <label> no html. Em casos como esses, isso é muito útil.

Agora, se usarmos o leitor de tela para olhar este exemplo, obtemos algumas melhorias:

• O formulário de busca é destacado como um item separado, tanto ao navegar pela página quanto no menu de Marcos.
• O texto da etiqueta contido no atributo aria-label é lido quando o input do formulário é destacado.

Atualizações de conteúdo dinâmico

O conteúdo carregado no DOM pode ser facilmente acessado por meio de leitores de tela, desde conteúdo textual até texto alternativo anexado à imagens.

Por isso, websites tradicionais estáticos, com conteúdo majoritariamente textual, são relativamente simples de tornar acessíveis para pessoas com deficiências visuais.

No entanto, os aplicativos web modernos frequentemente não se limitam a texto estático — eles costumam atualizar partes da página buscando novo conteúdo do servidor e atualizando o DOM. Essas áreas são às vezes chamadas de regiões ao vivo.

Vamos pensar num exemplo, um gerador de frases ditas por algum personagem da TV:

Nosso JavaScript utiliza a API fetch() para carregar um arquivo JSON contendo uma série de citações aleatórias dos personagens.

Uma vez carregado, iniciamos um loop com setInterval() que atualiza a caixa de citações com uma nova frase a cada 10 segundos:

Isso funciona, mas deixa a desejar em acessibilidade — a atualização do conteúdo não é detectada por leitores de tela, então seus usuários não ficam sabendo o que está acontecendo.

Esse exemplo pode parecer simples, mas imagine se você estivesse criando uma interface complexa com conteúdo que atualiza constantemente, como um chat, uma interface de usuário para um jogo de estratégia, ou um display de carrinho de compras que atualiza em tempo real — seria impossível usar o aplicativo de maneira eficaz sem algum recurso que alertasse o usuário sobre as atualizações.

Felizmente, o WAI-ARIA oferece um mecanismo útil para fornecer esses alertas — a propriedade aria-live.

Aplicar isso a um elemento faz com que leitores de tela anunciem o conteúdo que foi atualizado. A urgência com que o conteúdo é lido depende do valor do atributo:

• off: O padrão. Atualizações não devem ser anunciadas.
• polite: Atualizações devem ser anunciadas apenas se o usuário não estiver ocupado.
• assertive: Atualizações devem ser anunciadas o mais rápido possível. Gostaríamos que você pegasse uma cópia de aria-no-live.html e quotes.json, e atualizasse a tag de abertura da sua
  da seguinte forma:

Há uma consideração adicional aqui — apenas o trecho de texto que atualiza é anunciado. Seria interessante se sempre lêssemos o cabeçalho também, para que o usuário se lembre do que está sendo lido.

Para fazer isso, podemos adicionar a propriedade aria-atomic à seção. Atualize sua tag de abertura <section> novamente, assim:

O atributo aria-atomic="true" instrui os leitores de tela a lerem o conteúdo inteiro do elemento como uma unidade única, e não apenas as partes que foram atualizadas.

Aprimoramento da acessibilidade por teclado

Existem elementos HTML integrados que possuem acessibilidade nativa ao teclado; quando outros elementos são usados juntamente com o JavaScript para simular interações semelhantes, a acessibilidade por teclado e a comunicação com leitores de tela sofrem como resultado.

Onde isso é inevitável, o WAI-ARIA fornece um meio para permitir que outros elementos recebam foco (usando tabindex).

Geralmente, a gente pode navegar entre controles usando a tecla Tab do teclado, selecionar ou ativar controles com a tecla Enter e, em alguns casos, usar outras teclas (como as setas para cima e para baixo para navegar entre opções em um campo <select>).

Às vezes, nos encontramos em situações onde precisamos adaptar nosso código para cumprir requisitos específicos.

Isso pode envolver o uso de elementos HTML que, por natureza, não carregam significado semântico adequado para a função que precisam desempenhar, como transformar <div>s em botões interativos.

Ou, em outros casos, pode ser necessário adaptar elementos já focáveis de uma forma que originalmente não foram projetados para ser usados. Essas situações podem surgir ao lidar com códigos antigos que precisam de melhorias ou ao criar componentes complexos que vão além das capacidades dos elementos HTML padrão.

Para transformar código não focável em focável podemos usar o tabindex:

• tabindex="0": como indicado anteriormente, esse valor permite que elementos que normalmente não são navegáveis por tabulação tornem-se navegáveis. Esse é o valor mais útil de tabindex.
• tabindex="-1": isso permite que elementos normalmente não navegáveis recebam foco programaticamente, por exemplo, via JavaScript, ou como alvo de links.

Imagine que você está construindo uma galeria de imagens customizada e deseja que as imagens sejam focáveis para que os usuários possam selecioná-las usando apenas o teclado, mas sem que essas imagens sejam focadas ao navegar com a tecla Tab para não interromper o fluxo de navegação normal:

No exemplo acima, as imagens na galeria podem ser focadas programaticamente (por exemplo, quando o usuário clica em uma imagem, você pode querer focá-la para indicar que está selecionada), mas não serão focadas ao usar a navegação por tabulação, graças ao tabindex="-1".

Isso mantém a usabilidade para usuários de teclado sem sacrificar a funcionalidade para usuários de tecnologias assistivas.

Acessibilidade de controles não semânticos

Quando uma série de <div>s aninhados junto com CSS/JavaScript é usada para criar um recurso complexo de IU, ou um controle nativo é bastante aprimorado/alterado via JavaScript, a acessibilidade pode sofrer — usuários de leitores de tela acharão difícil entender o que o recurso faz se não houver semântica ou outras pistas.

Nessas situações, o ARIA pode ajudar a fornecer o que está faltando com uma combinação de roles como button, listbox ou tablist, e propriedades como aria-required ou aria-posinset para fornecer mais pistas sobre a funcionalidade.

Validação de formulários e alertas de erro

Imagine nosso HTML criado para lidarmos com erros de um formulário:

Quando adicionamos role="alert" a um elemento, ele se torna como um megafone: qualquer mudança que aconteça ali será imediatamente anunciada por leitores de tela e também marca o elemento como portador de uma mensagem importante.

Além disso, quando usamos aria-relevant="all", estamos dizendo ao leitor de tela para ficar atento a qualquer novidade naquele elemento, seja uma adição ou remoção de conteúdo.

É como se, após o anúncio inicial, continuássemos recebendo atualizações sobre como a situação está evoluindo.

Isso é útil em formulários, porque permite que os usuários saibam exatamente o que precisam corrigir ou prestar atenção, sem terem que adivinhar o que mudou desde a última vez que tentaram enviar o formulário.

No entanto, é importante lembrar — você deve usar o WAI-ARIA apenas quando necessário!

Idealmente, você sempre deve usar recursos HTML nativos para fornecer a semântica exigida pelos leitores de tela para informar seus usuários sobre o que está acontecendo.

Às vezes isso não é possível, seja porque você tem controle limitado sobre o código, ou porque está criando algo complexo que não tem um elemento HTML fácil de implementar.

Nesses casos, o WAI-ARIA pode ser uma ferramenta valiosa para aprimorar a acessibilidade.

Mas lembre-se, use-o apenas quando necessário!

Conclusão

Chegamos ao fim de nossa jornada explorando o universo do WAI-ARIA, e é claro que mal arranhamos a superfície do vasto potencial que essa ferramenta oferece para tornar a web um lugar mais acessível e inclusivo.

O que discutimos aqui é apenas uma pequena parte do poder que o WAI-ARIA tem para enriquecer a experiência do usuário na web, especialmente para aqueles que dependem de tecnologias assistivas.

No entanto, é crucial lembrar que, embora o WAI-ARIA ofereça soluções extraordinárias, seu uso inadequado pode levar a mais problemas de acessibilidade, em vez de solucioná-los. A implementação incorreta de roles, properties e states pode confundir os usuários de tecnologias assistivas, resultando em uma experiência de navegação frustrante e ineficaz.

Além disso, é fundamental enfatizar a importância do HTML semântico. Antes de recorrer ao WAI-ARIA, devemos explorar todas as possibilidades que o HTML oferece por si só.

Muitas necessidades de acessibilidade podem ser atendidas com elementos HTML semânticos, que já possuem suporte integrado para acessibilidade.

O WAI-ARIA deve ser visto como uma ferramenta para preencher as lacunas que o HTML não pode cobrir por conta própria, e não como uma solução primária para todos os desafios de acessibilidade.

Portanto, enquanto caminhamos na direção de uma web mais acessível, devemos manter um equilíbrio cuidadoso: utilizar o HTML semântico sempre que possível e recorrer ao WAI-ARIA de maneira judiciosa e informada.

Isso garantirá que nossas aplicações sejam não apenas acessíveis, mas também robustas e amigáveis para todos os usuários.

Ao adotar essa abordagem equilibrada, podemos contribuir para uma internet que acolha todos, independentemente de suas características.

A acessibilidade não é apenas uma consideração técnica; é um compromisso com a inclusão e a diversidade na era digital.

E aqui na Alura nós temos mais conteúdo sobre acessibilidade, se liga só:

• Acessibilidade e tecnologias web: técnicas em HTML, CSS e JavaScript para projetos inclusivos - Aqui vamos mergulhar em técnicas e ferramentas que ajudam a validar a acessibilidade das nossas aplicações.

• Criando uma aplicação acessível com JavaScript, Emotion e React Router - Nessa formação a gente cria um projeto do zero, aplicando algumas técnicas pra garantir a acessibilidade dos componentes React.

• Acessibilidade: estudando com tecnologias assistivas (parceria Alura e Itaú Unibanco) - Nesse curso a Louise ensina como configurar e utilizar tecnologias assistivas no Windows.