ARIA: veneno ou antídoto?

Aaron Leventhal

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 está aqui!" ou "este é um controle deslizante". É como adicionar notas autoadesivas mágicas em cima de ferramentas e widgets na bancada de trabalho. Essas notas autoadesivas mágicas fazem com que todos acreditem no que está escrito nelas.

Quando uma nota autoadesiva mágica existe, 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". Agora, o leitor de tela informa que há uma pistola de cola com 30% de carga.

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 em 100. A ARIA não transforma o div em um controle deslizante, apenas informa ao leitor de tela que ele é um.

A 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 a ARIA funciona?

Os navegadores são solicitados por um leitor de tela ou outra tecnologia adaptativa para receber informações sobre cada elemento. Quando a 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 <input type="range"> HTML é basicamente um controle deslizante, mas os autores querem que ele pareça 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 ao vivo 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 com mais rapidez. 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 ARIA a um 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 os sites comuns mais utilizáveis com um leitor de tela.

Exemplo de barra de menus

Digamos que a loja da Web 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 de 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 o CSS para alinhar os elementos e colocar contornos visuais ao redor 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 até usa 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 do menu são pais. 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 requer 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 todas as teclas pressionadas e decidir se o pressionamento de tecla é útil. Caso contrário, ele é enviado de volta à página como um peixe muito pequeno 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 de barra de menu interna 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, podemos tratá-la como um clique e realizar a ação apropriada (ou até abrir outro menu).
• Se o usuário pressionar uma tecla que precisa fazer outra coisa, envie-o de volta para a página. Por exemplo, nossa barra de menus não precisa da tecla Tab. Então, descarte-a. Isso é difícil de fazer. 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 à nossa barra de menus

Nossa barra de menu foi criada com fita adesiva e divs. Como resultado, um leitor de tela não tem ideia do que ele é. A cor de plano 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 da ARIA é o atributo aria-activedescendant. Defina o atributo como o ID do item de menu ativo, atualizando-o sempre que ele 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.

Explicação de antepassado, parente e descendente

O termo "descendente" se refere ao fato de que um item está contido em outro. O termo oposto é "ancestral", que significa que um item está contido em ancestrais. Para o próximo contêiner para cima/para baixo, eles podem usar os termos mais específicos pai/filho. Por exemplo, imagine um documento com um parágrafo que tem um link dentro. O pai do link é um parágrafo, mas ele também tem o documento como ancestral. Por outro lado, o documento pode ter muitos parágrafos filhos, cada um com links. Todos os links são descendentes do documento ancestral.

Ao usar aria-activedescendant para apontar da barra de menu focada para um item de menu 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 contém tudo e, em seguida, usamos role="menu" em grupos de itens e role="menuitem" em… suspense… itens de menu individuais.

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 como 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 pelo teclado faça parte do HTML principal, é fácil substituí-lo. 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 funcionará como esperado.
• Um 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 ao teclado, é útil tentar sem um leitor de tela ou com o modo de navegador virtual desativado. É possível descobrir bugs do 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 leitores de tela, algo vai dar errado na ARIA. No nosso exemplo de barra de menu, o autor poderia pensar que o papel "option" deveria ser usado quando "menuitem" estasse correto. Eles podem esquecer de usar aria-expanded, esquecer de definir e limpar aria-activedescendant nos momentos certos ou esquecer de ter uma barra de menus que contenha os outros menus. E quanto à contagem de itens de menu? Normalmente, os itens do 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 com 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, há uma dúzia de maneiras de usar indevidamente a ARIA. 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. Há muitas nuances. O ideal é que tudo fosse tentado com várias combinações diferentes de navegador e leitor de tela devido às inúmeras 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.

O 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

As Práticas de Criação de ARIA do W3C documentam as características importantes de navegação pelo teclado de cada exemplo e fornecem 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 está aqui agora!". 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 é acionado 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.