ARIA: veneno ou antídoto?

O que é ARIA?

A ARIA permite que os autores da Web criem uma realidade alternativa, que só é vista por leitores de tela.

Às vezes, é necessário expandir a verdade ou até mesmo "mentir" para leitores de tela sobre o que está acontecendo no conteúdo da Web. Por exemplo, "o foco realmente está aqui!" ou "isso é realmente um controle deslizante!". É como adicionar notas adesivas mágicas em cima de ferramentas e widgets em seu painel de trabalho. Essas notas autoadesivas mágicas fazem com que todos acreditem no que está escrito nelas.

Quando existe uma nota adesiva mágica, ela substitui nossa crença sobre o que cada ferramenta é ou faz. Por exemplo, se você adicionar ARIA que declara "esta coisa aqui é uma pistola de cola!". Mesmo que seja uma caixa azul vazia, a nota adesiva mágica nos diz que é uma pistola de cola. Também podemos adicionar "e está 30% cheia". O leitor de tela agora informa que há uma pistola de cola cheia de 30%.

O equivalente na Web é usar um div simples com uma imagem dentro dele e usar ARIA para indicar que é um controle deslizante com o valor 30 de 100. A ARIA não transforma o div em um controle deslizante, apenas informa ao leitor de tela que ele é um.

ARIA não afeta a aparência de uma página da Web nem o comportamento de um usuário de mouse ou teclado. Somente os usuários de tecnologias adaptativas percebem o impacto da ARIA. Os desenvolvedores da Web podem adicionar qualquer ARIA arbitrária sem afetar os usuários que não estão executando uma tecnologia adaptativa.

Você leu certo: a ARIA não faz nada com o foco do teclado ou a ordem de guias. Tudo isso é feito em HTML, às vezes ajustado com pedaços de JavaScript.

Como funciona a ARIA?

Um leitor de tela ou outra tecnologia adaptativa solicita informações sobre cada elemento aos navegadores. Quando ARIA está presente em um elemento, o navegador recebe as informações e muda o que ele informa ao leitor de tela sobre esse elemento.

Confira alguns usos comuns da ARIA.

• Adicione componentes especiais que não existem no HTML, como preenchimento automático, uma árvore ou uma planilha.
• Adicionar componentes que existem no HTML, mas que o autor decidiu reinventar, possivelmente porque queria mudar o comportamento ou a aparência do elemento padrão. Por exemplo, um elemento HTML <input type="range"> é basicamente um controle deslizante, mas os autores querem que ele tenha uma aparência diferente.
  • Na maioria dos casos, isso pode ser resolvido com CSS. No entanto, para range, o CSS é estranho. Os autores podem criar o próprio controle deslizante e usar role="slider" com aria-valuenow para informar ao teclado qual é o valor atual.
• Inclua regiões ativas para informar aos leitores de tela sobre mudanças relevantes em uma área da página.
• Crie pontos de referência, como títulos. Os pontos de referência ajudam os usuários de leitores de tela a encontrar o que querem mais rapidamente. Os marcos podem conter uma área inteira relacionada. Por exemplo, "este contêiner é a área principal da página" e "este contêiner é um painel de navegação".

Por que usar a ARIA?

Pode ser útil adicionar um pouco de ARIA ao HTML que já funciona. Por exemplo, podemos querer que um controle de formulário aponte para um alerta de mensagem de erro para uma entrada inválida. Ou talvez queiramos indicar o uso específico de uma entrada de texto. Esses ajustes podem tornar sites comuns mais utilizáveis com um leitor de tela.

Exemplo de barra de menus

Digamos que a loja on-line local não venda todos os widgets de que precisamos. Mas somos MacGyver. Podemos criar nossos próprios widgets com base em outros widgets. Isso é muito semelhante a um autor da Web que precisa criar uma barra de menus.

Embora o elemento <nav> exista, as barras de menu geralmente são montadas usando divs, imagens, botões, manipuladores de clique, manipuladores de pressionamento de tecla e ARIA.

Oferecer suporte a usuários de mouse

Vamos criar uma barra de menus juntos. Mostramos vários itens em elementos de caixa genéricos chamados divs. Sempre que o usuário clica em um div, ele executa o comando correspondente. Legal, funciona para pessoas que usam o mouse!

Em seguida, deixamos tudo bonito. Usamos CSS para alinhar bem os elementos e colocar contornos visuais em torno deles. Fazemos com que ela se pareça o suficiente com outras barras de menus para que os usuários saibam intuitivamente que se trata de uma barra de menus e como usá-la. Nossa barra de menu usa até mesmo uma cor de plano de fundo diferente em qualquer item sobre o qual o mouse está posicionado, ao usuário um feedback visual útil.

Alguns itens de menu são principais. Eles geram submenus filhos. Sempre que o usuário passa o cursor sobre um deles, inicia-se uma animação que desliza o submenu filho.

Tudo isso é bastante inacessível, como é o caso de muitas coisas na Web.

Tornar a barra de menus acessível para teclado

Vamos adicionar a acessibilidade do teclado. Isso exige apenas mudanças no HTML, e não na ARIA. Lembre-se de que a ARIA não afeta aspectos principais, como aparência, mouse ou teclado para usuários sem tecnologias adaptativas.

Assim como uma página da Web pode responder ao mouse, ela também pode responder ao teclado. Nosso JavaScript pode detectar todos os pressionamentos de tecla que ocorrem e decidir se o pressionamento de tecla é útil. Caso contrário, ele vai voltar para a página como um peixe pequeno demais para comer. Nossas regras são mais ou menos assim:

• Se o usuário pressionar uma tecla de seta, vamos analisar nossos próprios modelos internos de barra de menus e decidir qual será o novo item de menu ativo. Vamos limpar todos os destaques atuais e destacar o novo item de menu para que o usuário com visão saiba onde está. A página da Web precisa chamar event.preventDefault() para impedir que o navegador execute a ação usual (rolar a página, neste caso).
• Se o usuário pressionar a tecla Enter, poderemos tratá-la como um clique e realizar a ação adequada (ou até mesmo abrir outro menu).
• Se o usuário pressionar uma tecla que precisa fazer outra coisa, envie-a de volta para a página. Por exemplo, nossa barra de menus não precisa da tecla Tab, então jogue de volta. Isso é difícil de acertar. Por exemplo, a barra de menus precisa de teclas de seta, mas não de Alt+seta ou Command+seta. Esses são atalhos para ir para a página anterior e a próxima no histórico da Web da guia do navegador. Se o autor não tiver cuidado, a barra de menus vai consumir esses recursos. Esse tipo de bug acontece muito, e ainda não começamos a usar a ARIA.

Acesso do leitor de tela à barra de menus

Nossa barra de menu foi criada com fita adesiva e divs. Como resultado, o leitor de tela não tem ideia do que seja. A cor de fundo do item ativo é apenas uma cor. Os divs de itens de menu são apenas objetos simples sem significado específico. Consequentemente, um usuário da nossa barra de menu não recebe instruções sobre quais teclas pressionar ou em qual item ele está.

Mas isso não é justo! A barra de menu funciona bem para o usuário com visão.

ARIA ao resgate. A ARIA permite simular para o leitor de tela que o foco está em uma barra de menus. Se o autor fizer tudo certo, nossa barra de menu personalizada vai parecer ao leitor de tela como uma barra de menu em um aplicativo para computador.

Nossa primeira mentira do ARIA é o atributo aria-activedescendant. Defina o atributo como o ID do item de menu ativo e tenha o cuidado de atualizá-lo sempre que mudar. Por exemplo, aria-activedescendant="settings-menuitem". Isso faz com que o leitor de tela considere o item ativo do ARIA como o foco, que é lido em voz alta ou mostrado em uma linha braille.

Ao usar aria-activedescendant para apontar da barra de menus em foco para um item específico, o leitor de tela agora sabe para onde o usuário se moveu, mas nada mais sobre o objeto. O que é essa coisa de div? É aí que entra o atributo de função. Usamos role="menubar" no elemento que o contém para a coisa toda e, em seguida, usamos role="menu" em grupos de itens e role="menuitem" no ... tambor ... nos itens individuais do menu.

E se o item de menu puder levar a um menu filho? O usuário precisa saber disso. Para um usuário vidente, pode haver uma pequena imagem de um triângulo no final do menu, mas o leitor de tela não sabe ler imagens automaticamente, pelo menos por enquanto. Podemos adicionar aria-expanded="false" em cada item de menu expansível para indicar que há algo que pode ser expandido e que não está aberto. Além disso, o autor precisa colocar role="none" no triângulo img para indicar que é apenas para fins estéticos. Isso impede que o leitor de tela diga algo sobre a imagem que seja redundante.

Corrigir bugs do teclado

Embora o acesso ao teclado faça parte do HTML principal, ele é fácil de substituir. Por exemplo:

• Uma caixa de seleção usa a barra de espaço para alternar, mas o autor esqueceu de chamar preventDefault(). Agora, a barra de espaço alterna a caixa de seleção e move a página para baixo, que é o comportamento padrão do navegador para a barra de espaço.
• Uma caixa de diálogo modal ARIA quer prender a navegação de guias dentro dela. Se o autor esquecer de permitir especificamente que Control+Tab abra uma nova guia enquanto estiver na caixa de diálogo, ela não vai funcionar como esperado.
• O autor cria uma lista de seleção e implementa as teclas para cima e para baixo. No entanto, o autor ainda precisa adicionar a navegação de início, fim, página para cima, página para baixo ou primeira letra.

Os autores precisam seguir padrões conhecidos. Confira a seção Recursos para mais informações.

Para problemas de acesso puro ao teclado, também é útil tentar sem um leitor de tela ou com o modo de navegador virtual desativado. Você pode descobrir bugs de teclado sem um leitor de tela, já que o acesso ao teclado é implementado com HTML, não ARIA. Afinal, a ARIA não afeta o comportamento do teclado ou do mouse. Em vez disso, ela informa ao leitor de tela o que está na página da Web, o que está atualmente em foco e assim por diante.

Os bugs do teclado quase sempre são um bug no conteúdo da Web, especificamente no HTML e no JavaScript, não na ARIA.

Por que há tantos?

Há muitas maneiras de um autor usar a ARIA incorretamente. Cada erro leva a uma falha completa ou a diferenças sutis. Os problemas sutis podem ser piores, porque é improvável que o autor os detecte antes da publicação.

Afinal, a menos que o autor seja um usuário experiente de leitor de tela, algo dará errado no ARIA. Em nosso exemplo da barra de menus, o autor poderia pensar que o papel "option" deveria ser usado quando "menuitem" estivesse correto. Eles podem se esquecer de usar aria-expanded, esquecer de definir e limpar o aria-activedescendant nos momentos certos ou esquecer de ter uma barra de menus contendo os outros menus. E quanto à contagem de itens de menu? Normalmente, os itens de menu são apresentados por leitores de tela com algo como "item 3 de 5" para que o usuário saiba onde eles estão. Isso geralmente é contado automaticamente pelo navegador, mas em alguns casos e em algumas combinações de navegador e leitor de tela, os números errados podem ser calculados, e o autor precisa substituir esses números por aria-posinset e aria-setsize.

E isso é apenas barras de menu. Pense em quantos tipos de widgets existem. Confira a especificação ARIA ou práticas de criação, se quiser. Para cada padrão, ARIA pode ser usado indevidamente de várias maneiras. A ARIA depende de que os autores saibam o que estão fazendo. O que poderia dar errado, já que a maioria dos autores não são usuários de leitores de tela?

Em outras palavras, é 100% necessário que os usuários de leitores de tela reais testem os widgets ARIA antes de serem considerados para envio. Tem muitas nuances. O ideal é que tudo seja testado com várias combinações diferentes de leitores de tela do navegador, devido às diversas peculiaridades de implementação, além de algumas implementações incompletas.

Resumo

A ARIA pode ser usada para substituir ou adicionar a qualquer coisa que o HTML diz. Ele pode fazer pequenas mudanças na apresentação de acessibilidade ou criar uma experiência completa. Por esse motivo, a ARIA é incrivelmente poderosa e perigosa nas mãos de desenvolvedores que não são usuários de leitores de tela.

A ARIA é uma camada de marcação que substitui outras escolhas. Quando um leitor de tela pergunta o que está acontecendo, se o ARIA existe, o usuário recebe a versão ARIA da verdade.

Outros recursos

O W3C's ARIA Authoring Practices documenta as características importantes de navegação pelo teclado de cada exemplo e fornece JavaScript, CSS e ARIA em funcionamento. Os exemplos se concentram no que funciona hoje e não abrangem dispositivos móveis.

O que é uma API de acessibilidade?

Uma API de acessibilidade é como um leitor de tela ou outra tecnologia adaptativa sabe o que está na página e o que está acontecendo. Os exemplos incluem MSAA, IA2 e UIA. Há duas partes em uma API de acessibilidade:

• Uma "árvore" de objetos que representa uma hierarquia de contêineres. Por exemplo, um documento pode conter vários parágrafos. Um parágrafo pode ter texto, imagens, links e decorações de texto. Cada item na árvore de objetos pode ter propriedades, como função (o que sou?), um nome ou rótulo, um valor inserido pelo usuário, uma descrição e estados booleanos, como foco, foco, obrigatório, marcado. A ARIA pode substituir qualquer uma dessas propriedades.
  • Os leitores de tela usam a árvore para ajudar os usuários a navegar no modo de buffer virtual, como "vá para o próximo título".
• Uma série de eventos que ocorrem descrevendo mudanças na árvore, como "o foco agora está aqui!". O leitor de tela usa eventos para informar ao usuário o que acabou de acontecer. Quando uma marcação HTML ou ARIA importante muda, um evento é disparado para informar ao leitor de tela que algo mudou.

O HTML é mapeado perfeitamente para essas APIs de acessibilidade. Quando o HTML não é suficiente, a ARIA pode ser adicionada para que o navegador substitua a semântica do HTML antes de enviar a árvore de objetos ou os eventos para o leitor de tela.